From mip4-bounces@ietf.org Wed Jun 01 07:04:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdR14-0002tO-3j; Wed, 01 Jun 2005 07:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdR13-0002tJ-0A for mip4@megatron.ietf.org; Wed, 01 Jun 2005 07:04:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03853 for ; Wed, 1 Jun 2005 07:04:01 -0400 (EDT) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdRKq-00045P-4X for mip4@ietf.org; Wed, 01 Jun 2005 07:24:33 -0400 Received: from celerio.ucdavis.edu (celerio.ucdavis.edu [169.237.104.178]) by warsaw.ucdavis.edu (8.13.3/8.13.1/it-defang-5.3.0) with ESMTP id j51B41tQ008612 for ; Wed, 1 Jun 2005 04:04:01 -0700 (PDT) Received: from celerio.ucdavis.edu (localhost [127.0.0.1]) by celerio.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j51B41xQ001422 for ; Wed, 1 Jun 2005 04:04:01 -0700 (PDT) Received: (from www@localhost) by celerio.ucdavis.edu (8.12.10/8.12.9/Submit) id j51B413x001421; Wed, 1 Jun 2005 04:04:01 -0700 (PDT) Date: Wed, 1 Jun 2005 04:04:01 -0700 (PDT) Message-Id: <200506011104.j51B413x001421@celerio.ucdavis.edu> To: mip4@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [Mip4] Deadline extended: JSAC-MRNM 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 PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY The deadline is extened until June 5th. http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 5, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com -- 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 Jun 02 12:21:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsRR-0004qv-SN; Thu, 02 Jun 2005 12:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUlf-0002j7-5z; Wed, 01 Jun 2005 11:04:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24585; Wed, 1 Jun 2005 11:04:24 -0400 (EDT) Received: from none.cs.umass.edu ([128.119.241.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdV5U-0008P8-DF; Wed, 01 Jun 2005 11:24:57 -0400 Received: from [128.119.245.90] (tanam.cs.umass.edu [128.119.245.90]) by none.cs.umass.edu (8.12.8/8.12.5) with ESMTP id j51F4AUf024775; Wed, 1 Jun 2005 11:04:10 -0400 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1e00328706d92c0f43b6069fe4c282cc@cs.umass.edu> Content-Transfer-Encoding: quoted-printable From: Deepak Ganesan Date: Wed, 1 Jun 2005 11:04:07 -0400 To: Deepak Ganesan X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 02 Jun 2005 12:21:08 -0400 Cc: Subject: [Mip4] DIAL M-POMC 2005: Workshop on Foundation of Mobile Computing Final CFP 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 Our apologies if you receive multiple copies of this CFP. =A0FINAL CALL FOR PAPERS - DIAL M-POMC 2005 The Third ACM/SIGMOBILE International Workshop on Foundation of Mobile Computing September 2, 2005 - Cologne, Germany (co-located with ACM MobiCom 2005) http://gridnet.nec-labs.com/dialm =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0IMP= ORTANT DATES Paper submission due: June 5, 2005 (New=20 Extended Deadline) Notification of acceptance: July 5, 2005 Camera-ready version due: July 20, 2005 DIAL M-POMC is devoted to algorithms and modeling in the context of mobile and wireless computing and communications. It is intended to be a lively meeting, covering many of the algorithmic aspects of this field ranging from operations research to radio engineering problems. In particular, it aims at fostering the cooperation among practitioners and theoreticians of the field. This workshop is a merging of two workshops: DIAL M (Discrete Algorithms and Methods for Mobile Computing and Communications), which was held annually from 1997 to 2004 as a workshop in conjunction with ACM/SIGMOBILE MobiCom; and POMC (Principles of Mobile Computing), which was held in 2001 in conjunction with the ACM/SIGACT and SIGOPS Symposium on Principles of Distributed Computing (PODC), and in 2002 in conjunction with the ACM International Symposium on Distributed Computing (DISC). DIAL M-POMC 2005 will be composed of invited and peer-reviewed contributed talks. SCOPE: Mobile computing and communications devices will have an enormous impact on our lifestyle over the next several decades. The mobility of distributed computing components raises a number of interesting, and difficult, algorithmic issues. This workshop is devoted to algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to foster cooperation among researchers in mobile computing and researchers in discrete and distributed algorithms. PAPERS: All submitted papers will be rigorously reviewed by technical program committee members. Accepted papers will be published in the workshop proceedings. Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. Contributions are solicited in all areas related to mobile and wireless computing and communications where discrete algorithms and methods are utilized. Specific topics include, but are not limited to: - Channel assignment and management - Cryptography and security - Handover (handoff) - Routing, multicast and broadcast - Scheduling - Synchronization - Selfish behavior and cooperation - Energy saving methods and protocols - Ad hoc and sensor networking - Localization and location tracking - Error correcting codes - Protocol optimization - Dynamic networks - Cooperation enforcement - Dynamic graph algorithms - Modeling SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically (see the conference web page for details). Authors should prepare an electronic version of their full paper. Papers must not exceed 11 pages (US Letter size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 11 points. Program Co-Chairs Suman Banerjee Univ. of Wisconsin, Madison suman@cs.wisc.edu Samrat Ganguly NEC Labs samrat@nec-labs.com Publicity Chair Deepak Ganesan Univ. of Massachusetts dganesan@cs.umass.edu Steering Committee Ian Akyildiz (Georgia Tech) Maurizio Bonuccelli (U. of Pisa) Afonso Ferreira (INRIA) Errol Lloyd (U. of Delaware) Nancy Lynch (MIT) Andre Schiper (EPFL) Arunabha Sen (ASU) Nitin Vaidya (UIUC) Program Committee (partial list) Stefano Basagni(Northeastern University) basagni@ece.neu.edu Stephan Eidenbenz (Los Alamos National Labs) eidenben@lanl.gov Andras Farago (UT Dallas) farago@utdallas.edu Kamal Jain (Microsoft Research) kamalj@microsoft.com Li (Erran) Li (Bell Labs) erranlli@dnrc.bell-labs.com Archan Misra (IBM TJ Watson Research Center) archan@us.ibm.com Vishal Misra (Columbia University) misra@cs.columbia.edu S. Muthukrishnan (Rutgers) muthu@cs.rutgers.edu Dina Papagiannaki (Intel Research, Cambridge)=20 dina.papagiannaki@intel.com Cynthia Phillips (Sandia National Labs) caphill@sandia.gov Chiara Petrioli (University of Roma) petrioli@di.uniroma1.it Lili Qiu (University of Texas Austin) lili@cs.utexas.edu Rajmohan Rajaraman (Northeastern University) rraj@ccs.neu.edu Raghupathy Sivakumar (Georgia Institute of Technology)=20 siva@ece.gatech.edu Aravind Srinivasan (University of Maryland) srin@cs.umd.edu Martha Steenstrup (Stow Research) steenie@rcn.com Subhash Suri (University of California Santa Barbara) suri@cs.ucsb.edu -- 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 Jun 08 08:36:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfzni-0002er-DN; Wed, 08 Jun 2005 08:36:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Df9P5-0004J3-6e; Mon, 06 Jun 2005 00:39:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28350; Mon, 6 Jun 2005 00:39:56 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Df9jr-0006na-5F; Mon, 06 Jun 2005 01:01:27 -0400 Received: from ececs.uc.edu ([129.137.4.130] helo=mail.ececs.uc.edu) by mx2.foretec.com with esmtp (Exim 4.24) id 1Df9P4-0008Qx-Na; Mon, 06 Jun 2005 00:39:58 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.ececs.uc.edu (Postfix) with ESMTP id 3178ED15; Sun, 5 Jun 2005 16:24:17 -0400 (EDT) Received: from mail.ececs.uc.edu ([127.0.0.1]) by localhost (mail.ececs.uc.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20157-02; Sun, 5 Jun 2005 16:23:56 -0400 (EDT) Received: from ececsqzeng (ececs-qzeng.rhod.uc.edu [10.63.10.63]) by mail.ececs.uc.edu (Postfix) with SMTP id B6EA6D23; Sun, 5 Jun 2005 16:22:00 -0400 (EDT) Message-ID: <039201c56a0c$7f9b4080$3f0a3f0a@ececsqzeng> From: "Qing-An Zeng" To: "Qing-An Zeng" Date: Sun, 5 Jun 2005 16:22:00 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: amavisd-new at ececs.uc.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 X-Mailman-Approved-At: Wed, 08 Jun 2005 08:36:53 -0400 Cc: Subject: [Mip4] Call for Papers: IEEE MHWMN'05 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="===============0178448824==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0178448824== Content-Type: multipart/alternative; boundary="----=_NextPart_000_038B_01C569EA.B3656E80" This is a multi-part message in MIME format. ------=_NextPart_000_038B_01C569EA.B3656E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please accept our apologies if you receive this announcements from = multiple sources. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 First Call for Papers: IEEE International Workshop on Heterogeneous Multi-Hop Wireless and = Mobile Networks 2005 (IEEE MHWMN'05) =20 http://www.ececs.uc.edu/~qzeng/MHWMN2005/CFP.html=20 =20 to be held in conjunction with IEEE MASS 2005. Washington DC, USA, November 7-11, 2005. =20 AIM and SCOPE:=20 -------------------------- The traditional centralized wireless and mobile networks are based on = single-hop architecture and rely on the existing fixed infrastructure = such as base stations or access points. The proliferation and deployment = of radio access networks such as Wireless WANs, Wireless LANs, and = Wireless PANs with distinguishing characteristics of data rate, coverage = range, power, mobility, and prices will clearly lead to a need for = seamless and ubiquitous access across these various networks. Such an = integrated heterogeneous environment enables a user to access a = particular network depending upon the application needs and the types of = radio access networks (RANs) available (e.g., cellular network, ad hoc, = WLAN, WPAN etc). The heterogeneous multi-hop wireless and mobile = networks, on the other hand, provide unlimited mobility and greater = flexibility but introduce a number of challenges due to dynamic network = topology. The design of efficient and scalable protocols for existing = multi-hop wireless and mobile networks such as wireless and mobile ad = hoc networks continue to pose challenges at all the layers of networking = stack. Therefore, it is necessary to investigate a global heterogeneous = architecture and services that together provide seamless integration of = single-hop networks (e.g., cellular, WLAN, WWAN) and multi-hop mobile ad = hoc networks.=20 =20 The aim of this workshop is to bring together practitioners and = researchers from both academia and industry in order to have a forum for = discussion and technical presentations on the latest research and future = research directions in heterogeneous multi-hop wireless and mobile = networks. We are seeking original and previously unpublished research = papers addressing theoretical and application issues in heterogeneous = multi-hop wireless mobile networks.=20 =20 TOPICS:=20 ------------- Topics of interest include, but are not limited to, the following areas: - Multi-hop architectures and protocols for resource management=20 - Quality of services (QoS) delivery in MHWMN=20 - Robust and scalable routing protocols for MHWMN=20 - MAC protocols for MHWMN=20 - Self-configuration and synchronization for MHWMN=20 - Security issues in MHWMN=20 - Topology control and management for MHWMN=20 - Mobility models and location management in MHWMN=20 - Cross-layer design and interactions for MHWMN=20 - Modeling and performance evaluation for MHWMN=20 - Algorithms for localization and signal processing in MHWMN=20 - Implementation testbeds for MHWMN=20 - Operating systems and middleware for MHWMN=20 =20 SUBMISSIONS:=20 ------------------------ Submissions will be judged on correctness, originality, technical = strength, significance and quality of presentation. The manuscript must = follow IEEE two-column format with single-spaced, ten-point font in the = text. The maximum manuscript length is eight (8) pages. Authors are = requested to submit their papers (PDF format), contact addresses, = telephone number, fax number, and e-mail addresses (text format) to the = co-chairs Qing-An Zeng (qzeng@ececs.uc.edu) and Mieso Denko = (denko@cis.uoguelph.ca) by July 1, 2005.=20 =20 Note: Some selected high quality papers from the workshop will be = published at JPCC (Journal of Pervasive Computing and Communications) = Special Issue on "Key Technologies and Applications of Wireless Sensor = and Body-area Networks". Selected authors will be invited to submit = extended versions of their papers for publication in the special issue =20 IMPORTANT DATES: -------------------------------- Paper submission: July 1, 2005 Notification of acceptance: August 5, 2005=20 Camera-ready papers: August 26, 2005 =20 WORKSHOP GENERAL CHAIR: ------------------------------------------------ Anup Kumar Computer Engineering and Computer Science Department University of Louisville, KY 40292, USA Email: ak@louisville.edu =20 =20 WORKSHOP CO-CHAIRS:=20 --------------------------------------- Qing-An Zeng Department of Electrical & Computer Engineering=20 and Computer Science University of Cincinnati Cincinnati, OH 45221-0030, USA Email: qzeng@ececs.uc.edu =20 =20 Mieso Denko Department of Computing and Information Science University of Guelph N1G 2W1, Ontario, Canada Email: denko@cis.uoguelph.ca =20 PUBLICITY CHAIR: ---------------------------- Kui Wu Department of Computer Science University of Victoria V8W 3P6, British Columbia, Canada=20 Email: wkui@cs.uvic.ca =20 =20 PROGRAM COMMITTEE: -------------------------------------- Boukerche, Azzedine, University of Ottawa, Canada Caffery, James, University of Cincinnati, USA Cheng, Maggie, University of Missouri-Rolla, USA Cheng, Xiuzhen, George Washington University, USA Conrad, James, University of North Carolina at Charlotte, USA Dahlberg, Teresa, University of North Carolina, USA Datta, Suprakash, York University, Canada Ghosh, Ratan, Indian Institute of Technology, India Huang, Qingfeng, Palo Alto Research Center (PARC) Inc., USA Leung, Victor C. M., The University of British Columbia, Canada Li, Bo, Hong Kong University of Science and Technology, Hong Kong Li, Wei (Wayne), University Toledo, USA Lin, Chuang, Tsinghua University, China Nakano, Koji, Hiroshima University, Japan Nasser, Nidal, University of Guelph, Canada Olariu, Stephan, Old Dominion University, USA Park, Sang-Eon, Cal Poly Pomona, USA Pierre, Samuel, Ecole Polytechnique de Montreal, Canada Srimani, Pradip K., Clemson University, USA Tseng, Yu-Chee, National Chiao Tung University, Taiwan Vlajic, Natalija, York University, Canada Wang, Li-Chun, National Chiao-Tung University, Taiwan Watanabe, Takashi, University of Shizuoka, Japan Wu, Hong-Yi, University of Louisiana, USA Xue, Guoliang (Larry), Arizona State University, USA=20 Yang, Jiasi, Chengdu University of Information Technology, China Yang, Yuanyuan, SUNY at Stony Brook, USA Yeh, Chi-Hsiang, Queen's University, Canada Youn, Jon (Jong-Hoon), University of Nebraska at Omaha, USA Zhang, Jingyuan, University of Alabama, USA Zhou, Hong, University of Southern Queensland, Australia ------=_NextPart_000_038B_01C569EA.B3656E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Please accept our apologies if you = receive this=20 announcements from multiple sources.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <= /FONT>
 
First Call for = Papers:

IEEE=20 International Workshop on Heterogeneous Multi-Hop Wireless and Mobile = Networks=20 2005 (IEEE MHWMN'05)
 
http://www.ececs.uc.edu/~qzeng/MHWMN2005/CFP.html 
 
to be held in conjunction with = IEEE MASS=20 2005.
Washington DC, USA, November 7-11, = 2005.
 
AIM and=20 SCOPE:
--------------------------
The traditional centralized wireless = and mobile=20 networks are based on single-hop architecture and rely on the existing = fixed=20 infrastructure such as base stations or access points. The proliferation = and=20 deployment of radio access networks such as Wireless WANs, Wireless = LANs, and=20 Wireless PANs with distinguishing characteristics of data rate, coverage = range,=20 power, mobility, and prices will clearly lead to a need for seamless and = ubiquitous access across these various networks. Such an integrated=20 heterogeneous environment enables a user to access a particular network=20 depending upon the application needs and the types of radio access = networks=20 (RANs) available (e.g., cellular network, ad hoc, WLAN, WPAN etc). The=20 heterogeneous multi-hop wireless and mobile networks, on the other hand, = provide=20 unlimited mobility and greater flexibility but introduce a number of = challenges=20 due to dynamic network topology. The design of efficient and scalable = protocols=20 for existing multi-hop wireless and mobile networks such as wireless and = mobile=20 ad hoc networks continue to pose challenges at all the layers of = networking=20 stack. Therefore, it is necessary to investigate a global heterogeneous=20 architecture and services that together provide seamless integration of=20 single-hop networks (e.g., cellular, WLAN, WWAN) and multi-hop mobile ad = hoc=20 networks.
 
The aim of this workshop is to bring together=20 practitioners and researchers from both academia and industry in order = to have a=20 forum for discussion and technical presentations on the latest research = and=20 future research directions in heterogeneous multi-hop wireless and = mobile=20 networks. We are seeking original and previously unpublished research = papers=20 addressing theoretical and application issues in heterogeneous multi-hop = wireless mobile networks.
 
TOPICS: =
-------------
Topics of interest include, but are not = limited to,=20 the following areas:
- Multi-hop architectures and protocols for = resource=20 management
- Quality of services (QoS) delivery in MHWMN
- = Robust and=20 scalable routing protocols for MHWMN
- MAC protocols for MHWMN
- = Self-configuration and synchronization for MHWMN
- Security issues = in MHWMN=20
- Topology control and management for MHWMN
- Mobility models = and=20 location management in MHWMN
- Cross-layer design and interactions = for MHWMN=20
- Modeling and performance evaluation for MHWMN
- Algorithms = for =20 localization and signal processing in MHWMN
- Implementation = testbeds for=20 MHWMN
- Operating systems and middleware for MHWMN=20
 
SUBMISSIONS:
------------------------
Submissions will be judged on = correctness,=20 originality, technical strength, significance and quality of = presentation. The=20 manuscript must follow IEEE two-column format with single-spaced, = ten-point font=20 in the text. The maximum manuscript length is eight (8) pages. Authors = are=20 requested to submit their papers (PDF format), contact addresses, = telephone=20 number, fax number, and e-mail addresses (text format) to the co-chairs = Qing-An=20 Zeng (qzeng@ececs.uc.edu) and = Mieso=20 Denko (denko@cis.uoguelph.ca) by July = 1, 2005.
 
Note:  Some selected high quality papers from the workshop will be = published at=20 JPCC (Journal of Pervasive Computing and Communications) Special Issue = on =93Key=20 Technologies and Applications of Wireless Sensor and Body-area = Networks=94.=20 Selected authors will be invited to submit extended versions of their = papers for=20 publication in the special issue
 
IMPORTANT=20 DATES:
--------------------------------
Paper=20 submission:          &n= bsp;           &nb= sp;      July=20 1, 2005
Notification of=20 acceptance:          &n= bsp;      =20 August 5, 2005
Camera-ready=20 papers:           =             &= nbsp;August=20 26, 2005

 
WORKSHOP GENERAL=20 CHAIR:
------------------------------------------------
Anup=20 Kumar
Computer Engineering and Computer Science = Department
University of=20 Louisville, KY 40292, USA
Email: ak@louisville.edu   =

 
WORKSHOP CO-CHAIRS:=20
---------------------------------------
Qing-An=20 Zeng
Department of Electrical & Computer Engineering=20
    and Computer Science
University of=20 Cincinnati
Cincinnati, OH 45221-0030, USA
Email: qzeng@ececs.uc.edu  =20
 
Mieso Denko
Department of Computing and Information=20 Science
University of Guelph
N1G 2W1, Ontario, Canada
Email: denko@cis.uoguelph.ca=20  

PUBLICITY CHAIR:
----------------------------
Kui=20 Wu
Department of Computer Science
University of Victoria
V8W = 3P6,=20 British Columbia, Canada
Email: wkui@cs.uvic.ca  =20
 
PROGRAM COMMITTEE:
--------------------------------------
Boukerche, Azzedine, = University=20 of Ottawa, Canada
Caffery, James, University of Cincinnati, = USA
Cheng,=20 Maggie, University of Missouri-Rolla, USA
Cheng, Xiuzhen, George = Washington=20 University, USA
Conrad, James, University of North Carolina at = Charlotte,=20 USA
Dahlberg, Teresa, University of North Carolina, USA
Datta, = Suprakash,=20 York University, Canada
Ghosh, Ratan, Indian Institute of Technology, = India
Huang, Qingfeng, Palo Alto Research Center (PARC) Inc., = USA
Leung,=20 Victor C. M., The University of British Columbia, Canada
Li, Bo, Hong = Kong=20 University of Science and Technology, Hong Kong
Li, Wei (Wayne), = University=20 Toledo, USA
Lin, Chuang, Tsinghua University, China
Nakano, Koji,=20 Hiroshima University, Japan
Nasser, Nidal, University of Guelph,=20 Canada
Olariu, Stephan, Old Dominion University, USA
Park, = Sang-Eon, Cal=20 Poly Pomona, USA
Pierre, Samuel, Ecole Polytechnique de Montreal,=20 Canada
Srimani, Pradip K., Clemson University, USA
Tseng, Yu-Chee, = National Chiao Tung University, Taiwan
Vlajic, Natalija, York = University,=20 Canada
Wang, Li-Chun, National Chiao-Tung University, = Taiwan
Watanabe,=20 Takashi, University of Shizuoka, Japan
Wu, Hong-Yi, University of = Louisiana,=20 USA
Xue, Guoliang (Larry), Arizona State University, USA
Yang, = Jiasi,=20 Chengdu University of Information Technology, China
Yang, Yuanyuan, = SUNY at=20 Stony Brook, USA
Yeh, Chi-Hsiang, Queen's University, Canada
Youn, = Jon=20 (Jong-Hoon), University of Nebraska at Omaha, USA
Zhang, Jingyuan, = University=20 of Alabama, USA
Zhou, Hong, University of Southern Queensland,=20 Australia
------=_NextPart_000_038B_01C569EA.B3656E80-- --===============0178448824== 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/ --===============0178448824==-- From mip4-bounces@ietf.org Wed Jun 08 15:57:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6g8-0006NI-8Q; Wed, 08 Jun 2005 15:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6g4-0006MM-16 for mip4@megatron.ietf.org; Wed, 08 Jun 2005 15:57:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02001 for ; Wed, 8 Jun 2005 15:57:25 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg71L-00058t-Eo for mip4@ietf.org; Wed, 08 Jun 2005 16:19:29 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j58Jv8kr021099; Wed, 8 Jun 2005 14:57:08 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j58Jv6Q16378; Wed, 8 Jun 2005 14:57:06 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IHS7F8-0001W4-00; Wed, 08 Jun 2005 15:57:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17063.19858.537129.788053@gargle.gargle.HOWL> Date: Wed, 8 Jun 2005 14:57:06 -0500 From: Pete McCann To: Henrik Levkowetz Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration with FHAE In-Reply-To: <42362A4F.6000107@levkowetz.com> References: <4.3.2.7.2.20050314105333.02e960d0@mira-sjcm-2.cisco.com> <41E4A51B.10701@iprg.nokia.com> <4.3.2.7.2.20050111170556.03976dc0@mira-sjcm-2.cisco.com> <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.cisco.com> <4.3.2.7.2.20041210193834.02df4080@mira-sjcm-2.c> <4.3.2.7.2.20050314130018.0300a830@mira-sjcm-2.cisco.com> <42362A4F.6000107@levkowetz.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Cc: Kent Leung , mip4@ietf.org, "Charles E. Perkins" 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 Sorry for my long absence from the list. I am disappointed to find no further movement on this issue; I thought the writeup I did below summarized some of the issues nicely. First, can we agree that there should be an unambiguous specification of the "selectors" for Mobility Security Associations? And second, can we agree that for the FA-HA MSA the selectors for the Registration Request should be (a) the source address of the RRQ and (d) the Home Agent address. It seems like the most important issue is to clarify this in 3344bis. Now, what we are debating here is whether to include the boolean (e) (Lifetime=0) as an additional selector. In other words, the FA-HA authentication extension may be left out by the FA and need not be checked by the HA if the message is a de-registration. We need to converge. If this is not resolved soon I am inclined to flip a coin at IETF63. -Pete Henrik Levkowetz writes: > Hi Kent and Charlie, > > Below I attach Pete's writeup of the different combinations of > SA selectors we could use to express your respective 2 approaches. > Could you please check through the writeup, and indicate your > preferred selectors in terms of the a) to f) selectors in > Pete's note, (or add other's, if there are more than a) to > f) to consider), so we are clear here on exactly what is being > proposed. > > With that in hand I'll ask the people on the list to please weigh > in with considered opinions, so we can (hopefully) find a consensus > position regarding this, and close it. > > > Henrik > > > On 2005-03-14 10:05 pm Kent Leung said the following: > > Hi Charlie. Thanks. We have now articulated the 2 different > > approaches. I believe we both agree on one thing - closure on > > this issue. :) > > > > Kent > > > > At 12:53 PM 3/14/2005 -0800, Charles E. Perkins wrote: > [...] > > >>> And if real deployment > >>>problem is encountered by operators/customers, _then_ we can > >>>add more logic to support specific scenario. > >> > >>O.K. Let's interpret this sentence to mean the following: > >> > >>Allow the deregistration, and if real deployment shows any > >>problem with the FA when the mobile node wants to deregister, > >>then we will add more logic. > >> > >>>For now, please just keep it straightforward. Thanks. > >> > >>Check. > >> > >>Let's keep it straightforward. > >> > >>Mobile node authenticates ==> home agent acts on its > >>verifiable request. > >> > > > On 2005-02-25 10:47 pm Pete McCann said the following: > > Hi, Henrik, > > > > I went back and reviewed the archives. There are a lot of complex and > > thorny issues here. > > [...] > > > Whatever selectors we choose, it is important to understand that they > > serve two purposes: > > > > 1. The sender of a message must find the right SA with which to > > compute the authentication extension, or determine that an > > authentication extension is not necessary. > > > > 2. The receiver of a message must find the right SA with which to > > check the authentication extension, or to determine that a message > > without an authentication extension should be dropped. > > > > Both ends of the selector computation must be done in exactly the same > > way to guarantee interoperability. > > > > I would say that we need to choose some subset of the following fields > > as the selector set: > > > > Possible Registration Request Selector Fields > > a) The Source IP address > > b) The Destination IP address > > c) The Care-of Address > > d) The Home Agent Address > > e) The Lifetime field (or a bit which says whether or not it is zero) > > f) The D bit (set to 1 if co-located CoA is being used) > > > > Current status quo in the 3344bis text is, I believe, (c,d) with a > > proposal from Charlie to add (e). > > > > Now, before we consider adding (e) I think we need to get our story > > straight on why (c,d) is such a good choice. I have already pointed > > out the difficulty with (c,d) when using co-located CoA registering > > via the FA (which may or may not be using the 'R' bit). A possible > > solution to this difficulty is to configure duplicate SAs at every > > possible legal value of (c,d) (i.e., all CoAs 'c' that could be used > > from a given FA) but this seems like way too much state and doesn't > > handle the case where more than one FA are deployed on a given link. > > > > Another possible approach is to go back to using (a,d) instead of > > (c,d). Of course, NATs can change the value of (a) and so this is why > > 3519 mandated (c,d) and a=c. However, my understanding is that most > > current implementations (those that don't do 3519) actually use (a,d) > > even though this has been ambiguous ever since RFC 2002. (a,d) seems > > to be the most straightforward approach and matches e.g., IPSec style > > processing. > > > > I have proposed on the list a possible fix to the NAT issue where > > duplicate SAs are deployed at every possible legal value of (a,d) > > (i.e., all NATs that could be on the path between a given FA and HA) > > but this is a bit of an administrative overhead and doesn't handle the > > case where more than one FA is deployed behind the NAT. Another > > possible approach is to bury our heads in the sand while uttering some > > wistful complaint about the never-ending stupidity of NATs. I make it > > sound silly but it is actually my personally favored approach. > > > > Now, as I understand it, part of the motivation for adding (e) was to > > handle the case when the selector was (c,d) and the CoA 'c' in > > question nevertheless did not belong to the current FA. We really > > should nail down the question of whether we are going to revert back > > to (a,d) before debating whether to transition to (c,d,e). Agreed? > > Furthermore, if we do transition to (c,d,e) wouldn't we sometimes want > > an FA-HA authentication extension for (c,d,0)? > > > > In summary, I do not see a clear winner here. > > > > > > > > Note that for Registration Replies our choices are a bit different as > > the CoA is not represented in the message: > > > > Possible Registration Reply Selector Fields > > w) The Source IP address > > x) The Destination IP address > > y) The Home Agent Address > > z) The Lifetime field (or a bit which says whether or not it is zero) > > > > I assume that most implementations today use (x,y). Note that in this > > case the NAT issue boils down to modifying 'x' not 'w' because this is > > a response that trickles back through the NAT state set up by the > > request. How does 3519 handle this case? It seems like the HA has to > > find the SA based not on the contents of the outgoing message but > > based on the fact that it is a reply to a request and there is a > > corresponding SA pair in place that are bound together with > > administrative provisioning. Processing on the FA seems similarly > > bound up in the outstanding Request state, at least in the case of > > multi-interfaced FAs with different security policies for each > > interface. > > > [...] > > > -Pete > > > > > > > > -- > 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 Wed Jun 08 19:10:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg9gU-0005XD-60; Wed, 08 Jun 2005 19:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg9gS-0005X7-KN for mip4@megatron.ietf.org; Wed, 08 Jun 2005 19:10:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29716 for ; Wed, 8 Jun 2005 19:10:01 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgA1J-0006d0-Vo for mip4@ietf.org; Wed, 08 Jun 2005 19:31:38 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j58MaC020687; Wed, 8 Jun 2005 15:36:12 -0700 X-mProtect: <200506082236> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141161.americas.nokia.com (172.18.141.161, claiming to be "[172.18.141.161]") by darkstar.iprg.nokia.com smtpdttg9uu; Wed, 08 Jun 2005 15:36:10 PDT Message-ID: <42A77A37.5090806@iprg.nokia.com> Date: Wed, 08 Jun 2005 16:07:35 -0700 From: Charlie P Organization: NOKIA User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration with FHAE References: <4.3.2.7.2.20050314105333.02e960d0@mira-sjcm-2.cisco.com> <41E4A51B.10701@iprg.nokia.com> <4.3.2.7.2.20050111170556.03976dc0@mira-sjcm-2.cisco.com> <16861.48387.626374.280537@gargle.gargle.HOWL> <4.3.2.7.2.20050104153537.02b0e1a8@mira-sjcm-2.c In-Reply-To: <17063.19858.537129.788053@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit Cc: Kent Leung , mip4@ietf.org, 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 Hello Pete, You must have been reading my mind. I was preparing to send out some e-mail on the issue to try to resolve it. I think your solution is very workable, and fairly represents the situation. I am myself in favor of enlarging the set of selectors -- and not just in this situation. We had major damage to Mobile IPv6 because of carping about the available selectors. At least in this case, the situation is entirely under our control. Regards, Charlie P. Pete McCann wrote: >Sorry for my long absence from the list. > >I am disappointed to find no further movement on this issue; I thought >the writeup I did below summarized some of the issues nicely. > >First, can we agree that there should be an unambiguous specification >of the "selectors" for Mobility Security Associations? And second, >can we agree that for the FA-HA MSA the selectors for the Registration >Request should be (a) the source address of the RRQ and (d) the Home >Agent address. It seems like the most important issue is to clarify >this in 3344bis. > >Now, what we are debating here is whether to include the boolean (e) >(Lifetime=0) as an additional selector. In other words, the FA-HA >authentication extension may be left out by the FA and need not be >checked by the HA if the message is a de-registration. > >We need to converge. If this is not resolved soon I am inclined to >flip a coin at IETF63. > >-Pete > >Henrik Levkowetz writes: > > Hi Kent and Charlie, > > > > Below I attach Pete's writeup of the different combinations of > > SA selectors we could use to express your respective 2 approaches. > > Could you please check through the writeup, and indicate your > > preferred selectors in terms of the a) to f) selectors in > > Pete's note, (or add other's, if there are more than a) to > > f) to consider), so we are clear here on exactly what is being > > proposed. > > > > With that in hand I'll ask the people on the list to please weigh > > in with considered opinions, so we can (hopefully) find a consensus > > position regarding this, and close it. > > > > > > Henrik > > > > > > On 2005-03-14 10:05 pm Kent Leung said the following: > > > Hi Charlie. Thanks. We have now articulated the 2 different > > > approaches. I believe we both agree on one thing - closure on > > > this issue. :) > > > > > > Kent > > > > > > At 12:53 PM 3/14/2005 -0800, Charles E. Perkins wrote: > > [...] > > > > >>> And if real deployment > > >>>problem is encountered by operators/customers, _then_ we can > > >>>add more logic to support specific scenario. > > >> > > >>O.K. Let's interpret this sentence to mean the following: > > >> > > >>Allow the deregistration, and if real deployment shows any > > >>problem with the FA when the mobile node wants to deregister, > > >>then we will add more logic. > > >> > > >>>For now, please just keep it straightforward. Thanks. > > >> > > >>Check. > > >> > > >>Let's keep it straightforward. > > >> > > >>Mobile node authenticates ==> home agent acts on its > > >>verifiable request. > > >> > > > > > > On 2005-02-25 10:47 pm Pete McCann said the following: > > > Hi, Henrik, > > > > > > I went back and reviewed the archives. There are a lot of complex and > > > thorny issues here. > > > > [...] > > > > > Whatever selectors we choose, it is important to understand that they > > > serve two purposes: > > > > > > 1. The sender of a message must find the right SA with which to > > > compute the authentication extension, or determine that an > > > authentication extension is not necessary. > > > > > > 2. The receiver of a message must find the right SA with which to > > > check the authentication extension, or to determine that a message > > > without an authentication extension should be dropped. > > > > > > Both ends of the selector computation must be done in exactly the same > > > way to guarantee interoperability. > > > > > > I would say that we need to choose some subset of the following fields > > > as the selector set: > > > > > > Possible Registration Request Selector Fields > > > a) The Source IP address > > > b) The Destination IP address > > > c) The Care-of Address > > > d) The Home Agent Address > > > e) The Lifetime field (or a bit which says whether or not it is zero) > > > f) The D bit (set to 1 if co-located CoA is being used) > > > > > > Current status quo in the 3344bis text is, I believe, (c,d) with a > > > proposal from Charlie to add (e). > > > > > > Now, before we consider adding (e) I think we need to get our story > > > straight on why (c,d) is such a good choice. I have already pointed > > > out the difficulty with (c,d) when using co-located CoA registering > > > via the FA (which may or may not be using the 'R' bit). A possible > > > solution to this difficulty is to configure duplicate SAs at every > > > possible legal value of (c,d) (i.e., all CoAs 'c' that could be used > > > from a given FA) but this seems like way too much state and doesn't > > > handle the case where more than one FA are deployed on a given link. > > > > > > Another possible approach is to go back to using (a,d) instead of > > > (c,d). Of course, NATs can change the value of (a) and so this is why > > > 3519 mandated (c,d) and a=c. However, my understanding is that most > > > current implementations (those that don't do 3519) actually use (a,d) > > > even though this has been ambiguous ever since RFC 2002. (a,d) seems > > > to be the most straightforward approach and matches e.g., IPSec style > > > processing. > > > > > > I have proposed on the list a possible fix to the NAT issue where > > > duplicate SAs are deployed at every possible legal value of (a,d) > > > (i.e., all NATs that could be on the path between a given FA and HA) > > > but this is a bit of an administrative overhead and doesn't handle the > > > case where more than one FA is deployed behind the NAT. Another > > > possible approach is to bury our heads in the sand while uttering some > > > wistful complaint about the never-ending stupidity of NATs. I make it > > > sound silly but it is actually my personally favored approach. > > > > > > Now, as I understand it, part of the motivation for adding (e) was to > > > handle the case when the selector was (c,d) and the CoA 'c' in > > > question nevertheless did not belong to the current FA. We really > > > should nail down the question of whether we are going to revert back > > > to (a,d) before debating whether to transition to (c,d,e). Agreed? > > > Furthermore, if we do transition to (c,d,e) wouldn't we sometimes want > > > an FA-HA authentication extension for (c,d,0)? > > > > > > In summary, I do not see a clear winner here. > > > > > > > > > > > > Note that for Registration Replies our choices are a bit different as > > > the CoA is not represented in the message: > > > > > > Possible Registration Reply Selector Fields > > > w) The Source IP address > > > x) The Destination IP address > > > y) The Home Agent Address > > > z) The Lifetime field (or a bit which says whether or not it is zero) > > > > > > I assume that most implementations today use (x,y). Note that in this > > > case the NAT issue boils down to modifying 'x' not 'w' because this is > > > a response that trickles back through the NAT state set up by the > > > request. How does 3519 handle this case? It seems like the HA has to > > > find the SA based not on the contents of the outgoing message but > > > based on the fact that it is a reply to a request and there is a > > > corresponding SA pair in place that are bound together with > > > administrative provisioning. Processing on the FA seems similarly > > > bound up in the outstanding Request state, at least in the case of > > > multi-interfaced FAs with different security policies for each > > > interface. > > > > > [...] > > > > > -Pete > > > > > > > > > > > > > > -- > > 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 Wed Jun 08 20:48:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgBDj-0002Ml-R6; Wed, 08 Jun 2005 20:48:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgBDi-0002MM-4Y for mip4@megatron.ietf.org; Wed, 08 Jun 2005 20:48:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08128 for ; Wed, 8 Jun 2005 20:48:28 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgBYa-0002Rw-7K for mip4@ietf.org; Wed, 08 Jun 2005 21:10:04 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 08 Jun 2005 17:47:36 -0700 X-IronPort-AV: i="3.93,184,1115017200"; d="scan'208"; a="642167232:sNHT32953900" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j590lPc2024955; Wed, 8 Jun 2005 17:47:31 -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); Wed, 8 Jun 2005 17:47:31 -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] Issue #45; Seeking closure for on deregistration with FHAE Date: Wed, 8 Jun 2005 17:47:30 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] Issue #45; Seeking closure for on deregistration with FHAE Thread-Index: AcVsZFFdBiYKXnFuSvWyj/g9OotXPAAIeryQ From: "Kent Leung \(kleung\)" To: "Pete McCann" , "Henrik Levkowetz" X-OriginalArrivalTime: 09 Jun 2005 00:47:31.0486 (UTC) FILETIME=[D16EFBE0:01C56C8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, "Charles E. Perkins" 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 Welcome back Pete. #1) Agree with unambiguous selector of SA. #2) Currently RFC 3344 specifies selector of SA "by their SPI and IP address". > 3.2. Authentication > Each mobile node, foreign agent, and home agent MUST be able to > support a mobility security association for mobile entities, indexed > by their SPI and IP address. This is the same language since RFC 2002. I don't think we need to change this. For example, RRQ to FA/HA can be indexed by the source IP address/SPI. RRP to FA/MN can be indexed by the source IP address/SPI. #3) I favor a mobility security association selector that doesn't need the additional registration lifetime field. There's a backward compatibility issue if we add lifetime field to the selector parameters. For example, an FA (new change) will not append the FHAE when lifetime is zero. But an existing HA (with SA for FA) will drop the RRQ in compliance to RFC 3344. For registrations the SA and FHAE are in affect and will still work fine. Doesn't the IP addresses of the peers exchanging messages already "unambiguously" (#1 pt) satisfy the condition of securing communications between them? Is that what SA was designed for? =20 I'll bring the coin to Paris. ;) Kent > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com]=20 > Sent: Wednesday, June 08, 2005 12:57 PM > To: Henrik Levkowetz > Cc: Kent Leung (kleung); mip4@ietf.org; Charles E. Perkins > Subject: Re: [Mip4] Issue #45; Seeking closure for on=20 > deregistration with FHAE >=20 >=20 > Sorry for my long absence from the list. >=20 > I am disappointed to find no further movement on this issue;=20 > I thought the writeup I did below summarized some of the=20 > issues nicely. >=20 > First, can we agree that there should be an unambiguous=20 > specification of the "selectors" for Mobility Security=20 > Associations? And second, can we agree that for the FA-HA=20 > MSA the selectors for the Registration Request should be (a)=20 > the source address of the RRQ and (d) the Home Agent address.=20 > It seems like the most important issue is to clarify this in 3344bis. >=20 > Now, what we are debating here is whether to include the boolean (e) > (Lifetime=3D0) as an additional selector. In other words, the=20 > FA-HA authentication extension may be left out by the FA and=20 > need not be checked by the HA if the message is a de-registration. >=20 > We need to converge. If this is not resolved soon I am=20 > inclined to flip a coin at IETF63. >=20 > -Pete >=20 > Henrik Levkowetz writes: > > Hi Kent and Charlie, > >=20 > > Below I attach Pete's writeup of the different combinations of > > SA selectors we could use to express your respective 2 approaches. > > Could you please check through the writeup, and indicate=20 > your > preferred selectors in terms of the a) to f)=20 > selectors in > Pete's note, (or add other's, if there are=20 > more than a) to > f) to consider), so we are clear here on=20 > exactly what is being > proposed. =20 > > > > With that in hand I'll ask the people on the list to=20 > please weigh > in with considered opinions, so we can=20 > (hopefully) find a consensus > position regarding this, and close it. > > > >=20 > > Henrik > > > > > > On 2005-03-14 10:05 pm Kent Leung said the following: > > > Hi Charlie. Thanks. We have now articulated the 2=20 > different > > approaches. I believe we both agree on one=20 > thing - closure on > > this issue. :) > > > > Kent > > =20 > > > At 12:53 PM 3/14/2005 -0800, Charles E. Perkins wrote: > > [...] > >=20 > > >>> And if real deployment > > >>>problem is encountered by operators/customers, _then_=20 > we can > >>>add more logic to support specific scenario. > > >> > > >>O.K. Let's interpret this sentence to mean the following: > > >> > > >>Allow the deregistration, and if real deployment shows=20 > any > >>problem with the FA when the mobile node wants to=20 > deregister, > >>then we will add more logic. > > >> > > >>>For now, please just keep it straightforward. Thanks. > > >> > > >>Check. > > >> > > >>Let's keep it straightforward. > > >> > > >>Mobile node authenticates =3D=3D> home agent acts on its > > >>verifiable request. > > >> > > > > > > On 2005-02-25 10:47 pm Pete McCann said the following: > > > Hi, Henrik, > > > > > > I went back and reviewed the archives. There are a lot=20 > of complex and > > thorny issues here. > > > > [...] > > > > > Whatever selectors we choose, it is important to=20 > understand that they > > serve two purposes: > > > > > > 1. The sender of a message must find the right SA with which to > > > compute the authentication extension, or determine that an > > > authentication extension is not necessary. > > > > > > 2. The receiver of a message must find the right SA with which to > > > check the authentication extension, or to determine=20 > that a message > > > without an authentication extension should be dropped. > > > > > > Both ends of the selector computation must be done in=20 > exactly the same > > way to guarantee interoperability. > > > > > > I would say that we need to choose some subset of the=20 > following fields > > as the selector set: > > > > > > Possible Registration Request Selector Fields > > > a) The Source IP address > > > b) The Destination IP address > > > c) The Care-of Address > > > d) The Home Agent Address > > > e) The Lifetime field (or a bit which says whether or=20 > not it is zero) > > > f) The D bit (set to 1 if co-located CoA is being used) > > > > > > Current status quo in the 3344bis text is, I believe,=20 > (c,d) with a > > proposal from Charlie to add (e). > > > > > > Now, before we consider adding (e) I think we need to=20 > get our story > > straight on why (c,d) is such a good=20 > choice. I have already pointed > > out the difficulty with=20 > (c,d) when using co-located CoA registering > > via the FA=20 > (which may or may not be using the 'R' bit). A possible > >=20 > solution to this difficulty is to configure duplicate SAs at=20 > every > > possible legal value of (c,d) (i.e., all CoAs 'c'=20 > that could be used > > from a given FA) but this seems like=20 > way too much state and doesn't > > handle the case where=20 > more than one FA are deployed on a given link. > > > > > > Another possible approach is to go back to using (a,d)=20 > instead of > > (c,d). Of course, NATs can change the value=20 > of (a) and so this is why > > 3519 mandated (c,d) and a=3Dc. =20 > However, my understanding is that most > > current=20 > implementations (those that don't do 3519) actually use (a,d)=20 > > > even though this has been ambiguous ever since RFC 2002.=20 > (a,d) seems > > to be the most straightforward approach and=20 > matches e.g., IPSec style > > processing. > > > > > > I have proposed on the list a possible fix to the NAT=20 > issue where > > duplicate SAs are deployed at every possible=20 > legal value of (a,d) > > (i.e., all NATs that could be on=20 > the path between a given FA and HA) > > but this is a bit of=20 > an administrative overhead and doesn't handle the > > case=20 > where more than one FA is deployed behind the NAT. Another =20 > > > possible approach is to bury our heads in the sand while=20 > uttering some > > wistful complaint about the never-ending=20 > stupidity of NATs. I make it > > sound silly but it is=20 > actually my personally favored approach. > > > > > > Now, as I understand it, part of the motivation for=20 > adding (e) was to > > handle the case when the selector was=20 > (c,d) and the CoA 'c' in > > question nevertheless did not=20 > belong to the current FA. We really > > should nail down=20 > the question of whether we are going to revert back > > to=20 > (a,d) before debating whether to transition to (c,d,e). Agreed? > > > Furthermore, if we do transition to (c,d,e) wouldn't we=20 > sometimes want > > an FA-HA authentication extension for (c,d,0)? > > > > > > In summary, I do not see a clear winner here. > > > > > > > > > > > > Note that for Registration Replies our choices are a bit=20 > different as > > the CoA is not represented in the message: > > > > > > Possible Registration Reply Selector Fields > > > w) The Source IP address > > > x) The Destination IP address > > > y) The Home Agent Address > > > z) The Lifetime field (or a bit which says whether or=20 > not it is zero) > > > > > > I assume that most implementations today use (x,y). =20 > Note that in this > > case the NAT issue boils down to=20 > modifying 'x' not 'w' because this is > > a response that=20 > trickles back through the NAT state set up by the > >=20 > request. How does 3519 handle this case? It seems like the=20 > HA has to > > find the SA based not on the contents of the=20 > outgoing message but > > based on the fact that it is a=20 > reply to a request and there is a > > corresponding SA pair=20 > in place that are bound together with > > administrative=20 > provisioning. Processing on the FA seems similarly > >=20 > bound up in the outstanding Request state, at least in the=20 > case of > > multi-interfaced FAs with different security=20 > policies for each > > interface. > > > > > [...] > > > > > -Pete > > > > > > > > > > > > > > -- > > 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 > > 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 Thu Jun 09 01:21:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgFTT-0001uo-86; Thu, 09 Jun 2005 01:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgFTR-0001uZ-3w for mip4@megatron.ietf.org; Thu, 09 Jun 2005 01:21:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01534 for ; Thu, 9 Jun 2005 01:21:00 -0400 (EDT) Received: from av9-1-sn3.vrr.skanova.net ([81.228.9.185]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgFoL-0000JK-AP for mip4@ietf.org; Thu, 09 Jun 2005 01:42:38 -0400 Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id D05CF38311; Thu, 9 Jun 2005 07:19:58 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5292D382FF; Thu, 9 Jun 2005 07:19:58 +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 EBD3C37E42; Thu, 9 Jun 2005 07:19:57 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DgFSP-0005gz-1B; Thu, 09 Jun 2005 07:19:57 +0200 Message-ID: <42A7D173.4030109@levkowetz.com> Date: Thu, 09 Jun 2005 07:19:47 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration with FHAE References: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@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: cd3fc8e909678b38737fc606dec187f0 Cc: Pete McCann , mip4@ietf.org, "Charles E. Perkins" 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="===============0196853909==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0196853909== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A242C4030AF289DEA09E317" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A242C4030AF289DEA09E317 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kent, On 2005-06-09 02:47 Kent Leung (kleung) said the following: > Welcome back Pete. > > #1) Agree with unambiguous selector of SA. > > #2) Currently RFC 3344 specifies selector of SA "by their SPI and IP > address". > >> 3.2. Authentication > >> Each mobile node, foreign agent, and home agent MUST be able to >> support a mobility security association for mobile entities, > indexed >> by their SPI and IP address. > > This is the same language since RFC 2002. I don't think we need to > change this. For example, RRQ to FA/HA can be indexed by the source IP > address/SPI. RRP to FA/MN can be indexed by the source IP address/SPI. Since we need to firm up what the selector actually is, and any choice we make should be more explicit than this, we are in effect making a change if we define an unambiguous selector of SA (which I think we should do. For some implementers, our definitive choice may coincide with what they have implemented, but in general we can't expect this. Or in other words - I think we need to change the wording above to make it explicit exactly what the SA selector shall be. > #3) I favor a mobility security association selector that doesn't need > the additional registration lifetime field. There's a backward > compatibility issue if we add lifetime field to the selector parameters. > For example, an FA (new change) will not append the FHAE when lifetime > is zero. But an existing HA (with SA for FA) will drop the RRQ in > compliance to RFC 3344. For registrations the SA and FHAE are in affect > and will still work fine. No, I don't see that this argument holds. If there is a FA-HA SA, I think we can assume that both boxes are under the same administrative control. Now, it would be a simple thing for any vendor who implements a new SA selector scheme to keep a backward compatibility option, and when deploying new FAs to work with old HAs, an administrator setting up the FA-HA SA could indicate that it should run in compatibility mode, rather than in 3344bis mode. We can't use this as a blocker for moving forward to something better than we have today. > Doesn't the IP addresses of the peers exchanging messages already > "unambiguously" (#1 pt) satisfy the condition of securing communications > between them? Is that what SA was designed for? Obviously we have had shifting interpretations both over time and between vendors, so the answer seems to be "No". > I'll bring the coin to Paris. ;) Let's all bring coins and spend'em on some nice food and drink ;-) Henrik [...] >> > > I would say that we need to choose some subset of the following fields >> > > as the selector set: >> > > >> > > Possible Registration Request Selector Fields >> > > a) The Source IP address >> > > b) The Destination IP address >> > > c) The Care-of Address >> > > d) The Home Agent Address >> > > e) The Lifetime field (or a bit which says whether or not it is zero) >> > > f) The D bit (set to 1 if co-located CoA is being used) >> > > >> > > Current status quo in the 3344bis text is, I believe, (c,d) with a >> > > proposal from Charlie to add (e). >> > > >> > > Now, before we consider adding (e) I think we need to get our story >> > > straight on why (c,d) is such a good choice. I have already pointed >> > > out the difficulty with (c,d) when using co-located CoA registering >> > > via the FA (which may or may not be using the 'R' bit). A possible >> > > solution to this difficulty is to configure duplicate SAs at every >> > > possible legal value of (c,d) (i.e., all CoAs 'c' that could be used >> > > from a given FA) but this seems like way too much state and doesn't >> > > handle the case where more than one FA are deployed on a given link. >> > > >> > > Another possible approach is to go back to using (a,d) instead of >> > > (c,d). Of course, NATs can change the value of (a) and so this is why >> > > 3519 mandated (c,d) and a=c. However, my understanding is that most >> > > current implementations (those that don't do 3519) actually use (a,d) >> > > even though this has been ambiguous ever since RFC 2002. (a,d) seems >> > > to be the most straightforward approach and matches e.g., IPSec style >> > > processing. >> > > >> > > I have proposed on the list a possible fix to the NAT issue where >> > > duplicate SAs are deployed at every possible legal value of (a,d) >> > > (i.e., all NATs that could be on the path between a given FA and HA) >> > > but this is a bit of an administrative overhead and doesn't handle the >> > > case where more than one FA is deployed behind the NAT. Another >> > > possible approach is to bury our heads in the sand while uttering some >> > > wistful complaint about the never-ending stupidity of NATs. I make it >> > > sound silly but it is actually my personally favored approach. >> > > >> > > Now, as I understand it, part of the motivation for adding (e) was to >> > > handle the case when the selector was (c,d) and the CoA 'c' in >> > > question nevertheless did not belong to the current FA. We really >> > > should nail down the question of whether we are going to revert back >> > > to (a,d) before debating whether to transition to (c,d,e). Agreed? >> > > Furthermore, if we do transition to (c,d,e) wouldn't we sometimes want >> > > an FA-HA authentication extension for (c,d,0)? >> > > >> > > In summary, I do not see a clear winner here. >> > > >> > > >> > > >> > > Note that for Registration Replies our choices are a bit different as >> > > the CoA is not represented in the message: >> > > >> > > Possible Registration Reply Selector Fields >> > > w) The Source IP address >> > > x) The Destination IP address >> > > y) The Home Agent Address >> > > z) The Lifetime field (or a bit which says whether or >> > > not it is zero) >> > > >> > > I assume that most implementations today use (x,y). Note that in this >> > > case the NAT issue boils down to modifying 'x' not 'w' because this is >> > > a response that trickles back through the NAT state set up by the >> > > request. How does 3519 handle this case? It seems like the HA has to >> > > find the SA based not on the contents of the outgoing message but >> > > based on the fact that it is a reply to a request and there is a >> > > corresponding SA pair in place that are bound together with >> > > administrative provisioning. Processing on the FA seems similarly >> > > bound up in the outstanding Request state, at least in the case of >> > > multi-interfaced FAs with different security policies for each >> > > interface. >> > > >> > [...] >> > >> > > -Pete --------------enig0A242C4030AF289DEA09E317 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFCp9F7eVhrtTJkXCMRArfFAKC1d6tlA4uKv+HNS9uKMiAAU73KEACglcCI cDTK/zV06EWbovaFHUsuDD8= =ryJd -----END PGP SIGNATURE----- --------------enig0A242C4030AF289DEA09E317-- --===============0196853909== 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/ --===============0196853909==-- From mip4-bounces@ietf.org Thu Jun 09 10:42:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgOEd-00008P-D7; Thu, 09 Jun 2005 10:42:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgOEa-00008B-Nq for mip4@megatron.ietf.org; Thu, 09 Jun 2005 10:42:18 -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 KAA07771 for ; Thu, 9 Jun 2005 10:42:14 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgOa4-0006vj-A4 for mip4@ietf.org; Thu, 09 Jun 2005 11:04:28 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j59Eg4Xc021753; Thu, 9 Jun 2005 09:42:04 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j59Eg3319019; Thu, 9 Jun 2005 09:42:03 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IHTNI5-0002AK-00; Thu, 09 Jun 2005 10:42:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17064.21820.385129.666629@gargle.gargle.HOWL> Date: Thu, 9 Jun 2005 09:42:04 -0500 From: Pete McCann To: "Kent Leung \(kleung\)" Subject: RE: [Mip4] Issue #45; Seeking closure for on deregistration with FHAE In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@xmb-sjc-235.amer.cisco.com> References: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@xmb-sjc-235.amer.cisco.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Henrik Levkowetz , "Charles E. Perkins" 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 Strictly speaking, I don't think we would include the SPI as a "selector." Remember, the selector set has two functions: > 1. The sender of a message must find the right SA with which to > compute the authentication extension, or determine that an > authentication extension is not necessary. > > 2. The receiver of a message must find the right SA with which to > check the authentication extension, or to determine > that a message without an authentication extension should be dropped. It is true that, given multiple MSAs between two peers, the SPI field determines which MSA is in use. However, the SPI field does not "select" the outgoing traffic in (1) above, and is not present in messages that are missing authentication extensions as in (2). So, strictly speaking, I would say that the SPI field is part of the MSA but is not itself a selector. In the multiple MSA case, we should also have text which states that the sender can use any of the applicable MSAs, and the receiver should be prepared to validate the message based on any of the MSAs. Also note that, given (1) and (2) above, if we add the lifetime field, it simply means that an authentication extension is not necessary to either add at the sender or check at the receiver. One possible approach to backwards compatibility is to mandate that the FA adds it anyway but just allow the HA to skip it when the lifetime=0. Unlike Henrik, I do think it is important to address the backwards compatibility issue because we have mechanisms for dynamically distributing MSAs among FAs and HAs from different administrative domains (i.e., using AAA). -Pete Kent Leung \(kleung\) writes: > Welcome back Pete. > > #1) Agree with unambiguous selector of SA. > > #2) Currently RFC 3344 specifies selector of SA "by their SPI and IP > address". > > > 3.2. Authentication > > > Each mobile node, foreign agent, and home agent MUST be able to > > support a mobility security association for mobile entities, > indexed > > by their SPI and IP address. > > This is the same language since RFC 2002. I don't think we need to > change this. For example, RRQ to FA/HA can be indexed by the source IP > address/SPI. RRP to FA/MN can be indexed by the source IP address/SPI. > > #3) I favor a mobility security association selector that doesn't need > the additional registration lifetime field. There's a backward > compatibility issue if we add lifetime field to the selector parameters. > For example, an FA (new change) will not append the FHAE when lifetime > is zero. But an existing HA (with SA for FA) will drop the RRQ in > compliance to RFC 3344. For registrations the SA and FHAE are in affect > and will still work fine. > > Doesn't the IP addresses of the peers exchanging messages already > "unambiguously" (#1 pt) satisfy the condition of securing communications > between them? Is that what SA was designed for? > > I'll bring the coin to Paris. ;) > > Kent > > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Wednesday, June 08, 2005 12:57 PM > > To: Henrik Levkowetz > > Cc: Kent Leung (kleung); mip4@ietf.org; Charles E. Perkins > > Subject: Re: [Mip4] Issue #45; Seeking closure for on > > deregistration with FHAE > > > > > > Sorry for my long absence from the list. > > > > I am disappointed to find no further movement on this issue; > > I thought the writeup I did below summarized some of the > > issues nicely. > > > > First, can we agree that there should be an unambiguous > > specification of the "selectors" for Mobility Security > > Associations? And second, can we agree that for the FA-HA > > MSA the selectors for the Registration Request should be (a) > > the source address of the RRQ and (d) the Home Agent address. > > It seems like the most important issue is to clarify this in 3344bis. > > > > Now, what we are debating here is whether to include the boolean (e) > > (Lifetime=0) as an additional selector. In other words, the > > FA-HA authentication extension may be left out by the FA and > > need not be checked by the HA if the message is a de-registration. > > > > We need to converge. If this is not resolved soon I am > > inclined to flip a coin at IETF63. > > > > -Pete > > > > Henrik Levkowetz writes: > > > Hi Kent and Charlie, > > > > > > Below I attach Pete's writeup of the different combinations of > > > SA selectors we could use to express your respective 2 approaches. > > > Could you please check through the writeup, and indicate > > your > preferred selectors in terms of the a) to f) > > selectors in > Pete's note, (or add other's, if there are > > more than a) to > f) to consider), so we are clear here on > > exactly what is being > proposed. > > > > > > With that in hand I'll ask the people on the list to > > please weigh > in with considered opinions, so we can > > (hopefully) find a consensus > position regarding this, and close it. > > > > > > > > > Henrik > > > > > > > > > On 2005-03-14 10:05 pm Kent Leung said the following: > > > > Hi Charlie. Thanks. We have now articulated the 2 > > different > > approaches. I believe we both agree on one > > thing - closure on > > this issue. :) > > > > Kent > > > > > > At 12:53 PM 3/14/2005 -0800, Charles E. Perkins wrote: > > > [...] > > > > > > >>> And if real deployment > > > >>>problem is encountered by operators/customers, _then_ > > we can > >>>add more logic to support specific scenario. > > > >> > > > >>O.K. Let's interpret this sentence to mean the following: > > > >> > > > >>Allow the deregistration, and if real deployment shows > > any > >>problem with the FA when the mobile node wants to > > deregister, > >>then we will add more logic. > > > >> > > > >>>For now, please just keep it straightforward. Thanks. > > > >> > > > >>Check. > > > >> > > > >>Let's keep it straightforward. > > > >> > > > >>Mobile node authenticates ==> home agent acts on its > > > >>verifiable request. > > > >> > > > > > > > > > On 2005-02-25 10:47 pm Pete McCann said the following: > > > > Hi, Henrik, > > > > > > > > I went back and reviewed the archives. There are a lot > > of complex and > > thorny issues here. > > > > > > [...] > > > > > > > Whatever selectors we choose, it is important to > > understand that they > > serve two purposes: > > > > > > > > 1. The sender of a message must find the right SA with which to > > > > compute the authentication extension, or determine that an > > > > authentication extension is not necessary. > > > > > > > > 2. The receiver of a message must find the right SA with which to > > > > check the authentication extension, or to determine > > that a message > > > > without an authentication extension should be dropped. > > > > > > > > Both ends of the selector computation must be done in > > exactly the same > > way to guarantee interoperability. > > > > > > > > I would say that we need to choose some subset of the > > following fields > > as the selector set: > > > > > > > > Possible Registration Request Selector Fields > > > > a) The Source IP address > > > > b) The Destination IP address > > > > c) The Care-of Address > > > > d) The Home Agent Address > > > > e) The Lifetime field (or a bit which says whether or > > not it is zero) > > > > f) The D bit (set to 1 if co-located CoA is being used) > > > > > > > > Current status quo in the 3344bis text is, I believe, > > (c,d) with a > > proposal from Charlie to add (e). > > > > > > > > Now, before we consider adding (e) I think we need to > > get our story > > straight on why (c,d) is such a good > > choice. I have already pointed > > out the difficulty with > > (c,d) when using co-located CoA registering > > via the FA > > (which may or may not be using the 'R' bit). A possible > > > > solution to this difficulty is to configure duplicate SAs at > > every > > possible legal value of (c,d) (i.e., all CoAs 'c' > > that could be used > > from a given FA) but this seems like > > way too much state and doesn't > > handle the case where > > more than one FA are deployed on a given link. > > > > > > > > Another possible approach is to go back to using (a,d) > > instead of > > (c,d). Of course, NATs can change the value > > of (a) and so this is why > > 3519 mandated (c,d) and a=c. > > However, my understanding is that most > > current > > implementations (those that don't do 3519) actually use (a,d) > > > > even though this has been ambiguous ever since RFC 2002. > > (a,d) seems > > to be the most straightforward approach and > > matches e.g., IPSec style > > processing. > > > > > > > > I have proposed on the list a possible fix to the NAT > > issue where > > duplicate SAs are deployed at every possible > > legal value of (a,d) > > (i.e., all NATs that could be on > > the path between a given FA and HA) > > but this is a bit of > > an administrative overhead and doesn't handle the > > case > > where more than one FA is deployed behind the NAT. Another > > > > possible approach is to bury our heads in the sand while > > uttering some > > wistful complaint about the never-ending > > stupidity of NATs. I make it > > sound silly but it is > > actually my personally favored approach. > > > > > > > > Now, as I understand it, part of the motivation for > > adding (e) was to > > handle the case when the selector was > > (c,d) and the CoA 'c' in > > question nevertheless did not > > belong to the current FA. We really > > should nail down > > the question of whether we are going to revert back > > to > > (a,d) before debating whether to transition to (c,d,e). Agreed? > > > > Furthermore, if we do transition to (c,d,e) wouldn't we > > sometimes want > > an FA-HA authentication extension for (c,d,0)? > > > > > > > > In summary, I do not see a clear winner here. > > > > > > > > > > > > > > > > Note that for Registration Replies our choices are a bit > > different as > > the CoA is not represented in the message: > > > > > > > > Possible Registration Reply Selector Fields > > > > w) The Source IP address > > > > x) The Destination IP address > > > > y) The Home Agent Address > > > > z) The Lifetime field (or a bit which says whether or > > not it is zero) > > > > > > > > I assume that most implementations today use (x,y). > > Note that in this > > case the NAT issue boils down to > > modifying 'x' not 'w' because this is > > a response that > > trickles back through the NAT state set up by the > > > > request. How does 3519 handle this case? It seems like the > > HA has to > > find the SA based not on the contents of the > > outgoing message but > > based on the fact that it is a > > reply to a request and there is a > > corresponding SA pair > > in place that are bound together with > > administrative > > provisioning. Processing on the FA seems similarly > > > > bound up in the outstanding Request state, at least in the > > case of > > multi-interfaced FAs with different security > > policies for each > > interface. > > > > > > > [...] > > > > > > > -Pete -- 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 Jun 10 06:41:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dggwm-0003lW-P6; Fri, 10 Jun 2005 06:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dggwl-0003lC-4Q for mip4@megatron.ietf.org; Fri, 10 Jun 2005 06:41:07 -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 GAA05775 for ; Fri, 10 Jun 2005 06:41:04 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DghIJ-0001CJ-9L for mip4@ietf.org; Fri, 10 Jun 2005 07:03:29 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by delivery_mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0D4DAD46; Fri, 10 Jun 2005 12:40:34 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by outbound_mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E51B7D29; Fri, 10 Jun 2005 12:40:33 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 12:40:32 +0200 Received: from [147.214.237.81] ([147.214.237.81]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 12:40:32 +0200 Message-ID: <42A96E16.5050009@levkowetz.com> Date: Fri, 10 Jun 2005 12:40:22 +0200 From: Henrik Levkowetz User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration with FHAE References: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@xmb-sjc-235.amer.cisco.com> <17064.21820.385129.666629@gargle.gargle.HOWL> In-Reply-To: <17064.21820.385129.666629@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2005 10:40:32.0830 (UTC) FILETIME=[D3FAF5E0:01C56DA8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, "Charles E. Perkins" 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 On 06/09/2005 04:42 PM Pete McCann said the following: [...] > In the multiple MSA case, we should also have text which states that > the sender can use any of the applicable MSAs, and the receiver should > be prepared to validate the message based on any of the MSAs. > > Also note that, given (1) and (2) above, if we add the lifetime field, > it simply means that an authentication extension is not necessary to > either add at the sender or check at the receiver. One possible > approach to backwards compatibility is to mandate that the FA adds it > anyway but just allow the HA to skip it when the lifetime=0. This seems like a good proposal to me. Henrik -- 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 Jun 14 00:33:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di36v-0001QD-QU; Tue, 14 Jun 2005 00:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di36u-0001Px-Dz for mip4@megatron.ietf.org; Tue, 14 Jun 2005 00:33:12 -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 AAA15469 for ; Tue, 14 Jun 2005 00:33:09 -0400 (EDT) Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di3TJ-0001CK-Qm for mip4@ietf.org; Tue, 14 Jun 2005 00:56:22 -0400 Received: from usdaln07347 (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j5E4WwJ8001413; Mon, 13 Jun 2005 23:32:59 -0500 (CDT) Message-Id: <200506140432.j5E4WwJ8001413@auds951.usa.alcatel.com> From: "Tim Ozugur" To: Date: Mon, 13 Jun 2005 23:32:54 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-index: AcVq1E4jGciaydskSnOx/KV3UZDgVAAAAgzAAAAxcdABcPq8IAAAQZuA X-Spam-Score: 0.2 (/) X-Scan-Signature: bc751b94b9e719c152b6b70b67620ccf Subject: [Mip4] Call For Participation: BWAN 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="===============1383419917==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1383419917== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C57070.39E53D60" This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C57070.39E53D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 (Apologies if you are receiving this message more than once) =20 ----------------------------------------------------------- CALL FOR PARTICIPATION International Workshop on Broadband Wireless Access=20 Network on fixed network (BWAN 2005) ( http://www.bwan.org/) ORLANDO, FL - JUNE 15, 2005 co-located with International Conference on=20 Multimedia Services Access Networks (MSAN'05)=20 CO_SPONSORED BY IEEE ------------------------------------------------------------------------ =20 Agenda:=20 =20 8h30-8h45 Welcome=20 8h45-9h00 Opening remarks and Introduction 9h00-9h30 Invited Paper : Flash OFDM technical=20 overview and business opportunities=20 =20 9h00-10h40 Session 1 Wireless access =20 Chaired by Lars Johnsson Senior Director, Product Marketing, Flarion Technologies - Performance Modeling of an Upstream Link =20 in Open Access Networks Olav-Norvald Osterbo =20 - Wireless LAN for Multimedia=20 Vivek S. Deshpande =20 - Performance Evaluation of a Hybrid LMDS Architecture =20 Chris Basios =20 - Comparative Study of Coding/Spreading Trade off in Adaptive = Decision Feedback Multiuser Detection Using Turbo and =20 Convolutional Codes =20 V. D. Trajkovic and P. B. Rapajic =20 =20 10h40-11h30 Break 11h30-11h35 Panel Introduction =20 11h35-13h00 Panel : Trends and strategies for broadband=20 wireless access on fix network for 2010 =20 Panelists : Jerry Power,=20 Marketing Director, Alcatel;=20 Patrick Leary,=20 Assist. V.P Marketing, Alvarion;=20 Lars Johnsson,=20 Senior Director, Flarion Technologies;=20 Olav-Norvald Osterbo,=20 Senior Researc Scientist, Telenor; =20 Pandraig Moran,=20 CTO, IPunplugged. =20 13h00-14h00 Lunch and Break =20 14h00-14h30 Invited Paper : Wimax technical=20 and business opportunities 14h30-15h45 Session 2 Wireless QoS =20 Chaired by Patrick Leary Assist. V.P Marketing, Alvarion - IEEE 802.16 based Radio Access Network with QoS =20 P. Manohar and S.H Srinivasan =20 - Optimization of IEEE 802.11 Resource-Sharing Infrastructures =20 with Interference Constraints=20 E. Costa-Montenegro, F.J Gonzalez-Castano,=20 P.S .Rodriguez-Hernadez, J.C Burguillo-Rial =20 - Performance issues of voice over wireless LAN and comparison=20 with wired LAN=20 A. Bhatia=20 =20 15h45-16h15 Break 16h15-16h45 Invited Paper : Mobility and security=20 in Broadband wireless access 16h45-18h Session 3 Security and mobility =20 Chaired by P=E1draig Moran=20 CTO, IPunplugged - Securing and Dynamic Mobility Management of the Wireless=20 Inter-Networks in Public and Private Places =20 N. Janakiraman =20 - Guaranteed Quality of Service and Seamless Continuity of an=20 end-user's sessions thanks to the IP Mobility Manager=20 Annelise Massiera, Adrian Duda, Helene Vigue =20 - Multilateral Security for IP-Service Provisioning Thomas J. Wilke, Tor Hjalmar Johannessen =20 =20 18h00 Conclusion =20 =20 ------------------------------------------------------------=20 ------=_NextPart_000_0028_01C57070.39E53D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
(Apologies if you=20 are receiving this message more than once)
 
