From mip4-bounces@ietf.org Tue Aug 02 15:51:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02ng-0006kt-9u; Tue, 02 Aug 2005 15:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzQWz-0002VE-7w for mip4@megatron.ietf.org; Sun, 31 Jul 2005 22:59:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03008 for ; Sun, 31 Jul 2005 22:59:54 -0400 (EDT) Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzR3B-00067N-JD for mip4@ietf.org; Sun, 31 Jul 2005 23:33:13 -0400 Received: from hpn307pc2 (cpe-69-204-120-221.rochester.res.rr.com [69.204.120.221]) by ms-smtp-02.nyroc.rr.com (8.12.10/8.12.10) with SMTP id j712xsIU023582 for ; Sun, 31 Jul 2005 22:59:54 -0400 (EDT) Message-ID: <023001c59645$17505e60$6801a8c0@hpn307pc2> From: "Wendi Heinzelman" To: Date: Sun, 31 Jul 2005 22:59:53 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Aug 2005 15:51:43 -0400 Subject: [Mip4] MobiCom 2005 discounted registration deadline August 5 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org The deadline for early discounted registration to attend MobiCom 2005, the Eleventh Annual International Conference on Mobile Computing and Networking, is August 5, 2005. Registration after this date is still available but at the non-discounted rate. Registration is available at http://www.regmaster.com/mobicom2005.html. ******************************************************************* Call for Participation 11th Annual International Conference on Mobile Computing and Networking August 28 - September 2, 2005 Cologne, Germany http://www.sigmobile.org/mobicom/2005/ ******************************************************************* ACM MobiCom is a highly-selective international conference on mobile computing and wireless and mobile networking. It serves as the premier forum for presenting and discussing research results on networks, systems, algorithms, and applications supporting the symbiosis of mobile computing and wireless networking. Each year, the conference attracts about 500 researchers, practitioners, students, and executives. MobiCom 2005 will be held in beautiful Cologne, Germany. Technical Program. The program consists of a single track with 23 papers. The authors present cutting-edge results on various topics, such as new architectures, content-based and geometric routing, self-management, cross-layer optimization. The papers cover ad hoc networks, mesh networks, wireless sensor networks, WLANs, and cellular networks. A list of accepted papers can be found at http://www.sigmobile.org/mobicom/2005/program.html. Tutorials. Four tutorials will be offered: (a) Wireless sensor and actuator networks, (b) 802.11 WLAN MAC and smart antennas: issues and directions, (c) Security in sensor and ad hoc networks: perspectives and status, and (d) Wide area wireless networks: 3G and beyond. The conference will also feature two invited talks by leaders in our field: (a) "Secure, Natural Communications," by Jeffrey M. Jaffe, President, Bell Labs Research and Advanced Technologies, and (b) "Communicating Vehicles - Communicating Roadways: New Approaches to Driver Information and Road Safety," by Ralf Guido Herrtwich, Director Vehicle IT and Services Research, DaimlerChrysler AG. Cologne is very popular, especially in August due to World Youth Day 2005 taking place there. Because Pope Benedict XVI organizes this event, he will be in town just the week before MobiCom. Thus, we ask you to make your hotel and flight reservations as early as possible. For more travel info please visit http://www.sigmobile.org/mobicom/2005/travel.html. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 05 13:55:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E16Q1-0005Uw-U2; Fri, 05 Aug 2005 13:55:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0tRP-0000dl-DI; Fri, 05 Aug 2005 00:04:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28562; Fri, 5 Aug 2005 00:04:12 -0400 (EDT) Received: from gator9.hostgator.com ([67.18.141.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0tyO-0000fx-Ba; Fri, 05 Aug 2005 00:38:22 -0400 Received: from pool-71-96-167-218.dfw.dsl-w.verizon.net ([71.96.167.218]:50098 helo=cow) by gator9.hostgator.com with esmtpa (Exim 4.50) id 1E0tQ3-0007aG-8f; Thu, 04 Aug 2005 23:02:51 -0500 From: "Dawn " To: Date: Thu, 4 Aug 2005 23:02:54 -0500 Message-ID: <002001c59972$90fdf0d0$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator9.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - icst.org X-Spam-Score: 0.6 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 X-Mailman-Approved-At: Fri, 05 Aug 2005 13:55:40 -0400 Cc: Subject: [Mip4] Call for Participation - BroadNets 2005 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0408965181==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0408965181== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C59948.A827E8D0" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C59948.A827E8D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable *** We apologize if you have received multiple copies of this message = *** =20 ----------------------------------------------------------------------- CALL FOR PARTICIPATION IEEE Second Annual International Conference on Broadband Networks=20 (IEEE BroadNets 2005) October 3 - 7, 2005 Radisson Hotel Boston, Massachusetts, USA http://www.broadnets.org/ =20 ----------------------------------------------------------------------- IEEE BroadNets 2005 is an international conference focusing on broadband networking and covers the entire gamut of next generation networks with = high bandwidth available for both wireless and wireline networks. The = conference consists of the following three symposia: ** Broadband Optical Networking Symposium: It covers WDM technologies, Ethernet and MPLS integration into the optical layer, Next-Generation SONET/SDH, as well as SAN extensions over DWDM/SONET/SDH. ** Broadband Wireless Networking Symposium: It covers mobility, routing = for multihop, multimedia QoS and traffic management, cross-layer = optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed wireless networking. ** Broadband Applications/Services Symposium: It covers middleware and service architectures for broadband applications, pervasive computing = and ubiquitous communications, and universal broadband access for = information services. BroadNets 2005 thus offers a unique forum for researchers from academia, government and industry to share ideas and disseminate new results in = these important areas. The technical program as well registration information is available on = the conference website at http://www.broadnets.org/ =20 =20 =20 ------=_NextPart_000_0021_01C59948.A827E8D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

*** We = apologize if you have received multiple copies of this message ***

 

----------------------------------------------= -------------------------
CALL FOR PARTICIPATION

IEEE Second Annual International Conference = on Broadband Networks
(IEEE BroadNets 2005)
October 3 - 7, 2005
Radisson Hotel Boston, Massachusetts, USA
http://www.broadnets.org/
-----------------------------------------------------------------------

IEEE BroadNets 2005 is an international conference focusing on broadband = networking and covers the entire gamut of next generation networks with high = bandwidth available for both wireless and wireline networks. The conference = consists of the following three symposia:

** Broadband Optical Networking Symposium: It covers WDM technologies, = Ethernet and MPLS integration into the optical layer, Next-Generation SONET/SDH, = as well as SAN extensions over DWDM/SONET/SDH.

** Broadband Wireless Networking Symposium: It covers mobility, routing for multihop, multimedia QoS and traffic management, cross-layer = optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed = wireless networking.

** Broadband Applications/Services Symposium: It covers middleware and = service architectures for broadband applications, pervasive computing and = ubiquitous communications, and universal broadband access for information = services.

BroadNets 2005 thus offers a unique forum for researchers from academia, = government and industry to share ideas and disseminate new results in these important = areas.

The technical program as well registration information is available on the conference website at http://www.broadnets.org/

 

 

 

------=_NextPart_000_0021_01C59948.A827E8D0-- --===============0408965181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0408965181==-- From mip4-bounces@ietf.org Fri Aug 05 13:55:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E16Q2-0005VN-8l; Fri, 05 Aug 2005 13:55:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0vXI-0001j1-BQ for mip4@megatron.ietf.org; Fri, 05 Aug 2005 02:18:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16615 for ; Fri, 5 Aug 2005 02:18:26 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0w4I-0003Gz-TH for mip4@ietf.org; Fri, 05 Aug 2005 02:52:36 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 23:18:15 -0700 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.12.202]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 23:18:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Aug 2005 23:18:17 -0700 Message-ID: Thread-Topic: Call For Papers: Workshop on emerging services delivery platforms and software models for Next Generation Network Services thread-index: AcWZhXhZPBc/hL+CTbiFaik67qoCjg== From: "Joshy Joseph" To: X-OriginalArrivalTime: 05 Aug 2005 06:18:15.0532 (UTC) FILETIME=[76F3DAC0:01C59985] X-Spam-Score: 0.5 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 X-Mailman-Approved-At: Fri, 05 Aug 2005 13:55:40 -0400 Subject: [Mip4] Call For Papers: Workshop on emerging services delivery platforms and software models for Next Generation Network Services X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1308707589==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1308707589== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59985.76731E94" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59985.76731E94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Apologies, if you receive multiple copies of this request. =20 Call For Papers: Workshop on emerging services delivery platforms and software models for Next Generation Network Services (http://www.softplatforms.org) This workshop will be held in conjunction with the FIRST International Conference on COMmunication System softWAre and MiddlewaRE (COMSWARE 2006) at New Delhi, India (http://www.comsware.org/) from Jan 8-12 2006. =20 The exact date of the workshop will be made available on the workshop's Web site http://www.softplatforms.org. =20 Workshop Objectives:=20 The next generation services networks deliver enhanced business capabilities such as data, video, messaging and business functions for wired and wireless consumers. These new sets of services enhance the business opportunities by integrating with core business services, including: supply chain management, customer management, and consumer applications. This workshop aims to discuss topics related to emerging next generation services and service delivery platforms to host/support such complex application environments.=20 =20 The workshop focuses on: * How next generation service delivery platforms deliver enhanced QoS management, operational efficiencies, flexible services composability, faster time-to-market, efficient trust models and flexible pricing models. * Technical and business factors influencing the services composability and network services delivery environments. The associated revenue and cost models for consumers, suppliers and application providers. * The influences of emerging distributed computing architecture styles (loosely-coupled, asynchronous, compos able, collaborative, decentralized and parallel services) related to service delivery models. * Emerging middleware platforms for network services, service composability, distributed architecture models and programming models. * New services models (communication services, presence-enabled services, content/media services and enterprise/legacy services) and value creation environments that represents new business opportunities for operators and providers. =20 This workshop invites papers from research and business communities on the different aspects of service delivery platforms and emerging services models. The workshop will include papers that examine interesting practical problems, case studies, best practices, middleware platforms and innovative messaging architectures.=20 =20 Submission Guidelines: All papers are limited to 5 pages and must be in standard IEEE double-column format. All submissions must be sent by email to the workshops co-chairs with the e-mail addresses given above.=20 =20 Important Dates:=20 Paper Submission Deadline: September 23, 2005=20 Notification of Acceptance: October 28, 2005=20 Camera-Ready Papers: November 25, 2005=20 =20 Contact and organization: For any questions regarding the workshop feel free to contact=20 1. Craig Fellenstein, IBM (cfellen@us.ibm.com)=20 2. Joshy Joseph, Microsoft (jojoseph@microsoft.com)=20 =20 Submission requirements: All papers are limited to 5 pages and must be in standard IEEE double-column format. All submissions must be sent by email to the workshops co-chairs. ------_=_NextPart_001_01C59985.76731E94 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Apologies, if you receive multiple copies of this = request.

 

