From marc.brogle@sap.com Wed Feb 2 07:23:29 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7A53A6CD9 for ; Wed, 2 Feb 2011 07:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb5-yxktqOTa for ; Wed, 2 Feb 2011 07:23:28 -0800 (PST) Received: from smtpgw.sap-ag.de (smtpgw04.sap-ag.de [155.56.66.99]) by core3.amsl.com (Postfix) with ESMTP id B05003A6CD6 for ; Wed, 2 Feb 2011 07:23:27 -0800 (PST) From: "Brogle, Marc" To: "mip4@ietf.org" Date: Wed, 2 Feb 2011 16:26:37 +0100 Thread-Topic: IEEE WoWMoM 2011 Industry-Track: Paper Submission Deadline Extended to February 18, 2011 Thread-Index: AcvC7ZU94dSTQJEsRRy0EKAlap/+nQ== Message-ID: <9E6AD8FC163E774B845C845A7CB951091F82AE1D1F@DEWDFECCR04.wdf.sap.corp> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 Feb 2011 08:15:09 -0800 Subject: [Mip4] IEEE WoWMoM 2011 Industry-Track: Paper Submission Deadline Extended to February 18, 2011 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 15:27:05 -0000 ------------------------------------------------------------------------ CALL FOR PAPERS WoWMoM 2011 - Industry Track Twelfth International Symposium on a World of Wireless, Mobile and Multimedia Networks http://wowmom2011.imtlucca.it/callindustry.html sponsored by IEEE Computer Society, University of Texas at Arlington, IEEE CS TC on Computer Communications (TCCC) June 20-24, 2011 Lucca, Tuscany, Italy ------------------------------------------------------------------------ ****** SUBMISSION DEADLINE EXTENDED TO: February 18th, 2011 ******* ------------------------------------------------------------------------ IEEE WoWMoM 2011 is soliciting original and previously unpublished research papers from industry researchers and professionals for a one- day Industry Session. Specific topics of interest include, but are not limited to: - Wireless BAN, PAN, LAN and MAN - 3G and 4G Wireless Systems - Ad hoc, Sensor and Wireless Mesh Networks - Vehicle-to-X Communications (V2V, V2I, V2B) - Mobile P2P Networks - IP-based Mobile Networks - System Prototypes, Measurements and Real Deployment Experiences - Design of New Protocols and Performance Evaluation - Energy-Efficient Protocols and Power Management - Wireless Multimedia - Middleware and Wireless Applications=20 - Quality of Service and Quality of Experience Issues - Wireless Security, Dependability, Reliability and Survivability - Context-Aware Wireless Multimedia Applications - Location Mechanism and Services - Multicasting and Broadcasting Issues - Handoff and Mobility Management - Seamless Internetworking - Networking Services for Pervasive Systems - Network Management and Troubleshooting - Content Management and Distribution The Industry Session track is intended to specially highlight system experiences and proofs-of-concept in the areas above. Like regular=20 papers, the Industry Session papers will undergo a review process by an international TPC and will appear in the conference proceedings. However, the selection criteria for Industry Session papers are slightly different. In particular, papers should describe applications, prototypes or experiences of clear industry relevance. Papers with narrow=20 algorithmic focus or only high-level design details are discouraged. A=20 key goal of this session is to present systems-oriented research that exposes the academic and research communities to real-life issues and=20 problems being faced in industry. Accordingly, papers will be evaluated,=20 less on the novelty of specific algorithmic content, but by the=20 originality and general applicability of insights that can be inferred from the authors' implementation experience. PAPER SUBMISSION AND PUBLICATION ------------------------------------------------------------------------ Papers must be formatted according to the guidelines given in=20 http://wowmom2011.imtlucca.it/submission.html and submitted using EDAS. IMPORTANT DATES ------------------------------------------------------------------------ - Manuscript submission deadline: February 4th, 2011. - Manuscript submission deadline extended: February 18th, 2011. - Manuscript acceptance notification: April 4th, 2011. ORGANIZING COMMITTEE ------------------------------------------------------------------------ INDUSTRY TRACK CHAIRS - Marc Brogle, SAP Research, Switzerland - Xavier Perez-Costa, NEC Laboratories Europe, Germany INDUSTRY TRACK TECHNICAL PROGRAM COMMITTEE - Antonio Cimmino, Alcatel-Lucent, Italy - Nicola Ciulli, Nextworks, Italy - Michael Ditze, TWT, Germany - Michael Einhaus, Panasonic, Germany - Adam Flizikowski, iTTi, Poland - Guido Hiertz, Riedel Communications, Germany - Javier Jimenez, Telefonica I+D, Spain - Ayman Kaheel, Microsoft Innovation Lab, Egypt - Alberto Lopez Toledo, Telefonica I+D, Spain - Stefan Mangold, Disney Research Zurich, Switzerland - Telemaco Melia, Alcatel-Lucent, France - Markus Miche, SAP Research, Switzerland - Peter Rost, NEC Laboratories Europe, Germany - Patrick Stupar, Qualcomm, Germany - Andrea Tamatis, Hitachi, France From leszek.lilien@wmich.edu Fri Feb 4 00:10:04 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88433A6929 for ; Fri, 4 Feb 2011 00:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2abOc467gj0v for ; Fri, 4 Feb 2011 00:10:04 -0800 (PST) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by core3.amsl.com (Postfix) with ESMTP id 7F9F83A6909 for ; Fri, 4 Feb 2011 00:10:04 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from [99.92.232.170] (adsl-99-92-232-170.dsl.klmzmi.sbcglobal.net [99.92.232.170]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0LG3000EZ2UDYX60@mta01.service.private> for mip4@ietf.org; Fri, 04 Feb 2011 03:13:28 -0500 (EST) X-WMU-Spam: Gauge=IIIIIIII, Probability=8% on Fri Feb 4 03:13:28 2011, Report=' WMU_MSA_SMTP+ 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_BROADBAND 0, RDNS_GENERIC_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, SPF_NEUTRAL 0, TO_UNDISCLOSED_RECIPIENTS 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_CONTACT_NUM 0, __HAS_MSGID 0, __HIGHBITS 0, __INT_PROD_COMP 0, __INT_PROD_LOC 0, __INT_PROD_ONLINE 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_3 0, __URI_NS , __USER_AGENT 0' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.4.80323 - Fri Feb 4 03:13:27 2011 Sender: leszek.lilien@wmich.edu Message-id: <4D4BB51E.9030104@wmich.edu> Date: Fri, 04 Feb 2011 03:13:18 -0500 From: "Leszek T. Lilien" Organization: WMU User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 To: undisclosed-recipients: ; X-Mailman-Approved-At: Fri, 04 Feb 2011 08:15:09 -0800 Subject: [Mip4] CFP (due in 1 week): Specialized Ad Hoc Networks and Systems (SAHNS 2011 @ IEEE ICDCS 2011) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leszek.lilien@wmich.edu List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 08:10:04 -0000 ******************************************************************** We apologize in advance if you receive multiple copies of this CFP. Please disseminate CFP to your colleagues that might be interested. ******************************************************************** --------------------------------------------------------------------- CALL FOR PAPERS - due in 1 week >> Paper submission deadline extended till Friday, February 11 << SAHNS 2011 The Third International Workshop on Specialized Ad Hoc Networks and Systems Minneapolis, USA, June 23, 2011 http://www.cs.wmich.edu/~alfuqaha/SAHNS2011/ In conjunction with the IEEE 31st International Conference on Distributed Computing Systems (ICDCS 2011) --------------------------------------------------------------------- 1. SCOPE The Workshop provides a forum for engineers and scientists in academia, industry and government to present their latest research findings in specialized ad hoc networks and systems. As an alternative to one-size-fits-all general solutions in the area of ad hoc networking and systems, we want to stimulate the application-oriented divide-and-conquer approach to ad hoc network and system research. The goal is to provide sound and efficient specialized ad hoc networks and systems (SAHNS), suitable for building solutions specific for well-defined classes of applications or even individual applications. We want to consider both specialized ad hoc networks and specialized ad hoc systems. The latter can be built on top of specialized ad hoc networks. Alternatively, they can be constructed independently of specialized ad hoc networks, e.g., on top of general-purpose ad hoc networks. It should be emphasized that SAHNS is interested only in solutions specific to specialized ad hoc networks and systems. The Workshop is not interested in broad general-purpose solutions for all ad hoc networks and systems, or in generic solutions for extremely broad subclasses of ad hoc networks and systems. For example, the Workshop is not interested in general-purpose solutions for all sensornets or all P2P systems but is instead interested in specialized solutions for their application-oriented subclasses. One example of SAHNS targeted by this workshop are Incident Area Networks (IANs), dedicated to single incidents or events. An IAN can be pre-deployed for a planned event, such as a sporting or "nationally significant" event, or can be dynamically deployed for an unplanned incident, such as a local law enforcement situation or a natural disaster. Another example are opportunistic resource utilization networks (e.g., oppnets), in which the network reacts to a lack of resources by finding and incorporating "helpers" that have needed resources or services. Areas and topics of particular interest include, but are not limited to: a) Design issues for SAHNS: o Novel network and system architectures o Economically-based models and solutions (incl. incentive-based techniques) o Operating systems and middleware o Customized network protocols (incl. cross-layer and Layer 2.5 protocols) o Resource management solutions (incl. discovery and integration of resources) o Algorithms and models for localization and mobility management o Privacy, security, and trust o Reliability and dependability o Novel hardware platforms b) Development issues for SAHNS: o Development methodologies, models and tools o Analytical and validation models o Performance evaluation and modeling (incl. simulation tools) c) Operation and management issues for SAHNS: o Topology control and management o Energy control and management o Resource and service discovery and control o QoS provisioning and management o Data management, data aggregation, data dissemination, and query processing o Assuring survivability and reliability o Controls for privacy, security, and trust management d) Application issues for SAHNS: o Best current and future applications for SAHNS o Experience with SAHNS deployments and products o Social and business impacts of SAHNS-based applications 2. PAPER SUBMISSION Papers must be submitted in the PDF format, with numbered pages. They should have no more than 6 pages following the IEEE Computer Society proceedings format (8.5 by 11 inch sheets, double-column, 10 point or larger font, single-spaced). The following information must be provided on the first page: o Paper title o Full names, affiliations and email addresses of all authors o An abstract (up to 150 words) o Five to ten keywords/phrases o A footnote with the indication of the corresponding author, plus the complete address, phone and fax numbers of the corresponding author Papers should be submitted by emailing them to: llilien@wmich.edu Each received submission will be confirmed, usually within no more than two workdays. 3. PAPER REVIEW AND PUBLISHING Each paper will be peer-reviewed by at least two reviewers and their comments will be provided to the authors. If accepted, the paper will be published in the workshop proceedings by the IEEE Computer Society Press, provided that at least one of its authors registers for ICDCS (which includes SAHNS) by the early registration deadline. Information on indexing publications for the events of the IEEE Computer Society is available at: http://www.computer.org/portal/web/cscps/benefits#indexing We plan a special issue of an international journal with extended versions of the selected SAHNS papers. 4. IMPORTANT DEADLINES Paper submission - Friday, February 11, 2011 Author notification - Friday, March 11, 2011 Final manuscript due - Monday, March 30, 2011 5. COMMITTEES --------- Steering Committee --------- Bharat Bhargava, Purdue University, USA Torsten Braun, University of Bern, Switzerland Ajay Gupta, Western Michigan University, USA Leszek Lilien (Workshop Chair), Western Michigan University, USA Thomas Plagemann, University of Oslo, Norway --------- Technical Program Committee --------- Dharma P. Agrawal, University of Cincinnati, USA Ala Al-Fuqaha, Western Michigan University, USA Tom Altman, University of Colorado at Denver, USA Habib M. Ammari, Hofstra University, USA Michel Banâtre, IRISA-Rennes, France Lotfi Ben Othmane, Kalamazoo College, USA Vijay Bhuse, Parametric Technology, USA Glen Colby, Naval Air Systems Command, USA Andrew DeCarlo, Infoscitex, USA Ruy de Oliveira, Brazilian Federal Institute of Technology, Mato Grosso (IFMT), Brazil Leszek Gąsieniec, University of Liverpool, United Kingdom Jeong-Heon Hwang, University at Albany - State University of New York, USA Ireneusz Jóźwiak, Wroclaw University of Technology, Poland Steve Ko, University at Buffalo, The State University of New York, USA Dionysios Kountanis, Western Michigan University, USA Sandeep Kulkarni, Michigan State University, USA Yao-Nan Lien, National Chengchi University, Republic of China King-Shan Lui, University of Hong Kong, Hong Kong Sanjay Madria, Missouri University of Science and Technology, USA Kami Makki, Lamar University, USA Patrick Mitran, University of Waterloo, Canada Ravi Prakash, University of Texas at Dallas, USA Leonardo Querzoni, University of Rome "La Sapienza," Italy S.S. Ravi, University at Albany - State University of New York, USA Peter Reiher, UCLA, USA Sol Shatz, Univeristy of Illinois at Chicago, USA Vahid Tarokh, Harvard University, USA Dirk Timmermann, University of Rostock, Germany Goce Trajcevski, Northwestern University, USA Weichao Wang, University of North Carolina at Charlotte, USA Edward Wantuch, AGH University of Science and Technology, Poland Isaac Woungang, Ryerson University, Canada Sherali Zeadally, University of the District of Columbia, USA Krzysztof Zieliński, AGH University of Science and Technology, Poland --------- Organizing Committee --------- Publicity Chairs: Africa, Europe and Middle East: Athanasios (Thanos) Vasilakos, National Technical University of Athens (NTUA), Greece Asia and Australia: Mamata Jenamani, Indian Institute of Technology, Kharagpur, India Central and South America: Ruy de Oliveira, Brazilian Federal Institute of Technology, Mato Grosso (IFMT), Brazil North America: Ala Al-Fuqaha and Leszek T. Lilien, Western Michigan University, USA Publications Chair: James Yang, Western Michigan University, USA 6. FURTHER INFORMATION For further information please visit the SAHNS 2011 web pages at: http://www.cs.wmich.edu/~alfuqaha/SAHNS2011/ or contact Leszek T. Lilien, Workshop Chair (llilien@wmich.edu). --[CFP v.11.02.4c] -------------------------------------------------- From mccap@petoni.org Tue Feb 8 08:12:22 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37963A67CF for ; Tue, 8 Feb 2011 08:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nodmwj1ZcDkZ for ; Tue, 8 Feb 2011 08:12:21 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id AC6D63A672F for ; Tue, 8 Feb 2011 08:12:20 -0800 (PST) Received: by wyf23 with SMTP id 23so6233998wyf.31 for ; Tue, 08 Feb 2011 08:12:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.55.70 with SMTP id t6mr1061856wbg.212.1297181546961; Tue, 08 Feb 2011 08:12:26 -0800 (PST) Received: by 10.227.147.74 with HTTP; Tue, 8 Feb 2011 08:12:25 -0800 (PST) X-Originating-IP: [64.53.131.166] Date: Tue, 8 Feb 2011 10:12:25 -0600 Message-ID: From: Pete McCann To: mip4@ietf.org, draft-ietf-mip4-nemo-haaro.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:12:22 -0000 Hi, Below is my review of draft-ietf-mip4-nemo-haaro-03. I'd like to see some discussion on the major issues before we move to WGLC. -Pete Some issues in Section 3.2.3: The destination address is set to Correspondent Router's HoA. This is only true of the HoTI and CoTI messages, right? The text seems to say that all 4 messages have their destination address set to the CR's HoA. each containing a 64-bit random SHOULD BE: each containing a (different) 64-bit random It seems that 3.2.3 has a lot of text describing the route optimization procedure which would be better moved into its own sub-section. Suggest renaming 3.2.3 as "Route Optimization Overview" and putting "Updating Router keys and Nonces" in its own Section 3.2.4. In Section 3.2.3, try to be a bit more careful about describing the IP source and destination addresses of each message. I assume that the HoTI is sent with a source address equal to the HoA of the MR, and the CoTI is sent with a source address equal to the CoA of the MR. Both are sent to the HoA of the CR. The first must be reverse tunneled because it doesn't have a topologically correct source address, but the CoTI does not need to be so tunneled as long as the CR's HoA is globally routable. The response HoT and CoT messages are both sent from the CR's HoA and destined to the HoA and CoA of the MR, respectively. They must both be reverse tunneled to the HA. Is this right? More text is needed on how the keygen tokens are derived from the nonces, Kcrs, and CoAs. I know you may be repeating some of the MIP6 spec but it would be good for this spec to stand on its own. Section 3.3.3: The registration request MUST be set to the Home Address. SHOULD BE: The registration request MUST be sent to (have a destination address of) the Home Address of the Correspondent Router. Section 3.4: This section talks about triggering route optimization upon reception of a packet from a known network; however, 3.3.1 focused on the trigger being the transmission of a packet. Which is the preferred scenario? Section 4: The scheme for realm compression looks a bit complicated and I don't completely understand the reason for defining a new scheme that is so different from the one in RFC 1035. You say it achieves better compression but I think this is only true for odd cases where you want to compress the middle labels of a realm name that happen to match an earlier middle label but where the suffix doesn't match. I think it's more likely that MRs homed on the same HA will share the same suffixes. Also, DNS labels cannot be longer than 63 characters so you might as well use the top 2 bits of the label length field as DNS does (unless you think realm names have different rules?). Section 5.5: I thought that this Route Optimization Prefix Advertisement extension was what provided each correspondent router with the binding between MR HoA and mobile prefixes managed by that HoA. However, the rules given don't allow for the occurrence of an MR HoA and a prefix in the same listing. How exactly is the binding supposed to be achieved? Sections 5.5 - 5.9: You should add text describing how the IP and UDP fields are set in these new messages. Numerous editorial nits: The last sentence of the Abstract is a bit confusing: The functionality adds possibility to discover eligible peer nodes based on information received from Home Agent, Network Prefixes they represent, and how to establish direct tunnel between such nodes. Did you mean to say: The functionality adds the possibility to discover: eligible peer nodes based on information received from Home Agent; Network Prefixes they represent; and, how to establish a direct tunnel between such nodes. ? Section 1: proposes method SHOULD BE: proposes a method Although NAT and pending shortage of IPv4 addresses makes widespread deployment not feasible, using Route Optimization only in routers is still a practical scenario. Maybe be a bit more specific about what is not feasible: Although NAT and the pending shortage of IPv4 addresses makes widespread deployment of end-to-end route optimization infeasible, using Route Optimization from mobile router to mobile router is still a practical scenario. reliability and availability SHOULD BE: reliability, and availability From service provider perspective SHOULD BE: From a service provider perspective for enterprise SHOULD BE: for an enterprise MPLS VPNs or Layer 3 SHOULD BE: MPLS VPNs, or Layer 3 options however, are not reliable approach SHOULD BE: options, however, are not a reliable approach In this example case, organization network SHOULD BE: In this example case, the organization network two sites, that SHOULD BE: two sites that to the backend to minimum. SHOULD BE: on the backend to a minimum. beyond the need of a single, coordinating Home Agent. Did you mean: removing the need for a single, coordinating Home Agent. ? Section 3: domain; However, extranets SHOULD BE: domain; however, extranets The procedure aim SHOULD BE: The procedure aims are same SHOULD BE: are the same Section 3.1: regardless whether SHOULD BE: regardless of whether indicated with SHOULD BE: indicated with a (two instances) extension, see Section 5.1. SHOULD BE: extension; see Section 5.1. from Home Agent SHOULD BE: from the Home Agent registration timeouts and specific SHOULD BE: registration timeouts, and specific Section 3.1.1 As noted, NEMO-supporting Home Agent SHOULD BE: As noted, a NEMO-supporting Home Agent Only change to this functionality SHOULD BE: The only change to this functionality including Route Optimization capability extension, Section 5.1, SHOULD BE: including a Route Optimization Capability extension (Section 5.1) MUST include Route Optimization Reply extension (Section 5.2) to indicate whether Route Optimization was accepted. SHOULD BE: MUST include a Route Optimization Reply extension (Section 5.2) to indicate that the Route Optimization Capability extension was understood. informs Mobile Router if NAT was SHOULD BE: informs the Mobile Router whether NAT was with according prefix(es) SHOULD BE: with corresponding prefix(es) routers in customer's SHOULD BE: routers in the customer's e.g. Default prefix (0.0.0.0/0) pointing towards Internet gateway for Internet connectivity, and possible extranets. SHOULD BE: e.g. a default prefix (0.0.0.0/0) pointing towards an Internet gateway for Internet connectivity or additional prefixes belonging to possible extranets. within specific realm SHOULD BE: within a specific realm share same SHOULD BE: share the same receiving registration reply SHOULD BE: receiving a registration reply as a host-prefixes to SHOULD BE: as host-prefixes into SHALL also be inserted to SHOULD BE: SHALL also be inserted into Section 3.1.2: from Home Agent SHOULD BE: from the Home Agent prefix advertisements, and in registration messages SHOULD BE: prefix advertisements and in registration messages direction, see Section 3.3.4 SHOULD BE: direction; see Section 3.3.4 in Care-of-address extension in registration reply. If the entry exists, SHOULD BE: in the Care-of-address extension of a registration reply. If set to true, from Route Optimization Cache as long as tunnel SHOULD BE: from the Route Optimization Cache as long as a tunnel using Return Routability procedure, they are calculated in-situ based on nonces and router key. SHOULD BE: using a Return Routability procedure, it is calculated in-situ based on nonces and a router key. Care-of nonce indexes If the KRm was established with Return SHOULD BE: Care-of nonce indices If the KRm was established with a Return (Put a newline and indent all of the descriptions in the remainder of this section) Section 3.2: Same principles SHOULD BE: The same principles Two messages SHOULD BE: two messages to Correspondent Router's Home Address, one via Home Agent using Mobile Router's Home Address, SHOULD BE: to the Correspondent Router's Home Address, one via the Home Agent using the Mobile Router's Home Address by Mobile IP protocol SHOULD BE: by the Mobile IP protocol mechanism, Return Routability procedure SHOULD BE: mechanism, the Return Routability procedure Assumption on traffic patterns SHOULD BE: The main assumption on traffic patterns where mobile router is acting as a CR. SHOULD BE: where a mobile router is acting as a CR. Section 3.2.1: Correspondent Router uses router key to verify that the keygen tokens sent by Mobile Router in registration request are the CR's own. SHOULD BE: A Correspondent Router uses its router key to verify that the keygen tokens sent by a peer Mobile Router in a registration request are the CR's own. nonces, see SHOULD BE: nonces; see Section 3.2.2: The Mobile Router may use same nonces with all Mobile Routers. SHOULD BE: The Mobile Router may use the same nonces with all Correspondent Routers. Section 3.2.3: whose lifetime have SHOULD BE: whose lifetimes have Nonce should be kept acceptable SHOULD BE: A nonce should remain valid Section 3.3: The Mobile Router learns Correspondent Router's Care-of address by a new extension, "Care-of Address", in registration reply. SHOULD BE: The Mobile Router learns the Correspondent Router's Care-of address by a new extension, "Care-of Address", in the registration reply. Second issue is rising from security standpoint: In a registration SHOULD BE: The second issue is a security consideration: in a registration re-registration to Home Agent SHOULD BE: re-registration to the Home Agent Additional aspect is that Mobile Router MAY use different Care-of- Address for different Correspondent Routers SHOULD BE: An additional aspect is that a Mobile Router MAY use a different Care-of- Address for different Correspondent Routers where network provides SHOULD BE: where the network provides Section 3.3.1: at any time; However a better SHOULD BE: at any time; however, a better and destination address exists in the network prefixes of Route Optimization Cache. SHOULD BE: and whose destination address falls within the network prefixes of the Route Optimization Cache. With small number SHOULD BE: With a small number Section 3.3.3: between Mobile Router and Correspondent Router SHOULD BE: between a Mobile Router and a Correspondent Router either Return Routability procedure SHOULD BE: either the Return Routability procedure from desired interface SHOULD BE: from the desired interface address of desired outgoing interface SHOULD BE: address of the desired outgoing interface The address MAY be same as the Care-of address used with Home Agent. SHOULD BE: The address MAY be the same as the Care-of address used with the Home Agent. MUST include Mobile-Correspondent Authentication extension SHOULD BE: MUST include a Mobile-Correspondent Authentication extension SHOULD include Mobile Network Request Extension SHOULD BE: SHOULD include a Mobile Network Request Extension The registration reply MUST include Mobile-Correspondent Authentication extension SHOULD BE: The Registration Reply MUST include a Mobile-Correspondent Authentication extension conditions apply, registration request SHOULD BE: conditions apply, the Registration Request to facilitate detecting SHOULD BE: to facilitate detection (see Section (Section 10) SHOULD BE: (see Section 10) in it's Route Optimization Cache SHOULD BE: in its Route Optimization Cache by incoming Mobile Router SHOULD BE: by the incoming Mobile Router arbitrary networks; However, since Home Agent SHOULD BE: arbitrary networks; however, since the Home Agent authorize Mobile Router's claim SHOULD BE: authorize the Mobile Router's claim registrations from without this check SHOULD BE: registrations without this check and Route Optimization Cache updated. SHOULD BE: and the Route Optimization Cache updated. The reply MUST include a list of eligible care-of-addresses for the tunnel in Section 5.4, with which the Mobile Router may establish a tunnel with. SHOULD BE: The reply MUST include a list of eligible care-of-addresses (see Section 5.4) with which the Mobile Router may establish a tunnel. Mobile-Correspondent Authentication extensionSection 5.3. SHOULD BE: Mobile-Correspondent Authentication extension (see Section 5.3). The Correspondent Router's routing table MUST be updated to include the Mobile Router's networks are reachable SHOULD BE: The Correspondent Router's routing table MUST be updated to indicate that the Mobile Router's networks are reachable but only only act on it SHOULD BE: but only act on it Section 3.3.4: firewall.A deviation from RFC 3519 [RFC3519] is that keepalives should be sent both from ends of the tunnel SHOULD BE: firewall. A deviation from RFC 3519 [RFC3519] is that keepalives should be sent from both ends of the tunnel sending it's own SHOULD BE: sending its own in second SHOULD BE: per second Section 3.3.6 join home link SHOULD BE: join its home link if it's Route Optimization Cache SHOULD BE: whether its Route Optimization Cache in the order of ten seconds SHOULD BE: on the order of ten seconds at it is SHOULD BE: it is have to also be acquired SHOULD BE: have also to be acquired Section 3.4: assumption is that at least SHOULD BE: assumption that at least registers; Receives SHOULD BE: registers and receives (3 instances) receives to traffic SHOULD BE: receives traffic From antti.makela@aalto.fi Tue Feb 8 08:57:12 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2E53A67B8 for ; Tue, 8 Feb 2011 08:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LvRcUvPnHOW for ; Tue, 8 Feb 2011 08:57:11 -0800 (PST) Received: from mx04.aalto.fi (mx04.aalto.fi [130.233.222.103]) by core3.amsl.com (Postfix) with ESMTP id 9587A3A63D2 for ; Tue, 8 Feb 2011 08:57:10 -0800 (PST) Received: from mx04.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E1BA7F0718; Tue, 8 Feb 2011 18:57:16 +0200 (EET) Received: from EXHUB04.org.aalto.fi (ex-hub04.org.aalto.fi [130.233.222.117]) by mx04.aalto.fi (Postfix) with ESMTP id B8ABDF071C; Tue, 8 Feb 2011 18:57:16 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB04.org.aalto.fi ([130.233.222.117]) with mapi; Tue, 8 Feb 2011 18:57:16 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: Pete McCann , "mip4@ietf.org" , "draft-ietf-mip4-nemo-haaro.all@tools.ietf.org" Thread-Topic: Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLx6sEVyNvlxhxikqx2ukgnn8CzZP3zxvO Date: Tue, 8 Feb 2011 16:57:16 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> In-Reply-To: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:57:12 -0000 Hi, thanks for all comments. Based on this I'd say that most of these changes are editorial, some clarif= ications and one glaring mistake (in 3.4), which is in due to earlier chang= e that wasn't reflected everywhere in the document. Biggest issue seems to = be realm compression - this is something that Jouni can mostly comment on. >Some issues in Section 3.2.3: > > The destination address is set to > Correspondent Router's HoA. >This is only true of the HoTI and CoTI messages, right? The text seems >to say that all 4 messages have their destination address set >to the CR's HoA. > > each containing a 64-bit random >SHOULD BE: > each containing a (different) 64-bit random You are correct. Obviously the CoT/HoT's are replies to init messages. >It seems that 3.2.3 has a lot of text describing the route >optimization procedure which would be better moved into >its own sub-section. Suggest renaming 3.2.3 as "Route >Optimization Overview" and putting "Updating Router keys and Nonces" >in its own Section 3.2.4. I'll see about this. >In Section 3.2.3, try to be a bit more careful about describing >the IP source and destination addresses of each message. >I assume that the HoTI is sent with a source address equal >to the HoA of the MR, and the CoTI is sent with a source address >equal to the CoA of the MR. Both are sent to the HoA of the CR. This is correct. >The first must be reverse tunneled because it doesn't have a topologically >correct source address, but the CoTI does not need to be so tunneled >as long as the CR's HoA is globally routable. The response HoT and CoT >messages are both sent from the CR's HoA and destined to the HoA and >CoA of the MR, respectively. They must both be reverse tunneled >to the HA. Is this right? Correct as well. >More text is needed on how the keygen tokens are derived from the nonces, >Kcrs, and CoAs. I know you may be repeating some of the MIP6 spec but it = would >be good for this spec to stand on its own. Very well - I'll add some more clarifications (even though it is slightly= copy-paste from MIP6 spec). >Section 3.3.3: > The registration request MUST be set to the Home > Address. >SHOULD BE: > The registration request MUST be sent to (have a destination > address of) the Home > Address of the Correspondent Router. Agree. >Section 3.4: >This section talks about triggering route optimization upon >reception of a packet from a known network; however, 3.3.1 >focused on the trigger being the transmission of a packet. >Which is the preferred scenario? This is one of the changes made earlier due to comment on the list about = computational cost of matching based on destination prefix instead of sourc= e prefix. The transmission is correct. I need to change 3.4's text as well = - it's the old source prefix-matching behavior. Thank you very much for poi= nting this out. >Section 4: >The scheme for realm compression looks a bit complicated and >I don't completely understand the reason for defining a new >scheme that is so different from the one in RFC 1035. You say >it achieves better compression but I think this is only true for >odd cases where you want to compress the middle labels of >a realm name that happen to match an earlier middle label but >where the suffix doesn't match. I think it's more likely that >MRs homed on the same HA will share the same suffixes. > >Also, DNS labels cannot be longer than 63 characters so you >might as well use the top 2 bits of the label length field as >DNS does (unless you think realm names have different rules?). Jouni, can you comment? >Section 5.5: >I thought that this Route Optimization Prefix Advertisement >extension was what provided each correspondent router with >the binding between MR HoA and mobile prefixes managed >by that HoA. However, the rules given don't allow for the >occurrence of an MR HoA and a prefix in the same listing. >How exactly is the binding supposed to be achieved? Yes it does - our implementation does too. As it says, it's "1..n times t= he following information structure". The idea is that if you only have a mobile node (no network), then n=3D1,= and you have the extension as M=3D1, HoA=3Dx.x.x.x If the MR also has a network, then next occurrence has M=3D0, Prefix=3Da.a.a.a/oo If the MR has additional network, then next occurrence is M=3D0, Prefix=3Db.b.b.b/pp If there's another mobile node in the network, then next occurrence is M=3D1, HoA=3Dy.y.y.y ...and if it has network, well, you get the idea. >Sections 5.5 - 5.9: >You should add text describing how the IP and UDP fields >are set in these new messages. Ok. Numerous editorial nits: The last sentence of the Abstract is a bit confusing: The functionality adds possibility to discover eligible peer nodes based on information received from Home Agent, Network Prefixes they represent, and how to establish direct tunnel between such nodes. Did you mean to say: The functionality adds the possibility to discover: eligible peer nodes base= d on information received from Home Agent; Network Prefixes they represent; and, how to establish a direct tunnel between such nodes. ? Section 1: proposes method SHOULD BE: proposes a method Although NAT and pending shortage of IPv4 addresses makes widespread deployment not feasible, using Route Optimization only in routers is still a practical scenario. Maybe be a bit more specific about what is not feasible: Although NAT and the pending shortage of IPv4 addresses makes widespread deployment of end-to-end route optimization infeasible, using Route Optimization from mobile router to mobile router is still a practical scenario. reliability and availability SHOULD BE: reliability, and availability From service provider perspective SHOULD BE: From a service provider perspective for enterprise SHOULD BE: for an enterprise MPLS VPNs or Layer 3 SHOULD BE: MPLS VPNs, or Layer 3 options however, are not reliable approach SHOULD BE: options, however, are not a reliable approach In this example case, organization network SHOULD BE: In this example case, the organization network two sites, that SHOULD BE: two sites that to the backend to minimum. SHOULD BE: on the backend to a minimum. beyond the need of a single, coordinating Home Agent. Did you mean: removing the need for a single, coordinating Home Agent. ? Section 3: domain; However, extranets SHOULD BE: domain; however, extranets The procedure aim SHOULD BE: The procedure aims are same SHOULD BE: are the same Section 3.1: regardless whether SHOULD BE: regardless of whether indicated with SHOULD BE: indicated with a (two instances) extension, see Section 5.1. SHOULD BE: extension; see Section 5.1. from Home Agent SHOULD BE: from the Home Agent registration timeouts and specific SHOULD BE: registration timeouts, and specific Section 3.1.1 As noted, NEMO-supporting Home Agent SHOULD BE: As noted, a NEMO-supporting Home Agent Only change to this functionality SHOULD BE: The only change to this functionality including Route Optimization capability extension, Section 5.1, SHOULD BE: including a Route Optimization Capability extension (Section 5.1) MUST include Route Optimization Reply extension (Section 5.2) to indicate whether Route Optimization was accepted. SHOULD BE: MUST include a Route Optimization Reply extension (Section 5.2) to indicate that the Route Optimization Capability extension was understood. informs Mobile Router if NAT was SHOULD BE: informs the Mobile Router whether NAT was with according prefix(es) SHOULD BE: with corresponding prefix(es) routers in customer's SHOULD BE: routers in the customer's e.g. Default prefix (0.0.0.0/0) pointing towards Internet gateway for Internet connectivity, and possible extranets. SHOULD BE: e.g. a default prefix (0.0.0.0/0) pointing towards an Internet gateway for Internet connectivity or additional prefixes belonging to possible extranets. within specific realm SHOULD BE: within a specific realm share same SHOULD BE: share the same receiving registration reply SHOULD BE: receiving a registration reply as a host-prefixes to SHOULD BE: as host-prefixes into SHALL also be inserted to SHOULD BE: SHALL also be inserted into Section 3.1.2: from Home Agent SHOULD BE: from the Home Agent prefix advertisements, and in registration messages SHOULD BE: prefix advertisements and in registration messages direction, see Section 3.3.4 SHOULD BE: direction; see Section 3.3.4 in Care-of-address extension in registration reply. If the entry exists, SHOULD BE: in the Care-of-address extension of a registration reply. If set to true, from Route Optimization Cache as long as tunnel SHOULD BE: from the Route Optimization Cache as long as a tunnel using Return Routability procedure, they are calculated in-situ based on nonces and router key. SHOULD BE: using a Return Routability procedure, it is calculated in-situ based on nonces and a router key. Care-of nonce indexes If the KRm was established with Return SHOULD BE: Care-of nonce indices If the KRm was established with a Return (Put a newline and indent all of the descriptions in the remainder of this section) Section 3.2: Same principles SHOULD BE: The same principles Two messages SHOULD BE: two messages to Correspondent Router's Home Address, one via Home Agent using Mobile Router's Home Address, SHOULD BE: to the Correspondent Router's Home Address, one via the Home Agent using the Mobile Router's Home Address by Mobile IP protocol SHOULD BE: by the Mobile IP protocol mechanism, Return Routability procedure SHOULD BE: mechanism, the Return Routability procedure Assumption on traffic patterns SHOULD BE: The main assumption on traffic patterns where mobile router is acting as a CR. SHOULD BE: where a mobile router is acting as a CR. Section 3.2.1: Correspondent Router uses router key to verify that the keygen tokens sent by Mobile Router in registration request are the CR's own. SHOULD BE: A Correspondent Router uses its router key to verify that the keygen tokens sent by a peer Mobile Router in a registration request are= the CR's own. nonces, see SHOULD BE: nonces; see Section 3.2.2: The Mobile Router may use same nonces with all Mobile Routers. SHOULD BE: The Mobile Router may use the same nonces with all Correspondent Routers= . Section 3.2.3: whose lifetime have SHOULD BE: whose lifetimes have Nonce should be kept acceptable SHOULD BE: A nonce should remain valid Section 3.3: The Mobile Router learns Correspondent Router's Care-of address by a new extension, "Care-of Address", in registration reply. SHOULD BE: The Mobile Router learns the Correspondent Router's Care-of address by a new extension, "Care-of Address", in the registration reply= . Second issue is rising from security standpoint: In a registration SHOULD BE: The second issue is a security consideration: in a registration re-registration to Home Agent SHOULD BE: re-registration to the Home Agent Additional aspect is that Mobile Router MAY use different Care-of- Address for different Correspondent Routers SHOULD BE: An additional aspect is that a Mobile Router MAY use a different Care-of= - Address for different Correspondent Routers where network provides SHOULD BE: where the network provides Section 3.3.1: at any time; However a better SHOULD BE: at any time; however, a better and destination address exists in the network prefixes of Route Optimization Cache. SHOULD BE: and whose destination address falls within the network prefixes of the Route Optimization Cache. With small number SHOULD BE: With a small number Section 3.3.3: between Mobile Router and Correspondent Router SHOULD BE: between a Mobile Router and a Correspondent Router either Return Routability procedure SHOULD BE: either the Return Routability procedure from desired interface SHOULD BE: from the desired interface address of desired outgoing interface SHOULD BE: address of the desired outgoing interface The address MAY be same as the Care-of address used with Home Agent. SHOULD BE: The address MAY be the same as the Care-of address used with the Home Agent. MUST include Mobile-Correspondent Authentication extension SHOULD BE: MUST include a Mobile-Correspondent Authentication extension SHOULD include Mobile Network Request Extension SHOULD BE: SHOULD include a Mobile Network Request Extension The registration reply MUST include Mobile-Correspondent Authentication extension SHOULD BE: The Registration Reply MUST include a Mobile-Correspondent Authentication extension conditions apply, registration request SHOULD BE: conditions apply, the Registration Request to facilitate detecting SHOULD BE: to facilitate detection (see Section (Section 10) SHOULD BE: (see Section 10) in it's Route Optimization Cache SHOULD BE: in its Route Optimization Cache by incoming Mobile Router SHOULD BE: by the incoming Mobile Router arbitrary networks; However, since Home Agent SHOULD BE: arbitrary networks; however, since the Home Agent authorize Mobile Router's claim SHOULD BE: authorize the Mobile Router's claim registrations from without this check SHOULD BE: registrations without this check and Route Optimization Cache updated. SHOULD BE: and the Route Optimization Cache updated. The reply MUST include a list of eligible care-of-addresses for the tunnel in Section 5.4, with which the Mobile Router may establish a tunnel with. SHOULD BE: The reply MUST include a list of eligible care-of-addresses (see Section 5.4) with which the Mobile Router may establish a tunnel. Mobile-Correspondent Authentication extensionSection 5.3. SHOULD BE: Mobile-Correspondent Authentication extension (see Section 5.3). The Correspondent Router's routing table MUST be updated to include the Mobile Router's networks are reachable SHOULD BE: The Correspondent Router's routing table MUST be updated to indicate that the Mobile Router's networks are reachable but only only act on it SHOULD BE: but only act on it Section 3.3.4: firewall.A deviation from RFC 3519 [RFC3519] is that keepalives should be sent both from ends of the tunnel SHOULD BE: firewall. A deviation from RFC 3519 [RFC3519] is that keepalives should be sent from both ends of the tunnel sending it's own SHOULD BE: sending its own in second SHOULD BE: per second Section 3.3.6 join home link SHOULD BE: join its home link if it's Route Optimization Cache SHOULD BE: whether its Route Optimization Cache in the order of ten seconds SHOULD BE: on the order of ten seconds at it is SHOULD BE: it is have to also be acquired SHOULD BE: have also to be acquired Section 3.4: assumption is that at least SHOULD BE: assumption that at least registers; Receives SHOULD BE: registers and receives (3 instances) receives to traffic SHOULD BE: receives traffic From mccap@petoni.org Tue Feb 8 09:00:58 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7233D3A681D for ; Tue, 8 Feb 2011 09:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRiJHwiLKCwh for ; Tue, 8 Feb 2011 09:00:57 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 0E2693A6808 for ; Tue, 8 Feb 2011 09:00:40 -0800 (PST) Received: by wyf23 with SMTP id 23so6283549wyf.31 for ; Tue, 08 Feb 2011 09:00:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.133.130 with SMTP id f2mr15578467wbt.9.1297184447078; Tue, 08 Feb 2011 09:00:47 -0800 (PST) Received: by 10.227.147.74 with HTTP; Tue, 8 Feb 2011 09:00:46 -0800 (PST) X-Originating-IP: [64.53.131.166] Date: Tue, 8 Feb 2011 11:00:46 -0600 Message-ID: From: Pete McCann To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Mip4] Two final nits on gre-key X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:00:58 -0000 I went back and checked the latest changes to the gre-key draft. It now contains the following text: If the MN does not set both the 'G' bit and the 'D' bit (i.e., the mobile node is not using a co-located care-of address), and the local policy allows the FA to override the 'G' bit setting received from the MS, the FA MUST include the GRE-Key Extension as defined in this memo in the Registration Request that it propogates to the HA. I don't think this text quite says what was intended. It should say: If the MN does not set the 'G' bit and does not set the 'D' bit (i.e., the mobile node does not request GRE tunneling but is not using a co-located care-of address), and the local policy of the FA requires it to override the 'G' bit setting received from the MN, the FA MUST include the GRE-Key Extension as defined in this document in the Registration Request that it propagates to the HA. The problem is, !(A & B) equals !A | !B, but what you wanted was !A & !B. Also, this text in Section 5 should be slightly changed: The GRE Key extension MAY be included in Registration Requests [RFC3344]. It should say: The GRE Key extension MAY be included in Registration Requests or Registration Replies [RFC3344]. When we get a version that fixes these two nits, I think we are ready to send the publication request, unless there are any other objections. -Pete From kleung@cisco.com Tue Feb 8 09:37:20 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68533A67AD for ; Tue, 8 Feb 2011 09:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsrcMz86h53C for ; Tue, 8 Feb 2011 09:37:19 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D2F893A67AB for ; Tue, 8 Feb 2011 09:37:19 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoBAEwOUU2rR7H+/2dsb2JhbACWV45cc6AomzWFWgSEe4oj Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Feb 2011 17:37:27 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18HbRm6019892; Tue, 8 Feb 2011 17:37:27 GMT 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.4675); Tue, 8 Feb 2011 09:37:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Feb 2011 09:37:25 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520E0A77D0@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Two final nits on gre-key Thread-Index: AcvHseDwQ1aiIIjYRwaaU/fwtLED7QABDQ/w References: From: "Kent Leung (kleung)" To: "Pete McCann" , X-OriginalArrivalTime: 08 Feb 2011 17:37:27.0074 (UTC) FILETIME=[DA4E7020:01CBC7B6] Subject: Re: [Mip4] Two final nits on gre-key X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:37:21 -0000 Hi Pete. Comments below. -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Pete McCann Sent: Tuesday, February 08, 2011 9:01 AM To: mip4@ietf.org Subject: [Mip4] Two final nits on gre-key I went back and checked the latest changes to the gre-key draft. It now contains the following text: If the MN does not set both the 'G' bit and the 'D' bit (i.e., the mobile node is not using a co-located care-of address), and the local policy allows the FA to override the 'G' bit setting received from the MS, the FA MUST include the GRE-Key Extension as defined in this memo in the Registration Request that it propogates to the HA. I don't think this text quite says what was intended. It should say: If the MN does not set the 'G' bit and does not set the 'D' bit (i.e., the mobile node does not request GRE tunneling but is not using a co-located care-of address), and the local policy of the FA requires it to override the 'G' bit setting received from the MN, the FA MUST include the GRE-Key Extension as defined in this document in the Registration Request that it propagates to the HA. The problem is, !(A & B) equals !A | !B, but what you wanted was !A & !B. [Kent Leung (kleung)] Thanks for catching the logic error. Agree with the text, only exception is ".. mobile node does not request GRE tunneling and is not using a co-located care-of address". Basically, s/but/and/. Also, this text in Section 5 should be slightly changed: The GRE Key extension MAY be included in Registration Requests [RFC3344]. It should say: The GRE Key extension MAY be included in Registration Requests or Registration Replies [RFC3344]. [Kent Leung (kleung)] Yes. When we get a version that fixes these two nits, I think we are ready to send the publication request, unless there are any other objections. [Kent Leung (kleung)] OK, will do. Kent -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mccap@petoni.org Tue Feb 8 09:58:46 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6A83A672E for ; Tue, 8 Feb 2011 09:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PIVnAA+1C+S for ; Tue, 8 Feb 2011 09:58:45 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id A6A1B3A66B4 for ; Tue, 8 Feb 2011 09:58:44 -0800 (PST) Received: by eyd10 with SMTP id 10so3420976eyd.31 for ; Tue, 08 Feb 2011 09:58:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.36.220 with SMTP id u28mr304114fad.11.1297187929769; Tue, 08 Feb 2011 09:58:49 -0800 (PST) Received: by 10.223.151.11 with HTTP; Tue, 8 Feb 2011 09:58:49 -0800 (PST) X-Originating-IP: [64.53.131.166] In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520E0A77D0@xmb-sjc-235.amer.cisco.com> References: <2979E38DD6FC6544B789C8DAD7BAFC520E0A77D0@xmb-sjc-235.amer.cisco.com> Date: Tue, 8 Feb 2011 11:58:49 -0600 Message-ID: From: Pete McCann To: "Kent Leung (kleung)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org Subject: Re: [Mip4] Two final nits on gre-key X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:58:46 -0000 Hi, Kent, I'm fine with changing but to and. I waffled between the two myself. When you submit, I'll do the writeup. -Pete On Tue, Feb 8, 2011 at 11:37 AM, Kent Leung (kleung) wro= te: > Hi Pete. =A0Comments below. > > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of > Pete McCann > Sent: Tuesday, February 08, 2011 9:01 AM > To: mip4@ietf.org > Subject: [Mip4] Two final nits on gre-key > > I went back and checked the latest changes to the gre-key draft. > It now contains the following text: > > =A0 If the MN does not set both the 'G' bit and the 'D' bit (i.e., the > =A0 mobile node is not using a co-located care-of address), and the local > =A0 policy allows the FA to override the 'G' bit setting received from > =A0 the MS, the FA MUST include the GRE-Key Extension as defined in this > =A0 memo in the Registration Request that it propogates to the HA. > > I don't think this text quite says what was intended. =A0It should say: > > =A0 If the MN does not set the 'G' bit and does not set the 'D' bit > (i.e., > =A0 the mobile node does not request GRE tunneling but is not using > =A0 a co-located care-of address), and the local policy of the FA > requires > =A0 it to override the 'G' bit setting received from the MN, the FA MUST > =A0 include the GRE-Key Extension as defined in this document in the > =A0 Registration Request that it propagates to the HA. > > The problem is, !(A & B) equals !A | !B, but what you wanted was > !A & !B. > [Kent Leung (kleung)] Thanks for catching the logic error. =A0Agree with > the text, only exception is ".. mobile node does not request GRE > tunneling and is not using a co-located care-of address". =A0Basically, > s/but/and/. > > Also, this text in Section 5 should be slightly changed: > > =A0 The GRE Key extension MAY be included in Registration Requests > =A0 [RFC3344]. > > It should say: > > =A0 The GRE Key extension MAY be included in Registration Requests > =A0 or Registration Replies [RFC3344]. > [Kent Leung (kleung)] Yes. > > > When we get a version that fixes these two nits, I think we are ready > to send the publication request, unless there are any other objections. > [Kent Leung (kleung)] OK, will do. > > Kent > > -Pete > -- > Mip4 mailing list: Mip4@ietf.org > =A0 =A0Web interface: https://www.ietf.org/mailman/listinfo/mip4 > =A0 =A0 Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > From antti.makela@aalto.fi Wed Feb 9 02:58:26 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEFD03A6980 for ; Wed, 9 Feb 2011 02:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjelh+ao0uff for ; Wed, 9 Feb 2011 02:58:24 -0800 (PST) Received: from mx05.aalto.fi (mx05.aalto.fi [130.233.222.104]) by core3.amsl.com (Postfix) with ESMTP id 41C6A3A697E for ; Wed, 9 Feb 2011 02:58:23 -0800 (PST) Received: from mx05.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2DF3C80824; Wed, 9 Feb 2011 12:58:32 +0200 (EET) Received: from EXHUB01.org.aalto.fi (ex-hub01.org.aalto.fi [130.233.222.118]) by mx05.aalto.fi (Postfix) with ESMTP id 2127480815; Wed, 9 Feb 2011 12:58:31 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB01.org.aalto.fi ([130.233.222.118]) with mapi; Wed, 9 Feb 2011 12:58:15 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: Pete McCann , "mip4@ietf.org" Thread-Topic: Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLx6sEVyNvlxhxikqx2ukgnn8CzZP3zxvOgAEx0z8= Date: Wed, 9 Feb 2011 10:57:24 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com>, <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> In-Reply-To: <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 10:58:26 -0000 Hello,=0A= =0A= I've now come up with -04 that as of this time has the following modifica= tions. I'm waiting Jouni to comment on the realm compression portion. Apart= from that, would these changes be satisfactory?=0A= =0A= Thanks.=0A= =0A= --=0A= - Antti M=E4kel=E4 | Researcher -=0A= - Department of communications and networking -=0A= - Aalto University -=0A= =0A= >Some issues in Section 3.2.3:=0A= > The destination address is set to=0A= > Correspondent Router's HoA.=0A= >This is only true of the HoTI and CoTI messages, right? The text seems=0A= >to say that all 4 messages have their destination address set=0A= >to the CR's HoA.=0A= =0A= This now reads:=0A= =0A= The destination address of HoTI and CoTI messages is set to Correspondent R= outer's HoA with the sources being MR's home and care-of-address, respectiv= ely.=0A= =0A= > each containing a 64-bit random=0A= >SHOULD BE:=0A= >each containing a (different) 64-bit random=0A= =0A= Fixed.=0A= =0A= >It seems that 3.2.3 has a lot of text describing the route=0A= >optimization procedure which would be better moved into=0A= >its own sub-section. Suggest renaming 3.2.3 as "Route=0A= >Optimization Overview" and putting "Updating Router keys and Nonces"=0A= >in its own Section 3.2.4.=0A= =0A= I'm assuming you mean "Return Routability Overview". There's plenty of ov= erviews for RO as a whole :)=0A= =0A= >In Section 3.2.3, try to be a bit more careful about describing=0A= >the IP source and destination addresses of each message.=0A= >I assume that the HoTI is sent with a source address equal=0A= >to the HoA of the MR, and the CoTI is sent with a source address=0A= >equal to the CoA of the MR. Both are sent to the HoA of the CR.=0A= >The first must be reverse tunneled because it doesn't have a topologically= =0A= >correct source address, but the CoTI does not need to be so tunneled=0A= >as long as the CR's HoA is globally routable. The response HoT and CoT=0A= >messages are both sent from the CR's HoA and destined to the HoA and=0A= >CoA of the MR, respectively. They must both be reverse tunneled=0A= >to the HA. Is this right?=0A= >=0A= >More text is needed on how the keygen tokens are derived from the nonces,= =0A= >Kcrs, and CoAs. I know you may be repeating some of the MIP6 spec but it = would=0A= >be good for this spec to stand on its own.=0A= =0A= I've moved bulk of the original text to one level above, near the start o= f Section 3.2. =0A= =0A= Anyway, regarding copypasting MIP6 spec - I think I already have covered.= =0A= =0A= - Reasons for RR procedure=0A= - Message types=0A= - Message contents (Cookies, tokens, nonce indices)=0A= - Cookie: 64-bit random number=0A= - Nonce: Random number with a lifetime, indexed=0A= =0A= - Tokens: This wasn't explicitly specified how it's generated from cookie= + nonce. I've added this information. I've added the following bit of text= :=0A= =0A= ---=0A= Correspondent Router responds to HoTI and CoTI messages by=0A= constructing HoT and CoT messages, respectively, as replies. The HoT=0A= message contains home init cookie, current home nonce index and home=0A= keygen token. The CoT message contains care-of init cookie, current=0A= care-of nonce index and care-of keygen token.=0A= =0A= The Home Keygen token is constructed as follows:=0A= =0A= Home keygen token =3D First (64, HMAC_MD5 (Kcr, (home address | nonce |= =0A= 0)))=0A= =0A= The Care-of Keygen token is constructed as follows:=0A= =0A= Care-of keygen token =3D First (64, HMAC_MD5 (Kcr, (Care-of address |=0A= nonce | 1)))=0A= =0A= Note that the Care-of address in this case is the source address of=0A= the received CoTI message packet. The address may have changed in-=0A= transit due to network address translation. This does not affect=0A= registration process; subsequent registration requests are expected=0A= to arrive from the same translated address.=0A= ---=0A= =0A= >Section 3.3.3:=0A= > The registration request MUST be set to the Home=0A= > Address.=0A= >SHOULD BE:=0A= > The registration request MUST be sent to (have a destination=0A= > address of) the Home=0A= > Address of the Correspondent Router.=0A= =0A= Fixed.=0A= =0A= >Section 3.4:=0A= >This section talks about triggering route optimization upon=0A= >reception of a packet from a known network; however, 3.3.1=0A= >focused on the trigger being the transmission of a packet.=0A= >Which is the preferred scenario?=0A= =0A= This has now been fixed, and reads as follows. Sections 3.3.1 and the exa= mple diagrams were already as they should.=0A= =0A= If a node in mobile network C is about to send traffic to mobile network A,= the route optimization is straightforward; MR C already has network A in i= ts Route Optimization Cache. Thus, packet transmission triggers Route Optim= ization towards MR A. When MR C registers to MR A (after Return Routability= procedure is completed), MR A does not have information on mobile network = C; Thus it will perform a re-registration to the Home Agent on-demand. This= allows MR A to verify that MR C is indeed managing network C.=0A= =0A= If a node in mobile network B sends traffic to mobile network C, MR B has n= o information on network C. No route optimization is triggered. However, wh= en the node in network C replies and the reply reaches MR C, route optimiza= tion happens as above. Further examples of signaling are in (reference).=0A= =0A= >Section 4:=0A= >The scheme for realm compression looks a bit complicated and=0A= >I don't completely understand the reason for defining a new=0A= >scheme that is so different from the one in RFC 1035. You say=0A= >it achieves better compression but I think this is only true for=0A= >odd cases where you want to compress the middle labels of=0A= >a realm name that happen to match an earlier middle label but=0A= >where the suffix doesn't match. I think it's more likely that=0A= >MRs homed on the same HA will share the same suffixes.=0A= >=0A= >Also, DNS labels cannot be longer than 63 characters so you=0A= >might as well use the top 2 bits of the label length field as=0A= >DNS does (unless you think realm names have different rules?).=0A= =0A= Jouni?=0A= =0A= >Section 5.5:=0A= >I thought that this Route Optimization Prefix Advertisement=0A= >extension was what provided each correspondent router with=0A= >the binding between MR HoA and mobile prefixes managed=0A= >by that HoA. However, the rules given don't allow for the=0A= >occurrence of an MR HoA and a prefix in the same listing.=0A= >How exactly is the binding supposed to be achieved?=0A= =0A= Already explained - there can be 1..n information elements that can have = both information. Only the first occurrence must have M=3D1 since you can't= have prefixes without a MR.=0A= =0A= >Sections 5.5 - 5.9:=0A= >You should add text describing how the IP and UDP fields=0A= >are set in these new messages.=0A= =0A= Are you sure this is needed in 5.5? It's an extension to the reply from H= A.=0A= =0A= In 5.6 - 5.9, added the following text for 5.6:=0A= =0A= This message is sent from Mobile Router to Correspondent Router when perfor= ming Return Routability procedure. The source and destination IP addresses = are set to MR's Home Address and CR's Home Address, respectively. The UDP s= ource port MAY be randomly chosen. The UDP destination port is 434.=0A= =0A= 5.7:=0A= =0A= This message is sent from Mobile Router to Correspondent Router when perfor= ming Return Routability procedure. The source and destination IP addresses = are set to MR's Care-of-Address and CR's Home Address, respectively. The UD= P source port MAY be randomly chosen. The UDP destination port is 434.=0A= =0A= and this for 5.8 and 5.9 (in 5.9 using "Care-of-Test Init" instead of "Home= -Test init"):=0A= =0A= This message is sent from Correspondent Router to Mobile Router when perfor= ming Return Routability procedure as a reply to Home-Test Init message. The= source and destination IP addresses, as well as UDP ports, are reversed fr= om the Home-Test Init message the message is constructed for. As such, the = UDP source port is always 434.=0A= =0A= =0A= >Numerous editorial nits:=0A= =0A= >The last sentence of the Abstract is a bit confusing:=0A= > The=0A= > functionality adds possibility to discover eligible peer nodes based=0A= > on information received from Home Agent, Network Prefixes they=0A= > represent, and how to establish direct tunnel between such nodes.=0A= >Did you mean to say:=0A= > The=0A= > functionality adds the possibility to discover: eligible peer nodes bas= ed=0A= > on information received from Home Agent; Network Prefixes they=0A= > represent; and, how to establish a direct tunnel between such nodes.=0A= >=0A= =0A= Ok, for me, I see no difference in the meaning of these sentences, but I = agree that semicolons make it a bit easier to understand.=0A= =0A= As for the rest, I've incorporated most of them. I'll mention ones I have= question about. A lot of my cross-references were apparently broken in the= text version - I've done my editing in XXE and didn't check the text versi= on thoroughly.=0A= =0A= > beyond the need of a single, coordinating Home=0A= > Agent.=0A= >Did you mean:=0A= > removing the need for a single, coordinating Home=0A= > Agent.=0A= =0A= No - I mean that currently the spec does not cover MR's connected to diff= erent Home Agents. However, it's not limiting that in any way, either - if = the mobile nodes can learn of their peers via some other mechanism (DHT, DN= S, whatnot) they don't need to use information from Home Agent for that but= can still use other mechanisms in this spec - for single Mobile Nodes that= is enough. For networks - well, if the MRs can in addition somehow verify = an arbitrary MR's claim that they are representing a specific network, then= they also have RO for networks.=0A= =0A= So hence, "beyond", not "removing".=0A= =0A= Maybe this form would be the best:=0A= =0A= "such as not being tied to a single Home Agent".=0A= =0A= 3.1.2:=0A= =0A= > in Care-of-address extension in registration reply.=0A= > If the entry exists,=0A= >SHOULD BE:=0A= > in the Care-of-address extension of a registration reply.=0A= > If set to true,=0A= =0A= also changed this to "care-of-addresses" since the extension supports mul= tiple CoA's.=0A= =0A= =0A= > Care-of nonce indexes If the KRm was established with Return=0A= >SHOULD BE:=0A= > Care-of nonce indices=0A= > If the KRm was established with a Return=0A= >(Put a newline and indent all of the descriptions in the remainder=0A= >of this section)=0A= =0A= Also fixed Home nonce indices.= From jouni.nospam@gmail.com Wed Feb 9 03:51:35 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A93E3A6998 for ; Wed, 9 Feb 2011 03:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fft5TriMWZNi for ; Wed, 9 Feb 2011 03:51:34 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 731B23A6945 for ; Wed, 9 Feb 2011 03:51:34 -0800 (PST) Received: by bwz12 with SMTP id 12so928823bwz.31 for ; Wed, 09 Feb 2011 03:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=VQKu+jsZqWjDrIBVb052ucEf9NCezPHdpLW2qyWdlL0=; b=vt7CbSdZjsMXpc009nXzB24JwuXl7ljCdbunns9dxfydywnWL/7GXmEqSrlZvZa8bR jxhvnzkpItPdpl5NY1YQCRJsCEsmanpgjex1+KSxr5iyOyngtP4hhYnkmmzfYqLLezPW z4S4ZVedyWqP210zboLd+OzL/nme/FiBscYSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=TyAv2iqfaS/GAaQkOjMMw+8miX8RjHut2Acz9hjLEGSvqccowStPsiD2eCaQLaf8AN XQJgOFf756mN1lnB4OvVcJmrhM+rBwjsDQXODoSMtwQGRnc82j7souCNvb6fJVE7QPFQ 6IlK36SMgbdo/N3tNUYb8Qmr9f+wnZbZRNqdw= Received: by 10.204.138.130 with SMTP id a2mr7127127bku.211.1297252302998; Wed, 09 Feb 2011 03:51:42 -0800 (PST) Received: from a88-112-143-79.elisa-laajakaista.fi (a88-112-143-79.elisa-laajakaista.fi [88.112.143.79]) by mx.google.com with ESMTPS id v1sm153776bkt.5.2011.02.09.03.51.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 03:51:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 9 Feb 2011 13:51:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8EDC7716-4653-4295-B706-7DC961A2599B@gmail.com> References: To: Pete McCann X-Mailer: Apple Mail (2.1078) Cc: draft-ietf-mip4-nemo-haaro.all@tools.ietf.org, mip4@ietf.org Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 11:51:35 -0000 Hi Pete, Thanks for a thorough review. I cut the excess away to get to the realm = part.. On Feb 8, 2011, at 6:12 PM, Pete McCann wrote: > Section 4: > The scheme for realm compression looks a bit complicated and Actually it was a breeze to implement, since it is just adding strings = into a data structure and later getting an index to a searched string = from there. > I don't completely understand the reason for defining a new > scheme that is so different from the one in RFC 1035. You say > it achieves better compression but I think this is only true for > odd cases where you want to compress the middle labels of > a realm name that happen to match an earlier middle label but > where the suffix doesn't match. I think it's more likely that > MRs homed on the same HA will share the same suffixes. Could be. But still not a reason why we could not beef up something that = was done -87 ? >=20 > Also, DNS labels cannot be longer than 63 characters so you > might as well use the top 2 bits of the label length field as > DNS does (unless you think realm names have different rules?). >=20 The algorithm handles strings as a "blob" up to 127 octets. That = property is used e.g. when the "longest non-matching string" actually = spans multiple labels of a realm and then pushed into the dictionary. So = essentially we can assign an index to a multi-label realms (or parts of = it) as long as the total length is < 128 octets. - Jouni= From mccap@petoni.org Wed Feb 9 07:26:42 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE6E3A67A7 for ; Wed, 9 Feb 2011 07:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW40P7wC1E9J for ; Wed, 9 Feb 2011 07:26:41 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 44F513A67A6 for ; Wed, 9 Feb 2011 07:26:40 -0800 (PST) Received: by wyf23 with SMTP id 23so304009wyf.31 for ; Wed, 09 Feb 2011 07:26:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.156.207 with SMTP id y15mr3193087wbw.38.1297265209970; Wed, 09 Feb 2011 07:26:49 -0800 (PST) Received: by 10.227.147.74 with HTTP; Wed, 9 Feb 2011 07:26:49 -0800 (PST) X-Originating-IP: [64.53.131.166] In-Reply-To: <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> Date: Wed, 9 Feb 2011 09:26:49 -0600 Message-ID: From: Pete McCann To: =?ISO-8859-1?B?TeRrZWzkIEFudHRp?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 15:26:42 -0000 Hi, Antti, Thanks for the quick turnaround. A couple of comments/questions below: On Wed, Feb 9, 2011 at 4:57 AM, M=E4kel=E4 Antti wr= ote: >>It seems that 3.2.3 has a lot of text describing the route >>optimization procedure which would be better moved into >>its own sub-section. =A0Suggest renaming 3.2.3 as "Route >>Optimization Overview" and putting "Updating Router keys and Nonces" >>in its own Section 3.2.4. > > =A0I'm assuming you mean "Return Routability Overview". There's plenty of= overviews for RO as a whole :) Yes, "Return Routability Overview" would be fine. > =A0 The Home Keygen token is constructed as follows: Was there a discussion in MIP6 on whether to use MD5 or SHA1 for this? Just curious. We probably don't want to depart too much from the MIP6 spec but MD5 is pretty old and broken at this point. >>Section 5.5: >>I thought that this Route Optimization Prefix Advertisement >>extension was what provided each correspondent router with >>the binding between MR HoA and mobile prefixes managed >>by that HoA. =A0However, the rules given don't allow for the >>occurrence of an MR HoA and a prefix in the same listing. >>How exactly is the binding supposed to be achieved? > > =A0Already explained - there can be 1..n information elements that can ha= ve both information. Only the first occurrence must have M=3D1 since you ca= n't have prefixes without a MR. Ok, maybe put some explanation in the text that the list is a sequence of MR HoAs each followed by a list of prefixes owned by that MR. >>Sections 5.5 - 5.9: >>You should add text describing how the IP and UDP fields >>are set in these new messages. > > =A0Are you sure this is needed in 5.5? It's an extension to the reply fro= m HA. Right, I meant 5.6. Your text looks fine. >> =A0 beyond the need of a single, coordinating Home >> =A0 Agent. >>Did you mean: >> =A0 removing the need for a single, coordinating Home >> =A0 Agent. > > =A0No - I mean that currently the spec does not cover MR's connected to d= ifferent Home Agents. However, it's not limiting that in any way, either - = if the mobile nodes can learn of their peers via some other mechanism (DHT,= DNS, whatnot) they don't need to use information from Home Agent for that = but can still use other mechanisms in this spec - for single Mobile Nodes t= hat is enough. For networks - well, if the MRs can in addition somehow veri= fy an arbitrary MR's claim that they are representing a specific network, t= hen they also have RO for networks. > > =A0So hence, "beyond", not "removing". > > =A0Maybe this form would be the best: > > =A0"such as not being tied to a single Home Agent". Maybe say, "such as not requiring all MRs to be homed on the same Home Agen= t." Other changes looks good. Let's wrap up the discussion on compression with Jouni and proceed from there. -Pete From mccap@petoni.org Wed Feb 9 07:49:19 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE5A3A6767 for ; Wed, 9 Feb 2011 07:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKFiRYkp2gqf for ; Wed, 9 Feb 2011 07:49:18 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 576CC3A659B for ; Wed, 9 Feb 2011 07:49:18 -0800 (PST) Received: by wyf23 with SMTP id 23so329419wyf.31 for ; Wed, 09 Feb 2011 07:49:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.156.207 with SMTP id y15mr3225265wbw.38.1297266567000; Wed, 09 Feb 2011 07:49:27 -0800 (PST) Received: by 10.227.147.74 with HTTP; Wed, 9 Feb 2011 07:49:26 -0800 (PST) X-Originating-IP: [64.53.131.166] In-Reply-To: <8EDC7716-4653-4295-B706-7DC961A2599B@gmail.com> References: <8EDC7716-4653-4295-B706-7DC961A2599B@gmail.com> Date: Wed, 9 Feb 2011 09:49:26 -0600 Message-ID: From: Pete McCann To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-mip4-nemo-haaro.all@tools.ietf.org, mip4@ietf.org Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 15:49:19 -0000 Hi, Jouni, On Wed, Feb 9, 2011 at 5:51 AM, jouni korhonen wro= te: > On Feb 8, 2011, at 6:12 PM, Pete McCann wrote: > >> Section 4: >> The scheme for realm compression looks a bit complicated and > > Actually it was a breeze to implement, since it is just adding strings in= to a data structure and later getting an index to a searched string from th= ere. > >> I don't completely understand the reason for defining a new >> scheme that is so different from the one in RFC 1035. =A0You say >> it achieves better compression but I think this is only true for >> odd cases where you want to compress the middle labels of >> a realm name that happen to match an earlier middle label but >> where the suffix doesn't match. =A0I think it's more likely that >> MRs homed on the same HA will share the same suffixes. > > Could be. But still not a reason why we could not beef up something that = was done -87 ? I just worry about the draft running into problems with reviewers because of the extra complexity; in some ways, compression is really orthogonal to the purpose for which the draft was written. I understand that this is a case where the extension might contain lots of realms and therefore compression is a good idea for scalability, but it isn't really required for correct operation. Re-using something already specified and implemented in many places seems like a safer alternative. >> >> Also, DNS labels cannot be longer than 63 characters so you >> might as well use the top 2 bits of the label length field as >> DNS does (unless you think realm names have different rules?). >> > > The algorithm handles strings as a "blob" up to 127 octets. That property= is used e.g. when the "longest non-matching string" actually spans multipl= e labels of a realm and then pushed into the dictionary. So essentially we = can assign an index to a multi-label realms (or parts of it) as long as the= total length is < 128 octets. >From the text it looks like you are encoding one label at a time, and using the length field in the same way as RFC 1035. I don't think there is any constraint on the length of the strings in the dictionar= y. Of course, if you eliminated one bit from the index encoding you would be limited to 63 dictionary entries instead of 127. (it also seems to me inefficient and inelegant to empty the dictionary when it overflows - why not have an LRU replacement strategy?) Anyway, if we had an extra bit in the label length field we could use exten= ded label types from EDNS0, and maybe define a new extended label type to improve on the compression of RFC1035 by allowing for offsets greater than 63. Just a thought. I know you've already implemented your scheme and would like to stick with it. Let's see if anyone else has comments on the right direction here. -Pete From antti.makela@aalto.fi Wed Feb 9 08:04:09 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602403A67A7 for ; Wed, 9 Feb 2011 08:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amXwTPXmEUIH for ; Wed, 9 Feb 2011 08:04:08 -0800 (PST) Received: from mx06.aalto.fi (mx06.aalto.fi [130.233.222.105]) by core3.amsl.com (Postfix) with ESMTP id 5BD253A659A for ; Wed, 9 Feb 2011 08:04:08 -0800 (PST) Received: from mx06.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3D5D680884; Wed, 9 Feb 2011 18:04:17 +0200 (EET) Received: from EXHUB04.org.aalto.fi (ex-hub04.org.aalto.fi [130.233.222.117]) by mx06.aalto.fi (Postfix) with ESMTP id 1EA5680883; Wed, 9 Feb 2011 18:04:17 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB04.org.aalto.fi ([130.233.222.117]) with mapi; Wed, 9 Feb 2011 18:04:17 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: Pete McCann Thread-Topic: Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLx6sEVyNvlxhxikqx2ukgnn8CzZP3zxvOgAEx0z+AACm+gIAAJky4 Date: Wed, 9 Feb 2011 16:04:16 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi>, In-Reply-To: Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:04:09 -0000 Hi,=0A= =0A= >> The Home Keygen token is constructed as follows:=0A= >=0A= >Was there a discussion in MIP6 on whether to use MD5 or SHA1=0A= >for this? Just curious. We probably don't want to depart too much=0A= >from the MIP6 spec but MD5 is pretty old and broken at this point.=0A= =0A= Well, we went with MD5 since it's the standard in MIP4 - and you can reus= e existing HMAC_MD5 functions when extending current implementations. Of co= urse, best thing would of course be a free selection of hash algorithms, bu= t none of the existing MIP4 structures really lend much to it at least as p= art of the protocol itself. =0A= =0A= >> Already explained - there can be 1..n information elements that can hav= e both information. Only the first occurrence must have M=3D1 since you can= 't have prefixes without a MR.=0A= >Ok, maybe put some explanation in the text that the list is=0A= >a sequence of MR HoAs each followed by a list of prefixes=0A= >owned by that MR.=0A= =0A= Ok - I've added a clarification before the figure:=0A= =0A= "The extension contains a sequence of information structures. An informatio= n structure may consist of either an MR HoA or a network prefix. Any networ= k prefixes following an MR HoA are owned by that MR. An MR HoA MUST be firs= t in sequence, since you cannot have prefixes without an MR."=0A= =0A= >> "such as not being tied to a single Home Agent".=0A= >Maybe say, "such as not requiring all MRs to be homed on the same Home Age= nt."=0A= =0A= Done. =0A= =0A= >Other changes looks good. Let's wrap up the discussion on compression wit= h=0A= >Jouni and proceed from there.=0A= =0A= Great.=0A= =0A= - Antti= From jouni.nospam@gmail.com Wed Feb 9 08:28:27 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9382E3A657C for ; Wed, 9 Feb 2011 08:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5yC7dkLiy+p for ; Wed, 9 Feb 2011 08:28:26 -0800 (PST) Received: from vs14.mail.saunalahti.fi (vs14.mail.saunalahti.fi [195.197.172.102]) by core3.amsl.com (Postfix) with ESMTP id 431853A63EC for ; Wed, 9 Feb 2011 08:28:26 -0800 (PST) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs14.mail.saunalahti.fi (Postfix) with SMTP id 2B095A604A; Wed, 9 Feb 2011 18:28:35 +0200 (EET) Received: from vs14.mail.saunalahti.fi ([127.0.0.1]) by vs14.mail.saunalahti.fi ([195.197.172.102]) with SMTP (gateway) id A03A1628E46; Wed, 09 Feb 2011 18:28:35 +0200 Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs14.mail.saunalahti.fi (Postfix) with ESMTP id 15246A604A; Wed, 9 Feb 2011 18:28:35 +0200 (EET) Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id B9926151755; Wed, 9 Feb 2011 18:28:31 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Wed, 9 Feb 2011 18:28:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5EB93260-2438-422F-9087-11BE1189FCFE@gmail.com> References: <8EDC7716-4653-4295-B706-7DC961A2599B@gmail.com> To: Pete McCann X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Cc: draft-ietf-mip4-nemo-haaro.all@tools.ietf.org, mip4@ietf.org Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:28:27 -0000 Hi Pete, On Feb 9, 2011, at 5:49 PM, Pete McCann wrote: > Hi, Jouni, >=20 > On Wed, Feb 9, 2011 at 5:51 AM, jouni korhonen = wrote: >> On Feb 8, 2011, at 6:12 PM, Pete McCann wrote: >>=20 >>> Section 4: >>> The scheme for realm compression looks a bit complicated and >>=20 >> Actually it was a breeze to implement, since it is just adding = strings into a data structure and later getting an index to a searched = string from there. >>=20 >>> I don't completely understand the reason for defining a new >>> scheme that is so different from the one in RFC 1035. You say >>> it achieves better compression but I think this is only true for >>> odd cases where you want to compress the middle labels of >>> a realm name that happen to match an earlier middle label but >>> where the suffix doesn't match. I think it's more likely that >>> MRs homed on the same HA will share the same suffixes. >>=20 >> Could be. But still not a reason why we could not beef up something = that was done -87 ? >=20 > I just worry about the draft running into problems with reviewers > because of the extra complexity; in some ways, compression is > really orthogonal to the purpose for which the draft was written. > I understand that this is a case where the extension might contain > lots of realms and therefore compression is a good idea for = scalability, > but it isn't really required for correct operation. Re-using = something > already specified and implemented in many places seems like a > safer alternative. Well.. at the beginning we got some much concerns from others regarding = the possible packet size growth. >=20 >>>=20 >>> Also, DNS labels cannot be longer than 63 characters so you >>> might as well use the top 2 bits of the label length field as >>> DNS does (unless you think realm names have different rules?). >>>=20 >>=20 >> The algorithm handles strings as a "blob" up to 127 octets. That = property is used e.g. when the "longest non-matching string" actually = spans multiple labels of a realm and then pushed into the dictionary. So = essentially we can assign an index to a multi-label realms (or parts of = it) as long as the total length is < 128 octets. >=20 > =46rom the text it looks like you are encoding one label at a time, =46rom 4.2.1 .. dictionary based algorithm, which is designed to compress arbitrary length text strings. In this scheme, an entire realm, a single label or a list of labels may be replaced with an index to a previous occurrence of the same string stored in the dictionary. The realm .. dictionary. The realms are compressed label by label or as a list of labels. The dictionary can hold maximum 128 strings. Thus, when > and using the length field in the same way as RFC 1035. I don't > think there is any constraint on the length of the strings in the = dictionary. > Of course, if you eliminated one bit from the index encoding you would > be limited to 63 dictionary entries instead of 127. (it also seems to = me > inefficient and inelegant to empty the dictionary when it overflows - = why > not have an LRU replacement strategy?) Because I was lazy to be honest ;) Such addition would be easy to do, = though. And we probably should add LRU there. >=20 > Anyway, if we had an extra bit in the label length field we could use = extended > label types from EDNS0, and maybe define a new extended label type to > improve on the compression of RFC1035 by allowing for offsets greater > than 63. Realms are not necessarily something that are put into DNS. RFC4282 does = not have such requirements. However, in certain cases, like with = RFC3588, realms are explicitly said to be piggybacked on DNS. >=20 > Just a thought. I know you've already implemented your scheme and = would > like to stick with it. Let's see if anyone else has comments on the = right > direction here. Ok. - JOuni >=20 > -Pete From mccap@petoni.org Wed Feb 9 09:54:01 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328553A67BD for ; Wed, 9 Feb 2011 09:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLsRSGc3t4DG for ; Wed, 9 Feb 2011 09:54:00 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3B41B3A67A5 for ; Wed, 9 Feb 2011 09:54:00 -0800 (PST) Received: by wyf23 with SMTP id 23so465207wyf.31 for ; Wed, 09 Feb 2011 09:54:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.133.194 with SMTP id g2mr2889309wbt.154.1297274049647; Wed, 09 Feb 2011 09:54:09 -0800 (PST) Received: by 10.227.147.74 with HTTP; Wed, 9 Feb 2011 09:54:08 -0800 (PST) X-Originating-IP: [64.53.131.166] In-Reply-To: <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> Date: Wed, 9 Feb 2011 11:54:08 -0600 Message-ID: From: Pete McCann To: =?ISO-8859-1?B?TeRrZWzkIEFudHRp?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:54:01 -0000 Hi, Antti, On Wed, Feb 9, 2011 at 10:04 AM, M=E4kel=E4 Antti w= rote: > Hi, > >>> =A0 The Home Keygen token is constructed as follows: >> >>Was there a discussion in MIP6 on whether to use MD5 or SHA1 >>for this? =A0Just curious. =A0We probably don't want to depart too much >>from the MIP6 spec but MD5 is pretty old and broken at this point. > > =A0Well, we went with MD5 since it's the standard in MIP4 - and you can r= euse existing HMAC_MD5 functions when extending current implementations. Of= course, best thing would of course be a free selection of hash algorithms,= but none of the existing MIP4 structures really lend much to it at least a= s part of the protocol itself. I think we should go with whatever was used for MIP6. (was that SHA-1?) I don't think it matters too much that we stick with MD5. Any modern crypt= o library will have HMAC_SHA1 as well. This is new functionality so backward= s compatibility isn't a concern. Other edits look good. -Pete From antti.makela@aalto.fi Wed Feb 9 10:20:57 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D843A67BD for ; Wed, 9 Feb 2011 10:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-gzliBrYLLK for ; Wed, 9 Feb 2011 10:20:56 -0800 (PST) Received: from mx03.aalto.fi (mx03.aalto.fi [130.233.222.102]) by core3.amsl.com (Postfix) with ESMTP id 2A01E3A6768 for ; Wed, 9 Feb 2011 10:20:56 -0800 (PST) Received: from mx03.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3FB85288F6; Wed, 9 Feb 2011 20:21:05 +0200 (EET) Received: from EXHUB02.org.aalto.fi (ex-hub02.org.aalto.fi [130.233.222.119]) by mx03.aalto.fi (Postfix) with ESMTP id 2B207288E0; Wed, 9 Feb 2011 20:21:05 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB02.org.aalto.fi ([130.233.222.119]) with mapi; Wed, 9 Feb 2011 20:21:05 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: Pete McCann Thread-Topic: Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLx6sEVyNvlxhxikqx2ukgnn8CzZP3zxvOgAEx0z+AACm+gIAAJky4gAAC3QCAACb4lw== Date: Wed, 9 Feb 2011 18:21:04 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi>, In-Reply-To: Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:20:57 -0000 >I think we should go with whatever was used for MIP6. (was that SHA-1?)= =0A= >I don't think it matters too much that we stick with MD5. Any modern cryp= to=0A= >library will have HMAC_SHA1 as well. This is new functionality so backwar= ds=0A= >compatibility isn't a concern.=0A= =0A= It's SHA-1 for MIP6. Our implementation right now goes with MD5, but I gu= ess it's not too hard to replace that as such..=0A= =0A= Mostly I'm concerned about protocol fields and maintaining symmetry to ex= isting MIP4 fields. SHA-1 is 160-bit hash, MD5 is 128 bits. The authenticat= or field in all other authenticators (foreigh-mobile, foreign-home, mobile-= home etc) is essentially 128 bits, so using 160 bits for mobile-corresponde= nt might affect processing since you cannot use same "template" as with pro= cessing the other authenticator fields. =0A= =0A= Of course, you could always say that use First (128, HMAC_SHA1(xxx)), but= at this point somebody who understands about crypto might start grinding t= heir teeth...=0A= =0A= - Antti=0A= =0A= = From kleung@cisco.com Wed Feb 9 11:25:38 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CAE3A6833 for ; Wed, 9 Feb 2011 11:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxX+B6d27WKh for ; Wed, 9 Feb 2011 11:25:37 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6548A3A67F0 for ; Wed, 9 Feb 2011 11:25:37 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAK14Uk2rR7Ht/2dsb2JhbACWcY5cc6BPmzeFXASEf4op Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2011 19:25:47 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p19JPlT1002745; Wed, 9 Feb 2011 19:25:47 GMT 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.4675); Wed, 9 Feb 2011 11:25:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 11:25:43 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> In-Reply-To: <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLx6sEVyNvlxhxikqx2ukgnn8CzZP3zxvOgAEx0z+AACm+gIAAJky4gAAC3QCAACb4l4AADtzg References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com><21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi><64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi><64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi>, <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> From: "Kent Leung (kleung)" To: =?iso-8859-1?Q?M=E4kel=E4_Antti?= , "Pete McCann" X-OriginalArrivalTime: 09 Feb 2011 19:25:47.0654 (UTC) FILETIME=[275DFA60:01CBC88F] Cc: mip4@ietf.org Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:25:38 -0000 Hi Antti. Comments below. -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of = M=E4kel=E4 Antti Sent: Wednesday, February 09, 2011 10:21 AM To: Pete McCann Cc: mip4@ietf.org Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 >I think we should go with whatever was used for MIP6. (was that = SHA-1?) >I don't think it matters too much that we stick with MD5. Any modern = crypto >library will have HMAC_SHA1 as well. This is new functionality so = backwards >compatibility isn't a concern. It's SHA-1 for MIP6. Our implementation right now goes with MD5, but I = guess it's not too hard to replace that as such.. [Kent Leung (kleung)] Seems HMAC_SHA1 is better to use than MD5. =20 Mostly I'm concerned about protocol fields and maintaining symmetry to = existing MIP4 fields. SHA-1 is 160-bit hash, MD5 is 128 bits. The = authenticator field in all other authenticators (foreigh-mobile, = foreign-home, mobile-home etc) is essentially 128 bits, so using 160 = bits for mobile-correspondent might affect processing since you cannot = use same "template" as with processing the other authenticator fields.=20 [Kent Leung (kleung)] The Authentication Extensions are not limited to = 128 bits since the Length field is used to indicate size of the = Authenticator field. If implementations are hard coded with 128 bits, = then going with HMAC-MD5 (which is the default crypto for MIPv4). Maybe = by default it's HMAC_SHA1 (160 bits), with option for HMAC_MD5 (128 = bits)? Kent Of course, you could always say that use First (128, HMAC_SHA1(xxx)), = but at this point somebody who understands about crypto might start = grinding their teeth... - Antti =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From antti.makela@aalto.fi Wed Feb 9 13:24:41 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB7A3A69F2 for ; Wed, 9 Feb 2011 13:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9kcmtge640K for ; Wed, 9 Feb 2011 13:24:40 -0800 (PST) Received: from mx05.aalto.fi (mx05.aalto.fi [130.233.222.104]) by core3.amsl.com (Postfix) with ESMTP id C5B643A6839 for ; Wed, 9 Feb 2011 13:24:39 -0800 (PST) Received: from mx05.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3F4908088A; Wed, 9 Feb 2011 23:24:49 +0200 (EET) Received: from EXHUB01.org.aalto.fi (ex-hub01.org.aalto.fi [130.233.222.118]) by mx05.aalto.fi (Postfix) with ESMTP id A4C3380887; Wed, 9 Feb 2011 23:24:48 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB01.org.aalto.fi ([130.233.222.118]) with mapi; Wed, 9 Feb 2011 23:24:22 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: "Kent Leung (kleung)" , Pete McCann Thread-Topic: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLyI8p02mNYkDi6UaP8ZpZmrdXx5P5qVtI Date: Wed, 9 Feb 2011 21:24:21 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com><21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi><64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi><64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi>, <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi>, <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:24:41 -0000 Hi,=0A= =0A= [Kent Leung (kleung)] The Authentication Extensions are not limited to 128 = bits since the Length field is used to indicate size of the Authenticator f= ield. If implementations are hard coded with 128 bits, then going with HMA= C-MD5 (which is the default crypto for MIPv4). Maybe by default it's HMAC_= SHA1 (160 bits), with option for HMAC_MD5 (128 bits)?=0A= =0A= Specifying the used hash algorithm on a per-message basis is certainly po= ssible. The authentication extension has a bunch of free bits as of now. It= could be simply defined that if a bit is not set, the authenticator has be= en computed using MD5 and if yes, the authenticator has been configured usi= ng SHA-1.=0A= =0A= Anyway, picking one algorithm and sticking to it is probably easier (and = doesn't cause a discussion on a minimum set that needs to be supported in i= mplementations, and so on). Instead, I think there could perhaps be a wider= effort to make the MIP4 messages support freely selectable crypto algorith= ms as a whole (has there ever been work on "selectable hash algorithm exten= sion"?). =0A= =0A= So if SHA-1 is better choice (it's been used with MIP6), the question bec= omes whether using truncated version to match other authenticator lengths i= s a good idea - actually, MIP6 only uses first 96 bits, not 128, so it's pr= obably ok. As per RFC 3775,=0A= =0A= Mobility Data =3D care-of address | correspondent | MH Data=0A= Authenticator =3D First (96, HMAC_SHA1 (Kbm, Mobility Data))=0A= =0A= So if I were to go SHA-1, I'd replace the authenticator with=0A= =0A= First(128, HMAC_SHA1(KRm, Protected Data))=0A= =0A= For Tokens and Krm, just change the algorithm:=0A= =0A= Home keygen token =3D First (64, HMAC_SHA1 (Kcr, (home address | nonce | = 0)))=0A= =0A= and=0A= =0A= KRm =3D SHA1 (home keygen token | care-of keygen token)=0A= =0A= (Which pretty much makes them identical with MIP6).=0A= =0A= Anyway, if there's no one defending the use of MD5, I can make the above = changes.= From kleung@cisco.com Wed Feb 9 13:28:25 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 499AA3A6A07 for ; Wed, 9 Feb 2011 13:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHGEfjQ0ZOD9 for ; Wed, 9 Feb 2011 13:28:24 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 768AC3A69FF for ; Wed, 9 Feb 2011 13:28:24 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBACeWUk2rR7Ht/2dsb2JhbACWfo5cc6A0mzaFXASEf4op Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2011 21:28:34 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p19LSYSw019524; Wed, 9 Feb 2011 21:28:34 GMT 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.4675); Wed, 9 Feb 2011 13:28:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 13:28:36 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> In-Reply-To: <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLyI8p02mNYkDi6UaP8ZpZmrdXx5P5qVtIgAAFekA= References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com><21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi><64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi><64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi>, <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi>, <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> From: "Kent Leung (kleung)" To: =?iso-8859-1?Q?M=E4kel=E4_Antti?= , "Pete McCann" X-OriginalArrivalTime: 09 Feb 2011 21:28:34.0699 (UTC) FILETIME=[4E77D5B0:01CBC8A0] Cc: mip4@ietf.org Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:28:25 -0000 The algorithm is selectable by SPI value. For example, in MIPv4 = deployments where some MNs supported keyed MD5 (due to backwards = compatability) and other MNs support HMAC-MD5, the SPI in the MN-HA AE = would select the right security association which contains the algorithm = for authentication. Kent -----Original Message----- From: M=E4kel=E4 Antti [mailto:antti.makela@aalto.fi]=20 Sent: Wednesday, February 09, 2011 1:24 PM To: Kent Leung (kleung); Pete McCann Cc: mip4@ietf.org Subject: RE: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 Hi, [Kent Leung (kleung)] The Authentication Extensions are not limited to = 128 bits since the Length field is used to indicate size of the = Authenticator field. If implementations are hard coded with 128 bits, = then going with HMAC-MD5 (which is the default crypto for MIPv4). Maybe = by default it's HMAC_SHA1 (160 bits), with option for HMAC_MD5 (128 = bits)? Specifying the used hash algorithm on a per-message basis is certainly = possible. The authentication extension has a bunch of free bits as of = now. It could be simply defined that if a bit is not set, the = authenticator has been computed using MD5 and if yes, the authenticator = has been configured using SHA-1. Anyway, picking one algorithm and sticking to it is probably easier = (and doesn't cause a discussion on a minimum set that needs to be = supported in implementations, and so on). Instead, I think there could = perhaps be a wider effort to make the MIP4 messages support freely = selectable crypto algorithms as a whole (has there ever been work on = "selectable hash algorithm extension"?).=20 So if SHA-1 is better choice (it's been used with MIP6), the question = becomes whether using truncated version to match other authenticator = lengths is a good idea - actually, MIP6 only uses first 96 bits, not = 128, so it's probably ok. As per RFC 3775, Mobility Data =3D care-of address | correspondent | MH Data Authenticator =3D First (96, HMAC_SHA1 (Kbm, Mobility Data)) So if I were to go SHA-1, I'd replace the authenticator with First(128, HMAC_SHA1(KRm, Protected Data)) For Tokens and Krm, just change the algorithm: Home keygen token =3D First (64, HMAC_SHA1 (Kcr, (home address | nonce = | 0))) and KRm =3D SHA1 (home keygen token | care-of keygen token) (Which pretty much makes them identical with MIP6). Anyway, if there's no one defending the use of MD5, I can make the = above changes. From antti.makela@aalto.fi Wed Feb 9 21:36:57 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857B73A6892 for ; Wed, 9 Feb 2011 21:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge6xOnNnHVfD for ; Wed, 9 Feb 2011 21:36:56 -0800 (PST) Received: from mx06.aalto.fi (mx06.aalto.fi [130.233.222.105]) by core3.amsl.com (Postfix) with ESMTP id AF35C3A6889 for ; Wed, 9 Feb 2011 21:36:56 -0800 (PST) Received: from mx06.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AD5EF808EE; Thu, 10 Feb 2011 07:37:06 +0200 (EET) Received: from EXHUB01.org.aalto.fi (ex-hub01.org.aalto.fi [130.233.222.118]) by mx06.aalto.fi (Postfix) with ESMTP id 27A2A808EB; Thu, 10 Feb 2011 07:37:06 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB01.org.aalto.fi ([130.233.222.118]) with mapi; Thu, 10 Feb 2011 07:36:51 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: "Kent Leung (kleung)" , Pete McCann Thread-Topic: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLyI8p02mNYkDi6UaP8ZpZmrdXx5P5qVtIgAAFekCAAIeRUA== Date: Thu, 10 Feb 2011 05:36:51 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com><21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi><64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi><64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi>, <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi>, <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi>, <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> In-Reply-To: <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 05:36:57 -0000 Ok - I was under the impression that the SPI was only used to toggle e.g. u= sage of timestamps. =0A= =0A= ________________________________________=0A= From: mip4-bounces@ietf.org [mip4-bounces@ietf.org] on behalf of Kent Leung= (kleung) [kleung@cisco.com]=0A= Sent: Wednesday, February 09, 2011 23:28=0A= To: M=E4kel=E4 Antti; Pete McCann=0A= Cc: mip4@ietf.org=0A= Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03=0A= =0A= The algorithm is selectable by SPI value. For example, in MIPv4 deployment= s where some MNs supported keyed MD5 (due to backwards compatability) and o= ther MNs support HMAC-MD5, the SPI in the MN-HA AE would select the right s= ecurity association which contains the algorithm for authentication.=0A= =0A= Kent=0A= From mccap@petoni.org Thu Feb 10 08:04:33 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE783A67B1 for ; Thu, 10 Feb 2011 08:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rQyWPSaLxOv for ; Thu, 10 Feb 2011 08:04:33 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C504F3A6778 for ; Thu, 10 Feb 2011 08:04:32 -0800 (PST) Received: by wyf23 with SMTP id 23so1571555wyf.31 for ; Thu, 10 Feb 2011 08:04:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.134.129 with SMTP id j1mr7714025wbt.183.1297353884525; Thu, 10 Feb 2011 08:04:44 -0800 (PST) Received: by 10.227.147.74 with HTTP; Thu, 10 Feb 2011 08:04:44 -0800 (PST) X-Originating-IP: [64.53.131.166] In-Reply-To: <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi> Date: Thu, 10 Feb 2011 10:04:44 -0600 Message-ID: From: Pete McCann To: =?ISO-8859-1?B?TeRrZWzkIEFudHRp?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Kent Leung \(kleung\)" , "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:04:33 -0000 No, Kent is correct. The SPI is an index to find the "security association= ", which includes all aspects (secret, algorithm, replay protection method, et= c). If we need a method to dynamically update a security association (such as was done with the MN-AAA extension) that is the time we need to worry about encoding algorithms and such. -Pete On Wed, Feb 9, 2011 at 11:36 PM, M=E4kel=E4 Antti w= rote: > Ok - I was under the impression that the SPI was only used to toggle e.g.= usage of timestamps. > > ________________________________________ > From: mip4-bounces@ietf.org [mip4-bounces@ietf.org] on behalf of Kent Leu= ng (kleung) [kleung@cisco.com] > Sent: Wednesday, February 09, 2011 23:28 > To: M=E4kel=E4 Antti; Pete McCann > Cc: mip4@ietf.org > Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 > > The algorithm is selectable by SPI value. =A0For example, in MIPv4 deploy= ments where some MNs supported keyed MD5 (due to backwards compatability) a= nd other MNs support HMAC-MD5, the SPI in the MN-HA AE would select the rig= ht security association which contains the algorithm for authentication. > > Kent > From antti.makela@aalto.fi Thu Feb 10 08:19:41 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3FD3A6A38 for ; Thu, 10 Feb 2011 08:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol+F+hj5kATH for ; Thu, 10 Feb 2011 08:19:40 -0800 (PST) Received: from mx04.aalto.fi (mx04.aalto.fi [130.233.222.103]) by core3.amsl.com (Postfix) with ESMTP id 6CC843A69C5 for ; Thu, 10 Feb 2011 08:19:40 -0800 (PST) Received: from mx04.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F20E9F083C; Thu, 10 Feb 2011 18:19:51 +0200 (EET) Received: from EXHUB01.org.aalto.fi (ex-hub01.org.aalto.fi [130.233.222.118]) by mx04.aalto.fi (Postfix) with ESMTP id EA17BF0831; Thu, 10 Feb 2011 18:19:51 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB01.org.aalto.fi ([130.233.222.118]) with mapi; Thu, 10 Feb 2011 18:19:51 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: Pete McCann Thread-Topic: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLyI8p02mNYkDi6UaP8ZpZmrdXx5P5qVtIgAAFekCAAIeRUIAAj2sAgAAk8/w= Date: Thu, 10 Feb 2011 16:16:59 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF945B5@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi>, <26274_1297353891_4D540CA2_26274_1362_1_AANLkTimGyfL4ipA7wWeUnXbk8nU4u8TpcLuLh2Amj16e@mail.gmail.com> In-Reply-To: <26274_1297353891_4D540CA2_26274_1362_1_AANLkTimGyfL4ipA7wWeUnXbk8nU4u8TpcLuLh2Amj16e@mail.gmail.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:19:41 -0000 Very well. =0A= =0A= I'll update the draft to use SHA1 truncated to 128 bits (MIP6 uses 96 bits,= so I'd think that truncation is ok). I checked and our implementation shou= ld bend to that very easily as well since the library already supports SHA1= as well.=0A= =0A= Was there anything else to add to the realm compression discussion?=0A= =0A= --=0A= - Antti M=E4kel=E4 | Researcher -=0A= - Department of communications and networking -=0A= - Aalto University -=0A= =0A= ________________________________________=0A= From: mip4-bounces@ietf.org [mip4-bounces@ietf.org] on behalf of Pete McCan= n [mccap@petoni.org]=0A= Sent: Thursday, February 10, 2011 18:04=0A= To: M=E4kel=E4 Antti=0A= Cc: Kent Leung (kleung); mip4@ietf.org=0A= Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03=0A= =0A= No, Kent is correct. The SPI is an index to find the "security association= ",=0A= which includes all aspects (secret, algorithm, replay protection method, et= c).=0A= =0A= If we need a method to dynamically update a security association (such as= =0A= was done with the MN-AAA extension) that is the time we need to worry=0A= about encoding algorithms and such.=0A= =0A= -Pete=0A= =0A= On Wed, Feb 9, 2011 at 11:36 PM, M=E4kel=E4 Antti w= rote:=0A= > Ok - I was under the impression that the SPI was only used to toggle e.g.= usage of timestamps.=0A= >=0A= > ________________________________________=0A= > From: mip4-bounces@ietf.org [mip4-bounces@ietf.org] on behalf of Kent Leu= ng (kleung) [kleung@cisco.com]=0A= > Sent: Wednesday, February 09, 2011 23:28=0A= > To: M=E4kel=E4 Antti; Pete McCann=0A= > Cc: mip4@ietf.org=0A= > Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03=0A= >=0A= > The algorithm is selectable by SPI value. For example, in MIPv4 deployme= nts where some MNs supported keyed MD5 (due to backwards compatability) and= other MNs support HMAC-MD5, the SPI in the MN-HA AE would select the right= security association which contains the algorithm for authentication.=0A= >=0A= > Kent=0A= >=0A= --=0A= Mip4 mailing list: Mip4@ietf.org=0A= Web interface: https://www.ietf.org/mailman/listinfo/mip4=0A= Charter page: http://www.ietf.org/html.charters/mip4-charter.html=0A= Supplemental site: http://www.mip4.org/=0A= From jouni.nospam@gmail.com Thu Feb 10 08:28:28 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8EB03A67A2 for ; Thu, 10 Feb 2011 08:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoD6RUWzCPDx for ; Thu, 10 Feb 2011 08:28:27 -0800 (PST) Received: from vs15.mail.saunalahti.fi (vs15.mail.saunalahti.fi [195.197.172.101]) by core3.amsl.com (Postfix) with ESMTP id 4F41C3A659A for ; Thu, 10 Feb 2011 08:28:27 -0800 (PST) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs15.mail.saunalahti.fi (Postfix) with SMTP id 61CC91030AA; Thu, 10 Feb 2011 18:28:38 +0200 (EET) Received: from vs15.mail.saunalahti.fi ([127.0.0.1]) by vs15.mail.saunalahti.fi ([195.197.172.101]) with SMTP (gateway) id A0159E5F9E5; Thu, 10 Feb 2011 18:28:38 +0200 Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs15.mail.saunalahti.fi (Postfix) with ESMTP id 4BBA31030AA; Thu, 10 Feb 2011 18:28:38 +0200 (EET) Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id D1B97216A6B; Thu, 10 Feb 2011 18:28:34 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <64FACAB831EEEB418F27A18FE09095243CF945B5@EXMDB08.org.aalto.fi> Date: Thu, 10 Feb 2011 18:28:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <50019E1F-E975-42B2-8631-4552B08334E2@gmail.com> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi>, <26274_1297353891_4D540CA2_26274_1362_1_AANLkTimGyfL4ipA7wWeUnXbk8nU4u8TpcLuLh2Amj16e@mail.gmail.com> <64FACAB831EEEB418F27A18FE09095243CF945B5@EXMDB 08.org.aalto.fi> To: =?iso-8859-1?Q?M=E4kel=E4_Antti?= X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Cc: Pete McCann , "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:28:28 -0000 Antti, On Feb 10, 2011, at 6:16 PM, M=E4kel=E4 Antti wrote: > Very well.=20 >=20 > I'll update the draft to use SHA1 truncated to 128 bits (MIP6 uses 96 = bits, so I'd think that truncation is ok). I checked and our = implementation should bend to that very easily as well since the library = already supports SHA1 as well. >=20 > Was there anything else to add to the realm compression discussion? We could add the LRU replacement algorithm instead of junking the whole = dictionary, when it gets full. We have not implemented LRU though, so I = have no idea how much better it would perform. I believe LRU would beat = out current approach though, with a cost of few lines more of code and = such. Up to you. - Jouni >=20 > -- > - Antti M=E4kel=E4 | Researcher - > - Department of communications and networking - > - Aalto University - >=20 > ________________________________________ > From: mip4-bounces@ietf.org [mip4-bounces@ietf.org] on behalf of Pete = McCann [mccap@petoni.org] > Sent: Thursday, February 10, 2011 18:04 > To: M=E4kel=E4 Antti > Cc: Kent Leung (kleung); mip4@ietf.org > Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 >=20 > No, Kent is correct. The SPI is an index to find the "security = association", > which includes all aspects (secret, algorithm, replay protection = method, etc). >=20 > If we need a method to dynamically update a security association (such = as > was done with the MN-AAA extension) that is the time we need to worry > about encoding algorithms and such. >=20 > -Pete >=20 > On Wed, Feb 9, 2011 at 11:36 PM, M=E4kel=E4 Antti = wrote: >> Ok - I was under the impression that the SPI was only used to toggle = e.g. usage of timestamps. >>=20 >> ________________________________________ >> From: mip4-bounces@ietf.org [mip4-bounces@ietf.org] on behalf of Kent = Leung (kleung) [kleung@cisco.com] >> Sent: Wednesday, February 09, 2011 23:28 >> To: M=E4kel=E4 Antti; Pete McCann >> Cc: mip4@ietf.org >> Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 >>=20 >> The algorithm is selectable by SPI value. For example, in MIPv4 = deployments where some MNs supported keyed MD5 (due to backwards = compatability) and other MNs support HMAC-MD5, the SPI in the MN-HA AE = would select the right security association which contains the algorithm = for authentication. >>=20 >> Kent >>=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.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://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ From antti.makela@aalto.fi Thu Feb 10 09:13:28 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89143A67B6 for ; Thu, 10 Feb 2011 09:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBhSFl+mwAj1 for ; Thu, 10 Feb 2011 09:13:28 -0800 (PST) Received: from mx04.aalto.fi (mx04.aalto.fi [130.233.222.103]) by core3.amsl.com (Postfix) with ESMTP id AE8C73A63CA for ; Thu, 10 Feb 2011 09:13:27 -0800 (PST) Received: from mx04.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 45630F081F; Thu, 10 Feb 2011 19:13:39 +0200 (EET) Received: from EXHUB04.org.aalto.fi (ex-hub04.org.aalto.fi [130.233.222.117]) by mx04.aalto.fi (Postfix) with ESMTP id 00A0CF081E; Thu, 10 Feb 2011 19:13:38 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB04.org.aalto.fi ([130.233.222.117]) with mapi; Thu, 10 Feb 2011 19:13:38 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: Jouni Thread-Topic: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLyI8p02mNYkDi6UaP8ZpZmrdXx5P5qVtIgAAFekCAAIeRUIAAj2sAgAAk8/z//+G1AIAAI/wX Date: Thu, 10 Feb 2011 17:13:38 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF945CE@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi>, <26274_1297353891_4D540CA2_26274_1362_1_AANLkTimGyfL4ipA7wWeUnXbk8nU4u8TpcLuLh2Amj16e@mail.gmail.com> <64FACAB831EEEB418F27A18FE09095243CF945B5@EXMDB 08.org.aalto.fi>, <766_1297355325_4D54123D_766_79_1_50019E1F-E975-42B2-8631-4552B08334E2@gmail.com> In-Reply-To: <766_1297355325_4D54123D_766_79_1_50019E1F-E975-42B2-8631-4552B08334E2@gmail.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete McCann , "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:13:29 -0000 >We could add the LRU replacement algorithm instead of junking the whole di= ctionary, when it gets full. We have not implemented LRU >though, so I have= no idea how much better it would perform. I believe LRU would beat out cur= rent approach though, with a cost of few >lines more of code and such. Up t= o you.=0A= =0A= Hey,=0A= =0A= The LRU should be doable. Currently, text says about filling the dictionary= as such:=0A= =0A= --=0A= The dictionary can hold maximum 128 strings. Thus, when adding the 129th st= ring into the dictionary, the dictionary MUST first be reset to the initial= state (i.e. Emptied) and the index of the string will become 0.=0A= --=0A= =0A= Simplest change would of course be simply a rollover to the index that next= one goes to index 0, but not flushing the dictionary. The implementation c= ode footprint would remain the same as before.=0A= =0A= However, a more LRU'ish way requires extra information - which *is* the lea= st recently used entry. How's this (adds basically just a table of index en= tries, table length 128). Adds a second search when index becomes full, tho= ugh.=0A= =0A= -----=0A= The dictionary can hold maximum 128 strings. When more strings are added in= to the dictionary, the least-recently entry MUST be discarded. =0A= ----=0A= =0A= And add in the end of 4.2.2 the details:=0A= =0A= -----=0A= Alongside the dictionary, a counter and a table of integers with 128 entrie= s is maintained. The counter is initialized to 0 at the start of encoding o= r decoding process.=0A= =0A= When a new string is to be inserted into the dictionary, and the dictionary= is full, the table MUST be searched for the smallest value. The index of t= he value in the table becomes the index of the new dictionary entry. Existi= ng entry MUST be discarded and replaced with the new string. If the diction= ary is not full, the new string MUST be inserted into the end of the dictio= nary, and counter is stored at the same index.=0A= =0A= When the search algorithm finds a match in existing labels, the current val= ue of the counter MUST replace the existing value in the table at the label= 's index. =0A= =0A= The counter MUST increased whenever a new dictionary entry is inserted, or = match is found during the search. =0A= ------=0A= =0A= This would result in a second table (where you can probably survive with un= signed shorts), and slow down processing somewhat, but probably be a bit mo= re effective. = From Internet-Drafts@ietf.org Thu Feb 10 17:30:04 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012803A6860; Thu, 10 Feb 2011 17:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IlZlX6WgTuG; Thu, 10 Feb 2011 17:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4285A3A672F; Thu, 10 Feb 2011 17:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110211013002.6958.58592.idtracker@localhost> Date: Thu, 10 Feb 2011 17:30:02 -0800 Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-gre-key-extension-04.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 01:30:04 -0000 --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 : GRE Key Extension for Mobile IPv4 Author(s) : P. Yegani, et al. Filename : draft-ietf-mip4-gre-key-extension-04.txt Pages : 9 Date : 2011-02-10 The GRE specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile's traffic. The new extension allows a foreign agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4. GRE tunneling with the Key field allows the operators to have home networks that consist of multiple Virtual Private Networks (VPNs), which may have overlapping home addresses. When the tuple < Care of Address, Home Address and Home Agent Address > is the same across multiple subscriber sessions, GRE tunneling will provide a means for the FA and HA to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other, a significant drawback when using IP-in-IP tunneling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-gre-key-extension-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mip4-gre-key-extension-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-10172936.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Sun Feb 13 22:42:55 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153C03A6C77 for ; Sun, 13 Feb 2011 22:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.987 X-Spam-Level: X-Spam-Status: No, score=-2.987 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0FoGXW2RNEA for ; Sun, 13 Feb 2011 22:42:52 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 41D583A6C85 for ; Sun, 13 Feb 2011 22:42:47 -0800 (PST) Received: by eyd10 with SMTP id 10so2339582eyd.31 for ; Sun, 13 Feb 2011 22:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=+vkpFrsFiTzWTK04LsLYR7naWwQmyPz6y6DcXpIuytI=; b=tAl/HNYTDlndsaCKPVe6M1QsqcoSxVnq60jNePE0R/XwB07wDWBsuuHGt3jbbhgxvz DhlZkDZ0sr9EYvKk/M9Mo5ZGJpa0s1+zlFhx/CLx5/5E2TYfrq+JV3chFohvhHjRogIf Gc3Lwj2b4jPiS2nd5w5kUwBu8k1lfby7we2dM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Ta6ARI6hakfhLMPXqzcpWYElvamB/AFR2R19epZqgMCWQY/w0QrePaaNtYhQalzl8D rjX25/+Um/GG/hl4DFcetHoYq+pUx8+HQJ2p+/8DQnVaUZ9nI+edQPdJPMwvSyspMozI GPKvdxdmrZq2a0juVeH03qdgZRop2GP+4EnuM= Received: by 10.213.35.3 with SMTP id n3mr3502328ebd.36.1297665786187; Sun, 13 Feb 2011 22:43:06 -0800 (PST) Received: from a88-114-173-94.elisa-laajakaista.fi (a88-114-173-94.elisa-laajakaista.fi [88.114.173.94]) by mx.google.com with ESMTPS id u1sm2168861eeh.22.2011.02.13.22.43.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Feb 2011 22:43:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <64FACAB831EEEB418F27A18FE09095243CF945CE@EXMDB08.org.aalto.fi> Date: Mon, 14 Feb 2011 08:43:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <881DE455-BD31-436C-B86B-E25666AA0B7E@gmail.com> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi>, <26274_1297353891_4D540CA2_26274_1362_1_AANLkTimGyfL4ipA7wWeUnXbk8nU4u8TpcLuLh2Amj16e@mail.gmail.com> <64FACAB831EEEB418F27A18FE09095243CF945B5@EXMDB 08.org.aalto.fi>, <766_1297355325_4D54123D_766_79_1_50019E1F-E975-42B2-8631-4552B08334E2@gmail.com> <64FACAB831EEEB418F27A18FE09095243CF945CE@EXMDB08.org.aalto.fi> To: =?iso-8859-1?Q?M=E4kel=E4_Antti?= X-Mailer: Apple Mail (2.1078) Cc: Pete McCann , "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 06:42:55 -0000 Stuff inline. On Feb 10, 2011, at 7:13 PM, M=E4kel=E4 Antti wrote: >> We could add the LRU replacement algorithm instead of junking the = whole dictionary, when it gets full. We have not implemented LRU = >though, so I have no idea how much better it would perform. I believe = LRU would beat out current approach though, with a cost of few >lines = more of code and such. Up to you. >=20 > Hey, >=20 > The LRU should be doable. Currently, text says about filling the = dictionary as such: >=20 > -- > The dictionary can hold maximum 128 strings. Thus, when adding the = 129th string into the dictionary, the dictionary MUST first be reset to = the initial state (i.e. Emptied) and the index of the string will become = 0. > -- >=20 > Simplest change would of course be simply a rollover to the index that = next one goes to index 0, but not flushing the dictionary. The = implementation code footprint would remain the same as before. >=20 > However, a more LRU'ish way requires extra information - which *is* = the least recently used entry. How's this (adds basically just a table = of index entries, table length 128). Adds a second search when index = becomes full, though. >=20 > ----- > The dictionary can hold maximum 128 strings. When more strings are = added into the dictionary, the least-recently entry MUST be discarded.=20= > ---- Just need to make sure that it works in a case there are multiple = strings with the same reference count. A dictionary entry reference = counter overflow needs to be handled as well. Also a trivial dictionary = replacement strategy, in the worst case, results into swapping of few = strings.. Making these things without testing worries me a bit, to be = honest. >=20 > And add in the end of 4.2.2 the details: >=20 > ----- > Alongside the dictionary, a counter and a table of integers with 128 = entries is maintained. The counter is initialized to 0 at the start of = encoding or decoding process. "Each string in the dictionary is associated with a 16-bit reference = count. The counter is initialized to 0 at the start of the encoding or = decoding process. The 16-bt counter is treated as an unsigned integer." > When a new string is to be inserted into the dictionary, and the = dictionary is full, the table MUST be searched for the smallest value. = The index of the value in the table becomes the index of the new = dictionary entry. Existing entry MUST be discarded and replaced with the = new string. If the dictionary is not full, the new string MUST be = inserted into the end of the dictionary, and counter is stored at the = same index. "When a new string is to be inserted into the dictionary, and the = dictionary is full, then table MUST be searched for the string with the = lowest reference count. If there are multiple strings with the (lowest) = same reference count, the string with the smallest index value gets = selected. The index of the selected string in the dictionary becomes the = index of the dictionary entry to be replaced. The reference count to the = new dictionary entry is left as it was earlier. If the dictionary is not = full, the new string is inserted into the first available index in the = dictionary and its reference count is initialized to 1." >=20 > When the search algorithm finds a match in existing labels, the = current value of the counter MUST replace the existing value in the = table at the label's index.=20 Dunno what the above is for... remove it. >=20 > The counter MUST increased whenever a new dictionary entry is = inserted, or match is found during the search.=20 "When the search algorithm finds a match in the dictionary, the = reference count of the string MUST be increased by one. If the reference = count overflows, i.e. wraps from 65535 to 0, then the whole dictionary = MUST be reset to the initial state (i.e. emptied), the index of the = string will become 0 and the reference count is initialized to 1." > ------ >=20 > This would result in a second table (where you can probably survive = with unsigned shorts), and slow down processing somewhat, but probably = be a bit more effective. No need for new tables in a conceptual sense. We just add a reference = counter to each string and let it be like that. - Jouni From antti.makela@aalto.fi Mon Feb 14 01:45:09 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C1C3A6C93 for ; Mon, 14 Feb 2011 01:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsXqrtpRb-ka for ; Mon, 14 Feb 2011 01:45:09 -0800 (PST) Received: from mx04.aalto.fi (mx04.aalto.fi [130.233.222.103]) by core3.amsl.com (Postfix) with ESMTP id 8B5083A6C92 for ; Mon, 14 Feb 2011 01:45:08 -0800 (PST) Received: from mx04.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AE860F03F1; Mon, 14 Feb 2011 11:45:29 +0200 (EET) Received: from EXHUB01.org.aalto.fi (ex-hub01.org.aalto.fi [130.233.222.118]) by mx04.aalto.fi (Postfix) with ESMTP id 53463F03E7; Mon, 14 Feb 2011 11:45:29 +0200 (EET) Received: from EXMDB08.org.aalto.fi ([169.254.8.40]) by EXHUB01.org.aalto.fi ([130.233.222.118]) with mapi; Mon, 14 Feb 2011 11:45:29 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: jouni korhonen Thread-Topic: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLyI8p02mNYkDi6UaP8ZpZmrdXx5P5qVtIgAAFekCAAIeRUIAAj2sAgAAk8/z//+G1AIAAI/wXgAWBvwCAAFEYcA== Date: Mon, 14 Feb 2011 09:45:28 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF94923@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi>, <26274_1297353891_4D540CA2_26274_1362_1_AANLkTimGyfL4ipA7wWeUnXbk8nU4u8TpcLuLh2Amj16e@mail.gmail.com> <64FACAB831EEEB418F27A18FE09095243CF945B5@EXMDB 08.org.aalto.fi>, <766_1297355325_4D54123D_766_79_1_50019E1F-E975-42B2-8631-4552B08334E2@gmail.com> <64FACAB831EEEB418F27A18FE09095243CF945CE@EXMDB08.org.aalto.fi>, <9639_1297665803_4D58CF0A_9639_1636_1_881DE455-BD31-436C-B86B-E25666AA0B7E@gmail.com> In-Reply-To: <9639_1297665803_4D58CF0A_9639_1636_1_881DE455-BD31-436C-B86B-E25666AA0B7E@gmail.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete McCann , "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 09:45:09 -0000 >> The dictionary can hold maximum 128 strings. When more strings are added= into the dictionary, the least-recently entry MUST be >>iscarded.=0A= >Just need to make sure that it works in a case there are multiple strings = with the same reference count. A dictionary entry reference >counter overfl= ow needs to be handled as well. Also a trivial dictionary replacement strat= egy, in the worst case, results into swapping of >few strings.. Making thes= e things without testing worries me a bit, to be honest.=0A= =0A= Indeed, me too. Especially when there are not necessarily that much gains= . Your reference counter approach seems ok on the surface, though.=0A= =0A= The simple adjustment option of simply NOT flushing the dictionary but ov= erwriting from the bottom sounds most appealing to me instead of specifying= a new scheme in a relatively ad-hoc fashion without an implementation. =0A= =0A= Also, as our research showed, in the case where there are lots of realms = with some common elements (such as example.com), the only loss you get is t= hat at i=3D129 you have to re-introduce those few common labels - bad thing= in case you have exactly 131 labels or so, but not really in a generic cas= e.=0A= =0A= Pete - do you think this small change (not flushing, but overwriting from= bottom) is ok, instead of LRU scheme? I can upload -04 as soon as you give= the word.=0A= =0A= =0A= =0A= =0A= From mccap@petoni.org Mon Feb 14 06:55:41 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D5E3A6D63 for ; Mon, 14 Feb 2011 06:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.763 X-Spam-Level: X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nvw7GNxq3nst for ; Mon, 14 Feb 2011 06:55:40 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 68F513A6D50 for ; Mon, 14 Feb 2011 06:55:40 -0800 (PST) Received: by wwa36 with SMTP id 36so4862163wwa.13 for ; Mon, 14 Feb 2011 06:56:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.152.197 with SMTP id h5mr2594519wbw.78.1297695362663; Mon, 14 Feb 2011 06:56:02 -0800 (PST) Received: by 10.227.24.137 with HTTP; Mon, 14 Feb 2011 06:56:02 -0800 (PST) X-Originating-IP: [64.53.131.166] In-Reply-To: <64FACAB831EEEB418F27A18FE09095243CF94923@EXMDB08.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi> <26274_1297353891_4D540CA2_26274_1362_1_AANLkTimGyfL4ipA7wWeUnXbk8nU4u8TpcLuLh2Amj16e@mail.gmail.com> <766_1297355325_4D54123D_766_79_1_50019E1F-E975-42B2-8631-4552B08334E2@gmail.com> <64FACAB831EEEB418F27A18FE09095243CF945CE@EXMDB08.org.aalto.fi> <9639_1297665803_4D58CF0A_9639_1636_1_881DE455-BD31-436C-B86B-E25666AA0B7E@gmail.com> <64FACAB831EEEB418F27A18FE09095243CF94923@EXMDB08.org.aalto.fi> Date: Mon, 14 Feb 2011 08:56:02 -0600 Message-ID: From: Pete McCann To: =?ISO-8859-1?B?TeRrZWzkIEFudHRp?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jouni korhonen , "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 14:55:41 -0000 On Mon, Feb 14, 2011 at 3:45 AM, M=E4kel=E4 Antti w= rote: > > =A0Pete - do you think this small change (not flushing, but overwriting f= rom bottom) is ok, instead of LRU scheme? I can upload -04 as soon as you g= ive the word. Yes, I'm all for simplicity. This whole scheme (even with just rolling over to the bottom) seems like we're off in the weeds to me. Go ahead and submit what = you think is best and I'll try to get some wider review from outside the WG. -Pete From antti.makela@aalto.fi Mon Feb 14 07:34:50 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A813A6D6E for ; Mon, 14 Feb 2011 07:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9KfgzNWT1lX for ; Mon, 14 Feb 2011 07:34:49 -0800 (PST) Received: from mx03.aalto.fi (mx03.aalto.fi [130.233.222.102]) by core3.amsl.com (Postfix) with ESMTP id 520943A6D5E for ; Mon, 14 Feb 2011 07:34:49 -0800 (PST) Received: from mx03.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 71DDF2859D; Mon, 14 Feb 2011 17:35:11 +0200 (EET) Received: from EXHUB02.org.aalto.fi (ex-hub02.org.aalto.fi [130.233.222.119]) by mx03.aalto.fi (Postfix) with ESMTP id 5B4642859B; Mon, 14 Feb 2011 17:35:11 +0200 (EET) Received: from EXMDB07.org.aalto.fi ([169.254.7.14]) by EXHUB02.org.aalto.fi ([130.233.222.119]) with mapi; Mon, 14 Feb 2011 17:35:11 +0200 From: =?iso-8859-1?Q?M=E4kel=E4_Antti?= To: Pete McCann Thread-Topic: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 Thread-Index: AQHLyI8p02mNYkDi6UaP8ZpZmrdXx5P5qVtIgAAFekCAAIeRUIAAj2sAgAAk8/z//+G1AIAAI/wXgAWBvwCAAFEYcIAAOKYAgAAsMIw= Date: Mon, 14 Feb 2011 15:34:10 +0000 Message-ID: <64FACAB831EEEB418F27A18FE09095243CF97E5B@EXMDB07.org.aalto.fi> References: <21142_1297181564_4D516B7B_21142_84_1_AANLkTinZv5FJiBP1VqXWa=zEkgZLb=p1OgT_7pQmuGwo@mail.gmail.com> <21460_1297184251_4D5175FB_21460_602_1_64FACAB831EEEB418F27A18FE09095243CF9420D@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF942E8@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943A9@EXMDB08.org.aalto.fi> <64FACAB831EEEB418F27A18FE09095243CF943EE@EXMDB08.org.aalto.fi> <2979E38DD6FC6544B789C8DAD7BAFC520E0A7DF0@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF9441E@EXMDB08.org.aalto.fi> <19630_1297286920_4D530708_19630_10192_1_2979E38DD6FC6544B789C8DAD7BAFC520E0A7ED1@xmb-sjc-235.amer.cisco.com> <64FACAB831EEEB418F27A18FE09095243CF94488@EXMDB08.org.aalto.fi> <26274_1297353891_4D540CA2_26274_1362_1_AANLkTimGyfL4ipA7wWeUnXbk8nU4u8TpcLuLh2Amj16e@mail.gmail.com> <766_1297355325_4D54123D_766_79_1_50019E1F-E975-42B2-8631-4552B08334E2@gmail.com> <64FACAB831EEEB418F27A18FE09095243CF945CE@EXMDB08.org.aalto.fi> <9639_1297665803_4D58CF0A_9639_1636_1_881DE455-BD31-436C-B86B-E25666AA0B7E@gmail.com> <64FACAB831EEEB418F27A18FE09095243CF94923@EXMDB08.org.aalto.fi>, <15730_1297695368_4D594288_15730_3886_1_AANLkTi=aKB3VXcn5FH9fFvNctFC_Q7hqwZrDxf_-etC3@mail.gmail.com> In-Reply-To: <15730_1297695368_4D594288_15730_3886_1_AANLkTi=aKB3VXcn5FH9fFvNctFC_Q7hqwZrDxf_-etC3@mail.gmail.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: jouni korhonen , "mip4@ietf.org" Subject: Re: [Mip4] Review of draft-ietf-mip4-nemo-haaro-03 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:34:50 -0000 Hi,=0A= =0A= -04 submitted with all the changes discussed in the mailing list, including= the SHA-1 change and the simpler version of realm compression adjustment (= overwriting entries instead of resetting the entire dictionary).=0A= =0A= --=0A= - Antti M=E4kel=E4 | Researcher -=0A= - Department of communications and networking -=0A= - Aalto University -=0A= From Internet-Drafts@ietf.org Mon Feb 14 07:45:02 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34303A6D81; Mon, 14 Feb 2011 07:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJFo98wsQY3b; Mon, 14 Feb 2011 07:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B8B3A6D48; Mon, 14 Feb 2011 07:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110214154502.3177.40614.idtracker@localhost> Date: Mon, 14 Feb 2011 07:45:02 -0800 Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-nemo-haaro-04.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:45:03 -0000 --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 : Home Agent assisted Route Optimization between Mobile IPv4 Networks Author(s) : A. Makela, J. Korhonen Filename : draft-ietf-mip4-nemo-haaro-04.txt Pages : 50 Date : 2011-02-14 This document describes a Home Agent assisted Route Optimization functionality to IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single Home Agent, thus the use case is Route Optimization within single organization or similar entity. The functionality adds the possibility to discover: eligible peer nodes based on information received from Home Agent; Network Prefixes they represent; and, how to establish a direct tunnel between such nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-nemo-haaro-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mip4-nemo-haaro-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-14073332.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Fri Feb 18 09:30:05 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59973A6F39; Fri, 18 Feb 2011 09:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+DrWXsAr96x; Fri, 18 Feb 2011 09:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6991F3A6D71; Fri, 18 Feb 2011 09:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110218173002.23012.10784.idtracker@localhost> Date: Fri, 18 Feb 2011 09:30:02 -0800 Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-multiple-tunnel-support-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:30:05 -0000 --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 : Flow Binding Support for Mobile IPv4 Author(s) : S. Gundavelli, et al. Filename : draft-ietf-mip4-multiple-tunnel-support-01.txt Pages : 26 Date : 2011-02-18 This specification defines extensions to Mobile IPv4 protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple Mobile IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build an higher aggregated data pipe with the home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate flow policies for binding individual traffic flows with the registered care-of addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-multiple-tunnel-support-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mip4-multiple-tunnel-support-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-18092508.I-D@ietf.org> --NextPart-- From daniele.migliorini@for.unipi.it Tue Feb 22 00:52:29 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8313A6405 for ; Tue, 22 Feb 2011 00:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i2zVRr7iV8l for ; Tue, 22 Feb 2011 00:52:28 -0800 (PST) Received: from smtp.unipi.it (smtp3.unipi.it [131.114.21.153]) by core3.amsl.com (Postfix) with ESMTP id 5E7CC3A677E for ; Tue, 22 Feb 2011 00:52:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.unipi.it (Postfix) with ESMTP id 0F7B11C5CC; Tue, 22 Feb 2011 09:53:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at smtp.unipi.it Received: from smtp.unipi.it ([127.0.0.1]) by localhost (smtp.unipi.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKuKLQRn7Suk; Tue, 22 Feb 2011 09:53:03 +0100 (CET) Received: from [131.114.153.87] (unknown [131.114.153.87]) (Authenticated sender: r000420) by smtp.unipi.it (Postfix) with ESMTPSA id 03EC41C4CE; Tue, 22 Feb 2011 09:53:03 +0100 (CET) From: Daniele Migliorini Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2011 09:53:02 +0100 To: mip4@ietf.org Message-Id: <9B02466E-0DB6-42BF-99EC-760AD5905D44@for.unipi.it> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Mip4] IEEE WoWMoM 2011: Call for Demos X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 08:52:29 -0000 ------------------------------------------------------------------------ CALL FOR DEMOS WoWMoM 2011 Twelfth International Symposium on a World of Wireless, Mobile and Multimedia Networks http://wowmom2011.imtlucca.it/ sponsored by IEEE Computer Society, University of Texas at Arlington, IEEE CS TC on Computer Communications (TCCC) June 20-24, 2011 Lucca, Tuscany, Italy ------------------------------------------------------------------------ **** SUBMISSION DEADLINE: MARCH 14th, 2011 ******* ------------------------------------------------------------------------ WoWMoM 2011 invites technical demonstrations and posters showing = innovative and original research in the areas of wireless, mobile, and = multimedia networking as well as ubiquitous and pervasive systems. = Submissions from both industry and academia are strongly encouraged. A BEST DEMO AWARD will be granted by WoWMoM 2011, based on the demos' = innovation and technical contribution. At least one author of each accepted demo is required to register and = present their demo at the conference. The submissions should include an extended abstract of up to two pages = in accordance with the IEEE Computer Society author guidelines. They = should explicitly state what will be demonstrated to the WoWMoM = audience, and how the attendees will be able to interact, enjoy, and = experiment. The abstract should include a full list of authors with = complete affiliations. Power and wireless Internet connectivity will be = available at the venue. Please clearly state if any additional resources = are needed or arrangements have to be made in the email to the demo = chairs (not in the abstract). All submissions will undergo a rigorous review process, the extended = abstracts of accepted demonstrations will be included in the proceedings = of WoWMoM 2011. IMPORTANT DATES * Demo abstract submission deadline: March 14, 2011 * Acceptance notification: April 4, 2011 * Camera-ready submission: April 28, 2011 * WoWMoM 2011: June 20-24, 2011 Submissions should be emailed to BOTH demo chairs: * Falko Dressler, University of Erlangen, Germany = * Dario Maggiorini, University of Milan, Italy From mccap@petoni.org Thu Feb 24 07:43:50 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D573A6A25; Thu, 24 Feb 2011 07:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bwCswnrDB8N; Thu, 24 Feb 2011 07:43:48 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1E61C3A6A1C; Thu, 24 Feb 2011 07:43:46 -0800 (PST) Received: by wwb39 with SMTP id 39so684999wwb.13 for ; Thu, 24 Feb 2011 07:44:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.152.149 with SMTP id g21mr960821wbw.20.1298562274457; Thu, 24 Feb 2011 07:44:34 -0800 (PST) Received: by 10.227.24.137 with HTTP; Thu, 24 Feb 2011 07:44:34 -0800 (PST) X-Originating-IP: [64.53.131.166] Date: Thu, 24 Feb 2011 09:44:34 -0600 Message-ID: From: Pete McCann To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Mip4] Request to Publish draft-ietf-mip4-gre-key-extension-04 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 15:43:50 -0000 Dear iesg-secretary (BCC'd): This is a request for the IESG to consider publication of draft-ietf-mip4-gre-key-extension-04 as a Proposed Standard. Answers to the questionnaire are below. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Pete McCann. Yes, I have reviewed this version of the document and I believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, and no. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. No IPR disclosure related to this document has been filed. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus is solid. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? One nit: the reference to RFC3344 should be replaced with RFC5944. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document contains only normative references, contained in a properly labeled "Normative References" section. No downward refs are present. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA section requests allocation of one Mobile IP Extension Type needed by the document. Missing is a request to allocate the Subtype registry for this type. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No such formal languages exist. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The GRE specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field when GRE tunneling is used. Working Group Summary Considerable time was spent discussing whether the presence of a GRE key extension inserted by an FA can override the setting of the 'G' bit by the MN. We decided that it can, but only when using FA-located tunneling. Document Quality The protocol has been implemented in vendor-specific 3GPP2 extensions previously. The idea is well understood and the present document is of high quality. From jari.arkko@piuha.net Mon Feb 28 15:54:08 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037ED3A6CF4 for ; Mon, 28 Feb 2011 15:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzgGHKbM11HQ for ; Mon, 28 Feb 2011 15:54:07 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6371D3A69B5 for ; Mon, 28 Feb 2011 15:54:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5726B2CC31; Tue, 1 Mar 2011 01:55:07 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV3mABQVAxf3; Tue, 1 Mar 2011 01:55:06 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9C0DC2CC28; Tue, 1 Mar 2011 01:55:06 +0200 (EET) Message-ID: <4D6C35DA.7010405@piuha.net> Date: Tue, 01 Mar 2011 01:55:06 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Mobile IPv4 Mailing List , draft-ietf-mip4-gre-key-extension@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mip4] AD review of draft-ietf-mip4-gre-key-extension X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:54:08 -0000 I have reviewed this draft. The document is basically in good shape, was easy to read, and I have sent it forward to IETF Last Call and an eventual IESG review (currently scheduled for March 17th). I did have two comments, however, and I hope that the authors can address them even if the last call period is starting: > The HA SHOULD accept the RRQ and send a RRP with code 'Accepted (0)'. > The HA MUST assign a GRE key and include the GRE Key Extension in the > RRP before sending it to the FA. The HA MUST include the GRE Key > Extension in all RRPs in response to any RRQ that included GRE Key > Extension, when a GRE key is available for the registration. > The acronyms RRQ and RRP not defined before in this document. Also, the above does not leave room for other issues and error conditions. What if the HA wants to deny the request for some other reason, not related to GRE at all? > The HA MUST follow the procedures specified in RFC 3344 in processing > this extension in Registration Request messages. If the HA receives > the GRE Key Extension in a Registration Request and does not > recognize this non-skippable extension, it MUST silently discard the > message. Perhaps this is already explained in some other document, but how does one recover from this situation. Jari From iesg-secretary@ietf.org Mon Feb 28 16:54:47 2011 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5DF3A6D2B; Mon, 28 Feb 2011 16:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKyLHUcEnCZw; Mon, 28 Feb 2011 16:54:46 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8873A6D1E; Mon, 28 Feb 2011 16:54:46 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110301005446.21771.57661.idtracker@localhost> Date: Mon, 28 Feb 2011 16:54:46 -0800 Cc: mip4@ietf.org Subject: [Mip4] Last Call: (GRE Key Extension for Mobile IPv4) to Proposed Standard X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 00:54:47 -0000 The IESG has received a request from the Mobility for IPv4 WG (mip4) to consider the following document: - 'GRE Key Extension for Mobile IPv4' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mip4-gre-key-extension/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mip4-gre-key-extension/ No IPR declarations have been submitted directly on this I-D.