-----------------------------------------------------------

       &nbs= p;         CALL=20 FOR PARTICIPATION

International Workshop on Broadband = Wireless=20 Access

       &nbs= p; Network=20 on fixed network (BWAN 2005)

       &nbs= p;          (http://www.bwan.org/)

       &nbs= p; =20 ORLANDO, FL - JUNE 15, 2005

     co-located = with=20 International Conference on

Multimedia Services Access Networks = (MSAN'05)=20

       &nbs= p;    =20 CO_SPONSORED BY IEEE

----------------------------------------------= --------------------------
 
Agenda: 
  &n= bsp;    =20
8h30-8h45   Welcome =
8h45-9h00  =20 Opening remarks and Introduction

9h00-9h30   Invited Paper = : Flash=20 OFDM technical
       &nbs= p;   =20 overview and business opportunities 
 
9h00-10h40   Session 1 = Wireless=20 access         =20
      &n= bsp;           &nb= sp;    =20 Chaired by  Lars=20 Johnsson
       &nbs= p;            = ;   =20 Senior Director, Product Marketing,=20 Flarion Technologies
     - = Performance=20 Modeling of an Upstream Link  
         &nb= sp;  =20  in Open Access=20 Networks
       &nbs= p;            = ;   =20 Olav-Norvald = Osterbo    
          - = Wireless=20 LAN for Multimedia
       &nbs= p;            = ;   =20 Vivek S. Deshpande     
       &nbs= p;  - Performance Evaluation of a Hybrid = LMDS=20 Architecture    
          &nbs= p;           &= nbsp;=20 Chris=20 Basios    
       &nbs= p; =20 - Comparative Study of = Coding/Spreading=20 Trade off in Adaptive  
         &nb= sp;  =20  Decision=20 Feedback Multiuser Detection Using Turbo and  
         &nb= sp;  =20  Convolutional Codes      =
       &nbs= p;            = ;   =20 V. D. Trajkovic and P. B.=20 Rapajic   
 
10h40-11h30 Break

11h30-11h35 Panel Introduction =20
11h35-13h00 Panel : Trends and strategies for=20 broadband
       &nbs= p;   =20 wireless access on fix network for = 2010   =20
Panelists : Jerry Power,=20
       &nbs= p;                   &nb= sp;  Marketing Director, = Alcatel;
       &nbs= p;             &nb= sp;  Patrick=20 Leary,
       &nbs= p;                   &nb= sp;  Assist. V.P Marketing, = Alvarion;
       &nbs= p;             &nb= sp;  Lars=20 Johnsson, =
       &nbs= p;                   &nb= sp;  Senior Director, = Flarion Technologies;
       &nbs= p;             &nb= sp;  Olav-Norvald Osterbo,
       &nbs= p;                   &nb= sp; =20 Senior Researc Scientist, Telenor;  
       &nbs= p;             &nb= sp;  Pandraig=20 Moran,
       &nbs= p;                   &nb= sp;  CTO,=20 IPunplugged.
 
13h00-14h00 Lunch=20 and Break
    =20
14h00-14h30 Invited Paper : Wimax technical=20
       &nbs= p;   =20 and business opportunities

14h30-15h45 Session 2=20 Wireless QoS           =
      &n= bsp;           &nb= sp;    =20 Chaired by  Patrick = Leary
                     &nbs= p;     =20  Assist. V.P Marketing,=20 Alvarion
         &nb= sp;-  IEEE 802.16 = based Radio=20 Access Network with QoS  
          =            &nb= sp; =20 P. Manohar and S.H=20 Srinivasan   
    -=20 Optimization of IEEE 802.11 Resource-Sharing=20 Infrastructures  
       &nbs= p;       with Interference=20 Constraints 
       &nbs= p;            = ;   =20 E. Costa-Montenegro, F.J Gonzalez-Castano, =
       &nbs= p;            = ;   =20 P.S .Rodriguez-Hernadez, = J.C=20 Burguillo-Rial   
    -=20 Performance issues of voice over wireless LAN and = comparison
       &nbs= p;       with wired=20 LAN 
       &nbs= p;            = ;   =20 A. Bhatia 
 
15h45-16h15 Break

16h15-16h45 Invited Paper : Mobility and security =
       &nbs= p;   =20 in Broadband wireless access

16h45-18h   Session 3=20 Security and=20 mobility          =20
     &nbs= p;            = ;     =20 Chaired by P=E1draig Moran
       &nbs= p;            = ;   =20 CTO,=20 IPunplugged
    -=20 Securing and Dynamic Mobility Management of the = Wireless=20
       &nbs= p;       Inter-Networks in Public and Private=20 Places   
       &nbs= p;            = ;   =20 N. Janakiraman  
    -=20 Guaranteed Quality of Service and Seamless = Continuity of=20 an
       &nbs= p;       end-user's sessions thanks to the IP Mobility Manager 
        &nbs= p;            = ;   Annelise=20 Massiera, Adrian Duda, = Helene Vigue   
     =20 - Multilateral = Security=20 for IP-Service = Provisioning              =           
       &nbs= p;            = ;   =20 Thomas J. Wilke, Tor = Hjalmar=20 Johannessen    
=
 
18h00      =20 Conclusion  
 
------------------------------------------------------------ 
------=_NextPart_000_0028_01C57070.39E53D60-- --===============1383419917== 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/ --===============1383419917==-- From mip4-bounces@ietf.org Wed Jun 15 12:55:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DibAg-0008Lr-Lx; Wed, 15 Jun 2005 12:55:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiO6C-0001bn-G3; Tue, 14 Jun 2005 22:57: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 WAA29452; Tue, 14 Jun 2005 22:57:50 -0400 (EDT) Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiOSn-00068v-9Y; Tue, 14 Jun 2005 23:21:14 -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 j5F2ulIW027121; Tue, 14 Jun 2005 22:56:50 -0400 (EDT) Message-ID: <0c9101c57155$e68dd1e0$6401a8c0@hpn307pc2> From: "Wendi Heinzelman" To: "Wendi Heinzelman" References: Date: Tue, 14 Jun 2005 22:54:33 -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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 Jun 2005 12:55:21 -0400 Cc: Haiyun Luo , dirk.westhoff@netlab.nec.de, bettstetter@ieee.org Subject: [Mip4] Mobicom'05 student research competition deadline: June 20 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 -------------------------------------------- ACM Student Research Competition -------------------------------------------- For the first time, the annual SIGMOBILE MOBICOM conference is hosting the ACM Student Research Competition (SRC). Students submitting to the MOBICOM 2005 Poster Program can opt to have their posters considered also by the SRC committee. Selected competitors will receive up $500USD for their conference travel, depending on need and eligibility. Competitors should be prepared to attend the poster session and, if selected for further competition, give a short talk about their research projects. Winners will be announced at the conference. To participate: The Student Research Competition is open to graduate and undergraduate students whose submissions are accepted by the SRC committee. To be considered, complete a submission to the Student Poster Programm by June 20, 2005, and indicate that you would like to participate in the SRC. Current ACM student membership and student status as of the submission deadline are required for the lead student. Contact: Haiyun Luo, University of Illinois, (haiyun@cs.uiuc.edu) Dirk Westhoff, NEC Research Europe, (dirk.westhoff@netlab.nec.de) -- 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 Jun 16 11:53:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diwg9-00078w-4D; Thu, 16 Jun 2005 11:53:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diwg7-00078h-7B for mip4@megatron.ietf.org; Thu, 16 Jun 2005 11:53: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 LAA04575 for ; Thu, 16 Jun 2005 11:53:07 -0400 (EDT) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dix2z-0000Bj-DM for Mip4@ietf.org; Thu, 16 Jun 2005 12:16:54 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 268E190007 for ; Thu, 16 Jun 2005 11:52:56 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29999-08 for ; Thu, 16 Jun 2005 11:52:54 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 16 Jun 2005 11:52:54 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jun 2005 11:52:50 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D906D@ames.starentnetworks.com> Thread-Topic: HoA=0.0.0.0 question Thread-Index: AcVyiy+2mreMhAi2TKCL+/vP2e0Pvw== From: "Chowdhury, Kuntal" To: X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Mip4] HoA=0.0.0.0 question 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, I have a question on MIP RRQ with HoA=3D0.0.0.0. It is a common practice = in the industry today to use HoA=3D0.0.0.0 in the RRQ to request for a = dynamic HoA assignment. The question I have is: when the HA receives a = RRQ with HoA=3D0.0.0.0 does it always treat that as a NEW registration = request even if there is an unexpired mobility binding for the same NAI = in the HA? Thanks, Kuntal -- 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 Jun 16 13:15:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DixxI-0004DY-1o; Thu, 16 Jun 2005 13:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DixxH-0004D9-8o for mip4@megatron.ietf.org; Thu, 16 Jun 2005 13:15: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 NAA16070 for ; Thu, 16 Jun 2005 13:14:56 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiyKB-00069b-Nl for Mip4@ietf.org; Thu, 16 Jun 2005 13:38:45 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5GGgEP09721; Thu, 16 Jun 2005 09:42:14 -0700 X-mProtect: <200506161642> Nokia Silicon Valley Messaging Protection Received: from danira-pool049221.americas.nokia.com (10.241.49.221, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdN1FVYr; Thu, 16 Jun 2005 09:42:12 PDT Message-ID: <42B1B36A.9070806@iprg.nokia.com> Date: Thu, 16 Jun 2005 10:14:18 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip4] HoA=0.0.0.0 question References: <8A16DAD84432534FBFC19FD92B50512F035D906D@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F035D906D@ames.starentnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Hello Kuntal, Can you explain what difference it would make one way or the other? Regards, Charlie P. Chowdhury, Kuntal wrote: >Hi all, > >I have a question on MIP RRQ with HoA=0.0.0.0. It is a common practice in the industry today to use HoA=0.0.0.0 in the RRQ to request for a dynamic HoA assignment. The question I have is: when the HA receives a RRQ with HoA=0.0.0.0 does it always treat that as a NEW registration request even if there is an unexpired mobility binding for the same NAI in the HA? > >Thanks, >Kuntal > > > -- 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 Jun 16 13:31:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiyD9-0007Ep-Ip; Thu, 16 Jun 2005 13:31:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiyD6-0007EL-RT for mip4@megatron.ietf.org; Thu, 16 Jun 2005 13:31: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 NAA16627 for ; Thu, 16 Jun 2005 13:31:18 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiyZg-0007Pb-Gm for Mip4@ietf.org; Thu, 16 Jun 2005 13:54:45 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5GGwTw25683; Thu, 16 Jun 2005 09:58:29 -0700 X-mProtect: <200506161658> Nokia Silicon Valley Messaging Protection Received: from danira-pool049221.americas.nokia.com (10.241.49.221, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdozLtcU; Thu, 16 Jun 2005 09:58:27 PDT Message-ID: <42B1B73A.8080909@iprg.nokia.com> Date: Thu, 16 Jun 2005 10:30:34 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip4] HoA=0.0.0.0 question References: <8A16DAD84432534FBFC19FD92B50512F03411F39@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F03411F39@ames.starentnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Hello Kuntal, Based on your example, I do not believe that the distinction would case any change to the base Mobile IPv4 specification. Would this be a new document within the aaa working group? Regards, Charlie P. Chowdhury, Kuntal wrote: >Hi Charlie, > >Based on local policy the HA may have to process a new RRQ differently than a re-registration. For example, the local policy may not require the HA to perform AAA auth (i.e. process MN-AAA) every time the MN performs re-registration (i.e. when it has a valid binding) but the local policy requires AAA auth when there is no active binding (new RRQ). > >This is an example scenario. Is there any RFC/ID that explains the HoA=0.0.0.0 behavior for MIPv4? > >Regards, >Kuntal > > > > > >>-----Original Message----- >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>Sent: Thursday, June 16, 2005 12:14 PM >>To: Chowdhury, Kuntal >>Cc: Mip4@ietf.org >>Subject: Re: [Mip4] HoA=0.0.0.0 question >> >> >> >>Hello Kuntal, >> >>Can you explain what difference it would make >>one way or the other? >> >>Regards, >>Charlie P. >> >> >>Chowdhury, Kuntal wrote: >> >> >> >>>Hi all, >>> >>>I have a question on MIP RRQ with HoA=0.0.0.0. It is a >>> >>> >>common practice in the industry today to use HoA=0.0.0.0 in >>the RRQ to request for a dynamic HoA assignment. The question >>I have is: when the HA receives a RRQ with HoA=0.0.0.0 does >>it always treat that as a NEW registration request even if >>there is an unexpired mobility binding for the same NAI in the HA? >> >> >>>Thanks, >>>Kuntal >>> >>> >>> >>> >>> >> >> >> -- 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 Jun 16 13:31:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiyDT-0007OG-NY; Thu, 16 Jun 2005 13:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiyDO-0007MK-1h for mip4@megatron.ietf.org; Thu, 16 Jun 2005 13:31:42 -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 NAA16810 for ; Thu, 16 Jun 2005 13:31:34 -0400 (EDT) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiyPt-0006dL-OZ for Mip4@ietf.org; Thu, 16 Jun 2005 13:44:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id CAFD690007; Thu, 16 Jun 2005 13:20:45 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31011-07; Thu, 16 Jun 2005 13:20:44 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 16 Jun 2005 13:20:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Thu, 16 Jun 2005 13:20:44 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F03411F39@ames.starentnetworks.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcVylug0sDNjvKg5Qy2ZuXkh3QNPMAAADHzQ From: "Chowdhury, Kuntal" To: "Charles E. Perkins" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Hi Charlie, Based on local policy the HA may have to process a new RRQ differently = than a re-registration. For example, the local policy may not require = the HA to perform AAA auth (i.e. process MN-AAA) every time the MN = performs re-registration (i.e. when it has a valid binding) but the = local policy requires AAA auth when there is no active binding (new = RRQ). This is an example scenario. Is there any RFC/ID that explains the = HoA=3D0.0.0.0 behavior for MIPv4? Regards, Kuntal > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, June 16, 2005 12:14 PM > To: Chowdhury, Kuntal > Cc: Mip4@ietf.org > Subject: Re: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 >=20 > Hello Kuntal, >=20 > Can you explain what difference it would make > one way or the other? >=20 > Regards, > Charlie P. >=20 >=20 > Chowdhury, Kuntal wrote: >=20 > >Hi all, > > > >I have a question on MIP RRQ with HoA=3D0.0.0.0. It is a=20 > common practice in the industry today to use HoA=3D0.0.0.0 in=20 > the RRQ to request for a dynamic HoA assignment. The question=20 > I have is: when the HA receives a RRQ with HoA=3D0.0.0.0 does=20 > it always treat that as a NEW registration request even if=20 > there is an unexpired mobility binding for the same NAI in the HA? > > > >Thanks, > >Kuntal > > > > =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 Thu Jun 16 15:29:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj03d-0001iF-SX; Thu, 16 Jun 2005 15:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dizwm-00087s-IP for mip4@megatron.ietf.org; Thu, 16 Jun 2005 15:22:40 -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 PAA28319 for ; Thu, 16 Jun 2005 15:22:27 -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.33) id 1Dj0Ja-0006QS-3t for mip4@ietf.org; Thu, 16 Jun 2005 15:46:14 -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 j5GJMPBf029759 for ; Thu, 16 Jun 2005 15:22:28 -0400 (EDT) Received: from ECE.NEU.EDU ([129.10.60.216]) by calvin.ece.neu.edu (SAVSMTP 3.1.0.29) with SMTP id M2005061615222832477 for ; Thu, 16 Jun 2005 15:22:28 -0400 Received: from localhost (basagni@localhost) by ECE.NEU.EDU (8.12.8/8.12.5/Submit) with ESMTP id j5GJMSTG012400 for ; Thu, 16 Jun 2005 15:22:28 -0400 Date: Thu, 16 Jun 2005 15:22:28 -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: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Thu, 16 Jun 2005 15:29:44 -0400 Subject: [Mip4] IEEE SECON 2005: Call for Posters 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 POSTERS *** IEEE International Conference on Sensor and Ad Hoc Communications and Networks SECON 2005 Santa Clara, CA, 26-29 September 2005 http://inrg.cse.ucsc.edu/secon05/home.html ------------------------------------------------------------ The Second IEEE International Conference on Sensor and Ad Hoc Communications and Networks (SECON) will include 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. Since one of the main goals of this venue is to foster collaboration between industry and academia, participation of researchers/developers from industry and posters reporting joint work between industry and academia are especially encouraged. Submissions should be in the form of a proposal describing the main contributions of the poster and the merits of the proposed ideas. If available, preliminary results can also be included. Poster proposals will be evaluated, mainly based on their potential to generate interesting discussions and exchange of ideas. Accepted authors will have a space in the poster session room to display their posters and describe their work in discussions with interested attendees. The presentation material will be made available for download on the SECON Web site. Please submit your proposal (PDF format) by email to secon05-posters@comsoc.org. Submissions should not be more than three pages in length. The documents must contain the authors' names, affiliations, and contact information. The deadline for submission is *July 29, 2005* (23:59 PDT). Acceptance notifications will be sent by August 19, 2005. Poster Session Chair: David Gay, Intel Research, Berkeley, USA -- 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 Jun 16 15:35:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj08x-0002uZ-5r; Thu, 16 Jun 2005 15:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj08v-0002uT-Bz for mip4@megatron.ietf.org; Thu, 16 Jun 2005 15:35: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 PAA29541 for ; Thu, 16 Jun 2005 15:35:07 -0400 (EDT) Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj0Vr-0007AV-5L for Mip4@ietf.org; Thu, 16 Jun 2005 15:58:56 -0400 Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Jun 2005 15:34:42 -0400 Message-ID: From: Avi Lior To: "'Charles E. Perkins'" , "Chowdhury, Kuntal" Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Thu, 16 Jun 2005 15:34:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 Hi Charlie, Actually I am not sure it's a AAA problem either. The original scenario Kuntal raises can happen with or without the presence of a AAA function right? The side-effect (Kuntal's explaination) is what can happen with a AAA. IMO therefore, MIP needs to be more explicit as to what happens eventhough at the pure MIP context it may not make a difference. That is, we need to resolve Kuntal's original question in the MIP context: "when the HA receives a RRQ with HoA=0.0.0.0 does it always treat that as a NEW registration request even if there is an unexpired mobility binding for the same NAI in the HA?" We can either require the mobile to use an HoA when re-registering or only use the NAI to index the binding cache. > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, June 16, 2005 1:31 PM > To: Chowdhury, Kuntal > Cc: Mip4@ietf.org > Subject: Re: [Mip4] HoA=0.0.0.0 question > > > > Hello Kuntal, > > Based on your example, I do not believe that the distinction > would case any change to the base Mobile IPv4 specification. > Would this be a new document within the aaa working group? > > Regards, > Charlie P. > > Chowdhury, Kuntal wrote: > > >Hi Charlie, > > > >Based on local policy the HA may have to process a new RRQ > differently > >than a re-registration. For example, the local policy may > not require > >the HA to perform AAA auth (i.e. process MN-AAA) every time the MN > >performs re-registration (i.e. when it has a valid binding) but the > >local policy requires AAA auth when there is no active binding (new > >RRQ). > > > >This is an example scenario. Is there any RFC/ID that explains the > >HoA=0.0.0.0 behavior for MIPv4? > > > >Regards, > >Kuntal > > > > > > > > > > > >>-----Original Message----- > >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > >>Sent: Thursday, June 16, 2005 12:14 PM > >>To: Chowdhury, Kuntal > >>Cc: Mip4@ietf.org > >>Subject: Re: [Mip4] HoA=0.0.0.0 question > >> > >> > >> > >>Hello Kuntal, > >> > >>Can you explain what difference it would make > >>one way or the other? > >> > >>Regards, > >>Charlie P. > >> > >> > >>Chowdhury, Kuntal wrote: > >> > >> > >> > >>>Hi all, > >>> > >>>I have a question on MIP RRQ with HoA=0.0.0.0. It is a > >>> > >>> > >>common practice in the industry today to use HoA=0.0.0.0 in > >>the RRQ to request for a dynamic HoA assignment. The question > >>I have is: when the HA receives a RRQ with HoA=0.0.0.0 does > >>it always treat that as a NEW registration request even if > >>there is an unexpired mobility binding for the same NAI in the HA? > >> > >> > >>>Thanks, > >>>Kuntal > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > -- > 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 Thu Jun 16 15:56:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0T5-0007ZK-EW; Thu, 16 Jun 2005 15:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0T2-0007Yy-VQ for mip4@megatron.ietf.org; Thu, 16 Jun 2005 15:56: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 PAA01419 for ; Thu, 16 Jun 2005 15:55:55 -0400 (EDT) Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj0py-0000D3-VQ for Mip4@ietf.org; Thu, 16 Jun 2005 16:19:44 -0400 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 59ADC3821B; Thu, 16 Jun 2005 21:55:38 +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 42FDE37FAE; Thu, 16 Jun 2005 21:55:38 +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 0002437E46; Thu, 16 Jun 2005 21:55:37 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1Dj0Sf-00087x-C9; Thu, 16 Jun 2005 21:55:37 +0200 Message-ID: <42B1D938.5070701@levkowetz.com> Date: Thu, 16 Jun 2005 21:55:36 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip4] HoA=0.0.0.0 question References: <8A16DAD84432534FBFC19FD92B50512F03411F39@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F03411F39@ames.starentnetworks.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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Mip4@ietf.org, "Charles E. Perkins" 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="===============2129637512==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2129637512== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAB70AEB91D6603B765BB7EB4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAB70AEB91D6603B765BB7EB4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kuntal, On 2005-06-16 19:20 Chowdhury, Kuntal said the following: > Hi Charlie, > > Based on local policy the HA may have to process a new RRQ > differently than a re-registration. For example, the local policy may > not require the HA to perform AAA auth (i.e. process MN-AAA) every > time the MN performs re-registration (i.e. when it has a valid > binding) but the local policy requires AAA auth when there is no > active binding (new RRQ). Personal opinion: You have the answer there. If there is an active binding, you don't perform AAA auth, in this case. Never mind whether the RRQ requests a new dynamic address assignment or not. On the other hand, if the policy specifies AAA re-auth before address assignment, never mind any active sessions, the answer should be pretty clear too - do it :-) (Of course, a decent implementation should return the same HoA as the currently active binding has, also in the event of a new RRQ with 0.0.0.0 when there is an active binding. This is not an anomalous case, as the HA has to be prepared for a client which has re-booted or been turned off and on by the user. But I don't know if this really has any bearing on your original question.) > This is an example scenario. Is there any RFC/ID that explains the > HoA=0.0.0.0 behavior for MIPv4? RFC 3344. Henrik > Regards, Kuntal > > > >> -----Original Message----- From: Charles E. Perkins >> [mailto:charliep@iprg.nokia.com] Sent: Thursday, June 16, 2005 >> 12:14 PM To: Chowdhury, Kuntal Cc: Mip4@ietf.org Subject: Re: >> [Mip4] HoA=0.0.0.0 question >> >> >> >> Hello Kuntal, >> >> Can you explain what difference it would make one way or the other? >> >> >> Regards, Charlie P. --------------enigAB70AEB91D6603B765BB7EB4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFCsdk5eVhrtTJkXCMRAvp+AJ9DpaAsjsyxDVomLQcu/tTehWhf5gCdHs8d Y9jPxsk/AvVHpEh0+/eZ+N4= =Zu/h -----END PGP SIGNATURE----- --------------enigAB70AEB91D6603B765BB7EB4-- --===============2129637512== 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/ --===============2129637512==-- From mip4-bounces@ietf.org Thu Jun 16 16:16:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0iG-0004jv-9Q; Thu, 16 Jun 2005 16:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0iF-0004je-09 for mip4@megatron.ietf.org; Thu, 16 Jun 2005 16:11: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 QAA05460 for ; Thu, 16 Jun 2005 16:11:37 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj15A-0002Jh-Ci for Mip4@ietf.org; Thu, 16 Jun 2005 16:35:26 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5GJd9826462; Thu, 16 Jun 2005 12:39:09 -0700 X-mProtect: <200506161939> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddaYx4y; Thu, 16 Jun 2005 12:39:07 PDT Message-ID: <42B1DCE5.5476BBBE@iprg.nokia.com> Date: Thu, 16 Jun 2005 13:11:17 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Mip4] HoA=0.0.0.0 question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Hello Avi, Avi Lior wrote: > IMO therefore, MIP needs to be more explicit as to what happens eventhough > at the pure MIP context it may not make a difference. If you want to propose some text, then maybe I would understand what the problem is. If it doesn't make any difference in the "pure MIP context", then I am reluctant to make any further specification for it within the "pure MIP context" document. > That is, we need to resolve Kuntal's original question in the MIP context: > "when the HA receives a RRQ with HoA=0.0.0.0 does > it always treat that as a NEW registration request even if > there is an unexpired mobility binding for the same NAI in the HA?" As far as I can tell from the discussion, a competent engineer could build an excellent system regardless of whether the registration request was considered "new" or not. > We can either require the mobile to use an HoA when re-registering or only > use the NAI to index the binding cache. Either of these solutions sound overly restrictive to me, of course depending on the restraints posed by the legacy systems involved. Regards, Charlie P. -- 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 pana-bounces@ietf.org Thu Jun 16 16:16:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0iQ-0004ks-NF; Thu, 16 Jun 2005 16:11:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0iO-0004kU-Uu for pana@megatron.ietf.org; Thu, 16 Jun 2005 16:11: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 QAA05487 for ; Thu, 16 Jun 2005 16:11:47 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj15L-0002LX-DY for pana@ietf.org; Thu, 16 Jun 2005 16:35:36 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j5GKBlnr029363; Fri, 17 Jun 2005 05:11:47 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j5GKBkaf001050; Fri, 17 Jun 2005 05:11:46 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id FAA01020 ; Fri, 17 Jun 2005 05:11:46 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j5GKBkGc020158; Fri, 17 Jun 2005 05:11:46 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j5GKBk5C008637; Fri, 17 Jun 2005 05:11:46 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j5GKBjdF019312; Fri, 17 Jun 2005 05:11:45 +0900 (JST) Received: from steelhead ([172.30.24.135]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0II7006RN1FEDS@tsbpo1.po.toshiba.co.jp>; Fri, 17 Jun 2005 05:11:40 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Dixye-0005s9-00; Thu, 16 Jun 2005 10:16:28 -0700 Date: Thu, 16 Jun 2005 13:16:28 -0400 From: Yoshihiro Ohba Subject: Re: [Pana] PANA and lower layer ciphering In-reply-to: <7210B31550AC934A8637D6619739CE69055ABD79@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Message-id: <20050616171628.GB20801@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: "Salowey, Joe" , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.9i References: <7210B31550AC934A8637D6619739CE69055ABD79@e2k-sea-xch2.sea-alpha.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Yoshihiro Ohba , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pana-bounces@ietf.org Errors-To: pana-bounces@ietf.org On Wed, Jun 15, 2005 at 04:41:43PM -0700, Salowey, Joe wrote: > > > > > Although PaC-EP master keys are cryptographically independent > > of each other and of PANA keys, PaC-EP master keys are > > cryptographically dependent on the AAA-Key because they are > > derived from AAA-Key. > > > > [Joe] The draft does not state that the PaC-EP master key is > cryptographically independent of the PANA keys. The best way to achieve > this is to specify the derivation in this draft so that the keys are > independent. I agree. > > > > This would help eliminate > > > the possibility that a AAA-key is used directly by a lower layer > > > protocol or that a lower-layer key is derived that is not > > > cryptographically independent from the PANA keys. This should be > > > specified in the PANA protocol spec rather than trying to > > coordinate > > > it in multiple lower layer specs. > > > > I believe that key derivation algorithms for PaC-EP master > > keys cannot be independent of lower layers, because lower > > layer parameters such as authenticator identifier would need > > to be bound to the master keys. > > Thus, I think what we can describe in the PANA protocol spec > > is something like: "The PaC-EP master keys MUST be drived > > from the AAA-Key, bound to appropriate lower layer parameters > > and cryptographycally independent of each other". > > > > [Joe] Why must they be bound to lower layer parameters? This should be > done in the lower layer instead of creating dependencies in PANA on the > lower layer. PANA exports a key and the lower layer is free to use it > how it wishes, including deriving additional keys that have specific > binding to lower layer parameters. At least the PaC-EP master key needs to be associated with the identity of the consumers (i.e., the PaC and EP) so that the PaC and EP can make sure that which master key is used for which peer. > > > > > > > If negotiation is necessary then why is the > > Protection-Capability AVP > > > only indicated by the PAA, shouldn't the PaC be able to > > indicate this > > > as well? > > > > The current PANA design on this is that ciphering layer is > > not negotiable. This is because if we allow multiple choices > > on ciphering layers, then it might end up with a situation > > where some PaC uses L3 ciphering while others use L2 > > ciphering in the same access network, which might open up a > > security hole. > > > > [Joe] Interesting, can you elaborate on this problem? > Assume that there are two EPs on a single IP link where one EP is an WLAN AP using IEEE 802.11i and another EP is an access router using IPsec. Note that there is at least one open-access AP on the link to make this work. Then an unauthorized attacker may access the link via open-access AP to launch L3 or higher layer attacks on the legitimate PaCs that are using 802.11i. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From mip4-bounces@ietf.org Thu Jun 16 16:51:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj1KY-0001k4-4c; Thu, 16 Jun 2005 16:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj1KQ-0001jz-0d for mip4@megatron.ietf.org; Thu, 16 Jun 2005 16:51: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 QAA14279 for ; Thu, 16 Jun 2005 16:51:04 -0400 (EDT) Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj1hM-0006ad-R5 for Mip4@ietf.org; Thu, 16 Jun 2005 17:14:54 -0400 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 4D0F437F56; Thu, 16 Jun 2005 22:50:57 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 1F42237EEE; Thu, 16 Jun 2005 22:50:57 +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 7131337E43; Thu, 16 Jun 2005 22:50:56 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1Dj1KB-0007AA-Bu; Thu, 16 Jun 2005 22:50:55 +0200 Message-ID: <42B1E62E.7060707@levkowetz.com> Date: Thu, 16 Jun 2005 22:50:54 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Mip4] HoA=0.0.0.0 question References: In-Reply-To: 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: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Mip4@ietf.org, "Chowdhury, Kuntal" , "'Charles E. Perkins'" 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="===============1920514160==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1920514160== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig00096462D68ED58E167FB2B8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00096462D68ED58E167FB2B8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Avi, On 2005-06-16 21:34 Avi Lior said the following: > Hi Charlie, > > Actually I am not sure it's a AAA problem either. The original scenario > Kuntal raises can happen with or without the presence of a AAA function > right? > > The side-effect (Kuntal's explaination) is what can happen with a AAA. > > IMO therefore, MIP needs to be more explicit as to what happens eventhough > at the pure MIP context it may not make a difference. I think here we're at the crux of the matter: Not only doesn't it make a difference, there really isn't a difference at the MIP level, I believe. > That is, we need to resolve Kuntal's original question in the MIP context: > "when the HA receives a RRQ with HoA=0.0.0.0 does > it always treat that as a NEW registration request even if > there is an unexpired mobility binding for the same NAI in the HA?" Well, since there really isn't any difference between "re-registration" and "new registration" in MIP4, there really isn't a distinction, protocol-wise... > We can either require the mobile to use an HoA when re-registering or only > use the NAI to index the binding cache. This seems to argue for creating a distinction, based on the value of the HoA field, between some "new registrations" and other "re-registrations". I'm not convinced that this is wise, and I'm not convinced it is necessary. Possibly it could be argued that it would be advantageous to add to the specification that: "If there exists an active binding for the MN when a registration request with the Home Address field set to 0.0.0.0 is received by the HA, the HA SHOULD return the same Home Address as for the already existing binding." But that is maybe a different matter ? (As some background to this discussion, I coded the HA side of dynamic address assignment some 2-3 years ago. I found that since the HA can never know whether the MN has been turned on and off between registrations, and the MN really can't assume that the HA hasn't had a power outage, malfunction, or what-not, it turned out that you really have to find a way to handle a lot of different combinations of existing and non-existing active bindings, 0.0.0.0 requests, and requests with old, timed-out HoAs. Any attempt at specifying that the MN "must" use an assigned HoA when "re-registering" ran smack into the realities of things which said that there were no way of guaranteeing that behaviour, in the face of everything that might happen with the MN, the HA, and the link between them ... Or to put it in a completely different way - the randomness and unpredictability of changing wireless links makes it a strong protocol feature that there indeed is no difference between "new registration" and "re-registration".) Henrik >> -----Original Message----- >> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >> Sent: Thursday, June 16, 2005 1:31 PM >> To: Chowdhury, Kuntal >> Cc: Mip4@ietf.org >> Subject: Re: [Mip4] HoA=0.0.0.0 question >> >> >> >> Hello Kuntal, >> >> Based on your example, I do not believe that the distinction >> would case any change to the base Mobile IPv4 specification. >> Would this be a new document within the aaa working group? >> >> Regards, >> Charlie P. --------------enig00096462D68ED58E167FB2B8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFCseYueVhrtTJkXCMRApGGAKCjUxKWino1qbds9KIrkI3JbunjpwCcCTpR oQD+mc09ivR7FW7CbVJOAtE= =BW5W -----END PGP SIGNATURE----- --------------enig00096462D68ED58E167FB2B8-- --===============1920514160== 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/ --===============1920514160==-- From mip4-bounces@ietf.org Thu Jun 16 18:16:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj2ep-0005OJ-FX; Thu, 16 Jun 2005 18:16:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj2eo-0005OE-6N for mip4@megatron.ietf.org; Thu, 16 Jun 2005 18:16:18 -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 SAA20660 for ; Thu, 16 Jun 2005 18:16:12 -0400 (EDT) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj31m-00035T-K6 for Mip4@ietf.org; Thu, 16 Jun 2005 18:40:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 9BCD890008; Thu, 16 Jun 2005 18:16:00 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00747-05; Thu, 16 Jun 2005 18:15:59 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 16 Jun 2005 18:15:59 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Thu, 16 Jun 2005 18:15:59 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D9078@ames.starentnetworks.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcVyrWCMAnxyOwUcQW+NeMZ30jFtpgAEB7Rw From: "Chowdhury, Kuntal" To: "Henrik Levkowetz" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: Mip4@ietf.org, "Charles E. Perkins" 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 and Charlie, What I understand from your responses is that HoA=3D0 should be treated = by the HA as a new registration request (since an HoA assignment is = involved here). Is this a correct understanding? Regards, Kuntal > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Thursday, June 16, 2005 2:56 PM > To: Chowdhury, Kuntal > Cc: Charles E. Perkins; Mip4@ietf.org > Subject: Re: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 > Hi Kuntal, >=20 > On 2005-06-16 19:20 Chowdhury, Kuntal said the following: > > Hi Charlie, > >=20 > > Based on local policy the HA may have to process a new RRQ > > differently than a re-registration. For example, the local=20 > policy may > > not require the HA to perform AAA auth (i.e. process MN-AAA) every > > time the MN performs re-registration (i.e. when it has a valid > > binding) but the local policy requires AAA auth when there is no > > active binding (new RRQ). >=20 > Personal opinion: You have the answer there. If there is an active > binding, you don't perform AAA auth, in this case. Never mind whether > the RRQ requests a new dynamic address assignment or not. >=20 > On the other hand, if the policy specifies AAA re-auth before > address assignment, never mind any active sessions, the answer > should be pretty clear too - do it :-) >=20 > (Of course, a decent implementation should return the same HoA as > the currently active binding has, also in the event of a new RRQ > with 0.0.0.0 when there is an active binding. This is not an=20 > anomalous case, as the HA has to be prepared for a client which > has re-booted or been turned off and on by the user. But I don't > know if this really has any bearing on your original question.) >=20 > > This is an example scenario. Is there any RFC/ID that explains the > > HoA=3D0.0.0.0 behavior for MIPv4? >=20 > RFC 3344. >=20 >=20 > Henrik >=20 >=20 > > Regards, Kuntal > >=20 > >=20 > >=20 > >> -----Original Message----- From: Charles E. Perkins > >> [mailto:charliep@iprg.nokia.com] Sent: Thursday, June 16, 2005 > >> 12:14 PM To: Chowdhury, Kuntal Cc: Mip4@ietf.org Subject: Re: > >> [Mip4] HoA=3D0.0.0.0 question > >>=20 > >>=20 > >>=20 > >> Hello Kuntal, > >>=20 > >> Can you explain what difference it would make one way or the other? > >>=20 > >>=20 > >> Regards, Charlie P. >=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 Thu Jun 16 18:20:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj2iY-00066O-UA; Thu, 16 Jun 2005 18:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj2iX-00064i-MO for mip4@megatron.ietf.org; Thu, 16 Jun 2005 18:20: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 SAA21231 for ; Thu, 16 Jun 2005 18:20:03 -0400 (EDT) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj35W-0003I6-GN for Mip4@ietf.org; Thu, 16 Jun 2005 18:43:54 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id C145790008; Thu, 16 Jun 2005 18:20:00 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00747-07; Thu, 16 Jun 2005 18:19:59 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 16 Jun 2005 18:19:59 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Thu, 16 Jun 2005 18:19:58 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F03411F4F@ames.starentnetworks.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcVysNHKzZ8Rj+nNTImm3KH5ScLRTgAD/8Mg From: "Chowdhury, Kuntal" To: "Charles E.Perkins" , "Avi Lior" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Hi Charlie, It is not my intent to delay anything. I just want to clarify the HA = behavior. IMHO, the HA implementations will behave differently if it is = not spelt out in any spec that HoA=3D0 should be treated as a new = registration request. Regards, Kuntal > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org]On Behalf Of > Charles E.Perkins > Sent: Thursday, June 16, 2005 3:11 PM > To: Avi Lior > Cc: Mip4@ietf.org > Subject: Re: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 >=20 > Hello Avi, >=20 > Avi Lior wrote: >=20 > > IMO therefore, MIP needs to be more explicit as to what=20 > happens eventhough > > at the pure MIP context it may not make a difference. >=20 > If you want to propose some text, then maybe I would > understand what the problem is. If it doesn't make > any difference in the "pure MIP context", then I am > reluctant to make any further specification for > it within the "pure MIP context" document. >=20 > > That is, we need to resolve Kuntal's original question in=20 > the MIP context: > > "when the HA receives a RRQ with HoA=3D0.0.0.0 does > > it always treat that as a NEW registration request even if > > there is an unexpired mobility binding for the same NAI in the HA?" >=20 > As far as I can tell from the discussion, a competent > engineer could build an excellent system regardless of > whether the registration request was considered "new" or not. >=20 > > We can either require the mobile to use an HoA when=20 > re-registering or only > > use the NAI to index the binding cache. >=20 > Either of these solutions sound overly restrictive > to me, of course depending on the restraints posed > by the legacy systems involved. >=20 > Regards, > Charlie P. >=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 Thu Jun 16 18:33:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj2va-0000Qk-OL; Thu, 16 Jun 2005 18:33:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj2vZ-0000Qc-BS for mip4@megatron.ietf.org; Thu, 16 Jun 2005 18:33:37 -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 SAA22012 for ; Thu, 16 Jun 2005 18:33:31 -0400 (EDT) Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj3IY-00042y-54 for Mip4@ietf.org; Thu, 16 Jun 2005 18:57:22 -0400 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id 3434C38051; Fri, 17 Jun 2005 00:33:25 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 1B0B037FEA; Fri, 17 Jun 2005 00:33:25 +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 94AC037E42; Fri, 17 Jun 2005 00:33:23 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1Dj2vL-0004te-0M; Fri, 17 Jun 2005 00:33:23 +0200 Message-ID: <42B1FE30.9080509@levkowetz.com> Date: Fri, 17 Jun 2005 00:33:20 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip4] HoA=0.0.0.0 question References: <8A16DAD84432534FBFC19FD92B50512F035D9078@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F035D9078@ames.starentnetworks.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: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Mip4@ietf.org, "Charles E. Perkins" 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="===============0162131332==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0162131332== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig622CEACF7FB4472A17DD0E66" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig622CEACF7FB4472A17DD0E66 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kuntal, On 2005-06-17 00:15 Chowdhury, Kuntal said the following: > Hi Henrik and Charlie, > > What I understand from your responses is that HoA=0 should be treated > by the HA as a new registration request (since an HoA assignment is > involved here). Is this a correct understanding? No, there really doesn't exist a distinction between "re-registration" and "new registration", so your question doesn't have a "Yes" or "No" answer. Please see my reply to Avi's mail for more about this. Henrik > > Regards, Kuntal > > >> -----Original Message----- From: Henrik Levkowetz >> [mailto:henrik@levkowetz.com] Sent: Thursday, June 16, 2005 2:56 PM >> To: Chowdhury, Kuntal Cc: Charles E. Perkins; Mip4@ietf.org >> Subject: Re: [Mip4] HoA=0.0.0.0 question >> >> >> Hi Kuntal, >> >> On 2005-06-16 19:20 Chowdhury, Kuntal said the following: >>> Hi Charlie, >>> >>> Based on local policy the HA may have to process a new RRQ >>> differently than a re-registration. For example, the local >> policy may >>> not require the HA to perform AAA auth (i.e. process MN-AAA) >>> every time the MN performs re-registration (i.e. when it has a >>> valid binding) but the local policy requires AAA auth when there >>> is no active binding (new RRQ). >> >> Personal opinion: You have the answer there. If there is an active >> binding, you don't perform AAA auth, in this case. Never mind >> whether the RRQ requests a new dynamic address assignment or not. >> >> On the other hand, if the policy specifies AAA re-auth before >> address assignment, never mind any active sessions, the answer >> should be pretty clear too - do it :-) >> >> (Of course, a decent implementation should return the same HoA as >> the currently active binding has, also in the event of a new RRQ >> with 0.0.0.0 when there is an active binding. This is not an >> anomalous case, as the HA has to be prepared for a client which has >> re-booted or been turned off and on by the user. But I don't know >> if this really has any bearing on your original question.) >> >>> This is an example scenario. Is there any RFC/ID that explains >>> the HoA=0.0.0.0 behavior for MIPv4? >> >> RFC 3344. >> >> >> Henrik >> >> >>> Regards, Kuntal >>> >>> >>> >>>> -----Original Message----- From: Charles E. Perkins >>>> [mailto:charliep@iprg.nokia.com] Sent: Thursday, June 16, 2005 >>>> 12:14 PM To: Chowdhury, Kuntal Cc: Mip4@ietf.org Subject: Re: >>>> [Mip4] HoA=0.0.0.0 question >>>> >>>> >>>> >>>> Hello Kuntal, >>>> >>>> Can you explain what difference it would make one way or the >>>> other? >>>> >>>> >>>> Regards, Charlie P. >> >> > --------------enig622CEACF7FB4472A17DD0E66 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFCsf4xeVhrtTJkXCMRAlQ2AJ0V1Z+uwZaK63qvBjxFq86r04lMEACcCPLw E0XJO4nCbh4ZS+g1N4jJqBY= =+u/G -----END PGP SIGNATURE----- --------------enig622CEACF7FB4472A17DD0E66-- --===============0162131332== 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/ --===============0162131332==-- From mip4-bounces@ietf.org Thu Jun 16 18:43:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj35Z-0002l4-1h; Thu, 16 Jun 2005 18:43:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj35W-0002kX-Os for mip4@megatron.ietf.org; Thu, 16 Jun 2005 18:43:54 -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 SAA22896 for ; Thu, 16 Jun 2005 18:43:48 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj3SV-0004bn-O3 for Mip4@ietf.org; Thu, 16 Jun 2005 19:07:40 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5GMAjM19295; Thu, 16 Jun 2005 15:10:45 -0700 X-mProtect: <200506162210> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmmoq5z; Thu, 16 Jun 2005 15:10:44 PDT Message-ID: <42B2006D.1D049204@iprg.nokia.com> Date: Thu, 16 Jun 2005 15:42:53 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip4] HoA=0.0.0.0 question References: <8A16DAD84432534FBFC19FD92B50512F035D9078@ames.starentnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Mip4@ietf.org, 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 Hello Kuntal, "Chowdhury, Kuntal" wrote: > What I understand from your responses is that HoA=0 should be > treated by the HA as a new registration request (since an HoA > assignment is involved here). Is this a correct understanding? I'd rather not modify the specification about how the home agent might distinguish this as a new Request. Just from memory, without perusing the document, I believe that the concept of "new registration" in the base specification is tied closely to the use of the same "Identification" field within the Registration Request, and I would not want to disturb the meaning of that term. Moreover, I don't yet fully understand the need, even in the context of AAA protocols. Regards, Charlie P. -- 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 Jun 16 18:49:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj3BF-0004GV-Nk; Thu, 16 Jun 2005 18:49:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj3BD-0004GN-Aq for mip4@megatron.ietf.org; Thu, 16 Jun 2005 18:49: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 SAA23402 for ; Thu, 16 Jun 2005 18:49:41 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj3YB-0004xU-HY for mip4@ietf.org; Thu, 16 Jun 2005 19:13:32 -0400 Received: by zproxy.gmail.com with SMTP id 13so123226nzp for ; Thu, 16 Jun 2005 15:49:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=IAqTZRPBjN4CYLG0lISIBq7+TWwS2vviFf3jXRwlD/7yjIwl450WkkFeJ4YmEs0APKhbKIQjLEM9jeDecNJmSL1U6ERftzGzyRdqAx9Z9PNqNfJhb7NqSqXFykKzLp4LVf9bZJPM0h9tMemCh3w/Azn0CQBmeM4yQ0awqIRs/B8= Received: by 10.36.222.4 with SMTP id u4mr883063nzg; Thu, 16 Jun 2005 15:49:34 -0700 (PDT) Received: by 10.36.19.16 with HTTP; Thu, 16 Jun 2005 15:49:34 -0700 (PDT) Message-ID: <5f13657050616154918ef2de7@mail.gmail.com> Date: Thu, 16 Jun 2005 15:49:34 -0700 From: Darshan Purohit To: mip4@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Subject: [Mip4] Detecting presence of a Foreign Agent X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Darshan Purohit 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 am a bit unsure about detecting whether a foriegn agent is being used or = not. and what could be the possible Foreign Agent Address The way I thought about it is ... If D bit is not set , FADDR =3D Care-of Address (Source address could be NAT Translated) If D bit is set If no UDP Tunnel Request Extension FADDR =3D source address , if source !=3D care-of addre= ss else NO Foreign Agent else ????? Now, in the last else, a UDP Tunnel request extension is present and MN is using a co-located care-of Address. If there is an FA-HA Auth Extension, h= ow=20 do we look for the Foreign Agent Security Association. The source addres= s could have been NAT Translated and the care-of address belongs to the MN. Am I missing something here ? Thanks Darshan. -- 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 Jun 16 19:11:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj3Vx-0000T8-4x; Thu, 16 Jun 2005 19:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj3Vw-0000T0-8n for mip4@megatron.ietf.org; Thu, 16 Jun 2005 19:11:12 -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 TAA25033 for ; Thu, 16 Jun 2005 19:11:05 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj3su-00067i-Ck for mip4@ietf.org; Thu, 16 Jun 2005 19:34:57 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2005 16:10:44 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5GNAY7m014167; Thu, 16 Jun 2005 16:10:35 -0700 (PDT) Date: Thu, 16 Jun 2005 16:10:37 -0700 (PDT) From: Sri Gundavelli To: Darshan Purohit Subject: Re: [Mip4] Detecting presence of a Foreign Agent In-Reply-To: <5f13657050616154918ef2de7@mail.gmail.com> Message-ID: References: <5f13657050616154918ef2de7@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 On Thu, 16 Jun 2005, Darshan Purohit wrote: > I am a bit unsure about detecting whether a foriegn agent is being used or not. > and what could be the possible Foreign Agent Address > > The way I thought about it is ... > > If D bit is not set , FADDR = Care-of Address > (Source address could be NAT > Translated) > If D bit is set > If no UDP Tunnel Request Extension > FADDR = source address , if source != care-of address > else NO Foreign Agent > else > ????? If the UDP Tunnel request extension is before MHAE, the extension is added by the MN and the tunnel will terminate at the MN, or if the "D" bit is set. The "R" bit in the UDP Tunnel request extension will indicate if the FA is in the control path and so the special keep alive message for bringing up the tunnel to fix the NAT mappings for the data traffic. > > Now, in the last else, a UDP Tunnel request extension is present and > MN is using > a co-located care-of Address. If there is an FA-HA Auth Extension, how > do we look for the Foreign Agent Security Association. The source address > could have been NAT Translated and the care-of address belongs to the MN. > Please read issue#45, I've created this for the RFC3344bis. This is still unresolved and Pete plans to toss a coin in Paris. We will fix these issues in 3519bis anyways. Sri > Am I missing something here ? > > Thanks > Darshan. > > -- > 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 Jun 17 07:05:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjEf0-000379-4Q; Fri, 17 Jun 2005 07:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjEey-000374-RY for mip4@megatron.ietf.org; Fri, 17 Jun 2005 07:05: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 HAA05035 for ; Fri, 17 Jun 2005 07:05:13 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjF22-0002HZ-EK for mip4@ietf.org; Fri, 17 Jun 2005 07:29:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2005 04:05:05 -0700 X-IronPort-AV: i="3.93,207,1115017200"; d="scan'208"; a="644242733:sNHT28570804" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5HB4wTg023155; Fri, 17 Jun 2005 04:05:03 -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, 17 Jun 2005 04:05:00 -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] Detecting presence of a Foreign Agent Date: Fri, 17 Jun 2005 04:04:59 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC524A041A@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] Detecting presence of a Foreign Agent Thread-Index: AcVyxgA/lYug7EsMSF6WA1/Dav1AJAAZjL6A From: "Kent Leung \(kleung\)" To: "Darshan Purohit" , X-OriginalArrivalTime: 17 Jun 2005 11:05:00.0665 (UTC) FILETIME=[67C50E90:01C5732C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Darshan. You've encountered the issue of identifying the FA when NAT happens. This is suppose to be addressed in 3519bis, as Sri said. Kent=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Darshan Purohit > Sent: Thursday, June 16, 2005 3:50 PM > To: mip4@ietf.org > Subject: [Mip4] Detecting presence of a Foreign Agent >=20 > I am a bit unsure about detecting whether a foriegn agent is=20 > being used or not. > and what could be the possible Foreign Agent Address >=20 > The way I thought about it is ... >=20 > If D bit is not set , FADDR =3D Care-of Address > (Source address could be NAT > Translated) > If D bit is set > If no UDP Tunnel Request Extension > FADDR =3D source address , if source !=3D=20 > care-of address > else NO Foreign Agent > else > ????? >=20 > Now, in the last else, a UDP Tunnel request extension is present and > MN is using > a co-located care-of Address. If there is an FA-HA Auth=20 > Extension, how=20 > do we look for the Foreign Agent Security Association. The=20 > source address > could have been NAT Translated and the care-of address=20 > belongs to the MN. >=20 > Am I missing something here ? >=20 > Thanks > Darshan. >=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 Fri Jun 17 07:22:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjEvn-0005zT-79; Fri, 17 Jun 2005 07:22:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjEvk-0005xv-UB for mip4@megatron.ietf.org; Fri, 17 Jun 2005 07:22:37 -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 HAA06198 for ; Fri, 17 Jun 2005 07:22: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.33) id 1DjFIo-0003Na-Id for mip4@ietf.org; Fri, 17 Jun 2005 07:46:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2005 04:22:25 -0700 X-IronPort-AV: i="3.93,207,1115017200"; d="scan'208"; a="279920841:sNHT30549564" 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 j5HBM97r017193; Fri, 17 Jun 2005 04:22:16 -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, 17 Jun 2005 04:22:19 -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] HoA=0.0.0.0 question Date: Fri, 17 Jun 2005 04:22:17 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC524A041C@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcVysNHKzZ8Rj+nNTImm3KH5ScLRTgAD/8MgABrnv8A= From: "Kent Leung \(kleung\)" To: "Chowdhury, Kuntal" , "Charles E.Perkins" , "Avi Lior" X-OriginalArrivalTime: 17 Jun 2005 11:22:19.0402 (UTC) FILETIME=[D2E7BEA0:01C5732E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Hi Kuntal. =20 Further clarifications on NAI/home address assignment are covered in draft-paulkandasamy-nai-based-home-address-01.txt. We'll update that soon. I'm aware of the scenario that you've brought up. Only the first RRQ is authenticated by the AAA server, and subsequent Re-RRQ's are locally authenticated by the HA (AAA authentication skipped). The case you brought up is covered in #7 in the draft, which states that the HoA in the mobility binding is returned in the RRP. But I think the issue is not about address assignment but really authentication processing. Since all NEW RRQs are suppose to go to the AAA server, the question here is who's perspective of "NEW" - HA or MN? In this case, HA thinks this is not new since binding exists, but MN obviously thinks it is sending a new RRQ. My personal opinion is that since the network (AAA) has already authenticated the MN before, there's no need to go to AAA again since the same HoA (session) is still in effect. The reason this deployment knob (I call it) was to avoid overloading the AAA server for the same session (even though MN-AAA AE is in the RRQ). I agree with folks who said that there's no need to change any drafts since this is more of an implementation issue. The skipping of going to AAA server is an implementation optimization. This is a issue of that type of operation. Now, I'll go and read rest of thread ... :) Kent > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Chowdhury, Kuntal > Sent: Thursday, June 16, 2005 3:20 PM > To: Charles E.Perkins; Avi Lior > Cc: Mip4@ietf.org > Subject: RE: [Mip4] HoA=3D0.0.0.0 question >=20 > Hi Charlie, >=20 > It is not my intent to delay anything. I just want to clarify=20 > the HA behavior. IMHO, the HA implementations will behave=20 > differently if it is not spelt out in any spec that HoA=3D0=20 > should be treated as a new registration request. >=20 > Regards, > Kuntal >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org=20 > [mailto:mip4-bounces@ietf.org]On Behalf Of=20 > > Charles E.Perkins > > Sent: Thursday, June 16, 2005 3:11 PM > > To: Avi Lior > > Cc: Mip4@ietf.org > > Subject: Re: [Mip4] HoA=3D0.0.0.0 question > >=20 > >=20 > >=20 > > Hello Avi, > >=20 > > Avi Lior wrote: > >=20 > > > IMO therefore, MIP needs to be more explicit as to what > > happens eventhough > > > at the pure MIP context it may not make a difference. > >=20 > > If you want to propose some text, then maybe I would=20 > understand what=20 > > the problem is. If it doesn't make any difference in the "pure MIP=20 > > context", then I am reluctant to make any further=20 > specification for it=20 > > within the "pure MIP context" document. > >=20 > > > That is, we need to resolve Kuntal's original question in > > the MIP context: > > > "when the HA receives a RRQ with HoA=3D0.0.0.0 does it=20 > always treat=20 > > > that as a NEW registration request even if there is an unexpired=20 > > > mobility binding for the same NAI in the HA?" > >=20 > > As far as I can tell from the discussion, a competent=20 > engineer could=20 > > build an excellent system regardless of whether the registration=20 > > request was considered "new" or not. > >=20 > > > We can either require the mobile to use an HoA when > > re-registering or only > > > use the NAI to index the binding cache. > >=20 > > Either of these solutions sound overly restrictive to me, of course=20 > > depending on the restraints posed by the legacy systems involved. > >=20 > > Regards, > > Charlie P. > >=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 > > 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/ >=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 Jun 17 10:21:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHii-0005ZS-3d; Fri, 17 Jun 2005 10:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHih-0005ZN-Cw for mip4@megatron.ietf.org; Fri, 17 Jun 2005 10:21: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 KAA22329 for ; Fri, 17 Jun 2005 10:21:17 -0400 (EDT) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjI5n-00086W-D3 for Mip4@ietf.org; Fri, 17 Jun 2005 10:45:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 3861090007; Fri, 17 Jun 2005 10:21:08 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06662-07; Fri, 17 Jun 2005 10:21:04 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Fri, 17 Jun 2005 10:21:04 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Fri, 17 Jun 2005 10:21:03 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D907D@ames.starentnetworks.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcVysNHKzZ8Rj+nNTImm3KH5ScLRTgAD/8MgABrnv8AABmVWEA== From: "Chowdhury, Kuntal" To: "Kent Leung (kleung)" , "Charles E.Perkins" , "Avi Lior" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 Okay...what I sense is that the description of the HoA=3D0.0.0.0 = behavior for an existing MIP binding does not belong in MIP and it also = does not belong in AAA. But, all I know is that new registration vs. = re-registration determination has significant practical deployment = implication. I am wondering whether such a thing should be defined or = left open for interpretation. BTW, I thought MIP4 WG was chartered to take care of Mobile IPv4 = deployment issues! " Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts = deal with concerns such as optimization, security, extensions, AAA = support, and deployment issues. " -Kuntal > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Friday, June 17, 2005 6:22 AM > To: Chowdhury, Kuntal; Charles E.Perkins; Avi Lior > Cc: Mip4@ietf.org > Subject: RE: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 > Hi Kuntal. =20 >=20 > Further clarifications on NAI/home address assignment are covered in > draft-paulkandasamy-nai-based-home-address-01.txt. We'll update that > soon. >=20 > I'm aware of the scenario that you've brought up. Only the=20 > first RRQ is > authenticated by the AAA server, and subsequent Re-RRQ's are locally > authenticated by the HA (AAA authentication skipped). The case you > brought up is covered in #7 in the draft, which states that the HoA in > the mobility binding is returned in the RRP. But I think the issue is > not about address assignment but really authentication processing. > Since all NEW RRQs are suppose to go to the AAA server, the question > here is who's perspective of "NEW" - HA or MN? In this case,=20 > HA thinks > this is not new since binding exists, but MN obviously thinks it is > sending a new RRQ. My personal opinion is that since the=20 > network (AAA) > has already authenticated the MN before, there's no need to go to AAA > again since the same HoA (session) is still in effect. The=20 > reason this > deployment knob (I call it) was to avoid overloading the AAA=20 > server for > the same session (even though MN-AAA AE is in the RRQ). >=20 > I agree with folks who said that there's no need to change any drafts > since this is more of an implementation issue. The skipping=20 > of going to > AAA server is an implementation optimization. This is a issue of that > type of operation. >=20 > Now, I'll go and read rest of thread ... :) >=20 > Kent >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > > Behalf Of Chowdhury, Kuntal > > Sent: Thursday, June 16, 2005 3:20 PM > > To: Charles E.Perkins; Avi Lior > > Cc: Mip4@ietf.org > > Subject: RE: [Mip4] HoA=3D0.0.0.0 question > >=20 > > Hi Charlie, > >=20 > > It is not my intent to delay anything. I just want to clarify=20 > > the HA behavior. IMHO, the HA implementations will behave=20 > > differently if it is not spelt out in any spec that HoA=3D0=20 > > should be treated as a new registration request. > >=20 > > Regards, > > Kuntal > >=20 > > > -----Original Message----- > > > From: mip4-bounces@ietf.org=20 > > [mailto:mip4-bounces@ietf.org]On Behalf Of=20 > > > Charles E.Perkins > > > Sent: Thursday, June 16, 2005 3:11 PM > > > To: Avi Lior > > > Cc: Mip4@ietf.org > > > Subject: Re: [Mip4] HoA=3D0.0.0.0 question > > >=20 > > >=20 > > >=20 > > > Hello Avi, > > >=20 > > > Avi Lior wrote: > > >=20 > > > > IMO therefore, MIP needs to be more explicit as to what > > > happens eventhough > > > > at the pure MIP context it may not make a difference. > > >=20 > > > If you want to propose some text, then maybe I would=20 > > understand what=20 > > > the problem is. If it doesn't make any difference in the=20 > "pure MIP=20 > > > context", then I am reluctant to make any further=20 > > specification for it=20 > > > within the "pure MIP context" document. > > >=20 > > > > That is, we need to resolve Kuntal's original question in > > > the MIP context: > > > > "when the HA receives a RRQ with HoA=3D0.0.0.0 does it=20 > > always treat=20 > > > > that as a NEW registration request even if there is an=20 > unexpired=20 > > > > mobility binding for the same NAI in the HA?" > > >=20 > > > As far as I can tell from the discussion, a competent=20 > > engineer could=20 > > > build an excellent system regardless of whether the registration=20 > > > request was considered "new" or not. > > >=20 > > > > We can either require the mobile to use an HoA when > > > re-registering or only > > > > use the NAI to index the binding cache. > > >=20 > > > Either of these solutions sound overly restrictive to me,=20 > of course=20 > > > depending on the restraints posed by the legacy systems involved. > > >=20 > > > Regards, > > > Charlie P. > > >=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 > > > 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:=20 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 Fri Jun 17 10:30:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHrY-0007Dw-Ni; Fri, 17 Jun 2005 10:30:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHrW-0007Dr-Sz for mip4@megatron.ietf.org; Fri, 17 Jun 2005 10:30:26 -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 KAA23008 for ; Fri, 17 Jun 2005 10:30:24 -0400 (EDT) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjIEd-0000Gm-As for Mip4@ietf.org; Fri, 17 Jun 2005 10:54:20 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id D3DFE90007; Fri, 17 Jun 2005 10:30:16 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06758-05; Fri, 17 Jun 2005 10:30:15 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Fri, 17 Jun 2005 10:30:15 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Fri, 17 Jun 2005 10:30:15 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F03411F5E@ames.starentnetworks.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcVysNHKzZ8Rj+nNTImm3KH5ScLRTgAD/8MgABrnv8AABxLlAA== From: "Chowdhury, Kuntal" To: "Kent Leung (kleung)" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Cc: Mip4@ietf.org, "Charles E.Perkins" , Avi Lior 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 "draft-paulkandasamy-nai-based-home-address-01.txt" does not exist for = me to look at. -Kuntal > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Friday, June 17, 2005 6:22 AM > To: Chowdhury, Kuntal; Charles E.Perkins; Avi Lior > Cc: Mip4@ietf.org > Subject: RE: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 > Hi Kuntal. =20 >=20 > Further clarifications on NAI/home address assignment are covered in > draft-paulkandasamy-nai-based-home-address-01.txt. We'll update that > soon. >=20 > I'm aware of the scenario that you've brought up. Only the=20 > first RRQ is > authenticated by the AAA server, and subsequent Re-RRQ's are locally > authenticated by the HA (AAA authentication skipped). The case you > brought up is covered in #7 in the draft, which states that the HoA in > the mobility binding is returned in the RRP. But I think the issue is > not about address assignment but really authentication processing. > Since all NEW RRQs are suppose to go to the AAA server, the question > here is who's perspective of "NEW" - HA or MN? In this case,=20 > HA thinks > this is not new since binding exists, but MN obviously thinks it is > sending a new RRQ. My personal opinion is that since the=20 > network (AAA) > has already authenticated the MN before, there's no need to go to AAA > again since the same HoA (session) is still in effect. The=20 > reason this > deployment knob (I call it) was to avoid overloading the AAA=20 > server for > the same session (even though MN-AAA AE is in the RRQ). >=20 > I agree with folks who said that there's no need to change any drafts > since this is more of an implementation issue. The skipping=20 > of going to > AAA server is an implementation optimization. This is a issue of that > type of operation. >=20 > Now, I'll go and read rest of thread ... :) >=20 > Kent >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > > Behalf Of Chowdhury, Kuntal > > Sent: Thursday, June 16, 2005 3:20 PM > > To: Charles E.Perkins; Avi Lior > > Cc: Mip4@ietf.org > > Subject: RE: [Mip4] HoA=3D0.0.0.0 question > >=20 > > Hi Charlie, > >=20 > > It is not my intent to delay anything. I just want to clarify=20 > > the HA behavior. IMHO, the HA implementations will behave=20 > > differently if it is not spelt out in any spec that HoA=3D0=20 > > should be treated as a new registration request. > >=20 > > Regards, > > Kuntal > >=20 > > > -----Original Message----- > > > From: mip4-bounces@ietf.org=20 > > [mailto:mip4-bounces@ietf.org]On Behalf Of=20 > > > Charles E.Perkins > > > Sent: Thursday, June 16, 2005 3:11 PM > > > To: Avi Lior > > > Cc: Mip4@ietf.org > > > Subject: Re: [Mip4] HoA=3D0.0.0.0 question > > >=20 > > >=20 > > >=20 > > > Hello Avi, > > >=20 > > > Avi Lior wrote: > > >=20 > > > > IMO therefore, MIP needs to be more explicit as to what > > > happens eventhough > > > > at the pure MIP context it may not make a difference. > > >=20 > > > If you want to propose some text, then maybe I would=20 > > understand what=20 > > > the problem is. If it doesn't make any difference in the=20 > "pure MIP=20 > > > context", then I am reluctant to make any further=20 > > specification for it=20 > > > within the "pure MIP context" document. > > >=20 > > > > That is, we need to resolve Kuntal's original question in > > > the MIP context: > > > > "when the HA receives a RRQ with HoA=3D0.0.0.0 does it=20 > > always treat=20 > > > > that as a NEW registration request even if there is an=20 > unexpired=20 > > > > mobility binding for the same NAI in the HA?" > > >=20 > > > As far as I can tell from the discussion, a competent=20 > > engineer could=20 > > > build an excellent system regardless of whether the registration=20 > > > request was considered "new" or not. > > >=20 > > > > We can either require the mobile to use an HoA when > > > re-registering or only > > > > use the NAI to index the binding cache. > > >=20 > > > Either of these solutions sound overly restrictive to me,=20 > of course=20 > > > depending on the restraints posed by the legacy systems involved. > > >=20 > > > Regards, > > > Charlie P. > > >=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 > > > 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:=20 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 Sat Jun 18 01:22:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVmY-0006qB-Bx; Sat, 18 Jun 2005 01:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVmV-0006py-Sz for mip4@megatron.ietf.org; Sat, 18 Jun 2005 01:22:12 -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 BAA21493 for ; Sat, 18 Jun 2005 01:22:10 -0400 (EDT) Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjW9l-0008GS-3k for Mip4@ietf.org; Sat, 18 Jun 2005 01:46:13 -0400 Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Sat, 18 Jun 2005 01:21:59 -0400 Message-ID: From: Avi Lior To: "Charles E.Perkins" , "Chowdhury, Kuntal" Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Sat, 18 Jun 2005 01:21:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Mip4@ietf.org, 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 Charlie and All, Here is an example of the problem (as I understand it) Kuntal or others may correct me or add to this. Consider the case where customers are billed based on time. Now consider what happens when a mobile deregisters but the deregistration is lost; the binding cache in the HA will become stale. In order not to overbill the user, the HA -- everytime a binding update goes stale could then attempt to determine when the session actually terminated by looking at other indicators to determine the last activity time. Note this operation is expensive but it is important for accurate billing of customers and hence important to operators. If however, the same mobile preforms a new registration before the lifetime of the previous registration expires, then the HA will see this new registration as a re-registration. The HA will then NOT attempt to re-compute the real session time and the user will be billed for that time. In some environments such as wirelss this could happen relatively frequently and operators are concerned about these issues and want to make sure that they do everything possible to bill appropriately. One solution to this problem is as Kuntal suggested. In his particular case where the HOA is allocated by the home network then if the mobile always sends an HOA with 0.0.0.0 in new registration then we can then deferentiate between new registration and a re-registration. However, when the MN is assigned a static HOA then that "hint" is no longer available. We need something else. What that something else is I am not sure. But it seems to me that we should have explicitly indicated whether a registration is a new registration or a re-registration. This would make the protcol more robust. Another solution is to reduce the lifetime of a registration. This may be workable in fixed wireline mobile ip application but it is not a good idea for wireless mobile ip applications due to the expensive over the air resources. Perhaps I should ask this question from those who know this subject far better than me, is there a reliable way for the HA to reliably deferentiate between a Re-registration, a new Re-gistration? > -----Original Message----- > From: Charles E.Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, June 16, 2005 6:43 PM > To: Chowdhury, Kuntal > Cc: Mip4@ietf.org; Henrik Levkowetz > Subject: Re: [Mip4] HoA=0.0.0.0 question > > > > Hello Kuntal, > > "Chowdhury, Kuntal" wrote: > > > What I understand from your responses is that HoA=0 should > be treated > > by the HA as a new registration request (since an HoA assignment is > > involved here). Is this a correct understanding? > > I'd rather not modify the specification about how the > home agent might distinguish this as a new Request. > Just from memory, without perusing the document, > I believe that the concept of "new registration" > in the base specification is tied closely to the > use of the same "Identification" field within the > Registration Request, and I would not want to disturb > the meaning of that term. > > Moreover, I don't yet fully understand the need, even > in the context of AAA protocols. > > Regards, > Charlie P. > > -- > 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 Sat Jun 18 01:22:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVmY-0006qN-RL; Sat, 18 Jun 2005 01:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVmW-0006pz-5e for mip4@megatron.ietf.org; Sat, 18 Jun 2005 01:22:12 -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 BAA21495 for ; Sat, 18 Jun 2005 01:22:10 -0400 (EDT) Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjW9l-0008GT-5o for Mip4@ietf.org; Sat, 18 Jun 2005 01:46:13 -0400 Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Sat, 18 Jun 2005 01:21:59 -0400 Message-ID: From: Avi Lior To: Henrik Levkowetz , Avi Lior Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Sat, 18 Jun 2005 01:21:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Mip4@ietf.org, "Chowdhury, Kuntal" , "'Charles E. Perkins'" 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, See comments inline. Also perhaps the scenario I presented in another email will help. > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Thursday, June 16, 2005 4:51 PM > To: Avi Lior > Cc: 'Charles E. Perkins'; Chowdhury, Kuntal; Mip4@ietf.org > Subject: Re: [Mip4] HoA=0.0.0.0 question > > > Hi Avi, > > On 2005-06-16 21:34 Avi Lior said the following: > > Hi Charlie, > > > > Actually I am not sure it's a AAA problem either. The original > > scenario Kuntal raises can happen with or without the presence of a > > AAA function right? > > > > The side-effect (Kuntal's explaination) is what can happen > with a AAA. > > > > IMO therefore, MIP needs to be more explicit as to what happens > > eventhough at the pure MIP context it may not make a difference. > > I think here we're at the crux of the matter: Not only > doesn't it make a difference, there really isn't a difference > at the MIP level, I believe. Well its not clear to me that this is the case. Unless I missed something the scenario I presented does show that there is an issue with MIP protocol. A tighter protocol would solve the problem. Again if I am correct MIP group could say that this is a corner case and we don't care. But that is a different matter entirely. > > That is, we need to resolve Kuntal's original question in the MIP > > context: "when the HA receives a RRQ with HoA=0.0.0.0 does > it always > > treat that as a NEW registration request even if there is > an unexpired > > mobility binding for the same NAI in the HA?" > > Well, since there really isn't any difference between > "re-registration" and "new registration" in MIP4, there > really isn't a distinction, protocol-wise... But as you can see (again look at the scenario I presented) there is a real world difference. > > We can either require the mobile to use an HoA when > re-registering or > > only use the NAI to index the binding cache. > > This seems to argue for creating a distinction, based on the > value of the HoA field, between some "new registrations" and > other "re-registrations". So I actually now belive that the HOA could solve the problem but only in certain cases, that is, when the Home Network is setting the IP address. > I'm not convinced that this is wise, and I'm not convinced it > is necessary. > > Possibly it could be argued that it would be advantageous to > add to the specification that: > > "If there exists an active binding for the MN when a > registration request with the Home Address field set to > 0.0.0.0 is received by the HA, the HA SHOULD return the same > Home Address as for the already existing binding." That helps in one particular case. As well, it may be helpful to also state that during re-registration a mobile node MUST set the HOA address to the one assigned during the initial registration and during registration revocation. But that may already be stated. > But that is maybe a different matter ? > > (As some background to this discussion, I coded the HA side > of dynamic address assignment some 2-3 years ago. I found > that since the HA can never know whether the MN has been > turned on and off between registrations, and the MN really > can't assume that the HA hasn't had a power outage, > malfunction, or what-not, it turned out that you really have > to find a way to handle a lot of different combinations of > existing and non-existing active bindings, 0.0.0.0 requests, > and requests with old, timed-out HoAs. > > Any attempt at specifying that the MN "must" use an assigned > HoA when "re-registering" ran smack into the realities of > things which said that there were no way of guaranteeing that > behaviour, in the face of everything that might happen with > the MN, the HA, and the link between them ... > > Or to put it in a completely different way - the randomness > and unpredictability of changing wireless links makes it a > strong protocol feature that there indeed is no difference > between "new registration" and > "re-registration".) Well, I think a tighter specification can help in this situation. For example, if we had explicit commands for Registration, Re-registration, hen I don't see how that would have hurt. It at least helps reduce the guesswork at the HA as to the state of the MN. > > Henrik > > > >> -----Original Message----- > >> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > >> Sent: Thursday, June 16, 2005 1:31 PM > >> To: Chowdhury, Kuntal > >> Cc: Mip4@ietf.org > >> Subject: Re: [Mip4] HoA=0.0.0.0 question > >> > >> > >> > >> Hello Kuntal, > >> > >> Based on your example, I do not believe that the distinction > >> would case any change to the base Mobile IPv4 specification. > >> Would this be a new document within the aaa working group? > >> > >> Regards, > >> Charlie P. > > -- 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 Jun 19 12:12:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk2P8-0002Iy-KZ; Sun, 19 Jun 2005 12:12:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk2P7-0002Is-Nq for mip4@megatron.ietf.org; Sun, 19 Jun 2005 12:12:13 -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 MAA16345 for ; Sun, 19 Jun 2005 12:12:10 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk2me-000868-B7 for Mip4@ietf.org; Sun, 19 Jun 2005 12:36:33 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5JFfLe16152; Sun, 19 Jun 2005 08:41:21 -0700 X-mProtect: <200506191541> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp160175.americas.nokia.com (10.241.160.175, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdd8XVTw; Sun, 19 Jun 2005 08:41:19 PDT Message-ID: <42B59941.3040104@iprg.nokia.com> Date: Sun, 19 Jun 2005 09:11:45 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip4] HoA=0.0.0.0 question References: <8A16DAD84432534FBFC19FD92B50512F035D907D@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F035D907D@ames.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Hello Kuntal, Chowdhury, Kuntal wrote: >Okay...what I sense is that the description of the HoA=0.0.0.0 behavior for an existing > MIP binding does not belong in MIP and it also does not belong in AAA. But, all I know > is that new registration vs. re-registration determination has significant practical > deployment implication. I am wondering whether such a thing should be defined or left > open for interpretation. It depends on whether one vendor's HA should need to work with another vendor's AAA box(es). >BTW, I thought MIP4 WG was chartered to take care of Mobile IPv4 deployment issues! I guess this was meant to be provocative. Of course, it is chartered for that reason. I do not think the specification you seelk belongs in the base specification. I didn't say the work would be incompatible with [mip4] working group. That would be up to the working group to say. I could see the decision going either way. Regards, Charlie P. -- 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 Jun 20 10:34:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNLj-0008Hd-MG; Mon, 20 Jun 2005 10:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNLi-0008HY-4i for mip4@megatron.ietf.org; Mon, 20 Jun 2005 10:34: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 KAA05003 for ; Mon, 20 Jun 2005 10:34:04 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkNjQ-0002zm-Am for Mip4@ietf.org; Mon, 20 Jun 2005 10:58: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 j5KEVL7u026109; Mon, 20 Jun 2005 09:31:21 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j5KEVKt22391; Mon, 20 Jun 2005 09:31:20 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IIE0CB-00020K-00; Mon, 20 Jun 2005 10:31:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17078.54074.779625.964096@gargle.gargle.HOWL> Date: Mon, 20 Jun 2005 09:31:22 -0500 From: Pete McCann To: "Kent Leung \(kleung\)" Subject: RE: [Mip4] HoA=0.0.0.0 question In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC524A041C@xmb-sjc-235.amer.cisco.com> References: <2979E38DD6FC6544B789C8DAD7BAFC524A041C@xmb-sjc-235.amer.cisco.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: Mip4@ietf.org, "Chowdhury, Kuntal" , "Charles E.Perkins" , Avi Lior 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, Kent Leung \(kleung\) writes: > Hi Kuntal. > > Further clarifications on NAI/home address assignment are covered in > draft-paulkandasamy-nai-based-home-address-01.txt. We'll update that > soon. I think we agreed to merge the spec in draft-paulkandasamy into a 2794bis which you folks have agreed to edit. Correct? > I'm aware of the scenario that you've brought up. Only the first RRQ is > authenticated by the AAA server, and subsequent Re-RRQ's are locally > authenticated by the HA (AAA authentication skipped). The case you > brought up is covered in #7 in the draft, which states that the HoA in > the mobility binding is returned in the RRP. But I think the issue is > not about address assignment but really authentication processing. > Since all NEW RRQs are suppose to go to the AAA server, the question > here is who's perspective of "NEW" - HA or MN? In this case, HA thinks > this is not new since binding exists, but MN obviously thinks it is > sending a new RRQ. My personal opinion is that since the network (AAA) > has already authenticated the MN before, there's no need to go to AAA > again since the same HoA (session) is still in effect. The reason this > deployment knob (I call it) was to avoid overloading the AAA server for > the same session (even though MN-AAA AE is in the RRQ). > > I agree with folks who said that there's no need to change any drafts > since this is more of an implementation issue. The skipping of going to > AAA server is an implementation optimization. This is a issue of that > type of operation. > > Now, I'll go and read rest of thread ... :) > > Kent > > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > > Behalf Of Chowdhury, Kuntal > > Sent: Thursday, June 16, 2005 3:20 PM > > To: Charles E.Perkins; Avi Lior > > Cc: Mip4@ietf.org > > Subject: RE: [Mip4] HoA=0.0.0.0 question > > > > Hi Charlie, > > > > It is not my intent to delay anything. I just want to clarify > > the HA behavior. IMHO, the HA implementations will behave > > differently if it is not spelt out in any spec that HoA=0 > > should be treated as a new registration request. > > > > Regards, > > Kuntal > > > > > -----Original Message----- > > > From: mip4-bounces@ietf.org > > [mailto:mip4-bounces@ietf.org]On Behalf Of > > > Charles E.Perkins > > > Sent: Thursday, June 16, 2005 3:11 PM > > > To: Avi Lior > > > Cc: Mip4@ietf.org > > > Subject: Re: [Mip4] HoA=0.0.0.0 question > > > > > > > > > > > > Hello Avi, > > > > > > Avi Lior wrote: > > > > > > > IMO therefore, MIP needs to be more explicit as to what > > > happens eventhough > > > > at the pure MIP context it may not make a difference. > > > > > > If you want to propose some text, then maybe I would > > understand what > > > the problem is. If it doesn't make any difference in the "pure MIP > > > context", then I am reluctant to make any further > > specification for it > > > within the "pure MIP context" document. > > > > > > > That is, we need to resolve Kuntal's original question in > > > the MIP context: > > > > "when the HA receives a RRQ with HoA=0.0.0.0 does it > > always treat > > > > that as a NEW registration request even if there is an unexpired > > > > mobility binding for the same NAI in the HA?" > > > > > > As far as I can tell from the discussion, a competent > > engineer could > > > build an excellent system regardless of whether the registration > > > request was considered "new" or not. > > > > > > > We can either require the mobile to use an HoA when > > > re-registering or only > > > > use the NAI to index the binding cache. > > > > > > Either of these solutions sound overly restrictive to me, of course > > > depending on the restraints posed by the legacy systems involved. > > > > > > Regards, > > > Charlie P. -- 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 Jun 20 10:36:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNNr-0008QG-4N; Mon, 20 Jun 2005 10:36:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNNq-0008QA-5G for mip4@megatron.ietf.org; Mon, 20 Jun 2005 10:36:18 -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 KAA05230 for ; Mon, 20 Jun 2005 10:36:16 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkNlZ-000344-AD for Mip4@ietf.org; Mon, 20 Jun 2005 11:00:49 -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 j5KEa46Y001003; Mon, 20 Jun 2005 09:36:04 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j5KEa3t03864; Mon, 20 Jun 2005 09:36:03 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IIE0K7-0001E4-00; Mon, 20 Jun 2005 10:36:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17078.54358.10625.601208@gargle.gargle.HOWL> Date: Mon, 20 Jun 2005 09:36:06 -0500 From: Pete McCann To: Avi Lior Subject: RE: [Mip4] HoA=0.0.0.0 question In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: Mip4@ietf.org, "Chowdhury, Kuntal" , Henrik Levkowetz , "Charles E.Perkins" 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 Avi, One comment below: Avi Lior writes: > Charlie and All, > > Here is an example of the problem (as I understand it) Kuntal or others may > correct me or add to this. > > Consider the case where customers are billed based on time. > > Now consider what happens when a mobile deregisters but the deregistration > is lost; the binding cache in the HA will become stale. In order not to > overbill the user, the HA -- everytime a binding update goes stale could > then attempt to determine when the session actually terminated by looking at > other indicators to determine the last activity time. Note this operation > is expensive but it is important for accurate billing of customers and hence > important to operators. > > If however, the same mobile preforms a new registration before the lifetime > of the previous registration expires, then the HA will see this new > registration as a re-registration. The HA will then NOT attempt to > re-compute the real session time and the user will be billed for that time. > > In some environments such as wirelss this could happen relatively frequently > and operators are concerned about these issues and want to make sure that > they do everything possible to bill appropriately. > > One solution to this problem is as Kuntal suggested. In his particular case > where the HOA is allocated by the home network then if the mobile always > sends an HOA with 0.0.0.0 in new registration then we can then deferentiate > between new registration and a re-registration. > > However, when the MN is assigned a static HOA then that "hint" is no longer > available. We need something else. What that something else is I am not > sure. But it seems to me that we should have explicitly indicated whether a > registration is a new registration or a re-registration. This would make the > protcol more robust. Let's say we add a flag to indicate a "new registration" and then users won't be billed for time between the last registration and a "new registration". What is to prevent me from setting this flag in every single registration? Let's say the MN is set up to be a seldom-used server so you can't really tell from traffic flow whether the MN is still out there listening. Then I won't be billed for any time at all, but the MN is still available to receive packets from the HA at any time. I think we do need a more detailed case analysis of the address assignment implications when the HoA = 0.0.0.0 and this should be in a 2794 bis document. This is planned to be completed by the working group. However, we need to consider carefully whether this kind of a billing requirement needs to be addressed. > Another solution is to reduce the lifetime of a registration. This may be > workable in fixed wireline mobile ip application but it is not a good idea > for wireless mobile ip applications due to the expensive over the air > resources. As long as there is a binding in the HA the MN is getting some kind of service from the HA (the HA is available to forward packets). -Pete > Perhaps I should ask this question from those who know this subject far > better than me, is there a reliable way for the HA to reliably deferentiate > between a Re-registration, a new Re-gistration? > > > -----Original Message----- > > From: Charles E.Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Thursday, June 16, 2005 6:43 PM > > To: Chowdhury, Kuntal > > Cc: Mip4@ietf.org; Henrik Levkowetz > > Subject: Re: [Mip4] HoA=0.0.0.0 question > > > > > > > > Hello Kuntal, > > > > "Chowdhury, Kuntal" wrote: > > > > > What I understand from your responses is that HoA=0 should > > be treated > > > by the HA as a new registration request (since an HoA assignment is > > > involved here). Is this a correct understanding? > > > > I'd rather not modify the specification about how the > > home agent might distinguish this as a new Request. > > Just from memory, without perusing the document, > > I believe that the concept of "new registration" > > in the base specification is tied closely to the > > use of the same "Identification" field within the > > Registration Request, and I would not want to disturb > > the meaning of that term. > > > > Moreover, I don't yet fully understand the need, even > > in the context of AAA protocols. > > > > Regards, > > Charlie P. > > > > -- > > 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/ -- 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 Jun 20 17:42:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkU1r-0001Qz-65; Mon, 20 Jun 2005 17:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkU1o-0001Qp-UA for mip4@megatron.ietf.org; Mon, 20 Jun 2005 17:42: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 RAA12801 for ; Mon, 20 Jun 2005 17:41:57 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkUPY-0006WX-9N for mip4@ietf.org; Mon, 20 Jun 2005 18:06:35 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 20 Jun 2005 14:41:47 -0700 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 j5KLf5r6027362; Mon, 20 Jun 2005 14:41:37 -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); Mon, 20 Jun 2005 14:41:36 -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] HoA=0.0.0.0 question Date: Mon, 20 Jun 2005 14:41:35 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC524A0927@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcV1pVO5hAAwdMMESW6jxEREwLM+xwAO26oA From: "Kent Leung \(kleung\)" To: "Pete McCann" X-OriginalArrivalTime: 20 Jun 2005 21:41:36.0960 (UTC) FILETIME=[D5C66400:01C575E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: Mip4@ietf.org, "Chowdhury, Kuntal" , "Charles E.Perkins" , Avi Lior 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. Yes, we're working on that. Kent =20 > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com]=20 > Sent: Monday, June 20, 2005 7:31 AM > To: Kent Leung (kleung) > Cc: Chowdhury, Kuntal; Charles E.Perkins; Avi Lior; Mip4@ietf.org > Subject: RE: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 > Hi, Kent, >=20 > Kent Leung \(kleung\) writes: > > Hi Kuntal. =20 > > > > Further clarifications on NAI/home address assignment are=20 > covered in >=20 > draft-paulkandasamy-nai-based-home-address-01.txt. We'll=20 > update that > soon. >=20 > I think we agreed to merge the spec in draft-paulkandasamy=20 > into a 2794bis which you folks have agreed to edit. Correct? >=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 Jun 21 01:58:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkbmH-0005xg-Ro; Tue, 21 Jun 2005 01:58:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkbmC-0005wt-Oy for mip4@megatron.ietf.org; Tue, 21 Jun 2005 01:58:27 -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 BAA22342 for ; Tue, 21 Jun 2005 01:58:20 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkcA1-00023C-3Z for mip4@ietf.org; Tue, 21 Jun 2005 02:23:01 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2005 22:58:10 -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 j5L5veli013641; Mon, 20 Jun 2005 22:58:03 -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); Mon, 20 Jun 2005 22:58:02 -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] HoA=0.0.0.0 question Date: Mon, 20 Jun 2005 22:57:54 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC524A0A4A@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcV1paIyNUmrmbFJTEq6NZgPm9rnZAAeFsNg From: "Kent Leung \(kleung\)" To: "Pete McCann" , "Avi Lior" X-OriginalArrivalTime: 21 Jun 2005 05:58:02.0481 (UTC) FILETIME=[2F543610:01C57626] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: "Chowdhury, Kuntal" , Mip4@ietf.org, Henrik Levkowetz , "Charles E.Perkins" 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 Avi for clarifying the billing context. Pete's issue about trusting the MN for billing comes to my mind as well. I see the following implications of HoA =3D 0 in RRQ: 1) Address assignment HoA is set to address in existing binding, IMHO 2) Authentication HA may or may not go to AAA for authentication. Pros and cons of each method. Maybe up to operator to decide. No interoperability issue between HA and AAA server either way. 3) Accounting HA generate AAA accounting record which includes the HoA=3D0 value. One possible solution is to calculate the time difference between this RRQ and last time traffic was accounted for this MN. The reason is that charging is based on usage, which is indicated by traffic to/from MN, independent of registration timers. Note that I would still set HoA=3D0 for every RRQ on the MN to save some = $ for time-based billing. :) =20 So maybe a better scheme to deal with this is using RFC 3543? When MN is truly disconnected, FA sends revocation to the HA to remove the binding. Then it's always clear when there is a NEW session since old bindings don't hang around long. Kent=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Pete McCann > Sent: Monday, June 20, 2005 7:36 AM > To: Avi Lior > Cc: Mip4@ietf.org; Chowdhury, Kuntal; Henrik Levkowetz;=20 > Charles E.Perkins > Subject: RE: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 > Avi, >=20 > One comment below: >=20 > Avi Lior writes: > > Charlie and All, > > > > Here is an example of the problem (as I understand it)=20 > Kuntal or others may > correct me or add to this. > > > > Consider the case where customers are billed based on time. > > > > Now consider what happens when a mobile deregisters but=20 > the deregistration > is lost; the binding cache in the HA=20 > will become stale. In order not to > overbill the user, the=20 > HA -- everytime a binding update goes stale could > then=20 > attempt to determine when the session actually terminated by=20 > looking at > other indicators to determine the last activity=20 > time. Note this operation > is expensive but it is=20 > important for accurate billing of customers and hence >=20 > important to operators. > > > > If however, the same mobile preforms a new registration=20 > before the lifetime > of the previous registration expires,=20 > then the HA will see this new > registration as a=20 > re-registration. The HA will then NOT attempt to >=20 > re-compute the real session time and the user will be billed=20 > for that time. > > > > In some environments such as wirelss this could happen=20 > relatively frequently > and operators are concerned about=20 > these issues and want to make sure that > they do everything=20 > possible to bill appropriately. > > > > One solution to this problem is as Kuntal suggested. In=20 > his particular case > where the HOA is allocated by the home=20 > network then if the mobile always > sends an HOA with=20 > 0.0.0.0 in new registration then we can then deferentiate >=20 > between new registration and a re-registration. > > > > However, when the MN is assigned a static HOA then that=20 > "hint" is no longer > available. We need something else. =20 > What that something else is I am not > sure. But it seems=20 > to me that we should have explicitly indicated whether a >=20 > registration is a new registration or a re-registration. This=20 > would make the > protcol more robust. >=20 > Let's say we add a flag to indicate a "new registration" and=20 > then users won't be billed for time between the last=20 > registration and a "new registration". What is to prevent me=20 > from setting this flag in every single registration? Let's=20 > say the MN is set up to be a seldom-used server so you can't=20 > really tell from traffic flow whether the MN is still out=20 > there listening. Then I won't be billed for any time at all,=20 > but the MN is still available to receive packets from the HA=20 > at any time. >=20 > I think we do need a more detailed case analysis of the=20 > address assignment implications when the HoA =3D 0.0.0.0 and=20 > this should be in a > 2794 bis document. This is planned to be completed by the=20 > working group. However, we need to consider carefully=20 > whether this kind of a billing requirement needs to be addressed. >=20 > > Another solution is to reduce the lifetime of a=20 > registration. This may be > workable in fixed wireline=20 > mobile ip application but it is not a good idea > for=20 > wireless mobile ip applications due to the expensive over the=20 > air > resources. >=20 > As long as there is a binding in the HA the MN is getting=20 > some kind of service from the HA (the HA is available to=20 > forward packets). >=20 > -Pete >=20 > > Perhaps I should ask this question from those who know=20 > this subject far > better than me, is there a reliable way=20 > for the HA to reliably deferentiate > between a=20 > Re-registration, a new Re-gistration? > > > > > -----Original Message----- > > > From: Charles E.Perkins [mailto:charliep@iprg.nokia.com]=20 > > > Sent: Thursday, June 16, 2005 6:43 PM > > To:=20 > Chowdhury, Kuntal > > Cc: Mip4@ietf.org; Henrik Levkowetz >=20 > > Subject: Re: [Mip4] HoA=3D0.0.0.0 question > > > > > > >=20 > > Hello Kuntal, > > > > "Chowdhury, Kuntal" wrote: > > > > > > > What I understand from your responses is that HoA=3D0=20 > should > > be treated > > > by the HA as a new registration=20 > request (since an HoA assignment is > > > involved here). Is=20 > this a correct understanding? > > > > > > I'd rather not modify the specification about how the >=20 > > home agent might distinguish this as a new Request. > > > Just from memory, without perusing the document, > > I=20 > believe that the concept of "new registration" > > > in the base specification is tied closely to the > >=20 > use of the same "Identification" field within the > >=20 > Registration Request, and I would not want to disturb > >=20 > the meaning of that term. > > > > > > Moreover, I don't yet fully understand the need, even >=20 > > in the context of AAA protocols. > > > > > > Regards, > > > Charlie P. > > > > > > -- > > > 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 > > > Supplemental site: http://www.mip4.org/ > > > > -- >=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 > > Supplemental site: http://www.mip4.org/ >=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 Jun 21 11:21:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkkZY-00025c-Pc; Tue, 21 Jun 2005 11:21:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkkZX-00025X-4m for mip4@megatron.ietf.org; Tue, 21 Jun 2005 11:21:55 -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 LAA29751 for ; Tue, 21 Jun 2005 11:21:52 -0400 (EDT) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkkxR-0008HB-40 for Mip4@ietf.org; Tue, 21 Jun 2005 11:46:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 4D5EB90003; Tue, 21 Jun 2005 11:21:38 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06948-02; Tue, 21 Jun 2005 11:21:34 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 21 Jun 2005 11:21:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Tue, 21 Jun 2005 11:21:32 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D9091@ames.starentnetworks.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcV1paIyNUmrmbFJTEq6NZgPm9rnZAAeFsNgABStnDA= From: "Chowdhury, Kuntal" To: "Kent Leung (kleung)" , "Pete McCann" , "Avi Lior" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: quoted-printable Cc: Mip4@ietf.org, Henrik Levkowetz , "Charles E.Perkins" 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 > So maybe a better scheme to deal with this is using RFC 3543? When MN > is truly disconnected, FA sends revocation to the HA to remove the > binding. Then it's always clear when there is a NEW session since old > bindings don't hang around long. As always, there are holes in every proposal. What if the revocation = message is lost (never reached the HA)?=20 > Note that I would still set HoA=3D0 for every RRQ on the MN to=20 > save some $ > for time-based billing. :) =20 Yes, you can...but if you do that you run the risk of getting a = different address (HoA) every time you send an RRQ. This is because, the = HAs may treat the HoA=3D0 as a new registration, therefore tear down the = old binding and admit a new binding and assign a new HoA. This may break = your applications/sessions. To save a few cents you will cause yourself = more pain in that case. Besides, it does not take too much time for the = operators to figure out revenue leaks. Ideally, what MIP4 WG should do, IMHO: a. Define a reliable way to distinguish registrations from = re-registrations. b. Define a reliable way to distinguish registrations from retransmitted = registrations when Timestamp based ID is used. (In some situations, the = network nodes (FA, HA, AAA) get pounded due to too frequent = retransmissions of RRQs. -Kuntal > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, June 21, 2005 12:58 AM > To: Pete McCann; Avi Lior > Cc: Mip4@ietf.org; Chowdhury, Kuntal; Henrik Levkowetz; Charles > E.Perkins > Subject: RE: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 > Thanks Avi for clarifying the billing context. >=20 > Pete's issue about trusting the MN for billing comes to my=20 > mind as well. >=20 > I see the following implications of HoA =3D 0 in RRQ: >=20 > 1) Address assignment > HoA is set to address in existing binding, IMHO >=20 > 2) Authentication > HA may or may not go to AAA for authentication. Pros and cons > of each method. Maybe up to operator to decide. No interoperability > issue between HA and AAA server either way. >=20 > 3) Accounting > HA generate AAA accounting record which includes the HoA=3D0 > value. One possible solution is to calculate the time difference > between this RRQ and last time traffic was accounted for this MN. The > reason is that charging is based on usage, which is indicated=20 > by traffic > to/from MN, independent of registration timers. >=20 >=20 > Note that I would still set HoA=3D0 for every RRQ on the MN to=20 > save some $ > for time-based billing. :) =20 >=20 > So maybe a better scheme to deal with this is using RFC 3543? When MN > is truly disconnected, FA sends revocation to the HA to remove the > binding. Then it's always clear when there is a NEW session since old > bindings don't hang around long. >=20 > Kent=20 >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > > Behalf Of Pete McCann > > Sent: Monday, June 20, 2005 7:36 AM > > To: Avi Lior > > Cc: Mip4@ietf.org; Chowdhury, Kuntal; Henrik Levkowetz;=20 > > Charles E.Perkins > > Subject: RE: [Mip4] HoA=3D0.0.0.0 question > >=20 > >=20 > > Avi, > >=20 > > One comment below: > >=20 > > Avi Lior writes: > > > Charlie and All, > > > > > > Here is an example of the problem (as I understand it)=20 > > Kuntal or others may > correct me or add to this. > > > > > > Consider the case where customers are billed based on time. > > > > > > Now consider what happens when a mobile deregisters but=20 > > the deregistration > is lost; the binding cache in the HA=20 > > will become stale. In order not to > overbill the user, the=20 > > HA -- everytime a binding update goes stale could > then=20 > > attempt to determine when the session actually terminated by=20 > > looking at > other indicators to determine the last activity=20 > > time. Note this operation > is expensive but it is=20 > > important for accurate billing of customers and hence >=20 > > important to operators. > > > > > > If however, the same mobile preforms a new registration=20 > > before the lifetime > of the previous registration expires,=20 > > then the HA will see this new > registration as a=20 > > re-registration. The HA will then NOT attempt to >=20 > > re-compute the real session time and the user will be billed=20 > > for that time. > > > > > > In some environments such as wirelss this could happen=20 > > relatively frequently > and operators are concerned about=20 > > these issues and want to make sure that > they do everything=20 > > possible to bill appropriately. > > > > > > One solution to this problem is as Kuntal suggested. In=20 > > his particular case > where the HOA is allocated by the home=20 > > network then if the mobile always > sends an HOA with=20 > > 0.0.0.0 in new registration then we can then deferentiate >=20 > > between new registration and a re-registration. > > > > > > However, when the MN is assigned a static HOA then that=20 > > "hint" is no longer > available. We need something else. =20 > > What that something else is I am not > sure. But it seems=20 > > to me that we should have explicitly indicated whether a >=20 > > registration is a new registration or a re-registration. This=20 > > would make the > protcol more robust. > >=20 > > Let's say we add a flag to indicate a "new registration" and=20 > > then users won't be billed for time between the last=20 > > registration and a "new registration". What is to prevent me=20 > > from setting this flag in every single registration? Let's=20 > > say the MN is set up to be a seldom-used server so you can't=20 > > really tell from traffic flow whether the MN is still out=20 > > there listening. Then I won't be billed for any time at all,=20 > > but the MN is still available to receive packets from the HA=20 > > at any time. > >=20 > > I think we do need a more detailed case analysis of the=20 > > address assignment implications when the HoA =3D 0.0.0.0 and=20 > > this should be in a > > 2794 bis document. This is planned to be completed by the=20 > > working group. However, we need to consider carefully=20 > > whether this kind of a billing requirement needs to be addressed. > >=20 > > > Another solution is to reduce the lifetime of a=20 > > registration. This may be > workable in fixed wireline=20 > > mobile ip application but it is not a good idea > for=20 > > wireless mobile ip applications due to the expensive over the=20 > > air > resources. > >=20 > > As long as there is a binding in the HA the MN is getting=20 > > some kind of service from the HA (the HA is available to=20 > > forward packets). > >=20 > > -Pete > >=20 > > > Perhaps I should ask this question from those who know=20 > > this subject far > better than me, is there a reliable way=20 > > for the HA to reliably deferentiate > between a=20 > > Re-registration, a new Re-gistration? > > > > > > > -----Original Message----- > > > > From: Charles E.Perkins [mailto:charliep@iprg.nokia.com]=20 > > > > Sent: Thursday, June 16, 2005 6:43 PM > > To:=20 > > Chowdhury, Kuntal > > Cc: Mip4@ietf.org; Henrik Levkowetz >=20 > > > Subject: Re: [Mip4] HoA=3D0.0.0.0 question > > > > > > >=20 > > > Hello Kuntal, > > > > "Chowdhury, Kuntal" wrote: > > > > > > > > > What I understand from your responses is that HoA=3D0=20 > > should > > be treated > > > by the HA as a new registration=20 > > request (since an HoA assignment is > > > involved here). Is=20 > > this a correct understanding? > > > > > > > > I'd rather not modify the specification about how the >=20 > > > home agent might distinguish this as a new Request. > > > > Just from memory, without perusing the document, > > I=20 > > believe that the concept of "new registration" > > > > in the base specification is tied closely to the > >=20 > > use of the same "Identification" field within the > >=20 > > Registration Request, and I would not want to disturb > >=20 > > the meaning of that term. > > > > > > > > Moreover, I don't yet fully understand the need, even >=20 > > > in the context of AAA protocols. > > > > > > > > Regards, > > > > Charlie P. > > > > > > > > -- > > > > 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 > > > > Supplemental site: http://www.mip4.org/ > > > > -- >=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 > > > Supplemental site: http://www.mip4.org/ > >=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 > 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 Jun 21 12:16:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DklMf-0005ZN-LX; Tue, 21 Jun 2005 12:12:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DklMd-0005XQ-1F for mip4@megatron.ietf.org; Tue, 21 Jun 2005 12:12:39 -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 MAA04448 for ; Tue, 21 Jun 2005 12:12:36 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DklkZ-0001Ni-2E for mip4@ietf.org; Tue, 21 Jun 2005 12:37:24 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2005 09:12:29 -0700 X-IronPort-AV: i="3.93,218,1115017200"; d="scan'208"; a="644913535:sNHT31075932" 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 j5LGBUrM005239; Tue, 21 Jun 2005 09:12:25 -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, 21 Jun 2005 09:12:18 -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] HoA=0.0.0.0 question Date: Tue, 21 Jun 2005 09:12:15 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC524A0AC6@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcV1paIyNUmrmbFJTEq6NZgPm9rnZAAeFsNgABStnDAAAq07YA== From: "Kent Leung \(kleung\)" To: "Chowdhury, Kuntal" , "Pete McCann" , "Avi Lior" X-OriginalArrivalTime: 21 Jun 2005 16:12:18.0369 (UTC) FILETIME=[FF266B10:01C5767B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: Mip4@ietf.org, Henrik Levkowetz , "Charles E.Perkins" 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 =20 > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Tuesday, June 21, 2005 8:22 AM > To: Kent Leung (kleung); Pete McCann; Avi Lior > Cc: Mip4@ietf.org; Henrik Levkowetz; Charles E.Perkins > Subject: RE: [Mip4] HoA=3D0.0.0.0 question >=20 > > So maybe a better scheme to deal with this is using RFC=20 > 3543? When MN=20 > > is truly disconnected, FA sends revocation to the HA to remove the=20 > > binding. Then it's always clear when there is a NEW=20 > session since old=20 > > bindings don't hang around long. >=20 > As always, there are holes in every proposal. What if the=20 > revocation message is lost (never reached the HA)?=20 >=20 The messages support ack/retransmissions. > > Note that I would still set HoA=3D0 for every RRQ on the MN=20 > to save some=20 > > $ for time-based billing. :) >=20 > Yes, you can...but if you do that you run the risk of getting=20 > a different address (HoA) every time you send an RRQ. This is=20 > because, the HAs may treat the HoA=3D0 as a new registration,=20 > therefore tear down the old binding and admit a new binding=20 > and assign a new HoA. This may break your=20 > applications/sessions. To save a few cents you will cause=20 > yourself more pain in that case. Besides, it does not take=20 > too much time for the operators to figure out revenue leaks. >=20 But since the MN knows the reg lifetime, it can send RRQ with HoA=3D0 before expiration so the chance is good that mobility binding exists if HA is functioning properly. And HA has to consider the case when MN moves to a black-out area and provide the same HoA to MN whenever possible - the benefits of same HoA. Kent > Ideally, what MIP4 WG should do, IMHO: >=20 > a. Define a reliable way to distinguish registrations from=20 > re-registrations. > b. Define a reliable way to distinguish registrations from=20 > retransmitted registrations when Timestamp based ID is used.=20 > (In some situations, the network nodes (FA, HA, AAA) get=20 > pounded due to too frequent retransmissions of RRQs. >=20 > -Kuntal >=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 Jun 21 14:34:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DknaA-0008IL-7r; Tue, 21 Jun 2005 14:34:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkna8-0008GB-Fx for mip4@megatron.ietf.org; Tue, 21 Jun 2005 14:34: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 OAA15731 for ; Tue, 21 Jun 2005 14:34:43 -0400 (EDT) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkny5-00056u-ML for Mip4@ietf.org; Tue, 21 Jun 2005 14:59:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id E05AA90011; Tue, 21 Jun 2005 14:34:33 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08247-08; Tue, 21 Jun 2005 14:34:33 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 21 Jun 2005 14:34:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Tue, 21 Jun 2005 14:34:32 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D9094@ames.starentnetworks.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcV1paIyNUmrmbFJTEq6NZgPm9rnZAAeFsNgABStnDAAAq07YAAAwetg From: "Chowdhury, Kuntal" To: "Kent Leung (kleung)" , "Pete McCann" , "Avi Lior" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: Mip4@ietf.org, Henrik Levkowetz , "Charles E.Perkins" 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 > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, June 21, 2005 11:12 AM > To: Chowdhury, Kuntal; Pete McCann; Avi Lior > Cc: Mip4@ietf.org; Henrik Levkowetz; Charles E.Perkins > Subject: RE: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > > Sent: Tuesday, June 21, 2005 8:22 AM > > To: Kent Leung (kleung); Pete McCann; Avi Lior > > Cc: Mip4@ietf.org; Henrik Levkowetz; Charles E.Perkins > > Subject: RE: [Mip4] HoA=3D0.0.0.0 question > >=20 > > > So maybe a better scheme to deal with this is using RFC=20 > > 3543? When MN=20 > > > is truly disconnected, FA sends revocation to the HA to=20 > remove the=20 > > > binding. Then it's always clear when there is a NEW=20 > > session since old=20 > > > bindings don't hang around long. > >=20 > > As always, there are holes in every proposal. What if the=20 > > revocation message is lost (never reached the HA)?=20 > >=20 >=20 > The messages support ack/retransmissions. >=20 That does not guarantee anything. Links can be in a down state for a = while, right? >=20 > > > Note that I would still set HoA=3D0 for every RRQ on the MN=20 > > to save some=20 > > > $ for time-based billing. :) > >=20 > > Yes, you can...but if you do that you run the risk of getting=20 > > a different address (HoA) every time you send an RRQ. This is=20 > > because, the HAs may treat the HoA=3D0 as a new registration,=20 > > therefore tear down the old binding and admit a new binding=20 > > and assign a new HoA. This may break your=20 > > applications/sessions. To save a few cents you will cause=20 > > yourself more pain in that case. Besides, it does not take=20 > > too much time for the operators to figure out revenue leaks. > >=20 >=20 > But since the MN knows the reg lifetime, it can send RRQ with HoA=3D0 > before expiration so the chance is good that mobility binding=20 > exists if > HA is functioning properly. And HA has to consider the case when MN > moves to a black-out area and provide the same HoA to MN whenever > possible - the benefits of same HoA. >=20 MN's knowledge of the reg-lifetime won't save it from getting a new HoA = if it uses HoA=3D0 in every RRQ. Please note that this discussion did = not start based on how HAs should do address management. Rather the aim = here is to define a way to distinguish registrations from = re-registrations so that the HAs can apply N-number of local policies = (including interaction with the AAA) on the MIP sessions. > Kent >=20 >=20 > > Ideally, what MIP4 WG should do, IMHO: > >=20 > > a. Define a reliable way to distinguish registrations from=20 > > re-registrations. > > b. Define a reliable way to distinguish registrations from=20 > > retransmitted registrations when Timestamp based ID is used.=20 > > (In some situations, the network nodes (FA, HA, AAA) get=20 > > pounded due to too frequent retransmissions of RRQs. > >=20 > > -Kuntal > >=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 Jun 21 15:51:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkolx-0005Mh-Tu; Tue, 21 Jun 2005 15:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkol7-0005Ab-8C; Tue, 21 Jun 2005 15:50: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 PAA24785; Tue, 21 Jun 2005 15:50:07 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkp90-0007RU-Oc; Tue, 21 Jun 2005 16:14:51 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dkol0-0002bH-H1; Tue, 21 Jun 2005 15:50:02 -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: Tue, 21 Jun 2005 15:50:02 -0400 X-Spam-Score: 2.4 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-rfc3012bis-04.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 Challenge/Response Extensions (revised) Author(s) : C. Perkins, et al. Filename : draft-ietf-mip4-rfc3012bis-04.txt Pages : 37 Date : 2005-6-21 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. Furthermore, this document updates RFC3344 by including new authentication extension called the Mobile-AAA Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization using commonly available AAA infrastructure elements. This Authorization-enabling extension MAY co-exist in the same Registration Request with Authentication extensions defined for Mobile IP Registration by RFC3344. This document obsoletes RFC3012. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-rfc3012bis-04.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-rfc3012bis-04.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-rfc3012bis-04.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-6-21151847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-rfc3012bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-rfc3012bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-21151847.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 Jun 21 15:59:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkouR-000779-Qa; Tue, 21 Jun 2005 15:59:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkouQ-00076t-IL for mip4@megatron.ietf.org; Tue, 21 Jun 2005 15:59:46 -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 PAA26545 for ; Tue, 21 Jun 2005 15:59:44 -0400 (EDT) Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpIO-00080D-AH for Mip4@ietf.org; Tue, 21 Jun 2005 16:24:33 -0400 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id D409638214; Tue, 21 Jun 2005 21:59:24 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id A672C37FDD; Tue, 21 Jun 2005 21:59:24 +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 8D88537E43; Tue, 21 Jun 2005 21:59:23 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1Dkou2-0002DO-FW; Tue, 21 Jun 2005 21:59:22 +0200 Message-ID: <42B87193.2080208@levkowetz.com> Date: Tue, 21 Jun 2005 21:59:15 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip4] HoA=0.0.0.0 question References: <8A16DAD84432534FBFC19FD92B50512F035D9094@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F035D9094@ames.starentnetworks.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: b5d20af10c334b36874c0264b10f59f1 Cc: "Kent Leung \(kleung\)" , 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: , Content-Type: multipart/mixed; boundary="===============0279358465==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0279358465== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8CB6016DA6EE143CFA0D056D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8CB6016DA6EE143CFA0D056D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [Kent] >>>> Note that I would still set HoA=0 for every RRQ on the MN >>> to save some >>>> $ for time-based billing. :) This is a good point, and underlines the fact that it's pretty absurd to leave it up to the MN to signal, directly or indirectly, how and when it will be authenticated or billed. [Kuntal] >>> Yes, you can...but if you do that you run the risk of getting a >>> different address (HoA) every time you send an RRQ. This is >>> because, the HAs may treat the HoA=0 as a new registration, >>> therefore tear down the old binding and admit a new binding and >>> assign a new HoA. This may break your applications/sessions. To >>> save a few cents you will cause yourself more pain in that case. >>> Besides, it does not take too much time for the operators to >>> figure out revenue leaks. >>> You only run that risk with a fairly incompetent implementation of dynamic HoA assignment. An implementation which e.g. uses the mechanisms defined by and for DHCP will not make this mistake, and re-designing Mobile-IP because it would be possible to implement the dynamic address assignment feature in an incompetent manner seems a bit unnecessary. [Kent] >> But since the MN knows the reg lifetime, it can send RRQ with HoA=0 >> before expiration so the chance is good that mobility binding >> exists if HA is functioning properly. And HA has to consider the >> case when MN moves to a black-out area and provide the same HoA to >> MN whenever possible - the benefits of same HoA. >> Correct [Kuntal] > MN's knowledge of the reg-lifetime won't save it from getting a new > HoA if it uses HoA=0 in every RRQ. Please note that this discussion > did not start based on how HAs should do address management. Rather > the aim here is to define a way to distinguish registrations from > re-registrations so that the HAs can apply N-number of local policies > (including interaction with the AAA) on the MIP sessions. > I'm sorry to say this, but it seems to me, Kuntal, that you've decided that you want a certain solution, without being willing to take a step back and look at the broader picture and re-evaluate your options. As said above, a good implementation of dynamic address allocation will provide the same address if at all possible, even if the registration has lapsed meanwhile. However, your statement that the aim is to define a way to distinguish registrations from re-registrations is based on a belief that 1) this makes sense, and 2) it is possible. I've tried to say that both of these may be false, and in order to progress, could you please explain in more detail what it is you actually require? Could it be that doing something as simple as monitoring the CoA, and apply certain policies every time the CoA changes, would help you? Or maybe it is more appropriate to apply a policy every time a registration is done when there is no currently active binding? I believe there are many valid state changes available to trigger policy application off, without redesigning the protocol. Henrik --------------enig8CB6016DA6EE143CFA0D056D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFCuHGaeVhrtTJkXCMRAoM7AJ4+fQ3EhMuSdzN7PYYse5xKZNY2FACgxfx9 cUjFqLrSrcMtTiK5a3flg5M= =Sy6I -----END PGP SIGNATURE----- --------------enig8CB6016DA6EE143CFA0D056D-- --===============0279358465== 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/ --===============0279358465==-- From mip4-bounces@ietf.org Tue Jun 21 16:40:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkpY7-0006Ja-Ct; Tue, 21 Jun 2005 16:40:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkpY4-0006JE-Vk for mip4@megatron.ietf.org; Tue, 21 Jun 2005 16:40:45 -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 QAA12686 for ; Tue, 21 Jun 2005 16:40:42 -0400 (EDT) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkpw2-00058S-9l for Mip4@ietf.org; Tue, 21 Jun 2005 17:05:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2F6A39000E; Tue, 21 Jun 2005 16:40:33 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09132-10; Tue, 21 Jun 2005 16:40:32 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 21 Jun 2005 16:40:32 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Tue, 21 Jun 2005 16:40:30 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D9095@ames.starentnetworks.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcV2m9NKqam6CmxjQry0RVix8zfGEgAAy78w From: "Chowdhury, Kuntal" To: "Henrik Levkowetz" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: "Kent Leung \(kleung\)" , 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 Henrik, IMHO, HAs can assign the same HoA to the MN even if the HAs don't do = address management via DHCP. The idea of posting the question in the = first place was to clarify the behavior with MIP4 experts. After past = few days discussion, I think I got my answer: i.e. leave it upto the = implementation. I will log out of this discussion for now, and thanks for all the = responses. Regards, Kuntal=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Tuesday, June 21, 2005 2:59 PM > To: Chowdhury, Kuntal > Cc: Kent Leung (kleung); Mip4@ietf.org > Subject: Re: [Mip4] HoA=3D0.0.0.0 question >=20 >=20 >=20 > [Kent] > >>>> Note that I would still set HoA=3D0 for every RRQ on the MN > >>> to save some > >>>> $ for time-based billing. :) >=20 > This is a good point, and underlines the fact that it's pretty > absurd to leave it up to the MN to signal, directly or indirectly, > how and when it will be authenticated or billed. >=20 > [Kuntal] > >>> Yes, you can...but if you do that you run the risk of getting a > >>> different address (HoA) every time you send an RRQ. This is=20 > >>> because, the HAs may treat the HoA=3D0 as a new registration,=20 > >>> therefore tear down the old binding and admit a new binding and > >>> assign a new HoA. This may break your applications/sessions. To > >>> save a few cents you will cause yourself more pain in that case. > >>> Besides, it does not take too much time for the operators to > >>> figure out revenue leaks. > >>>=20 >=20 > You only run that risk with a fairly incompetent implementation of > dynamic HoA assignment. An implementation which e.g. uses the > mechanisms defined by and for DHCP will not make this mistake, and > re-designing Mobile-IP because it would be possible to implement the > dynamic address assignment feature in an incompetent manner seems > a bit unnecessary. >=20 > [Kent] > >> But since the MN knows the reg lifetime, it can send RRQ with = HoA=3D0 > >> before expiration so the chance is good that mobility binding=20 > >> exists if HA is functioning properly. And HA has to consider the > >> case when MN moves to a black-out area and provide the same HoA to > >> MN whenever possible - the benefits of same HoA. > >>=20 >=20 > Correct >=20 > [Kuntal] > > MN's knowledge of the reg-lifetime won't save it from getting a new > > HoA if it uses HoA=3D0 in every RRQ. Please note that this = discussion > > did not start based on how HAs should do address management. Rather > > the aim here is to define a way to distinguish registrations from > > re-registrations so that the HAs can apply N-number of=20 > local policies > > (including interaction with the AAA) on the MIP sessions. > >=20 >=20 > I'm sorry to say this, but it seems to me, Kuntal, that you've decided > that you want a certain solution, without being willing to take a step > back and look at the broader picture and re-evaluate your options. >=20 > As said above, a good implementation of dynamic address=20 > allocation will > provide the same address if at all possible, even if the registration > has lapsed meanwhile. >=20 > However, your statement that the aim is to define a way to distinguish > registrations from re-registrations is based on a belief that 1) this > makes sense, and 2) it is possible. >=20 > I've tried to say that both of these may be false, and in order to > progress, could you please explain in more detail what it is you > actually require? =20 >=20 > Could it be that doing something as simple as monitoring the CoA, and > apply certain policies every time the CoA changes, would help you? >=20 > Or maybe it is more appropriate to apply a policy every time a > registration is done when there is no currently active binding? >=20 > I believe there are many valid state changes available to trigger > policy application off, without redesigning the protocol. >=20 >=20 > Henrik >=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 Jun 21 17:02:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkptR-0006J4-S0; Tue, 21 Jun 2005 17:02:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkptK-0006GM-Qh for mip4@megatron.ietf.org; Tue, 21 Jun 2005 17:02:42 -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 RAA14220 for ; Tue, 21 Jun 2005 17:02:40 -0400 (EDT) Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkqHJ-0005gg-2C for mip4@ietf.org; Tue, 21 Jun 2005 17:27:30 -0400 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 9174A38386; Tue, 21 Jun 2005 23:02:31 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 7732E38317; Tue, 21 Jun 2005 23:02:31 +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 610AB37E43; Tue, 21 Jun 2005 23:02:31 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1Dkpt5-00049N-Ma; Tue, 21 Jun 2005 23:02:27 +0200 Message-ID: <42B88063.5020203@levkowetz.com> Date: Tue, 21 Jun 2005 23:02:27 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration with FHAE References: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@xmb-sjc-235.amer.cisco.com> <17064.21820.385129.666629@gargle.gargle.HOWL> <42A96E16.5050009@levkowetz.com> In-Reply-To: <42A96E16.5050009@levkowetz.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: 4d87d2aa806f79fed918a62e834505ca Cc: Pete McCann , mip4@ietf.org, "Kent Leung \(kleung\)" , "Charles E. Perkins" 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="===============2058858598==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2058858598== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig87906EC8DB5C0997E56660E6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig87906EC8DB5C0997E56660E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kent, Charlie, It seems to me that we have a definitive proposal from Pete (see below) which would resolve the issue, without violating the position of either of you. Could you please indicate if this solution is acceptable to you, in which case we could move forward and forge some text and finish the 3344bis; or alternatively, explain clearly why this solution is unworkable, so we can search some other resolution. Henrik On 2005-06-10 12:40 Henrik Levkowetz said the following: > On 06/09/2005 04:42 PM Pete McCann said the following: > [...] > >> In the multiple MSA case, we should also have text which states that >> the sender can use any of the applicable MSAs, and the receiver should >> be prepared to validate the message based on any of the MSAs. >> >> Also note that, given (1) and (2) above, if we add the lifetime field, >> it simply means that an authentication extension is not necessary to >> either add at the sender or check at the receiver. One possible >> approach to backwards compatibility is to mandate that the FA adds it >> anyway but just allow the HA to skip it when the lifetime=0. > > This seems like a good proposal to me. > > Henrik > --------------enig87906EC8DB5C0997E56660E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFCuIBjeVhrtTJkXCMRAmRVAJwL3XQctwnyDlAHNWIHeQAsfBAATgCg+XGH Gx5VXV05X3eFDs7RfHHCTbI= =E0/T -----END PGP SIGNATURE----- --------------enig87906EC8DB5C0997E56660E6-- --===============2058858598== 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/ --===============2058858598==-- From mip4-bounces@ietf.org Tue Jun 21 17:31:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkqLb-0008O8-M8; Tue, 21 Jun 2005 17:31:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkqLZ-0008MC-80 for mip4@megatron.ietf.org; Tue, 21 Jun 2005 17:31:53 -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 RAA16498 for ; Tue, 21 Jun 2005 17:31:50 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkqjX-0006QJ-TW for mip4@ietf.org; Tue, 21 Jun 2005 17:56:41 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5LL0FY13354; Tue, 21 Jun 2005 14:00:15 -0700 X-mProtect: <200506212100> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7BZHZh; Tue, 21 Jun 2005 14:00:13 PDT Message-ID: <42B88706.EDDEE0C0@iprg.nokia.com> Date: Tue, 21 Jun 2005 14:30:46 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration withFHAE References: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@xmb-sjc-235.amer.cisco.com> <17064.21820.385129.666629@gargle.gargle.HOWL> <42A96E16.5050009@levkowetz.com> <42B88063.5020203@levkowetz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Pete McCann , mip4@ietf.org, "Kent Leung \(kleung\)" 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 Hello Henrik, This is fine with me. Regards, Charlie P. Henrik Levkowetz wrote: > > Kent, Charlie, > > It seems to me that we have a definitive proposal from Pete (see below) > which would resolve the issue, without violating the position of either > of you. > > Could you please indicate if this solution is acceptable to you, in which > case we could move forward and forge some text and finish the 3344bis; or > alternatively, explain clearly why this solution is unworkable, so we can > search some other resolution. > > Henrik > > On 2005-06-10 12:40 Henrik Levkowetz said the following: > > On 06/09/2005 04:42 PM Pete McCann said the following: > > [...] > > > >> In the multiple MSA case, we should also have text which states that > >> the sender can use any of the applicable MSAs, and the receiver should > >> be prepared to validate the message based on any of the MSAs. > >> > >> Also note that, given (1) and (2) above, if we add the lifetime field, > >> it simply means that an authentication extension is not necessary to > >> either add at the sender or check at the receiver. One possible > >> approach to backwards compatibility is to mandate that the FA adds it > >> anyway but just allow the HA to skip it when the lifetime=0. > > > > This seems like a good proposal to me. > > > > Henrik > > > > -------------------------------------------------------------------------------- > Name: signature.asc > signature.asc Type: application/pgp-signature > Description: OpenPGP digital 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 Jun 21 18:47:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkrX3-0001n8-QX; Tue, 21 Jun 2005 18:47:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkrX1-0001n2-OZ for mip4@megatron.ietf.org; Tue, 21 Jun 2005 18:47: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 SAA21899 for ; Tue, 21 Jun 2005 18:47:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkrv1-00015R-7G for Mip4@ietf.org; Tue, 21 Jun 2005 19:12:36 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5LMGn514334; Tue, 21 Jun 2005 15:16:49 -0700 X-mProtect: <200506212216> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBSaI2I; Tue, 21 Jun 2005 15:16:48 PDT Message-ID: <42B898F7.3CAC0991@iprg.nokia.com> Date: Tue, 21 Jun 2005 15:47:19 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip4] HoA=0.0.0.0 question References: <8A16DAD84432534FBFC19FD92B50512F035D9095@ames.starentnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Hello Kuntal, "Chowdhury, Kuntal" wrote: > IMHO, HAs can assign the same HoA to the MN even if the HAs don't do address > management via DHCP. The idea of posting the question in the first place was > to clarify the behavior with MIP4 experts. After past few days discussion, > I think I got my answer: i.e. leave it upto the implementation. I didn't exactly see anyone else make that statement. > I will log out of this discussion for now, and thanks for all the responses. I would think that if you have an idea about how to fix a problem, you should consider writing an Internet Draft and finding other people who want to help solve the problem. Regards, Charlie P. -- 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 Jun 22 02:00:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkyI7-0006Z2-To; Wed, 22 Jun 2005 02:00:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkyI5-0006XW-Gz for mip4@megatron.ietf.org; Wed, 22 Jun 2005 02:00:49 -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 CAA26196 for ; Wed, 22 Jun 2005 02:00:47 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkyg9-0003kC-KK for Mip4@ietf.org; Wed, 22 Jun 2005 02:25:41 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5M60ZN07428; Wed, 22 Jun 2005 02:00:35 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jun 2005 02:00:35 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437108AC3C41@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "'Charles E.Perkins'" , "'Chowdhury, Kuntal'" Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Wed, 22 Jun 2005 02:00:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "'Mip4@ietf.org'" , 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: , Content-Type: multipart/mixed; boundary="===============1590659481==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1590659481== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C576EF.B2F8AE6A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C576EF.B2F8AE6A Content-Type: text/plain Hello Charlie, "Chowdhury, Kuntal" wrote: >> IMHO, HAs can assign the same HoA to the MN even if the HAs don't do >> address management via DHCP. The idea of posting the question in the >> first place was to clarify the behavior with MIP4 experts. After past >> few days discussion, I think I got my answer: i.e. leave it upto the >> implementation. > I didn't exactly see anyone else make that statement. You probably missed what Kent said. At least he clearly said it is implementation specific: "I agree with folks who said that there's no need to change any drafts since this is more of an implementation issue. The skipping of going to AAA server is an implementation optimization. This is a issue of that type of operation. " Regards, Ahmad ------_=_NextPart_001_01C576EF.B2F8AE6A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] HoA=3D0.0.0.0 question

Hello Charlie,

"Chowdhury, Kuntal" wrote:

>> IMHO, HAs can assign the same HoA to the MN = even if the HAs don't do
>> address management via DHCP. The idea of = posting the question in the
>> first place was to clarify the behavior = with MIP4 experts. After past
>> few days discussion, I think I got my = answer: i.e. leave it upto the
>> implementation.

> I didn't exactly see anyone else make that = statement.

You probably missed what Kent said. At least he = clearly said it is implementation specific:

"I agree with folks who said that there's no = need to change any drafts since this is more of an implementation = issue.  The skipping of going to AAA server is an implementation = optimization.  This is a issue of that type of operation. = "

Regards,
Ahmad

------_=_NextPart_001_01C576EF.B2F8AE6A-- --===============1590659481== 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/ --===============1590659481==-- From mip4-bounces@ietf.org Wed Jun 22 02:49:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkz3T-0006oP-7f; Wed, 22 Jun 2005 02:49:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkz3R-0006lZ-Ii for mip4@megatron.ietf.org; Wed, 22 Jun 2005 02:49:45 -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 CAA04841 for ; Wed, 22 Jun 2005 02:49:43 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkzRW-00054Z-3w for Mip4@ietf.org; Wed, 22 Jun 2005 03:14:38 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5M6nN312808; Wed, 22 Jun 2005 02:49:24 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jun 2005 02:49:09 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437108AC3C48@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "'Mip4@ietf.org'" Date: Wed, 22 Jun 2005 02:49:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: "'kleung@cisco.com'" , Ahmad Muhanna , "'mkulkarn@cisco.com'" , "'alpesh@cisco.com'" Subject: [Mip4] "Mobile IPv4 Dynamic Home Agent Assignment " Possibility of MN re gistering with multiple HAs!! 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="===============0618520329==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0618520329== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C576F6.7A902EF6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C576F6.7A902EF6 Content-Type: text/plain 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.? Am I correct here? Thanks for your comments and reply. Regards, Ahmad ------_=_NextPart_001_01C576F6.7A902EF6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable "Mobile IPv4 Dynamic Home Agent Assignment " = Possibility of MN registering with multiple HAs!!

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.?

Am I correct here?
Thanks for your comments and reply.

Regards,
Ahmad

------_=_NextPart_001_01C576F6.7A902EF6-- --===============0618520329== 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/ --===============0618520329==-- From mip4-bounces@ietf.org Wed Jun 22 02:51:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkz5P-0007WW-VO; Wed, 22 Jun 2005 02:51:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkz5O-0007W7-2C for mip4@megatron.ietf.org; Wed, 22 Jun 2005 02:51:46 -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 CAA05172 for ; Wed, 22 Jun 2005 02:51:44 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkzTR-00057S-B6 for mip4@ietf.org; Wed, 22 Jun 2005 03:16:39 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2005 23:51:34 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5M6pTne009172; Wed, 22 Jun 2005 02:51:30 -0400 (EDT) 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, 21 Jun 2005 23:50:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Tue, 21 Jun 2005 23:49:52 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC524A0D83@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] HoA=0.0.0.0 question Thread-Index: AcV28AQFnQkAp8i0QcGHoTKU4ugq2gAASPvg From: "Kent Leung \(kleung\)" To: "Ahmad Muhanna" , "Charles E.Perkins" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 22 Jun 2005 06:50:47.0481 (UTC) FILETIME=[B83AA290:01C576F6] X-Spam-Score: 0.6 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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: , Content-Type: multipart/mixed; boundary="===============0235973710==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0235973710== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C576F6.B7E2F203" This is a multi-part message in MIME format. ------_=_NextPart_001_01C576F6.B7E2F203 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ahmad. =20 I would like to clarify the context of my statement quoted below. It was in response to the example given for differentiating new and re-registrations was: "Based on local policy the HA may have to process a new RRQ differently than a re-registration. For example, the local policy may not require the HA to perform AAA auth (i.e. process MN-AAA) every time the MN performs re-registration ..." There are _no_ standards specification on this authentication optimization. It is an implementation policy that exists today. Standards specifies that MN-AAA AE is authenticated by the AAA server, not subjectively ignored. But I don't have any problem with this method since it's a usage policy that's interoperable between HA and AAA using standards mapping of RRQ fields to RADIUS AVPs. So what triggers RADIUS messages can remain a user's knob, ranging from each registration to only when new binding is created, with steps in between. =20 Anyways, I agree with Charlie that the WG is always open to ideas on solving practical problems. Don't let a few comments dissuade you from writing an I-D to clarify the issues and potential solution. Maybe some of us are missing a few pieces of info (Avi's accounting perspective was good input). Henrik and Pete provided some good feedbacks which can generate some explanatory text in the doc. =20 =20 Kent ________________________________ From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Ahmad Muhanna Sent: Tuesday, June 21, 2005 11:01 PM To: 'Charles E.Perkins'; 'Chowdhury, Kuntal' Cc: 'Mip4@ietf.org'; Ahmad Muhanna Subject: RE: [Mip4] HoA=3D0.0.0.0 question =09 =09 Hello Charlie,=20 "Chowdhury, Kuntal" wrote:=20 >> IMHO, HAs can assign the same HoA to the MN even if the HAs don't do=20 >> address management via DHCP. The idea of posting the question in the=20 >> first place was to clarify the behavior with MIP4 experts. After past=20 >> few days discussion, I think I got my answer: i.e. leave it upto the=20 >> implementation.=20 > I didn't exactly see anyone else make that statement.=20 You probably missed what Kent said. At least he clearly said it is implementation specific:=20 "I agree with folks who said that there's no need to change any drafts since this is more of an implementation issue. The skipping of going to AAA server is an implementation optimization. This is a issue of that type of operation. " Regards,=20 Ahmad=20 ------_=_NextPart_001_01C576F6.B7E2F203 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Mip4] HoA=3D0.0.0.0 question
Hi Ahmad.
 