Call For Papers:  Workshop on emerging services = delivery platforms and software models for Next Generation Network Services (http://www.softplatforms.org)

This workshop will be held in conjunction with the = FIRST International Conference on COMmunication System softWAre and MiddlewaRE (COMSWARE 2006) at New = Delhi, India (http://www.comsware.org/) from Jan 8-12 2006. =

 

The exact date of the workshop will be made available = on the workshop's Web site = http://www.softplatforms.org.

 

Workshop Objectives:

The next generation services networks deliver = enhanced business capabilities such as data, video, messaging and business = functions for wired and wireless consumers. These new sets of services enhance the = business opportunities by integrating with core business services, including: = supply chain management, customer management, and consumer applications. This = workshop aims to discuss topics related to emerging next generation services and = service delivery platforms to host/support such complex application = environments.

 

The workshop focuses on:

* How next generation service delivery platforms = deliver enhanced QoS management, operational efficiencies, flexible services composability, faster time-to-market, efficient trust models and = flexible pricing models.

* Technical and business factors influencing the = services composability and network services delivery environments. The associated revenue and cost models for consumers, suppliers and application = providers.

* The influences of emerging distributed computing architecture styles (loosely-coupled, asynchronous, compos able, = collaborative, decentralized and parallel services) related to service delivery = models.

* Emerging middleware platforms for network services, service composability, distributed architecture models and programming = models.

* New services models (communication services, presence-enabled services, content/media services and enterprise/legacy services) and value creation environments that represents new business opportunities for operators and providers.

 

This workshop invites papers from research and = business communities on the different aspects of service delivery platforms and = emerging services models. The workshop will include papers that examine = interesting practical problems, case studies, best practices, middleware platforms = and innovative messaging architectures.

 

Submission Guidelines:

All papers are limited to 5 pages and must be in = standard IEEE double-column format. All submissions must be sent by email to the workshops co-chairs with the e-mail addresses given above. =

 

Important Dates:

Paper Submission Deadline: September 23, 2005 =

Notification of Acceptance: October 28, 2005 =

Camera-Ready Papers: November 25, 2005 =

 

Contact and = organization:

For any questions regarding the workshop feel free to contact

1. Craig Fellenstein, IBM (cfellen@us.ibm.com) =

2. Joshy Joseph, Microsoft (jojoseph@microsoft.com) =

 

Submission requirements:

All papers are limited to 5 pages and must be in = standard IEEE double-column format. All submissions must be sent by email to the workshops co-chairs.

------_=_NextPart_001_01C59985.76731E94-- --===============1308707589== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1308707589==-- From mip4-bounces@ietf.org Tue Aug 09 18:30:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ccc-0004qX-6I; Tue, 09 Aug 2005 18:30:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2cca-0004q5-DS for mip4@megatron.ietf.org; Tue, 09 Aug 2005 18:30:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19640 for ; Tue, 9 Aug 2005 18:30:53 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2dAY-0000xj-Ve for mip4@ietf.org; Tue, 09 Aug 2005 19:06:04 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 18:30:43 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 18:30:43 -0400 Message-ID: Thread-Topic: [Mip4] MobiCom 2005 discounted registration deadline August 5 Thread-Index: AcWXnARhpVsoaPggRQOokumH/mwo9QFlICgw From: "Soliman, Hesham" To: X-OriginalArrivalTime: 09 Aug 2005 22:30:43.0634 (UTC) FILETIME=[FAC8A920:01C59D31] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: "Tsirtsis, George" Subject: [Mip4] MIPv4 transition issues X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi all,=20 I'd like to request that this WG considers the MIPv4 transition issues addressed by the solution in: draft-tsirtsis-v4v6-mipv4, which expired and will be refreshed. The MIP6 WG is considering the problem and is taking steps towards formulating a solution for MIPv6. The problem statement is=20 described in: http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-00.txt I think a solution for MIPv4 would also be appropriate and relatively simple.=20 I'd appreciate your feedback, especially in answering some=20 questions: - Do you think the work is needed? - If your answer is yes, would you be able to contribute (reviews, = ideas, drafts ..etc)? - If the answer is no, would you object to the WG taking this task?=20 If you don't care either way you don't need to answer :)=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 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 09 18:39:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ckm-0000CC-0y; Tue, 09 Aug 2005 18:39:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ckk-0000C1-8m for mip4@megatron.ietf.org; Tue, 09 Aug 2005 18:39:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20177 for ; Tue, 9 Aug 2005 18:39:18 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2dIg-0001An-JD for mip4@ietf.org; Tue, 09 Aug 2005 19:14:29 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j79MmxEn027210; Tue, 9 Aug 2005 15:48:59 -0700 (MST) Received: from [10.181.33.20] (mvp-10-181-33-20.ea.mot.com [10.181.33.20]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j79Mj8Hv007318; Tue, 9 Aug 2005 17:45:09 -0500 (CDT) Message-ID: <42F93087.5050704@motorola.com> Date: Wed, 10 Aug 2005 00:39:03 +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: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip4] MIPv4 transition issues References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: "Tsirtsis, George" , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Hesham, Soliman, Hesham wrote: > Hi all, > > I'd like to request that this WG considers the MIPv4 transition > issues addressed by the solution in: > draft-tsirtsis-v4v6-mipv4, which expired and will be refreshed. > > The MIP6 WG is considering the problem and is taking steps > towards formulating a solution for MIPv6. The problem statement is > described in: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-00.txt > > I think a solution for MIPv4 would also be appropriate and relatively > simple. > I'd appreciate your feedback, especially in answering some > questions: > - Do you think the work is needed? I think MIP4 has a NAT traversal scheme that could be re-used for MIPv6 when MH connects to a v4-exclusively access network, in order to give v6 session continuity to MH. > - If your answer is yes, would you be able to contribute (reviews, ideas, drafts ..etc)? I'd gladly review and post ideas about the above. Writing a draft probably too, but not very long. > - If the answer is no, would you object to the WG taking this > task? It's not no :-) Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Aug 13 09:23:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3vyW-0008F8-7w; Sat, 13 Aug 2005 09:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3vyT-0008F3-Pt for mip4@megatron.ietf.org; Sat, 13 Aug 2005 09:22:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20750 for ; Sat, 13 Aug 2005 09:22:56 -0400 (EDT) Received: from mail-gw1.york.ac.uk ([144.32.128.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3wXB-0006WY-M2 for mip4@ietf.org; Sat, 13 Aug 2005 09:58:51 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with SMTP id j7DDMlad001065; Sat, 13 Aug 2005 14:22:47 +0100 (BST) Message-ID: <069101c5a00a$af96a610$68892090@grouse> From: "Ji Zhang" To: , "Mobile IP v4" Date: Sat, 13 Aug 2005 14:27:00 +0100 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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-York-MailScanner: Found to be clean X-York-MailScanner-From: jz105@york.ac.uk X-Spam-Score: 3.3 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: waa@cs.umd.edu, Rajeev Koodli Subject: [Mip4] [New I-D] Agent-Based Return Routability Test for Mobile IPv4 Route Optimization X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Dear all, Please find the following a new draft: route optimization for mip4 may be an old topic, just to see if there are still any interests. Comments are highly appreciated. Regards, Ji =================================================== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Agent-Based Return Routability Test for Mobile IPv4 Route Optimization Author(s) : J. Zhang, D. Pearce Filename : draft-zhang-mobopts-agent-mip4rr-00.txt Pages : 18 Date : 2005-8-12 This document is to propose a more deployable route optimization scheme for Mobile IPv4, which is transparent to fixed IPv4 end nodes, and does not need any preconfigured security associations. Specifically, we propose to adapt the Mobile IPv6 Return Routability Test for Mobile IPv4 route optimization, on the basis of an agent- based architecture. In order to achieve this, six new message types and formats are defined for Mobile IPv4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhang-mobopts-agent-mip4rr-00.txt -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Aug 14 16:45:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4PMP-0006Qh-GO; Sun, 14 Aug 2005 16:45:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3NKJ-0004mH-SI for mip4@megatron.ietf.org; Thu, 11 Aug 2005 20:23:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08427 for ; Thu, 11 Aug 2005 20:23:10 -0400 (EDT) Received: from markov.ece.neu.edu ([129.10.60.83] helo=SMTP1.ECE.NEU.EDU) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Nsj-0006NA-Et for mip4@ietf.org; Thu, 11 Aug 2005 20:58:45 -0400 Received: from calvin.ece.neu.edu (calvin.ece.neu.edu [129.10.62.61]) by SMTP1.ECE.NEU.EDU (8.12.5/8.12.5) with SMTP id j7C0MEAe020963 for ; Thu, 11 Aug 2005 20:23:10 -0400 (EDT) Received: from ECE.NEU.EDU ([129.10.60.216]) by calvin.ece.neu.edu (SAVSMTP 3.1.0.29) with SMTP id M2005081120231017105 for ; Thu, 11 Aug 2005 20:23:10 -0400 Received: from localhost (basagni@localhost) by ECE.NEU.EDU (8.12.8/8.12.5/Submit) with ESMTP id j7C0N92L017074 for ; Thu, 11 Aug 2005 20:23:10 -0400 Date: Thu, 11 Aug 2005 20:23:09 -0400 (EDT) From: Stefano Basagni To: mip4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-Mailman-Approved-At: Sun, 14 Aug 2005 16:45:35 -0400 Subject: [Mip4] IEEE SECON 2005, Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (Apologies if you receive this call multiple times.) ************************************************************ CALL FOR PARTICIPATION IEEE SECON 2005 The Second IEEE International Conference on Sensors and Ad Hoc Communications and Networks http://www.ieee-secon.org/2005/ September 26-29 2005 Santa Clara, California, USA ************************************************************ Building on the success of last year's inaugural conference, IEEE SECON 2005 provides a forum to exchange ideas, techniques, and applications, discuss best practices, raise awareness and share experiences among researchers, practitioners, standard developers and policy makers in the field of sensor and ad hoc networks and systems. The conference is organized to provide for a degree of collegiality and continuity in the discussions of the various topics among participants from the industrial, governmental and academic sectors. * KEYNOTE SPEAKER: Professor Anthony Ephremides, University of Maryland at College Park: "Making Sense Out of Sensor Networks." * TECHNICAL PROGRAM: 55 papers have been accepted for presentation and for publication in the conference proceedings. The advance program can be found on-line at the conference web page. * PANELS: Featured panels concern cognitive networking, federal funding for wireless networks as well as current and future directions for sensor and ad hoc communications and networks. * TUTORIALS: IEEE SECON 2005 features two full-day tutorials: Wireless Sensor Networks, Ian F. Akyildiz, Georgia Tech. Mote Software Development for Wireless Sensor Networks, Tim Reilly and John Suh, Crossbow Technology, Inc. Two half-day tutorials: Security in Wireless Sensor Networks, Radha Poovendran, University of Washington at Seattle. EmStar: Sensor Networks Design, Simulation, Emulation and Deployment, Richard Guy and Lewis Girod, University of California at Los Angeles. * POSTERS: IEEE SECON 2005 includes poster sessions providing a forum for presenting and discussing recent results, ongoing work, challenges, future directions, and novel approaches in the field of sensor and ad hoc communications and networks. * WORKSHOP: The First IEEE Workshop on Wireless Mesh Networks, IEEE WiMesh 2005, will be held September 26th 2005 in conjunction with IEEE SECON 2005. (http://www.cs.ucdavis.edu/~prasant/wimesh). * DEMOS: The demo sessions include a dozen demonstrations featuring technologies that enable the wired and wireless networking infrastructure for ubiquitous computing along with applications that showcase novel user experiences in environments of complex but invisible computing infrastructure. * STUDENT TRAVEL GRANTS: The IEEE SECON 2005 organizing committee is pleased to announce the availability of Student Travel Grants. Applications are invited from qualified graduate students. See how to apply at http://inrg.cse.ucsc.edu/secon05/grants.html. Deadline 25 August, 2005. * VENUE: The Santa Clara Marriott at 2700 Mission College Boulevard, Santa Clara, CA, Please make your hotel arrangements early in order to insure getting a room at the special conference rate price ($156+taxes for a single or double room). Reservations can be made on-line http://inrg.cse.ucsc.edu/secon05/santaclara.html or by phone, Marriott Global Reservations: 1 800 228 9290 or by calling the hotel directly: 1 408-988-1500 (mention the IEEE SECON block). * IMPORTANT DATES: Discounted hotel reservation deadline 9 September 2005 Early registration deadline 29 August 2005 IEEE WiMesh 2005 26 September 2005 Conference dates 26-29 September 2005 -- Stefano Basagni, Ph.D. Assistant Professor of Computer Engineering Dept. of Electrical and Computer Engineering 312 Dana Research Center Northeastern University 360 Huntington Ave. Boston, MA 02115 Tel. 617 373 3061, Fax 617 373 8970 E-mail: basagni@ece.neu.edu *** http://www.ece.neu.edu/faculty/basagni/ *** -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 15 10:18:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4fnZ-0006ls-Pz; Mon, 15 Aug 2005 10:18:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4fnY-0006lj-AP; Mon, 15 Aug 2005 10:18:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05410; Mon, 15 Aug 2005 10:18:39 -0400 (EDT) Received: from bay106-f35.bay106.hotmail.com ([65.54.161.45] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4gMc-0008Fj-Dz; Mon, 15 Aug 2005 10:55:00 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Aug 2005 07:18:29 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 15 Aug 2005 14:18:29 GMT X-Originating-IP: [65.54.161.200] X-Originating-Email: [amin_abdul@hotmail.com] X-Sender: amin_abdul@hotmail.com From: "Amin Abdul" To: mip4@ietf.org Date: Mon, 15 Aug 2005 14:18:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Aug 2005 14:18:29.0734 (UTC) FILETIME=[35AFA860:01C5A1A4] X-Spam-Score: 0.8 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: nemo@ietf.org Subject: [Mip4] IPv4: Mobile IP Lite (Host/Network Mobility) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Any comments/questions are welcome: Objectives: 1. Re-thinking IPv4 Mobility design. 2. Take advantage of last ~10 years of IPv4 evolution 3. simplified design by removing redundant\unused\unusable objects 4. Design reused Issues: 1. IPv4 Mobility model pre-dates some recents developments in IPv4 2. IPv4 Mobility model develop in parallel with widely deployed changes in IPv4 without taking into account those changes 3. In recent years, it seems that IPv4 mobility model is bit ignore because of the push for IPv6. Mobile IP Lite: Frameworks: A. Host Mobility framework: ------------------------------------------ | Mobile Node | | Objects: | - Registration | - Co-located Care-OF-Addr | - DHCP Client | - UDP/IP Tunnel | - DNA (Detecting Network Attachment) | - Cookies (depends) (such as AAA Cookies) | - Optional tunnel Feature Profile |------------------------------------------- | | | -------------------------------------------- | Access Network | | Objects: | - Access Point | - DHCP Relay/Server | - AAA Client/Proxy (depends) | - Cookies (depends) (such as AAA Cookies) | - NAT (depends) |-------------------------------------------- | | | ------------------------------------- | Home Agent | | Objects: | - Registration | - Binding Information | - UDP/IP Tunnel | - Optional tunnel Feature Profile | - Header Compression | - Data Compression | - Content Adaptation | - Packet Buffering | - Encryption | - Proxying/Caching | - Congestion Control | - QoS | - etc... |------------------------------------- | | ------------------------ | Corresponding Node |----------------------- Please note that: 1. No Foreign Agent (FA) 2. Mobile Node Don't care about the nature of co-located care-of-addr, is it public or private 3. Simply Tunnel options - UDP/IP only 4. Usage of cookies for stateful information (such as AAA). Scope could be intra/inter domains 5. Customized tunnel features according to user(s) needs 6. AAA can be reuse for IP information as well (such as IP address, IP netmask ...) B. Network Mobility framework: ------------------------ ----------------------- | IP Enabled Device 1 | | IP Enabled Device 2 | ------------------------ ----------------------- | | | | ------------------------------------------ | Mobile Router | | Objects: | - Registration | - Co-located Care-OF-Addr | - DHCP Client | - UDP/IP Tunnel | - DNA (Detecting Network Attachment) | - Cookies (depends) (such as AAA Cookies) | - Optional tunnel Feature Profile | - IP forwarding | - NAT |------------------------------------------- | | | -------------------------------------------- | Access Network | | Objects: | - Access Point | - DHCP Relay/Server | - AAA Client/Proxy (depends) | - Cookies (depends) (such as AAA Cookies) | - NAT (depends) |-------------------------------------------- | | | ------------------------------------- | Home Agent | | Objects: | - Registration | - Binding Information | - UDP/IP Tunnel | - Optional tunnel Feature Profile | - Header Compression | - Data Compression | - Content Adaptation | - Packet Buffering | - Encryption | - Proxying/Caching | - Congestion Control | - QoS | - etc... |------------------------------------- | | ------------------------ | Corresponding Node |----------------------- Please note that only changes are: 1. Mobile Router supports IP forwarding 2. Mobile Router supports NAT Any comments/questions are welcome. /Amin 1 (519) 721 3301 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 15 12:40:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4i0l-0000TD-BY; Mon, 15 Aug 2005 12:40:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4fgC-0005cA-8O; Mon, 15 Aug 2005 10:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04734; Mon, 15 Aug 2005 10:11:06 -0400 (EDT) Received: from bay106-f14.bay106.hotmail.com ([65.54.161.24] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4gFL-00086C-6k; Mon, 15 Aug 2005 10:47:27 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Aug 2005 07:10:58 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 15 Aug 2005 14:10:57 GMT X-Originating-IP: [65.54.161.200] X-Originating-Email: [amin_abdul@hotmail.com] X-Sender: amin_abdul@hotmail.com From: "Amin Abdul" To: mip4@ietf.org Date: Mon, 15 Aug 2005 14:10:57 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Aug 2005 14:10:58.0159 (UTC) FILETIME=[2886C7F0:01C5A1A3] X-Spam-Score: 0.8 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 X-Mailman-Approved-At: Mon, 15 Aug 2005 12:40:30 -0400 Cc: nemo@ietf.org Subject: [Mip4] IPv4: Mobile IP Lite (Host/Network Mobility) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Any comments/questions are welcome: Objectives: 1. Re-thinking IPv4 Mobility design. 2. Take advantage of last ~10 years of IPv4 evolution 3. simplified design by removing redundant\unused\unusable objects 4. Design reused Issues: 1. IPv4 Mobility model pre-dates some recents developments in IPv4 2. IPv4 Mobility model develop in parallel with widely deployed changes in IPv4 without taking into account those changes 3. In recent years, it seems that IPv4 mobility model is bit ignore because of the push for IPv6. Mobile IP Lite: Frameworks: A. Host Mobility framework: ------------------------------------------ | Mobile Node | | Objects: | - Registration | - Co-located Care-OF-Addr | - DHCP Client | - UDP/IP Tunnel | - DNA (Detecting Network Attachment) | - Cookies (depends) (such as AAA Cookies) | - Optional tunnel Feature Profile |------------------------------------------- | | | -------------------------------------------- | Access Network | | Objects: | - Access Point | - DHCP Relay/Server | - AAA Client/Proxy (depends) | - Cookies (depends) (such as AAA Cookies) | - NAT (depends) |-------------------------------------------- | | | ------------------------------------- | Home Agent | | Objects: | - Registration | - Binding Information | - UDP/IP Tunnel | - Optional tunnel Feature Profile | - Header Compression | - Data Compression | - Content Adaptation | - Packet Buffering | - Encryption | - Proxying/Caching | - Congestion Control | - QoS | - etc... |------------------------------------- | | ------------------------ | Corresponding Node |----------------------- Please note that: 1. No Foreign Agent (FA) 2. Mobile Node Don't care about the nature of co-located care-of-addr, is it public or private 3. Simply Tunnel options - UDP/IP only 4. Usage of cookies for stateful information (such as AAA). Scope could be intra/inter domains 5. Customized tunnel features according to user(s) needs 6. AAA can be reuse for IP information as well (such as IP address, IP netmask ...) B. Network Mobility framework: ------------------------ ----------------------- | IP Enabled Device 1 | | IP Enabled Device 2 | ------------------------ ----------------------- | | | | ------------------------------------------ | Mobile Router | | Objects: | - Registration | - Co-located Care-OF-Addr | - DHCP Client | - UDP/IP Tunnel | - DNA (Detecting Network Attachment) | - Cookies (depends) (such as AAA Cookies) | - Optional tunnel Feature Profile | - IP forwarding | - NAT |------------------------------------------- | | | -------------------------------------------- | Access Network | | Objects: | - Access Point | - DHCP Relay/Server | - AAA Client/Proxy (depends) | - Cookies (depends) (such as AAA Cookies) | - NAT (depends) |-------------------------------------------- | | | ------------------------------------- | Home Agent | | Objects: | - Registration | - Binding Information | - UDP/IP Tunnel | - Optional tunnel Feature Profile | - Header Compression | - Data Compression | - Content Adaptation | - Packet Buffering | - Encryption | - Proxying/Caching | - Congestion Control | - QoS | - etc... |------------------------------------- | | ------------------------ | Corresponding Node |----------------------- Please note that only changes are: 1. Mobile Router supports IP forwarding 2. Mobile Router supports NAT Any comments/questions are welcome. /Amin 1 (519) 721 3301 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 15 15:50:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kyF-0001Xu-6W; Mon, 15 Aug 2005 15:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kyA-0001VP-DZ; Mon, 15 Aug 2005 15:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23036; Mon, 15 Aug 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4lXM-00085I-7v; Mon, 15 Aug 2005 16:26:24 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E4ky9-0002pq-Bu; Mon, 15 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 15 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-dynamic-assignment-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Dynamic Home Agent Assignment Author(s) : M. Kulkarni, et al. Filename : draft-ietf-mip4-dynamic-assignment-05.txt Pages : 23 Date : 2005-8-15 Mobile IPv4 [1] uses the Home Agent (HA) to anchor sessions of a roaming Mobile Node (MN). This draft proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-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-mip4-dynamic-assignment-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-mip4-dynamic-assignment-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: <2005-8-15141854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-dynamic-assignment-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-dynamic-assignment-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-15141854.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Tue Aug 16 07:47:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4zvD-0006iv-Ee; Tue, 16 Aug 2005 07:47:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4zvB-0006ij-Fg for mip4@megatron.ietf.org; Tue, 16 Aug 2005 07:47:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04556 for ; Tue, 16 Aug 2005 07:47:56 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E50UV-0006l9-PX for mip4@ietf.org; Tue, 16 Aug 2005 08:24:28 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C9B5F89852; Tue, 16 Aug 2005 14:47:47 +0300 (EEST) Message-ID: <4301D270.9030808@piuha.net> Date: Tue, 16 Aug 2005 14:48:00 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org, Charlie P 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: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: Subject: [Mip4] draft-ietf-mip4-faerr-01.txt review X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Technical: Overall, this draft is short and seems to make a lot of sense. I did have one technical question (which may be just a lack of my own understanding), one suggested addition to the security considerations section and a three very minor editorial nits. > A mobile node that cannot correctly interpret the > contents of the FA Error Extension MUST NOT use the care-of > address provided in the Registration Reply message, until another > Registration Request message has been sent and a successful > Registration Reply message received. Hmm... I may be missing something here, but why would the mobile node use the care-of address even if it did "correctly interpret the contents of the FA error extensions"? Its an error, so why continue...? > 7. Security Considerations > > The extension in this document improves the security features > of Mobile IPv4 by allowing the mobile node to be assured of the > authenticity of the information supplied within a Registration > Request. Previously, whenever the foreign agent was required to > provide status information to the mobile node, it could only do so > by destroying the ability of the mobile device to authenticated the > Mobile-Home Authentication Extension data. > In many typical cases, the mobile node will not have a security > association with the foreign agent that has sent the extension. > Thus, the mobile node will be unable to ascertain that the foreign > agent sending the extended Registration Reply message is the same > foreign agent that earlier received the associated Registration > Request from the mobile node. Because of this, a malicious foreign > agent could cause a mobile node to operate as if the registration had > failed, when in fact its home agent and a correctly operating foreign > agent had both accepted the mobile node's Registration Request. In > order to reduce the vulnerability to such maliciously transmitted > Registration Reply messages with the unauthenticated extension, the > mobile node MAY delay processing of such Registration Reply messages > for a short while in order to determine whether another authentic > Registration Reply might be received fromm the true foreign agent. This is very good. However, we should probably say something about bidding down attacks somewhere. Suggest adding the following note to the end of Section 7: It should be noted that if the mobile node can not be certain that it operates in a network that supports this extension, malicious foreign agents might still be able to change the status information. Where such vulnerability is unacceptable, the mobile node can employ a policy where it refuses to communicate with foreign agents that do not support this extension. Editorial: > (see section 3) from the space of numbers for nonskippable mobility s/nonskippable/non-skippable/ > Future allocations from this number space require IETF > consensus. Maybe s/IETF consensus/IETF Consensus [RFC 2434]/ > Registration Reply might be received fromm the true foreign agent. s/fromm/from/ --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 18 09:26:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kPJ-0000wO-6y; Thu, 18 Aug 2005 09:26:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NYC-0007VJ-Fj for mip4@megatron.ietf.org; Wed, 17 Aug 2005 09:01:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28486 for ; Wed, 17 Aug 2005 09:01:47 -0400 (EDT) Received: from hkueee2.eee.hku.hk ([147.8.180.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5O7j-00073u-Ug for mip4@ietf.org; Wed, 17 Aug 2005 09:38:32 -0400 Received: from se6000 (se6000.eee.hku.hk [147.8.180.36]) by hkueee2.eee.hku.hk (8.13.4/8.13.4) with ESMTP id j7HD1EsT017633; Wed, 17 Aug 2005 21:01:14 +0800 (HKT) Date: Wed, 17 Aug 2005 21:01:14 +0800 (HKT) From: Ka-Cheong Leung X-X-Sender: kcleung@se6000 To: mip4@ietf.org Subject: [mip4] [CFP] NASM 2005 (Deadline: Aug. 31, 2005) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-HKUEEE-MailScanner-Information: www.eee.hku.hk/intranet/computer/faq/mailscanner.htm X-HKUEEE-MailScanner: Found to be clean X-HKUEEE-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.107, required 5, autolearn=not spam, AWL 0.49, BAYES_00 -2.60) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-Mailman-Approved-At: Thu, 18 Aug 2005 09:26:07 -0400 Cc: Leung Ka Cheong X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kcleung@ieee.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (We apologize if you receive multiple copies of this CFP.) CALL FOR PAPERS The First International Workshop on Network Architecture and Service Models NASM 2005 November 21-23, 2005 Fudan University, Shanghai, China http://www.elec.qmul.ac.uk/wharf/NASM-2005.htm Technically Co-Sponsored by: British Computer Society (BCS) Institution of Electrical Engineers (IEE) Queen Mary / Fudan Joint Laboratory in Mobile Networks and Ubiquitous Computing SCOPE Network architecture and service model are two key topics of network research and applications. With the rapid development of optical and wireless communications, chips and software, network architectures are changing and new service models are needed. Many research and technical challenges are being addressed by researchers from both industries and academia. It is viewed that through international collaboration among several experts in different parts of the globe, greater research excellence and achievements can be made. OBJECTIVE The objective of this workshop is to discuss new approaches and technologies in the field of next generation networks (NGN), ad hoc mobile networks, wireless sensor networks, and P2P networks. TOPICS OF INTERESTS The main topics of interests include, but not limited to: * Network architectures and services * Optical and wireless networks * Routing and scheduling * Application model and QoS * Mobile network architecture * MAC and QoS MAC in MANET * Mobile addressing * Mobile routing * Mobile applications PAPER SUBMISSIONS - Format: Submissions should include an abstract of 100 words, 5-7 keywords, the e-mail address of the corresponding author, and must not exceed 8 pages (in 2-column format), including tables and figures, with PDF, Postscript, or MS Word format. - Submission: Please submit your paper directly to the workshop chair or co-chair. E-mail: xinw@fudan.edu.cn - Review: Contributions will be reviewed by at least three reviewers from both program committee and external reviewers for relevance and technical contents on basis of papers. - Publication: Selected accepted papers will be published as special issues of International Journal of Ad Hoc and Ubiquitous Computing (IJHAUC). http://www.inderscience.com/browse/index.php?journalID=145 IMPORTANT DATES Paper Submission Due: August 31, 2005 Acceptance Notification: October 15, 2005 Final Camera-Ready Paper: October 22, 2005 Author Registration: October 22, 2005 Workshop Date: November 22, 2005 ORGANIZERS AND COMMITTEE Honorary Chair Prof. Jiangxing Wu, NDSC, China General Chair Prof. CK Toh, Queen Mary University of London, UK Technical Program Chair Prof. Xiangyang Xue, Fudan University, China TPC Members Prof. Victor Li, University of Hong Kong, China Prof. Laurie Cuthbert, University of London, UK Prof. Hong Shen, Japan Advanced Institute of Science and Technology, Japan Prof. Yoshiaki Kakuda, Hiroshima University, Japan Prof. Tadanori Mizuno, Shizuoka University, Japan Prof. Shuigeng Zhou, Fudan University, China Prof. Ke Xu, Tsinghua University, China Prof. Hai Jin, Wuhan University, China Prof. Jiandong Li, Xidian University, China Prof. Zhengbin Li, Peking University, China Prof. Y.-H. Choi, Seoul National University, Korea Prof. H.-K. Kahng, Korea University, Korea Prof. D.-K. Kim, Kyungpook National University, Korea Dr. Jiang Du, Queensland University, Australia Prof. Lai Xu, Vrije University, Netherlands Prof. Jun Zhang, National Chiao Tung University, China Prof. Qing'an Zeng, Southeast University, China Prof. H-C. Chao, National Dong Hwa University, Taiwan, China Prof. J.-C. Chen, National Hsing Hwa University, Taiwan, China Prof. Y. S. Chen, National Chung Cheng University, Taiwan, China Dr. Russell Hsing, Telcordia Technologies Inc., USA Prof. Wei K. Tsai, University of California Irvine, USA Prof. Joe Hui, Arizona State University, USA Local Arrangements Chair Prof. Wang Xin, Fudan University, China Publicity Chair Dr. K.-C. Leung, University of Hong Kong, China -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 19 14:57:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6C3O-00005v-M8; Fri, 19 Aug 2005 14:57:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Bst-0005SQ-RE for mip4@megatron.ietf.org; Fri, 19 Aug 2005 14:46:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21163 for ; Fri, 19 Aug 2005 14:46:29 -0400 (EDT) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6CSo-0002Qu-6Q for mip4@ietf.org; Fri, 19 Aug 2005 15:23:44 -0400 Received: from [162.83.73.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11939129; Fri, 19 Aug 2005 14:46:16 -0400 Message-Id: <6.2.1.2.0.20050819141759.02ce9ec0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 19 Aug 2005 14:46:06 -0400 To: , Henrik Levkowetz , Margaret Wasserman From: "Joel M. Halpern" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Fri, 19 Aug 2005 14:57:21 -0400 Cc: Peter McCann , kleung@cisco.com, mip4@ietf.org, mkulkarn@cisco.com, alpesh@cisco.com Subject: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Gen_Art last call review of Mobile IPv4 Dynamic Home Agent Assignment draft-ietf-mip4-dynamic-assignment-05.txt The General Area Review Team (Gen_Art) serves as a review team for the IETF Chair. We are asked to review documents being considered by the IESG, and where possible to provide reviews during or after IETF last call. The Gen-Art reviewer is selected by a quasi-random process from the team. I have been selected to review this document. This is a re-review, following up on a review done of -03. This draft is almost ready for publication as a Proposed Standard RFC. However, one item that had been noted earlier still leaves room for ambiguity about certain fields: Sections 4.2 and 4.2.1 still do not identify what value is placed in the HA Address field of the second registration request, after the redirect has been received. Whatever behavior is intended (put the new HA address in the HA Address field, or continue to put ALL-ZERO-ONE-ADDR in the HA Address field to allow for further redirection, or either one) should be stated. This was in my earlier comments, and had been acknowledged as reasonable. (Sections 5.1.1 and 5.1.2 note that the new HA address must be placed in the Requested HA Extensions, but that does not answer the question of what goes in the HA Address field of the packet.) Nits: This document is using an out of date IPR clause. I don't know if it needs to be updated. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 19 15:13:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CIn-00037P-Js; Fri, 19 Aug 2005 15: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 1E6CIm-00037K-5G for mip4@megatron.ietf.org; Fri, 19 Aug 2005 15:13:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22541 for ; Fri, 19 Aug 2005 15:13:14 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Csk-00032W-Lq for mip4@ietf.org; Fri, 19 Aug 2005 15:50:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Aug 2005 12:12:56 -0700 X-IronPort-AV: i="3.96,126,1122879600"; d="scan'208"; a="333936726:sNHT1260918972" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7JJCdQQ009929; Fri, 19 Aug 2005 12:12:45 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 12:12:46 -0700 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, 19 Aug 2005 12:12:45 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC528610D7@xmb-sjc-235.amer.cisco.com> Thread-Topic: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Thread-Index: AcWk7o1Lm9yjxqBSRfyE4EtDGVgGUAAAEB2g From: "Kent Leung \(kleung\)" To: "Joel M. Halpern" , , "Henrik Levkowetz" , "Margaret Wasserman" X-OriginalArrivalTime: 19 Aug 2005 19:12:46.0441 (UTC) FILETIME=[FB8E5590:01C5A4F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: Peter McCann , mip4@ietf.org, "Milind Kulkarni \(mkulkarn\)" , "Alpesh Patel \(alpesh\)" Subject: [Mip4] RE: LC review: draft-ietf-mip4-dynamic-assignment-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Joel. Comments below. =20 > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: Friday, August 19, 2005 11:46 AM > To: gen-art@alvestrand.no; Henrik Levkowetz; Margaret Wasserman > Cc: Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Kent=20 > Leung (kleung); Peter McCann; mip4@ietf.org > Subject: Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt >=20 > Gen_Art last call review of Mobile IPv4 Dynamic Home Agent Assignment > draft-ietf-mip4-dynamic-assignment-05.txt >=20 > The General Area Review Team (Gen_Art) serves as a review=20 > team for the IETF Chair. > We are asked to review documents being considered by the=20 > IESG, and where possible to provide reviews during or after=20 > IETF last call. > The Gen-Art reviewer is selected by a quasi-random process=20 > from the team. > I have been selected to review this document. >=20 > This is a re-review, following up on a review done of -03. >=20 > This draft is almost ready for publication as a Proposed=20 > Standard RFC. However, one item that had been noted earlier=20 > still leaves room for ambiguity about certain fields: >=20 > Sections 4.2 and 4.2.1 still do not identify what value is=20 > placed in the HA Address field of the second registration=20 > request, after the redirect has been received. Whatever=20 > behavior is intended (put the new HA address in the HA=20 > Address field, or continue to put ALL-ZERO-ONE-ADDR in the HA=20 > Address field to allow for further redirection, or either=20 > one) should be stated. This was in my earlier comments, and=20 > had been acknowledged as reasonable. =20 The HA address field is set to ALL-ZERO-ONE-ADDR to signify that MN is still registering in dynamic HA assignment mode. So step 5 of 4.2.1 is same as step 1 in the section. So proposed new text in 4.2.1: 5. If the MN can authenticate the Reply, the MN extracts the HA address from the Redirected HA Extension. The MN then sends a Registration Request to the Redirected HA, unless it has already received a redirection response from that HA while processing the Registration Request. The Home Agent address field in this Registration Request is set to ALL-ZERO-ONE-ADDR. The MN may choose to add Requested HA extension in this new Registration Request. >(Sections 5.1.1 and=20 > 5.1.2 note that the new HA address must be placed in the=20 > Requested HA Extensions, but that does not answer the=20 > question of what goes in the HA Address field of the packet.) >=20 See above. > Nits: > This document is using an out of date IPR clause. I=20 > don't know if it needs to be updated.=20 >=20 Hmm, this seems up to date. Pls provide some more details so we can fix this up. Thanks for the review. Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 19 16:25:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DQZ-0006LP-AC; Fri, 19 Aug 2005 16:25:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DQY-0006LK-3m for mip4@megatron.ietf.org; Fri, 19 Aug 2005 16:25:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03406 for ; Fri, 19 Aug 2005 16:25:19 -0400 (EDT) Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6E0X-0007Q7-91 for mip4@ietf.org; Fri, 19 Aug 2005 17:02:35 -0400 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id B857737EB5; Fri, 19 Aug 2005 22:24:56 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7776337E45; Fri, 19 Aug 2005 22:24:56 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8ACE937E44; Fri, 19 Aug 2005 22:24:55 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1E6DQ7-0003Rj-5M; Fri, 19 Aug 2005 22:24:55 +0200 Message-ID: <43064012.5020303@levkowetz.com> Date: Fri, 19 Aug 2005 22:24:50 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <2979E38DD6FC6544B789C8DAD7BAFC528610D7@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC528610D7@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Margaret Wasserman , Peter McCann , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , "Joel M. Halpern" , gen-art@alvestrand.no, "Milind Kulkarni \(mkulkarn\)" Subject: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1488147619==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1488147619== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC971A7D11B0D7D942140C952" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC971A7D11B0D7D942140C952 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >> Nits: >> This document is using an out of date IPR clause. I >> don't know if it needs to be updated. >> > > Hmm, this seems up to date. Pls provide some more details so we can fix > this up. Most of the errors which idnits report on this document is due to many boilerplate paragraphs being broken up by blank lines, which prevents recognition. Manual removal of these added blank lines reduces the idnits complaints to just one: (Expected a match on the following text: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."" ... but found this: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress".") This is caused by the final full stop being placed outside the quotes, instead of inside. Personally, I think this is just fine, but the current guidelines to handling boilerplate are very rigid and requires verbatim compliance, which means putting the full stop before the final double quote. Or take your chances. Whatever you do with this, I think fixing the extraneous blank lines in the middle of the boilerplate paragraphs would be good, though. Henrik --------------enigC971A7D11B0D7D942140C952 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFDBkAYeVhrtTJkXCMRAgwnAJ92rYY0W/ku/shE6IbucACOYte49wCg/PmT ywq0pSd9TBBr/CeTX+OWHqQ= =uplA -----END PGP SIGNATURE----- --------------enigC971A7D11B0D7D942140C952-- --===============1488147619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1488147619==-- From mip4-bounces@ietf.org Fri Aug 19 17:01:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DzO-00087B-Ol; Fri, 19 Aug 2005 17:01:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DzJ-00086b-PF for mip4@megatron.ietf.org; Fri, 19 Aug 2005 17:01:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04983 for ; Fri, 19 Aug 2005 17:01:15 -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.43) id 1E6EZJ-0008Mp-44 for mip4@ietf.org; Fri, 19 Aug 2005 17:38:31 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2005 14:01:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7JL0QQo002651; Fri, 19 Aug 2005 14:01:01 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 14:01:01 -0700 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, 19 Aug 2005 14:01:00 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52861133@xmb-sjc-235.amer.cisco.com> Thread-Topic: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Thread-Index: AcWk/EdEiOQyoiZ5Spex9HyBAmO7iAAAyhtA From: "Kent Leung \(kleung\)" To: "Henrik Levkowetz" X-OriginalArrivalTime: 19 Aug 2005 21:01:01.0981 (UTC) FILETIME=[1B3314D0:01C5A501] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: Margaret Wasserman , Peter McCann , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , "Joel M. Halpern" , gen-art@alvestrand.no, "Milind Kulkarni \(mkulkarn\)" Subject: [Mip4] RE: LC review: draft-ietf-mip4-dynamic-assignment-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Henrik. Thanks for clarifying the issue. > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Friday, August 19, 2005 1:25 PM > To: Kent Leung (kleung) > Cc: Joel M. Halpern; gen-art@alvestrand.no; Margaret=20 > Wasserman; Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh);=20 > Peter McCann; mip4@ietf.org > Subject: Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt >=20 >=20 > >> Nits: > >> This document is using an out of date IPR clause. I=20 > don't know=20 > >> if it needs to be updated. > >>=20 > >=20 > > Hmm, this seems up to date. Pls provide some more details=20 > so we can=20 > > fix this up. >=20 > Most of the errors which idnits report on this document is=20 > due to many boilerplate paragraphs being broken up by blank=20 > lines, which prevents recognition. Manual removal of these=20 > added blank lines reduces the idnits complaints to just one: >=20 > (Expected a match on the following text: > "Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by=20 > other documents > at any time. It is inappropriate to use Internet-Drafts=20 > as reference > material or to cite them other than as "work in progress."" > =20 > ... but found this: > "Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by=20 > other documents > at any time. It is inappropriate to use Internet Drafts=20 > as reference > material or to cite them other than as "work in progress".") >=20 > This is caused by the final full stop being placed outside=20 > the quotes, instead of inside. >=20 OK, will fix this. > Personally, I think this is just fine, but the current=20 > guidelines to handling boilerplate are very rigid and=20 > requires verbatim compliance, which means putting the full=20 > stop before the final double quote. Or take your chances. >=20 > Whatever you do with this, I think fixing the extraneous=20 > blank lines in the middle of the boilerplate paragraphs would=20 > be good, though. >=20 I normally use xml which would avoid this problem. But this draft was created awhile back and source is word doc. Unless it's mandated to remove the blank lines (which we would have to go find them), I'll avoid such work that is not related to supplying good content. Let us know if the previous text is satisfactory? If everything looks good, then we'll submit a new draft version with the 2 changes. Thanks. Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 19 17:32:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ETe-0008PE-02; Fri, 19 Aug 2005 17:32:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ETc-0008Mz-9A for mip4@megatron.ietf.org; Fri, 19 Aug 2005 17:32:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06346 for ; Fri, 19 Aug 2005 17:32:33 -0400 (EDT) Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6F3d-0000p1-0X for mip4@ietf.org; Fri, 19 Aug 2005 18:09:50 -0400 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 487CC37EED; Fri, 19 Aug 2005 23:32:23 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 0E32437EB9; Fri, 19 Aug 2005 23:32:23 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 86CD437E43; Fri, 19 Aug 2005 23:32:19 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1E6ETL-0004Bg-Lx; Fri, 19 Aug 2005 23:32:19 +0200 Message-ID: <43064FE5.7020902@levkowetz.com> Date: Fri, 19 Aug 2005 23:32:21 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" References: <2979E38DD6FC6544B789C8DAD7BAFC52861133@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52861133@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Margaret Wasserman , Peter McCann , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , "Joel M. Halpern" , gen-art@alvestrand.no, "Milind Kulkarni \(mkulkarn\)" Subject: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1485540804==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1485540804== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3DAD22D17B3CDB4B1C875FC1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3DAD22D17B3CDB4B1C875FC1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 2005-08-19 23:01 Kent Leung (kleung) said the following: > Hi Henrik. Thanks for clarifying the issue. > You're welcome :-) [...] > I normally use xml which would avoid this problem. But this draft was > created awhile back and source is word doc. Unless it's mandated to > remove the blank lines (which we would have to go find them), I'll avoid > such work that is not related to supplying good content. > > Let us know if the previous text is satisfactory? If everything looks > good, then we'll submit a new draft version with the 2 changes. Thanks. I can understand not wanting to debug the process, however manually fixing the resulting .txt document doesn't take much time, and prevents other (possibly several other) people having to do it. So please fix up the document to avoid the broken paragraphs - I bet you can do it in only a minute or two... ,,:-) Henrik --------------enig3DAD22D17B3CDB4B1C875FC1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFDBk/leVhrtTJkXCMRAux5AJ4nBCPCV+ffbdo8eSovipgQs7CjPgCgyBJu BfS/CMe0ms+/w/ZoByDD3tM= =T6fk -----END PGP SIGNATURE----- --------------enig3DAD22D17B3CDB4B1C875FC1-- --===============1485540804== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1485540804==-- From mip4-bounces@ietf.org Fri Aug 19 18:03:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ExA-0000JN-9r; Fri, 19 Aug 2005 18:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Ex8-0000JE-G8 for mip4@megatron.ietf.org; Fri, 19 Aug 2005 18:03:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07651 for ; Fri, 19 Aug 2005 18:03:03 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6FXA-0001e5-Hh for mip4@ietf.org; Fri, 19 Aug 2005 18:40:20 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 Aug 2005 15:02:57 -0700 X-IronPort-AV: i="3.96,127,1122879600"; d="scan'208"; a="333993205:sNHT34304916" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7JM2n0L028621; Fri, 19 Aug 2005 15:02:51 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 15:02:50 -0700 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, 19 Aug 2005 15:02:48 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5286117D@xmb-sjc-235.amer.cisco.com> Thread-Topic: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Thread-Index: AcWlBTDl35g91/tRSuS5Y+O1hUpLAAABDsMQ From: "Kent Leung \(kleung\)" To: "Joel M. Halpern" , , "Henrik Levkowetz" , "Margaret Wasserman" X-OriginalArrivalTime: 19 Aug 2005 22:02:50.0105 (UTC) FILETIME=[BD69E690:01C5A509] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: Peter McCann , mip4@ietf.org, "Milind Kulkarni \(mkulkarn\)" , "Alpesh Patel \(alpesh\)" Subject: [Mip4] RE: LC review: draft-ietf-mip4-dynamic-assignment-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org OK, we'll submit rev 06 after fixing the identified issues. Thanks. Kent > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: Friday, August 19, 2005 2:30 PM > To: Kent Leung (kleung); gen-art@alvestrand.no; Henrik=20 > Levkowetz; Margaret Wasserman > Cc: Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Peter=20 > McCann; mip4@ietf.org > Subject: RE: LC review: draft-ietf-mip4-dynamic-assignment-05.txt >=20 > The proposed replacement for bullet 5 in 4.2.1 works for me. =20 > Thank you. >=20 > With regard to the IPR, Henrik's very nice IDnits checker reports: >=20 > Checking conformance with RFC 3978/3979 boilerplate... > * The document seems to lack an RFC 3978 Section 5.5 Disclaimer -- > however, there's a paragraph with a matching beginning.=20 > Boilerplate > error? > * The document seems to lack an RFC 3979 Section 5, para 1 IPR > Disclosure Acknowledgement -- however, there's a paragraph with a > matching beginning. Boilerplate error? > * The document seems to lack an RFC 3979 Section 5, para 2 IPR > Disclosure Acknowledgement -- however, there's a paragraph with a > matching beginning. Boilerplate error? >=20 > Yours, > Joel >=20 > PS: Thank you for the prompt reply. > At 03:12 PM 8/19/2005, Kent Leung \(kleung\) wrote: > > > Sections 4.2 and 4.2.1 still do not identify what value=20 > is placed in=20 > > > the HA Address field of the second registration request,=20 > after the=20 > > > redirect has been received. Whatever behavior is=20 > intended (put the=20 > > > new HA address in the HA Address field, or continue to put=20 > > > ALL-ZERO-ONE-ADDR in the HA Address field to allow for further=20 > > > redirection, or either > > > one) should be stated. This was in my earlier comments, and had=20 > > > been acknowledged as reasonable. > > > >The HA address field is set to ALL-ZERO-ONE-ADDR to signify=20 > that MN is=20 > >still registering in dynamic HA assignment mode. So step 5=20 > of 4.2.1 is=20 > >same as step 1 in the section. > > > >So proposed new text in 4.2.1: > > > >5. If the MN can authenticate the Reply, the MN extracts the HA=20 > >address from the Redirected HA Extension. The MN then sends a=20 > >Registration Request to the Redirected HA, unless it has already=20 > >received a redirection response from that HA while processing the=20 > >Registration Request. The Home Agent address field in this=20 > >Registration Request is set to ALL-ZERO-ONE-ADDR. The MN=20 > may choose to=20 > >add Requested HA extension in this new Registration Request. > > > > > > >(Sections 5.1.1 and > > > 5.1.2 note that the new HA address must be placed in the =20 > Requested=20 > > >HA Extensions, but that does not answer the question of=20 > what goes in=20 > > >the HA Address field of the packet.) > > > > > > >See above. > > > > > > > Nits: > > > This document is using an out of date IPR clause. I=20 > don't know=20 > > > if it needs to be updated. > > > > > > >Hmm, this seems up to date. Pls provide some more details so we can=20 > >fix this up. > > > >Thanks for the review. > > > >Kent >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Aug 20 16:42:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6aAd-0002En-IR; Sat, 20 Aug 2005 16:42:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ERT-0007nC-5N for mip4@megatron.ietf.org; Fri, 19 Aug 2005 17:30:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06224 for ; Fri, 19 Aug 2005 17:30:20 -0400 (EDT) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6F1T-0000lU-Qf for mip4@ietf.org; Fri, 19 Aug 2005 18:07:37 -0400 Received: from [162.83.73.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11940665; Fri, 19 Aug 2005 17:30:00 -0400 Message-Id: <6.2.1.2.0.20050819172749.02e66330@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 19 Aug 2005 17:29:33 -0400 To: "Kent Leung \(kleung\)" , , "Henrik Levkowetz" , "Margaret Wasserman" From: "Joel M. Halpern" In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC528610D7@xmb-sjc-235.amer.ci sco.com> References: <2979E38DD6FC6544B789C8DAD7BAFC528610D7@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Sat, 20 Aug 2005 16:42:26 -0400 Cc: Peter McCann , mip4@ietf.org, "Milind Kulkarni \(mkulkarn\)" , "Alpesh Patel \(alpesh\)" Subject: [Mip4] RE: LC review: draft-ietf-mip4-dynamic-assignment-05.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org The proposed replacement for bullet 5 in 4.2.1 works for me. Thank you. With regard to the IPR, Henrik's very nice IDnits checker reports: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.5 Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Yours, Joel PS: Thank you for the prompt reply. At 03:12 PM 8/19/2005, Kent Leung \(kleung\) wrote: > > Sections 4.2 and 4.2.1 still do not identify what value is > > placed in the HA Address field of the second registration > > request, after the redirect has been received. Whatever > > behavior is intended (put the new HA address in the HA > > Address field, or continue to put ALL-ZERO-ONE-ADDR in the HA > > Address field to allow for further redirection, or either > > one) should be stated. This was in my earlier comments, and > > had been acknowledged as reasonable. > >The HA address field is set to ALL-ZERO-ONE-ADDR to signify that MN is >still registering in dynamic HA assignment mode. So step 5 of 4.2.1 is >same as step 1 in the section. > >So proposed new text in 4.2.1: > >5. If the MN can authenticate the Reply, the MN extracts the HA address >from the Redirected HA Extension. The MN then sends a Registration >Request to the Redirected HA, unless it has already received a >redirection response from that HA while processing the Registration >Request. The Home Agent address field in this Registration Request is >set to ALL-ZERO-ONE-ADDR. The MN may choose to add Requested HA >extension in this new Registration Request. > > > >(Sections 5.1.1 and > > 5.1.2 note that the new HA address must be placed in the > > Requested HA Extensions, but that does not answer the > > question of what goes in the HA Address field of the packet.) > > > >See above. > > > > Nits: > > This document is using an out of date IPR clause. I > > don't know if it needs to be updated. > > > >Hmm, this seems up to date. Pls provide some more details so we can fix >this up. > >Thanks for the review. > >Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 22 04:13:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77OB-0007HD-Dc; Mon, 22 Aug 2005 04:10:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77OA-0007H3-Co for mip4@megatron.ietf.org; Mon, 22 Aug 2005 04:10:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29775 for ; Mon, 22 Aug 2005 04:10:36 -0400 (EDT) Received: from av12-1-sn2.hy.skanova.net ([81.228.8.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E77ye-0008FN-P9 for mip4@ietf.org; Mon, 22 Aug 2005 04:48:23 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 3B4F537FDA; Mon, 22 Aug 2005 10:10:10 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 9D82C37EBF for ; Mon, 22 Aug 2005 10:10:09 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8D8A737E51 for ; Mon, 22 Aug 2005 10:10:09 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1E77Nf-00067b-P6 for mip4@ietf.org; Mon, 22 Aug 2005 10:10:08 +0200 Content-Type: text/plain; charset=utf-8 To: mip4@ietf.org From: mehmet Date: Mon, 22 Aug 2005 08:10:07 +0000 MIME-Version: 1.0 Message-Id: <1124698207.71.0.409701747597.issue47@mip4.org> X-Roundup-Name: Mip4 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,BAYES_00, MIME_QP_LONG_LINE, USER_IN_WHITELIST, X_HELO_CHECK_FAILED autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Subject: [Mip4] [issue47] route optimization and private ip in mobile node problems X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip4 issue tracker List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org New submission from mehmet : Hi .I am Mehmet OZDEM from Turkey. Iam working Turk Telekom as electronical engineer and continues my educati= on=20 in MsC.My thesis is related mobile IP V4's problems.I have read many papers=20 from IEEE. I want to ask some questions about it. As far as I see; the big problem is Handover process in Mip4.Routing=20 optimization is good idea; but I think it suffers from binding because it=20 requires special hardware in mobile agents.Do you think that binding soluti= on=20 is bad? Another question is that ensapsulation is bad or goodmethod (for Home Agent= and=20 Foreign Agent communication) We can solve it using MPLS. And If we use private IP in mobile node, what are the drawbacks of this solution( According o paper written by=20 Toshihiko "Mobile IP Using Private IP" it is unable to route optimization) = Why? =20 If you interest my problems I'll be very happy Thanks,Best regards ---------- category: Technical draft: issue-tracker-deficiencies messages: 184 nosy: ozdemmehmet priority: May fix status: No discussion title: route optimization and private ip in mobile node problems _________________________________________________ Mip4 issue tracker _________________________________________________ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 22 05:22:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E78WB-0001Gy-AU; Mon, 22 Aug 2005 05:22:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E78W9-0001GU-RQ for mip4@megatron.ietf.org; Mon, 22 Aug 2005 05:22:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02525 for ; Mon, 22 Aug 2005 05:22:55 -0400 (EDT) Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E796g-0001or-Te for mip4@ietf.org; Mon, 22 Aug 2005 06:00:43 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 766C637F7D; Mon, 22 Aug 2005 11:20:17 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 4589D37F6B; Mon, 22 Aug 2005 11:20:17 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3980837E49; Mon, 22 Aug 2005 11:22:42 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1E78Vt-0005Zv-CS; Mon, 22 Aug 2005 11:22:41 +0200 Message-ID: <43099963.1050108@levkowetz.com> Date: Mon, 22 Aug 2005 11:22:43 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip4] draft-ietf-mip4-faerr-01.txt review References: <4301D270.9030808@piuha.net> In-Reply-To: <4301D270.9030808@piuha.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 2.1 (++) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: mip4@ietf.org, Charlie P X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1455553043==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1455553043== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig419975CE79777575E1EF6D54" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig419975CE79777575E1EF6D54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Jari, on 2005-08-16 13:48 Jari Arkko said the following: > Technical: > > Overall, this draft is short and seems to make a lot of > sense. I did have one technical question (which may > be just a lack of my own understanding), one suggested > addition to the security considerations section and a three > very minor editorial nits. > >> A mobile node that cannot correctly interpret the >> contents of the FA Error Extension MUST NOT use the care-of >> address provided in the Registration Reply message, until another >> Registration Request message has been sent and a successful >> Registration Reply message received. > > Hmm... I may be missing something here, but why would > the mobile node use the care-of address even if it did "correctly > interpret the contents of the FA error extensions"? Its an error, > so why continue...? Ah, but if the mobile node does not understand the new extension, it will only look at the result code returned int the regular result code field; and that result code (from the HA) may be ok. However, since this extension is non-skippable, a mobile node which complies with the base spec will discard the message (as it does not understand the extension). So a 3344 compliant MN will do the right thing; this text just underlines / explains this. I'd say this text is not strictly needed, or at least could be re-written, maybe as follows: "The FA Error extension is only valid for use within Mobile IPv4 Registration Reply messages. The FA Error Extension is not skippable. Accordingly, a mobile node that cannot correctly interpret the contents of the FA Error Extension must silently discard the message, according to Section 1.8 of RFC 3344 [2], and not use the care-of address it contains." >> 7. Security Considerations >> >> The extension in this document improves the security features >> of Mobile IPv4 by allowing the mobile node to be assured of the >> authenticity of the information supplied within a Registration >> Request. Previously, whenever the foreign agent was required to >> provide status information to the mobile node, it could only do so >> by destroying the ability of the mobile device to authenticated the >> Mobile-Home Authentication Extension data. > >> In many typical cases, the mobile node will not have a security >> association with the foreign agent that has sent the extension. >> Thus, the mobile node will be unable to ascertain that the foreign >> agent sending the extended Registration Reply message is the same >> foreign agent that earlier received the associated Registration >> Request from the mobile node. Because of this, a malicious foreign >> agent could cause a mobile node to operate as if the registration had >> failed, when in fact its home agent and a correctly operating foreign >> agent had both accepted the mobile node's Registration Request. In >> order to reduce the vulnerability to such maliciously transmitted >> Registration Reply messages with the unauthenticated extension, the >> mobile node MAY delay processing of such Registration Reply messages >> for a short while in order to determine whether another authentic >> Registration Reply might be received fromm the true foreign agent. > > > This is very good. However, we should probably say something > about bidding down attacks somewhere. Suggest adding the > following note to the end of Section 7: > > It should be noted that if the mobile node can not be certain > that it operates in a network that supports this extension, > malicious foreign agents might still be able to change the > status information. Where such vulnerability is unacceptable, > the mobile node can employ a policy where it refuses to > communicate with foreign agents that do not support this > extension. Mmm. In order for this to be enforceable, we would need to add a bit to the Router Advertisements of agents, announcing support. But this could also be spoofed, so we're back to zero. I don't see how this is enforceable without requiring use only of FAs with which the MN has a security association. > Editorial: > >> (see section 3) from the space of numbers for nonskippable mobility > > s/nonskippable/non-skippable/ > >> Future allocations from this number space require IETF >> consensus. > > Maybe s/IETF consensus/IETF Consensus [RFC 2434]/ > >> Registration Reply might be received fromm the true foreign agent. > > s/fromm/from/ Right to all. Henrik --------------enig419975CE79777575E1EF6D54 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFDCZljeVhrtTJkXCMRAoAOAJ9M4BomCPHBIB794Eb0jSVf50N4cACeIxxw zQzNedq55M1Q9ThjOg+PuYQ= =MeSD -----END PGP SIGNATURE----- --------------enig419975CE79777575E1EF6D54-- --===============1455553043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1455553043==-- From mip4-bounces@ietf.org Mon Aug 22 05:51:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E78xi-0005o9-EC; Mon, 22 Aug 2005 05:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E78xg-0005ny-Uv for mip4@megatron.ietf.org; Mon, 22 Aug 2005 05:51:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03600 for ; Mon, 22 Aug 2005 05:51:22 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E79YC-0002bk-Vr for mip4@ietf.org; Mon, 22 Aug 2005 06:29:10 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E393F89852; Mon, 22 Aug 2005 12:50:56 +0300 (EEST) Message-ID: <4309A00C.3000002@piuha.net> Date: Mon, 22 Aug 2005 12:51:08 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] draft-ietf-mip4-faerr-01.txt review References: <4301D270.9030808@piuha.net> <43099963.1050108@levkowetz.com> In-Reply-To: <43099963.1050108@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Charlie P X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Henrik, >>> A mobile node that cannot correctly interpret the >>> contents of the FA Error Extension MUST NOT use the care-of >>> address provided in the Registration Reply message, until another >>> Registration Request message has been sent and a successful >>> Registration Reply message received. >>> >>> >>Hmm... I may be missing something here, but why would >>the mobile node use the care-of address even if it did "correctly >>interpret the contents of the FA error extensions"? Its an error, >>so why continue...? >> >> > >Ah, but if the mobile node does not understand the new extension, it >will only look at the result code returned int the regular result >code field; and that result code (from the HA) may be ok. However, > > Yes. Success needs to be prevented somehow in this case. >since this extension is non-skippable, a mobile node which complies >with the base spec will discard the message (as it does not >understand the extension). So a 3344 compliant MN will do the right >thing; this text just underlines / explains this. I'd say this text > > Ok, I didn't realize this. >is not strictly needed, or at least could be re-written, maybe as >follows: > > "The FA Error extension is only valid for use within Mobile IPv4 > Registration Reply messages. The FA Error Extension is not > skippable. Accordingly, a mobile node that cannot correctly > interpret the contents of the FA Error Extension must silently > discard the message, according to Section 1.8 of RFC 3344 [2], > and not use the care-of address it contains." > > Much better, thanks. >>>7. Security Considerations >>> >>> The extension in this document improves the security features >>> of Mobile IPv4 by allowing the mobile node to be assured of the >>> authenticity of the information supplied within a Registration >>> Request. Previously, whenever the foreign agent was required to >>> provide status information to the mobile node, it could only do so >>> by destroying the ability of the mobile device to authenticated the >>> Mobile-Home Authentication Extension data. >>> >>> >>> In many typical cases, the mobile node will not have a security >>> association with the foreign agent that has sent the extension. >>> Thus, the mobile node will be unable to ascertain that the foreign >>> agent sending the extended Registration Reply message is the same >>> foreign agent that earlier received the associated Registration >>> Request from the mobile node. Because of this, a malicious foreign >>> agent could cause a mobile node to operate as if the registration had >>> failed, when in fact its home agent and a correctly operating foreign >>> agent had both accepted the mobile node's Registration Request. In >>> order to reduce the vulnerability to such maliciously transmitted >>> Registration Reply messages with the unauthenticated extension, the >>> mobile node MAY delay processing of such Registration Reply messages >>> for a short while in order to determine whether another authentic >>> Registration Reply might be received fromm the true foreign agent. >>> >>> >>This is very good. However, we should probably say something >>about bidding down attacks somewhere. Suggest adding the >>following note to the end of Section 7: >> >> It should be noted that if the mobile node can not be certain >> that it operates in a network that supports this extension, >> malicious foreign agents might still be able to change the >> status information. Where such vulnerability is unacceptable, >> the mobile node can employ a policy where it refuses to >> communicate with foreign agents that do not support this >> extension. >> >> > >Mmm. In order for this to be enforceable, we would need to add a >bit to the Router Advertisements of agents, announcing support. But >this could also be spoofed, so we're back to zero. I don't see how >this is enforceable without requiring use only of FAs with which the >MN has a security association. > > Agreed. But the question is if we need to enforce it. The first priority would be to document the vulnerability, if it exists. The second priority would be finding a possibility for some subset of mobile nodes to avoid this problem, if they wish to pay the price of not working with existing FAs. I didn't actually think about this in terms of a new bit. Is it possible to look at the status code value and if its in the range designated for errors given from the FA, and refuse to accept such an error if it doesn't come in the FA Error Extension? --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 22 06:32:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E79bJ-0004QL-20; Mon, 22 Aug 2005 06: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 1E79bH-0004Q2-W8 for mip4@megatron.ietf.org; Mon, 22 Aug 2005 06:32:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05699 for ; Mon, 22 Aug 2005 06:32:17 -0400 (EDT) Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ABo-0003t4-U4 for mip4@ietf.org; Mon, 22 Aug 2005 07:10:06 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 08F0637F1D; Mon, 22 Aug 2005 12:32:09 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A358D37E5D; Mon, 22 Aug 2005 12:32:08 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 912EE37E44; Mon, 22 Aug 2005 12:32:08 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1E79b5-0006Qk-O4; Mon, 22 Aug 2005 12:32:07 +0200 Message-ID: <4309A9A8.3030607@levkowetz.com> Date: Mon, 22 Aug 2005 12:32:08 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip4] draft-ietf-mip4-faerr-01.txt review References: <4301D270.9030808@piuha.net> <43099963.1050108@levkowetz.com> <4309A00C.3000002@piuha.net> In-Reply-To: <4309A00C.3000002@piuha.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mip4@ietf.org, Charlie P X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0677806161==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0677806161== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD56AC9B521EC9417A667982E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD56AC9B521EC9417A667982E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 2005-08-22 11:51 Jari Arkko said the following: [...] >>>This is very good. However, we should probably say something >>>about bidding down attacks somewhere. Suggest adding the >>>following note to the end of Section 7: >>> >>> It should be noted that if the mobile node can not be certain >>> that it operates in a network that supports this extension, >>> malicious foreign agents might still be able to change the >>> status information. Where such vulnerability is unacceptable, >>> the mobile node can employ a policy where it refuses to >>> communicate with foreign agents that do not support this >>> extension. >>> >>> >> >>Mmm. In order for this to be enforceable, we would need to add a >>bit to the Router Advertisements of agents, announcing support. But >>this could also be spoofed, so we're back to zero. I don't see how >>this is enforceable without requiring use only of FAs with which the >>MN has a security association. >> >> > Agreed. But the question is if we need to enforce > it. The first priority would be to document the > vulnerability, if it exists. Agreed. > The second priority would be finding a possibility > for some subset of mobile nodes to avoid this problem, > if they wish to pay the price of not working with > existing FAs. I didn't actually think about this in terms of a > new bit. Is it possible to look at the status code value > and if its in the range designated for errors given > from the FA, and refuse to accept such an error > if it doesn't come in the FA Error Extension? No, the FA would not in general use this FA Error Extension if it was the originator of an error messages; only in the case when it has to override a message from the HA would this be used. What you can say is that with this extension in place, the MN can choose to never accept a Registration Reply where the HA's message digest is broken. This means that any malicious FA has to generate a complete, false reply without HA auth. ext. present; but in that case, a later correct one could appear, as already described in the draft. However, this also brings us to the main point for which this extension was designed - for use with the revised MIPv4 challenge/response mechanism, which hopefully should be in good shape when this extension can be used. Checking for bidding-down usage in that context should be done, though - I don't think draft-ietf-mip4-rfc3012bis-04.txt mentions this. Henrik --------------enigD56AC9B521EC9417A667982E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFDCamoeVhrtTJkXCMRAjx+AKC4z5E7HoQtxVAQYAXmjSZZgwWvRwCgw5LL iEs09sEdmLaMMeIOCAygHcc= =/FD8 -----END PGP SIGNATURE----- --------------enigD56AC9B521EC9417A667982E-- --===============0677806161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0677806161==-- From mip4-bounces@ietf.org Mon Aug 22 10:32:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DLl-0004T8-Ot; Mon, 22 Aug 2005 10:32:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DLj-0004Sy-LW for mip4@megatron.ietf.org; Mon, 22 Aug 2005 10:32:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19482 for ; Mon, 22 Aug 2005 10:32:29 -0400 (EDT) Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7DwJ-0002iw-9M for mip4@ietf.org; Mon, 22 Aug 2005 11:10:20 -0400 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 92BC837E9C; Mon, 22 Aug 2005 16:32:16 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3477837F38; Mon, 22 Aug 2005 16:32:16 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 0B5F037E47; Mon, 22 Aug 2005 16:32:16 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1E7DLT-00068E-96; Mon, 22 Aug 2005 16:32:15 +0200 Message-ID: <4309E1F1.7010007@levkowetz.com> Date: Mon, 22 Aug 2005 16:32:17 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IPv4 Mailing List X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 2.1 (++) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: Pete McCann Subject: [Mip4] Meeting minutes from IETF-63 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0507227983==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0507227983== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB4BE9D3933E3A8BCEA69FAD5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB4BE9D3933E3A8BCEA69FAD5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Below is a first draft of the meeting minutes from IETF-63 in Paris. Please read and comment. (I seem to be able to find only the notes from George, but another kind person also took notes - I wonder if I have received these and mislaid them?) The minutes are also available in HTML format: http://www.mip4.org/ietf63/minutes.html Regards, Henrik ======================================================================== MIP4 WG Minutes (Monday, August 1, 2005, 1815-1945) ======================================================================== 1. Preliminaries: Chairs ------------------------------------------------------------------------ Minute takers: George Tsirtsis There were no comments on the agenda. 2. Document Status: Chairs ------------------------------------------------------------------------ +---------------------------------------------+-----------------------+ |draft |status | +=============================================+=======================+ |draft-ietf-mip4-rfc3344bis |New revision needed, | | |then publication req. | +---------------------------------------------+-----------------------+ |draft-ietf-mip4-rfc2006bis |Review needed. | +---------------------------------------------+-----------------------+ |draft-ietf-mip4-vpn-problem-solution |Review needed. | +---------------------------------------------+-----------------------+ |draft-ietf-mip4-rfc3012bis |Publication Requested | +---------------------------------------------+-----------------------+ |draft-ietf-mip4-faerr |Publication Requested | +---------------------------------------------+-----------------------+ |draft-ietf-mip4-dynamic-assignment |Waiting for AD Writeup | +---------------------------------------------+-----------------------+ |draft-ietf-mip4-reg-tunnel |AD Evaluation | | |Revised ID Needed | |Henrik: Charlie has produced new Appendix | | |text, but it needs review. | | |Hesham S. offered to do this review. | | +---------------------------------------------+-----------------------+ |draft-ietf-mobileip-lowlatency-handoffs-v4 |AD Evaluation | +---------------------------------------------+-----------------------+ |draft-ietf-mip4-vpn-problem-statement |RFC Ed Queue | +---------------------------------------------+-----------------------+ |draft-ietf-mip4-experimental-messages |RFC 4064 | +---------------------------------------------+-----------------------+ 3. Relevant BOFs: Chairs ------------------------------------------------------------------------ * NETLMM Monday 0900 - 1000 * MONAMI6 Friday 0900 - 1130 4. Proposed new charter: Chairs ------------------------------------------------------------------------ http://mip4.org/charter/mip4-charter-2005-07-13 A new charter proposal has been submitted. It's available at the URL given. However, if any new work items are proposed and accepted by the WG during this meeting, this will have to be updated. 5. Proposed new work-items: Chairs ------------------------------------------------------------------------ The following work items are part of the proposed charter update: * Radius Attributes * Generic Strings * FMIPv4 6. RADIUS attributes for Mobile-IP v4: Kent Leung ------------------------------------------------------------------------ draft-nakhjiri-radius-mip4-01.txt Slides: http://mip4.org/ietf63/mip4-radius.pdf No slides were received for this agenda item before the meeting, and Kent was not present in the room. Skipped here, but inserted as agenda item 12, below. 7. MIPv4 Extension for Configuration Options Exchange: Jayshree Bharatia ------------------------------------------------------------------------ draft-bharatia-mip4-gen-ext-00.txt Slides: http://mip4.org/ietf63/mip4-gen-ext.pdf This draft defines a Mobile IP extension for configuration options, which should be used by any Mobile IP entity to exchange information of the network entities like DNS server address, previous Foreign Agent (FA) address etc. Comments: Charlie: Is this for host configuration from the HA? Jayshree: 3GPP is using L2 mechanisms to carry info...would be nice to do it over MIP. But this is only one option. This can be used for other things. Kent: the L2 mechanisms probably provide local info anyway....we need home info too. 8. Discussion of mip4-gen-ext vs. mip4-host-config-vse: Chairs ------------------------------------------------------------------------ draft-bharatia-mip4-gen-ext-00.txt draft-leung-mip4-host-config-vse-00.txt Discussion: Henrik: Why not just carry the DHCP option format instead of redefining? Jayshree: Yes Someone: Options should be minimal, the rest should be done over DHCP Henrik: Should we adopt this or Kent's draft or merge them? Kent: The Kent draft was proposed 2 years ago with no success. 3GPP2 defined this with VSEs. Cisco also defined VSEs defined as informational. This new draft is good as a way forward for standards track doc. We should not eliminate existing implementations though so the info RFC should also progress. George: Kent's draft is in IESG hands and independent. This should go ahead by itself. Henrik: Should we take this on?. 6 say yes. 5 say they will work on it. 0 say it should not be taken on. It will be taken on. Conclusion: This will be proposed as a new work item in the updated charter. 9. Secure Connectivity using Mobile IPv4 and MOBIKE: Vijay Devarapalli ------------------------------------------------------------------------ draft-devarapalli-mip4-mobike-connectivity-00.txt Slides: http://mip4.org/ietf63/mip4-mobike-connectivity.pdf This draft presents an alternative to using dual-MIP (as described in draft-ietf-mip4-vpn-problem-solution-01) for combined MIPv4 and IPsec deployment, when the VPN gateway supports MOBIKE extensions. Comments: Someone: I like the idea. You are using the VPN only when external. OK in enterprise but maybe not always? Vijay: Some enterprises want you to use VPN all the time which is OK, this can be used in this case Kent: Question. Does this support FA mode when outside? From a network that has FAs? Vijay: No this mode is not supported Henrik: This and the double MIP solution solve the same problem in different ways, with no new protocols, just describe how to use existing tools. Kent: MOBIKE is between MN and HA...if there is an FA MOBIKE can not be used. Someone: This is not design for fast handoffs Vijay: Yes, you can probably combine it with fast handoff mechs Henrik: Realize that although MOBIKE provides mobility it is not designed for fast handoffs. Discussion: Both the dual MIP and MIP/MOBIKE solutions require cooperation between the two Mobility clients. Discussion: do we need both solutions? Henrik/Vijay say yes, Gopal says no. lets take it offline... Discussion continues for a little while more, but Gopal does not have the same viewpoint as others. Henrik: Should we adopt this? As part of the already described VPN problem statement? Or should we merge the two solution in one doc to fully describe the problem and solutions? Gopal: Lets not try the dualMIP solution for this. Vijay: I think dualMIP is stable. This new one is simple 10pg long. We do not need to merge. Lets make them consistent/clean-up. Henrik: OK, no merging. So should we adopt? 12-15 yes. 7 say they will work on it. OK it will be added. 0 say no. Hesham: We should no really have multiple solutions...although I do not have any problem with this particular solution. Henrik. I agree in general, but the two solutions are separate. Hesham: but what should the MN implement? Henrik: Yes the default should be addressed. Gopal: Why not do this in MOBIKE. We now going to have two solutions...back and forth with Henrik...take it offline. Conclusion: There is rough consensus in the working group for taking this on, with some dissent about describing 2 (complementary) solutions. This will be proposed as a new work item in the updated charter. 10. Mobile IPv4 Home Agent Switch Message: Hui Deng ------------------------------------------------------------------------ draft-jin-mip4-ha-switch-00.txt Slides: http://mip4.org/ietf63/mip4-ha-switch.pdf This document specifies a new MIP4 control message that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. Discussion: Applicability. Take down could be done by rejecting requests or use of redundant HA. Kent: Operationally it might be useful for various reasons like errors or change in billing etc. Henrik: Yes applicability is not defined enough. The general capability of notification message may be useful. Henrik: Should we take this specific draft on? 6 say yes, 2-3 say they will work on it. 1 says no Henrik: Should we take on the general idea? 20 say yes, 2-3 say they will work, 0 say no Henrik: OK we go with the general idea. Conclusion: A new draft is needed, describing a general notification message. The WG will consider adoption of such a draft when it is available. 11. Binding Identifier Extension for Mobile IPv4: Nobuo Ogashiwa ------------------------------------------------------------------------ draft-ogashiwa-mip4-bid-extension-00.txt Slides: http://mip4.org/ietf63/mip4-bid-extension.pdf This document specifies a new extension which carries a care-of address binding identifier, for the purpose of being able to couple tear-down and set-up of bindings when simultaneous bindings are used. Discussion: This is dealing with complex issues. Some think that it enables complicated things to happen but we do not have to get into all of that. Some think that it does not do anything without defining how you set up the routing tables Henrik: We tried to define how routing tables are set-up before but the WG and Chairs did not want to do this. You can also do this with a dereg followed by a reg. If not then you probably have other assumptions. Maybe we need to have a bof on multi-homed MIP4...this is too immature. Hesham: The chairs now are ok (after many year) to work on multi-homing and MIP4? >laughs< Henrik: yes :-) Henrik: Should we take this draft on? 0 say yes, 3 say no Henrik: Should either here or in a BOF or in MONAMI6 we should work on multi-homing on MIP4? 25 say yes, 0 say no. Will consult with Pete and IESG to figure out how to proceed. 12. RADIUS attributes for Mobile-IP v4: Kent Leung ------------------------------------------------------------------------ draft-nakhjiri-radius-mip4-01.txt Slides: http://mip4.org/ietf63/mip4-radius.pdf Kent gives a short update on the RADIUS attribute draft. No discussion. --------------enigB4BE9D3933E3A8BCEA69FAD5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFDCeHxeVhrtTJkXCMRAoylAJ9YuFn4Cb3kyG6fW22UFDn/hjTVVwCgu3PO oOtVTn4PYkKSrJ7sSVLnVoA= =DHLw -----END PGP SIGNATURE----- --------------enigB4BE9D3933E3A8BCEA69FAD5-- --===============0507227983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0507227983==-- From mip4-bounces@ietf.org Mon Aug 22 11:23:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E9R-0005y0-69; Mon, 22 Aug 2005 11:23:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E9O-0005xv-4M for mip4@megatron.ietf.org; Mon, 22 Aug 2005 11:23:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22578 for ; Mon, 22 Aug 2005 11:23:47 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Ejy-0004Lj-Ck for mip4@ietf.org; Mon, 22 Aug 2005 12:01:38 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EB50D89852; Mon, 22 Aug 2005 18:23:34 +0300 (EEST) Message-ID: <4309EE00.4030503@piuha.net> Date: Mon, 22 Aug 2005 18:23:44 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org, Vijay Devarapalli , Pasi Eronen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: Subject: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Pasi and Vijay, I finally found time to read this draft. Overall, I like it a lot. Some of its good properties include simplicity, minimal changes to both existing VPN plumbing and MIPv4 systems, and the separation between the two. I support taking this work forward. Technical: > 3. Solution Overview I started to wonder whether there's something here that would apply in similar manner to Mobile IPv6. There does not appear to be any specific dependency on Mobile IPv4 here. Doing the same for Mobile IPv6 appears to be possible, although doing VPN + IPsec-based home agent security would imply nested IPsec tunnels. Interestingly, with v6 RO you could eliminate the second (inner) tunnel in your solution. But perhaps that discussion falls under the scope of the v4-v6 interoperability scheme. In any case, I think it would be useful to think about this matter in order to ensure that we don't have too fragmented solutions (this works for v6 only; that you can do only if you also access a corporate VPN; it connects v4 and v6 but doesn't work if you combine it with VPNs; etc). > 3.4 Crossing Security Boundaries > > Security boundary detection is based on the reachability of the i-HA > from the mobile node's current point of attachment. I think it would be useful to recognize that there can be other sources of information. I like the fact that you have defined one mandated scheme here but its quite possible that there will e.g. L2 assist or configuration information in some cases; lets not rule that out. > 3.4.1 Operation when moving from an untrusted network Is there a need to talk about the specific SPD policy settings that are necessary to enable MIPv4 operations to be carried through a VPN tunnel? Or are we assuming (the most often used) all-or-nothing VPN model? > 3.4.2 Operation when moving from a trusted network Lets remember that MOBIKE has mechanisms not just for movements, but also for multihoming support and the ability to detect problems. I suppose there has to be some specification here about the interaction between problem detection mechanisms in MIPv4 and MOBIKE -- unless we are restricting this spec to situations where we get information from L2 that we have moved. > Appendix A. Mobility Extensions for IKEv1 I would rather not see this defined in this document. Personally, I'd favor recommending an upgrade to IKEv2, but if that's not sufficient then it would make sense to have a discussion elsewhere in the IETF (maybe in the MOBIKE WG or on the IPsec mailing list) about whether this is needed, and how it should be provided. Editorial: > typically, separated by a DMZ. Access to the intranet is controlled Expand DMZ on its first occurrence. > 1. Initiate IKE mobility exchange to update the current address with > the VPN gateway. If the new network is also untrusted, this will > be enough for setting up the connectivity. If the new network is > trusted, and if the VPN gateway is reachable, this exchange will > allow the mobile node to keep the VPN state alive while in the > trusted side. If the VPN gateway is not reachable from inside, > then this exchange will fail. > 2. At the same time as step 1, send a Mobile IPv4 Registration > Request to the internal Home Agent without VPN encapsulation. > 3. If the mobile node receives a Registration Response to the > request sent in step 2, then the current subnet is a trusted > subnet, and the mobile node can communicate without VPN > tunneling. The mobile node MAY tear down the VPN tunnel. Maybe renumber these "1a", "1b", and "2" for clarity (or something similar). Other occurrences later in the document, too. --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 22 13:18:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7FwE-0004xS-Nd; Mon, 22 Aug 2005 13:18:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7FwC-0004xG-5E for mip4@megatron.ietf.org; Mon, 22 Aug 2005 13:18:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29274 for ; Mon, 22 Aug 2005 13:18:17 -0400 (EDT) Received: from stinghorn.com ([194.251.121.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7GWm-00082e-QL for mip4@ietf.org; Mon, 22 Aug 2005 13:56:10 -0400 Received: from [172.20.100.26] ([::ffff:172.20.100.26]) by stinghorn.com with esmtp; Mon, 22 Aug 2005 20:17:57 +0300 id 00F3C003.430A08C5.0000120F Message-ID: <430A0992.6030900@iki.fi> Date: Mon, 22 Aug 2005 20:21:22 +0300 From: Sami Vaarala User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt References: <4309EE00.4030503@piuha.net> In-Reply-To: <4309EE00.4030503@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Vijay Devarapalli , mip4@ietf.org, Pasi Eronen X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Jari, > I finally found time to read this draft. Overall, I like it > a lot. Some of its good properties include simplicity, > minimal changes to both existing VPN plumbing and > MIPv4 systems, and the separation between the two. > I support taking this work forward. The problem I see w.r.t. to using IKEv2/MOBIKE is that it does not, alone, match the current problem statement. The assumption made in draft-ietf-mip4-vpn-problem-statement-03.txt is that existing deployed VPN infrastructure should be used (see e.g. Section 5.1). As far as I can see, this makes IKEv1 support mandatory, which is reflected in the current VPN solution draft (essentially the same mechanism, but uses an outer MIPv4 layer to compensate for lack of IPsec mobility support). If we drop the "deployed VPN" requirement, we're defining a new solution for the problem. Such a solution does not ease the perceived MIPv4 deployment issue of existing VPN infrastructure. I'm not sure the perception is correct, but it was included in the problem statement because several vendors thought it was relevant. If we decide that there is no deployment issue w.r.t. MIPv4 and already deployed VPNs, we should IMO take a larger view of improving MIPv4/VPN coexistence. Minimizing overlap between the two mechanisms would give a much better solution. For instance, there is room for improvement in MIPv4 packet overhead, MIPv4/VPN compression interactions, and integrated MIPv4/VPN packet authentication. As discussed in earlier e-mails, I believe that: 1. A solution document should address current VPN deployment. 2. There are multiple VPN technologies currentl in use. For instance, let's not forget L2TP/IPsec which probably accounts for a sizable chunk of deployments. 3. Because no new protocols are needed specifically for MIPv4/VPN coexistence, the most appropriate way of dealing with the solution space would be an applicability statement of existing protocols for the enterprise scenario. Best, -Sami -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 23 04:23:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7U4S-0001dz-52; Tue, 23 Aug 2005 04:23:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7U4R-0001dH-86 for mip4@megatron.ietf.org; Tue, 23 Aug 2005 04:23:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21001 for ; Tue, 23 Aug 2005 04:23:45 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7U4U-0004SJ-HZ for mip4@ietf.org; Tue, 23 Aug 2005 04:23:52 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 193AE89852; Tue, 23 Aug 2005 11:23:31 +0300 (EEST) Message-ID: <430ADD0E.2060108@piuha.net> Date: Tue, 23 Aug 2005 11:23:42 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie P , mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Cc: Subject: [Mip4] draft-ietf-mip4-rfc3012bis-04.txt review X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I understand that this draft is mainly a bug fix revision. It seems reasonable, overall. Some small technical issues/ questions, clarifications, and nits below, however: Technical: > 3.5 Mobile Node Processing for Registration Replies > > ... > > UNKNOWN_CHALLENGE: ... MUST use a new Challenge value in > any new registration, obtained either from an Agent Advertisement, or > from a Challenge extension to the Registration Reply containing the > error. > > MISSING_CHALLENGE: ... > SHOULD send a Challenge extension containing an unused challenge in > the next Registration Request. > > BAD_AUTHENTICATION: ... MUST use a new Challenge > value in any new registration, obtained either from an Agent > Advertisement, or from a Challenge extension to the Registration > Reply containing the error. > > FA_BAD_AAA_AUTH: ... MUST use a new Challenge value > in any new registration, obtained either from an Agent Advertisement, > or from a Challenge extension to the Registration Reply containing > the error. > > HA_BAD_AAA_AUTH: ... MUST use a new Challenge value > in any new registration, obtained either from an Agent Advertisement, > or from a Challenge extension to the Registration Reply containing > the error. > > STALE_CHALLENGE: ... MUST use a new Challenge value in > next Registration Request, obtained either from an Agent > Advertisement, or from a Challenge extension to the Registration > Reply containing the error. > > HA_WRONG_CHALLENGE: ... (no mention of the challenges)... The challenge rules are almost the same for all error cases, except the last one. I realize that the last one is a serious error, and there's little that the mobile node can do about it. However, the rules appear to imply that a new challenge value is required in all cases, except if you retry after HA_WRONG_CHALLENGE. Is there a reason for this? Presumably if you want to retry the registration just in case the system now works correctly, you would want to use a new, fresh Challenge. If there is no reason for this difference, I would suggest deleting some of the case-specific rules above and replacing them with generic text at the bottom of the section, saying something like: "In any case, if the mobile node attempts to register again after such an error, it MUST use a new Challenge value in such a registration, obtained either from an Agent Advertisement, or from a Challenge extension to the Registration Reply containing the error." (And even this may be unnecessary, given that there is also a requirement close to this in Section 4.) > 11. IANA Considerations > > All protocol values in this specification are to be the same as > defined in RFC 3012 [RFC3012]. Additionaly, new error codes > FA_BAD_AAA_AUTH, HA_BAD_AAA_AUTH, and HA_WRONG_CHALLENGE are defined > by this document. Among these, HA_WRONG_CHALLENGE may appear in the > Status code of the FA Error extension defined in [FAERR]. Are IANA considerations & rules needed for the Subtype field and SPI 0-255 range defined in Section 5? > The protocol messages for handling the authentication within the > verification infrastructure, and identity of the agent performing the > verification of the foreign agent challenge, are not specified in > this document, because those operations do not have to be performed > by any Mobile IP entity. I'm not sure I understand the part that begins "identity of the agent". Also, mobile IP entities appear to have to be involved, at least the FA is involved. Of course there can be other intermediate nodes such as AAA proxies or authentication servers that are not Mobile IP entities. The fact that you are not specifying the verification infrastructure becomes clear already earlier in Appendix B, so one way to deal with this paragraph is to remove it. > Preceding Mobile IP data || Type, Subtype, Length, SPI "Preceding Mobile IP data" is not explained. All bytes preceding the start of the option in question, presumably? But starting from the IP, UDP, or Mobile IP header or something else? Editorial: > defined in RFC 3012 [RFC3012]. Additionaly, new error codes s/additionaly/additionally/ > node has attempted to use. The following stylized programmatic > algorithm accomplishes this objective. The maximum amount of total Maybe s/stylized programmatic algorithm/pseudo-code algorithm/ > Appendix A. Change History Might be an idea to clean this up to a "What's New vs. RFC3012" section. Right now its hard to see if all the changes are true technical changes from 3012, editorial modifications, or just back-and-forth modifications between draft revisions. Other editorial issues: I spent quite a bit of time trying to understand all the "MUST precede" rules relating to the order of the options (Sect 3, Sect 6, etc). Its still hard to get an overview, and its also hard to convince yourself that the specification of these rules is complete and unambiguous. But I don't have a good suggestion for a better way to describe the rules. > Least-order 237 bytes from Challenge > ... > using MD5. Finally, the least significant 237 bytes of the challenge Would "last 237 bytes" be easier to understand? --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 23 10:35:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZsD-0003wb-Ml; Tue, 23 Aug 2005 10:35:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZsC-0003wR-Pu for mip4@megatron.ietf.org; Tue, 23 Aug 2005 10:35:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07993 for ; Tue, 23 Aug 2005 10:35:30 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ZsJ-0006Pw-Hg for mip4@ietf.org; Tue, 23 Aug 2005 10:35:40 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6C0668987B for ; Tue, 23 Aug 2005 17:35:14 +0300 (EEST) Message-ID: <430B342E.90809@piuha.net> Date: Tue, 23 Aug 2005 17:35:26 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Subject: [Mip4] review of draft-nakhjiri-radius-mip4-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I read this draft. In general, it seems very useful to document & standardize the aaa-side of the mobile ipv4 authentication protocols. (Would there be commitment from pp2 to take this?) I don't have a lot of comments, it seems pretty straightforward given the things that we've already defined in other specifications. I wish the Diameter - RADIUS translation was easier or even automatic, but I don't see other way around this given that RFC 4004 was already published. Some technical comments: Section 5 description of attributes that already exist was confusing. Suggest splitting section 5 to new attributes and instruction for the use of old attributes parts. Section 6 needs more details. Maybe ok for an -01, though. Presumably this draft is still structurally and key-wise the same as RFC 4004? If no, that would make the implementation of a RADIUS-Diameter gateway even harder. Some editorial nits: > The HA may reside in the mobile node=C6s home domain, in which case = HA=20 Non-ASCII char. In several places, applies to double quotes too. > [DIAMIP] P. Calhoun, C. Perkins, =E6=E6Diameter Mobile IP applicatio= n=C6=C6, > IETF work in progress, draft-ietf-aaa-diameter-mobileip-18.txt, May > 2004. RFC 4004 now. > MIP-answer (HMA). RADIUS currently does not any messages that=20 s/does not any/does not have any/ --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 23 14:08:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dCL-0004My-C7; Tue, 23 Aug 2005 14:08:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dCJ-0004Mq-MP for mip4@megatron.ietf.org; Tue, 23 Aug 2005 14:08:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19248 for ; Tue, 23 Aug 2005 14:08:30 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7dCS-0004mo-Q3 for mip4@ietf.org; Tue, 23 Aug 2005 14:08:42 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2005 11:08:22 -0700 X-IronPort-AV: i="3.96,135,1122879600"; d="scan'208"; a="207009512:sNHT789475474" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7NI8BZ3006861; Tue, 23 Aug 2005 11:08:14 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 11:08:16 -0700 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: [Mip4] review of draft-nakhjiri-radius-mip4-01.txt Date: Tue, 23 Aug 2005 11:08:16 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC528C6B3B@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review of draft-nakhjiri-radius-mip4-01.txt Thread-Index: AcWn8F38o4ZJb7AQTB6Dt7XJ5HMneAAHNQcA From: "Kent Leung \(kleung\)" To: "Jari Arkko" , X-OriginalArrivalTime: 23 Aug 2005 18:08:17.0215 (UTC) FILETIME=[A2F84CF0:01C5A80D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Jari.=20 > I read this draft. In general, it seems very useful to=20 > document & standardize the aaa-side of the mobile ipv4=20 > authentication protocols. (Would there be commitment from pp2=20 > to take this?) >=20 This draft is not specific to 3GPP2. In fact, many non-3GPP2 Mobile IP deployments today use Cisco vendor specific attributes due to lack of standardized AVPs. So it has general applicability. Definitely 3GPP2 can leverage these new AVPs in the next revision for reference if they like to. Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 23 15:49:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7elt-0003Wk-9A; Tue, 23 Aug 2005 15:49:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7elr-0003Wf-Fa for mip4@megatron.ietf.org; Tue, 23 Aug 2005 15:49:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26790 for ; Tue, 23 Aug 2005 15:49:17 -0400 (EDT) Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7em1-00083h-FA for mip4@ietf.org; Tue, 23 Aug 2005 15:49:30 -0400 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: [Mip4] review of draft-nakhjiri-radius-mip4-01.txt Date: Tue, 23 Aug 2005 15:49:06 -0400 Message-ID: Thread-Topic: [Mip4] review of draft-nakhjiri-radius-mip4-01.txt Thread-Index: AcWn8F38o4ZJb7AQTB6Dt7XJ5HMneAAHNQcAAAOe7hA= From: "Avi Lior" To: "Kent Leung \(kleung\)" , "Jari Arkko" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org FYI: We are considering this for WiMAX.=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Kent Leung (kleung) > Sent: Tuesday, August 23, 2005 2:08 PM > To: Jari Arkko; mip4@ietf.org > Subject: RE: [Mip4] review of draft-nakhjiri-radius-mip4-01.txt >=20 > Hi Jari.=20 >=20 > > I read this draft. In general, it seems very useful to document &=20 > > standardize the aaa-side of the mobile ipv4 authentication=20 > protocols.=20 > > (Would there be commitment from pp2 to take this?) > >=20 >=20 > This draft is not specific to 3GPP2. In fact, many non-3GPP2=20 > Mobile IP deployments today use Cisco vendor specific=20 > attributes due to lack of standardized AVPs. So it has=20 > general applicability. Definitely 3GPP2 can leverage these=20 > new AVPs in the next revision for reference if they like to. >=20 > Kent >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 24 11:32:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xFG-0001TZ-Na; Wed, 24 Aug 2005 11:32:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7gtr-0002Je-Os for mip4@megatron.ietf.org; Tue, 23 Aug 2005 18:05:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14772 for ; Tue, 23 Aug 2005 18:05:41 -0400 (EDT) Received: from markov.ece.neu.edu ([129.10.60.83] helo=SMTP1.ECE.NEU.EDU) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7gu3-0007mJ-QK for mip4@ietf.org; Tue, 23 Aug 2005 18:05:56 -0400 Received: from calvin.ece.neu.edu (calvin.ece.neu.edu [129.10.62.61]) by SMTP1.ECE.NEU.EDU (8.12.5/8.12.5) with SMTP id j7NM5gXM004824 for ; Tue, 23 Aug 2005 18:05:42 -0400 (EDT) Received: from ECE.NEU.EDU ([129.10.60.216]) by calvin.ece.neu.edu (SAVSMTP 3.1.0.29) with SMTP id M2005082318054228783 for ; Tue, 23 Aug 2005 18:05:42 -0400 Received: from localhost (basagni@localhost) by ECE.NEU.EDU (8.12.8/8.12.5/Submit) with ESMTP id j7NM5fN5025598 for ; Tue, 23 Aug 2005 18:05:41 -0400 Date: Tue, 23 Aug 2005 18:05:41 -0400 (EDT) From: Stefano Basagni To: mip4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by SMTP1.ECE.NEU.EDU id j7NM5gXM004824 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 24 Aug 2005 11:32:53 -0400 Subject: [Mip4] IEEE WiMEsh 2005, Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (Multiple apologies for multiple copies of this call.) ----------------------------------------------------------- CALL FOR PARTICIPATION ----------------------------------------------------------- WiMesh 2005 First IEEE Workshop on Wireless Mesh Networks Held in conjunction with IEEE SECON 2005 =20 Santa Clara, CA September 26th (Monday), 2005 ------------------------------------------------------------ Web site: http://www.cs.ucdavis.edu/~prasant/wimesh ------------------------------------------------------------ Recently, there has been a growing research and practical interest on wireless mesh networks. Academia, large industrial research labs, and start-up companies have ongoing projects related to various aspects of mesh networks. All these efforts and experimental studies are geared towards real applications in home networks, enterprise networks, and community networks that we already see today, and more can be envisioned in near future. To create a venue for leading experts in this field to meet and discuss theory, practice, experience, vision, and research issues on this timely subject, we are organizing the First IEEE Communication Society's Workshop on Wireless Mesh Networks (WiMesh 2005) in conjunction with IEEE SECON 2005. ------------------------------------------------------------ Workshop Chairs: Sung-Ju Lee HP Labs=20 (sjlee(AT)hpl.hp.com) Prasant Mohapatra University of California, Davis=20 (prasant(AT)cs.ucdavis.edu) ------------------------------------------------------------ REGISTRATION You can register on-line, or by fax/mail.=20 Please visit http://inrg.cse.ucsc.edu/secon05/home.html ------------------------------------------------------------ Tentative Program: * High Throughput Multimedia Broadcast in Multi-Rate Wireless Meshes Chun Tung Chou (University of New South Wales)=20 Archan Misra (IBM Watson Research) * Architecture of a Layer-2 Radio-Aware Mesh Network W. Steven Conner (Intel Research) Bahar Sadeghi (Intel Research) Lily Yang (Intel Research) Anand Rangarajan (Intel Research) * Mesh Networking Protocols to Exploit Physical Layer Capabilities Pradeep Kyasanur (University of Illinois) Xue Yang (University of Illinois) Nitin H. Vaidya (University of Illinois) * Optimizing Multicast Load in Mesh Networks using Dual-Association Dongwook Lee (Ohio State University) Gayathri Chandrasekaran (Ohio State University) Prasun Sinha (Ohio State University) * Exploiting Partially Overlapped Channels in Wireless Meshes Arunesh Mishra (University of Maryland)=20 Eric Rozner (University of Wisconsin) Suman Banerjee (University of Wisconsin) William Arbaugh (University of Maryland) * Multipath Routing in Heterogeneous Wireless Networks=20 Marc Mosko (UC Santa Cruz)=20 J.J. Garcia-Luna-Aceves (UC Santa Cruz and PARC) * A Channel Management Scheme for Improving Throughput in Multi-Channel Mesh Networks Thyaga Nandagopal (Bell Labs) Murali Kodialam (Bell Labs) * Power-Bandwidth Tradeoff in Multi-Antenna Interference Relay Networks Ozgur Oyman (Stanford University) Arogyaswami J. Paulraj (Stanford University) * On the Design of High Performance Multi-radio Infrastructure Mesh Netwo= rks Krishna Ramachandran (UC Santa Barbara) Milind M. Buddhikot (Bell Labs) Girish Chandranmenon (Bell Labs) Scott Miller (Bell Labs) * Capacity Scaling with Multi-radio Mesh Sumit Roy (University of Washington) Hamed Al Azemi (University of Washington) Arindam Das (University of Washington)=20 Hui Ma (University of Washington) Eman Alotaibi (University of Washington) * A Fair Scheduling for Mesh Networks=20 Naouel Ben Salem (EPFL) Jean-Pierre Hubaux (EPFL) * On the Impact of Beamforming on Mutual Interference and MAC Layer Desig= n Robert Vilzmann (Technische Universit=E4t M=FCnchen) Christian Bettstetter (NTT DoCoMo Euro Labs) Christian Hartmann (Technische Universit=E4t M=FCnchen) * Designing Routing Metrics for Mesh Networks=20 Yaling Yang (University of Illinois) Jun Wang (University of Illinois) Robin Kravets (University of Illinois) * ROMER: Resilient Opportunistic Mesh Routing for Wireless Mesh Networks Yuan Yuan (University of Maryland)=20 Hao Yang (UCLA) Songwu Lu (UCLA) William Arbaugh (University of Maryland) -- Stefano Basagni, Ph.D. Assistant Professor of Computer Engineering Dept. of Electrical and Computer Engineering 312 Dana Research Center Northeastern University 360 Huntington Ave. Boston, MA 02115 Tel. 617 373 3061, Fax 617 373 8970 E-mail: basagni@ece.neu.edu *** http://www.ece.neu.edu/faculty/basagni/ *** -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 25 11:58:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8K7I-0005Ol-MD; Thu, 25 Aug 2005 11:58:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8K7H-0005O1-8Q for mip4@megatron.ietf.org; Thu, 25 Aug 2005 11:58:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25933 for ; Thu, 25 Aug 2005 11:58:08 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8K7p-0007fe-Bn for mip4@ietf.org; Thu, 25 Aug 2005 11:58:45 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j7PFvpHC024903; Thu, 25 Aug 2005 10:57:52 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j7PFvp909431; Thu, 25 Aug 2005 10:57:51 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17165.60030.694164.997530@gargle.gargle.HOWL> Date: Thu, 25 Aug 2005 10:57:50 -0500 From: Pete McCann To: "Ahmad Muhanna" Subject: RE: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437109FD205E@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437109FD205E@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , Margaret Wasserman , "Kent Leung \(kleung\)" , Mohamed Khalil , "Milind Kulkarni \(mkulkarn\)" , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, [back on the mailing list now] This thread concerns the possibility of having more than one HA create a binding for a given MN. It seems true that the RRQ created by the MN, if delivered to multiple HAs, could potentially create state on each of those HAs. However, I think we are making too much out of the possibility. An attacker that has the power to duplicate packets (changing the destination IP address) and drop selected packets can pretty much prevent a mobile IP registration from taking place. Rather, I think we should focus on the correctness of the protocol in the absence of attackers: there is a requirement for a unicast destination address on the packet so only one HA will receive it in a normal protocol run. I do not think we need to add special mechanisms like the infinite/short lifetime that is being proposed or the requirement for an FA-HA MSA. I think these requirements would unfairly limit the deployment possibilities. It seems to me that it should suffice to put in some text in the security considerations about this issue. We might also consider adding text that says if the MN gets RRPs from more than one HA it must immediately de-register the extra unwanted bindings. -Pete Ahmad Muhanna writes: > Aplesh, > > Comments inline. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Alpesh Patel (alpesh) [mailto:alpesh@cisco.com] > > Sent: Wednesday, August 24, 2005 8:44 PM > > To: Henrik Levkowetz; Muhanna, Ahmad [RICH2:2Q30:EXCH] > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung); > > Milind Kulkarni (mkulkarn); Joel M. Halpern; Khalil, Mohamed > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh) > > Subject: RE: [Mip4] Re: LC review: > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > Henrik: > > > > In regards to Ahmad's original comment, we have one suggestion: > > > > If the rogue node changes the destination address enroute to > > the HA and sends the RRQ to multiple HA's, the most that can > > go wrong is multiple HA's creating a binding for the MN. > > > [Ahmad] > I believe that is a big deal. It means that multiple resources will be > allocated for the same MN, including IP address which is very precious > in MIPv4. It also could have impact on billing at the HA. > > > The rogue has to first figure out all the HA's addresses - > > this may not be trivial. > > [Ahmad] > Well, I do not want to debate this but the fact it is possible then it > is an issue. > > > > > Also, a good MN implementation will deregister when it > > receives multiple Registration Replies (if the rogue > > succeeded in doing its trick). So, there is not a problem here. > > [Ahmad] > Where is that documented? Can you please give a reference to this. > > > > > Also, the rogue cannot mount a "store and replay" attack - > > this window of vulnerability is limited only within the > > replay window - otherwise the HA's will reject the > > Reigstration Replies anyway. > > [Ahmad] > I agree that this attack is limited to the replay window. However, it is > very simple and can happen. > > > > > How about adding text to the following effect: > > > > When requesting dynamic HA assignment, MN SHOULD not set the > > lifetime field to infinity (0xffff). If lifetime requested is > > infinite, HA MUST set it to a low value and send a > > Registration Reply. (This will mitigate the risk of lingering > > binding entries at HA's - in case the Registration Reply from > > other HAs' are lost). > > [Ahmad] > Let us assume that the MN ends up registering at multiple HA's. As per > the RFC3543 "Registration Revocation", we need a security association > between the FA and the HA in order to revoke this false binding. On the > other hand, we do not have the same requirement for establishing the > binding to start with. Does that make sense?. > > > > > Subsequent registration requests with the HA where MN is > > anchored can have default behavior. > > > > So, if the rogue is succesful in mounting this type of > > attack, it will be short lived (limited to lifetime). > > [Ahmad] > Basically you agree to publish a standard with a security vulnerability > as long as it is short lived? > I understand that there is a limited audience on this thread, but I > guess some carriers may not like that limitation. > > Also, > > this attack will be successful only if the Reply from the > > HAs' do not reach the MN. > > [Ahmad] > I disagree, same comment as above. Is that documented anywhere?. > > Finally, I have no issue to publish the draft (as is) as long as you > document the security vulnerability as per your statement below. > " So, if the rogue is succesful in mounting this type of attack, it will > be short lived (limited to lifetime)" > > Another alternative: we can add this under section 5.2 Foreign Agent > Considerations: > During the registration process, if the foreign agent wishes to > participate in dynamic home agent allocation process with the home > domain, > it MUST have an existing security association with the home agent > that has been identified to serve the registration request. > > > > Comments/Suggestions? > > Alpesh > > > > > -----Original Message----- > > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > Sent: Saturday, August 20, 2005 6:42 PM > > > To: Ahmad Muhanna > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung); > > > Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Joel M. > > > Halpern; Mohamed Khalil > > > Subject: Re: [Mip4] Re: LC review: > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Hi Ahmad, > > > > > > Comments below. Milind, Alpesh, Kent - would you check > > > this, please? > > > > > > > > > On 2005-08-20 23:23 Ahmad Muhanna said the following: > > > > Hi Pete/Henrick, > > > > > > > > > > > > As chairs for the Mip4 working group, I would like to get your > > > > feedback on the security issue identified in my posting dated > > > > 6/22/205. email attached. In that posting I identified a security > > > > issue which could cause a MN to register with multiple > > HAs. No one > > > > apparently showed interest in this issue including the authors. > > > > However, I believe that the group needs to conclude if it > > > is an issue > > > > or not before this draft becomes a standard. > > > > > > > > This email is not posted to the mip4 list. > > > > > > > > Please let me know what you think of this. > > > > Thanks! > > > > > > > > > > [snip copy of later mail from Joel Halpern] > > > > > > > Hello all, > > > > > > > > My apologies in advance if this issue has been discussed > > before. If > > > > that is true, can someone let me know of the conclusion. Thanks! > > > > > > > > As per section 5.3.1 Assigned Home Agent Considerations, > > I find the > > > > following paragraph: > > > > " > > > > As per the messaging proposed here, the mobile node (or > > the foreign > > > > agent) sends the Registration Request to the Requested HA > > address, > > > > which is a unicast address. Therefore, this document does > > > not specify > > > > any new behavior for the case where the HA receives a > > > subnet directed > > > > broadcast Registration Request as specified in section > > > 3.8.2.1 of the > > > > Mobile IPv4 specification [1]. Although the Home Agent > > field in the > > > > Registration Request is not a unicast address, the destination IP > > > > address is a unicast address. This avoids the problem > > > associated with > > > > subnet-directed broadcast destination IP address that may > > result in > > > > multiple HAs responding. Thus, there is no need to deny the > > > > registration as stated in Mobile IPv4 [1] section 3.8.3.2." > > > > > > > > My question here is how by setting the destination IP > > > address of the > > > > IP packet to the HA unicast IP address guarantee that MN > > will avoid > > > > the possibility of being registered with multiple HAs? > > > > > > > > What I have in mind here, is the possibility of someone > > > listening on > > > > that link and all what is needed is to include the RRQ in > > > an IP packet > > > > with the destination IP address is set to a different HA. In other > > > > words, any HA receives this RRQ can process this RRQ and send a > > > > confirmation reply to the MN and MN ends up registering > > > with multiple > > > > HAs.? > > > > > > This would be the case when an MN registers directly with a > > > HA, with a co-located care-of address, and does not include > > > the requested HA extension. > > > > > > I believe you are right that there is a possibility of a bad > > > guy causing a registration with more than one HA in this > > > case. This would result in the MN receiving registration > > > replies from multiple HAs, if more than one HA would decide > > > to accept the registration. > > > > > > The solution could be to specify that the inclusion of a > > > Requested HA extension would be a MUST in all cases, with the > > > HA being required to verify that the HA address in the > > > Requested HA extension matches its own address. > > > > > > > > > Henrik > > > -----BEGIN PGP SIGNATURE----- > > > > > > iD8DBQFDB9vjeVhrtTJkXCMRAhxDAKCAVB5dw98q6fNcHe/r7qmbLd9vJQCg4oLd > > > 9k8rjzf6t7VTAI/L1rLu8cg= > > > =Wo9C > > > -----END PGP SIGNATURE----- > > > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 25 16:43:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OZC-0006ac-Bu; Thu, 25 Aug 2005 16:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OZA-0006aW-Hq for mip4@megatron.ietf.org; Thu, 25 Aug 2005 16:43:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17843 for ; Thu, 25 Aug 2005 16:43:14 -0400 (EDT) Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8OZk-0001e7-0U for mip4@ietf.org; Thu, 25 Aug 2005 16:43:53 -0400 Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id CAA5B38177; Thu, 25 Aug 2005 22:42:54 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id BD75437F26; Thu, 25 Aug 2005 22:42:54 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 23DDD37E42; Thu, 25 Aug 2005 22:42:52 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1E8OYm-00011e-0L; Thu, 25 Aug 2005 22:42:52 +0200 Message-ID: <430E2D4F.9050004@levkowetz.com> Date: Thu, 25 Aug 2005 22:42:55 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt References: <6FC4416DDE56C44DA0AEE67BC7CA437109FD205E@zrc2hxm2.corp.nortel.com> <17165.60030.694164.997530@gargle.gargle.HOWL> In-Reply-To: <17165.60030.694164.997530@gargle.gargle.HOWL> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , Margaret Wasserman , "Kent Leung \(kleung\)" , Mohamed Khalil , "Milind Kulkarni \(mkulkarn\)" , Ahmad Muhanna X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 2005-08-25 17:57 Pete McCann said the following: > Hi, > > [back on the mailing list now] > > This thread concerns the possibility of having more than one HA create > a binding for a given MN. It seems true that the RRQ created by the > MN, if delivered to multiple HAs, could potentially create state on > each of those HAs. However, I think we are making too much out of the > possibility. An attacker that has the power to duplicate packets > (changing the destination IP address) and drop selected packets can > pretty much prevent a mobile IP registration from taking place. > > Rather, I think we should focus on the correctness of the protocol in > the absence of attackers: there is a requirement for a unicast > destination address on the packet so only one HA will receive it in a > normal protocol run. I do not think we need to add special mechanisms > like the infinite/short lifetime that is being proposed or the > requirement for an FA-HA MSA. I think these requirements would > unfairly limit the deployment possibilities. > > It seems to me that it should suffice to put in some text in the > security considerations about this issue. We might also consider > adding text that says if the MN gets RRPs from more than one HA it > must immediately de-register the extra unwanted bindings. Certainly makes sense to me. Henrik -----BEGIN PGP SIGNATURE----- iD8DBQFDDi1PeVhrtTJkXCMRAkBBAJ9rT4hqF55GQUxlMf754v1oSl/XZwCg/GEZ sAihRiL7iMbMjnV093Wojp4= =67Z/ -----END PGP SIGNATURE----- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 25 19:51:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RVd-0008Cc-FR; Thu, 25 Aug 2005 19:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RVc-0008CX-RC for mip4@megatron.ietf.org; Thu, 25 Aug 2005 19:51:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29147 for ; Thu, 25 Aug 2005 19:51:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8RWE-00076w-O4 for mip4@ietf.org; Thu, 25 Aug 2005 19:52:27 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7PNJHa11930; Thu, 25 Aug 2005 16:19:17 -0700 X-mProtect: <200508252319> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14192.americas.nokia.com (172.18.141.92, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdP01Zwh; Thu, 25 Aug 2005 16:19:15 PDT Message-ID: <430E5979.90506@iprg.nokia.com> Date: Thu, 25 Aug 2005 16:51:21 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko References: <4309EE00.4030503@piuha.net> In-Reply-To: <4309EE00.4030503@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Pasi Eronen Subject: [Mip4] Re: review of draft-devarapalli-mip4-mobike-connectivity-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org hi Jari, thanks for the review. Jari Arkko wrote: > Hi Pasi and Vijay, > > I finally found time to read this draft. Overall, I like it > a lot. Some of its good properties include simplicity, > minimal changes to both existing VPN plumbing and > MIPv4 systems, and the separation between the two. > I support taking this work forward. thanks. > > Technical: > >> 3. Solution Overview > > > I started to wonder whether there's something here > that would apply in similar manner to Mobile IPv6. There > does not appear to be any specific dependency on Mobile > IPv4 here. yes its possible. infact in 3GPP2-WLAN IW, this is already being considered. a MIPv6 tunnel with a HA through an IPsec tunnel with the PDIF. I thought about writing up a draft for MIPv6 too, but nobody is asking for it right now. :) also for MIPv6, it might make sense to collapse the VPN gateway and the HA into the same box. > Doing the same for Mobile IPv6 appears to > be possible, although doing VPN + IPsec-based > home agent security would imply nested IPsec tunnels. > Interestingly, with v6 RO you could eliminate the > second (inner) tunnel in your solution. yup. > But perhaps that discussion falls under the scope of > the v4-v6 interoperability scheme. > > In any case, I think it would be useful to think about > this matter in order to ensure that we don't have > too fragmented solutions (this works for v6 only; > that you can do only if you also access a corporate > VPN; it connects v4 and v6 but doesn't work if you > combine it with VPNs; etc). I didnt understand the above. ?? > >> 3.4 Crossing Security Boundaries >> >> Security boundary detection is based on the reachability of the i-HA >> from the mobile node's current point of attachment. > > > I think it would be useful to recognize that there > can be other sources of information. I like the fact > that you have defined one mandated scheme here > but its quite possible that there will e.g. L2 assist > or configuration information in some cases; lets > not rule that out. very true. we hint about this in the draft. There could also be some out-of-band mechanisms that involve configuring the wireless access points with some information which the mobile node can recognize as access points that belong to the trusted network in an enterprise network. Such mechanisms are beyond the scope of this document. >> 3.4.1 Operation when moving from an untrusted network > > > Is there a need to talk about the specific SPD policy > settings that are necessary to enable MIPv4 > operations to be carried through a VPN tunnel? > > Or are we assuming (the most often used) > all-or-nothing VPN model? I prefer the MIPv4 signaling messages and the IP-in-IP packets appearing to the IPsec tunnel as ordinary traffic. if the all-or-nothing VPN model is not used (very rare), then we need to add selectors so that the MIPv4 signaling messages and IP-in-IP packets are not discarded. > >> 3.4.2 Operation when moving from a trusted network > > > Lets remember that MOBIKE has mechanisms not > just for movements, but also for multihoming support > and the ability to detect problems. I suppose there > has to be some specification here about the > interaction between problem detection mechanisms > in MIPv4 and MOBIKE -- unless we are restricting > this spec to situations where we get information > from L2 that we have moved. I think this is implementation specific. the mobile node could get information from multiple sources, MOBIKE, MIPv4, L2, 802.21, etc... the host implementation on the mobile node should decide what to do with the information from all these sources. we shouldnt venture into specifying how they can work together. what do you think? > >> Appendix A. Mobility Extensions for IKEv1 > > > I would rather not see this defined in this document. > Personally, I'd favor recommending an upgrade to IKEv2, > but if that's not sufficient then it would make sense to > have a discussion elsewhere in the IETF (maybe in the > MOBIKE WG or on the IPsec mailing list) about whether > this is needed, and how it should be provided. okay. > > Editorial: > >> typically, separated by a DMZ. Access to the intranet is controlled > > > Expand DMZ on its first occurrence. > >> 1. Initiate IKE mobility exchange to update the current address with >> the VPN gateway. If the new network is also untrusted, this will >> be enough for setting up the connectivity. If the new network is >> trusted, and if the VPN gateway is reachable, this exchange will >> allow the mobile node to keep the VPN state alive while in the >> trusted side. If the VPN gateway is not reachable from inside, >> then this exchange will fail. >> 2. At the same time as step 1, send a Mobile IPv4 Registration >> Request to the internal Home Agent without VPN encapsulation. >> 3. If the mobile node receives a Registration Response to the >> request sent in step 2, then the current subnet is a trusted >> subnet, and the mobile node can communicate without VPN >> tunneling. The mobile node MAY tear down the VPN tunnel. > > > Maybe renumber these "1a", "1b", and "2" for clarity (or something > similar). Other occurrences later in the document, too. okay. Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 26 06:40:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8bdh-0005T6-2w; Fri, 26 Aug 2005 06:40:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8bdd-0005T0-EX for mip4@megatron.ietf.org; Fri, 26 Aug 2005 06:40:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10106 for ; Fri, 26 Aug 2005 06:40:42 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8beJ-0000tH-7E for mip4@ietf.org; Fri, 26 Aug 2005 06:41:29 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7QAdeK01721; Fri, 26 Aug 2005 06:39:40 -0400 (EDT) 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: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Date: Fri, 26 Aug 2005 05:39:38 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710A04E5F3@zrc2hxm2.corp.nortel.com> Thread-Topic: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Thread-Index: AcWpjeX75MyayVeLRAGT6FAIjrDtcQAkt0qQ From: "Ahmad Muhanna" To: "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , Margaret Wasserman , "Kent Leung \(kleung\)" , Mohamed Khalil , "Milind Kulkarni \(mkulkarn\)" , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Thanks Pete for bringing the discussion to the mailing list. Please see comments inline. Regards, Ahmad >=20 > Hi, >=20 > [back on the mailing list now] >=20 > This thread concerns the possibility of having more than one=20 > HA create a binding for a given MN. It seems true that the=20 > RRQ created by the MN, if delivered to multiple HAs, could=20 > potentially create state on each of those HAs.=20 =20 [Ahmad] Since you agree that this attack is valid and possible and if this attack is successful with a single MN, then it is possible for almost every MN requesting Dynamic HA on the compromised FA-HA link. That could be devastating to the HA domain. I hope you agree. > However, I=20 > think we are making too much out of the possibility. An=20 > attacker that has the power to duplicate packets (changing=20 > the destination IP address) and drop selected packets [Ahmad] If we think along this line, we probably do not need any security measures in MIPv4 protocol to start with. On the other hand, why RFC (3543) mandates the FA to have a security association with the HA to participate in registration revocation? > can=20 > pretty much prevent a mobile IP registration from taking place. [Ahmad] Of course, that is true. That is why we need to make sure that we have a secure solution (protocol) to prevent such attacks. >=20 > Rather, I think we should focus on the correctness of the=20 > protocol in the absence of attackers:=20 [Ahmad] Is that a MIPv4 WG mandate or just your opinion? > there is a requirement=20 > for a unicast destination address on the packet so only one=20 > HA will receive it in a normal protocol run. =20 [Ahmad] Thinking of normal protocol run; If all what we are looking for is just normal protocol run, then why do we have all of these security associations and extensions in all of the RFCs related to MIPv4 protocol. > I do not think=20 > we need to add special mechanisms like the infinite/short=20 > lifetime that is being proposed or the requirement for an=20 > FA-HA MSA. I think these requirements would unfairly limit=20 > the deployment possibilities. [Ahmad] I respectfully disagree. If such attack happens, service providers may not be able to serve their own legitimate customers. It will cost them a lot of money. >=20 > It seems to me that it should suffice to put in some text in=20 > the security considerations about this issue. =20 [Ahmad] If we clearly highlight the security issue and this mailing list has a consensus, I have no problem at all. > We might also=20 > consider adding text that says if the MN gets RRPs from more=20 > than one HA it must immediately de-register the extra=20 > unwanted bindings. [Ahmad] Could you please explain to me how this is possible in a case when FA is present in the call path. Thanks. >=20 > -Pete >=20 >=20 > Ahmad Muhanna writes: > > Aplesh, > >=20 > > Comments inline. > >=20 > > Regards, > > Ahmad > >=20 > >=20 > > > -----Original Message----- > > > From: Alpesh Patel (alpesh) [mailto:alpesh@cisco.com]=20 > > > Sent: Wednesday, August 24, 2005 8:44 PM > > > To: Henrik Levkowetz; Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung);=20 > > > Milind Kulkarni (mkulkarn); Joel M. Halpern; Khalil, Mohamed=20 > > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh) > > > Subject: RE: [Mip4] Re: LC review:=20 > > > draft-ietf-mip4-dynamic-assignment-05.txt > > >=20 > > >=20 > > > Henrik: > > >=20 > > > In regards to Ahmad's original comment, we have one=20 > suggestion: > >=20 > > > If the rogue node changes the destination address enroute to=20 > > > the HA and sends the RRQ to multiple HA's, the most that can=20 > > > go wrong is multiple HA's creating a binding for the MN. > > >=20 > > [Ahmad] > > I believe that is a big deal. It means that multiple=20 > resources will be > allocated for the same MN, including IP=20 > address which is very precious > in MIPv4. It also could=20 > have impact on billing at the HA. >=20 > > > The rogue has to first figure out all the HA's addresses -=20 > > > this may not be trivial. > >=20 > > [Ahmad] > > Well, I do not want to debate this but the fact it is=20 > possible then it > is an issue. >=20 > > >=20 > > > Also, a good MN implementation will deregister when it=20 > > > receives multiple Registration Replies (if the rogue=20 > > > succeeded in doing its trick). So, there is not a=20 > problem here. >=20 > > [Ahmad] > > Where is that documented? Can you please give a reference to this.=20 > >=20 > > >=20 > > > Also, the rogue cannot mount a "store and replay" attack -=20 > > > this window of vulnerability is limited only within the=20 > > > replay window - otherwise the HA's will reject the=20 > > > Reigstration Replies anyway. > >=20 > > [Ahmad] > > I agree that this attack is limited to the replay window.=20 > However, it is > very simple and can happen. >=20 > > >=20 > > > How about adding text to the following effect: > > >=20 > > > When requesting dynamic HA assignment, MN SHOULD not set the=20 > > > lifetime field to infinity (0xffff). If lifetime requested is=20 > > > infinite, HA MUST set it to a low value and send a=20 > > > Registration Reply. (This will mitigate the risk of lingering=20 > > > binding entries at HA's - in case the Registration Reply from=20 > > > other HAs' are lost). > >=20 > > [Ahmad] > > Let us assume that the MN ends up registering at multiple=20 > HA's. As per > the RFC3543 "Registration Revocation", we=20 > need a security association > between the FA and the HA in=20 > order to revoke this false binding. On the > other hand, we=20 > do not have the same requirement for establishing the >=20 > binding to start with. Does that make sense?. >=20 > > >=20 > > > Subsequent registration requests with the HA where MN is=20 > > > anchored can have default behavior. > > >=20 > > > So, if the rogue is succesful in mounting this type of=20 > > > attack, it will be short lived (limited to lifetime). > > =20 > > [Ahmad] > > Basically you agree to publish a standard with a security=20 > vulnerability > as long as it is short lived? > I=20 > understand that there is a limited audience on this thread,=20 > but I > guess some carriers may not like that limitation. >=20 > > Also,=20 > > > this attack will be successful only if the Reply from the=20 > > > HAs' do not reach the MN.=20 > >=20 > > [Ahmad] > > I disagree, same comment as above. Is that documented=20 > anywhere?. >=20 > > Finally, I have no issue to publish the draft (as is) as=20 > long as you > document the security vulnerability as per=20 > your statement below. > " So, if the rogue is succesful in=20 > mounting this type of attack, it will > be short lived=20 > (limited to lifetime)" >=20 > > Another alternative: we can add this under section 5.2=20 > Foreign Agent > Considerations:=20 > > During the registration process, if the foreign agent wishes to > > participate in dynamic home agent allocation process=20 > with the home > > domain,=20 > > it MUST have an existing security association with the=20 > home agent=20 > > that has been identified to serve the registration request. > > >=20 > > > Comments/Suggestions? > > > Alpesh=20 > > >=20 > > > > -----Original Message----- > > > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > > Sent: Saturday, August 20, 2005 6:42 PM > > > > To: Ahmad Muhanna > > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung);=20 > > > > Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Joel M.=20 > > > > Halpern; Mohamed Khalil > > > > Subject: Re: [Mip4] Re: LC review:=20 > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > >=20 > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > >=20 > > > > Hi Ahmad, > > > >=20 > > > > Comments below. Milind, Alpesh, Kent - would you check > > > > this, please? > > > >=20 > > > >=20 > > > > On 2005-08-20 23:23 Ahmad Muhanna said the following: > > > > > Hi Pete/Henrick, > > > > >=20 > > > > >=20 > > > > > As chairs for the Mip4 working group, I would like=20 > to get your > > > > feedback on the security issue=20 > identified in my posting dated=20 > > > > > 6/22/205. email attached. In that posting I=20 > identified a security=20 > > > > > issue which could cause a MN to register with multiple=20 > > > HAs. No one=20 > > > > > apparently showed interest in this issue including=20 > the authors.=20 > > > > > However, I believe that the group needs to conclude if it=20 > > > > is an issue > > > > > or not before this draft becomes a standard. > > > > >=20 > > > > > This email is not posted to the mip4 list. > > > > >=20 > > > > > Please let me know what you think of this. > > > > > Thanks! > > > > >=20 > > > >=20 > > > > [snip copy of later mail from Joel Halpern] > > > >=20 > > > > > Hello all, > > > > >=20 > > > > > My apologies in advance if this issue has been discussed=20 > > > before. If > > > > > that is true, can someone let me know of the=20 > conclusion. Thanks! > > > >=20 > > > > > As per section 5.3.1 Assigned Home Agent Considerations,=20 > > > I find the > > > > > following paragraph: > > > > > " > > > > > As per the messaging proposed here, the mobile node (or=20 > > > the foreign > > > > > agent) sends the Registration Request to the Requested HA=20 > > > address,=20 > > > > > which is a unicast address. Therefore, this document does=20 > > > > not specify > > > > > any new behavior for the case where the HA receives=20 > a > > > subnet directed > > > > broadcast Registration=20 > Request as specified in section > > > 3.8.2.1 of the > > >=20 > > Mobile IPv4 specification [1]. Although the Home Agent=20 > > > field in the > > > > > Registration Request is not a unicast address, the=20 > destination IP=20 > > > > > address is a unicast address. This avoids the problem=20 > > > > associated with > > > > > subnet-directed broadcast destination IP address that may=20 > > > result in > > > > > multiple HAs responding. Thus, there is no need to deny the=20 > > > > > registration as stated in Mobile IPv4 [1] section=20 > 3.8.3.2." > > > >=20 > > > > > My question here is how by setting the destination=20 > IP > > > address of the > > > > IP packet to the HA unicast=20 > IP address guarantee that MN=20 > > > will avoid > > > > > the possibility of being registered with multiple=20 > HAs? > > > >=20 > > > > > What I have in mind here, is the possibility of=20 > someone > > > listening on > > > > that link and all what=20 > is needed is to include the RRQ in > > > an IP packet > > >=20 > > with the destination IP address is set to a different HA.=20 > In other > > > > words, any HA receives this RRQ can process=20 > this RRQ and send a=20 > > > > > confirmation reply to the MN and MN ends up registering=20 > > > > with multiple > > > > > HAs.? > > > >=20 > > > > This would be the case when an MN registers directly=20 > with a > > > HA, with a co-located care-of address, and does=20 > not include=20 > > > > the requested HA extension. > > > >=20 > > > > I believe you are right that there is a possibility of=20 > a bad > > > guy causing a registration with more than one HA in this=20 > > > > case. This would result in the MN receiving registration=20 > > > > replies from multiple HAs, if more than one HA would decide=20 > > > > to accept the registration. > > > >=20 > > > > The solution could be to specify that the inclusion of=20 > a > > > Requested HA extension would be a MUST in all cases,=20 > with the=20 > > > > HA being required to verify that the HA address in the=20 > > > > Requested HA extension matches its own address. > > > >=20 > > > >=20 > > > > Henrik > > > > -----BEGIN PGP SIGNATURE----- > > > >=20 > > > >=20 > iD8DBQFDB9vjeVhrtTJkXCMRAhxDAKCAVB5dw98q6fNcHe/r7qmbLd9vJQCg4oLd > > > > 9k8rjzf6t7VTAI/L1rLu8cg=3D > > > > =3DWo9C > > > > -----END PGP SIGNATURE----- > > > >=20 > > >=20 > > >=20 >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 26 11:04:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8flF-0008SH-I0; Fri, 26 Aug 2005 11:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fl9-0008Rf-7H for mip4@megatron.ietf.org; Fri, 26 Aug 2005 11:04:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25314 for ; Fri, 26 Aug 2005 11:04:45 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fls-0001C8-AT for mip4@ietf.org; Fri, 26 Aug 2005 11:05:33 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j7QF3wXm013856; Fri, 26 Aug 2005 10:03:59 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j7QF1Ba12982; Fri, 26 Aug 2005 10:01:12 -0500 (CDT) Message-ID: <17167.11960.59164.262305@gargle.gargle.HOWL> Date: Fri, 26 Aug 2005 10:01:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: "Ahmad Muhanna" Subject: RE: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710A04E5F3@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710A04E5F3@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , "Joel M. Halpern" , "Kent Leung \(kleung\)" , Henrik Levkowetz , "Milind Kulkarni \(mkulkarn\)" , Mohamed Khalil X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, Ahmad, See below. Ahmad Muhanna writes: > Thanks Pete for bringing the discussion to the mailing list. > Please see comments inline. > > Regards, > Ahmad > > > > > Hi, > > > > [back on the mailing list now] > > > > This thread concerns the possibility of having more than one > > HA create a binding for a given MN. It seems true that the > > RRQ created by the MN, if delivered to multiple HAs, could > > potentially create state on each of those HAs. > > [Ahmad] > Since you agree that this attack is valid and possible and if this > attack is successful with a single MN, then it is possible for almost > every MN requesting Dynamic HA on the compromised FA-HA link. That could > be devastating to the HA domain. I hope you agree. I wouldn't use the word "devastating." If the HAs are on different subnets, it creates some extra state that has no effect on the overall operation of the system and which will timeout after the first Lifetime. If the HAs are on the same subnet, however, it will create a competition for the gratuitous/proxy ARP which would have an effect on the reliability of the traffic, so I can see your point of view here. > > However, I > > think we are making too much out of the possibility. An > > attacker that has the power to duplicate packets (changing > > the destination IP address) and drop selected packets > > [Ahmad] > If we think along this line, we probably do not need any security > measures in MIPv4 protocol to start with. On the other hand, why RFC > (3543) mandates the FA to have a security association with the HA to > participate in registration revocation? I am not saying we don't need security, just that we need to consider the big picture. If you think about the most likely deployment scenarios for this draft, there will be a single AAA server that is responsible for allocating a home agent address and for distributing security associations. Inserting requests into a secure AAA infrastructure is a lot harder than inserting a duplicate (destination address modified) packet. Even if the Registration Request is sent directly to an HA, it will most likely be protected by an MN-AAA authentication extension, and the central AAA server can prevent duplicate sessions. > > can > > pretty much prevent a mobile IP registration from taking place. > > [Ahmad] > Of course, that is true. That is why we need to make sure that we have a > secure solution (protocol) to prevent such attacks. > > > > > Rather, I think we should focus on the correctness of the > > protocol in the absence of attackers: > > [Ahmad] > Is that a MIPv4 WG mandate or just your opinion? Sorry, chair hat off for now. > > there is a requirement > > for a unicast destination address on the packet so only one > > HA will receive it in a normal protocol run. > > [Ahmad] > Thinking of normal protocol run; If all what we are looking for is just > normal protocol run, then why do we have all of these security > associations and extensions in all of the RFCs related to MIPv4 > protocol. > > > I do not think > > we need to add special mechanisms like the infinite/short > > lifetime that is being proposed or the requirement for an > > FA-HA MSA. I think these requirements would unfairly limit > > the deployment possibilities. > > [Ahmad] > I respectfully disagree. If such attack happens, service providers may > not be able to serve their own legitimate customers. It will cost them a > lot of money. > > > > > It seems to me that it should suffice to put in some text in > > the security considerations about this issue. > > [Ahmad] > If we clearly highlight the security issue and this mailing list has a > consensus, I have no problem at all. > > > > We might also > > consider adding text that says if the MN gets RRPs from more > > than one HA it must immediately de-register the extra > > unwanted bindings. > > [Ahmad] > Could you please explain to me how this is possible in a case when FA is > present in the call path. Thanks. You are right I think - the FA would drop the extra RRPs because it would be looking for a response from the unicast HA to which it sent the message. Of course, if the RRQ was sent to the AAA infrastructure ala RFC 4004, then there is no issue. Perhaps what we need is a note in the security considerations that mentions the possibility of multiple HAs on the same subnet getting the registration request and independently authenticating it. This will be possible in some deployments and impossible (e.g., centralized AAA server validating MN-AAA auth extension) in others. If it is possible, then maybe we need to return a successful binding with Lifetime=0 which will indicate to the MN that it needs to immediately re-register with the assigned HA. -Pete > > -Pete > > > > > > Ahmad Muhanna writes: > > > Aplesh, > > > > > > Comments inline. > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Alpesh Patel (alpesh) [mailto:alpesh@cisco.com] > > > > Sent: Wednesday, August 24, 2005 8:44 PM > > > > To: Henrik Levkowetz; Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung); > > > > Milind Kulkarni (mkulkarn); Joel M. Halpern; Khalil, Mohamed > > > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh) > > > > Subject: RE: [Mip4] Re: LC review: > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > > > > > > > Henrik: > > > > > > > > In regards to Ahmad's original comment, we have one > > suggestion: > > > > > > If the rogue node changes the destination address enroute to > > > > the HA and sends the RRQ to multiple HA's, the most that can > > > > go wrong is multiple HA's creating a binding for the MN. > > > > > > > [Ahmad] > > > I believe that is a big deal. It means that multiple > > resources will be > allocated for the same MN, including IP > > address which is very precious > in MIPv4. It also could > > have impact on billing at the HA. > > > > > The rogue has to first figure out all the HA's addresses - > > > > this may not be trivial. > > > > > > [Ahmad] > > > Well, I do not want to debate this but the fact it is > > possible then it > is an issue. > > > > > > > > > Also, a good MN implementation will deregister when it > > > > receives multiple Registration Replies (if the rogue > > > > succeeded in doing its trick). So, there is not a > > problem here. > > > > [Ahmad] > > > Where is that documented? Can you please give a reference to this. > > > > > > > > > > > Also, the rogue cannot mount a "store and replay" attack - > > > > this window of vulnerability is limited only within the > > > > replay window - otherwise the HA's will reject the > > > > Reigstration Replies anyway. > > > > > > [Ahmad] > > > I agree that this attack is limited to the replay window. > > However, it is > very simple and can happen. > > > > > > > > > How about adding text to the following effect: > > > > > > > > When requesting dynamic HA assignment, MN SHOULD not set the > > > > lifetime field to infinity (0xffff). If lifetime requested is > > > > infinite, HA MUST set it to a low value and send a > > > > Registration Reply. (This will mitigate the risk of lingering > > > > binding entries at HA's - in case the Registration Reply from > > > > other HAs' are lost). > > > > > > [Ahmad] > > > Let us assume that the MN ends up registering at multiple > > HA's. As per > the RFC3543 "Registration Revocation", we > > need a security association > between the FA and the HA in > > order to revoke this false binding. On the > other hand, we > > do not have the same requirement for establishing the > > > binding to start with. Does that make sense?. > > > > > > > > > Subsequent registration requests with the HA where MN is > > > > anchored can have default behavior. > > > > > > > > So, if the rogue is succesful in mounting this type of > > > > attack, it will be short lived (limited to lifetime). > > > > > > [Ahmad] > > > Basically you agree to publish a standard with a security > > vulnerability > as long as it is short lived? > I > > understand that there is a limited audience on this thread, > > but I > guess some carriers may not like that limitation. > > > > Also, > > > > this attack will be successful only if the Reply from the > > > > HAs' do not reach the MN. > > > > > > [Ahmad] > > > I disagree, same comment as above. Is that documented > > anywhere?. > > > > Finally, I have no issue to publish the draft (as is) as > > long as you > document the security vulnerability as per > > your statement below. > " So, if the rogue is succesful in > > mounting this type of attack, it will > be short lived > > (limited to lifetime)" > > > > Another alternative: we can add this under section 5.2 > > Foreign Agent > Considerations: > > > During the registration process, if the foreign agent wishes to > > > participate in dynamic home agent allocation process > > with the home > > > domain, > > > it MUST have an existing security association with the > > home agent > > > that has been identified to serve the registration request. > > > > > > > > Comments/Suggestions? > > > > Alpesh > > > > > > > > > -----Original Message----- > > > > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > > > Sent: Saturday, August 20, 2005 6:42 PM > > > > > To: Ahmad Muhanna > > > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung); > > > > > Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Joel M. > > > > > Halpern; Mohamed Khalil > > > > > Subject: Re: [Mip4] Re: LC review: > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA1 > > > > > > > > > > Hi Ahmad, > > > > > > > > > > Comments below. Milind, Alpesh, Kent - would you check > > > > > this, please? > > > > > > > > > > > > > > > On 2005-08-20 23:23 Ahmad Muhanna said the following: > > > > > > Hi Pete/Henrick, > > > > > > > > > > > > > > > > > > As chairs for the Mip4 working group, I would like > > to get your > > > > feedback on the security issue > > identified in my posting dated > > > > > > 6/22/205. email attached. In that posting I > > identified a security > > > > > > issue which could cause a MN to register with multiple > > > > HAs. No one > > > > > > apparently showed interest in this issue including > > the authors. > > > > > > However, I believe that the group needs to conclude if it > > > > > is an issue > > > > > > or not before this draft becomes a standard. > > > > > > > > > > > > This email is not posted to the mip4 list. > > > > > > > > > > > > Please let me know what you think of this. > > > > > > Thanks! > > > > > > > > > > > > > > > > [snip copy of later mail from Joel Halpern] > > > > > > > > > > > Hello all, > > > > > > > > > > > > My apologies in advance if this issue has been discussed > > > > before. If > > > > > > that is true, can someone let me know of the > > conclusion. Thanks! > > > > > > > > > > As per section 5.3.1 Assigned Home Agent Considerations, > > > > I find the > > > > > > following paragraph: > > > > > > " > > > > > > As per the messaging proposed here, the mobile node (or > > > > the foreign > > > > > > agent) sends the Registration Request to the Requested HA > > > > address, > > > > > > which is a unicast address. Therefore, this document does > > > > > not specify > > > > > > any new behavior for the case where the HA receives > > a > > > subnet directed > > > > broadcast Registration > > Request as specified in section > > > 3.8.2.1 of the > > > > > > Mobile IPv4 specification [1]. Although the Home Agent > > > > field in the > > > > > > Registration Request is not a unicast address, the > > destination IP > > > > > > address is a unicast address. This avoids the problem > > > > > associated with > > > > > > subnet-directed broadcast destination IP address that may > > > > result in > > > > > > multiple HAs responding. Thus, there is no need to deny the > > > > > > registration as stated in Mobile IPv4 [1] section > > 3.8.3.2." > > > > > > > > > > My question here is how by setting the destination > > IP > > > address of the > > > > IP packet to the HA unicast > > IP address guarantee that MN > > > > will avoid > > > > > > the possibility of being registered with multiple > > HAs? > > > > > > > > > > What I have in mind here, is the possibility of > > someone > > > listening on > > > > that link and all what > > is needed is to include the RRQ in > > > an IP packet > > > > > > with the destination IP address is set to a different HA. > > In other > > > > words, any HA receives this RRQ can process > > this RRQ and send a > > > > > > confirmation reply to the MN and MN ends up registering > > > > > with multiple > > > > > > HAs.? > > > > > > > > > > This would be the case when an MN registers directly > > with a > > > HA, with a co-located care-of address, and does > > not include > > > > > the requested HA extension. > > > > > > > > > > I believe you are right that there is a possibility of > > a bad > > > guy causing a registration with more than one HA in this > > > > > case. This would result in the MN receiving registration > > > > > replies from multiple HAs, if more than one HA would decide > > > > > to accept the registration. > > > > > > > > > > The solution could be to specify that the inclusion of > > a > > > Requested HA extension would be a MUST in all cases, > > with the > > > > > HA being required to verify that the HA address in the > > > > > Requested HA extension matches its own address. > > > > > > > > > > > > > > > Henrik > > > > > -----BEGIN PGP SIGNATURE----- > > > > > > > > > > > > iD8DBQFDB9vjeVhrtTJkXCMRAhxDAKCAVB5dw98q6fNcHe/r7qmbLd9vJQCg4oLd > > > > > 9k8rjzf6t7VTAI/L1rLu8cg= > > > > > =Wo9C > > > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > > > > > > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 26 18:14:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8mRd-00008X-HS; Fri, 26 Aug 2005 18:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8mRb-00008A-06; Fri, 26 Aug 2005 18:13:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25792; Fri, 26 Aug 2005 18:12:59 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8mSN-0000z6-D2; Fri, 26 Aug 2005 18:13:52 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j7QMCDh02732; Fri, 26 Aug 2005 15:12:13 -0700 (PDT) Message-Id: <200508262212.j7QMCDh02732@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 26 Aug 2005 15:12:13 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: mip4@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip4] RFC 4093 on Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4093 Title: Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways Author(s): F. Adrangi, Ed., H. Levkowetz, Ed. Status: Informational Date: August 2005 Mailbox: farid.adrangi@intel.com, henrik@levkowetz.com Pages: 19 Characters: 44082 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip4-vpn-problem-statement-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4093.txt Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions. This document is a product of the Mobility for IPv4 Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050826151103.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4093 --OtherAccess Content-Type: Message/External-body; name="rfc4093.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050826151103.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Sun Aug 28 05:29:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9JTP-0000Sa-Ee; Sun, 28 Aug 2005 05:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9JTN-0000SV-Ij for mip4@megatron.ietf.org; Sun, 28 Aug 2005 05:29:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06574 for ; Sun, 28 Aug 2005 05:29:02 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9JUS-0006Bf-Jo for mip4@ietf.org; Sun, 28 Aug 2005 05:30:14 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A458489852; Sun, 28 Aug 2005 12:28:38 +0300 (EEST) Message-ID: <431183D2.7080509@piuha.net> Date: Sun, 28 Aug 2005 12:28:50 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sami Vaarala Subject: Re: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt References: <4309EE00.4030503@piuha.net> <430A0992.6030900@iki.fi> In-Reply-To: <430A0992.6030900@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Sami Vaarala wrote: >The problem I see w.r.t. to using IKEv2/MOBIKE is that it does >not, alone, match the current problem statement. The assumption >made in draft-ietf-mip4-vpn-problem-statement-03.txt is that >existing deployed VPN infrastructure should be used (see e.g. >Section 5.1). > > Yes. I still view that as the main and most urgent use case, so the problem statement is OK. However, I believe we are also at a situation where we can see future deployments (particularly those based on IKEv2) start to do new things. I don't see a problem with pursuing two tracks simultaneously. Its not like they would be two redundant solutions, its more like points in different stages of evolution. >If we decide that there is no deployment issue w.r.t. MIPv4 and >already deployed VPNs, we should IMO take a larger view of >improving MIPv4/VPN coexistence. Minimizing overlap between >the two mechanisms would give a much better solution. For >instance, there is room for improvement in MIPv4 packet overhead, >MIPv4/VPN compression interactions, and integrated MIPv4/VPN >packet authentication. > I believe we will eventually get there. Probably step by step, however. I view Vijay's draft one of those steps... eliminating one unnecessary level in the stack. Or are you arguing that we should spend more time thinking what to do, if we discard the no-changes-at-all assumption? --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Aug 28 09:07:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Msc-0005Ss-36; Sun, 28 Aug 2005 09:07:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9MsW-0005Sj-5u for mip4@megatron.ietf.org; Sun, 28 Aug 2005 09:07:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17272 for ; Sun, 28 Aug 2005 09:07:14 -0400 (EDT) Received: from ns2.academica.fi ([217.64.177.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Mtd-000375-O3 for mip4@ietf.org; Sun, 28 Aug 2005 09:08:27 -0400 Received: from [82.133.140.118] (ip82-133-140-118.adsl.academica.fi [82.133.140.118]) by ns2.academica.fi (Postfix) with ESMTP id 61B11257025; Sun, 28 Aug 2005 16:03:37 +0300 (EEST) Message-ID: <4311CA83.9000306@iki.fi> Date: Sun, 28 Aug 2005 17:30:27 +0300 From: Sami Vaarala User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt References: <4309EE00.4030503@piuha.net> <430A0992.6030900@iki.fi> <431183D2.7080509@piuha.net> In-Reply-To: <431183D2.7080509@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sami.vaarala@iki.fi List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, >> The problem I see w.r.t. to using IKEv2/MOBIKE is that it does >> not, alone, match the current problem statement. The assumption >> made in draft-ietf-mip4-vpn-problem-statement-03.txt is that >> existing deployed VPN infrastructure should be used (see e.g. >> Section 5.1). >> >> > Yes. I still view that as the main and most urgent > use case, so the problem statement is OK. However, > I believe we are also at a situation where we can > see future deployments (particularly those based on > IKEv2) start to do new things. I don't see a problem > with pursuing two tracks simultaneously. Its not > like they would be two redundant solutions, its more > like points in different stages of evolution. Right, I agree. And I agree we can pursue two tracks at the same time. However, given that these two tracks have so much in common, it doesn't seem useful to specify them in two seemginly separate specifications. Given the way the solutions are specified, x-MIP + IKEv1 vs. MOBIKE + IKEv2 are just two different access modes. The overall approach, the intranet detection, etc, are all same. But stepping back a little, if we relax either the "existing VPN" or "minimal MIPv4 changes" assumptions, we get a number of different solutions. For instance: - A *very* straightforward way of getting mobility without x-MIP (and just IKEv1+IPsec) is just to use the "implicit ESP update" mechanism already deployed by some vendors. I believe a similar mechanism is used in the MIPv6 + IPsec draft. This is rather simple to implement and does away with the x-MIP overhead completely. - We could specify IKEv1 mobility extensions to allow more or less the same effect albeit with more vendor effort. Vijay's draft's Appendix has a suggestion for this. - Looking at x-MIP, we can also eliminate x-MIP overhead completely by defining an optimization extension between the MN and the x-HA. This approach retains FA support, while eliminating all x-MIP overhead in non-FA scenarios. The rough approach was described in draft-vaarala-mip4-optudp-00 [*]. - A very important concern in practice is managing the keys and authentication in a dual MIP or MOBIKE+MIP solution. Should we define something to make this easier? At least to me it's not at all clear which avenue would produce the best possible solution - minimal changes, maximum impact, and maximum generality (especially). So going past absolute minimum changes (dual MIP) needs more thought on what criteria we should apply to solutions. >> If we decide that there is no deployment issue w.r.t. MIPv4 and >> already deployed VPNs, we should IMO take a larger view of >> improving MIPv4/VPN coexistence. Minimizing overlap between >> the two mechanisms would give a much better solution. For >> instance, there is room for improvement in MIPv4 packet overhead, >> MIPv4/VPN compression interactions, and integrated MIPv4/VPN >> packet authentication. >> > I believe we will eventually get there. Probably step > by step, however. I view Vijay's draft one of those > steps... eliminating one unnecessary level in the stack. > Or are you arguing that we should spend more time thinking > what to do, if we discard the no-changes-at-all > assumption? I think we should work on defining what the longer term goal is w.r.t. IPsec and MIPv4 integration. I don't think it's clear people agree what that goal should be. And proposing, discussing, and comparing solutions beyond dual MIP is difficult at the moment, because we have nothing to compare them against. As far as dual MIP is concerned, going forward with it would be useful as a baseline and as documenting existing practice (as far as I know, some people are deploying it, although I'm not sure at what scale). But if we agree on working on a better long-term solution, that would of course be preferable to working on a limited dual MIP solution. Best, -Sami [*] http://users.tkk.fi/~svaarala/publications/draft-vaarala-mip4-optudp-00.txt -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 29 10:37:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9klG-0006ok-35; Mon, 29 Aug 2005 10:37:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9klE-0006oY-R3 for mip4@megatron.ietf.org; Mon, 29 Aug 2005 10:37:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13812 for ; Mon, 29 Aug 2005 10:37:19 -0400 (EDT) From: jouni.korhonen@teliasonera.com Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9kmZ-0001im-TS for mip4@ietf.org; Mon, 29 Aug 2005 10:38:45 -0400 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id j7TEaweA003561 for ; Mon, 29 Aug 2005 17:36:58 +0300 (EEST) Received: from FITMS201MB.tcad.telia.se (fitms201cb.tcad.telia.se [131.177.121.204]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id j7TEaw2b003557; Mon, 29 Aug 2005 17:36:58 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6617.27 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Re: review ofdraft-devarapalli-mip4-mobike-connectivity-00.txt Date: Mon, 29 Aug 2005 17:36:57 +0300 Message-ID: <07B14A720C46C344AC96AAA64F5D6A3101491817@FITMS201MB.tcad.telia.se> Thread-Topic: [Mip4] Re: review ofdraft-devarapalli-mip4-mobike-connectivity-00.txt Thread-Index: AcWp0A31svztHydjSJ+YMBTRkrpAVQC0Zvxw To: , X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Vijay,=20 Adding some more comments inline on this very interesting draft. > > I started to wonder whether there's something here > > that would apply in similar manner to Mobile IPv6. There > > does not appear to be any specific dependency on Mobile > > IPv4 here.=20 >=20 > yes its possible. infact in 3GPP2-WLAN IW, this is already > being considered. a MIPv6 tunnel with a HA through an IPsec > tunnel with the PDIF. I thought about writing up a draft > for MIPv6 too, but nobody is asking for it right now. :) > also for MIPv6, it might make sense to collapse the VPN > gateway and the HA into the same box. I also would like to see a draft to cover the MIP6 case. Furthermore, even though 3GPP has not spelled it out yet, this work might have relevance in there also. Their 3G-WLAN interworking has an IKEv2 scenario -- from where a leap towards MOBIKE isn't that big anymore ;) > > Doing the same for Mobile IPv6 appears to > > be possible, although doing VPN + IPsec-based > > home agent security would imply nested IPsec tunnels. > > Interestingly, with v6 RO you could eliminate the > > second (inner) tunnel in your solution. >=20 > yup. >=20 > > But perhaps that discussion falls under the scope of > > the v4-v6 interoperability scheme. >From a telco (3GPP-WLAN interworking) perspective MOBIKE with MIP6 could actually provide one solution for migration in heterogeneous access network. I was thinking of the case, where the cellular using MIP6 would be considered as the trusted network and the other accesses (read WLANs etc) as untrusted. There MOBIKE could be used to provide access also in untrusted IPv4 access networks. Any comments? Cheers, Jouni -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 29 12:04:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9m81-0006w3-Bh; Mon, 29 Aug 2005 12:04:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8f1f-0004Za-Ui for mip4@megatron.ietf.org; Fri, 26 Aug 2005 10:17:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22701 for ; Fri, 26 Aug 2005 10:17:45 -0400 (EDT) Received: from hkueee2.eee.hku.hk ([147.8.180.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8f2O-0008At-Tr for mip4@ietf.org; Fri, 26 Aug 2005 10:18:33 -0400 Received: from se6000 (se6000.eee.hku.hk [147.8.180.36]) by hkueee2.eee.hku.hk (8.13.4/8.13.4) with ESMTP id j7QEGt9e028512; Fri, 26 Aug 2005 22:16:55 +0800 (HKT) Date: Fri, 26 Aug 2005 22:16:55 +0800 (HKT) From: Ka-Cheong Leung X-X-Sender: kcleung@se6000 To: mip4@ietf.org Subject: [mip4] [CFP] NASM 2005 (Deadline: Aug. 31, 2005) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-HKUEEE-MailScanner-Information: www.eee.hku.hk/intranet/computer/faq/mailscanner.htm X-HKUEEE-MailScanner: Found to be clean X-HKUEEE-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.127, required 5, autolearn=not spam, AWL 0.47, BAYES_00 -2.60) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-Mailman-Approved-At: Mon, 29 Aug 2005 12:04:56 -0400 Cc: Leung Ka Cheong X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kcleung@ieee.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (We apologize if you receive multiple copies of this CFP.) CALL FOR PAPERS The First International Workshop on Network Architecture and Service Models NASM 2005 November 21-23, 2005 Fudan University, Shanghai, China http://www.elec.qmul.ac.uk/wharf/NASM-2005.htm Technically Co-Sponsored by: British Computer Society (BCS) Institution of Electrical Engineers (IEE) Queen Mary / Fudan Joint Laboratory in Mobile Networks and Ubiquitous Computing SCOPE Network architecture and service model are two key topics of network research and applications. With the rapid development of optical and wireless communications, chips and software, network architectures are changing and new service models are needed. Many research and technical challenges are being addressed by researchers from both industries and academia. It is viewed that through international collaboration among several experts in different parts of the globe, greater research excellence and achievements can be made. OBJECTIVE The objective of this workshop is to discuss new approaches and technologies in the field of next generation networks (NGN), ad hoc mobile networks, wireless sensor networks, and P2P networks. TOPICS OF INTERESTS The main topics of interests include, but not limited to: * Network architectures and services * Optical and wireless networks * Routing and scheduling * Application model and QoS * Mobile network architecture * MAC and QoS MAC in MANET * Mobile addressing * Mobile routing * Mobile applications PAPER SUBMISSIONS - Format: Submissions should include an abstract of 100 words, 5-7 keywords, the e-mail address of the corresponding author, and must not exceed 8 pages (in 2-column format), including tables and figures, with PDF, Postscript, or MS Word format. - Submission: Please submit your paper directly to the workshop chair or co-chair. E-mail: xinw@fudan.edu.cn - Review: Contributions will be reviewed by at least three reviewers from both program committee and external reviewers for relevance and technical contents on basis of papers. - Publication: Selected accepted papers will be published as special issues of International Journal of Ad Hoc and Ubiquitous Computing (IJHAUC). http://www.inderscience.com/browse/index.php?journalID=145 IMPORTANT DATES Paper Submission Due: August 31, 2005 Acceptance Notification: October 15, 2005 Final Camera-Ready Paper: October 22, 2005 Author Registration: October 22, 2005 Workshop Date: November 22, 2005 ORGANIZERS AND COMMITTEE Honorary Chair Prof. Jiangxing Wu, NDSC, China General Chair Prof. CK Toh, Queen Mary University of London, UK Technical Program Chair Prof. Xiangyang Xue, Fudan University, China TPC Members Prof. Victor Li, University of Hong Kong, China Prof. Laurie Cuthbert, University of London, UK Prof. Hong Shen, Japan Advanced Institute of Science and Technology, Japan Prof. Yoshiaki Kakuda, Hiroshima University, Japan Prof. Tadanori Mizuno, Shizuoka University, Japan Prof. Shuigeng Zhou, Fudan University, China Prof. Ke Xu, Tsinghua University, China Prof. Hai Jin, Wuhan University, China Prof. Jiandong Li, Xidian University, China Prof. Zhengbin Li, Peking University, China Prof. Y.-H. Choi, Seoul National University, Korea Prof. H.-K. Kahng, Korea University, Korea Prof. D.-K. Kim, Kyungpook National University, Korea Dr. Jiang Du, Queensland University, Australia Prof. Lai Xu, Vrije University, Netherlands Prof. Jun Zhang, National Chiao Tung University, China Prof. Qing'an Zeng, Southeast University, China Prof. H-C. Chao, National Dong Hwa University, Taiwan, China Prof. J.-C. Chen, National Hsing Hwa University, Taiwan, China Prof. Y. S. Chen, National Chung Cheng University, Taiwan, China Dr. Russell Hsing, Telcordia Technologies Inc., USA Prof. Wei K. Tsai, University of California Irvine, USA Prof. Joe Hui, Arizona State University, USA Local Arrangements Chair Prof. Wang Xin, Fudan University, China Publicity Chair Dr. K.-C. Leung, University of Hong Kong, China -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 29 22:19:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9viR-0005gI-EL; Mon, 29 Aug 2005 22:19:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9viP-0005g8-CO for mip4@megatron.ietf.org; Mon, 29 Aug 2005 22:19:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00751 for ; Mon, 29 Aug 2005 22:19:07 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9vjq-00006k-Kx for mip4@ietf.org; Mon, 29 Aug 2005 22:20:40 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7U1kS127712; Mon, 29 Aug 2005 18:46:28 -0700 X-mProtect: <200508300146> 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 smtpdBk1vxh; Mon, 29 Aug 2005 18:46:26 PDT Message-ID: <4313C201.6070307@iprg.nokia.com> Date: Mon, 29 Aug 2005 19:18:41 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [Mip4] Re: review ofdraft-devarapalli-mip4-mobike-connectivity-00.txt References: <07B14A720C46C344AC96AAA64F5D6A3101491817@FITMS201MB.tcad.telia.se> In-Reply-To: <07B14A720C46C344AC96AAA64F5D6A3101491817@FITMS201MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, mip4@ietf.org, jari.arkko@piuha.net X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org jouni.korhonen@teliasonera.com wrote: > Hi Vijay, > > Adding some more comments inline on this very interesting draft. > > >>>I started to wonder whether there's something here >>>that would apply in similar manner to Mobile IPv6. There >>>does not appear to be any specific dependency on Mobile >>>IPv4 here. >> >>yes its possible. infact in 3GPP2-WLAN IW, this is already >>being considered. a MIPv6 tunnel with a HA through an IPsec >>tunnel with the PDIF. I thought about writing up a draft >>for MIPv6 too, but nobody is asking for it right now. :) >>also for MIPv6, it might make sense to collapse the VPN >>gateway and the HA into the same box. > I also would like to see a draft to cover the MIP6 case. > Furthermore, even though 3GPP has not spelled it out yet, > this work might have relevance in there also. Their 3G-WLAN > interworking has an IKEv2 scenario -- from where a leap > towards MOBIKE isn't that big anymore ;) okay >>From a telco (3GPP-WLAN interworking) perspective MOBIKE with > MIP6 could actually provide one solution for migration in > heterogeneous access network. I was thinking of the case, > where the cellular using MIP6 would be considered as the > trusted network and the other accesses (read WLANs etc) as > untrusted. There MOBIKE could be used to provide access also > in untrusted IPv4 access networks. Any comments? agreed. please bring this up on the MIP6 mailing list. I would be happy to write up a similar draft for MIPv6. Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 29 23:57:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xFM-0003n3-DY; Mon, 29 Aug 2005 23: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 1E9xFK-0003mx-HL for mip4@megatron.ietf.org; Mon, 29 Aug 2005 23:57:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04698 for ; Mon, 29 Aug 2005 23:57:11 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9xGm-0002Y1-OO for mip4@ietf.org; Mon, 29 Aug 2005 23:58:45 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7U3sv111082; Mon, 29 Aug 2005 23:54:57 -0400 (EDT) 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: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Date: Mon, 29 Aug 2005 22:56:51 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710A16150E@zrc2hxm2.corp.nortel.com> Thread-Topic: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Thread-Index: AcWqT6DxPTAF7CAnTcSU9hkW93mMZAA81q7w From: "Ahmad Muhanna" To: "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c Content-Transfer-Encoding: quoted-printable Cc: Margaret Wasserman , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , "Joel M. Halpern" , "Kent Leung \(kleung\)" , Henrik Levkowetz , "Milind Kulkarni \(mkulkarn\)" , Mohamed Khalil X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Pete, Sorry for the late response. Please see comments inline. Regards, Ahmad >=20 > Hi, Ahmad, >=20 > See below. >=20 > Ahmad Muhanna writes: > > Thanks Pete for bringing the discussion to the mailing list. >=20 > Please see comments inline. > > Regards, > > Ahmad > >=20 > > >=20 > > > Hi, > > >=20 > > > [back on the mailing list now] > > >=20 > > > This thread concerns the possibility of having more than one=20 > > > HA create a binding for a given MN. It seems true that the=20 > > > RRQ created by the MN, if delivered to multiple HAs, could=20 > > > potentially create state on each of those HAs.=20 > > =20 > > [Ahmad] > > Since you agree that this attack is valid and possible and=20 > if this > attack is successful with a single MN, then it is=20 > possible for almost > every MN requesting Dynamic HA on the=20 > compromised FA-HA link. That could > be devastating to the=20 > HA domain. I hope you agree. >=20 > I wouldn't use the word "devastating." If the HAs are on different=20 > subnets, it creates some extra state that has no effect on the overall > operation of the system and which will timeout after the first=20 > Lifetime. [Ahmad] In the case where HA's assign IP addresses from local pools, this means a waste of IP addresses. Now, if this attack is possible for one MN, it can be possible for many MN's and probably drain HA resources of IP addresses. It could be a real problem. >=20 > If the HAs are on the same subnet, however, it will create a=20 > competition for the gratuitous/proxy ARP which would have an effect on > the reliability of the traffic, so I can see your point of view here. >=20 > > > However, I > > > think we are making too much out of the possibility. An > > > attacker that has the power to duplicate packets (changing=20 > > > the destination IP address) and drop selected packets > >=20 > > [Ahmad] > > If we think along this line, we probably do not need any=20 > security > measures in MIPv4 protocol to start with. On the=20 > other hand, why RFC > (3543) mandates the FA to have a=20 > security association with the HA to > participate in=20 > registration revocation? >=20 > I am not saying we don't need security, just that we need to consider=20 > the big picture. If you think about the most likely deployment=20 > scenarios for this draft, there will be a single AAA server that is=20 > responsible for allocating a home agent address and for distributing=20 > security associations. > Inserting requests into a secure AAA infrastructure is a lot=20 > harder than inserting a duplicate (destination address=20 > modified) packet. [Ahmad] I am not sure about the concept of a single AAA server. Anyway, you are basically proving my point here. You just highlighted that the reason that we do not need to worry about this issue when the deployment uses AAA infrastructure is that AAA infrastructure is a SECURE one. On the other hand, you seem not to agree to make the FA-HA link a secure one for the other deployment. Why don't we agree to make that link secure too. It is nothing new, already existing FA and HA most probably support registration revocation which requires FA-HA security association. >=20 > Even if the Registration Request is sent directly to an HA, it will=20 > most likely be protected by an MN-AAA authentication extension, and=20 > the central AAA server can prevent duplicate sessions. [Ahmad] You are assuming a SINGLE statefull AAA server in this one. >=20 > > > can > > > pretty much prevent a mobile IP registration from taking > place. >=20 > > [Ahmad] > > Of course, that is true. That is why we need to make sure=20 > that we have a > secure solution (protocol) to prevent such=20 > attacks. >=20 > > >=20 > > > Rather, I think we should focus on the correctness of the=20 > > > protocol in the absence of attackers:=20 > >=20 > > [Ahmad] > > Is that a MIPv4 WG mandate or just your opinion? >=20 > Sorry, chair hat off for now. >=20 > > > there is a requirement > > > for a unicast destination address on the packet so only one > > > HA will receive it in a normal protocol run. =20 > >=20 > > [Ahmad] > > Thinking of normal protocol run; If all what we are=20 > looking for is just > normal protocol run, then why do we=20 > have all of these security > associations and extensions in=20 > all of the RFCs related to MIPv4 > protocol. >=20 > > > I do not think=20 > > > we need to add special mechanisms like the infinite/short=20 > > > lifetime that is being proposed or the requirement for an=20 > > > FA-HA MSA. I think these requirements would unfairly limit=20 > > > the deployment possibilities. > >=20 > > [Ahmad] > > I respectfully disagree. If such attack happens, service=20 > providers may > not be able to serve their own legitimate=20 > customers. It will cost them a > lot of money. >=20 > > >=20 > > > It seems to me that it should suffice to put in some text in=20 > > > the security considerations about this issue. =20 > >=20 > > [Ahmad] > > If we clearly highlight the security issue and this=20 > mailing list has a > consensus, I have no problem at all. >=20 > >=20 > > > We might also=20 > > > consider adding text that says if the MN gets RRPs from more=20 > > > than one HA it must immediately de-register the extra=20 > > > unwanted bindings. > >=20 > > [Ahmad] > > Could you please explain to me how this is possible in a=20 > case when FA is > present in the call path. Thanks. >=20 > You are right I think - the FA would drop the extra RRPs because it=20 > would be looking for a response from the unicast HA to which it sent=20 > the message. Of course, if the RRQ was sent to the AAA infrastructure > ala RFC 4004, then there is no issue. >=20 > Perhaps what we need is a note in the security considerations that=20 > mentions the possibility of multiple HAs on the same subnet getting=20 > the registration request and independently authenticating it. This=20 > will be possible in some deployments and impossible (e.g., centralized > AAA server validating MN-AAA auth extension) in others. If it is=20 > possible, then maybe we need to return a successful binding with=20 > Lifetime=3D0 which will indicate to the MN that it needs to = immediately > re-register with the assigned HA. [Ahmad] I do not agree that this belongs to the security consideration section. IMO it is more serious than that and it should be considered under the FA consideration section. On the other hand, your suggestion (lifetime = =3D 0) defeats the basic principle of Dynamic HA being established in a single round trip registration. If we need to use 2 round trip registration, I believe what RFC(3344) already has makes more sense. HA reject the RRQ with code (136) Unknown HA Address and inserts its own unicast IP address in the HA field of the RRP. Then MN sends RRQ using the HA unicast IP address as per the HA address in RRP.=20 >=20 > -Pete >=20 >=20 > > > -Pete > > > > > > > > > Ahmad Muhanna writes: > > > > Aplesh, > > > >=20 > > > > Comments inline. > > > >=20 > > > > Regards, > > > > Ahmad > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Alpesh Patel (alpesh) [mailto:alpesh@cisco.com]=20 > > > > > Sent: Wednesday, August 24, 2005 8:44 PM > > > > > To: Henrik Levkowetz; Muhanna, Ahmad=20 > [RICH2:2Q30:EXCH] > > > > Cc: Peter McCann; Margaret=20 > Wasserman; Kent Leung (kleung);=20 > > > > > Milind Kulkarni (mkulkarn); Joel M. Halpern;=20 > Khalil, Mohamed=20 > > > > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh) > > > > > Subject: RE: [Mip4] Re: LC review:=20 > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > >=20 > > > > >=20 > > > > > Henrik: > > > > >=20 > > > > > In regards to Ahmad's original comment, we have one=20 > > > suggestion: > >=20 > > > > > If the rogue node changes the destination address=20 > enroute to=20 > > > > > the HA and sends the RRQ to multiple HA's, the most=20 > that can=20 > > > > > go wrong is multiple HA's creating a binding for=20 > the MN. > > > >=20 > > > > [Ahmad] > > > > I believe that is a big deal. It means that multiple=20 > > > resources will be > allocated for the same MN, including IP=20 > > > address which is very precious > in MIPv4. It also could=20 > > > have impact on billing at the HA. >=20 > > > > > The rogue has to first figure out all the HA's addresses -=20 > > > > > this may not be trivial. > > > >=20 > > > > [Ahmad] > > > > Well, I do not want to debate this but the fact it is=20 > > > possible then it > is an issue. >=20 > > > > >=20 > > > > > Also, a good MN implementation will deregister when it=20 > > > > > receives multiple Registration Replies (if the rogue=20 > > > > > succeeded in doing its trick). So, there is not a=20 > > > problem here. >=20 > > > > [Ahmad] > > > > Where is that documented? Can you please give a=20 > reference to this.=20 > > > >=20 > > > > >=20 > > > > > Also, the rogue cannot mount a "store and replay" attack -=20 > > > > > this window of vulnerability is limited only within the=20 > > > > > replay window - otherwise the HA's will reject the=20 > > > > > Reigstration Replies anyway. > > > >=20 > > > > [Ahmad] > > > > I agree that this attack is limited to the replay window.=20 > > > However, it is > very simple and can happen. >=20 > > > > >=20 > > > > > How about adding text to the following effect: > > > > >=20 > > > > > When requesting dynamic HA assignment, MN SHOULD=20 > not set the=20 > > > > > lifetime field to infinity (0xffff). If lifetime=20 > requested is=20 > > > > > infinite, HA MUST set it to a low value and send a=20 > > > > > Registration Reply. (This will mitigate the risk of=20 > lingering=20 > > > > > binding entries at HA's - in case the Registration=20 > Reply from=20 > > > > > other HAs' are lost). > > > >=20 > > > > [Ahmad] > > > > Let us assume that the MN ends up registering at multiple=20 > > > HA's. As per > the RFC3543 "Registration Revocation", we=20 > > > need a security association > between the FA and the HA in=20 > > > order to revoke this false binding. On the > other hand, we=20 > > > do not have the same requirement for establishing the >=20 > > > binding to start with. Does that make sense?. >=20 > > > > >=20 > > > > > Subsequent registration requests with the HA where MN is=20 > > > > > anchored can have default behavior. > > > > >=20 > > > > > So, if the rogue is succesful in mounting this type of=20 > > > > > attack, it will be short lived (limited to=20 > lifetime). > > > =20 > > > > [Ahmad] > > > > Basically you agree to publish a standard with a security=20 > > > vulnerability > as long as it is short lived? > I=20 > > > understand that there is a limited audience on this thread,=20 > > > but I > guess some carriers may not like that limitation. >=20 > > > > Also,=20 > > > > > this attack will be successful only if the Reply from the=20 > > > > > HAs' do not reach the MN.=20 > > > >=20 > > > > [Ahmad] > > > > I disagree, same comment as above. Is that documented=20 > > > anywhere?. >=20 > > > > Finally, I have no issue to publish the draft (as is) as=20 > > > long as you > document the security vulnerability as per=20 > > > your statement below. > " So, if the rogue is succesful in=20 > > > mounting this type of attack, it will > be short lived=20 > > > (limited to lifetime)" >=20 > > > > Another alternative: we can add this under section 5.2=20 > > > Foreign Agent > Considerations:=20 > > > > During the registration process, if the foreign=20 > agent wishes to > > > > participate in dynamic home agent allocation process=20 > > > with the home > > > > domain,=20 > > > > it MUST have an existing security association with the=20 > > > home agent=20 > > > > that has been identified to serve the registration request. > > > > >=20 > > > > > Comments/Suggestions? > > > > > Alpesh=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Henrik Levkowetz=20 > [mailto:henrik@levkowetz.com] > > > > > Sent: Saturday,=20 > August 20, 2005 6:42 PM > > > > > To: Ahmad Muhanna > > >=20 > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung); > > > > > > Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Joel M. > > > > > > Halpern; Mohamed Khalil > > > > > > Subject: Re: [Mip4] Re: LC review:=20 > > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > >=20 > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > Hash: SHA1 > > > > > >=20 > > > > > > Hi Ahmad, > > > > > >=20 > > > > > > Comments below. Milind, Alpesh, Kent - would=20 > you check > > > > > > this, please? > > > > > >=20 > > > > > >=20 > > > > > > On 2005-08-20 23:23 Ahmad Muhanna said the=20 > following: > > > > > > Hi Pete/Henrick, > > > > > >=20 > > > > > > >=20 > > > > > > > As chairs for the Mip4 working group, I would like=20 > > > to get your > > > > feedback on the security issue=20 > > > identified in my posting dated=20 > > > > > > > 6/22/205. email attached. In that posting I=20 > > > identified a security=20 > > > > > > > issue which could cause a MN to register with multiple=20 > > > > > HAs. No one=20 > > > > > > > apparently showed interest in this issue including=20 > > > the authors.=20 > > > > > > > However, I believe that the group needs to=20 > conclude if it=20 > > > > > > is an issue > > > > > > > or not before this draft becomes a standard. > > > > > > >=20 > > > > > > > This email is not posted to the mip4 list. > > > > > > >=20 > > > > > > > Please let me know what you think of this. > > > > > > > Thanks! > > > > > > >=20 > > > > > >=20 > > > > > > [snip copy of later mail from Joel Halpern] > > > > > >=20 > > > > > > > Hello all, > > > > > > >=20 > > > > > > > My apologies in advance if this issue has been=20 > discussed=20 > > > > > before. If > > > > > > > that is true, can someone let me know of the=20 > > > conclusion. Thanks! > > > >=20 > > > > > > > As per section 5.3.1 Assigned Home Agent=20 > Considerations,=20 > > > > > I find the > > > > > > > following paragraph: > > > > > > > " > > > > > > > As per the messaging proposed here, the mobile node (or=20 > > > > > the foreign > > > > > > > agent) sends the Registration Request to the=20 > Requested HA=20 > > > > > address,=20 > > > > > > > which is a unicast address. Therefore, this=20 > document does=20 > > > > > > not specify > > > > > > > any new behavior for the case where the HA receives=20 > > > a > > > subnet directed > > > > broadcast Registration=20 > > > Request as specified in section > > > 3.8.2.1 of the > > >=20 > > > > Mobile IPv4 specification [1]. Although the Home Agent=20 > > > > > field in the > > > > > > > Registration Request is not a unicast address, the=20 > > > destination IP=20 > > > > > > > address is a unicast address. This avoids the problem=20 > > > > > > associated with > > > > > > > subnet-directed broadcast destination IP=20 > address that may=20 > > > > > result in > > > > > > > multiple HAs responding. Thus, there is no need=20 > to deny the=20 > > > > > > > registration as stated in Mobile IPv4 [1] section=20 > > > 3.8.3.2." > > > >=20 > > > > > > > My question here is how by setting the destination=20 > > > IP > > > address of the > > > > IP packet to the HA unicast=20 > > > IP address guarantee that MN=20 > > > > > will avoid > > > > > > > the possibility of being registered with multiple=20 > > > HAs? > > > >=20 > > > > > > > What I have in mind here, is the possibility of=20 > > > someone > > > listening on > > > > that link and all what=20 > > > is needed is to include the RRQ in > > > an IP packet > > >=20 > > > > with the destination IP address is set to a different HA.=20 > > > In other > > > > words, any HA receives this RRQ can process=20 > > > this RRQ and send a=20 > > > > > > > confirmation reply to the MN and MN ends up registering=20 > > > > > > with multiple > > > > > > > HAs.? > > > > > >=20 > > > > > > This would be the case when an MN registers directly=20 > > > with a > > > HA, with a co-located care-of address, and does=20 > > > not include=20 > > > > > > the requested HA extension. > > > > > >=20 > > > > > > I believe you are right that there is a possibility of=20 > > > a bad > > > guy causing a registration with more than=20 > one HA in this=20 > > > > > > case. This would result in the MN receiving registration=20 > > > > > > replies from multiple HAs, if more than one HA=20 > would decide=20 > > > > > > to accept the registration. > > > > > >=20 > > > > > > The solution could be to specify that the inclusion of=20 > > > a > > > Requested HA extension would be a MUST in all cases,=20 > > > with the=20 > > > > > > HA being required to verify that the HA address in the=20 > > > > > > Requested HA extension matches its own address. > > > > > >=20 > > > > > >=20 > > > > > > Henrik > > > > > > -----BEGIN PGP SIGNATURE----- > > > > > >=20 > > > > > >=20 > > > iD8DBQFDB9vjeVhrtTJkXCMRAhxDAKCAVB5dw98q6fNcHe/r7qmbLd9vJQCg4oLd > > > > > > 9k8rjzf6t7VTAI/L1rLu8cg=3D > > > > > > =3DWo9C > > > > > > -----END PGP SIGNATURE----- > > > > > >=20 > > > > >=20 > > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-> charter.html > >=20 > Supplemental site: http://www.mip4.org/ >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 30 10:27:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA74p-0004In-KE; Tue, 30 Aug 2005 10:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA74m-0004G0-Ph for mip4@megatron.ietf.org; Tue, 30 Aug 2005 10:27:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16112 for ; Tue, 30 Aug 2005 10:26:58 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA76K-0002jQ-Td for mip4@ietf.org; Tue, 30 Aug 2005 10:28:37 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j7UEQgG7012371; Tue, 30 Aug 2005 09:26:43 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j7UEQe701777; Tue, 30 Aug 2005 09:26:40 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17172.27808.156164.884480@gargle.gargle.HOWL> Date: Tue, 30 Aug 2005 09:26:40 -0500 From: Pete McCann To: "Ahmad Muhanna" Subject: RE: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710A16150E@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710A16150E@zrc2hxm2.corp.nortel.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , Margaret Wasserman , "Kent Leung \(kleung\)" , Mohamed Khalil , Henrik Levkowetz , "Milind Kulkarni \(mkulkarn\)" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, Ahmad, I think I see your point now, but I still disagree that we need to mandate FA-HA security association in all cases. Think about the MIP4 Diameter application where the security is hop-by-hop: the RRQ arrives at the HA via the AAA server and the HAs can be configured to accept initial RRQs only from this interface. I don't think we need to require the FA/HA MSA in this case; it is provided indirectly via the hop-by-hop AAA security. -Pete Ahmad Muhanna writes: > Hi Pete, > Sorry for the late response. Please see comments inline. > > Regards, > Ahmad > > > > > > Hi, Ahmad, > > > > See below. > > > > Ahmad Muhanna writes: > > > Thanks Pete for bringing the discussion to the mailing list. > > > Please see comments inline. > > Regards, > > > Ahmad > > > > > > > > > > > Hi, > > > > > > > > [back on the mailing list now] > > > > > > > > This thread concerns the possibility of having more than one > > > > HA create a binding for a given MN. It seems true that the > > > > RRQ created by the MN, if delivered to multiple HAs, could > > > > potentially create state on each of those HAs. > > > > > > [Ahmad] > > > Since you agree that this attack is valid and possible and > > if this > attack is successful with a single MN, then it is > > possible for almost > every MN requesting Dynamic HA on the > > compromised FA-HA link. That could > be devastating to the > > HA domain. I hope you agree. > > > > I wouldn't use the word "devastating." If the HAs are on different > > subnets, it creates some extra state that has no effect on the overall > > > operation of the system and which will timeout after the first > > Lifetime. > > [Ahmad] > In the case where HA's assign IP addresses from local pools, this means > a waste of IP addresses. Now, if this attack is possible for one MN, it > can be possible for many MN's and probably drain HA resources of IP > addresses. It could be a real problem. > > > > > If the HAs are on the same subnet, however, it will create a > > competition for the gratuitous/proxy ARP which would have an effect on > > > the reliability of the traffic, so I can see your point of view here. > > > > > > However, I > > > > think we are making too much out of the possibility. An > > > > attacker that has the power to duplicate packets (changing > > > > the destination IP address) and drop selected packets > > > > > > [Ahmad] > > > If we think along this line, we probably do not need any > > security > measures in MIPv4 protocol to start with. On the > > other hand, why RFC > (3543) mandates the FA to have a > > security association with the HA to > participate in > > registration revocation? > > > > I am not saying we don't need security, just that we need to consider > > the big picture. If you think about the most likely deployment > > scenarios for this draft, there will be a single AAA server that is > > responsible for allocating a home agent address and for distributing > > security associations. > > Inserting requests into a secure AAA infrastructure is a lot > > harder than inserting a duplicate (destination address > > modified) packet. > > [Ahmad] > I am not sure about the concept of a single AAA server. Anyway, you are > basically proving my point here. You just highlighted that the reason > that we do not need to worry about this issue when the deployment uses > AAA infrastructure is that AAA infrastructure is a SECURE one. On the > other hand, you seem not to agree to make the FA-HA link a secure one > for the other deployment. Why don't we agree to make that link secure > too. It is nothing new, already existing FA and HA most probably support > registration revocation which requires FA-HA security association. > > > > > Even if the Registration Request is sent directly to an HA, it will > > most likely be protected by an MN-AAA authentication extension, and > > the central AAA server can prevent duplicate sessions. > > [Ahmad] > You are assuming a SINGLE statefull AAA server in this one. > > > > > > > can > > > > pretty much prevent a mobile IP registration from taking > > place. > > > > [Ahmad] > > > Of course, that is true. That is why we need to make sure > > that we have a > secure solution (protocol) to prevent such > > attacks. > > > > > > > > > Rather, I think we should focus on the correctness of the > > > > protocol in the absence of attackers: > > > > > > [Ahmad] > > > Is that a MIPv4 WG mandate or just your opinion? > > > > Sorry, chair hat off for now. > > > > > > there is a requirement > > > > for a unicast destination address on the packet so only one > > > > HA will receive it in a normal protocol run. > > > > > > [Ahmad] > > > Thinking of normal protocol run; If all what we are > > looking for is just > normal protocol run, then why do we > > have all of these security > associations and extensions in > > all of the RFCs related to MIPv4 > protocol. > > > > > I do not think > > > > we need to add special mechanisms like the infinite/short > > > > lifetime that is being proposed or the requirement for an > > > > FA-HA MSA. I think these requirements would unfairly limit > > > > the deployment possibilities. > > > > > > [Ahmad] > > > I respectfully disagree. If such attack happens, service > > providers may > not be able to serve their own legitimate > > customers. It will cost them a > lot of money. > > > > > > > > > It seems to me that it should suffice to put in some text in > > > > the security considerations about this issue. > > > > > > [Ahmad] > > > If we clearly highlight the security issue and this > > mailing list has a > consensus, I have no problem at all. > > > > > > > > We might also > > > > consider adding text that says if the MN gets RRPs from more > > > > than one HA it must immediately de-register the extra > > > > unwanted bindings. > > > > > > [Ahmad] > > > Could you please explain to me how this is possible in a > > case when FA is > present in the call path. Thanks. > > > > You are right I think - the FA would drop the extra RRPs because it > > would be looking for a response from the unicast HA to which it sent > > the message. Of course, if the RRQ was sent to the AAA infrastructure > > > ala RFC 4004, then there is no issue. > > > > Perhaps what we need is a note in the security considerations that > > mentions the possibility of multiple HAs on the same subnet getting > > the registration request and independently authenticating it. This > > will be possible in some deployments and impossible (e.g., centralized > > > AAA server validating MN-AAA auth extension) in others. If it is > > possible, then maybe we need to return a successful binding with > > Lifetime=0 which will indicate to the MN that it needs to immediately > > re-register with the assigned HA. > > [Ahmad] > I do not agree that this belongs to the security consideration section. > IMO it is more serious than that and it should be considered under the > FA consideration section. On the other hand, your suggestion (lifetime = > 0) defeats the basic principle of Dynamic HA being established in a > single round trip registration. If we need to use 2 round trip > registration, I believe what RFC(3344) already has makes more sense. HA > reject the RRQ with code (136) Unknown HA Address and inserts its own > unicast IP address in the HA field of the RRP. Then MN sends RRQ using > the HA unicast IP address as per the HA address in RRP. > > > > -Pete > > > > > > > > -Pete > > > > > > > > > > > > Ahmad Muhanna writes: > > > > > Aplesh, > > > > > > > > > > Comments inline. > > > > > > > > > > Regards, > > > > > Ahmad > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Alpesh Patel (alpesh) [mailto:alpesh@cisco.com] > > > > > > Sent: Wednesday, August 24, 2005 8:44 PM > > > > > > To: Henrik Levkowetz; Muhanna, Ahmad > > [RICH2:2Q30:EXCH] > > > > Cc: Peter McCann; Margaret > > Wasserman; Kent Leung (kleung); > > > > > > Milind Kulkarni (mkulkarn); Joel M. Halpern; > > Khalil, Mohamed > > > > > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh) > > > > > > Subject: RE: [Mip4] Re: LC review: > > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > > > > > > > > > > > > > Henrik: > > > > > > > > > > > > In regards to Ahmad's original comment, we have one > > > > suggestion: > > > > > > > > If the rogue node changes the destination address > > enroute to > > > > > > the HA and sends the RRQ to multiple HA's, the most > > that can > > > > > > go wrong is multiple HA's creating a binding for > > the MN. > > > > > > > > > [Ahmad] > > > > > I believe that is a big deal. It means that multiple > > > > resources will be > allocated for the same MN, including IP > > > > address which is very precious > in MIPv4. It also could > > > > have impact on billing at the HA. > > > > > > > The rogue has to first figure out all the HA's addresses - > > > > > > this may not be trivial. > > > > > > > > > > [Ahmad] > > > > > Well, I do not want to debate this but the fact it is > > > > possible then it > is an issue. > > > > > > > > > > > > > Also, a good MN implementation will deregister when it > > > > > > receives multiple Registration Replies (if the rogue > > > > > > succeeded in doing its trick). So, there is not a > > > > problem here. > > > > > > [Ahmad] > > > > > Where is that documented? Can you please give a > > reference to this. > > > > > > > > > > > > > > > > > Also, the rogue cannot mount a "store and replay" attack - > > > > > > this window of vulnerability is limited only within the > > > > > > replay window - otherwise the HA's will reject the > > > > > > Reigstration Replies anyway. > > > > > > > > > > [Ahmad] > > > > > I agree that this attack is limited to the replay window. > > > > However, it is > very simple and can happen. > > > > > > > > > > > > > How about adding text to the following effect: > > > > > > > > > > > > When requesting dynamic HA assignment, MN SHOULD > > not set the > > > > > > lifetime field to infinity (0xffff). If lifetime > > requested is > > > > > > infinite, HA MUST set it to a low value and send a > > > > > > Registration Reply. (This will mitigate the risk of > > lingering > > > > > > binding entries at HA's - in case the Registration > > Reply from > > > > > > other HAs' are lost). > > > > > > > > > > [Ahmad] > > > > > Let us assume that the MN ends up registering at multiple > > > > HA's. As per > the RFC3543 "Registration Revocation", we > > > > need a security association > between the FA and the HA in > > > > order to revoke this false binding. On the > other hand, we > > > > do not have the same requirement for establishing the > > > > > binding to start with. Does that make sense?. > > > > > > > > > > > > > Subsequent registration requests with the HA where MN is > > > > > > anchored can have default behavior. > > > > > > > > > > > > So, if the rogue is succesful in mounting this type of > > > > > > attack, it will be short lived (limited to > > lifetime). > > > > > > > > [Ahmad] > > > > > Basically you agree to publish a standard with a security > > > > vulnerability > as long as it is short lived? > I > > > > understand that there is a limited audience on this thread, > > > > but I > guess some carriers may not like that limitation. > > > > > > Also, > > > > > > this attack will be successful only if the Reply from the > > > > > > HAs' do not reach the MN. > > > > > > > > > > [Ahmad] > > > > > I disagree, same comment as above. Is that documented > > > > anywhere?. > > > > > > Finally, I have no issue to publish the draft (as is) as > > > > long as you > document the security vulnerability as per > > > > your statement below. > " So, if the rogue is succesful in > > > > mounting this type of attack, it will > be short lived > > > > (limited to lifetime)" > > > > > > Another alternative: we can add this under section 5.2 > > > > Foreign Agent > Considerations: > > > > > During the registration process, if the foreign > > agent wishes to > > > > > participate in dynamic home agent allocation process > > > > with the home > > > > > domain, > > > > > it MUST have an existing security association with the > > > > home agent > > > > > that has been identified to serve the registration request. > > > > > > > > > > > > Comments/Suggestions? > > > > > > Alpesh > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Henrik Levkowetz > > [mailto:henrik@levkowetz.com] > > > > > Sent: Saturday, > > August 20, 2005 6:42 PM > > > > > To: Ahmad Muhanna > > > > > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung (kleung); > > > > > > > Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Joel M. > > > > > > > Halpern; Mohamed Khalil > > > > > > > Subject: Re: [Mip4] Re: LC review: > > > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > > Hash: SHA1 > > > > > > > > > > > > > > Hi Ahmad, > > > > > > > > > > > > > > Comments below. Milind, Alpesh, Kent - would > > you check > > > > > > > this, please? > > > > > > > > > > > > > > > > > > > > > On 2005-08-20 23:23 Ahmad Muhanna said the > > following: > > > > > > Hi Pete/Henrick, > > > > > > > > > > > > > > > > > > > > > > As chairs for the Mip4 working group, I would like > > > > to get your > > > > feedback on the security issue > > > > identified in my posting dated > > > > > > > > 6/22/205. email attached. In that posting I > > > > identified a security > > > > > > > > issue which could cause a MN to register with multiple > > > > > > HAs. No one > > > > > > > > apparently showed interest in this issue including > > > > the authors. > > > > > > > > However, I believe that the group needs to > > conclude if it > > > > > > > is an issue > > > > > > > > or not before this draft becomes a standard. > > > > > > > > > > > > > > > > This email is not posted to the mip4 list. > > > > > > > > > > > > > > > > Please let me know what you think of this. > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > [snip copy of later mail from Joel Halpern] > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > > > My apologies in advance if this issue has been > > discussed > > > > > > before. If > > > > > > > > that is true, can someone let me know of the > > > > conclusion. Thanks! > > > > > > > > > > > > As per section 5.3.1 Assigned Home Agent > > Considerations, > > > > > > I find the > > > > > > > > following paragraph: > > > > > > > > " > > > > > > > > As per the messaging proposed here, the mobile node (or > > > > > > the foreign > > > > > > > > agent) sends the Registration Request to the > > Requested HA > > > > > > address, > > > > > > > > which is a unicast address. Therefore, this > > document does > > > > > > > not specify > > > > > > > > any new behavior for the case where the HA receives > > > > a > > > subnet directed > > > > broadcast Registration > > > > Request as specified in section > > > 3.8.2.1 of the > > > > > > > > Mobile IPv4 specification [1]. Although the Home Agent > > > > > > field in the > > > > > > > > Registration Request is not a unicast address, the > > > > destination IP > > > > > > > > address is a unicast address. This avoids the problem > > > > > > > associated with > > > > > > > > subnet-directed broadcast destination IP > > address that may > > > > > > result in > > > > > > > > multiple HAs responding. Thus, there is no need > > to deny the > > > > > > > > registration as stated in Mobile IPv4 [1] section > > > > 3.8.3.2." > > > > > > > > > > > > My question here is how by setting the destination > > > > IP > > > address of the > > > > IP packet to the HA unicast > > > > IP address guarantee that MN > > > > > > will avoid > > > > > > > > the possibility of being registered with multiple > > > > HAs? > > > > > > > > > > > > What I have in mind here, is the possibility of > > > > someone > > > listening on > > > > that link and all what > > > > is needed is to include the RRQ in > > > an IP packet > > > > > > > > with the destination IP address is set to a different HA. > > > > In other > > > > words, any HA receives this RRQ can process > > > > this RRQ and send a > > > > > > > > confirmation reply to the MN and MN ends up registering > > > > > > > with multiple > > > > > > > > HAs.? > > > > > > > > > > > > > > This would be the case when an MN registers directly > > > > with a > > > HA, with a co-located care-of address, and does > > > > not include > > > > > > > the requested HA extension. > > > > > > > > > > > > > > I believe you are right that there is a possibility of > > > > a bad > > > guy causing a registration with more than > > one HA in this > > > > > > > case. This would result in the MN receiving registration > > > > > > > replies from multiple HAs, if more than one HA > > would decide > > > > > > > to accept the registration. > > > > > > > > > > > > > > The solution could be to specify that the inclusion of > > > > a > > > Requested HA extension would be a MUST in all cases, > > > > with the > > > > > > > HA being required to verify that the HA address in the > > > > > > > Requested HA extension matches its own address. > > > > > > > > > > > > > > > > > > > > > Henrik > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > > > > > > > > > > > > > > > iD8DBQFDB9vjeVhrtTJkXCMRAhxDAKCAVB5dw98q6fNcHe/r7qmbLd9vJQCg4oLd > > > > > > > 9k8rjzf6t7VTAI/L1rLu8cg= > > > > > > > =Wo9C > > > > > > > -----END PGP SIGNATURE----- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 30 11:45:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8Iz-0006iV-8G; Tue, 30 Aug 2005 11:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8Ix-0006iP-8H for mip4@megatron.ietf.org; Tue, 30 Aug 2005 11:45:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19580 for ; Tue, 30 Aug 2005 11:45:40 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA8KW-0004ar-5G for mip4@ietf.org; Tue, 30 Aug 2005 11:47:20 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7UFhO103678; Tue, 30 Aug 2005 11:43:24 -0400 (EDT) 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: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Date: Tue, 30 Aug 2005 10:45:19 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710A1619C3@zrc2hxm2.corp.nortel.com> Thread-Topic: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Thread-Index: AcWtbvzCYm/dAwbJSm6xxJC6ZjX4AgAB9wuA From: "Ahmad Muhanna" To: "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7c7a0f28a102b9cb6317697abf1cf76 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , Margaret Wasserman , "Kent Leung \(kleung\)" , Mohamed Khalil , Henrik Levkowetz , "Milind Kulkarni \(mkulkarn\)" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Pete, I agree on the example you just mentioned. However, it seems that we agree on the concept but differ on the wording. What about if we come up with something generic to all cases and more specific to others. I will try by adding the following. Please feel free to comment or modify as needed. under section 5.2 Foreign Agent Considerations:=20 During the registration process, if the foreign agent wishes to participate in dynamic home agent allocation process with a home=20 domain, it MUST utilize a mechanism that provides secure transmission of the registration request to the home agent which is identified to=20 server this registration request. In the case where FA relays the registration=20 request directly to the home agent, Foreign Agent must have an existing=20 security association with that home agent. What do you think? Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com]=20 > Sent: Tuesday, August 30, 2005 9:27 AM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: Margaret Wasserman; mip4@ietf.org; Alpesh Patel (alpesh);=20 > Joel M. Halpern; Kent Leung (kleung); Henrik Levkowetz;=20 > Milind Kulkarni (mkulkarn); Khalil, Mohamed [RICH2:2S20:EXCH] > Subject: RE: [Mip4] Re: LC review:=20 > draft-ietf-mip4-dynamic-assignment-05.txt >=20 >=20 >=20 > Hi, Ahmad, >=20 > I think I see your point now, but I still disagree that we=20 > need to mandate FA-HA security association in all cases. =20 > Think about the MIP4 Diameter application where the security=20 > is hop-by-hop: the RRQ arrives at the HA via the AAA server=20 > and the HAs can be configured to accept initial RRQs only=20 > from this interface. I don't think we need to require the=20 > FA/HA MSA in this case; it is provided indirectly via the=20 > hop-by-hop AAA security. >=20 > -Pete >=20 >=20 > Ahmad Muhanna writes: > > Hi Pete, > > Sorry for the late response. Please see comments inline. > >=20 > > Regards, > > Ahmad > >=20 > >=20 > > >=20 > > > Hi, Ahmad, > > >=20 > > > See below. > > >=20 > > > Ahmad Muhanna writes: > > > > Thanks Pete for bringing the discussion to the=20 > mailing list. >=20 > > > Please see comments inline. > > Regards, > > > > Ahmad > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > [back on the mailing list now] > > > > >=20 > > > > > This thread concerns the possibility of having more=20 > than one=20 > > > > > HA create a binding for a given MN. It seems true that the=20 > > > > > RRQ created by the MN, if delivered to multiple HAs, could=20 > > > > > potentially create state on each of those HAs.=20 > > > > =20 > > > > [Ahmad] > > > > Since you agree that this attack is valid and possible and=20 > > > if this > attack is successful with a single MN, then it is=20 > > > possible for almost > every MN requesting Dynamic HA on the=20 > > > compromised FA-HA link. That could > be devastating to the=20 > > > HA domain. I hope you agree. > > >=20 > > > I wouldn't use the word "devastating." If the HAs are=20 > on different=20 > > > subnets, it creates some extra state that has no effect=20 > on the overall >=20 > > > operation of the system and which will timeout after the first=20 > > > Lifetime. > >=20 > > [Ahmad] > > In the case where HA's assign IP addresses from local=20 > pools, this means > a waste of IP addresses. Now, if this=20 > attack is possible for one MN, it > can be possible for many=20 > MN's and probably drain HA resources of IP > addresses. It=20 > could be a real problem. >=20 > > >=20 > > > If the HAs are on the same subnet, however, it will create a=20 > > > competition for the gratuitous/proxy ARP which would=20 > have an effect on >=20 > > > the reliability of the traffic, so I can see your point=20 > of view here. > >=20 > > > > > However, I > > > > > think we are making too much out of the=20 > possibility. An > > > > attacker that has the power to=20 > duplicate packets (changing=20 > > > > > the destination IP address) and drop selected=20 > packets > > >=20 > > > > [Ahmad] > > > > If we think along this line, we probably do not need any=20 > > > security > measures in MIPv4 protocol to start with. On the=20 > > > other hand, why RFC > (3543) mandates the FA to have a=20 > > > security association with the HA to > participate in=20 > > > registration revocation? > > >=20 > > > I am not saying we don't need security, just that we=20 > need to consider=20 > > > the big picture. If you think about the most likely deployment=20 > > > scenarios for this draft, there will be a single AAA=20 > server that is=20 > > > responsible for allocating a home agent address and for=20 > distributing=20 > > > security associations. > > > Inserting requests into a secure AAA infrastructure is a lot=20 > > > harder than inserting a duplicate (destination address=20 > > > modified) packet. > >=20 > > [Ahmad] > > I am not sure about the concept of a single AAA server.=20 > Anyway, you are > basically proving my point here. You just=20 > highlighted that the reason > that we do not need to worry=20 > about this issue when the deployment uses > AAA=20 > infrastructure is that AAA infrastructure is a SECURE one. On=20 > the > other hand, you seem not to agree to make the FA-HA=20 > link a secure one > for the other deployment. Why don't we=20 > agree to make that link secure > too. It is nothing new,=20 > already existing FA and HA most probably support >=20 > registration revocation which requires FA-HA security association. >=20 > > >=20 > > > Even if the Registration Request is sent directly to an=20 > HA, it will=20 > > > most likely be protected by an MN-AAA authentication=20 > extension, and=20 > > > the central AAA server can prevent duplicate sessions. > >=20 > > [Ahmad] > > You are assuming a SINGLE statefull AAA server in this one. >=20 > > >=20 > > > > > can > > > > > pretty much prevent a mobile IP registration from=20 > taking > > place. >=20 > > > > [Ahmad] > > > > Of course, that is true. That is why we need to make sure=20 > > > that we have a > secure solution (protocol) to prevent such=20 > > > attacks. >=20 > > > > >=20 > > > > > Rather, I think we should focus on the correctness of the=20 > > > > > protocol in the absence of attackers:=20 > > > >=20 > > > > [Ahmad] > > > > Is that a MIPv4 WG mandate or just your opinion? > > >=20 > > > Sorry, chair hat off for now. > > >=20 > > > > > there is a requirement > > > > > for a unicast destination address on the packet so=20 > only one > > > > HA will receive it in a normal protocol run. =20 > > > >=20 > > > > [Ahmad] > > > > Thinking of normal protocol run; If all what we are=20 > > > looking for is just > normal protocol run, then why do we=20 > > > have all of these security > associations and extensions in=20 > > > all of the RFCs related to MIPv4 > protocol. >=20 > > > > > I do not think=20 > > > > > we need to add special mechanisms like the infinite/short=20 > > > > > lifetime that is being proposed or the requirement for an=20 > > > > > FA-HA MSA. I think these requirements would unfairly limit=20 > > > > > the deployment possibilities. > > > >=20 > > > > [Ahmad] > > > > I respectfully disagree. If such attack happens, service=20 > > > providers may > not be able to serve their own legitimate=20 > > > customers. It will cost them a > lot of money. >=20 > > > > >=20 > > > > > It seems to me that it should suffice to put in=20 > some text in=20 > > > > > the security considerations about this issue. =20 > > > >=20 > > > > [Ahmad] > > > > If we clearly highlight the security issue and this=20 > > > mailing list has a > consensus, I have no problem at all. >=20 > > > >=20 > > > > > We might also=20 > > > > > consider adding text that says if the MN gets RRPs=20 > from more=20 > > > > > than one HA it must immediately de-register the extra=20 > > > > > unwanted bindings. > > > >=20 > > > > [Ahmad] > > > > Could you please explain to me how this is possible in a=20 > > > case when FA is > present in the call path. Thanks. > > >=20 > > > You are right I think - the FA would drop the extra RRPs=20 > because it=20 > > > would be looking for a response from the unicast HA to=20 > which it sent=20 > > > the message. Of course, if the RRQ was sent to the AAA=20 > infrastructure >=20 > > > ala RFC 4004, then there is no issue. > > >=20 > > > Perhaps what we need is a note in the security=20 > considerations that=20 > > > mentions the possibility of multiple HAs on the same=20 > subnet getting=20 > > > the registration request and independently=20 > authenticating it. This=20 > > > will be possible in some deployments and impossible=20 > (e.g., centralized >=20 > > > AAA server validating MN-AAA auth extension) in others. =20 > If it is=20 > > > possible, then maybe we need to return a successful binding with=20 > > > Lifetime=3D0 which will indicate to the MN that it needs=20 > to immediately > > re-register with the assigned HA. >=20 > > [Ahmad] > > I do not agree that this belongs to the security=20 > consideration section. > IMO it is more serious than that=20 > and it should be considered under the > FA consideration=20 > section. On the other hand, your suggestion (lifetime =3D > 0)=20 > defeats the basic principle of Dynamic HA being established=20 > in a > single round trip registration. If we need to use 2=20 > round trip > registration, I believe what RFC(3344) already=20 > has makes more sense. HA > reject the RRQ with code (136)=20 > Unknown HA Address and inserts its own > unicast IP address=20 > in the HA field of the RRP. Then MN sends RRQ using > the HA=20 > unicast IP address as per the HA address in RRP.=20 > > >=20 > > > -Pete > > >=20 > > >=20 > > > > > -Pete > > > > > > > > > > > > > > > Ahmad Muhanna writes: > > > > > > Aplesh, > > > > > >=20 > > > > > > Comments inline. > > > > > >=20 > > > > > > Regards, > > > > > > Ahmad > > > > > >=20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Alpesh Patel (alpesh) [mailto:alpesh@cisco.com]=20 > > > > > > > Sent: Wednesday, August 24, 2005 8:44 PM > > > > > > > To: Henrik Levkowetz; Muhanna, Ahmad=20 > > > [RICH2:2Q30:EXCH] > > > > Cc: Peter McCann; Margaret=20 > > > Wasserman; Kent Leung (kleung);=20 > > > > > > > Milind Kulkarni (mkulkarn); Joel M. Halpern;=20 > > > Khalil, Mohamed=20 > > > > > > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh) > > > > > > > Subject: RE: [Mip4] Re: LC review:=20 > > > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > >=20 > > > > > > >=20 > > > > > > > Henrik: > > > > > > >=20 > > > > > > > In regards to Ahmad's original comment, we have one=20 > > > > > suggestion: > >=20 > > > > > > > If the rogue node changes the destination address=20 > > > enroute to=20 > > > > > > > the HA and sends the RRQ to multiple HA's, the most=20 > > > that can=20 > > > > > > > go wrong is multiple HA's creating a binding for=20 > > > the MN. > > > >=20 > > > > > > [Ahmad] > > > > > > I believe that is a big deal. It means that multiple=20 > > > > > resources will be > allocated for the same MN,=20 > including IP=20 > > > > > address which is very precious > in MIPv4. It also could=20 > > > > > have impact on billing at the HA. >=20 > > > > > > > The rogue has to first figure out all the HA's=20 > addresses -=20 > > > > > > > this may not be trivial. > > > > > >=20 > > > > > > [Ahmad] > > > > > > Well, I do not want to debate this but the fact it is=20 > > > > > possible then it > is an issue. >=20 > > > > > > >=20 > > > > > > > Also, a good MN implementation will deregister when it=20 > > > > > > > receives multiple Registration Replies (if the rogue=20 > > > > > > > succeeded in doing its trick). So, there is not a=20 > > > > > problem here. >=20 > > > > > > [Ahmad] > > > > > > Where is that documented? Can you please give a=20 > > > reference to this.=20 > > > > > >=20 > > > > > > >=20 > > > > > > > Also, the rogue cannot mount a "store and=20 > replay" attack -=20 > > > > > > > this window of vulnerability is limited only=20 > within the=20 > > > > > > > replay window - otherwise the HA's will reject the=20 > > > > > > > Reigstration Replies anyway. > > > > > >=20 > > > > > > [Ahmad] > > > > > > I agree that this attack is limited to the=20 > replay window.=20 > > > > > However, it is > very simple and can happen. >=20 > > > > > > >=20 > > > > > > > How about adding text to the following effect: > > > > > > >=20 > > > > > > > When requesting dynamic HA assignment, MN SHOULD=20 > > > not set the=20 > > > > > > > lifetime field to infinity (0xffff). If lifetime=20 > > > requested is=20 > > > > > > > infinite, HA MUST set it to a low value and send a=20 > > > > > > > Registration Reply. (This will mitigate the risk of=20 > > > lingering=20 > > > > > > > binding entries at HA's - in case the Registration=20 > > > Reply from=20 > > > > > > > other HAs' are lost). > > > > > >=20 > > > > > > [Ahmad] > > > > > > Let us assume that the MN ends up registering at=20 > multiple=20 > > > > > HA's. As per > the RFC3543 "Registration Revocation", we=20 > > > > > need a security association > between the FA and the HA in=20 > > > > > order to revoke this false binding. On the > other=20 > hand, we=20 > > > > > do not have the same requirement for establishing the >=20 > > > > > binding to start with. Does that make sense?. >=20 > > > > > > >=20 > > > > > > > Subsequent registration requests with the HA=20 > where MN is=20 > > > > > > > anchored can have default behavior. > > > > > > >=20 > > > > > > > So, if the rogue is succesful in mounting this type of=20 > > > > > > > attack, it will be short lived (limited to=20 > > > lifetime). > > > =20 > > > > > > [Ahmad] > > > > > > Basically you agree to publish a standard with a=20 > security=20 > > > > > vulnerability > as long as it is short lived? > I=20 > > > > > understand that there is a limited audience on this thread,=20 > > > > > but I > guess some carriers may not like that=20 > limitation. >=20 > > > > > > Also,=20 > > > > > > > this attack will be successful only if the=20 > Reply from the=20 > > > > > > > HAs' do not reach the MN.=20 > > > > > >=20 > > > > > > [Ahmad] > > > > > > I disagree, same comment as above. Is that documented=20 > > > > > anywhere?. >=20 > > > > > > Finally, I have no issue to publish the draft (as is) as=20 > > > > > long as you > document the security vulnerability as per=20 > > > > > your statement below. > " So, if the rogue is succesful in=20 > > > > > mounting this type of attack, it will > be short lived=20 > > > > > (limited to lifetime)" >=20 > > > > > > Another alternative: we can add this under section 5.2=20 > > > > > Foreign Agent > Considerations:=20 > > > > > > During the registration process, if the foreign=20 > > > agent wishes to > > > > > > participate in dynamic home agent allocation process=20 > > > > > with the home > > > > > > domain,=20 > > > > > > it MUST have an existing security association=20 > with the=20 > > > > > home agent=20 > > > > > > that has been identified to serve the=20 > registration request. > > > > > > >=20 > > > > > > > Comments/Suggestions? > > > > > > > Alpesh=20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Henrik Levkowetz=20 > > > [mailto:henrik@levkowetz.com] > > > > > Sent: Saturday,=20 > > > August 20, 2005 6:42 PM > > > > > To: Ahmad Muhanna > > >=20 > > > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung=20 > (kleung); > > > > > > > Milind Kulkarni (mkulkarn); Alpesh=20 > Patel (alpesh); Joel M. > > > > > > > Halpern; Mohamed=20 > Khalil > > > > > > > Subject: Re: [Mip4] Re: LC review:=20 > > > > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > > >=20 > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > > > Hash: SHA1 > > > > > > > >=20 > > > > > > > > Hi Ahmad, > > > > > > > >=20 > > > > > > > > Comments below. Milind, Alpesh, Kent - would=20 > > > you check > > > > > > > > this, please? > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > On 2005-08-20 23:23 Ahmad Muhanna said the=20 > > > following: > > > > > > Hi Pete/Henrick, > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > As chairs for the Mip4 working group, I would like=20 > > > > > to get your > > > > feedback on the security issue=20 > > > > > identified in my posting dated=20 > > > > > > > > > 6/22/205. email attached. In that posting I=20 > > > > > identified a security=20 > > > > > > > > > issue which could cause a MN to register=20 > with multiple=20 > > > > > > > HAs. No one=20 > > > > > > > > > apparently showed interest in this issue including=20 > > > > > the authors.=20 > > > > > > > > > However, I believe that the group needs to=20 > > > conclude if it=20 > > > > > > > > is an issue > > > > > > > > > or not before this draft becomes a=20 > standard. > > > > > > > >=20 > > > > > > > > > This email is not posted to the mip4 list. > > > > > > > > >=20 > > > > > > > > > Please let me know what you think of this. > > > > > > > > > Thanks! > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > [snip copy of later mail from Joel Halpern] > > > > > > > >=20 > > > > > > > > > Hello all, > > > > > > > > >=20 > > > > > > > > > My apologies in advance if this issue has been=20 > > > discussed=20 > > > > > > > before. If > > > > > > > > > that is true, can someone let me know of the=20 > > > > > conclusion. Thanks! > > > >=20 > > > > > > > > > As per section 5.3.1 Assigned Home Agent=20 > > > Considerations,=20 > > > > > > > I find the > > > > > > > > > following paragraph: > > > > > > > > > " > > > > > > > > > As per the messaging proposed here, the=20 > mobile node (or=20 > > > > > > > the foreign > > > > > > > > > agent) sends the Registration Request to the=20 > > > Requested HA=20 > > > > > > > address,=20 > > > > > > > > > which is a unicast address. Therefore, this=20 > > > document does=20 > > > > > > > > not specify > > > > > > > > > any new behavior for the case where the HA=20 > receives=20 > > > > > a > > > subnet directed > > > > broadcast Registration=20 > > > > > Request as specified in section > > > 3.8.2.1 of=20 > the > > >=20 > > > > > > Mobile IPv4 specification [1]. Although the Home Agent=20 > > > > > > > field in the > > > > > > > > > Registration Request is not a unicast address, the=20 > > > > > destination IP=20 > > > > > > > > > address is a unicast address. This avoids=20 > the problem=20 > > > > > > > > associated with > > > > > > > > > subnet-directed broadcast destination IP=20 > > > address that may=20 > > > > > > > result in > > > > > > > > > multiple HAs responding. Thus, there is no need=20 > > > to deny the=20 > > > > > > > > > registration as stated in Mobile IPv4 [1] section=20 > > > > > 3.8.3.2." > > > >=20 > > > > > > > > > My question here is how by setting the destination=20 > > > > > IP > > > address of the > > > > IP packet to the=20 > HA unicast=20 > > > > > IP address guarantee that MN=20 > > > > > > > will avoid > > > > > > > > > the possibility of being registered with multiple=20 > > > > > HAs? > > > >=20 > > > > > > > > > What I have in mind here, is the possibility of=20 > > > > > someone > > > listening on > > > > that link and all what=20 > > > > > is needed is to include the RRQ in > > > an IP=20 > packet > > >=20 > > > > > > with the destination IP address is set to a different HA.=20 > > > > > In other > > > > words, any HA receives this RRQ=20 > can process=20 > > > > > this RRQ and send a=20 > > > > > > > > > confirmation reply to the MN and MN ends=20 > up registering=20 > > > > > > > > with multiple > > > > > > > > > HAs.? > > > > > > > >=20 > > > > > > > > This would be the case when an MN registers directly=20 > > > > > with a > > > HA, with a co-located care-of=20 > address, and does=20 > > > > > not include=20 > > > > > > > > the requested HA extension. > > > > > > > >=20 > > > > > > > > I believe you are right that there is a=20 > possibility of=20 > > > > > a bad > > > guy causing a registration with more than=20 > > > one HA in this=20 > > > > > > > > case. This would result in the MN receiving=20 > registration=20 > > > > > > > > replies from multiple HAs, if more than one HA=20 > > > would decide=20 > > > > > > > > to accept the registration. > > > > > > > >=20 > > > > > > > > The solution could be to specify that the=20 > inclusion of=20 > > > > > a > > > Requested HA extension would be a MUST in=20 > all cases,=20 > > > > > with the=20 > > > > > > > > HA being required to verify that the HA=20 > address in the=20 > > > > > > > > Requested HA extension matches its own=20 > address. > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Henrik > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > > > > >=20 > > > > > > > >=20 > > > > >=20 > iD8DBQFDB9vjeVhrtTJkXCMRAhxDAKCAVB5dw98q6fNcHe/r7qmbLd9vJQCg4oLd > > > > > > > > 9k8rjzf6t7VTAI/L1rLu8cg=3D > > > > > > > > =3DWo9C > > > > > > > > -----END PGP SIGNATURE----- >=20 >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 30 12:00:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8XM-0001qx-Tr; Tue, 30 Aug 2005 12:00:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8XK-0001pw-7t for mip4@megatron.ietf.org; Tue, 30 Aug 2005 12:00:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20381 for ; Tue, 30 Aug 2005 12:00:31 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA8Yr-0004zE-2D for mip4@ietf.org; Tue, 30 Aug 2005 12:02:12 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 30 Aug 2005 09:00:22 -0700 X-IronPort-AV: i="3.96,154,1122879600"; d="scan'208"; a="208529508:sNHT43401958" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7UFxxp4022125; Tue, 30 Aug 2005 09:00:17 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 08:59:53 -0700 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: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Date: Tue, 30 Aug 2005 08:59:52 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52923E13@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Thread-Index: AcWtbvzCYm/dAwbJSm6xxJC6ZjX4AgAB9wuAAADaUqA= From: "Kent Leung \(kleung\)" To: "Ahmad Muhanna" , "Pete McCann" X-OriginalArrivalTime: 30 Aug 2005 15:59:53.0819 (UTC) FILETIME=[DC479AB0:01C5AD7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2af167865907217f0b49c659e31a77f7 Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , Margaret Wasserman , Mohamed Khalil , "Milind Kulkarni \(mkulkarn\)" , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Ahmad and Pete. I think there there are 2 methods to address the issue, which is arguably unlikely scenario, IMHO. The pros and cons of the solution is restriction of mandatory SA between FA and HA vs. 2 round trips. 1) Use FHAE to protect that FA-HA signaling path. Since not every FA and HA will have an SA, this is a major limiting factor. 2) Either use a short lifetime value for initial registration reply by the HA which mitigates any malicious effort to a few seconds or reject RRQ outright and have MN re-register once more with HA field set. I personally favor one of the choices in option #2. Kent > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Tuesday, August 30, 2005 8:45 AM > To: Pete McCann > Cc: Margaret Wasserman; mip4@ietf.org; Alpesh Patel (alpesh);=20 > Joel M. Halpern; Kent Leung (kleung); Henrik Levkowetz;=20 > Milind Kulkarni (mkulkarn); Mohamed Khalil > Subject: RE: [Mip4] Re: LC review:=20 > draft-ietf-mip4-dynamic-assignment-05.txt >=20 > Hi Pete, >=20 > I agree on the example you just mentioned. However, it seems=20 > that we agree on the concept but differ on the wording. What=20 > about if we come up with something generic to all cases and=20 > more specific to others. I will try by adding the following.=20 > Please feel free to comment or modify as needed. >=20 > under section 5.2 Foreign Agent Considerations:=20 >=20 > During the registration process, if the foreign agent wishes to > participate in dynamic home agent allocation process with a home=20 > domain, it MUST utilize a mechanism that provides secure=20 > transmission >=20 > of the registration request to the home agent which is=20 > identified to=20 > server this registration request. In the case where FA=20 > relays the registration=20 > request directly to the home agent, Foreign Agent must=20 > have an existing=20 > security association with that home agent. >=20 > What do you think? >=20 > Regards, > Ahmad >=20 >=20 > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Tuesday, August 30, 2005 9:27 AM > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > Cc: Margaret Wasserman; mip4@ietf.org; Alpesh Patel=20 > (alpesh); Joel M.=20 > > Halpern; Kent Leung (kleung); Henrik Levkowetz; Milind Kulkarni=20 > > (mkulkarn); Khalil, Mohamed [RICH2:2S20:EXCH] > > Subject: RE: [Mip4] Re: LC review:=20 > > draft-ietf-mip4-dynamic-assignment-05.txt > >=20 > >=20 > >=20 > > Hi, Ahmad, > >=20 > > I think I see your point now, but I still disagree that we need to=20 > > mandate FA-HA security association in all cases. > > Think about the MIP4 Diameter application where the security is=20 > > hop-by-hop: the RRQ arrives at the HA via the AAA server=20 > and the HAs=20 > > can be configured to accept initial RRQs only from this=20 > interface. I=20 > > don't think we need to require the FA/HA MSA in this case; it is=20 > > provided indirectly via the hop-by-hop AAA security. > >=20 > > -Pete > >=20 > >=20 > > Ahmad Muhanna writes: > > > Hi Pete, > > > Sorry for the late response. Please see comments inline. > > > > > > Regards, > > > Ahmad > > > > > > > > > > > > > > Hi, Ahmad, > > > > > > > > See below. > > > > > > > > Ahmad Muhanna writes: > > > > > Thanks Pete for bringing the discussion to the=20 > mailing list. =20 > > > > > Please see comments inline. > > Regards, > > >=20 > Ahmad > > =20 > > > > > > > > > > > Hi, > > > > > > > > [back on the mailing=20 > > list now] > > > > > > > > This thread concerns the=20 > possibility of=20 > > having more than one > > > > HA create a binding for a=20 > given MN. It=20 > > seems true that the > > > > RRQ created by the MN, if=20 > delivered to=20 > > multiple HAs, could > > > > potentially create state on each of=20 > > those HAs. > > > > > > > > > > [Ahmad] > > > > > Since you agree that this attack is valid and=20 > possible and >=20 > > > if this > attack is successful with a single MN, then it is > >=20 > > possible for almost > every MN requesting Dynamic HA on the > >=20 > > compromised FA-HA link. That could > be devastating to the > > HA=20 > > domain. I hope you agree. > > > > > > > > I wouldn't use the word "devastating." If the HAs are on=20 > > different > > subnets, it creates some extra state that=20 > has no effect=20 > > on the overall > > > operation of the system and which=20 > will timeout=20 > > after the first > > Lifetime. > > > > > > [Ahmad] > > > In the case where HA's assign IP addresses from local=20 > pools, this=20 > > means > a waste of IP addresses. Now, if this attack is=20 > possible for=20 > > one MN, it > can be possible for many MN's and probably drain HA=20 > > resources of IP > addresses. It could be a real problem. =20 > > > > > >=20 > > If the HAs are on the same subnet, however, it will create a > >=20 > > competition for the gratuitous/proxy ARP which would have=20 > an effect on =20 > > > > > the reliability of the traffic, so I can see your=20 > point of view=20 > > here. > > > > > > However, I > > > > think we are=20 > making too much=20 > > out of the possibility. An > > > > attacker that has the=20 > power to=20 > > duplicate packets (changing > > > > the destination IP=20 > address) and=20 > > drop selected packets > > > > > > [Ahmad] > > > If we think=20 > > along this line, we probably do not need any > > security =20 > > measures=20 > > in MIPv4 protocol to start with. On the > > other hand, why RFC >=20 > > (3543) mandates the FA to have a > > security association=20 > with the HA=20 > > to > participate in > > registration revocation? > > > > > > > > I am not saying we don't need security, just that we need to=20 > > consider > > the big picture. If you think about the most likely=20 > > deployment > > scenarios for this draft, there will be a=20 > single AAA=20 > > server that is > > responsible for allocating a home agent address=20 > > and for distributing > > security associations. > > > > Inserting requests into a secure AAA infrastructure is=20 > a lot > >=20 > > harder than inserting a duplicate (destination address > >=20 > modified)=20 > > packet. > > > > > > [Ahmad] > > > I am not sure about the concept of a single AAA server.=20 > > Anyway, you are > basically proving my point here. You just=20 > > highlighted that the reason > that we do not need to worry=20 > about this=20 > > issue when the deployment uses > AAA infrastructure is that AAA=20 > > infrastructure is a SECURE one. On the > other hand, you=20 > seem not to=20 > > agree to make the FA-HA link a secure one > for the other=20 > deployment.=20 > > Why don't we agree to make that link secure > too. It is=20 > nothing new,=20 > > already existing FA and HA most probably support > registration=20 > > revocation which requires FA-HA security association. > > > > >=20 > > Even if the Registration Request is sent directly to an HA,=20 > it will >=20 > > > most likely be protected by an MN-AAA authentication=20 > extension, and =20 > > > > the central AAA server can prevent duplicate sessions. > > > > > > [Ahmad] > > > You are assuming a SINGLE statefull AAA server in this=20 > one. > > > =20 > > > > > > can > > > > pretty much prevent a mobile IP registration=20 > > from taking > > place. > > > > [Ahmad] > > > Of=20 > course, that is=20 > > true. That is why we need to make sure > > that we have a =20 > > secure=20 > > solution (protocol) to prevent such > > attacks. > > > =20 > > > > > >=20 > > > Rather, I think we should focus on the correctness of the=20 > > > > >=20 > > protocol in the absence of attackers: > > > > > > > > > > [Ahmad] > > > > > Is that a MIPv4 WG mandate or just your opinion? > > > > > > > > Sorry, chair hat off for now. > > > > > > > > > > there is a requirement > > > > > > for a unicast destination address on the packet=20 > so only one =20 > > > > > > HA will receive it in a normal protocol run. > > > > > > > > > > [Ahmad] > > > > > Thinking of normal protocol run; If all what we are > >=20 > > looking for is just > normal protocol run, then why do we =20 > > > have=20 > > all of these security > associations and extensions in > > all of=20 > > the RFCs related to MIPv4 > protocol. > > > > > I do=20 > not think >=20 > > > > > we need to add special mechanisms like the=20 > infinite/short > > =20 > > > > lifetime that is being proposed or the requirement for=20 > an > > >=20 > > > FA-HA MSA. I think these requirements would unfairly=20 > limit > > >=20 > > > the deployment possibilities. > > > > > > > > > > [Ahmad] > > > > > I respectfully disagree. If such attack happens,=20 > service > >=20 > > providers may > not be able to serve their own legitimate > >=20 > > customers. It will cost them a > lot of money. > > > >=20 > > > > > >=20 > > It seems to me that it should suffice to put in some text=20 > in > > > >=20 > > the security considerations about this issue. > > > > > > > > > > [Ahmad] > > > > > If we clearly highlight the security issue and this > >=20 > > mailing list has a > consensus, I have no problem at all. =20 > > > > > =20 > > > > > > We might also > > > > consider adding text that=20 > says if the=20 > > MN gets RRPs from more > > > > than one HA it must immediately=20 > > de-register the extra > > > > unwanted bindings. > > > > > > > > > > [Ahmad] > > > > > Could you please explain to me how this is possible=20 > in a > >=20 > > case when FA is > present in the call path. Thanks. > > > > > > > > You are right I think - the FA would drop the extra=20 > RRPs because=20 > > it > > would be looking for a response from the unicast HA=20 > to which=20 > > it sent > > the message. Of course, if the RRQ was sent=20 > to the AAA=20 > > infrastructure > > > ala RFC 4004, then there is no issue. > > > > > > > > Perhaps what we need is a note in the security considerations=20 > > that > > mentions the possibility of multiple HAs on the=20 > same subnet=20 > > getting > > the registration request and independently=20 > authenticating=20 > > it. This > > will be possible in some deployments and impossible=20 > > (e.g., centralized > > > AAA server validating MN-AAA auth=20 > > extension) in others. > > If it is > > > > possible, then maybe we need to return a successful=20 > binding with =20 > > > > Lifetime=3D0 which will indicate to the MN that it needs to=20 > > immediately > > re-register with the assigned HA. > >=20 > [Ahmad] > I=20 > > do not agree that this belongs to the security=20 > consideration section. =20 > > > IMO it is more serious than that and it should be=20 > considered under=20 > > the > FA consideration section. On the other hand, your suggestion=20 > > (lifetime =3D > 0) defeats the basic principle of Dynamic HA being=20 > > established in a > single round trip registration. If we=20 > need to use=20 > > 2 round trip > registration, I believe what RFC(3344) already has=20 > > makes more sense. HA > reject the RRQ with code (136) Unknown HA=20 > > Address and inserts its own > unicast IP address in the HA=20 > field of=20 > > the RRP. Then MN sends RRQ using > the HA unicast IP=20 > address as per=20 > > the HA address in RRP. > > > > > > > > -Pete > > > > > > > > > > > > > > -Pete > > > > > > > > > > > > > > > > > > Ahmad Muhanna writes: > > > > > > > Aplesh, > > > > > > > > > > > > > > Comments inline. > > > > > > > > > > > > > > Regards, > > > > > > > Ahmad > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > >=20 > From: Alpesh=20 > > Patel (alpesh) [mailto:alpesh@cisco.com] > > > > > > Sent:=20 > > Wednesday, August 24, 2005 8:44 PM > > > > > > To: Henrik=20 > > Levkowetz; Muhanna, Ahmad > > [RICH2:2Q30:EXCH] > > > >=20 > Cc: Peter=20 > > McCann; Margaret > > Wasserman; Kent Leung (kleung); > > =20 > > > > >=20 > > Milind Kulkarni (mkulkarn); Joel M. Halpern; > > Khalil,=20 > Mohamed > > =20 > > > > > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh) > > > > > >=20 > > Subject: RE: [Mip4] Re: LC review: > > > > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > > > > > > > > > > > > > > > > > > > Henrik: > > > > > > > > > > > > > > > > In regards to Ahmad's original comment, we=20 > have one >=20 > > > > > suggestion: > > > > > > > > If the rogue node=20 > changes the=20 > > destination address > > enroute to > > > > > > the HA and sends=20 > > the RRQ to multiple HA's, the most > > that can > > > > > > go=20 > > wrong is multiple HA's creating a binding for > > the MN. =20 > > > > > =20 > > > > > > > [Ahmad] > > > > > I believe that is a big deal. It=20 > > means that multiple > > > > resources will be >=20 > allocated for the=20 > > same MN, including IP > > > > address which is very=20 > precious > in=20 > > MIPv4. It also could > > > > have impact on billing at=20 > the HA. > >=20 > > > > > > > The rogue has to first figure out all the HA's=20 > addresses - =20 > > > > > > > > this may not be trivial. > > > > > > > > > > > > > > [Ahmad] > > > > > > > Well, I do not want to debate this but the=20 > fact it is >=20 > > > > > possible then it > is an issue. > > > > > > > =20 > > > > > >=20 > > > Also, a good MN implementation will deregister when it >=20 > > > > >=20 > > > receives multiple Registration Replies (if the rogue > >=20 > > > > >=20 > > succeeded in doing its trick). So, there is not a > > > > problem=20 > > here. > > > > > > [Ahmad] > > > > > Where is that=20 > documented?=20 > > Can you please give a > > reference to this. > > > > > > > > > > > > > > > > > > > > > > > Also, the rogue cannot mount a "store and replay"=20 > > attack - > > > > > > this window of vulnerability is=20 > limited only=20 > > within the > > > > > > replay window - otherwise the HA's will=20 > > reject the > > > > > > Reigstration Replies anyway. > > > > > > > > > > > > > > [Ahmad] > > > > > > > I agree that this attack is limited to the=20 > replay window. > > > > > > However, it is > very simple and can happen. > =20 > > > > > =20 > > > > > > > > > > How about adding text to the following effect: > > > > > > > > > > > > > > > > When requesting dynamic HA assignment, MN=20 > SHOULD > >=20 > > not set the > > > > > > lifetime field to infinity (0xffff). If=20 > > lifetime > > requested is > > > > > > infinite, HA MUST=20 > set it to=20 > > a low value and send a > > > > > > Registration Reply.=20 > (This will=20 > > mitigate the risk of > > lingering > > > > > > binding=20 > entries at=20 > > HA's - in case the Registration > > Reply from > > > > =20 > > > other=20 > > HAs' are lost). > > > > > > > > > > > > > > [Ahmad] > > > > > > > Let us assume that the MN ends up registering=20 > at multiple =20 > > > > > > HA's. As per > the RFC3543 "Registration=20 > Revocation", we >=20 > > > > > need a security association > between the FA and=20 > the HA in >=20 > > > > > order to revoke this false binding. On the > other=20 > hand, we >=20 > > > > > do not have the same requirement for establishing=20 > the > > > =20 > > > > binding to start with. Does that make sense?. > > > =20 > > > > > >=20 > > > > > > > Subsequent registration requests with the HA=20 > where MN is =20 > > > > > > > > anchored can have default behavior. > > > > > > > > > > > > > > > > So, if the rogue is succesful in mounting=20 > this type of =20 > > > > > > > > attack, it will be short lived (limited to > >=20 > > lifetime). > > > > > > > > [Ahmad] > > > > > Basically you=20 > > agree to publish a standard with a security > > > >=20 > vulnerability >=20 > > as long as it is short lived? > I > > > > understand=20 > that there is=20 > > a limited audience on this thread, > > > > but I > guess some=20 > > carriers may not like that limitation. > > > > > >=20 > Also, > > > > =20 > > > > this attack will be successful only if the Reply from=20 > the > > >=20 > > > > > HAs' do not reach the MN. > > > > > > > > > > > > > > [Ahmad] > > > > > > > I disagree, same comment as above. Is that=20 > documented >=20 > > > > > anywhere?. > > > > > > Finally, I have no issue=20 > to publish=20 > > the draft (as is) as > > > > long as you > document the security=20 > > vulnerability as per > > > > your statement below. > "=20 > So, if the=20 > > rogue is succesful in > > > > mounting this type of=20 > attack, it will =20 > > > be short lived > > > > (limited to lifetime)" > > > > > >=20 > > Another alternative: we can add this under section 5.2 > > > >=20 > > Foreign Agent > Considerations: > > > > > > > During the registration process, if the foreign=20 > > > > agent wishes to > > > > > > > participate in dynamic home agent=20 > allocation process=20 > > > > > > with the home > > > > > > > domain,=20 > > > > > > > it MUST have an existing security association=20 > > with the > > > > > > home agent=20 > > > > > > > that has been identified to serve the=20 > > registration request. > > > > > > > > > > > > > > > > Comments/Suggestions? > > > > > > > > Alpesh > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From:=20 > > Henrik Levkowetz > > [mailto:henrik@levkowetz.com] > > >=20 > > > Sent:=20 > > Saturday, > > August 20, 2005 6:42 PM > > > > > To:=20 > Ahmad Muhanna =20 > > > > > > > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung=20 > > (kleung); > > > > > > > Milind Kulkarni (mkulkarn); Alpesh Patel=20 > > (alpesh); Joel M. > > > > > > > Halpern; Mohamed Khalil =20 > > > > > =20 > > > > > Subject: Re: [Mip4] Re: LC review: > > > > > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > > > > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > >=20 > > > > >=20 > > Hash: SHA1 > > > > > > > > > > > > > > Hi Ahmad, > >=20 > > > > >=20 > > > > > > > > > > > > Comments below. Milind, Alpesh, Kent - would=20 > > > > you check > > > > > > > > > this, please? > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2005-08-20 23:23 Ahmad Muhanna said the > >=20 > > following: > > > > > > Hi Pete/Henrick, > > > > > > >=20 > > > > > >=20 > > > > > > > > > > > > As chairs for the Mip4 working=20 > group, I would=20 > > like > > > > to get your > > > > feedback on the=20 > security issue >=20 > > > > > identified in my posting dated > > > > > > > > 6/22/205.=20 > > email attached. In that posting I > > > > identified a=20 > security > > =20 > > > > > > > > issue which could cause a MN to register with=20 > multiple >=20 > > > > > > > HAs. No one > > > > > > > > apparently=20 > showed interest=20 > > in this issue including > > > > the authors. > > > > > > > > > > However, I believe that the group needs to > >=20 > > conclude if it > > > > > > > is an issue > > > > > >=20 > > > or not=20 > > before this draft becomes a standard. > > > > > > > > >=20 > > > > >=20 > > > > > This email is not posted to the mip4 list. > > > > > > > > > > > > > > > > > > > > Please let me know what you think of this. > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > [snip copy of later mail from Joel=20 > Halpern] > > > > =20 > > > > > > > > > > > > > Hello all, > > > > > > > > > >=20 > > > > >=20 > > > > My apologies in advance if this issue has been > >=20 > discussed > > =20 > > > > > > before. If > > > > > > > > that is true, can=20 > someone let=20 > > me know of the > > > > conclusion. Thanks! > > > > > > =20 > > > > > >=20 > > > As per section 5.3.1 Assigned Home Agent > >=20 > Considerations, > > =20 > > > > > > I find the > > > > > > > > following paragraph: > > > > > > > > > > " > > > > > > > > > > As per the messaging proposed here, the=20 > mobile node=20 > > (or > > > > > > the foreign > > > > > > > > agent) sends the=20 > > Registration Request to the > > Requested HA > > > > >=20 > > address, =20 > > > > > > > > > > which is a unicast address. Therefore, this > >=20 > > document does > > > > > > > not specify > > > > > > >=20 > > any new=20 > > behavior for the case where the HA receives > > > > a >=20 > > > subnet=20 > > directed > > > > broadcast Registration > > > > Request as=20 > > specified in section > > > 3.8.2.1 of the > > > > > > >=20 > > Mobile=20 > > IPv4 specification [1]. Although the Home Agent > > > > =20 > > > field=20 > > in the > > > > > > > > Registration Request is not a unicast=20 > > address, the > > > > destination IP > > > > > > > >=20 > address is a=20 > > unicast address. This avoids the problem > > > > > > >=20 > associated=20 > > with > > > > > > > > subnet-directed broadcast=20 > destination IP > >=20 > > address that may > > > > > > result in > > > > > > >=20 > > multiple=20 > > HAs responding. Thus, there is no need > > to deny the >=20 > > > > > >=20 > > > > registration as stated in Mobile IPv4 [1] section > > > >=20 > > 3.8.3.2." > > > > > > > > > > > > My question here is how by=20 > > setting the destination > > > > IP > > > address of the =20 > > > > > IP=20 > > packet to the HA unicast > > > > IP address guarantee=20 > that MN > > =20 > > > > > > will avoid > > > > > > > > the possibility of being=20 > > registered with multiple > > > > HAs? > > > > > > > > > > > >=20 > > What I have in mind here, is the possibility of > > > >=20 > someone > >=20 > > > listening on > > > > that link and all what > > > > is=20 > needed is=20 > > to include the RRQ in > > > an IP packet > > > > > > >=20 > > with the=20 > > destination IP address is set to a different HA. > > > > > > In other > > > > words, any HA receives this RRQ can=20 > > process > > > > this RRQ and send a > > > > > > > >=20 > confirmation=20 > > reply to the MN and MN ends up registering > > > > > > > with=20 > > multiple > > > > > > > > HAs.? > > > > > > > > > > > > > > > > > > This would be the case when an MN=20 > registers directly =20 > > > > > > with a > > > HA, with a co-located care-of=20 > address, and does =20 > > > > > > not include > > > > > > > the requested HA extension. > > > > > > > > > > > > > > > > > > I believe you are right that there is a=20 > possibility=20 > > of > > > > a bad > > > guy causing a registration with=20 > more than >=20 > > > one HA in this > > > > > > > case. This would result=20 > in the MN=20 > > receiving registration > > > > > > > replies from=20 > multiple HAs, if=20 > > more than one HA > > would decide > > > > > > > to accept the=20 > > registration. > > > > > > > > > > > > > > > > > > The solution could be to specify that the=20 > inclusion=20 > > of > > > > a > > > Requested HA extension would be a MUST in all=20 > > cases, > > > > with the > > > > > > > HA being=20 > required to verify=20 > > that the HA address in the > > > > > > > Requested HA extension=20 > > matches its own address. > > > > > > > > > > > > > > > > > > > > > > > Henrik > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > >=20 > > > > > =20 > > > > > > > > > > >=20 > > iD8DBQFDB9vjeVhrtTJkXCMRAhxDAKCAVB5dw98q6fNcHe/r7qmbLd9vJQCg4oLd > > > > > > > > > 9k8rjzf6t7VTAI/L1rLu8cg=3D > > > > > > >=20 > =3DWo9C > > =20 > > > > > > > -----END PGP SIGNATURE----- > >=20 > >=20 > >=20 > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 30 12:47:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA9Gr-0007RD-7O; Tue, 30 Aug 2005 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 1EA9Gp-0007Pc-Cz for mip4@megatron.ietf.org; Tue, 30 Aug 2005 12:47:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23153 for ; Tue, 30 Aug 2005 12:47:32 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA9IO-0006N1-IO for mip4@ietf.org; Tue, 30 Aug 2005 12:49:13 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7UGjF129177; Tue, 30 Aug 2005 12:45:16 -0400 (EDT) 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: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Date: Tue, 30 Aug 2005 11:47:11 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710A161B53@zrc2hxm2.corp.nortel.com> Thread-Topic: [Mip4] Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt Thread-Index: AcWtbvzCYm/dAwbJSm6xxJC6ZjX4AgAB9wuAAADaUqAAAdCJsA== From: "Ahmad Muhanna" To: "Kent Leung \(kleung\)" , "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f3de74e534ea82d41273d2b8504db1c Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , mip4@ietf.org, "Alpesh Patel \(alpesh\)" , Margaret Wasserman , Mohamed Khalil , "Milind Kulkarni \(mkulkarn\)" , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Kent, I would recommend keeping both.=20 I mean we could specify that in the case of using one round trip registration for Dynamic HA, an FHAE is needed to protect the RRQ. On the other hand, if FA-HA SA is not available, a two round trip RRQ is required as specified in RFC3344. If we agree on the concept, then we can come up with some wording. Regards, Ahmad > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 > Sent: Tuesday, August 30, 2005 11:00 AM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Pete McCann > Cc: Margaret Wasserman; mip4@ietf.org; Alpesh Patel (alpesh);=20 > Joel M. Halpern; Henrik Levkowetz; Milind Kulkarni=20 > (mkulkarn); Khalil, Mohamed [RICH2:2S20:EXCH] > Subject: RE: [Mip4] Re: LC review:=20 > draft-ietf-mip4-dynamic-assignment-05.txt >=20 >=20 > Hi Ahmad and Pete. >=20 > I think there there are 2 methods to address the issue, which=20 > is arguably unlikely scenario, IMHO. The pros and cons of=20 > the solution is restriction of mandatory SA between FA and HA=20 > vs. 2 round trips. >=20 > 1) Use FHAE to protect that FA-HA signaling path. Since not=20 > every FA and HA will have an SA, this is a major limiting factor. >=20 > 2) Either use a short lifetime value for initial registration=20 > reply by the HA which mitigates any malicious effort to a few=20 > seconds or reject RRQ outright and have MN re-register once=20 > more with HA field set. >=20 > I personally favor one of the choices in option #2. >=20 > Kent >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Tuesday, August 30, 2005 8:45 AM > > To: Pete McCann > > Cc: Margaret Wasserman; mip4@ietf.org; Alpesh Patel (alpesh);=20 > > Joel M. Halpern; Kent Leung (kleung); Henrik Levkowetz;=20 > > Milind Kulkarni (mkulkarn); Mohamed Khalil > > Subject: RE: [Mip4] Re: LC review:=20 > > draft-ietf-mip4-dynamic-assignment-05.txt > >=20 > > Hi Pete, > >=20 > > I agree on the example you just mentioned. However, it seems > > that we agree on the concept but differ on the wording. What=20 > > about if we come up with something generic to all cases and=20 > > more specific to others. I will try by adding the following.=20 > > Please feel free to comment or modify as needed. > >=20 > > under section 5.2 Foreign Agent Considerations: > >=20 > > During the registration process, if the foreign agent wishes to > > participate in dynamic home agent allocation process with a home=20 > > domain, it MUST utilize a mechanism that provides secure > > transmission > >=20 > > of the registration request to the home agent which is > > identified to=20 > > server this registration request. In the case where FA=20 > > relays the registration=20 > > request directly to the home agent, Foreign Agent must=20 > > have an existing=20 > > security association with that home agent. > >=20 > > What do you think? > >=20 > > Regards, > > Ahmad > >=20 > >=20 > > > -----Original Message----- > > > From: Pete McCann [mailto:mccap@lucent.com] > > > Sent: Tuesday, August 30, 2005 9:27 AM > > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > Cc: Margaret Wasserman; mip4@ietf.org; Alpesh Patel > > (alpesh); Joel M. > > > Halpern; Kent Leung (kleung); Henrik Levkowetz; Milind Kulkarni > > > (mkulkarn); Khalil, Mohamed [RICH2:2S20:EXCH] > > > Subject: RE: [Mip4] Re: LC review:=20 > > > draft-ietf-mip4-dynamic-assignment-05.txt > > >=20 > > >=20 > > >=20 > > > Hi, Ahmad, > > >=20 > > > I think I see your point now, but I still disagree that we need to > > > mandate FA-HA security association in all cases. > > > Think about the MIP4 Diameter application where the security is=20 > > > hop-by-hop: the RRQ arrives at the HA via the AAA server=20 > > and the HAs > > > can be configured to accept initial RRQs only from this > > interface. I > > > don't think we need to require the FA/HA MSA in this case; it is > > > provided indirectly via the hop-by-hop AAA security. > > >=20 > > > -Pete > > >=20 > > >=20 > > > Ahmad Muhanna writes: > > > > Hi Pete, > > > > Sorry for the late response. Please see comments inline. > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > > > > > > Hi, Ahmad, > > > > > > > > > > See below. > > > > > > > > > > Ahmad Muhanna writes: > > > > > > Thanks Pete for bringing the discussion to the=20 > > mailing list. > > > > > > Please see comments inline. > > Regards, > > > > > Ahmad > > > > > > > > > > > > > > Hi, > > > > > > > > [back on the mailing > > > list now] > > > > > > > > This thread concerns the > > possibility of > > > having more than one > > > > HA create a binding for a > > given MN. It > > > seems true that the > > > > RRQ created by the MN, if > > delivered to > > > multiple HAs, could > > > > potentially create state on each of > > > those HAs. > > > > > > > > > > > > [Ahmad] > > > > > > Since you agree that this attack is valid and=20 > > possible and > > > > > if this > attack is successful with a single MN, then=20 > it is > > > > > possible for almost > every MN requesting Dynamic HA on the > > > > > compromised FA-HA link. That could > be devastating to=20 > the > > HA=20 > > > domain. I hope you agree. > > > > > > > > > > I wouldn't use the word "devastating." If the HAs are on=20 > > > different > > subnets, it creates some extra state that=20 > > has no effect > > > on the overall > > > operation of the system and which > > will timeout > > > after the first > > Lifetime. > > > > > > > > [Ahmad] > > > > In the case where HA's assign IP addresses from local > > pools, this > > > means > a waste of IP addresses. Now, if this attack is > > possible for > > > one MN, it > can be possible for many MN's and probably drain HA > > > resources of IP > addresses. It could be a real problem. =20 > > > > > > >=20 > > > If the HAs are on the same subnet, however, it will create a > >=20 > > > competition for the gratuitous/proxy ARP which would have=20 > > an effect on > > > > > > the reliability of the traffic, so I can see your > > point of view > > > here. > > > > > > However, I > > > > think we are > > making too much > > > out of the possibility. An > > > > attacker that has the > > power to > > > duplicate packets (changing > > > > the destination IP > > address) and > > > drop selected packets > > > > > > [Ahmad] > > > If we think > > > along this line, we probably do not need any > > security =20 > > > measures=20 > > > in MIPv4 protocol to start with. On the > > other hand,=20 > why RFC >=20 > > > (3543) mandates the FA to have a > > security association=20 > > with the HA > > > to > participate in > > registration revocation? > > > > > > > > > > I am not saying we don't need security, just that we need to > > > consider > > the big picture. If you think about the=20 > most likely=20 > > > deployment > > scenarios for this draft, there will be a=20 > > single AAA > > > server that is > > responsible for allocating a home=20 > agent address > > > and for distributing > > security associations. > > > > > Inserting requests into a secure AAA infrastructure is=20 > > a lot > > > > > harder than inserting a duplicate (destination address > > > > modified) > > > packet. > > > > > > > > [Ahmad] > > > > I am not sure about the concept of a single AAA server. > > > Anyway, you are > basically proving my point here. You just=20 > > > highlighted that the reason > that we do not need to worry=20 > > about this > > > issue when the deployment uses > AAA infrastructure is that AAA > > > infrastructure is a SECURE one. On the > other hand, you=20 > > seem not to > > > agree to make the FA-HA link a secure one > for the other > > deployment. > > > Why don't we agree to make that link secure > too. It is > > nothing new, > > > already existing FA and HA most probably support > registration > > > revocation which requires FA-HA security association. > =20 > > > > >=20 > > > Even if the Registration Request is sent directly to an HA,=20 > > it will > > > > > most likely be protected by an MN-AAA authentication > > extension, and > > > > > the central AAA server can prevent duplicate sessions. > > > > > > > > [Ahmad] > > > > You are assuming a SINGLE statefull AAA server in this > > one. > > > > > > > > > > can > > > > pretty much prevent a mobile IP=20 > registration > > > from taking > > place. > > > > [Ahmad] > > > Of > > course, that is > > > true. That is why we need to make sure > > that we have a > > > secure=20 > > > solution (protocol) to prevent such > > attacks. > > > =20 > > > > > > > > > > > Rather, I think we should focus on the correctness of the=20 > > > > > > > > > protocol in the absence of attackers: > > > > > > > > > > > > [Ahmad] > > > > > > Is that a MIPv4 WG mandate or just your opinion? > > > > > > > > > > Sorry, chair hat off for now. > > > > > > > > > > > > there is a requirement > > > > > > > for a unicast destination address on the packet > > so only one > > > > > > > HA will receive it in a normal protocol run. > > > > > > > > > > > > [Ahmad] > > > > > > Thinking of normal protocol run; If all what we are > > > > > looking for is just > normal protocol run, then why do we =20 > > > > have > > > all of these security > associations and extensions in =20 > > > all of > > > the RFCs related to MIPv4 > protocol. > > > > > I do=20 > > not think > > > > > > > we need to add special mechanisms like the > > infinite/short > > > > > > > lifetime that is being proposed or the requirement for > > an > > > > > > > FA-HA MSA. I think these requirements would unfairly > > limit > > > > > > > the deployment possibilities. > > > > > > > > > > > > [Ahmad] > > > > > > I respectfully disagree. If such attack happens, > > service > > > > > providers may > not be able to serve their own legitimate > > > > > customers. It will cost them a > lot of money. > > > >=20 > > > > > > >=20 > > > It seems to me that it should suffice to put in some text=20 > > in > > > > > > > the security considerations about this issue. > > > > > > > > > > > > [Ahmad] > > > > > > If we clearly highlight the security issue and this > > > > > mailing list has a > consensus, I have no problem at all. =20 > > > > > > =20 > > > > > > > We might also > > > > consider adding text that > > says if the > > > MN gets RRPs from more > > > > than one HA it must immediately > > > de-register the extra > > > > unwanted bindings. > > > > > > > > > > > > [Ahmad] > > > > > > Could you please explain to me how this is possible=20 > > in a > > > > > case when FA is > present in the call path. Thanks. > > > > > > > > > > You are right I think - the FA would drop the extra > > RRPs because > > > it > > would be looking for a response from the unicast HA > > to which > > > it sent > > the message. Of course, if the RRQ was sent > > to the AAA > > > infrastructure > > > ala RFC 4004, then there is no issue. > > > > > > > Perhaps what we need is a note in the security=20 > considerations=20 > > > that > > mentions the possibility of multiple HAs on the=20 > > same subnet > > > getting > > the registration request and independently > > authenticating > > > it. This > > will be possible in some deployments and impossible > > > (e.g., centralized > > > AAA server validating MN-AAA auth=20 > > > extension) in others. > > > If it is > > > > > possible, then maybe we need to return a successful=20 > > binding with > > > > > Lifetime=3D0 which will indicate to the MN that it needs to > > > immediately > > re-register with the assigned HA. > > > > [Ahmad] > I > > > do not agree that this belongs to the security > > consideration section. > > > > IMO it is more serious than that and it should be > > considered under > > > the > FA consideration section. On the other hand, your=20 > suggestion > > > (lifetime =3D > 0) defeats the basic principle of Dynamic HA = being=20 > > > established in a > single round trip registration. If we=20 > > need to use > > > 2 round trip > registration, I believe what RFC(3344) already has > > > makes more sense. HA > reject the RRQ with code (136) Unknown HA=20 > > > Address and inserts its own > unicast IP address in the HA=20 > > field of > > > the RRP. Then MN sends RRQ using > the HA unicast IP > > address as per > > > the HA address in RRP. > > > > > > > > > > -Pete > > > > > > > > > > > > > > > > > -Pete > > > > > > > > > > > > > > > > > > > > > Ahmad Muhanna writes: > > > > > > > > Aplesh, > > > > > > > > > > > > > > > > Comments inline. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Ahmad > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Alpesh > > > Patel (alpesh) [mailto:alpesh@cisco.com] > > > > > > Sent: > > > Wednesday, August 24, 2005 8:44 PM > > > > > > To: Henrik=20 > > > Levkowetz; Muhanna, Ahmad > > [RICH2:2Q30:EXCH] > > > >=20 > > Cc: Peter > > > McCann; Margaret > > Wasserman; Kent Leung (kleung); > > > > > > > > > > > Milind Kulkarni (mkulkarn); Joel M. Halpern; > > Khalil, > > Mohamed > > > > > > > > > [RICH2:2S20:EXCH]; Alpesh Patel (alpesh) > > > > > > > > > Subject: RE: [Mip4] Re: LC review: > > > > > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > Henrik: > > > > > > > > > > > > > > > > > > In regards to Ahmad's original comment, we > > have one > > > > > > > suggestion: > > > > > > > > If the rogue node > > changes the > > > destination address > > enroute to > > > > > > the HA=20 > and sends > > > the RRQ to multiple HA's, the most > > that can > > >=20 > > > > go=20 > > > wrong is multiple HA's creating a binding for > > the MN. =20 > > > > > > > > > > > > > > [Ahmad] > > > > > I believe that is a big deal. It > > > means that multiple > > > > resources will be > > > allocated for the > > > same MN, including IP > > > > address which is very > > precious > in > > > MIPv4. It also could > > > > have impact on billing at > > the HA. > > > > > > > > > > The rogue has to first figure out all the HA's > > addresses - > > > > > > > > > this may not be trivial. > > > > > > > > > > > > > > > > [Ahmad] > > > > > > > > Well, I do not want to debate this but the > > fact it is > > > > > > > possible then it > is an issue. > > > > > > > > > > > > > >=20 > > > > Also, a good MN implementation will deregister when it >=20 > > > > > > > > > > receives multiple Registration Replies (if the rogue > > > > > > > > > > > succeeded in doing its trick). So, there is not a > > >=20 > > problem > > > here. > > > > > > [Ahmad] > > > > > Where is that=20 > > documented? > > > Can you please give a > > reference to this. > > > > > > > > > > > > > > > > > > > > > > > > > > Also, the rogue cannot mount a "store and replay" > > > attack - > > > > > > this window of vulnerability is=20 > > limited only > > > within the > > > > > > replay window - otherwise the HA's will > > > reject the > > > > > > Reigstration Replies anyway. > > > > > > > > > > > > > > > > [Ahmad] > > > > > > > > I agree that this attack is limited to the=20 > > replay window. > > > > > > > However, it is > very simple and can happen. > > > > > > > > > > > > > > > > > > How about adding text to the following effect: > > > > > > > > > > > > > > > > > > When requesting dynamic HA assignment, MN > > SHOULD > > > > > not set the > > > > > > lifetime field to infinity (0xffff). If > > > lifetime > > requested is > > > > > > infinite, HA MUST=20 > > set it to > > > a low value and send a > > > > > > Registration Reply. > > (This will > > > mitigate the risk of > > lingering > > > > > > binding > > entries at > > > HA's - in case the Registration > > Reply from > > > > > > > > other > > > HAs' are lost). > > > > > > > > > > > > > > > > [Ahmad] > > > > > > > > Let us assume that the MN ends up registering > > at multiple > > > > > > > HA's. As per > the RFC3543 "Registration > > Revocation", we > > > > > > > need a security association > between the FA and > > the HA in > > > > > > > order to revoke this false binding. On the > other > > hand, we > > > > > > > do not have the same requirement for establishing > > the > > > > > > > > binding to start with. Does that make sense?. > > > > > > > > > > > > > > > > > > Subsequent registration requests with the HA=20 > > where MN is > > > > > > > > > anchored can have default behavior. > > > > > > > > > > > > > > > > > > So, if the rogue is succesful in mounting > > this type of > > > > > > > > > attack, it will be short lived (limited to > > > > > lifetime). > > > > > > > > [Ahmad] > > > > > Basically you > > > agree to publish a standard with a security > > > >=20 > > vulnerability > > > > as long as it is short lived? > I > > > > understand > > that there is > > > a limited audience on this thread, > > > > but I > guess some > > > carriers may not like that limitation. > > > > > >=20 > > Also, > > > > > > > > > this attack will be successful only if the Reply from > > the > > > > > > > > > HAs' do not reach the MN. > > > > > > > > > > > > > > > > [Ahmad] > > > > > > > > I disagree, same comment as above. Is that > > documented > > > > > > > anywhere?. > > > > > > Finally, I have no issue > > to publish > > > the draft (as is) as > > > > long as you > document=20 > the security > > > vulnerability as per > > > > your statement below. > "=20 > > So, if the > > > rogue is succesful in > > > > mounting this type of > > attack, it will > > > > be short lived > > > > (limited to lifetime)" > > > > > > > > > Another alternative: we can add this under section 5.2 > > > > > > > Foreign Agent > Considerations: > > > > > > > > During the registration process, if the foreign=20 > > > > > agent wishes to > > > > > > > > participate in dynamic home agent=20 > > allocation process > > > > > > > with the home > > > > > > > > domain,=20 > > > > > > > > it MUST have an existing security association=20 > > > with the > > > > > > > home agent=20 > > > > > > > > that has been identified to serve the=20 > > > registration request. > > > > > > > > > > > > > > > > > > Comments/Suggestions? > > > > > > > > > Alpesh > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: > > > Henrik Levkowetz > > [mailto:henrik@levkowetz.com] > > >=20 > > > > Sent: > > > Saturday, > > August 20, 2005 6:42 PM > > > > > To: > > Ahmad Muhanna > > > > > > > > > > Cc: Peter McCann; Margaret Wasserman; Kent Leung > > > (kleung); > > > > > > > Milind Kulkarni (mkulkarn);=20 > Alpesh Patel > > > (alpesh); Joel M. > > > > > > > Halpern; Mohamed Khalil =20 > > > > > > > > > > > > Subject: Re: [Mip4] Re: LC review: > > > > > > > > > > draft-ietf-mip4-dynamic-assignment-05.txt > > > > > > > > > > > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > > > >=20 > > > Hash: SHA1 > > > > > > > > > > > > > > Hi Ahmad, > >=20 > > > > > > > > > > > > > > > > > > > > Comments below. Milind, Alpesh,=20 > Kent - would=20 > > > > > you check > > > > > > > > > > this, please? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2005-08-20 23:23 Ahmad Muhanna said the > > > > > following: > > > > > > Hi Pete/Henrick, > > > > > > >=20 > > > > > > >=20 > > > > > > > > > > > > > As chairs for the Mip4 working > > group, I would > > > like > > > > to get your > > > > feedback on the > > security issue > > > > > > > identified in my posting dated > > > > > > > > 6/22/205. > > > email attached. In that posting I > > > > identified a > > security > > > > > > > > > > > issue which could cause a MN to register with > > multiple > > > > > > > > > HAs. No one > > > > > > > > apparently > > showed interest > > > in this issue including > > > > the authors. > > > > > > > > > > > However, I believe that the group needs to > > > > > conclude if it > > > > > > > is an issue > > > > > >=20 > > > > or not > > > before this draft becomes a standard. > > > > > > > > > > > > > > >=20 > > > > > > This email is not posted to the mip4 list. > > > > > > > > > > > > > > > > > > > > > > Please let me know what you think of=20 > this. > > =20 > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > [snip copy of later mail from Joel=20 > > Halpern] > > > > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > > > > > > > > My apologies in advance if this issue has been > > > > discussed > > > > > > > > > before. If > > > > > > > > that is true, can > > someone let > > > me know of the > > > > conclusion. Thanks! > > > > > > > > > > > > > > > > > As per section 5.3.1 Assigned Home Agent > >=20 > > Considerations, > > > > > > > > > I find the > > > > > > > > following paragraph: > > > > > > > > > > > " > > > > > > > > > > > As per the messaging proposed here, the > > mobile node > > > (or > > > > > > the foreign > > > > > > > > agent) sends the > > > Registration Request to the > > Requested HA > > > > >=20 > > > address, =20 > > > > > > > > > > > which is a unicast address. Therefore, this > > > > > document does > > > > > > > not specify > > > > > > > > > > any new=20 > > > behavior for the case where the HA receives > > > > a >=20 > > > > subnet > > > directed > > > > broadcast Registration > > > > Request as > > > specified in section > > > 3.8.2.1 of the > > > > > > >=20 > > > Mobile=20 > > > IPv4 specification [1]. Although the Home Agent > > > > =20 > > > > field > > > in the > > > > > > > > Registration Request is not a unicast > > > address, the > > > > destination IP > > > > > > > >=20 > > address is a > > > unicast address. This avoids the problem > > > > > > > > > associated > > > with > > > > > > > > subnet-directed broadcast > > destination IP > > > > > address that may > > > > > > result in > > > > > > > > > > multiple=20 > > > HAs responding. Thus, there is no need > > to deny the >=20 > > > > > > >=20 > > > > > registration as stated in Mobile IPv4 [1] section > > > > > > > 3.8.3.2." > > > > > > > > > > > > My question here is how by > > > setting the destination > > > > IP > > > address of the =20 > > > > > > IP > > > packet to the HA unicast > > > > IP address guarantee > > that MN > > > > > > > > > will avoid > > > > > > > > the possibility of being > > > registered with multiple > > > > HAs? > > > > > > >=20 > > > > > > > > > What I have in mind here, is the possibility of > > > >=20 > > someone > > > > > > listening on > > > > that link and all what > > > > is > > needed is > > > to include the RRQ in > > > an IP packet > > > > > > > > > > with the=20 > > > destination IP address is set to a different HA. > > > > > > > In other > > > > words, any HA receives this RRQ can=20 > > > process > > > > this RRQ and send a > > > > > > > >=20 > > confirmation > > > reply to the MN and MN ends up registering > > > > > > > with > > > multiple > > > > > > > > HAs.? > > > > > > > > > > > > > > > > > > > > This would be the case when an MN=20 > > registers directly > > > > > > > with a > > > HA, with a co-located care-of > > address, and does > > > > > > > not include > > > > > > > the requested HA extension. > > > > > > > > > > > > > > > > > > > > I believe you are right that there is a > > possibility > > > of > > > > a bad > > > guy causing a registration with > > more than > > > > > one HA in this > > > > > > > case. This would result > > in the MN > > > receiving registration > > > > > > > replies from > > multiple HAs, if > > > more than one HA > > would decide > > > > > > > to accept the > > > registration. > > > > > > > > > > > > > > > > > > > > The solution could be to specify that the=20 > > inclusion > > > of > > > > a > > > Requested HA extension would be a=20 > MUST in all > > > cases, > > > > with the > > > > > > > HA being=20 > > required to verify > > > that the HA address in the > > > > > > > Requested HA extension > > > matches its own address. > > > > > > > > > > > > > > > > > > > > > > > > Henrik > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > >=20 > > > > > > > > > > > > > > > > > > > > > iD8DBQFDB9vjeVhrtTJkXCMRAhxDAKCAVB5dw98q6fNcHe/r7qmbLd9vJQCg4oLd > > > > > > > > > > 9k8rjzf6t7VTAI/L1rLu8cg=3D > > > > > > > > > =3DWo9C > > > > > > > > > > -----END PGP SIGNATURE----- > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 30 14:40:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAB2E-0000OX-S5; Tue, 30 Aug 2005 14:40:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAB2C-0000OP-Rv for mip4@megatron.ietf.org; Tue, 30 Aug 2005 14:40:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29816 for ; Tue, 30 Aug 2005 14:40:35 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAB3n-0001OO-ID for mip4@ietf.org; Tue, 30 Aug 2005 14:42:16 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 30 Aug 2005 11:40:25 -0700 X-IronPort-AV: i="3.96,154,1122879600"; d="scan'208"; a="337206208:sNHT33837836" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7UIeFQQ027820; Tue, 30 Aug 2005 11:40:20 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 11:40:21 -0700 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: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt Date: Tue, 30 Aug 2005 11:40:20 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52923F11@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt Thread-Index: AcWr0cxTCNIjdYI1TGmUazSE/du3WQBvg3dw From: "Kent Leung \(kleung\)" To: , "Jari Arkko" X-OriginalArrivalTime: 30 Aug 2005 18:40:21.0658 (UTC) FILETIME=[46EB3FA0:01C5AD92] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I agree with Sami. 1) x-MIP solution should go forth as it directly addressed the problem statement, RFC 4093. 2) Now, there is the effort to provide a solution that can avoid the extra tunnel overhead on the airlink and layering on the MN for data traffic. For #2, assuming this is the new requirement/problem statement to support VPN traversal, one possible solution is MOBIKE while another is x-MIP with optimization. MOBIKE requires changes to VPN GW and can't work with FAs. X-MIP w/optimization don't have these restrictions. It's worth defining the requirements of the long-term solution. Kent=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Sami Vaarala > Sent: Sunday, August 28, 2005 7:30 AM > To: Jari Arkko > Cc: mip4@ietf.org > Subject: Re: [Mip4] review of=20 > draft-devarapalli-mip4-mobike-connectivity-00.txt >=20 > Hi, >=20 > >> The problem I see w.r.t. to using IKEv2/MOBIKE is that it=20 > does not,=20 > >> alone, match the current problem statement. The=20 > assumption made in=20 > >> draft-ietf-mip4-vpn-problem-statement-03.txt is that existing=20 > >> deployed VPN infrastructure should be used (see e.g. > >> Section 5.1). > >> =20 > >> > > Yes. I still view that as the main and most urgent use case, so the=20 > > problem statement is OK. However, I believe we are also at=20 > a situation=20 > > where we can see future deployments (particularly those based on > > IKEv2) start to do new things. I don't see a problem with=20 > pursuing two=20 > > tracks simultaneously. Its not like they would be two redundant=20 > > solutions, its more like points in different stages of evolution. >=20 > Right, I agree. And I agree we can pursue two tracks at the=20 > same time. However, given that these two tracks have so much=20 > in common, it doesn't seem useful to specify them in two=20 > seemginly separate specifications. Given the way the=20 > solutions are specified, x-MIP + IKEv1 vs. MOBIKE + IKEv2 are=20 > just two different access modes. > The overall approach, the intranet detection, etc, are all same. >=20 > But stepping back a little, if we relax either the "existing VPN" > or "minimal MIPv4 changes" assumptions, we get a number of=20 > different solutions. For instance: >=20 > - A *very* straightforward way of getting mobility without x-MIP > (and just IKEv1+IPsec) is just to use the "implicit ESP update" > mechanism already deployed by some vendors. I believe a similar > mechanism is used in the MIPv6 + IPsec draft. This is rather > simple to implement and does away with the x-MIP overhead > completely. >=20 > - We could specify IKEv1 mobility extensions to allow more or less > the same effect albeit with more vendor effort. Vijay's draft's > Appendix has a suggestion for this. >=20 > - Looking at x-MIP, we can also eliminate x-MIP overhead=20 > completely > by defining an optimization extension between the MN=20 > and the x-HA. > This approach retains FA support, while eliminating all x-MIP > overhead in non-FA scenarios. The rough approach was=20 > described in > draft-vaarala-mip4-optudp-00 [*]. >=20 > - A very important concern in practice is managing the keys and > authentication in a dual MIP or MOBIKE+MIP solution. Should we > define something to make this easier? >=20 > At least to me it's not at all clear which avenue would=20 > produce the best possible solution - minimal changes, maximum=20 > impact, and maximum generality (especially). So going past=20 > absolute minimum changes (dual > MIP) needs more thought on what criteria we should apply to solutions. >=20 > >> If we decide that there is no deployment issue w.r.t. MIPv4 and=20 > >> already deployed VPNs, we should IMO take a larger view of=20 > improving=20 > >> MIPv4/VPN coexistence. Minimizing overlap between the two=20 > mechanisms=20 > >> would give a much better solution. For instance, there is=20 > room for=20 > >> improvement in MIPv4 packet overhead, MIPv4/VPN compression=20 > >> interactions, and integrated MIPv4/VPN packet authentication. > >> > > I believe we will eventually get there. Probably step by step,=20 > > however. I view Vijay's draft one of those steps... eliminating one=20 > > unnecessary level in the stack. > > Or are you arguing that we should spend more time thinking=20 > what to do,=20 > > if we discard the no-changes-at-all assumption? >=20 > I think we should work on defining what the longer term goal is w.r.t. > IPsec and MIPv4 integration. I don't think it's clear people=20 > agree what that goal should be. And proposing, discussing,=20 > and comparing solutions beyond dual MIP is difficult at the=20 > moment, because we have nothing to compare them against. >=20 > As far as dual MIP is concerned, going forward with it would=20 > be useful as a baseline and as documenting existing practice=20 > (as far as I know, some people are deploying it, although I'm=20 > not sure at what scale). > But if we agree on working on a better long-term solution,=20 > that would of course be preferable to working on a limited=20 > dual MIP solution. >=20 > Best, >=20 > -Sami >=20 > [*] > http://users.tkk.fi/~svaarala/publications/draft-vaarala-mip4- > optudp-00.txt >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 30 15:03:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABOH-00070P-44; Tue, 30 Aug 2005 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 1EABOF-000700-5a for mip4@megatron.ietf.org; Tue, 30 Aug 2005 15:03:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00726 for ; Tue, 30 Aug 2005 15:03:21 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EABPq-0001v4-0u for mip4@ietf.org; Tue, 30 Aug 2005 15:05:02 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j7UITU123867; Tue, 30 Aug 2005 11:29:30 -0700 X-mProtect: <200508301829> 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 smtpd7ZEJxB; Tue, 30 Aug 2005 11:29:29 PDT Message-ID: <4314AD19.9090702@iprg.nokia.com> Date: Tue, 30 Aug 2005 12:01:45 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt References: <2979E38DD6FC6544B789C8DAD7BAFC52923F11@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52923F11@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit Cc: sami.vaarala@iki.fi, Jari Arkko , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Kent Leung (kleung) wrote: > I agree with Sami. > > 1) x-MIP solution should go forth as it directly addressed the problem > statement, RFC 4093. > > 2) Now, there is the effort to provide a solution that can avoid the > extra tunnel overhead on the airlink and layering on the MN for data > traffic. which solution? draft-devarapalli-mip4-mobike-connectivity-00.txt is definitely not targeting this. it is only addressing a scenario where IKEv2 IPsec VPNs with MOBIKE support are used. it is doing this because there are some immediate use cases. however, I would support an effort to define requirements for a more optimal solution involving MIPv4 and *any kind* of VPN gateway and encourage MIPv4 WG to look into an optimal solution. Vijay > For #2, assuming this is the new requirement/problem statement to > support VPN traversal, one possible solution is MOBIKE while another is > x-MIP with optimization. MOBIKE requires changes to VPN GW and can't > work with FAs. X-MIP w/optimization don't have these restrictions. > It's worth defining the requirements of the long-term solution. > > Kent > > >>-----Original Message----- >>From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On >>Behalf Of Sami Vaarala >>Sent: Sunday, August 28, 2005 7:30 AM >>To: Jari Arkko >>Cc: mip4@ietf.org >>Subject: Re: [Mip4] review of >>draft-devarapalli-mip4-mobike-connectivity-00.txt >> >>Hi, >> >> >>>>The problem I see w.r.t. to using IKEv2/MOBIKE is that it >> >>does not, >> >>>>alone, match the current problem statement. The >> >>assumption made in >> >>>>draft-ietf-mip4-vpn-problem-statement-03.txt is that existing >>>>deployed VPN infrastructure should be used (see e.g. >>>>Section 5.1). >>>> >>>> >>> >>>Yes. I still view that as the main and most urgent use case, so the >>>problem statement is OK. However, I believe we are also at >> >>a situation >> >>>where we can see future deployments (particularly those based on >>>IKEv2) start to do new things. I don't see a problem with >> >>pursuing two >> >>>tracks simultaneously. Its not like they would be two redundant >>>solutions, its more like points in different stages of evolution. >> >>Right, I agree. And I agree we can pursue two tracks at the >>same time. However, given that these two tracks have so much >>in common, it doesn't seem useful to specify them in two >>seemginly separate specifications. Given the way the >>solutions are specified, x-MIP + IKEv1 vs. MOBIKE + IKEv2 are >>just two different access modes. >>The overall approach, the intranet detection, etc, are all same. >> >>But stepping back a little, if we relax either the "existing VPN" >>or "minimal MIPv4 changes" assumptions, we get a number of >>different solutions. For instance: >> >> - A *very* straightforward way of getting mobility without x-MIP >> (and just IKEv1+IPsec) is just to use the "implicit ESP update" >> mechanism already deployed by some vendors. I believe a similar >> mechanism is used in the MIPv6 + IPsec draft. This is rather >> simple to implement and does away with the x-MIP overhead >> completely. >> >> - We could specify IKEv1 mobility extensions to allow more or less >> the same effect albeit with more vendor effort. Vijay's draft's >> Appendix has a suggestion for this. >> >> - Looking at x-MIP, we can also eliminate x-MIP overhead >>completely >> by defining an optimization extension between the MN >>and the x-HA. >> This approach retains FA support, while eliminating all x-MIP >> overhead in non-FA scenarios. The rough approach was >>described in >> draft-vaarala-mip4-optudp-00 [*]. >> >> - A very important concern in practice is managing the keys and >> authentication in a dual MIP or MOBIKE+MIP solution. Should we >> define something to make this easier? >> >>At least to me it's not at all clear which avenue would >>produce the best possible solution - minimal changes, maximum >>impact, and maximum generality (especially). So going past >>absolute minimum changes (dual >>MIP) needs more thought on what criteria we should apply to solutions. >> >> >>>>If we decide that there is no deployment issue w.r.t. MIPv4 and >>>>already deployed VPNs, we should IMO take a larger view of >> >>improving >> >>>>MIPv4/VPN coexistence. Minimizing overlap between the two >> >>mechanisms >> >>>>would give a much better solution. For instance, there is >> >>room for >> >>>>improvement in MIPv4 packet overhead, MIPv4/VPN compression >>>>interactions, and integrated MIPv4/VPN packet authentication. >>>> >>> >>>I believe we will eventually get there. Probably step by step, >>>however. I view Vijay's draft one of those steps... eliminating one >>>unnecessary level in the stack. >>>Or are you arguing that we should spend more time thinking >> >>what to do, >> >>>if we discard the no-changes-at-all assumption? >> >>I think we should work on defining what the longer term goal is w.r.t. >>IPsec and MIPv4 integration. I don't think it's clear people >>agree what that goal should be. And proposing, discussing, >>and comparing solutions beyond dual MIP is difficult at the >>moment, because we have nothing to compare them against. >> >>As far as dual MIP is concerned, going forward with it would >>be useful as a baseline and as documenting existing practice >>(as far as I know, some people are deploying it, although I'm >>not sure at what scale). >>But if we agree on working on a better long-term solution, >>that would of course be preferable to working on a limited >>dual MIP solution. >> >>Best, >> >>-Sami >> >>[*] >>http://users.tkk.fi/~svaarala/publications/draft-vaarala-mip4- >>optudp-00.txt >> >> >>-- >>Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>Supplemental site: http://www.mip4.org/ >> > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 30 15:24:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABj4-0005q9-Eb; Tue, 30 Aug 2005 15:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABj2-0005pq-3G for mip4@megatron.ietf.org; Tue, 30 Aug 2005 15:24:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03066 for ; Tue, 30 Aug 2005 15:24:50 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EABkc-0002b3-DK for mip4@ietf.org; Tue, 30 Aug 2005 15:26:31 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 30 Aug 2005 12:24:42 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7UJNqR0020860; Tue, 30 Aug 2005 12:24:33 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 12:24:35 -0700 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: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt Date: Tue, 30 Aug 2005 12:24:34 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52923F4C@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt Thread-Index: AcWtlYHMKT16lPExQ9qJrvmK0zTX+wAAK4uA From: "Kent Leung \(kleung\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 30 Aug 2005 19:24:35.0385 (UTC) FILETIME=[74A9DA90:01C5AD98] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: sami.vaarala@iki.fi, Jari Arkko , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org > which solution? draft-devarapalli-mip4-mobike-connectivity-00.txt > is definitely not targeting this. it is only addressing a=20 > scenario where IKEv2 IPsec VPNs with MOBIKE support are used.=20 > it is doing this because there are some immediate use cases. >=20 OK. I read the following and interpreted the draft proposed a solution that addressed the identified shortcomings of x-MIP draft. draft-devarapalli-mip4-mobike-connectivity-00.txt: "There has been some work done on using Mobile IPv4 and IPsec VPNs to provide roaming and secure connectivity to an enterprise [10]. The solution described in [10] was designed with certain restrictions, including requiring no modifications to the VPN gateways and involves the use of two layers of MIPv4, with one Home Agent inside the intranet and one in the Internet or in the DMZ before the VPN gateway. The per-packet overhead is very high in this solution. It is also challenging to implement and have two instances of MIPv4 active at the same time on a mobile node.=20 This document describes an alternate solution that does not require two layers of MIPv4. " Then later, I see your clarification stated later. OK. "The solution described in this document uses Mobile IPv4 when the mobile node is on the trusted network and MOBIKE capable IPsec VPNs when mobile node is on the untrusted network. " =20 > however, I would support an effort to define requirements for=20 > a more optimal solution involving MIPv4 and *any kind* of VPN=20 > gateway and encourage MIPv4 WG to look into an optimal solution. >=20 OK. Should this draft be under the scope of such general solution? A IKEv2/MOBIKE VPN GW is a specific type of "any kind" of VPN GW, right? :) =20 Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/