I would like to clarify the context of my = statement quoted=20 below.  It was in response to the example given for differentiating = new and=20 re-registrations was:

"Based on = local policy the=20 HA may have to process a new RRQ differently than a re-registration. For = example, the local policy may not require the HA to perform AAA auth = (i.e.=20 process MN-AAA) every time the MN performs re-registration ..."

There are _no_ standards specification on this=20 authentication optimization.  It is an implementation policy that = exists=20 today.  Standards specifies that MN-AAA AE is authenticated by the = AAA=20 server, not subjectively ignored.  But I don't have any problem = with this=20 method since it's a usage policy that's interoperable between HA and AAA = using=20 standards mapping of RRQ fields to RADIUS AVPs.  So what triggers = RADIUS=20 messages can remain a user's knob, ranging from each registration to = only when=20 new binding is created, with steps in between.
 
Anyways, I agree with Charlie that the WG is = always open to=20 ideas on solving practical problems.  Don't let a few comments = dissuade you=20 from writing an I-D to clarify the issues and potential solution. =20 Maybe some of us are missing a few pieces of info (Avi's accounting = perspective was good input).  Henrik and Pete provided some = good=20 feedbacks which can generate some explanatory text in the doc. =20
 
Kent

From: mip4-bounces@ietf.org=20 [mailto:mip4-bounces@ietf.org] On Behalf Of Ahmad=20 Muhanna
Sent: Tuesday, June 21, 2005 11:01 PM
To: = 'Charles=20 E.Perkins'; 'Chowdhury, Kuntal'
Cc: 'Mip4@ietf.org'; Ahmad=20 Muhanna
Subject: RE: [Mip4] HoA=3D0.0.0.0=20 question

Hello Charlie,

"Chowdhury, Kuntal" wrote:

>> IMHO, HAs can assign the same HoA to the MN = even if=20 the HAs don't do
>> address management = via DHCP.=20 The idea of posting the question in the
>> first=20 place was to clarify the behavior with MIP4 experts. After past=20
>> few days discussion, I think I got = my answer:=20 i.e. leave it upto the
>> = implementation.=20

> I didn't exactly see anyone else make that=20 statement.

You probably missed what Kent said. At least he = clearly said=20 it is implementation specific:

"I agree with folks who said that there's no need to = change=20 any drafts since this is more of an implementation issue.  The = skipping=20 of going to AAA server is an implementation optimization.  This = is a=20 issue of that type of operation. "

Regards,
Ahmad=20

------_=_NextPart_001_01C576F6.B7E2F203-- --===============0235973710== 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/ --===============0235973710==-- From mip4-bounces@ietf.org Wed Jun 22 03:14:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkzRe-0007Vu-UJ; Wed, 22 Jun 2005 03:14:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkzRc-0007Vk-KC for mip4@megatron.ietf.org; Wed, 22 Jun 2005 03:14: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 DAA06644 for ; Wed, 22 Jun 2005 03:14:42 -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.33) id 1Dkzph-0005dS-FH for Mip4@ietf.org; Wed, 22 Jun 2005 03:39:37 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5M7DC920902; Wed, 22 Jun 2005 03:13:12 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jun 2005 03:14:15 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437108AC3C53@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "'Kent Leung (kleung)'" , "'Charles E.Perkins'" , "'Chowdhury, Kuntal'" Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Wed, 22 Jun 2005 03:14:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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: , Content-Type: multipart/mixed; boundary="===============1262849324==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1262849324== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C576F9.FBE0E388" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C576F9.FBE0E388 Content-Type: text/plain Thanks Kent for the clarification. I thought that was the context of Kuntal's initial question. Regards, Ahmad -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Wednesday, June 22, 2005 1:50 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Charles E.Perkins; Chowdhury, Kuntal Cc: Mip4@ietf.org Subject: RE: [Mip4] HoA=0.0.0.0 question Hi Ahmad. I would like to clarify the context of my statement quoted below. It was in response to the example given for differentiating new and re-registrations was: "Based on local policy the HA may have to process a new RRQ differently than a re-registration. For example, the local policy may not require the HA to perform AAA auth (i.e. process MN-AAA) every time the MN performs re-registration ..." There are _no_ standards specification on this authentication optimization. It is an implementation policy that exists today. Standards specifies that MN-AAA AE is authenticated by the AAA server, not subjectively ignored. But I don't have any problem with this method since it's a usage policy that's interoperable between HA and AAA using standards mapping of RRQ fields to RADIUS AVPs. So what triggers RADIUS messages can remain a user's knob, ranging from each registration to only when new binding is created, with steps in between. Anyways, I agree with Charlie that the WG is always open to ideas on solving practical problems. Don't let a few comments dissuade you from writing an I-D to clarify the issues and potential solution. Maybe some of us are missing a few pieces of info (Avi's accounting perspective was good input). Henrik and Pete provided some good feedbacks which can generate some explanatory text in the doc. Kent _____ From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Ahmad Muhanna Sent: Tuesday, June 21, 2005 11:01 PM To: 'Charles E.Perkins'; 'Chowdhury, Kuntal' Cc: 'Mip4@ietf.org'; Ahmad Muhanna Subject: RE: [Mip4] HoA=0.0.0.0 question Hello Charlie, "Chowdhury, Kuntal" wrote: >> IMHO, HAs can assign the same HoA to the MN even if the HAs don't do >> address management via DHCP. The idea of posting the question in the >> first place was to clarify the behavior with MIP4 experts. After past >> few days discussion, I think I got my answer: i.e. leave it upto the >> implementation. > I didn't exactly see anyone else make that statement. You probably missed what Kent said. At least he clearly said it is implementation specific: "I agree with folks who said that there's no need to change any drafts since this is more of an implementation issue. The skipping of going to AAA server is an implementation optimization. This is a issue of that type of operation. " Regards, Ahmad ------_=_NextPart_001_01C576F9.FBE0E388 Content-Type: text/html Message
Thanks Kent for the clarification.
 
I thought that was the context of Kuntal's initial question.

Regards,
Ahmad

-----Original Message-----
From: Kent Leung (kleung) [mailto:kleung@cisco.com]
Sent: Wednesday, June 22, 2005 1:50 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Charles E.Perkins; Chowdhury, Kuntal
Cc: Mip4@ietf.org
Subject: RE: [Mip4] HoA=0.0.0.0 question

Hi Ahmad.
 
I would like to clarify the context of my statement quoted below.  It was in response to the example given for differentiating new and re-registrations was:

"Based on local policy the HA may have to process a new RRQ differently than a re-registration. For example, the local policy may not require the HA to perform AAA auth (i.e. process MN-AAA) every time the MN performs re-registration ..."

There are _no_ standards specification on this authentication optimization.  It is an implementation policy that exists today.  Standards specifies that MN-AAA AE is authenticated by the AAA server, not subjectively ignored.  But I don't have any problem with this method since it's a usage policy that's interoperable between HA and AAA using standards mapping of RRQ fields to RADIUS AVPs.  So what triggers RADIUS messages can remain a user's knob, ranging from each registration to only when new binding is created, with steps in between.
 
Anyways, I agree with Charlie that the WG is always open to ideas on solving practical problems.  Don't let a few comments dissuade you from writing an I-D to clarify the issues and potential solution.  Maybe some of us are missing a few pieces of info (Avi's accounting perspective was good input).  Henrik and Pete provided some good feedbacks which can generate some explanatory text in the doc. 
 
Kent

From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Ahmad Muhanna
Sent: Tuesday, June 21, 2005 11:01 PM
To: 'Charles E.Perkins'; 'Chowdhury, Kuntal'
Cc: 'Mip4@ietf.org'; Ahmad Muhanna
Subject: RE: [Mip4] HoA=0.0.0.0 question

Hello Charlie,

"Chowdhury, Kuntal" wrote:

>> IMHO, HAs can assign the same HoA to the MN even if the HAs don't do
>> address management via DHCP. The idea of posting the question in the
>> first place was to clarify the behavior with MIP4 experts. After past
>> few days discussion, I think I got my answer: i.e. leave it upto the
>> implementation.

> I didn't exactly see anyone else make that statement.

You probably missed what Kent said. At least he clearly said it is implementation specific:

"I agree with folks who said that there's no need to change any drafts since this is more of an implementation issue.  The skipping of going to AAA server is an implementation optimization.  This is a issue of that type of operation. "

Regards,
Ahmad

------_=_NextPart_001_01C576F9.FBE0E388-- --===============1262849324== 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/ --===============1262849324==-- From mip4-bounces@ietf.org Wed Jun 22 14:54:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlAMN-0005nm-Bl; Wed, 22 Jun 2005 14:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkunM-0003by-67; Tue, 21 Jun 2005 22:16: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 WAA08840; Tue, 21 Jun 2005 22:16:49 -0400 (EDT) Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkvBM-0006jG-45; Tue, 21 Jun 2005 22:41:42 -0400 Received: from hpn307pc2 (cpe-69-204-120-221.rochester.res.rr.com [69.204.120.221]) by ms-smtp-01.nyroc.rr.com (8.12.10/8.12.10) with SMTP id j5M2EbDX024922; Tue, 21 Jun 2005 22:14:38 -0400 (EDT) Message-ID: <046d01c576d0$293dd380$6601a8c0@hpn307pc2> From: "Wendi Heinzelman" To: "Wendi Heinzelman" Date: Tue, 21 Jun 2005 22:14:16 -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: 1.1 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Jun 2005 14:54:02 -0400 Cc: Subject: [Mip4] MobiCom 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 ******************************************************************* Call for Participation ACM MobiCom 2005 11th 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 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 26 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. Panels and Demonstrations. The program also includes a number of panel discussions on hot topics and technical demonstrations of experimental systems. 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, (d) Wide area wireless networks: 3G and beyond. Student Poster Session. For the first time, MobiCom hosts the ACM Student Research Competition. Students submitting to the poster session can receive up to $500 for their travel, depending on need and eligibility. Workshops. One day is dedicated to workshops on specific technical areas in mobile and wireless networking. The following workshops take place: - Foundations of Mobile Computing (DIAL M-POMC) - Dynamic Interconnection of Networks (DIN) - Vehicular Ad Hoc Networks (VANET) - Wireless Security (WiSe) - Wireless Mobile Applications and Services on WLAN Hotspots (WMASH) Registration is available at http://www.regmaster.com/mobicom2005.html. There is a discounted rate until August 5, 2005. ---------------------------------------------------------- Wendi B. Heinzelman Assistant Professor of Electrical and Computer Engineering University of Rochester P.O. Box 270126, Hopeman Building, Room 307 Rochester, NY 14627-0126 Phone: 585-275-4053 Fax: 585-273-4919 http://www.ece.rochester.edu/~wheinzel ---------------------------------------------------------- -- 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 Jun 22 14:54:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlAMN-0005oB-KZ; Wed, 22 Jun 2005 14:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7hX-0008Qy-RO for mip4@megatron.ietf.org; Wed, 22 Jun 2005 12:03: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 MAA26906 for ; Wed, 22 Jun 2005 12:03: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.33) id 1Dl85g-0005GO-BR for Mip4@ietf.org; Wed, 22 Jun 2005 12:28:41 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5MG2N902885 for ; Wed, 22 Jun 2005 12:02:23 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jun 2005 12:03:14 -0400 Message-ID: From: "Jayshree Bharatia" To: "'Mip4@ietf.org'" Date: Wed, 22 Jun 2005 12:03:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Wed, 22 Jun 2005 14:54:02 -0400 Cc: Subject: [Mip4] New version of RFC3012bis 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 Hello all, New version of rfc3012bis has been submitted (draft-ietf-mip4-rfc3012bis-04.txt). The following changes are made based on comments received from Pete McCann. - Introduced HA_WRONG_CHALLENGE error code. - Clarified use of FA Error extension in section 3.2. Also, editorial changes are made in sections 1, 1.1, 3.1 and 3.2. Please let me know if you have any comments/concerns. Regards, Jayshree -- 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 Jun 22 18:31:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlDlE-0007Xf-OI; Wed, 22 Jun 2005 18:31:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlDlB-0007XQ-TF for mip4@megatron.ietf.org; Wed, 22 Jun 2005 18:31:54 -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 SAA13524 for ; Wed, 22 Jun 2005 18:31:50 -0400 (EDT) Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlE9M-0006M8-VJ for mip4@ietf.org; Wed, 22 Jun 2005 18:56:55 -0400 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id 884FB38755; Thu, 23 Jun 2005 00:31:31 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 52549386E4 for ; Thu, 23 Jun 2005 00:31:31 +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 469E437E44 for ; Thu, 23 Jun 2005 00:31:31 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DlDkp-0001ej-3v for mip4@ietf.org; Thu, 23 Jun 2005 00:31:31 +0200 Message-ID: <42B9E6C2.1030900@levkowetz.com> Date: Thu, 23 Jun 2005 00:31:30 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) 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: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Mip4] Agenda items for Paris 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="===============1295852766==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1295852766== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig88D3097F756371CB743E7B1C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig88D3097F756371CB743E7B1C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, The MIP4 WG will meet in Paris, most likely in a 2 hour slot. At this time we'd like to solicit suggestions for agenda items. We will be talking at least about the 3 new drafts which we hope will be approved as charter items by then: The general strings, radius ext and fmipv4 drafts. Please send suggestions to Pete and myself. Regards, Henrik --------------enig88D3097F756371CB743E7B1C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFCuebCeVhrtTJkXCMRAhg7AKDFIJiNpiSO2q5B4f/XNGv+Z9dg7ACggxy5 T24DaP9IEPzpmwjDeKyOEGc= =XBJW -----END PGP SIGNATURE----- --------------enig88D3097F756371CB743E7B1C-- --===============1295852766== 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/ --===============1295852766==-- From mip4-bounces@ietf.org Thu Jun 23 11:28:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTcl-0001Zt-Lk; Thu, 23 Jun 2005 11:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTch-0001Zb-3g for mip4@megatron.ietf.org; Thu, 23 Jun 2005 11:28: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 LAA24118 for ; Thu, 23 Jun 2005 11:28:09 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlU10-0001X1-Sw for Mip4@ietf.org; Thu, 23 Jun 2005 11:53:21 -0400 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id j5NFinWZ026190 for ; Thu, 23 Jun 2005 08:44:49 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j5NFVIsq015945 for ; Thu, 23 Jun 2005 10:31:19 -0500 (CDT) Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Jun 2005 10:27:54 -0500 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Kent Leung \\(kleung\\)'" , Ahmad Muhanna , "Charles E.Perkins" , "Chowdhury, Kuntal" Subject: RE: [Mip4] HoA=0.0.0.0 question Date: Thu, 23 Jun 2005 10:27:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.4 (++) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a 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: , Content-Type: multipart/mixed; boundary="===============1126223829==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1126223829== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57807.A69DFBA1" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C57807.A69DFBA1 Content-Type: text/plain As far as authentication and interaction with AAA goes: The way I look at it, the MN uses MN-HA-AE if it has an MSA with the HA, if not it uses MN-AAA-AE. These MSAs are specified through SPIs, not through IP addresses (unless I missed something). So whether or not the HoA is zero or not, does not change anything. The main point is whether the MSA is still alive or not. We can also debate on how we can tie the MSA life time to the RRQ life time, but seeing all this discussion, maybe it is good to keep the possibility of "these two lifetimes being independent" open. Madjid -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Kent Leung \(kleung\) Sent: Wednesday, June 22, 2005 1:50 AM To: Ahmad Muhanna; Charles E.Perkins; Chowdhury, Kuntal Cc: Mip4@ietf.org Subject: RE: [Mip4] HoA=0.0.0.0 question Hi Ahmad. I would like to clarify the context of my statement quoted below. It was in response to the example given for differentiating new and re-registrations was: "Based on local policy the HA may have to process a new RRQ differently than a re-registration. For example, the local policy may not require the HA to perform AAA auth (i.e. process MN-AAA) every time the MN performs re-registration ..." There are _no_ standards specification on this authentication optimization. It is an implementation policy that exists today. Standards specifies that MN-AAA AE is authenticated by the AAA server, not subjectively ignored. But I don't have any problem with this method since it's a usage policy that's interoperable between HA and AAA using standards mapping of RRQ fields to RADIUS AVPs. So what triggers RADIUS messages can remain a user's knob, ranging from each registration to only when new binding is created, with steps in between. Anyways, I agree with Charlie that the WG is always open to ideas on solving practical problems. Don't let a few comments dissuade you from writing an I-D to clarify the issues and potential solution. Maybe some of us are missing a few pieces of info (Avi's accounting perspective was good input). Henrik and Pete provided some good feedbacks which can generate some explanatory text in the doc. Kent _____ From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Ahmad Muhanna Sent: Tuesday, June 21, 2005 11:01 PM To: 'Charles E.Perkins'; 'Chowdhury, Kuntal' Cc: 'Mip4@ietf.org'; Ahmad Muhanna Subject: RE: [Mip4] HoA=0.0.0.0 question Hello Charlie, "Chowdhury, Kuntal" wrote: >> IMHO, HAs can assign the same HoA to the MN even if the HAs don't do >> address management via DHCP. The idea of posting the question in the >> first place was to clarify the behavior with MIP4 experts. After past >> few days discussion, I think I got my answer: i.e. leave it upto the >> implementation. > I didn't exactly see anyone else make that statement. You probably missed what Kent said. At least he clearly said it is implementation specific: "I agree with folks who said that there's no need to change any drafts since this is more of an implementation issue. The skipping of going to AAA server is an implementation optimization. This is a issue of that type of operation. " Regards, Ahmad ------_=_NextPart_001_01C57807.A69DFBA1 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxodG1sPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCg0KDQo8bWV0YSBuYW1lPUdl bmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMCAoZmlsdGVyZWQpIj4NCjx0aXRsZT5S RTogW01pcDRdIEhvQT0wLjAuMC4wIHF1ZXN0aW9uPC90aXRsZT4NCg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkJhdGFu ZzsNCglwYW5vc2UtMToyIDMgNiAwIDAgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxAQmF0YW5nIjsNCglwYW5vc2UtMToyIDMgNiAwIDAgMSAxIDEg MSAxO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpo MQ0KCXttYXJnaW4tdG9wOjEyLjBwdDsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0 b206My4wcHQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpBcmlhbDsNCglmb250LXdlaWdodDpub3Jt YWw7fQ0KaDMNCgl7bWFyZ2luLXRvcDoxMi4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjMuMHB0Ow0KCW1hcmdpbi1sZWZ0Oi43NWluOw0KCXRleHQtaW5kZW50Oi0uNWlu Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCnAuUkZDaGVhZGluZzMsIGxpLlJGQ2hlYWRpbmczLCBkaXYuUkZDaGVhZGlu ZzMNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbGluZS1oZWlnaHQ6 MTIuMHB0Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuUkZDSGVhZGluZzMwLCBsaS5SRkNIZWFkaW5n MzAsIGRpdi5SRkNIZWFkaW5nMzANCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJbGluZS1oZWlnaHQ6MTIuMHB0Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuUkZDaGVhZGlu ZzMxLCBsaS5SRkNoZWFkaW5nMzEsIGRpdi5SRkNoZWFkaW5nMzENCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbGluZS1oZWlnaHQ6MTIuMHB0Ow0KCXBhZ2UtYnJlYWst YWZ0ZXI6YXZvaWQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe2ZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOm5h dnk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0K IC8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCiBvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT4NCjwvc3R5bGU+DQoNCjwvaGVhZD4NCg0KPGJvZHkg bGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24x Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om5hdnknPkFzIGZhciBhcyBhdXRoZW50aWNhdGlvbiBhbmQgaW50ZXJhY3Rpb24NCndpdGggQUFB IGdvZXM6IFRoZSB3YXkgSSBsb29rIGF0IGl0LCB0aGUgTU4gdXNlcyBNTi1IQS1BRSBpZiBpdCBo YXMgYW4gTVNBIHdpdGgNCnRoZSBIQSwgaWYgbm90IGl0IHVzZXMgTU4tQUFBLUFFLiBUaGVzZSBN U0FzIGFyZSBzcGVjaWZpZWQgdGhyb3VnaCBTUElzLCBub3QNCnRocm91Z2ggSVAgYWRkcmVzc2Vz ICh1bmxlc3MgSSBtaXNzZWQgc29tZXRoaW5nKS4gU28gd2hldGhlciBvciBub3QgdGhlIEhvQSBp cw0KemVybyBvciBub3QsIGRvZXMgbm90IGNoYW5nZSBhbnl0aGluZy4gVGhlIG1haW4gcG9pbnQg aXMgd2hldGhlciB0aGUgTVNBIGlzDQpzdGlsbCBhbGl2ZSBvciBub3QuIFdlIGNhbiBhbHNvIGRl YmF0ZSBvbiBob3cgd2UgY2FuIHRpZSB0aGUgTVNBIGxpZmUgdGltZSB0bw0KdGhlIFJSUSBsaWZl IHRpbWUsIGJ1dCBzZWVpbmcgYWxsIHRoaXMgZGlzY3Vzc2lvbiwgbWF5YmUgaXQgaXMgZ29vZCB0 byBrZWVwIHRoZQ0KcG9zc2liaWxpdHkgb2YgInRoZXNlIHR3byBsaWZldGltZXMgYmVpbmcgaW5k ZXBlbmRlbnQiIG9wZW4uPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6bmF2eSc+TWFkamlkPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+Jm5ic3A7PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhvbWEnPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJv bGQnPkZyb206PC9zcGFuPjwvYj4gbWlwNC1ib3VuY2VzQGlldGYub3JnDQpbbWFpbHRvOm1pcDQt Ym91bmNlc0BpZXRmLm9yZ10gPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPk9uIEJl aGFsZiBPZiA8L3NwYW4+PC9iPktlbnQNCkxldW5nIFwoa2xldW5nXCk8YnI+DQo8Yj48c3BhbiBz dHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9iPiBXZWRuZXNkYXksIEp1bmUg MjIsIDIwMDUNCjE6NTAgQU08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ VG86PC9zcGFuPjwvYj4gQWhtYWQgTXVoYW5uYTsgQ2hhcmxlcyBFLlBlcmtpbnM7DQpDaG93ZGh1 cnksIEt1bnRhbDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5DYzo8L3Nw YW4+PC9iPiBNaXA0QGlldGYub3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJv bGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFtNaXA0XSBIb0E9MC4wLjAuMA0KcXVlc3Rpb248 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPkhpIEFobWFkLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1 ZSc+SSB3b3VsZCBsaWtlIHRvIGNsYXJpZnkgdGhlIGNvbnRleHQgb2YgbXkNCnN0YXRlbWVudCBx dW90ZWQgYmVsb3cuJm5ic3A7IEl0IHdhcyBpbiByZXNwb25zZSB0byB0aGUgZXhhbXBsZSBnaXZl biBmb3INCmRpZmZlcmVudGlhdGluZyBuZXcgYW5kIHJlLXJlZ2lzdHJhdGlvbnMgd2FzOjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+JnF1b3Q7QmFzZWQNCm9uIGxvY2FsIHBvbGlj eSB0aGUgSEEgbWF5IGhhdmUgdG8gcHJvY2VzcyBhIG5ldyBSUlEgZGlmZmVyZW50bHkgdGhhbiBh DQpyZS1yZWdpc3RyYXRpb24uIEZvciBleGFtcGxlLCB0aGUgbG9jYWwgcG9saWN5IG1heSBub3Qg cmVxdWlyZSB0aGUgSEEgdG8NCnBlcmZvcm0gQUFBIGF1dGggKGkuZS4gcHJvY2VzcyBNTi1BQUEp IGV2ZXJ5IHRpbWUgdGhlIE1OIHBlcmZvcm1zDQpyZS1yZWdpc3RyYXRpb24mbmJzcDsuLi4mcXVv dDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250 LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5UaGVyZSBhcmUgX25vXyBzdGFuZGFyZHMgc3BlY2lm aWNhdGlvbiBvbg0KdGhpcyBhdXRoZW50aWNhdGlvbiBvcHRpbWl6YXRpb24uJm5ic3A7IEl0IGlz IGFuIGltcGxlbWVudGF0aW9uIHBvbGljeSB0aGF0IGV4aXN0cw0KdG9kYXkuJm5ic3A7IFN0YW5k YXJkcyBzcGVjaWZpZXMgdGhhdCBNTi1BQUEgQUUgaXMgYXV0aGVudGljYXRlZCBieSB0aGUgQUFB DQpzZXJ2ZXIsIG5vdCBzdWJqZWN0aXZlbHkgaWdub3JlZC4mbmJzcDsgQnV0IEkgZG9uJ3QgaGF2 ZSBhbnkgcHJvYmxlbSB3aXRoIHRoaXMNCm1ldGhvZCBzaW5jZSBpdCdzIGEgdXNhZ2UgcG9saWN5 IHRoYXQncyBpbnRlcm9wZXJhYmxlIGJldHdlZW4gSEEgYW5kIEFBQSB1c2luZw0Kc3RhbmRhcmRz IG1hcHBpbmcgb2YgUlJRIGZpZWxkcyB0byBSQURJVVMgQVZQcy4mbmJzcDsgU28gd2hhdCB0cmln Z2VycyBSQURJVVMNCm1lc3NhZ2VzIGNhbiByZW1haW4gYSB1c2VyJ3Mga25vYiwgcmFuZ2luZyBm cm9tIGVhY2ggcmVnaXN0cmF0aW9uIHRvIG9ubHkgd2hlbg0KbmV3IGJpbmRpbmcgaXMgY3JlYXRl ZCwgd2l0aCBzdGVwcyBpbiBiZXR3ZWVuLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+QW55d2F5 cywgSSBhZ3JlZSB3aXRoIENoYXJsaWUgdGhhdCB0aGUgV0cNCmlzIGFsd2F5cyBvcGVuIHRvIGlk ZWFzIG9uIHNvbHZpbmcgcHJhY3RpY2FsIHByb2JsZW1zLiZuYnNwOyBEb24ndCBsZXQgYSBmZXcN CmNvbW1lbnRzIGRpc3N1YWRlIHlvdSBmcm9tIHdyaXRpbmcgYW4gSS1EIHRvIGNsYXJpZnkgdGhl IGlzc3VlcyBhbmQgcG90ZW50aWFsDQpzb2x1dGlvbi4mbmJzcDsgTWF5YmUmbmJzcDtzb21lIG9m IHVzIGFyZSBtaXNzaW5nIGEgZmV3IHBpZWNlcyBvZiBpbmZvIChBdmkncw0KYWNjb3VudGluZyBw ZXJzcGVjdGl2ZSB3YXMgZ29vZCBpbnB1dCkuJm5ic3A7IEhlbnJpayBhbmQgUGV0ZSZuYnNwO3By b3ZpZGVkDQpzb21lIGdvb2QgZmVlZGJhY2tzIHdoaWNoIGNhbiBnZW5lcmF0ZSBzb21lIGV4cGxh bmF0b3J5IHRleHQgaW4gdGhlIGRvYy4mbmJzcDsgPC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5L ZW50PC9zcGFuPjwvZm9udD48L3A+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7DQpt YXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQnPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7 PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBz dHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxmb250IHNpemU9Mw0KZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+DQoNCjxociBzaXplPTIgd2lkdGg9 IjEwMCUiIGFsaWduPWNlbnRlcj4NCg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGI+PGZvbnQgc2l6ZT0yIGZh Y2U9VGFob21hPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhv bWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udA0Kc2l6ZT0y IGZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRh aG9tYSc+DQptaXA0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptaXA0LWJvdW5jZXNAaWV0Zi5v cmddIDxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDoNCmJvbGQnPk9uIEJlaGFsZiBPZiA8L3Nw YW4+PC9iPkFobWFkIE11aGFubmE8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9s ZCc+U2VudDo8L3NwYW4+PC9iPiBUdWVzZGF5LCBKdW5lIDIxLCAyMDA1IDExOjAxDQpQTTxicj4N CjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiAnQ2hhcmxl cyBFLlBlcmtpbnMnOw0KJ0Nob3dkaHVyeSwgS3VudGFsJzxicj4NCjxiPjxzcGFuIHN0eWxlPSdm b250LXdlaWdodDpib2xkJz5DYzo8L3NwYW4+PC9iPiAnTWlwNEBpZXRmLm9yZyc7IEFobWFkIE11 aGFubmE8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3Nw YW4+PC9iPiBSRTogW01pcDRdIEhvQT0wLjAuMC4wDQpxdWVzdGlvbjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+SGVsbG8NCkNoYXJsaWUsPC9zcGFuPjwvZm9udD4gPC9wPg0KDQo8 cD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+JnF1b3Q7Q2hvd2RodXJ5LA0KS3VudGFsJnF1b3Q7IHdyb3RlOjwvc3Bhbj48 L2ZvbnQ+IDwvcD4NCg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsmZ3Q7DQpJTUhPLCBIQXMgY2FuIGFzc2ln biB0aGUgc2FtZSBIb0EgdG8gdGhlIE1OIGV2ZW4gaWYgdGhlIEhBcyBkb24ndCBkbzwvc3Bhbj48 L2ZvbnQ+DQo8YnI+DQo8Zm9udCBzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PiZndDsmZ3Q7IGFkZHJlc3MgbWFuYWdlbWVudCB2aWENCkRIQ1AuIFRoZSBpZGVhIG9mIHBvc3Rp bmcgdGhlIHF1ZXN0aW9uIGluIHRoZSA8L3NwYW4+PC9mb250Pjxicj4NCjxmb250IHNpemU9Mj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyZndDsgZmlyc3QgcGxhY2Ugd2FzIHRv IGNsYXJpZnkNCnRoZSBiZWhhdmlvciB3aXRoIE1JUDQgZXhwZXJ0cy4gQWZ0ZXIgcGFzdCA8L3Nw YW4+PC9mb250Pjxicj4NCjxmb250IHNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+Jmd0OyZndDsgZmV3IGRheXMgZGlzY3Vzc2lvbiwgSQ0KdGhpbmsgSSBnb3QgbXkgYW5zd2Vy OiBpLmUuIGxlYXZlIGl0IHVwdG8gdGhlIDwvc3Bhbj48L2ZvbnQ+PGJyPg0KPGZvbnQgc2l6ZT0y PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlvbi48 L3NwYW4+PC9mb250Pg0KPC9wPg0KDQo8cD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyBJDQpkaWRuJ3QgZXhhY3Rs eSBzZWUgYW55b25lIGVsc2UgbWFrZSB0aGF0IHN0YXRlbWVudC48L3NwYW4+PC9mb250PiA8L3A+ DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz5Zb3UNCnByb2JhYmx5IG1pc3NlZCB3aGF0IEtlbnQgc2FpZC4gQXQg bGVhc3QgaGUgY2xlYXJseSBzYWlkIGl0IGlzIGltcGxlbWVudGF0aW9uDQpzcGVjaWZpYzo8L3Nw YW4+PC9mb250PiA8L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mcXVvdDtJDQphZ3JlZSB3aXRoIGZvbGtz IHdobyBzYWlkIHRoYXQgdGhlcmUncyBubyBuZWVkIHRvIGNoYW5nZSBhbnkgZHJhZnRzIHNpbmNl IHRoaXMNCmlzIG1vcmUgb2YgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUuJm5ic3A7IFRoZSBza2lw cGluZyBvZiBnb2luZyB0byBBQUEgc2VydmVyDQppcyBhbiBpbXBsZW1lbnRhdGlvbiBvcHRpbWl6 YXRpb24uJm5ic3A7IFRoaXMgaXMgYSBpc3N1ZSBvZiB0aGF0IHR5cGUgb2YNCm9wZXJhdGlvbi4g JnF1b3Q7PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5SZWdhcmRzLDwvc3Bhbj48 L2ZvbnQ+DQo8YnI+DQo8Zm9udCBzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PkFobWFkPC9zcGFuPjwvZm9udD4gPC9wPg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjwvZGl2Pg0KDQo8 L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C57807.A69DFBA1-- --===============1126223829== 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/ --===============1126223829==-- From mip4-bounces@ietf.org Fri Jun 24 09:54:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlodI-0001Fo-EL; Fri, 24 Jun 2005 09:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlodH-0001Fg-7l for mip4@megatron.ietf.org; Fri, 24 Jun 2005 09:54: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 JAA09902 for ; Fri, 24 Jun 2005 09:54:09 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlp1n-00022l-BB for Mip4@ietf.org; Fri, 24 Jun 2005 10:19:32 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5ODroO07489; Fri, 24 Jun 2005 09:53:50 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jun 2005 09:53:51 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437108C1173A@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "'Mip4@ietf.org'" Date: Fri, 24 Jun 2005 09:53:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: "'kleung@cisco.com'" , "'mkulkarn@cisco.com'" , "'alpesh@cisco.com'" Subject: [Mip4] RE: "Mobile IPv4 Dynamic Home Agent Assignment " Possibility of M N registering with multiple HAs!! 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="===============1612517808==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1612517808== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C578C4.21347D36" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C578C4.21347D36 Content-Type: text/plain Hello Milind, Alpesh, Kent, Do you have any comments regarding this? What do you think? Is this a real issue? No issue? Thanks for your comments! Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Wednesday, June 22, 2005 1:49 AM To: 'Mip4@ietf.org' Cc: 'mkulkarn@cisco.com'; 'alpesh@cisco.com'; 'kleung@cisco.com'; Muhanna, Ahmad [RICH2:2Q30:EXCH] Subject: "Mobile IPv4 Dynamic Home Agent Assignment " Possibility of MN registering with multiple HAs!! 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.? Am I correct here? Thanks for your comments and reply. Regards, Ahmad ------_=_NextPart_001_01C578C4.21347D36 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: "Mobile IPv4 Dynamic Home Agent Assignment " = Possibility of MN registering with multiple HAs!!

Hello Milind, Alpesh, Kent,

Do you have any comments regarding this?
What do you think? Is this a real issue? No = issue?
Thanks for your comments!

Regards,
Ahmad


-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Wednesday, June 22, 2005 1:49 AM
To: 'Mip4@ietf.org'
Cc: 'mkulkarn@cisco.com'; 'alpesh@cisco.com'; = 'kleung@cisco.com'; Muhanna, Ahmad [RICH2:2Q30:EXCH]
Subject: "Mobile IPv4 Dynamic Home Agent = Assignment " Possibility of MN registering with multiple = HAs!!


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.?

Am I correct here?
Thanks for your comments and reply.

Regards,
Ahmad

------_=_NextPart_001_01C578C4.21347D36-- --===============1612517808== 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/ --===============1612517808==-- From mip4-bounces@ietf.org Fri Jun 24 12:49:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrMe-0006oE-4m; Fri, 24 Jun 2005 12:49:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrMb-0006o9-Ta for mip4@megatron.ietf.org; Fri, 24 Jun 2005 12:49: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 MAA24189 for ; Fri, 24 Jun 2005 12:49:07 -0400 (EDT) Received: from uekaegateway.mam.gov.tr ([193.140.74.2] helo=uekae.uekae.gov.tr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlrlA-00016O-A2 for mip4@ietf.org; Fri, 24 Jun 2005 13:14:33 -0400 Received: by uekae.uekae.gov.tr (UEKAE MAIL SERVER, from userid 2432) id 815ED55E9C; Fri, 24 Jun 2005 19:52:24 +0300 (EEST) Received: from www.uekae.tubitak.gov.tr (unknown [192.168.5.6]) by uekae.uekae.gov.tr (UEKAE MAIL SERVER) with ESMTP id 5E06055E99 for ; Fri, 24 Jun 2005 19:52:21 +0300 (EEST) Received: from 85.97.88.100 (SquirrelMail authenticated user umuttekin) by www.uekae.tubitak.gov.tr with HTTP; Fri, 24 Jun 2005 19:47:13 +0300 (EEST) Date: Fri, 24 Jun 2005 19:47:13 +0300 (EEST) From: "Umut Tekin" To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-9 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable Message-Id: <20050624165224.CFD6255E9B@uekae.uekae.gov.tr> X-Spam-Score: 0.8 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: quoted-printable Subject: [Mip4] (no subject) 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 -- 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 Jun 29 13:05:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dng04-0004pL-53; Wed, 29 Jun 2005 13:05:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dng02-0004p1-Ss; Wed, 29 Jun 2005 13:05: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 NAA11467; Wed, 29 Jun 2005 13:05:20 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DngPd-0005ZE-Hf; Wed, 29 Jun 2005 13:31:50 -0400 Message-ID: <083701c57ccc$e2e99a60$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , , , Date: Wed, 29 Jun 2005 10:06:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Subject: [Mip4] BOF on Network-based Localized Mobility Management at 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: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Phil Roberts and I are organizing a BOF on network based localized mobility management (netlmm) for IETF 63. The idea is to provide support in the local access network for mobility management so that a mobile node doesn't have to change its IP address so frequently. The BOF description is at: http://www.geocities.com/kempf42/netlmm-bof.txt There's a mailing list: netlmm@ngnet.it https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm, to subscribe Currently, the list is being used by co-authors of the problem statement and requirements drafts, but please subscribe and join in discussion if you would like. Please don't respond to this message, since any discussion on the proposed BOF should be on the BOF list. The problem statement draft is available from the Internet Drafts repository: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=13248 The requirements draft is about complete and will be posted to the Internet Drafts repository by the end of the week. I'll send email to the list about it when its posted. Phil and I are working on a proposed WG charter, we'll post the charter to the list when its complete. jak -- 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 Jun 29 14:21:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnhCB-00079J-PF; Wed, 29 Jun 2005 14:21:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnhCA-000796-Vc for mip4@megatron.ietf.org; Wed, 29 Jun 2005 14:21:59 -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 OAA20821 for ; Wed, 29 Jun 2005 14:21:57 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnhbl-0001TX-F6 for mip4@ietf.org; Wed, 29 Jun 2005 14:48:26 -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 j5TILjh4003819; Wed, 29 Jun 2005 13:21:45 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j5TILiq17762; Wed, 29 Jun 2005 13:21:44 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id IIUZ0B-0001VS-00; Wed, 29 Jun 2005 14:21:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17090.59060.329625.825928@gargle.gargle.HOWL> Date: Wed, 29 Jun 2005 13:21:40 -0500 From: Pete McCann To: mip4@ietf.org Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration withFHAE In-Reply-To: <42B88706.EDDEE0C0@iprg.nokia.com> References: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@xmb-sjc-235.amer.cisco.com> <17064.21820.385129.666629@gargle.gargle.HOWL> <42A96E16.5050009@levkowetz.com> <42B88063.5020203@levkowetz.com> <42B88706.EDDEE0C0@iprg.nokia.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "Kent Leung \(kleung\)" , Henrik Levkowetz , "Charles E.Perkins" 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 Proposed resolution of Issue #45: Section 3.5.4: Remove the sentence: The Foreign-Home Authentication extension MUST NOT be applied to deregistration messages. Replace the following: In order to perform the authentication, the Home Agent and the Foreign Agent have to have configured a security association that is able to be indexed by use of the SPI and the care-of address assocated with the Foreign Agent. This care-of address MUST be used as the Source IP address of the Registration Request containing the Foreign-Home Authentication Extension. with: In order to perform the authentication, the Home Agent and the Foreign Agent have to have configured a security association that is able to be indexed by use of the SPI and the Source IP of the Registration Request containing the Foreign-Home Authentication Extension. Section 3.8.1: Replace the following: When receiving a Registration Request from a foreign agent, if the home agent shares a mobility security association with the foreign agent, the home agent MUST check the Authenticator in the required Foreign-Home Authentication Extension in the message, based on this mobility security association. with: When receiving a Registration Request from a foreign agent, if the home agent shares a mobility security association with the foreign agent, the home agent MUST check the Authenticator in the required Foreign-Home Authentication Extension in the message, based on this mobility security association, unless the Lifetime field equals 0. When processing a Registration Request with Lifetime=0, the HA MAY skip checking for the presence and validity of a Foreign-Home Authentication Extension. -- 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 Jun 29 16:16:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnixH-0000K7-L7; Wed, 29 Jun 2005 16:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnixF-0000JE-BA for mip4@megatron.ietf.org; Wed, 29 Jun 2005 16:14:41 -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 QAA13974 for ; Wed, 29 Jun 2005 16:14:39 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnjMq-0002YJ-Lg for mip4@ietf.org; Wed, 29 Jun 2005 16:41:10 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5TJhOY31433; Wed, 29 Jun 2005 12:43:24 -0700 X-mProtect: <200506291943> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTWpSfd; Wed, 29 Jun 2005 12:43:23 PDT Message-ID: <42C30116.436906BC@iprg.nokia.com> Date: Wed, 29 Jun 2005 13:14:14 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration withFHAE References: <2979E38DD6FC6544B789C8DAD7BAFC523A46AA@xmb-sjc-235.amer.cisco.com> <17064.21820.385129.666629@gargle.gargle.HOWL> <42A96E16.5050009@levkowetz.com> <42B88063.5020203@levkowetz.com> <42B88706.EDDEE0C0@iprg.nokia.com> <17090.59060.329625.825928@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, 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 Hello Pete, This is fine with me. Just let me know, and I will prepare the next (and perhaps last!) revision of rfc3344bis. Regards, Charlie P. Pete McCann wrote: > > Proposed resolution of Issue #45: > > Section 3.5.4: > > Remove the sentence: > The Foreign-Home Authentication extension MUST NOT be applied to > deregistration messages. > > Replace the following: > In order to perform the authentication, the Home Agent and the > Foreign Agent have to have configured a security association that > is able to be indexed by use of the SPI and the care-of address > assocated with the Foreign Agent. This care-of address MUST be used > as the Source IP address of the Registration Request containing the > Foreign-Home Authentication Extension. > with: > In order to perform the authentication, the Home Agent and the > Foreign Agent have to have configured a security association that > is able to be indexed by use of the SPI and the Source IP of the > Registration Request containing the Foreign-Home Authentication > Extension. > > Section 3.8.1: > Replace the following: > When receiving a Registration Request > from a foreign agent, if the home agent shares a mobility security > association with the foreign agent, the home agent MUST check the > Authenticator in the required Foreign-Home Authentication Extension > in the message, based on this mobility security association. > with: > When receiving a Registration Request from a foreign agent, if the > home agent shares a mobility security association with the foreign > agent, the home agent MUST check the Authenticator in the required > Foreign-Home Authentication Extension in the message, based on this > mobility security association, unless the Lifetime field equals 0. > When processing a Registration Request with Lifetime=0, the HA MAY > skip checking for the presence and validity of a Foreign-Home > Authentication Extension. > > -- > 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 Thu Jun 30 03:15:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DntGw-0006w7-CS; Thu, 30 Jun 2005 03:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DntGu-0006uJ-KY for mip4@megatron.ietf.org; Thu, 30 Jun 2005 03:15:40 -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 DAA11475 for ; Thu, 30 Jun 2005 03:15:39 -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.33) id 1Dntgc-00028s-Vv for mip4@ietf.org; Thu, 30 Jun 2005 03:42:15 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Jun 2005 00:15:30 -0700 X-IronPort-AV: i="3.93,244,1115017200"; d="scan'208"; a="284552388:sNHT29846962" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5U7FPVZ015197; Thu, 30 Jun 2005 00:15:27 -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); Thu, 30 Jun 2005 00:15:25 -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] Issue #45; Seeking closure for on deregistration withFHAE Date: Thu, 30 Jun 2005 00:15:19 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52514B5F@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] Issue #45; Seeking closure for on deregistration withFHAE Thread-Index: AcV813cWLKv2eyQATIyat7yTOFFZhQAV/WQA From: "Kent Leung \(kleung\)" To: "Pete McCann" , X-OriginalArrivalTime: 30 Jun 2005 07:15:25.0302 (UTC) FILETIME=[7C623960:01C57D43] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: Henrik Levkowetz , "Charles E.Perkins" 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. Looks good. Some minor comments and few questions below.=20 > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com]=20 > Sent: Wednesday, June 29, 2005 11:22 AM > To: mip4@ietf.org > Cc: Henrik Levkowetz; Charles E.Perkins; Kent Leung (kleung) > Subject: Re: [Mip4] Issue #45; Seeking closure for on=20 > deregistration withFHAE >=20 >=20 > Proposed resolution of Issue #45: >=20 > Section 3.5.4: >=20 > Remove the sentence: > The Foreign-Home Authentication extension MUST NOT be applied to > deregistration messages. >=20 > Replace the following: > In order to perform the authentication, the Home Agent and the > Foreign Agent have to have configured a security association that > is able to be indexed by use of the SPI and the care-of address > assocated with the Foreign Agent. This care-of address=20 > MUST be used > as the Source IP address of the Registration Request containing the > Foreign-Home Authentication Extension. =20 > with: > In order to perform the authentication, the Home Agent and the > Foreign Agent have to have configured a security association that > is able to be indexed by use of the SPI and the Source IP of the > Registration Request containing the Foreign-Home Authentication > Extension. >=20 KL>=20 Not sure if this text is any clearer or not? I'm OK either way. In order to perform the authentication, the Home Agent and the Foreign Agent are configured with a mobility security association that is indexed by the SPI (in the appended Foreign-Home Authentication=20 Extension) and the IP Source Address of the Registration Request. >=20 > Section 3.8.1: > Replace the following: > When receiving a Registration Request > from a foreign agent, if the home agent shares a mobility security > association with the foreign agent, the home agent MUST check the > Authenticator in the required Foreign-Home Authentication Extension > in the message, based on this mobility security association. > with: > When receiving a Registration Request from a foreign agent, if the > home agent shares a mobility security association with the foreign > agent, the home agent MUST check the Authenticator in the required > Foreign-Home Authentication Extension in the message, based on this > mobility security association, unless the Lifetime field equals 0. > When processing a Registration Request with Lifetime=3D0, the HA = MAY > skip checking for the presence and validity of a Foreign-Home > Authentication Extension. >=20 KL> If HA skips checking the presence of FHAE, then validity check is already bypassed. Change: When processing a Registration Request with Lifetime=3D0, the HA MAY skip checking for the presence and validity of a Foreign-Home Authentication Extension. To: When processing a Registration Request with Lifetime=3D0, the Home Agent MAY skip the Foreign-Home Authentication Extension. KL> What happens to extensions between MHAE and MFAE when MFAE is skipped? Are they also skipped since these extensions are no longer protected? Or they are processed normally, which is implicitly implied in current text. KL> Do we also need to change "MUST" to "MAY" for checking the FHAE in the RRP with Lifetime=3D0 in the section below? Else FA will send RRP with error code 68 to MN. I can't find what was agreed upon for FA processing of the RRP w/o FHAE from HA. 3.7.1: As with any node on the Internet, a foreign agent MAY also share mobility security associations with any other nodes. When relaying a Registration Request from a mobile node to its home agent, if the foreign agent shares a mobility security association with the home agent, it MUST add a Foreign-Home Authentication Extension to the Request and MUST check the required Foreign-Home Authentication Extension in the Registration Reply from the home agent (Sections 3.3 and 3.4).=20 KL> Inconsistency encountered: http://people.nokia.net/~charliep/txt/mobileip/rfc3344bis.txt Error code 68 is missing in section 3.4, but referenced in 3.7.3.1. 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 Thu Jun 30 04:49:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnuk9-0001aY-K0; Thu, 30 Jun 2005 04:49:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnuk7-0001aT-9s for mip4@megatron.ietf.org; Thu, 30 Jun 2005 04:49:55 -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 EAA17380 for ; Thu, 30 Jun 2005 04:49:53 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnv9q-0007a8-8y for mip4@ietf.org; Thu, 30 Jun 2005 05:16:30 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 696761850; Thu, 30 Jun 2005 10:49:39 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 10:49:38 +0200 Received: from [147.214.237.81] ([147.214.237.81]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 10:49:38 +0200 Message-ID: <42C3B218.5010900@levkowetz.com> Date: Thu, 30 Jun 2005 10:49:28 +0200 From: Henrik Levkowetz User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] Issue #45; Seeking closure for on deregistration withFHAE References: <2979E38DD6FC6544B789C8DAD7BAFC52514B5F@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52514B5F@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2005 08:49:38.0227 (UTC) FILETIME=[A5CA2030:01C57D50] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: Pete McCann , mip4@ietf.org, "Charles E.Perkins" 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 Inline... On 06/30/2005 09:15 AM Kent Leung (kleung) said the following: > Hi Pete. Looks good. Some minor comments and few questions below. > [...] >> >>Replace the following: >> In order to perform the authentication, the Home Agent and the >> Foreign Agent have to have configured a security association that >> is able to be indexed by use of the SPI and the care-of address >> assocated with the Foreign Agent. This care-of address MUST be used >> as the Source IP address of the Registration Request containing the >> Foreign-Home Authentication Extension. >>with: >> In order to perform the authentication, the Home Agent and the >> Foreign Agent have to have configured a security association that >> is able to be indexed by use of the SPI and the Source IP of the >> Registration Request containing the Foreign-Home Authentication >> Extension. > > KL> > > Not sure if this text is any clearer or not? I'm OK either way. > > In order to perform the authentication, the Home Agent and the > Foreign Agent are configured with a mobility security association that > is indexed by the SPI (in the appended Foreign-Home Authentication > Extension) and the IP Source Address of the Registration Request. Looks good to me >>Section 3.8.1: >>Replace the following: >> When receiving a Registration Request >> from a foreign agent, if the home agent shares a mobility security >> association with the foreign agent, the home agent MUST check the >> Authenticator in the required Foreign-Home Authentication Extension >> in the message, based on this mobility security association. >>with: >> When receiving a Registration Request from a foreign agent, if the >> home agent shares a mobility security association with the foreign >> agent, the home agent MUST check the Authenticator in the required >> Foreign-Home Authentication Extension in the message, based on this >> mobility security association, unless the Lifetime field equals 0. >> When processing a Registration Request with Lifetime=0, the HA MAY >> skip checking for the presence and validity of a Foreign-Home >> Authentication Extension. > > KL> If HA skips checking the presence of FHAE, then validity check is > already bypassed. > > Change: > > When processing a Registration Request with Lifetime=0, the HA MAY > skip checking for the presence and validity of a Foreign-Home > Authentication Extension. > > To: > > When processing a Registration Request with Lifetime=0, the Home Agent MAY > skip the Foreign-Home Authentication Extension. I prefer the original version - what you argue is correct, but I find the original text is more explicit, and matching how I'd think when implementing this... > KL> > > What happens to extensions between MHAE and MFAE when MFAE is skipped? > Are they also skipped since these extensions are no longer protected? > Or they are processed normally, which is implicitly implied in current > text. > The latter, I think. Do you have a position on this, Kent? > > Do we also need to change "MUST" to "MAY" for checking the FHAE in the > RRP with Lifetime=0 in the section below? Else FA will send RRP with > error code 68 to MN. I can't find what was agreed upon for FA > processing of the RRP w/o FHAE from HA. > > 3.7.1: > > As with any node on the Internet, a foreign agent MAY also share > mobility security associations with any other nodes. When relaying a > Registration Request from a mobile node to its home agent, if the > foreign agent shares a mobility security association with the home > agent, it MUST add a Foreign-Home Authentication Extension to the > Request and MUST check the required Foreign-Home Authentication > Extension in the Registration Reply from the home agent (Sections 3.3 > and 3.4). Yes, this change should be done to match the other one above. > KL> > > Inconsistency encountered: > > http://people.nokia.net/~charliep/txt/mobileip/rfc3344bis.txt > > Error code 68 is missing in section 3.4, but referenced in 3.7.3.1. Oops! Gremlins at work. Charlie, you need to speak sternly to your pets ;-) It's there in RFC 3344 but has been inexplicably lost here... Henrik -- 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/