From wassim.haddad@ericsson.com Thu Jul 2 16:00:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357133A6932 for ; Thu, 2 Jul 2009 16:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AAx0oz-RVdad for ; Thu, 2 Jul 2009 16:00:41 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 5B0673A6AB2 for ; Thu, 2 Jul 2009 16:00:41 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n62N13Uu028889 for ; Thu, 2 Jul 2009 18:01:03 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 18:00:24 -0500 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: Thu, 2 Jul 2009 17:56:28 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04C40ECA@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-haddad-mext-mobisoc-00.txt Thread-Index: Acn7T+KGA5SqY4sNQuSyJTFhhWOCcAAGHLhg References: <20090702200001.ACC7C3A6BB6@core3.amsl.com> From: "Wassim Haddad" To: X-OriginalArrivalTime: 02 Jul 2009 23:00:24.0848 (UTC) FILETIME=[E24A9900:01C9FB68] Subject: [MEXT] FW: I-D Action:draft-haddad-mext-mobisoc-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 23:00:42 -0000 Hi all, I'd like to mention the following new draft: Title: Enhancing Mobile IPv6 Route Optimization Mode with Secure Social = Dimension =09 This memo describes an enhancement to Mobile IPv6 route optimization = mode which=20 is derived from introducing a social dimension within the home network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-mext-mobisoc-00.txt Comments are welcome! Regards, Wassim H. From hesham@elevatemobile.com Fri Jul 3 02:21:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E3928C1E4 for ; Fri, 3 Jul 2009 02:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] 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 umwUR707VhRl for ; Fri, 3 Jul 2009 02:21:00 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 7FF0928C1F3 for ; Fri, 3 Jul 2009 02:21:00 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MMexK-00074u-8Q; Fri, 03 Jul 2009 19:21:18 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Fri, 03 Jul 2009 19:21:13 +1000 From: Hesham Soliman To: =?ISO-2022-JP?B?GyRCM3BJcG1sGyhC?= Message-ID: Thread-Topic: Questions about the draft-ietf-mext-flow-binding-02 Thread-Index: Acn7v5vrn3W8an+VBUiM1NtRiBkogw== In-Reply-To: <30074801.833981246519028522.JavaMail.coremail@bj163app17.163.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] Questions about the draft-ietf-mext-flow-binding-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 09:21:01 -0000 > Hello hesham > > I have read the draft-ietf-mext-flow-binding-02, and i have a question > about the draft. > > When the flow binding list is create for the MN, the HA or LMA must check the => The LMA is not supported in this draft, only the HA, MAP or CN can receive a BU from the MN. > type of the packet which is sent to the MN, and then check which Flow Binding > Entry is matched with this packet. In the home link or LMA domian there maybe > a lot of MNs, and checking the packet maybe cost some time, so it will affect > the efficiency of packet forwarding seriously. => This is already done today by routers very efficiently for load balancing different flows. The whole thing can be done in hardware on the fast path of course using hash tables ...etc. There is nothing new in this draft to warrant concerns about performance. Hesham > > Wudi Ye > > 2009-7-2 From hesham@elevatemobile.com Fri Jul 3 05:15:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D8328C28D for ; Fri, 3 Jul 2009 05:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] 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 13dUixMmOCqA for ; Fri, 3 Jul 2009 05:15:36 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A1BC828C291 for ; Fri, 3 Jul 2009 05:15:35 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MMhgL-00031v-EL for ; Fri, 03 Jul 2009 22:15:57 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Fri, 03 Jul 2009 22:15:52 +1000 From: Hesham Soliman To: mext Message-ID: Thread-Topic: Questions about the draft-ietf-mext-flow-binding-02 Thread-Index: Acn7w2gSrrd03itAUUiyy0mIIB1ngAAFJnSf In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit Subject: [MEXT] FW: Questions about the draft-ietf-mext-flow-binding-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 12:15:37 -0000 Sorry forgot to copy the list. ------ Forwarded Message > From: Hesham Soliman > Date: Fri, 03 Jul 2009 19:48:24 +1000 > To: $B3pIpml(B > Conversation: Questions about the draft-ietf-mext-flow-binding-02 > Subject: Re: Questions about the draft-ietf-mext-flow-binding-02 > > >>> => This is already done today by routers very efficiently for load balancing >>> different flows. The whole thing can be done in hardware on the fast path of >>> course using hash tables ...etc. There is nothing new in this draft to >>> warrant concerns about performance. > >> Dosen't it need Deep Packet Inspection for flow type checking? > > => Not necessarily, it depends on how you defined the flow. If you only use > protocols, addresses, spi, or even port numbers that should cover almost all > of the use cases. Once the flow label is in use it would eliminate the need > for port numbers. You only need deep inspections if you're looking for payload > information, which I suspect will be a very rare case. But if that's needed > then you should pay the price for that. But most firewalls do deep inspections > today anyway. > > Hesham > > > >>> >>> Hesham >>> >>>> >>>> Wudi Ye >>>> >>>> 2009-7-2 >>> >>> ------ End of Forwarded Message From Vrparente@aol.com Fri Jul 3 10:35:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A38E28C2F5 for ; Fri, 3 Jul 2009 10:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] 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 d31V27FhOM3k for ; Fri, 3 Jul 2009 10:35:47 -0700 (PDT) Received: from imo-m27.mx.aol.com (imo-m27.mx.aol.com [64.12.137.8]) by core3.amsl.com (Postfix) with ESMTP id 6C84728C2DE for ; Fri, 3 Jul 2009 10:35:46 -0700 (PDT) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imo-m27.mx.aol.com (v107.10) with ESMTP id RELAYIN3-44a4e417611c; Fri, 03 Jul 2009 13:36:00 -0400 Received: from Vrparente@aol.com by imo-ma01.mx.aol.com (mail_out_v40_r1.5.) id l.c8a.3fc18d9b (37069); Fri, 3 Jul 2009 13:35:44 -0400 (EDT) Received: from Study ([216.246.69.52]) by cia-db05.mx.aol.com (v124.15) with ESMTP id MAILCIADB053-90cd4a4e416c202; Fri, 03 Jul 2009 13:35:41 -0400 From: "Victor Blake" To: References: In-Reply-To: Date: Fri, 3 Jul 2009 13:35:25 -0400 Message-ID: <006501c9fc04$a79be3d0$f6d3ab70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn4Is2s2KmgCa/ASteJrvCC8T+RSQD3+EsQ Content-Language: en-us x-cr-hashedpuzzle: BYaP CcQz CitZ Dml4 EI1H E/J3 F1PL H+TG Im2v MiIC Nc6p N5J/ Qn+E RXfA RrZF UvPj; 2; bQBlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA7AHYAcgBwAGEAcgBlAG4AdABlAEAAYQBvAGwALgBjAG8AbQA=; Sosha1_v1; 7; {A5B55ED6-5410-4390-AD2C-5EC503C3F0F0}; dgByAHAAYQByAGUAbgB0AGUAQABhAG8AbAAuAGMAbwBtAA==; Fri, 03 Jul 2009 17:35:20 GMT; TgBFAFgAVABFAFgAVAAyACAAQgBPAEYA x-cr-puzzleid: {A5B55ED6-5410-4390-AD2C-5EC503C3F0F0} X-AOL-IP: 64.12.78.136 Cc: vrparente@aol.com Subject: [MEXT] NEXTEXT2 BOF X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 17:35:48 -0000 To the Chair and authors of the NEXTEXT2 BOF in particular, I am pleased to see the consideration of the challenges of multi-layer mobility being considered here. I support the idea of considering, as the draft authors suggest below, Layer 2 mobility models (independent of L3 methods) - Because these could support models with either network based global mobility (such as PMIP) or client based mobility (CMIP) or independent local mobility without the "L3 methods." Although the latter might apparently seem to indicate no need to improvements in IETF, this is not necessarily the case. This is because there could be (I believe there is) demand for layered approaches to mobility wherein a service provider or entity might want to layer mobility on top of mobility. Although such methods could be made to work off the shelf, the demand for fast mobility (such as FMIP) could be difficult to accomplish without cross-layer signaling. Hybrid Layer 2/3 - I'm not sure how this differs from the above. If we assume an independent L2 model (CAPWAP, LWAP, L2TP, etc.) L3 would, by definition -- not "know" about the underlying L2 mobility. Is hybrid to mean that the layers MUST of necessity know to work together or CHOULD/SHOULD know. This might be the same as what I describe above. My only comment is that I think it is helpful to both support independent L2 from L3, but also allow cross-layer signaling to assist or expedite event handling Layer 3 (independent of L2 technologies) - Still quite valuable when being applied across multiple ran/wireline technologies - As the above comments suggest, even where there is "apparently" L3 independent, there could be underlying L2 mobility not visible to the L3 elements I think that that (additional) issues to consider are: 1. Bootstrap procedure for identifying or assisting with multi-layer signaling and multi-layer mobility 2. Multi-attached (multi-homed) devices 3. concurrent mobility 4. Layered (hybrid) approaches -- operator control (enable/disable) multi-layer signaling 5. Integration with network (versus device) mobility -- perhaps segregated by layers (this might be out of scope for this work) Victor Blake vrparente@aol.com ---------------------------------------------------------------------- Message: 1 Date: Sun, 28 Jun 2009 20:16:11 +0200 From: marcelo bagnulo braun Subject: [MEXT] NEXTEXT2: first draft of the bof description To: netext@ietf.org, mext , netlmm@ietf.org Cc: "Soininen Jonne \(NSN FI/Espoo\)" , Jari Arkko , netext-chairs@tools.ietf.org Message-ID: <4A47B36B.9030702@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, This is a first draft of the BOF description for your consideration. It is still very open so, feel free to comment on whether the proposed approach seems appropriate or not. NETEXT2 BOF description ----------------------- Proxy Mobile IPv6 (PMIP6) [RFC5213] is a network based mobility protocol built on Mobile IPv6 [RFC3775]. PMIP6 provides mobility to IP hosts without requiring any protocol enhancements or additional capabilities on the host. Current PMIP6 specification fully defines how to provide mobility support for mobile nodes with a single interface roaming in a PMIP6 domain. The goal of this BOF is gain understanding of how to support nodes with multiple interfaces (of possible different technologies) in a PMIP6 network. In particular, this BOF assumes the following scenario: We have a single PMIP6 domain that has deployed multiple access technologies and needs to support nodes that have multiple interfaces, possibly of different technologies. In particular, the following capabilities are needed: - Inter-technology handover support. The MN has initiated a communication over one interface and it needs to be able to move the established connection to a different interface of a possibly different technology. The reason for moving the communication to another interface is because of the MNs mobility and attaching via a different interface. Basically the ability to perform handovers that span different access technologies. - Multihoming support. The MN with multiple interfaces of possibly different technologies should be able to use them simultaneously to exchange data and manage the mobility of communications established through the different interfaces. - Flow mobility. A MN with multiple interfaces of possibly different technologies must be able to move a flow from one interface to another. Moreover, the MN should be able to inform the network through which interface it wishes to receive different types of flows. In order to provide the support for these capabilities, different approaches can be envisioned, namely: - L2 only approaches. In this type of approaches, the mechanisms to provide the required capabilities are fully L2 mechanisms and no modification of the IP layer is needed. - L3 only approaches. In this type of approaches, the mechanism to provide to required capabilities are located in the IP layer - Hybrid L2/L3 approaches. In this case, some mechanisms are located in L2 and other mechanisms are located in L3. Now, the different possible approaches vary greatly in their nature and resulting capabilities. To understanding the benefits and suitability of these alternatives, the requirements have to be properly defined and understood. The main goal of the BOF is understanding the need for work in the IETF in this area. In order to do so, during the BOF, we will attempt to: 1) Understand the applicable scenarios, and the problem statement related to those 2) Understand the restrictions and requirement imposed to solutions to address the problem statement and scenarios 3) Get an overview of the proposed solutions ************************************ From web-usrn@ISI.EDU Wed Jul 8 10:26:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15793A6A92 for ; Wed, 8 Jul 2009 10:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.109 X-Spam-Level: X-Spam-Status: No, score=-17.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 HeNOo1+3dBvU for ; Wed, 8 Jul 2009 10:26:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 05F633A69CE for ; Wed, 8 Jul 2009 10:26:22 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n68HP2Fl012575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Jul 2009 10:25:03 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n68HP1ZF012569; Wed, 8 Jul 2009 10:25:01 -0700 (PDT) Date: Wed, 8 Jul 2009 10:25:01 -0700 (PDT) Message-Id: <200907081725.n68HP1ZF012569@boreas.isi.edu> To: hesham@elevatemobile.com, rdroms@cisco.com, jari.arkko@piuha.net, julien.laganier.IETF@googlemail.com, marcelo@it.uc3m.es From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: rfc-editor@rfc-editor.org, julien.laganier.ietf@googlemail.com, mext@ietf.org Subject: [MEXT] [Technical Errata Reported] RFC5555 (1805) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 17:26:24 -0000 The following errata report has been submitted for RFC5555, "Mobile IPv6 Support for Dual Stack Hosts and Routers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5555&eid=1805 -------------------------------------- Type: Technical Reported by: Julien Laganier Section: 8 Original Text ------------- The IPv4 home address option described in Section 3.1.1 has been assigned value 29. This option is included in the mobility header described in [RFC3775]. The IPv4 address acknowledgement option described in Section 3.2.1 has been assigned value 29. This option is included in the mobility header described in [RFC3775]. Corrected Text -------------- The IPv4 home address option described in Section 3.1.1 has been assigned value 29. This option is included in the mobility header described in [RFC3775]. The IPv4 address acknowledgement option described in Section 3.2.1 has been assigned value 30. This option is included in the mobility header described in [RFC3775]. Notes ----- There's an error in the IANA section of the RFC: while both the IANA registry and the section of the RFC describing the option have the correct type value for the IPv4 address acknowledgement option, i.e., 30, the IANA section assigns type value 29 to both the IPv4 home address option and IPv4 address acknowledgement option. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5555 (draft-ietf-mext-nemo-v4traversal-10) -------------------------------------- Title : Mobile IPv6 Support for Dual Stack Hosts and Routers Publication Date : June 2009 Author(s) : H. Soliman, Ed. Category : PROPOSED STANDARD Source : Mobility EXTensions for IPv6 Area : Internet Stream : IETF Verifying Party : IESG From ryuji.wakikawa@gmail.com Mon Jul 13 00:28:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022243A6A8B for ; Mon, 13 Jul 2009 00:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 i693jiGlH7PI for ; Mon, 13 Jul 2009 00:28:18 -0700 (PDT) Received: from mail-px0-f185.google.com (mail-px0-f185.google.com [209.85.216.185]) by core3.amsl.com (Postfix) with ESMTP id 5F59E3A6CCB for ; Mon, 13 Jul 2009 00:28:18 -0700 (PDT) Received: by pxi15 with SMTP id 15so591609pxi.29 for ; Mon, 13 Jul 2009 00:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=KajEyP1q1offToIHFrEZVwTV0hxf3pZOFiKz4CCeygc=; b=CjNBEqJQ4X1fxe8ljEABfCKSZaaN6nHaltYKSvT/q9lpArLs20e/E9nIJxdlQrFUvZ jsrQDFFpnu25HGeGoBIEU6fIe7mSEHdIvQPm0qxLX6HA0QWsMucYFup2VekxL3scKjlc eNYYb38azovxa5FXkcs+GvsO6bKUCkpVG/GGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=CbU3FnuT3Mk49Bpepby/3BcYVcOFzFsCX/+kq7U7R9YyS+6SFQqps4KMNGUykCuq/q GCYbmhzFPWOInA1g1bKMoh2yag/TtMn4YTSAHYjDJQqDQb+3A7UGO/8ysxSJO1tbaT9c qq1xtuHrL4SOA/E+Bd6lkJ484+x9k2QXG7BDo= Received: by 10.115.95.20 with SMTP id x20mr8410256wal.40.1247470126587; Mon, 13 Jul 2009 00:28:46 -0700 (PDT) Received: from ?10.0.1.3? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id l37sm7969568waf.5.2009.07.13.00.28.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Jul 2009 00:28:44 -0700 (PDT) From: Ryuji Wakikawa To: Arnaud Ebalard In-Reply-To: <87hc0157z1.fsf@small.ssi.corp> References: <49EF37D8.2010408@it.uc3m.es> <49FAC1A2.7060206@it.uc3m.es> <87hc0157z1.fsf@small.ssi.corp> Message-Id: <0B51A76D-C67E-4614-A239-D77FC7BAB129@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 13 Jul 2009 00:28:42 -0700 X-Mailer: Apple Mail (2.935.3) Cc: Jari Arkko , mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-mip6-hareliability-04 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 07:28:20 -0000 Hi Arnaud, I submitted the new version (-05). Most of your comments were solved in this version. Please review it and confirms the update (see the inline messages, I list up the changes). On 2009/05/04, at 6:10, Arnaud Ebalard wrote: > Hi, > > Some comments on an inline version of draft-ietf-mip6-hareliability-04 > are provided below. > > From a general standpoint, I think the document is useful and provides > a sensible solution to the problem while taking into account the > various > difficulties and possible cases. > > That been said, at some point during the reading, I started > considering > that the most interesting review would be (as usual) from someone that > would have tried implementing *and testing* the protocol. Ryuji, are > you > aware of some tentative implementation or is it only a pure spec at > the > moment? > > Just a thought before starting: I understand the technical > difficulties > to implement the HA Virtual Switch functionality compared to the HA > Hard > Switch one but I think it is worth the effort both from a user (no > additional traffic, no need for additional computations, code and > logic), traffic and a management perspective. > >> Home Agent Hard Switch >> >> In the Home Agent Hard Switch, IPsec/IKE states >> synchronization is >> not required. The home agents are addressed by different IP >> addresses. When an active home agent fails, a mobile node will >> receive a notification (Home Agent Switch message [RFC-5142]) >> from >> a standby home agent, and send a Binding Update to the standby >> home agent. In order for the mobile node to receive the Home >> Agent Switch message securely from the standby home agent, the >> mobile node needs to establish an IPsec SA with both the active >> and the standby home agents beforehand. > > I understand the need for the SA to be available beforehand. Some > questions though: > > - I guess that the pair of SA is similar to the ones negotiated > between > the HA and the MN, i.e. that they reference the HoA, not the CoA, > don't they? > - When the MN moves and the CoA changes, the IKE_SA on both sides > (MN and standby HA) need to be updated. On the MN side, this is > feasible because the MIPv6 module is aware of the handover and of the > new CoA but because no exchange occur *directly* between the MN and > the standby HA, this is trickier on the standby HA side. Is it > expected that the handover information received from the state > synchronization with the active HA be used for that purpose? If this > is the case, it should be stated/described. If not, how is it done? > Full rekeying initiated by the MN? see section 9.5.3. Synchronizing State: K-bit treatment . . . . . . . . . 37 > >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> |# of Addresses |I| >> Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> >> | | >> >> + + >> . Home Agent >> Addresses . >> >> + + >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> . Mobility >> options . >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> >> >> Figure 7: Home Agent Switch Message >> >> IPsec Re-key (I) >> >> The IPsec re-key (I) bit is set to indicate that the mobile node >> SHOULD start an IPsec re-key with the home agent specified in >> the >> Home Agent Addresses field. This flag is used when a failed >> home >> agent recovers and needs to re-establish IPsec SA/IKE state >> with a >> mobile node. When this flag is set, the mobile node does not >> switch the home agent, but only re-key the SA. > > If I understand things correctly, when a Home Agent Switch message is > sent to a MN by a standby HA, it means that the MN should send a > binding > update to the standby HA (referenced in the Home Agent Addresses field > of the message), *except* when the I flag is set in the message > which in > that case means that the MN should perform an IKE negotiation with the > HA in the Home Agent Addresses field *but* not send a binding update > to > that HA. > > If that is correct, this breaks the semantic of the message. In that > case, having a simple flag changing the whole purpose of the message > looks like a bad idea. > > I reread RFC5142 (more precisely the end of section 5.1 and the > content > of section 6.1 describing how the MN should process the message). 2 > cases are described (from a MN perspective): > > - Home Agent Switch message is sent by a HA which is our current HA, > containing one or more addresses which should be considered in > order. In all cases, the MN is expected to send a de-registration > binding and send a BU to the first HA of the list. > - Home Agent Switch message is sent by a HA which is not our current > HA: > the message SHOULD contain one address, which is the address of the > sender of the message, which implies the MN should switch to the > sender of the message, i.e. send a BU. > > Current proposal in section 5.1.4 of the draft would basically add the > additional third case: > > - Home Agent Switch message is sent by a HA (standby or not based on > what is in 9.4.3, but chances are high is is the active HA) *with* I > flag set *and* an address different from the one of the sender. In > that case, the MN does not switch, it just setup an IPsec SA with the > addresses in the message. > > In the context of Hard Switch mechanism, I understand the need to have > the MN set up SA with the reborn HA (in order for that standby HA to > be > able to send switch messages later in the process). But IMO that > "Please > rekey" feature needs a different (MH) container. see the following sections. 5.1.4. Home Agent Rekey Message . . . . . . . . . . . . . . . 17 9.3. Sending Home Agent Rekey Messages . . . . . . . . . . . . 36 9.5.5. Receiving Home Agent Rekey message . . . . . . . . . . 38 > >> 9.4.2. IKE/IPsec pre-establishment to Home Agents >> >> After a mobile node obtains multiple home agent addresses, it needs >> to trigger multiple IKE exchanges with the multiple home agents >> selected from the home agent list. Since both IKEv1 and IKEv2 >> can be >> used to bootstrap Mobile IPv6, this solution does not introduce any >> new operations to co-operate with IKEv1 or IKEv2. It should >> initiate >> IKE for home agents as soon as home registration is complete. >> >> The mobile node MUST follow the standard IKEv2 exchange in the >> bootstrapping solution of the split scenario [RFC-5026]. Home >> Address configuration maybe also be included, if necessary, for the >> first IKE exchange. After its Home Address is assigned or approved >> by the first home agent, mobile node SHOULD register itself with >> the >> second home agent with IKE using the same Home Address. Therefore, >> no home address configuration should be used in the second IKEv2 >> procedure. Note that the mobile node only sends a Binding Update >> message to the first home agent. > > I have the feeling that this subsection should be extended in order to > describe what happens when a handover occurs, from an IKE standpoint > (IKE_SA management/update on both sides) between the reborn HA and the > MN. I added new sections 9.5.3. Synchronizing State: K-bit treatment . . . . . . . . . 37 9.5.5. Receiving Home Agent Rekey message . . . . . . . . . . 38 > >> 9.4.3. Receiving Home Agent Switch message >> >> A mobile node must follow the operation specified in [RFC-5142] >> when >> it receives a Home Agent Switch message. >> >> If the I-flag is set in the received Home Agent Switch message, the >> mobile node MUST re-key the SA with the home agent addresses stored >> in the Home Agent Addresses field. The mobile node MUST NOT change >> its active home agent when the I-flag is set. If the home agent >> address is not known from the bootstrapping described in >> Section 9.4.1, the mobile node MUST NOT start an IKE session with >> the >> unknown home agent. Instead, it SHOULD re-start home agent >> discovery >> again to update its home agent address information. >> >> When the mobile node receives a Home Agent Switch message without >> I-flag set, and if the message contains the IPv6 address of a >> standby >> home agent, it MUST select the standby home agent in the switch >> message as the active home agent and send a new Binding Update >> >> message to it. Note that the standby home agent address in the >> Home >> Agent Switch MUST be equal to the sender of the Home Agent Switch >> message. The standby Home agent expects the Binding Update as an >> acknowledgment of the Home Agent Switch message. The mobile node >> already has a pre-established SA with the standby home agents and >> should use that SA to send the Binding Update. If the address >> stored >> in the Home agent address field is different from the sender, the >> mobile node MUST send a binding update to the sender. > > I already provided some comments about the content of that section at > the beginning of the review. > >> 10. Security Considerations >> >> Since Mobile IPv6 operation requires ESP in transport mode between >> the mobile node and the home agent, we will discuss the ESP field >> synchronization issues between the mobile node and the redundant >> set >> of home agents. This synchronization is required only for Home >> Agent >> Virtual Switch mode. Most of fields should be synchronized based >> on >> [RFC-4301]. The ESP header has the following fields: >> >> SPI >> >> This field identifies the SAD at the receiver. >> >> The mobile node negotiates only one IPsec SA. Hence, the SPI >> value will remain unchanged upon home agent failover. >> >> Sequence Number >> >> This field is used for "anti-replay" feature of ESP. The >> transmitter must include this monotonically increasing number. >> The receiver may process the sequence number based on local >> policy. >> >> The mobile node and the redundant home agent set will have the >> same set of sequence numbers for transmit and receive. Hence, >> synchronization of the sequence number field is mandatory in >> this >> mode of operation. >> >> The SA1, SA2, SA3, SA4 could be synchronized between the home >> agents as these messages are not sent continuously. Moreover >> for >> the Binding Update case, if the mobile node is in the middle of >> sending a Binding Update to an active home agent for a binding >> refresh, and the active home agent is not available at that >> moment, the mobile node will not get any response from the >> active >> home agent. After a standby home agent becomes active, the >> mobile >> node will retry and it will receive the Binding Update from the >> mobile node with a sequence number that is +n from its last >> known >> sequence number for SA1. For the Binding Acknowledgment case >> (SA2), the standby home agent SHOULD add a random number to the >> last known sequence number over and above the replay window to >> ensure that the packet passes the replay check at the mobile >> node. >> The same applies to HoTi and HoT messages with SA3 and SA4. >> Note >> that this windowing of the sequence numbers for Mobile IPv6 >> signaling is only needed to cover the corner cases when Binding >> Update or HoTi is in-flight and the active home agent fails. >> >> The technique explained above should work for user data >> packets if >> ESP is used to encrypt user data traffic as well. The actual >> switchover time and the routing infrastructure convergence >> time is >> the only latency that the user may perceive. >> >> Initialization Vector >> >> Since the Initialization Vector will be delivered in each >> exchange >> between a mobile node and home agent, this field is not >> necessarily synchronized between home agents. >> >> Others >> >> Other fields should be synchronized based on RFC4301 [RFC-4301] >> >> In the Home Agent Hard Switch mode, the standby home agent needs to >> send a Home Agent Switch message using IPsec encryption. Since the >> mobile node has pre-established an IPsec SA with both the active >> and >> standby home agents, the standby home agent can send the message to >> the mobile node with the pre-established IPsec SA. > > I wonder if previous text really belongs to the "Security > Considerations" section. IMHO, it should be in a dedicated section. This text still stay in the Security Consideration section. I prefer keeping this in the security consideration, because it is just informational text. thanks ryuji > > Cheers, > > a+ > From root@core3.amsl.com Mon Jul 13 00:30:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A18173A6CD5; Mon, 13 Jul 2009 00:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713073001.A18173A6CD5@core3.amsl.com> Date: Mon, 13 Jul 2009 00:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mip6-hareliability-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 07:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Home Agent Reliability Protocol Author(s) : R. Wakikawa Filename : draft-ietf-mip6-hareliability-05.txt Pages : 47 Date : 2009-07-13 The home agent can be a single point of failure when Mobile IPv6 is operated in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-05.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-mip6-hareliability-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13002839.I-D@ietf.org> --NextPart-- From hesham@elevatemobile.com Mon Jul 13 03:41:03 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB36528C1DB for ; Mon, 13 Jul 2009 03:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 bGSRoOVmMUCs for ; Mon, 13 Jul 2009 03:41:03 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 1F6FD3A686D for ; Mon, 13 Jul 2009 03:41:02 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MQIyR-0007x9-2G for ; Mon, 13 Jul 2009 20:41:31 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 13 Jul 2009 20:41:25 +1000 From: Hesham Soliman To: mext Message-ID: Thread-Topic: New Version Notification for draft-ietf-mext-flow-binding-03 Thread-Index: AcoDpng5GTRa7ASFtUmlwVpIj5nJOQ== In-Reply-To: <20090713103929.6D5813A6B3F@core3.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: [MEXT] FW: New Version Notification for draft-ietf-mext-flow-binding-03 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 10:41:04 -0000 Folks, I just sbumitted the new version and contains all comments to date. Hesham ------ Forwarded Message > From: IETF I-D Submission Tool > Date: Mon, 13 Jul 2009 03:39:29 -0700 (PDT) > To: Hesham Soliman > Cc: Hesham Soliman , > , > Subject: New Version Notification for draft-ietf-mext-flow-binding-03 > > > A new version of I-D, draft-ietf-mext-flow-binding-03.txt has been successfuly > submitted by Hesham Soliman and posted to the IETF repository. > > Filename: draft-ietf-mext-flow-binding > Revision: 03 > Title: Flow Bindings in Mobile IPv6 and NEMO Basic Support > Creation_date: 2009-07-13 > WG ID: mext > Number_of_pages: 32 > > Abstract: > This document introduces extensions to Mobile IPv6 that allow nodes > to bind one or more flows to a care-of address. These extensions > allow multihomed nodes to instruct home agents and other Mobile IPv6 > entities to direct inbound flows to specific addresses. > > > > The IETF Secretariat. > > ------ End of Forwarded Message From root@core3.amsl.com Mon Jul 13 03:45:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DFBCF28C2CA; Mon, 13 Jul 2009 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713104501.DFBCF28C2CA@core3.amsl.com> Date: Mon, 13 Jul 2009 03:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-flow-binding-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 10:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Flow Bindings in Mobile IPv6 and NEMO Basic Support Author(s) : H. Soliman, et al. Filename : draft-ietf-mext-flow-binding-03.txt Pages : 32 Date : 2009-07-13 This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-03.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-mext-flow-binding-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13033929.I-D@ietf.org> --NextPart-- From Basavaraj.Patil@nokia.com Mon Jul 13 12:21:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7663A6EE8 for ; Mon, 13 Jul 2009 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, 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 zHqaJFpKQs5a for ; Mon, 13 Jul 2009 12:21:24 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D4D183A6EF6 for ; Mon, 13 Jul 2009 12:19:58 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6DJKIMF013984 for ; Mon, 13 Jul 2009 14:20:24 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 22:20:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 22:20:17 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 13 Jul 2009 21:19:34 +0200 From: To: Date: Mon, 13 Jul 2009 21:20:30 +0200 Thread-Topic: Revised I-D: Problems with the use of IPsec as the security protocol for Mobile IPv6 Thread-Index: AcoD7VZFF+dWkoY7ScWRuim94dh04gAAaXQi Message-ID: In-Reply-To: <20090713190236.4DE4C28C37B@core3.amsl.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2009 19:20:17.0690 (UTC) FILETIME=[F4C177A0:01CA03EE] X-Nokia-AV: Clean Subject: [MEXT] Revised I-D: Problems with the use of IPsec as the security protocol for Mobile IPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 19:21:25 -0000 FYI, A new version of I-D, draft-patil-mext-mip6issueswithipsec-01.txt has been successfuly submitted by Basavaraj Patil and posted to the IETF repository. Filename: draft-patil-mext-mip6issueswithipsec Revision: 01 Title: Problems with the use of IPsec as the security protocol fo= r Mobile IPv6 Creation_date: 2009-07-13 WG ID: Independent Submission Number_of_pages: 15 Abstract: Mobile IPv6 as specified in RFC3775 relies on IPsec for security. An IPsec SA between the mobile node and the home agent provides security for the mobility signaling. Use of IPsec for securing the data traffic between the mobile node and home agent is optional. This document analyses the implications of the design decision to mandate IPsec as the default security protocol for Mobile IPv6 and consequently Dual-stack Mobile IPv6 and recommends revisiting this decision in view of the experience gained from implementation and adoption in other standards bodies. From root@core3.amsl.com Mon Jul 13 14:00:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9421628C37E; Mon, 13 Jul 2009 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713210001.9421628C37E@core3.amsl.com> Date: Mon, 13 Jul 2009 14:00:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-04.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 21:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : D. Johnson, et al. Filename : draft-ietf-mext-rfc3775bis-04.txt Pages : 175 Date : 2009-07-13 This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-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-mext-rfc3775bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13134949.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Mon Jul 13 14:03:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E80F3A67AA for ; Mon, 13 Jul 2009 14:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] 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 LIVM0C3vl1jS for ; Mon, 13 Jul 2009 14:03:11 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 4C9703A67F0 for ; Mon, 13 Jul 2009 14:03:04 -0700 (PDT) Received: by ewy26 with SMTP id 26so2848781ewy.37 for ; Mon, 13 Jul 2009 14:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :references:x-mailer; bh=4rC6691U0Mjkzoo3MFw6aNuN4LERZNtkSzm0Slq+j+0=; b=Ij0iLYEeyg/lYFYMpi+P5Ks9czCsOJ/V1ELoeCtuXvwS0EaiCcIqs4/3izySLP2XDw N3URNHmn4RPNEXxVg6qln1f94o2AetrLa8oipt7XqZitVgo0LubD42Ni2F+8f83KX4Tq 54ya/vkKY2uLujdy/Pe5f147Z3Cct4Jdu0BTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:references:x-mailer; b=L239SmezFo5YWZGHWHrZbJuSV5rC4UHJjYUvFbYXZrj5naDPoTzdTpcBh7qMDZZXG+ KjMmI7pNhNhA8lD/qd1tQZgdJltpqGbsnXJ2WxQQBBq7xxivJ0VVMDw+DMEJ6RdiSF4E G/1O51385MKTCyMd5/Cpc1pO4d0dmXIcXQui8= Received: by 10.210.118.14 with SMTP id q14mr5609763ebc.46.1247519008409; Mon, 13 Jul 2009 14:03:28 -0700 (PDT) Received: from a88-114-66-140.elisa-laajakaista.fi (a88-114-66-140.elisa-laajakaista.fi [88.114.66.140]) by mx.google.com with ESMTPS id 7sm2567635eyb.5.2009.07.13.14.03.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Jul 2009 14:03:27 -0700 (PDT) Message-Id: <19AA2C79-FDF2-4EA4-8819-E2A1AB6F2D83@gmail.com> From: jouni korhonen To: mext Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 00:03:26 +0300 References: <20090713204502.1CE2A3A6D53@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) Subject: [MEXT] Revised I-D: draft-korhonen-mext-mip6-altsec-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 21:03:12 -0000 FYI > From: Internet-Drafts@ietf.org > Date: July 13, 2009 11:45:02 PM GMT+03:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-korhonen-mext-mip6-altsec-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Transport Layer Security-based Mobile IPv6 > Security Framework for Mobile Node to Home Agent Communication > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-mext-mip6-altsec-01.txt > Pages : 24 > Date : 2009-07-13 > > Mobile IPv6 signaling between the mobile node and home agent is > secured using IPsec. The security association between a mobile node > and the home agent is established using IKEv1 or IKEv2. The security > model specified for Mobile IPv6, which relies on IKE/IPsec, requires > interaction between the Mobile IPv6 protocol part of the IP stack and > the IKE/IPsec part of the IP stack. Implementation and deployment > concerns exist with such a security architecture. This document > proposes an alternate security framework, which relies on Transport > Layer Security for establishing keying material and other parameters > required to protecting Mobile IPv6 signaling and data traffic between > the mobile node and home agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-mext-mip6-altsec-01.txt > > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From wassim.haddad@ericsson.com Mon Jul 13 14:51:28 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE8228C71A for ; Mon, 13 Jul 2009 14:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 0Ud3ePDZgAC3 for ; Mon, 13 Jul 2009 14:51:28 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 928D228C72F for ; Mon, 13 Jul 2009 14:49:30 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n6DLnhMq030172 for ; Mon, 13 Jul 2009 16:49:44 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 16:48:35 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0403.AC488906" Date: Mon, 13 Jul 2009 16:48:34 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF0582BE6D@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MobiSoc: draft-haddad-mext-mobisoc-00.txt Thread-Index: AcoEA6vDM/BAikSWQbGokPxPKTdgYw== From: "Wassim Haddad" To: X-OriginalArrivalTime: 13 Jul 2009 21:48:35.0610 (UTC) FILETIME=[AC544FA0:01CA0403] Cc: Wassim Haddad Subject: [MEXT] MobiSoc: draft-haddad-mext-mobisoc-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 21:51:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0403.AC488906 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, An updated version of the MobiSoc draft: http://www.ietf.org/internet-drafts/draft-haddad-mext-mobisoc-01.txt Comments are welcome! Regards, Wassim H. ------_=_NextPart_001_01CA0403.AC488906 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MobiSoc: draft-haddad-mext-mobisoc-00.txt

Hi all,

An updated version of the MobiSoc = draft:

http://www.ietf.org/internet-drafts/draft-haddad-mext-mobi= soc-01.txt

Comments are welcome!


Regards,

Wassim H.

------_=_NextPart_001_01CA0403.AC488906-- From ryuji.wakikawa@gmail.com Mon Jul 13 15:17:11 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BF328C6A7 for ; Mon, 13 Jul 2009 15:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 I4y0lVp-JGkd for ; Mon, 13 Jul 2009 15:17:09 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 1BA7F28C662 for ; Mon, 13 Jul 2009 15:17:08 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so644142eye.65 for ; Mon, 13 Jul 2009 15:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=YryUJliIKdWNbx+5K7QAAg1reiTk9JC7HF+IIX68/GQ=; b=IzEPljNAmKrVwP+lm/xVdSV4v/Q3mxZPY5cMqLb1l5rCb/sNXFurgyT9kNeF0DjUL2 E9pmM/AyHbEDqaN+B9manBoFmNYqi5MA4pdCFzfa5A7lSlV2tBfIH35TERLjahZ+uWsY txoWoH+1cqBm0/1J2zIwS9C1xYHEUZdPVrPBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; b=eSJVoIuLLQYyLbACDh9hRpmATKS+0VKKLPTg3zYBUuaincf9zIDgQNueb4M/6TX9fR bkk1d4sdQZ/4vACM3OR9LK4UQInbW4fV50F9jAZb0YxL/jnNpNfs6IuTpAB/qcGWzFmC i8POgtV+W+W7j2YkWSWaEYyz/mix02G7cDtQg= MIME-Version: 1.0 Received: by 10.216.74.14 with SMTP id w14mr1556198wed.153.1247523457100; Mon, 13 Jul 2009 15:17:37 -0700 (PDT) Date: Mon, 13 Jul 2009 15:17:37 -0700 Message-ID: <84840efa0907131517w3de9530ew1a898530d7d4d5ea@mail.gmail.com> From: Ryuji Wakikawa To: mext Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: zhenkai@CS.UCLA.EDU, lixia@CS.UCLA.EDU Subject: [MEXT] global HAHA specification is ready (extension of HA reliability protocol) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 22:17:11 -0000 Hi all, We submitted a revised version of the global HAHA protocol specification. All the protocol specifications for the global HAHA are now added on top of the Home Agent Reliability protocol. http://tools.ietf.org/search/draft-wakikawa-mext-global-haha-spec-01 The original GlobalHAHA is also updated by Pascal. http://tools.ietf.org/html/draft-thubert-mext-global-haha-01 thanks ryuji ps. Allow me to announce this CFP. Infocom2010 deadline is approaching. ***************************** **** IEEE INFOCOM 2010 **** **** **** **** CALL FOR PAPERS **** ***************************** The 29th Annual Conference of the IEEE Communications Society March 14 -19, 2010, San Diego, California USA http://www.ieee-infocom.org/2010 The IEEE INFOCOM 2010 conference seeks papers describing significant research contributions to the field of computer and data communication networks. We invite submissions on network architecture, design, implementation, operations, analysis, measurement, performance, and simulation. Topics of interest include, but are not limited to, the following: * Ad hoc mobile networks * Addressing & location management * Broadband access technologies * Capacity planning * Cellular & broadband wireless nets * Cognitive radio networking * Congestion control * Content distribution * Cross layer design & optimization * Cyber-physical computing & networking * Denial of service * Delay/disruption tolerant networks * Future Internet design * Implementation & experimental testbeds * Middleware support for networking * Mobility models & systems * Multicast & anycast * Multimedia protocols * Network applications & services * Network architectures * Network control * Network management * Network simulation & emulation * Novel network architectures * Optical networks * Peer-to-peer networks * Performance evaluation * Power control & management * Pricing & billing * Quality of service * Resource allocation & management * Routing protocols * Scheduling & buffer management * Security, trust, & privacy * Self-organizing networks * Sensor nets & embedded systems * Service overlays * Social computing * Switches & switching * Topology characterization & inference * Traffic measurement and analysis * Traffic engineering & control * Virtual & overlay networks * Web services & performance * Wireless mesh networks & protocols Important Dates: * Abstract due: July 24, 2009 * Full paper due: July 31, 2009 * Notification of acceptance: November 21, 2009 Organizing Committee: General Chair: Giridhar Mandyam (Qualcomm, USA) Vice Chair: Cedric Westphal (Docomo Labs, USA) Technical Program Co-Chairs: Mooi Choo Chuah (Lehigh University, USA), Reuven Cohen (Technion, Israel) and Guoliang Xue (Arizona State University, USA) Standing Committee Chair: Harvey Freeman (HAF Consulting, Inc., USA) From jonne.soininen@nsn.com Tue Jul 14 03:16:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0116C3A6C53 for ; Tue, 14 Jul 2009 03:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.976 X-Spam-Level: X-Spam-Status: No, score=-4.976 tagged_above=-999 required=5 tests=[AWL=1.623, BAYES_00=-2.599, 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 0wX+zO3TreqV for ; Tue, 14 Jul 2009 03:16:21 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 541E53A6946 for ; Tue, 14 Jul 2009 03:16:21 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6E83PDW018857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Jul 2009 10:03:25 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6E83Lj1029335 for ; Tue, 14 Jul 2009 10:03:25 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 10:03:23 +0200 Received: from 10.162.72.229 ([10.162.72.229]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.159.32.11]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Jul 2009 08:03:23 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 14 Jul 2009 11:03:20 +0300 From: "Soininen, Jonne (NSN - FI/Espoo)" To: mext Message-ID: Thread-Topic: Binding Revocation Draft - status? Thread-Index: AcoEWY0jjG5rjnZLFkuI+e6zIRGU5Q== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jul 2009 08:03:23.0871 (UTC) FILETIME=[8F723EF0:01CA0459] Subject: [MEXT] Binding Revocation Draft - status? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 10:16:23 -0000 Hi, I was wondering what is the status of the binding revocation draft. I saw the last mail from Julien from ca. Middle June, but it has been fairly quiet on that front after that. If somebody could just quickly recap what are the next steps for the draft. Thank you in advance! Cheers, Jonne. -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com From julien.laganier.ietf@googlemail.com Tue Jul 14 09:13:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1943E28C387 for ; Tue, 14 Jul 2009 09:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 VrIsHUxAAQWf for ; Tue, 14 Jul 2009 09:13:03 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2012628C346 for ; Tue, 14 Jul 2009 09:13:02 -0700 (PDT) Received: by fxm18 with SMTP id 18so2915348fxm.37 for ; Tue, 14 Jul 2009 09:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v/QCPYTFwOZGqmJZWYXSbeRIjnDShpLWG/RED3rNKCs=; b=tmCtFUCta3rFipg+sdV8rx+p3B6N00XgLOD4NjkvKSzf5rFyq0Zil8h6KOfy85mTDJ 0A8obeA+A4FoxKtv3/l603lBPe1382ydpSlqtcn/EeC5TPFQ8jgOCNQ84tEWas4Dq5FH oJOhW7llQnF+avzNuLIAslTjtTKtZeCkf/ONE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lCECQ6291LwU6CujXrOQpGARR235l5oorjlcWwQJtS25lSD3fd5ZRXIO+Tthx9gaCS C/B6y0pExMKODcW+QT+C4D5IbKhYPZ7CfJvKM+ah8n0jGgB3JY2SFjaWh1ffGs59Y9zx UfBU5wAz5HL4KTa5f26ewgb1ijiVfu6r1AMeg= MIME-Version: 1.0 Received: by 10.204.57.18 with SMTP id a18mr6574580bkh.19.1247587606921; Tue, 14 Jul 2009 09:06:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Jul 2009 09:06:46 -0700 Message-ID: <7ad6d6db0907140906y73e8a2afnea905d001c3e14d2@mail.gmail.com> From: Julien Laganier To: "Soininen, Jonne (NSN - FI/Espoo)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jari Arkko , mext Subject: Re: [MEXT] Binding Revocation Draft - status? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 16:13:04 -0000 Hello Jonne, I think we are awaiting an AD review from Jari. I have also just sent an email to IESG secretary so that the draft is put in 'Publication Requested" state in the datatracker. --julien On Tue, Jul 14, 2009 at 1:03 AM, Soininen, Jonne (NSN - FI/Espoo) wrote: > Hi, > > I was wondering what is the status of the binding revocation draft. I saw > the last mail from Julien from ca. Middle June, but it has been fairly quiet > on that front after that. > > If somebody could just quickly recap what are the next steps for the draft. > > Thank you in advance! > > Cheers, > > Jonne. > > -- > Jonne Soininen > Nokia Siemens Networks > > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nsn.com > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From marcelo@it.uc3m.es Tue Jul 14 12:41:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC8E3A69A5 for ; Tue, 14 Jul 2009 12:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 h9qEsqMBOTsC for ; Tue, 14 Jul 2009 12:41:24 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B38B83A6942 for ; Tue, 14 Jul 2009 12:41:23 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (8.pool85-53-137.dynamic.orange.es [85.53.137.8]) by smtp02.uc3m.es (Postfix) with ESMTP id 245816BA2A4 for ; Tue, 14 Jul 2009 21:39:29 +0200 (CEST) Message-ID: <4A5CDEF0.5050806@it.uc3m.es> Date: Tue, 14 Jul 2009 21:39:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16764.001 Subject: [MEXT] first version of the agenda X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 19:41:25 -0000 Hi, This is the agenda we have so far --------------------------------------------------------------------- MEXT meeting agenda - IETF75 TUESDAY, July 28, 2009 1520-1700 Afternoon Session II --------------------------------------------------------------------- 1. Blue sheets, scribe, agenda bashing Chairs - 5 min 2. Next steps with some open issues - RFC3775bis - Charter description of flow bindings work Chairs 15 min 3. Flow binding transport http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-07 George - 15 min 4. Flow binding bit pattern format http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00 George - 10 min 5. Issues with MIP6 deployment Suresh - 10 min 6. Present the implementation issues with IPsec/IKEv2 w.r.t DSMIP6 http://tools.ietf.org/html/draft-patil-mext-mip6issueswithipsec-01 Charlie/Basavaraj - 15 Mins 7. Alternate security solution http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec-01 (Jouni Korhonen) - 15 Mins 8. HA reliability http://tools.ietf.org/html/draft-ietf-mip6-hareliability-05 Ryuji - 10 min ---------------------------------------------------------------------- From tsirtsis@googlemail.com Wed Jul 15 03:52:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F9B3A6B15 for ; Wed, 15 Jul 2009 03:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 uv1i9D8YghCT for ; Wed, 15 Jul 2009 03:52:35 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 27A0B3A68B9 for ; Wed, 15 Jul 2009 03:52:34 -0700 (PDT) Received: by bwz28 with SMTP id 28so1330502bwz.37 for ; Wed, 15 Jul 2009 03:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WDqHx1c5h/PjA8HNTSLHNNsq9sdCnnWOLe81jtfh+oE=; b=BhOyt6zaNCs+rAY3cOQEVipPms0/0NGhDevhX4Fu3Km8fAELYrF1LkodgnwynZKbfa fgx2xYmWL+IHktdU3hQ/z76CTBSxh0x6mnSfXHFOaqtIRoQWKODlrpqh2YYgP39PJkwp xumxF3VkMWQMb+Zv2hVOOETBmvCRliU2CVwhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xqgUFE0y61WONwhVWXVfVgxKo3QeF3YoHnC+0L31eksUN8YTzE3wV7xtEmYNzBk/KK onl6DQd8Ve4DRIJkNR8OHfBUFynwgyKnPW73h9kl4U3D+h9g5/p6fIMo2EfagFwD4PBn esmgWCRCmjRPTXRmtxUyuKcLylfQlL0/J7prs= MIME-Version: 1.0 Received: by 10.223.105.72 with SMTP id s8mr3814785fao.9.1247655101100; Wed, 15 Jul 2009 03:51:41 -0700 (PDT) In-Reply-To: <4A5CDEF0.5050806@it.uc3m.es> References: <4A5CDEF0.5050806@it.uc3m.es> Date: Wed, 15 Jul 2009 11:51:41 +0100 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] first version of the agenda X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 10:52:36 -0000 Hi Marcelo, I think for item 3 below you have the wrong reference. It should be :http://tools.ietf.org/id/draft-ietf-mext-flow-binding-03.txt George On Tue, Jul 14, 2009 at 8:39 PM, marcelo bagnulo braun wrote: > Hi, > > This is the agenda we have so far > > --------------------------------------------------------------------- > MEXT meeting agenda - IETF75 > > TUESDAY, July 28, 2009 > 1520-1700 Afternoon Session II > --------------------------------------------------------------------- > > 1. Blue sheets, scribe, agenda bashing > Chairs - 5 min > > 2. Next steps with some open issues > - RFC3775bis > - Charter description of flow bindings work > Chairs 15 min > > 3. Flow binding transport > http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-07 > George - 15 min > > 4. Flow binding bit pattern format > http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00 > George - 10 min > > 5. Issues with MIP6 deployment > Suresh - 10 min > > 6. Present the implementation issues with IPsec/IKEv2 w.r.t DSMIP6 > http://tools.ietf.org/html/draft-patil-mext-mip6issueswithipsec-01 > Charlie/Basavaraj - 15 Mins > > 7. Alternate security solution > http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec-01 > (Jouni Korhonen) - 15 Mins > > 8. HA reliability > http://tools.ietf.org/html/draft-ietf-mip6-hareliability-05 > Ryuji - 10 min > > > ---------------------------------------------------------------------- > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From jeanmichel.combes@gmail.com Wed Jul 15 05:30:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EAF83A687E for ; Wed, 15 Jul 2009 05:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 4Pz0Vwe6dBNp for ; Wed, 15 Jul 2009 05:30:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id DC86C3A6BE5 for ; Wed, 15 Jul 2009 05:30:14 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so784767fga.18 for ; Wed, 15 Jul 2009 05:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=AhdstzQmvqhS9l43kMWxznvVJ3YPDqDIGq2m5h7+5XI=; b=p6BAb02ITzGYd0YSd9VpJCOsL1n7/SQrtI4YBecTCARA7IO7yk2ImAs91cThQa4dyw 3IhlvNJ/CMBccFil8ytWzviazKI4Ck+ZziqJ3r/pUgz3DtOk8zLfYAdAnGWznTNKRtgf V5UxiU4gD+fzgRtCddKzyzy77OijAAv+DK02c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Ua0frO2pHBTI+xY2cypicJ6fPgJMGZVPeYF12Izbtt89yExDvBNNr4IBFtMX3I9Gix WH1o6Oxw4lRrcAwl95rVz51igf6K+qROaeXrIgwR3FQ2YGWSnAl8LTvGHMRbI2zLUUdg cU8PSKinNFV+662IWr1Kti7Q7jbT+gXvMmeJk= MIME-Version: 1.0 Received: by 10.86.27.17 with SMTP id a17mr5105602fga.17.1247661025224; Wed, 15 Jul 2009 05:30:25 -0700 (PDT) Date: Wed, 15 Jul 2009 14:30:25 +0200 Message-ID: <729b68be0907150530q72e0ddf8l1e85a1b75e14d758@mail.gmail.com> From: Jean-Michel Combes To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: [MEXT] (Quick) Review of draft-patil-mext-mip6issueswithipsec [was: Revised I-D: Problems with the use of IPsec as the security protocol for Mobile IPv6] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 12:30:16 -0000 Hi, Here is my first (quick, especially on the section 6 where some points must be checked more deeply) review of this draft. At first, the new version of this draft is clearly more detailed than the previous one, thanks a lot! Comments: o Section 4 Regarding the interaction between MIPv6 and IPsec/IKEv2, I agree that IPsec/IKEv2 must be "MIPv6 aware" but the main reason is not explained in the draft. This last one is that, when doing Route Optimization, a packet sent by a MN must follow this process (I omit the process for a packet received/sent by the CN and a packet received by a MN: the goal is just to illustrate the interaction between MIPv6 and IKEv2): 1. MIPv6 daemon builds of the IP packet with the HoA in the IP Header and the CoA in Home Address Destination Option 2. IPsec daemon applies IPsec policy 3. MIPv6 daemon switches the HoA and the CoA and sends the packet So, if a MN wants to do RO with a CN and wants to set up an IPsec connection with this CN, no choice: IKEv2 must interact with MIPv6. The arguments described in this section, IMHO, should not be more valid if an API would be standardized between the MIPv6 daemon and the IPsec/IKEv2 daemon (cf. my comments for the section 6). o Section 5 - Issue (1) Based on RFC4294 and the draft RFC4294bis, IPsec, and specially ESP, is mandatory on every IPv6 node. Based on RFC4294 and the draft RFC4294bis, when on-demand creation of Security Associations (SAs) is required, automated keying is mandatory on every IPv6 node. - Issue (2) The IPsec policy for MIPv6 is set up on dedicated entities so I must admit I don't understand this issue. - Issue (3) I agree that today there is a lack of figures regarding how many IPsec SAs a HA can maintain. - Issue (4) Cf. my comments about the section 6. - Issue (5) Cf. my comments about Issue (1) - Issue (6) Cf. my comments about the section 6. - Issue (7) IMHO, this argument is not a technical one and could generate, at middle-long term, interoperability issues (e.g. HA-HA mechanism, HA reliability architecture, HMIPv6 scenarios, etc.). - Issue (8) The problem doesn't exist anymore (i.e. Traffic Selector have been modified to set up MIPv6 policy). BTW, I know at least another application using IPsec. - Issue (9) Cf. my comments about the section 6. - Issue (10) Only the MIPv6 signaling is secured with IPsec and there is no encapsulation (i.e. transport mode). Regarding IKEv2 messages, the number of messages depends on the authentication method but IKEv2 exchanges are only for the SAs creation or renewal. o Section 6 - Triggering IKEv2 on the MN For the MIPv6 bootstrapping, IMHO, IKEv2 could be launched without a needed SPD, exactly as we do today when we set up a VPN to our company. Regarding the SPD update, again, this is more or less the same scenario with a VPN connection: our laptop doesn't know in advance which internal address will be provided by the IPsec Security Gateway and so will have to update the SPD once this internal address is provided. - Instructing IKEv2 to ask for the MN HoA/prefix IMHO, this could be configured in the IKEv2 config file. Now, I am not sure that IKEv2 implementations support today the MIP6_HOME_PREFIX Attribute - Providing the MN prefix to the IKEv2 daemon Same as above, IMHO, that could be configured in the IKEv2 config file. - Registering the MN's FQDN in DNS This issue is the same with the VPN scenario (i.e. once an internal IP address has been provided, the DNS should be updated with this one) - Providing the Home Network Prefix to the MIP6 application Here, I must admit that maybe there is an issue and so an standardized API between the MIPv6 daemon and the IKEv2 daemon may be needed. - SPD Entry for the HoA on the MN side Same issue as the VPN scenario (cf. above) - SPD Entry for the HoA on the HA side Same issue as the VPN scenario (cf. above) BTW, a critical point is not mentioned: the PAD must be updated also. - The K bit I agree that "K bit" is an issue and an API must exist - UDP encapsulation of DSMIP6 signaling Cf. my comments about section 4 Best regards. JMC. 2009/7/13 =A0: > > FYI, > > > A new version of I-D, draft-patil-mext-mip6issueswithipsec-01.txt has bee= n > successfuly submitted by Basavaraj Patil and posted to the IETF repositor= y. > > Filename: =A0 =A0 =A0 =A0draft-patil-mext-mip6issueswithipsec > Revision: =A0 =A0 =A0 =A001 > Title: =A0 =A0 =A0 =A0 =A0 Problems with the use of IPsec as the security= protocol for > Mobile IPv6 > Creation_date: =A0 2009-07-13 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 15 > > Abstract: > Mobile IPv6 as specified in RFC3775 relies on IPsec for security. =A0An > IPsec SA between the mobile node and the home agent provides security > for the mobility signaling. =A0Use of IPsec for securing the data > traffic between the mobile node and home agent is optional. =A0This > document analyses the implications of the design decision to mandate > IPsec as the default security protocol for Mobile IPv6 and > consequently Dual-stack Mobile IPv6 and recommends revisiting this > decision in view of the experience gained from implementation and > adoption in other standards bodies. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From marcelo@it.uc3m.es Wed Jul 15 07:39:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9F33A6B7D for ; Wed, 15 Jul 2009 07:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, 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 zRNo5GwRsfz3 for ; Wed, 15 Jul 2009 07:39:17 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CA1BD3A6CED for ; Wed, 15 Jul 2009 07:39:03 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 54F926C1023; Wed, 15 Jul 2009 15:41:22 +0200 (CEST) Message-ID: <4A5DDC83.50003@it.uc3m.es> Date: Wed, 15 Jul 2009 15:41:23 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: George Tsirtsis References: <4A5CDEF0.5050806@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16764.006 Cc: mext Subject: Re: [MEXT] first version of the agenda X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 14:39:19 -0000 right, ben already pointed this to me. I have corrected in the posted agenda and i was hoping it would pass unnoticed... George Tsirtsis escribió: > Hi Marcelo, > > I think for item 3 below you have the wrong reference. It should be > :http://tools.ietf.org/id/draft-ietf-mext-flow-binding-03.txt > > George > > On Tue, Jul 14, 2009 at 8:39 PM, marcelo bagnulo > braun wrote: > >> Hi, >> >> This is the agenda we have so far >> >> --------------------------------------------------------------------- >> MEXT meeting agenda - IETF75 >> >> TUESDAY, July 28, 2009 >> 1520-1700 Afternoon Session II >> --------------------------------------------------------------------- >> >> 1. Blue sheets, scribe, agenda bashing >> Chairs - 5 min >> >> 2. Next steps with some open issues >> - RFC3775bis >> - Charter description of flow bindings work >> Chairs 15 min >> >> 3. Flow binding transport >> http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-07 >> George - 15 min >> >> 4. Flow binding bit pattern format >> http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00 >> George - 10 min >> >> 5. Issues with MIP6 deployment >> Suresh - 10 min >> >> 6. Present the implementation issues with IPsec/IKEv2 w.r.t DSMIP6 >> http://tools.ietf.org/html/draft-patil-mext-mip6issueswithipsec-01 >> Charlie/Basavaraj - 15 Mins >> >> 7. Alternate security solution >> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec-01 >> (Jouni Korhonen) - 15 Mins >> >> 8. HA reliability >> http://tools.ietf.org/html/draft-ietf-mip6-hareliability-05 >> Ryuji - 10 min >> >> >> ---------------------------------------------------------------------- >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > From behcetsarikaya@yahoo.com Wed Jul 15 09:54:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1143A6F30 for ; Wed, 15 Jul 2009 09:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] 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 Va1-y6hdbG0w for ; Wed, 15 Jul 2009 09:54:45 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 3CD363A6F44 for ; Wed, 15 Jul 2009 09:54:31 -0700 (PDT) Received: from [68.142.237.89] by n9.bullet.re3.yahoo.com with NNFMP; 15 Jul 2009 15:52:16 -0000 Received: from [67.195.9.82] by t5.bullet.re3.yahoo.com with NNFMP; 15 Jul 2009 15:52:16 -0000 Received: from [67.195.9.109] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2009 15:52:16 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 15 Jul 2009 15:52:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 319890.37027.bm@omp113.mail.gq1.yahoo.com Received: (qmail 60337 invoked by uid 60001); 15 Jul 2009 15:51:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247673088; bh=In0r7Q3hJpUx6DW9GnwqNFO8AvdD7UvaxTb2xSeSy2k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TtwbOlGWcsclD+V/+pKIqPf3ExmwK2YkjVkWcqv2vgLu/Aenw2v1+4XXUJJyJSTKRKh4l5HjZVzXsbzvurPGNsm3/dtnUF8s9Ce0ulbTgP9qS7IGbcMlkNBXoGobumWb77lCRvVuAToPgVWRAjh2Dz3zh7Cn9JsKoACYKqTbzF4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=okCSCg34KcNGzSlcdNSe8+kVgVoiGEPjeY/TBjF+3DvGTQCqgUnzH0zY5nV3EA2zTHpVF2vlwV8zAbg2i1Mj9q2Y4WSrxdeR3ZkbpTHz1FGLaEm9MSjR0GYiX58+Ivu3El5Fffivtg3VLXBL6MGrjkiWtqRjN/4GjMIxwCU8iys=; Message-ID: <972584.42365.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: WfquzUAVM1lDT7rYuRKQLXOqbQLe5qG_rK5JzkbZSRCN9c6D1plfWVgOCYY1fUwLNrkwKQGZ45qkIiEn6r0YbFmC49V7V6JxYNYRh_.03sREAbW9mMvWZUYy_BqApKjWYLfOin1NprI2KVdppT3lRoORD7M6SHqbrUpOImOW8US.HdvyQfW8EfO5aEPcWEpY_Vg22Xkhyu7neRw8F.Q_KmlqPfNlWU4LI3HwMGXWVtJNtQgVsZqZh792_Fn_xPjKxKIrX_bFtkua5eaDyHXVlXWShdb5ipzOmNVPtXe63E1e3RUlDZQLad0SVWnAsoMF55qWfwAFCNxRWwDL0KIjmieine0VsxrCZ1T1_eQ- Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Wed, 15 Jul 2009 08:51:27 PDT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 Date: Wed, 15 Jul 2009 08:51:27 -0700 (PDT) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] Fw: New Version Notification for draft-xia-mext-hioptv4-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:54:46 -0000 Hello All,=0A=A0 We have submitted a draft on configuring RFC 5555 (DSMIP) = hosts using DHCPv4. The need for such a draft was pointed out by our AD in = his message at:=0Ahttp://www.ietf.org/mail-archive/web/mext/current/msg0272= 9.html=0A=0APlease see the past discussions around March 3, 2009 at http://= www.ietf.org/mail-archive/web/mext/current/mail35.html.=0A=0A=A0 Please sen= d your comments on the list.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Forwar= ded Message ----=0A> From: IETF I-D Submission Tool = =0A> To: xiayangsong@huawei.com=0A> Cc: sarikaya@ieee.org=0A> Sent: Sunday,= June 7, 2009 3:25:18 PM=0A> Subject: New Version Notification for draft-xi= a-mext-hioptv4-00=0A> =0A> =0A> A new version of I-D, draft-xia-mext-hioptv= 4-00.txt has been successfuly =0A> submitted by Frank Xia and posted to the= IETF repository.=0A> =0A> Filename:=A0=A0=A0 draft-xia-mext-hioptv4=0A> Re= vision:=A0=A0=A0 00=0A> Title:=A0=A0=A0 =A0=A0=A0 DHCPv4 Options for Home I= nformation Discovery in Dual Stack MIPv6=0A> Creation_date:=A0=A0=A0 2009-0= 6-07=0A> WG ID:=A0=A0=A0 =A0=A0=A0 Independent Submission=0A> Number_of_pag= es: 8=0A> =0A> Abstract:=0A> This document defines DHCPv4 options for dynam= ic discovery of home=0A> network information in Dual Stack Mobile IPv6.=A0 = New DHCPv4 options=0A> are defined which allow a mobile node to request the= home agent=0A> IPv4/v6 address, FQDN, or home network prefix and obtain it= via the=0A> DHCPv4 response.=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A> =A0 =0A> =0A> =0A> The IE= TF Secretariat.=0A=0A=0A=0A From kaaspetersen@yahoo.dk Thu Jul 16 02:09:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB2C3A6C7C for ; Thu, 16 Jul 2009 02:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 vUM+uJ+sERS7 for ; Thu, 16 Jul 2009 02:09:44 -0700 (PDT) Received: from web27803.mail.ukl.yahoo.com (web27803.mail.ukl.yahoo.com [217.146.182.8]) by core3.amsl.com (Postfix) with SMTP id 643193A6CA0 for ; Thu, 16 Jul 2009 02:08:59 -0700 (PDT) Received: (qmail 31568 invoked by uid 60001); 16 Jul 2009 09:09:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1247735370; bh=maQKQgrvc35g0p8tZXAmnPRaa9ZC6OneRkQVqGVz3+Y=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fZtI8jH6UpgTUlu/oMj5LdhgE1Wqju/oFfY3aM/2smYTvWNWgdLyBuSU1bKdGOmcUWTMA9d23W1YcYN44wtBa/waKPYXtJ2CPUfhbiXIkZ+tX4rxtXdh4egRH7GIbPUpSJIcWu5INpvqNWNhp4b4lMXDoSPqo8w0RpIyVePmOC0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3cGRP+P3mHKiX8vS5xhGKh5+a6Rv+ftC+mN7U7uOKSinpW7S7+OeWB0tp9sm08itRip51AnzGQLE8P7s0N6pDruTqaOdyFAN/HuFb4oIslTq7cj4TDlp0wpeft1XH7PIP7MBD4ikpcgH0BvKNPtoVF1wnTTX5gyTdsoaoH/QKH8=; Message-ID: <24830.31399.qm@web27803.mail.ukl.yahoo.com> X-YMail-OSG: nGzeKXUVM1lkYAc63zn9eKEU0OPMGzVx9eMAZtX6QPFXP4Wz5jzk7I_iSfCOsnd88vvsy7ba2ZXeqapyWs0AaXIkUOH_hiznLLCgXOwsURq5PQb.wBoaqop.n3xoplsn28hFoL2zERZkshRz.88eHC9ccYsbypksZBJSjlyDteRALUPY0tMFSDd6nmllviSxcYeXvH71SBmicHBLOc8RR3AhHdSu7gHStf2xqmZXVulVG.f1rLKVp4BW0VuBDKScxnESw5Y_wXotLWiQ.v3qCqLI0_B2PPnDIuO9MXPLKYenTXBfoglUtCVWh_sUoJZ1aX7wAkXN2uyT0wycJ2HlN_EXuG3Zx0IesuA_BJKuJ5_OyHGt20s_yE6LCPVazQXnz4lyn2LVBPAZ6c9YeA-- Received: from [193.15.240.60] by web27803.mail.ukl.yahoo.com via HTTP; Thu, 16 Jul 2009 09:09:29 GMT X-Mailer: YahooMailClassic/6.0.18 YahooMailWebService/0.7.289.15 Date: Thu, 16 Jul 2009 09:09:29 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 09:09:45 -0000 A few comments on draft-ietf-mext-flow-binding-03 * chapter 2, paragraph 2, "other specifications" AND section 5.1, paragraphs 3, "another document": Will it harm to make a reference to draft-tsirtsis-mext-binary-filters, in order to give one example of what a flow description could look like? * chapter 3: After reading the document, I think a flow should be defined as follows. "Flow: A flow is a subset of all IP packets sent *to* a mobile node. The packets of the subset match a flow description." With this definition, it makes more sense that a flow description can use source address, will never use destination address, and can use both source and destination ports. * section 4.1, BID-PRI paragraph: Suggest to add a sentence like "This field is needed in case a packet does not match any flow description." A similar top-level motivation is given for the FID-PRI field in section 4.2. * section 4.2, Status paragraph: A suggestion for easing the reading, let the sentences "Values from 0 to 127 indicate success. Values of 128 and higher indicate failure." be the second and third sentences, which are then followed by detailing the relevance of the field. * section 4.2: I wonder, isn't the Forward action forgotten? The Forward action is certainly mentioned in section 5.3.2.1. * section 5.2.2.1, last paragraph: Shouldn't a third bullet be added concerning if action indicates 'Forward', where one BID must be included? * section 5.2.4, last paragraph: The last sentence describes one way for an inactive flow binding to become active, namely by modifying the flow entry such that it maps to already existing BIDs. I think there is a second way, namely to send a Binding Identifier Mobility option re-introducing the BID-value. Christian =0A=0A=0A ___________________________________________________________ = =0ASkal du k=F8be ny bil? Sammenlign priser p=E5 brugte biler med Kelkoo og= find et godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb From hesham@elevatemobile.com Thu Jul 16 02:19:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A23E3A6C7A for ; Thu, 16 Jul 2009 02:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 CHTpf8XzZPh6 for ; Thu, 16 Jul 2009 02:19:45 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 3B0DB3A67BE for ; Thu, 16 Jul 2009 02:19:44 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MRN8Q-0000Mi-2b; Thu, 16 Jul 2009 19:20:14 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 16 Jul 2009 19:20:09 +1000 From: Hesham Soliman To: Christian Kaas-Petersen , Message-ID: Thread-Topic: [MEXT] flow binding draft 3 Thread-Index: AcoF9p0kg+GXD5SIQU6b8Kvga8QPBA== In-Reply-To: <24830.31399.qm@web27803.mail.ukl.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 09:19:46 -0000 On 16/07/09 7:09 PM, "Christian Kaas-Petersen" wrote: >=20 > A few comments on draft-ietf-mext-flow-binding-03 >=20 > * chapter 2, paragraph 2, "other specifications" AND > section 5.1, paragraphs 3, "another document": Will it harm to make > a reference to draft-tsirtsis-mext-binary-filters, in order to > give one example of what a flow description could look like? =3D> Hopefully in the next revisions that draft will be a WG draft and progress together with the flow binding draft so we can reference it as a default.=20 >=20 > * chapter 3: After reading the document, I think a flow should be > defined as follows. "Flow: A flow is a subset of all IP packets > sent *to* a mobile node. The packets of the subset match > a flow description." With this definition, it makes more sense > that a flow description can use source address, will never use > destination address, and can use both source and destination ports. =3D> I actually prefer RFC 2460's definition: A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers I think we should reuse it as much as possible. >=20 > * section 4.1, BID-PRI paragraph: Suggest to add a sentence like > "This field is needed in case a packet does not match any flow > description." A similar top-level motivation is given for the > FID-PRI field in section 4.2. =3D> ok. >=20 > * section 4.2, Status paragraph: A suggestion for easing the reading, > let the sentences "Values from 0 to 127 indicate success. Values > of 128 and higher indicate failure." be the second and third sentences= , > which are then followed by detailing the relevance of the field. =3D> ok. >=20 > * section 4.2: I wonder, isn't the Forward action forgotten? The > Forward action is certainly mentioned in section 5.3.2.1. =3D> It was removed, you must've found a left over one that I forgot to remove. N-cast now covers the forward action. >=20 > * section 5.2.2.1, last paragraph: Shouldn't a third bullet be added > concerning if action indicates 'Forward', where one BID must be > included? =3D> There is always one or more in n-cast. >=20 > * section 5.2.4, last paragraph: The last sentence describes one way > for an inactive flow binding to become active, namely by modifying > the flow entry such that it maps to already existing BIDs. I think > there is a second way, namely to send a Binding Identifier Mobility > option re-introducing the BID-value. =3D> An inactive flow should not point to anything, so (re)-installing a BID should have no effect unless explicitly bound to a flow. I don't think we should keep records of what a flow used to be bound to. It's a memoryless operation. If there is text suggesting otherwise please let me know. Hesham >=20 > Christian >=20 >=20 >=20 >=20 > ___________________________________________________________ > Skal du k=F8be ny bil? Sammenlign priser p=E5 brugte biler med Kelkoo og find= et > godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From kaaspetersen@yahoo.dk Thu Jul 16 03:45:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7F83A69C6 for ; Thu, 16 Jul 2009 03:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 W5YHtmJGJT6d for ; Thu, 16 Jul 2009 03:45:28 -0700 (PDT) Received: from web27802.mail.ukl.yahoo.com (web27802.mail.ukl.yahoo.com [217.146.182.7]) by core3.amsl.com (Postfix) with SMTP id 58D653A68CB for ; Thu, 16 Jul 2009 03:45:28 -0700 (PDT) Received: (qmail 43175 invoked by uid 60001); 16 Jul 2009 10:43:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1247741017; bh=cdTydeIk0cnJhBjdHYQxwqqKmFHRizdriJ/jgaf9E/8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eRsrbDAKV+R+OsuZC23TmWvVXj1gsn08l2+OlUJQKKS8baqDqtEpGsg4QV69eF18I+cNvk95FAjnI2jCLFhE32c4VdYAkTVOzktexIlF8lRfvagkztnF0BBjkzkVJ/HDYLZOr2Efjz01xx7W1zHTkZLr89oTDF8kGoVFIlm/tSg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3tB4SyD++y3fQQiVO1nC531g1GntVH7h6TkZqHgluv4SYlKUb15Y4HuEGMC16reR8OhSL9Jd0ZAyyyTZML6UFeGi2tGnGE+jGH6/6TnfIs+af+4WGAXYQBx7MMJct31HG44IO5uCXtSup7i8qJY7YLu6yj/mGEBxELTWxUR3AUM=; Message-ID: <695837.42158.qm@web27802.mail.ukl.yahoo.com> X-YMail-OSG: OVFAvhsVM1mU89MaL6ImKXGmI_qnyqJrNWAAFxdqR4aFx3pPOP6h4CUrQJr3MjMqEXazYclpbTYhDh_kFn9CUdcRHstNJhfYMxGw9IZ_QU7WCD79DqSebiPNpIR0vh623Wqrv3XV9IqVXOBapzh1ktnemYCv1DmaPaGtdz9TBUGGF389Xf2EEeUWJQvfh1IWFbABBpwl3fIsR3RUbI_eOwQB.2A5qKbGKH2LYHoGv9kvl_k2L2QwV5CRzXp0aQ0wuGq2.g9AZFM3ZiY7NRU0XdH4QQKNNaYfQd3MAqHeros3iAaEKz5W3CReBFXVWdWFKin.U4NSsUbeqaNCg4JVSNf1uQdGTDOYZIB9lPkl_UKhLskuzBNy3_bNNA-- Received: from [193.15.240.60] by web27802.mail.ukl.yahoo.com via HTTP; Thu, 16 Jul 2009 10:43:37 GMT X-Mailer: YahooMailClassic/6.0.18 YahooMailWebService/0.7.289.15 Date: Thu, 16 Jul 2009 10:43:37 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org, Hesham Soliman MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 10:45:29 -0000 I agree to reuse as much as possible. The RFC 2460 definition says a flow is from a specific source. However, the first entry in the=20 Ordered Flow Binding table of section 4.4 describes a flow as TCP packets from any source, not a specific source. So I don't think the RFC 2460 definition fully covers the needs for flow bindings. Also, is it the source which desires special handling of its IP packets? To me it more the destination having requested a special handling to be performed by an intermediate node, the home agent (for now I have ignored correspondent nodes and hierarchical mobility).=20 Christian --- Den tors 16/7/09 skrev Hesham Soliman : Fra: Hesham Soliman Emne: Re: [MEXT] flow binding draft 3 Til: "Christian Kaas-Petersen" , mext@ietf.org Dato: torsdag 16. juli 2009 11.20 On 16/07/09 7:09 PM, "Christian Kaas-Petersen" wrote: >=20 >=A0 * chapter 3: After reading the document, I think a flow should be >=A0 =A0 defined as follows.=A0 "Flow: A flow is a subset of all IP packets >=A0 =A0 sent *to* a mobile node.=A0 The packets of the subset match >=A0 =A0 a flow description."=A0 With this definition, it makes more sense >=A0 =A0 that a flow description can use source address, will never use >=A0 =A0 destination address, and can use both source and destination ports= . =3D> I actually prefer RFC 2460's definition: =A0=A0=A0A flow is a sequence of packets sent from a particular source to a =A0=A0=A0particular (unicast or multicast) destination for which the source =A0=A0=A0desires special handling by the intervening routers I think we should reuse it as much as possible. =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig g= ode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From hesham@elevatemobile.com Thu Jul 16 04:24:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691DD3A6904 for ; Thu, 16 Jul 2009 04:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 6xyQbmEHKNNU for ; Thu, 16 Jul 2009 04:24:17 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 3CF643A6C44 for ; Thu, 16 Jul 2009 04:23:59 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MROg4-0004AD-Sg; Thu, 16 Jul 2009 20:59:05 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 16 Jul 2009 20:59:01 +1000 From: Hesham Soliman To: Christian Kaas-Petersen , Message-ID: Thread-Topic: [MEXT] flow binding draft 3 Thread-Index: AcoGBGzkbove0Pa1MUuz2wzzGPqzqQ== In-Reply-To: <695837.42158.qm@web27802.mail.ukl.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 11:24:18 -0000 On 16/07/09 8:43 PM, "Christian Kaas-Petersen" wrote: >=20 > I agree to reuse as much as possible. The RFC 2460 definition says > a flow is from a specific source. However, the first entry in the > Ordered Flow Binding table of section 4.4 describes a flow as TCP > packets from any source, not a specific source. So I don't think > the RFC 2460 definition fully covers the needs for flow bindings. =3D> Sure but it's essentially a wildcard tool that translates to any src. If it makes it easier we can simply s/particular/a. I don't see an issue with that.=20 > Also, is it the source which desires special handling of its IP > packets? To me it more the destination having requested a special > handling to be performed by an intermediate node, the home agent > (for now I have ignored correspondent nodes and hierarchical mobility). =3D> I don't think you should ignore CNs and HMIP. Regardless of who's requesting the treatment of the flow, the definition of a flow should be orthogonal to the scenario in which it is used. For example, we don't say that the FID is a number located in the third byte of the option, we just say it's a number.=20 Hesham >=20 > Christian >=20 >=20 > --- Den tors 16/7/09 skrev Hesham Soliman : >=20 >=20 > Fra: Hesham Soliman > Emne: Re: [MEXT] flow binding draft 3 > Til: "Christian Kaas-Petersen" , mext@ietf.org > Dato: torsdag 16. juli 2009 11.20 >=20 >=20 >=20 >=20 >=20 > On 16/07/09 7:09 PM, "Christian Kaas-Petersen" > wrote: >=20 >>=20 >> =A0 * chapter 3: After reading the document, I think a flow should be >> =A0 =A0 defined as follows.=A0 "Flow: A flow is a subset of all IP packets >> =A0 =A0 sent *to* a mobile node.=A0 The packets of the subset match >> =A0 =A0 a flow description."=A0 With this definition, it makes more sense >> =A0 =A0 that a flow description can use source address, will never use >> =A0 =A0 destination address, and can use both source and destination ports. >=20 > =3D> I actually prefer RFC 2460's definition: > =A0=A0=A0A flow is a sequence of packets sent from a particular source to a > =A0=A0=A0particular (unicast or multicast) destination for which the source > =A0=A0=A0desires special handling by the intervening routers >=20 > I think we should reuse it as much as possible. >=20 >=20 >=20 >=20 > Tr=E6nger du til at se det store billede? Kelkoo giver dig gode tilbu= d p=E5 > LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From behcetsarikaya@yahoo.com Thu Jul 16 08:17:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158C83A6891 for ; Thu, 16 Jul 2009 08:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 w3QK8GE7WgdT for ; Thu, 16 Jul 2009 08:17:52 -0700 (PDT) Received: from n3.bullet.mail.re3.yahoo.com (n3.bullet.mail.re3.yahoo.com [68.142.237.110]) by core3.amsl.com (Postfix) with SMTP id 0E49A3A67AC for ; Thu, 16 Jul 2009 08:17:51 -0700 (PDT) Received: from [68.142.230.29] by n3.bullet.mail.re3.yahoo.com with NNFMP; 16 Jul 2009 15:16:59 -0000 Received: from [67.195.9.83] by t2.bullet.re2.yahoo.com with NNFMP; 16 Jul 2009 15:16:59 -0000 Received: from [67.195.9.104] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 16 Jul 2009 15:16:59 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 16 Jul 2009 15:16:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 100106.73860.bm@omp108.mail.gq1.yahoo.com Received: (qmail 34985 invoked by uid 60001); 16 Jul 2009 15:16:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247757418; bh=8hNc3huCCgoGavsc50y2vMyLY3NSVhJ96x+gUdhBVe4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ft5q9fqf6u1dW5xBoWxNLIZzK/djcQpprlpM7VUw4dNZQrrgTXR42DyTNWZZmjTkk/pad/FtgszsQL/V80jST7JKTB09VIQj5SgiYXINaTkrFRRprUVjyHo6z2WHWDj/QA7+7P8o3dE30/wNDdgg1qXDMXwYAiC+F2Uh3wQnf/M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VDu7xGTx9YgNtyIz7x3l0ocG8X2t25prVxtm+wPkHvcHOF0rsRvG1w5N5e43lj1/UEKipiBEv/R3b5Wdhn8sIaDvKXlCCFiN1a1uz4fgv/luSDrn80OzYF25uPv32rXhaF9eNl9HIuLrNEcWkq1EoQB59IBHhco/KqE0hmj2+uI=; Message-ID: <901946.29543.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: NHm_lhcVM1l0oqQXkqWNEx_rmuLK4v5ip21k2Y6oq8jj2FiNSjJnQYng1NBPyO1jPnWbmE8GeFgcBy.3AfKRYTngvOn.7FaY.E_XuhHqs4F5mMAnCz.NV_ggfulhru5HbSn.rxdXre1EE_LmwWd9jzWKJlCscYfn3p.VotoJ2YqVrvTH364S5Kqvapu7JgKNLolVkXHBSgvezdkuAAf4D5k0qPzoDt0QLWCGD.pfkPj1lozHr5OFLiDSWfiSdyy5THNFtfIcRiL8inOizJs8cP09oy.9kUlG_M1IgwMJio4K1W4fzIYShG8gZf_nbIS40G8G5gi1w.wyxiuhaLMQiGNDunZnYQJch2urNLs- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Thu, 16 Jul 2009 08:16:58 PDT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 References: <972584.42365.qm@web111401.mail.gq1.yahoo.com> Date: Thu, 16 Jul 2009 08:16:58 -0700 (PDT) From: Behcet Sarikaya To: mext@ietf.org In-Reply-To: <972584.42365.qm@web111401.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] Discussions/history/background on draft-xia-mext-hioptv4-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 15:17:53 -0000 Hi Marcelo,=0A=A0 Here is the history behind this draft: You can follow the= thread with this subject: =0AProposed RFC editor change for DSMIPv6.=0AThe= first mail is by Hesham Soliman at http://www.ietf.org/mail-archive/web/me= xt/current/msg02713.html=A0on=A0February 28, 2009=0AHere Hesham suggests us= ing DHCPv4 from the DHCP=0AMobile IP Home Agent Option 68.=0A=0AThis was di= scussed in messages 2720 thru 2724 where people preferred defining a differ= ent DHCPv4 option. =0AIn fact way back in May 2008, at http://www.ietf.org/= mail-archive/web/mext/current/msg01375.html=0AFrank had suggested this and = asked this to be a recharter item.=0A=0AIn message http://www.ietf.org/mail= -archive/web/mext/current/msg02727.html=A0Jari asked DHCPv6 option defined = in hiopt draft http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-17= ..txt=A0could be used.=0AHesham replied in message http://www.ietf.org/mail-= archive/web/mext/current/msg02728.html=A0that in hiopt it's assumed to only= be present in IPv6-enabled networks=A0and he suggested defining a new opti= on.=0AJari replied in http://www.ietf.org/mail-archive/web/mext/current/msg= 02729.html=0Athat We can easily define an RFC to do this. He asked a draft = to be written immediately.=0AIn http://www.ietf.org/mail-archive/web/mext/c= urrent/msg02730.html=A0Frank volunteered to help.=0A=0AFrom March to June 2= 009 I think there was some offline communication between Hesham and Frank i= n which Hesham showed no interest in writing such a draft. Hesham can clari= fy this point if it is wrong, otherwise silence should be interpreted as ac= ceptance.=0A=0AWe informed Jari offline sometime in May 2009 that we wrote = the draft.=A0We submitted the draft on June 7, 2009.=0A=0A=A0=0ASo we belie= ve that enough has been said on this draft and ask the draft to be moved fo= rward.=0A=0ARegards,=0A=0ABehcet=0A=0A----- Original Message ----=0A> From:= Behcet Sarikaya =0A> To: mext@ietf.org=0A> Sent:= Wednesday, July 15, 2009 10:51:27 AM=0A> Subject: [MEXT] Fw: New Version N= otification for draft-xia-mext-hioptv4-00=0A> =0A> =0A> Hello All,=0A> =A0 = We have submitted a draft on configuring RFC 5555 (DSMIP) hosts using DHCPv= 4. =0A> The need for such a draft was pointed out by our AD in his message = at:=0A> http://www.ietf.org/mail-archive/web/mext/current/msg02729.html=0A>= =0A> Please see the past discussions around March 3, 2009 at =0A> http://w= ww.ietf.org/mail-archive/web/mext/current/mail35.html.=0A> =0A> =A0 Please = send your comments on the list.=0A> =0A> Regards,=0A> =0A> Behcet=0A> =0A> = =0A> ----- Forwarded Message ----=0A> > From: IETF I-D Submission Tool =0A>= > To: xiayangsong@huawei.com=0A> > Cc: sarikaya@ieee.org=0A> > Sent: Sunda= y, June 7, 2009 3:25:18 PM=0A> > Subject: New Version Notification for draf= t-xia-mext-hioptv4-00=0A> > =0A> > =0A> > A new version of I-D, draft-xia-m= ext-hioptv4-00.txt has been successfuly =0A> > submitted by Frank Xia and p= osted to the IETF repository.=0A> > =0A> > Filename:=A0=A0=A0 draft-xia-mex= t-hioptv4=0A> > Revision:=A0=A0=A0 00=0A> > Title:=A0=A0=A0 =A0=A0=A0 DHCPv= 4 Options for Home Information Discovery in Dual Stack =0A> MIPv6=0A> > Cre= ation_date:=A0=A0=A0 2009-06-07=0A> > WG ID:=A0=A0=A0 =A0=A0=A0 Independent= Submission=0A> > Number_of_pages: 8=0A> > =0A> > Abstract:=0A> > This docu= ment defines DHCPv4 options for dynamic discovery of home=0A> > network inf= ormation in Dual Stack Mobile IPv6.=A0 New DHCPv4 options=0A> > are defined= which allow a mobile node to request the home agent=0A> > IPv4/v6 address,= FQDN, or home network prefix and obtain it via the=0A> > DHCPv4 response.= =0A> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =0A> =A0 =0A> > =A0 =0A> > =0A> > =0A> > The IETF Secretariat.= =0A=0A=0A=0A From marcelo@it.uc3m.es Sun Jul 19 09:11:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602253A6B97 for ; Sun, 19 Jul 2009 09:11:07 -0700 (PDT) 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 xk16qJZ-d1Ao for ; Sun, 19 Jul 2009 09:11:06 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A30FC3A6C2D for ; Sun, 19 Jul 2009 09:10:43 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (192.pool85-53-144.dynamic.orange.es [85.53.144.192]) by smtp01.uc3m.es (Postfix) with ESMTP id 68F63B9FE26 for ; Sun, 19 Jul 2009 18:10:40 +0200 (CEST) Message-ID: <4A634580.7090908@it.uc3m.es> Date: Sun, 19 Jul 2009 18:10:40 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16774.000 Subject: [MEXT] About flow binding directionality X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 16:11:07 -0000 Hi, I have read the long discussion about this. It seems that in order for the HA to be able to send meaningful/useful information to the MN about a flow binding, either: 1- the HA knows something relevant that is not available to the MN about the path conditions between the HA and the different CoAs, or, 2- The HA has enough information to make a clue-full decision and we want to support a model where the network side influences the MN choices. Let me try to take a stab on those, and i am confident you will let me know what i am missing. Let's start by the first case i.e. 1- the HA knows something relevant that is not available to the MN about the path conditions between the HA and the different CoAs, Suppose the following scenario. +-----+ | CN | +-----+ | +------------------+ | ISP3 | | | +------------------+ | +----------------------------------------+ | Home Network | | +----+ | | | HA | | | +----+ | | | | | | +--------+ +---------+ | | | | | +--------|---------------------|---------+ | | | | +------------+ +---------------+ | ISP1 | | ISP2 | | | | | +------------+ +---------------+ | | | +----+ | +--------| MN |----+ CoA1 +----+ CoA2 So, in case it is not obvious, i describe it a bit more in detail. Assume that the home network has 3 providers. ISP1 that is the same that it is providing one access to the MN ISP1 that is the same that it is providing the other access to the MN And ISP3, that is connected to the CN (i know this is a somehow forced example, but it is easily generalizable to more complex scenarios, where the HA could play a useful role in traffic engineering for the home network) So, for obvious reasons, the traffic flowing from the MN to the HA through CoA1 will flow through ISP1 and the traffic flowing from the MN to the HA through CoA2 will flow through ISP2. Now, suppose that the link between the ISP1 and the home network is becoming congested, or is about to reach the expected quota or whatever traffic management issue that is perfectly known to the home network. Since the HA, as it is located in the home network, it would make sense that the HA can have easy access to that circumstance and it would make sense that the HA asks the MN to move the traffic from the CoA1 to the CoA2. Of course, this is not all the information that is needed to actually decide what is the best CoA, but i think that the point is that this is relevant information for the MN to have. Of course, the problem is that what if the MN actually believes that the other CoA is the right one to use? I believe that this is up to the MN policy and internal heuristics, about how to make a reasonable decision considering all the input it has. At this point, the point that i am trying to make is that the HA may have access to information that the MN has not and if anything, if the MN has no preference, it can follow the HA suggestions. Does this makes sense to you? Let me try the second case i.e. The HA has enough information to make a clue-full decision and we want to support a model where the network side influences the MN choices. Now, in order for this work, we need to assume a bunch of things, which will certainly not be true in the general case, but may be true in some specific cases. First of all, we need to agree whether there is some value in allowing the HA (i.e. the network side) to micro manage the MN. If not, then, this case has no value. If yes, then i guess that under a set of assumptions, this can be done. I understand that the assumptions basically comes down to the things that are needed for the HA to have the information. So these assumptions include: - The HA knows what access is associated to each CoA - The HA knows the situation of the visited network, including the radio access link with the MN. This essentially implies that the HA and the visited network are the same admin domain. - The HA also knows the situation of the rest of the network, in order to have a full picture of the different paths. - The HA knows something about the flows. This can be achieved cause the apps running in the MN are managed by the network, or cause they usually use the well known ports in a reasonable way or because they the late binding approach (i.e. the HA moves the existent flows once it is aware of their characteristics e.g. the rate fo the flow) So, maybe the assumptions can be relaxed, but i think that the point is that under a set of assumptions that may match to a viable scenario, it is possible for the HA to manage the MN. So, does people agree that this is a viable scenario? And does people see any value in having the network side managing the MN? Fire up. We should try to wrap this up for ietf75.... Regards, marcelo From hesham@elevatemobile.com Sun Jul 19 18:33:58 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138F23A683E for ; Sun, 19 Jul 2009 18:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 pPOUOMSXMD7X for ; Sun, 19 Jul 2009 18:33:57 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 901983A6823 for ; Sun, 19 Jul 2009 18:33:42 -0700 (PDT) Received: from [114.75.136.211] (helo=[192.168.0.3]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MShl1-0003T3-0x; Mon, 20 Jul 2009 11:33:37 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 20 Jul 2009 11:33:21 +1000 From: Hesham Soliman To: marcelo bagnulo braun , mext Message-ID: Thread-Topic: [MEXT] About flow binding directionality Thread-Index: AcoI2hC61nxMkiU0rEeqS7Et55oyLA== In-Reply-To: <4A634580.7090908@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [MEXT] About flow binding directionality X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 01:33:58 -0000 > > +-----+ > | CN | > +-----+ > | > +------------------+ > | ISP3 | > | | > +------------------+ > | > +----------------------------------------+ > | Home Network | > | +----+ | > | | HA | | > | +----+ | > | | | | > | +--------+ +---------+ | > | | | | > +--------|---------------------|---------+ > | | > | | > +------------+ +---------------+ > | ISP1 | | ISP2 | > | | | | > +------------+ +---------------+ > | | > | +----+ | > +--------| MN |----+ > CoA1 +----+ CoA2 > > > So, in case it is not obvious, i describe it a bit > more in detail. > Assume that the home network has 3 providers. > ISP1 that is the same that it is providing one access to the MN > ISP1 that is the same that it is providing the other access to the MN > And ISP3, that is connected to the CN > > (i know this is a somehow forced example, but it is easily generalizable > to more complex scenarios, where the HA could play a useful role in > traffic engineering for the home network) => Never mind the scenario's simplicity, I have two simple questions that I need an answer for in order to be able to consider this scenario: 1. How does the HA learn the Path corresponding to a particular CoA? Assuming that the internet is a bit complex with potentially one or more transit networks that are meshed in some cases. 2. If the HA is not a border router on its site, how does it know which ISP's link is up/congested in real time? Is there an RFC or best practices link? This has to be in real time for the scenario to make sense. I think the second scenario is making way too many assumptions that it's almost a scenario for corner cases that don't exist, so I'll stick with discussing this scenario for now. Hesham > > So, for obvious reasons, the traffic flowing from the MN to the HA through > CoA1 will flow through ISP1 and the traffic flowing from the MN to the > HA through CoA2 will flow through ISP2. > > Now, suppose that the link between the ISP1 and the home network is > becoming > congested, or is about to reach the expected quota or whatever traffic > management issue that is perfectly known to the home network. > > Since the HA, as it is located in the home network, it would make sense > that the HA can have easy access to that circumstance and it would > make sense that the HA asks the MN to move the traffic from the CoA1 to the > CoA2. > > Of course, this is not all the information that is needed to actually > decide > what is the best CoA, but i think that the point is that this is relevant > information for the MN to have. Of course, the problem is that what if > the MN > actually believes that the other CoA is the right one to use? > I believe that this is up to the MN policy and internal heuristics, about > how to make a reasonable decision considering all the input it has. > At this point, the point that i am trying to make is that the HA may have > access to information that the MN has not and if anything, if the MN > has no preference, it can follow the HA suggestions. > > Does this makes sense to you? > > Let me try the second case i.e. > > The HA has enough information to make a clue-full decision and > we want to support a model where the network side influences the MN > choices. > > Now, in order for this work, we need to assume a bunch of things, > which will certainly not be true in the general case, but may be > true in some specific cases. > > First of all, we need to agree whether there is some value in allowing > the HA (i.e. the network side) to micro manage the MN. > If not, then, this case has no value. > If yes, then i guess that under a set of assumptions, this can be done. > I understand that the assumptions basically comes down to the things > that are needed for the HA to have the information. > > So these assumptions include: > - The HA knows what access is associated to each CoA > - The HA knows the situation of the visited network, including > the radio access link with the MN. This essentially > implies that the HA and the visited network are the same admin domain. > - The HA also knows the situation of the rest of the network, in order > to have a full picture of the different paths. > - The HA knows something about the flows. This can be achieved cause > the apps running in the MN are managed by the network, or cause they > usually use the well known ports in a reasonable way or because they > the late binding approach (i.e. the HA moves the existent flows once > it is aware of their characteristics e.g. the rate fo the flow) > > So, maybe the assumptions can be relaxed, but i think that the point is > that under a set of assumptions that may match to a viable scenario, > it is possible for the HA to manage the MN. > > So, does people agree that this is a viable scenario? > And does people see any value in having the network side managing the MN? > > Fire up. > > We should try to wrap this up for ietf75.... > > Regards, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Sun Jul 19 23:51:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037913A6AF1 for ; Sun, 19 Jul 2009 23:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 D84IZLZLScET for ; Sun, 19 Jul 2009 23:51:49 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 892D23A68AC for ; Sun, 19 Jul 2009 23:51:49 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (192.pool85-53-144.dynamic.orange.es [85.53.144.192]) by smtp03.uc3m.es (Postfix) with ESMTP id 7997B7326B9; Mon, 20 Jul 2009 08:51:46 +0200 (CEST) Message-ID: <4A641402.5020101@it.uc3m.es> Date: Mon, 20 Jul 2009 08:51:46 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16774.005 Cc: mext Subject: Re: [MEXT] About flow binding directionality X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 06:51:51 -0000 Hesham Soliman escribió: > >> +-----+ >> | CN | >> +-----+ >> | >> +------------------+ >> | ISP3 | >> | | >> +------------------+ >> | >> +----------------------------------------+ >> | Home Network | >> | +----+ | >> | | HA | | >> | +----+ | >> | | | | >> | +--------+ +---------+ | >> | | | | >> +--------|---------------------|---------+ >> | | >> | | >> +------------+ +---------------+ >> | ISP1 | | ISP2 | >> | | | | >> +------------+ +---------------+ >> | | >> | +----+ | >> +--------| MN |----+ >> CoA1 +----+ CoA2 >> >> >> So, in case it is not obvious, i describe it a bit >> more in detail. >> Assume that the home network has 3 providers. >> ISP1 that is the same that it is providing one access to the MN >> ISP1 that is the same that it is providing the other access to the MN >> And ISP3, that is connected to the CN >> >> (i know this is a somehow forced example, but it is easily generalizable >> to more complex scenarios, where the HA could play a useful role in >> traffic engineering for the home network) >> > > => Never mind the scenario's simplicity, I have two simple questions that I > need an answer for in order to be able to consider this scenario: > 1. How does the HA learn the Path corresponding to a particular CoA? > Assuming that the internet is a bit complex with potentially one or more > transit networks that are meshed in some cases. > correct (this is why i stated that the described scenario was simplistic) I think that this can be obtained from BGP. I mean, If the home site is multihomed it is not uncommon it runs BGP. BGP will know what CoA prefix is reachable through which ISP. Now, we need to assume symmetric traffic i.e. the the forward path is the same than the reverse path. I think this is fairly common in the fringes (it is certainly not common across big providers the peer in multiple locations, but this doesn't seem to be the case here) > 2. If the HA is not a border router on its site, how does it know which > ISP's link is up/congested in real time? Is there an RFC or best practices > link? This has to be in real time for the scenario to make sense. > > Well, i think management protocols like SNMP can tell the HA link load information, correct? That information can be used by the HA to tell which link is more loaded. In general, today, when multihomed sites want to move traffic from one link to another, they simply move a bunch of destiantions that are coming from one link to anohter one. You actually could do the same here. Suppose that you have half of your MN using CoA1 and half of them using CoA2 (just to have a simple example). Now, the link with ISP1 is heavily loaded and the one with ISP2 has little traffic. It would be enough to start moving MNs that are using CoA1 to use CoA2. I know this all sounds a bit complex, but i think in general traffic engineering across domains is something pretty complex, so i am not sure this is beyond what current bgp techniques require. Makes sense? Regards, marcelo > I think the second scenario is making way too many assumptions that it's > almost a scenario for corner cases that don't exist, so I'll stick with > discussing this scenario for now. > > Hesham > > >> So, for obvious reasons, the traffic flowing from the MN to the HA through >> CoA1 will flow through ISP1 and the traffic flowing from the MN to the >> HA through CoA2 will flow through ISP2. >> >> Now, suppose that the link between the ISP1 and the home network is >> becoming >> congested, or is about to reach the expected quota or whatever traffic >> management issue that is perfectly known to the home network. >> >> Since the HA, as it is located in the home network, it would make sense >> that the HA can have easy access to that circumstance and it would >> make sense that the HA asks the MN to move the traffic from the CoA1 to the >> CoA2. >> >> Of course, this is not all the information that is needed to actually >> decide >> what is the best CoA, but i think that the point is that this is relevant >> information for the MN to have. Of course, the problem is that what if >> the MN >> actually believes that the other CoA is the right one to use? >> I believe that this is up to the MN policy and internal heuristics, about >> how to make a reasonable decision considering all the input it has. >> At this point, the point that i am trying to make is that the HA may have >> access to information that the MN has not and if anything, if the MN >> has no preference, it can follow the HA suggestions. >> >> Does this makes sense to you? >> >> Let me try the second case i.e. >> >> The HA has enough information to make a clue-full decision and >> we want to support a model where the network side influences the MN >> choices. >> >> Now, in order for this work, we need to assume a bunch of things, >> which will certainly not be true in the general case, but may be >> true in some specific cases. >> >> First of all, we need to agree whether there is some value in allowing >> the HA (i.e. the network side) to micro manage the MN. >> If not, then, this case has no value. >> If yes, then i guess that under a set of assumptions, this can be done. >> I understand that the assumptions basically comes down to the things >> that are needed for the HA to have the information. >> >> So these assumptions include: >> - The HA knows what access is associated to each CoA >> - The HA knows the situation of the visited network, including >> the radio access link with the MN. This essentially >> implies that the HA and the visited network are the same admin domain. >> - The HA also knows the situation of the rest of the network, in order >> to have a full picture of the different paths. >> - The HA knows something about the flows. This can be achieved cause >> the apps running in the MN are managed by the network, or cause they >> usually use the well known ports in a reasonable way or because they >> the late binding approach (i.e. the HA moves the existent flows once >> it is aware of their characteristics e.g. the rate fo the flow) >> >> So, maybe the assumptions can be relaxed, but i think that the point is >> that under a set of assumptions that may match to a viable scenario, >> it is possible for the HA to manage the MN. >> >> So, does people agree that this is a viable scenario? >> And does people see any value in having the network side managing the MN? >> >> Fire up. >> >> We should try to wrap this up for ietf75.... >> >> Regards, marcelo >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > > From jari.arkko@piuha.net Mon Jul 20 02:30:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E5A3A69C0 for ; Mon, 20 Jul 2009 02:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 A0DmmBlKiJkh for ; Mon, 20 Jul 2009 02:30:43 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6629E3A68D1 for ; Mon, 20 Jul 2009 02:30:43 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 7DB37198702; Mon, 20 Jul 2009 12:30:27 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id CEB171986E2; Mon, 20 Jul 2009 12:30:26 +0300 (EEST) Message-ID: <4A643932.5030201@piuha.net> Date: Mon, 20 Jul 2009 12:30:26 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" References: <4A380AB6.2080407@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "draft-ietf-mext-aero-reqs@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] AD review of draft-ietf-mext-aero-reqs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:30:48 -0000 Wes, >> Hmm. There's a hidden requirement here that you actually cannot cope >> with the basic NEMO at all (even without RO), because Mobile IP is by >> its nature relies on a single point of failure (the HA). You _also_ need >> another type of an extension to support multiple HAs for the same home >> address. You should explicitly indicate that such a hidden requirement >> exists and that its outside the scope of the RO work. Its good that the >> end of 3.4.1 already says that Internet-less operation is ruled out, and >> that HA/MR redundancy mechanisms are ruled out. But it would be good to >> add the explicit note about this. >> > > > Yes, this is right; we were always looking at the HA-redundancy extensions > as well for deployment in this case. We can add a sentence to clarify. > OK >> Or are you thinking of using the RO solution as a way around this >> requirement? To some small extent this would be possible. E.g., prefix >> certificates could indicate to CRs that you can claim yourself as the >> destination for a particular prefix. This would enable applications to >> work. However, it would not enable a CN in some random location to send >> a packet to the aircraft, unless the aircraft's MR had already >> established RO with a router near the CN. >> > > The real requirement here is that beyond any existing fragility in the > NEMO system, that the RO solution not add *new* single points of failure > of its own creation. It could perhaps be rephrased somewhat in the draft > to make that more clear. > > It was understood that if an HA was a single point of failure due to not > using HA redundancy mechanisms, and it did in fact fail, then established > sessions using RO could still operate based on the binding cache entries, > but new incoming connections would not reach the MR/MN. So, having RO is > nice in that it increases robustness to HA failure for established > application flows, but it is not in itself a real solution for HA > reliability, and that's not why it's asked for. > OK. As long as the document is clear on these points, I'm fine. >>> The first security requirement is driven by concerns expressed by ATS >>> communications engineers. The concern is with the air-ground links >>> to a craft, and their current lack of security. If an RO scheme >>> exposes the MNP to eavesdroppers on these links, it may enable >>> attackers to easily send packets towards onboard networks of crafts. >>> The RO scheme should use some reasonable form of encryption (e.g. >>> standard ESP transforms) in order to protect any new RO signalling >>> data that contains the MNP. >>> >> I think you mean integrity protection or authentication, not encryption. >> Encryption may not prevent the attacker from falsifying a signaling >> packet. I would simply say ... reasonable security mechanisms (e.g., >> strong authentication). >> > > > Actually a concern here is that by sniffing the right frequency and > seeing the MNP that is assigned to an aircraft, it will be very easy to > track flights the way people currently do with ACARS, and even worse, > it may be possible to find ways to direct packets at the planes based > on this knowledge. There are many people sniffing ACARS from the air > and tracking flights based on this today. > I understand. However, I think that particular worry is just one among many. Its OK for you to state a requirement to handle this, but at the same time you should also have requirements for the other things. Please remember that if your security is only based on hiding data, you may in fact be vulnerable. For instance, RO signaling packets are not the only potential source of information about, say, aircraft prefixes or server addresses. Parts of this data would also appear in public registries, be visible to anyone working on the network, etc. >> Also, I do not think the security of your networks can be based on the >> MNP being a secret. The text is fuzzy about what the real issues are. >> Note that I think the requirement from 3.8 was crystal clear. But the >> 3.8.1 text is making things a little more less clear. I would suggest >> cutting some of the text. >> > > > Ok; the MNP being secret is not a foundation of securing the system, but > not broadcasting it to the world is something that raises the barriers to > entry, and it's a request that was brought to us rather than something that > the IETF decided was needed. > That's fine, but as noted above, you also need to require the RO mechanism to be secure in other ways as well. >>> The second security requirement is driven by the greater risk of >>> flooding attacks that are started by an attacker redirecting an MNP's >>> traffic to some target victim CoA. This is somewhat worse than the >>> case for MIPv6 mobile host RO, because the MNP's traffic is >>> potentially a higher rate than that of a single mobile host's HoA. >>> To protect bindings to bogus CoAs from being sent, the RO scheme must >>> somehow validate that an MR actually possesses any CoAs that it >>> claims. In typical Mobile IPv6 RO, the return routability test >>> provides a form of validation, under certain assumptions. For the >>> purposes of aeronautics, to demonstrate ownership of the CoA, it is >>> safe to assume ingress filtering on the part of the access network >>> providers, in conjunction with the ability to correlate a BU's source >>> address and the decrypted alternate CoA at the end recipient of the >>> BU. (Note: this is particularly subject to MEXT discussion) >>> >> Again, the requirement in 3.8 was great. The justifications are less >> convincing. For instance, its not clear to me at all that a malicious MR >> will have greater bandwidth than a malicious MN. I would simply say: >> >> "The second security requirement is driven by the risk of flooding >> attacks that are started by an attacker redirecting an MNP's traffic to >> some target victim CoA. To protect bindings to bogus CoAs from being >> sent, the RO scheme must somehow validate that an MR actually possesses >> any CoAs that it claims. For the purposes of aeronautics, it is safe to >> assume ingress filtering is in place in the access networks." >> > > > Ok; that makes sense to me, and sounds like a good change. > Great! >>> It is felt by many individuals that by the time the IP-based ATN >>> grows into production use, there will be a global PKI useable for >>> ATS, though it is agreed that such a PKI does not currently exist, >>> and will take time to develop both technically and politically. >>> >> I think you mean s/global PKI/global ATN-specific PKI/. You should not >> hold your breath for a global all-purpose PKI. >> > > > :) Yes, of course. > OK >>> If the RO solution assumes that some amount >>> of preconfiguration of flow properties (port number ranges, etc.) is >>> required, this could make the integration of new applications or >>> protocols difficult. An RO scheme might assume this in order to >>> classify between flows that prefer the MRHA tunnel to an optimized >>> path per requirement Req1, for instance, among other reasons. >>> >> Req1 and this text under Req9 are in conflict. There is no way for a >> middlebox like the MR to look at anything else than the 5-tuples for >> doing traffic separation. Even without NEMO, your choices for providing >> differentiated treatment for IPsec packets are limited. Basically, its >> down to looking at addresses. (I think this would in fact most cases >> suffice, so I do not see the real world problem.) >> >> So if Req9 is about disallowing 5-tuple based policies, we have a >> problem. Perhaps you meant to say that RO still needs to be possible for >> unrecognized stuff, and that it then get some sort of default treatment. >> > > > What this requirement is saying is that the RO scheme must not assume > only TCP traffic, for instance, and prevent new transports or other > protocols from being deployed over the IP services provided. An > implementation could still screw this up, but the RO mechanism as > defined itself should be adaptable to new protocols. The actual > requirement text is pretty clear: > " Applications using new transport protocols, IPsec, or new IP options > MUST be possible within an RO scheme." > Agree. > Maybe we have so much rationale that we made it confusing? We could > definitely trim it a bit. > Yes, I think that was the problem. Please trim. If flow-based traffic separation is needed, some amount of configuration will be necessary. Of course we all agree that the software should allow all protocols and ports. >>> 4.2. Des2 - Nesting >>> >>> >>> It is desirable if the RO mechanism supports RO for nested MRs, >>> >> since >> >>> it is possible that for PIES and astronaut spacesuits, that PANs >>> >> with >> >>> MRs will need to be supported. For oceanic flight, ATS and AOS may >>> also benefit from the capability of nesting MRs between multiple >>> planes to provide a "reachback" to terrestrial groundstations >>> >> rather >> >>> than relying solely on lower rate HF or satellite systems. In >>> >> either >> >>> case, this mode of operation is beyond current strict requirements >>> and is merely desirable. It is also noted that there are other >>> >> ways >> >>> to support these communications scenarios using routing protocols >>> >> or >> >>> other means outside of NEMO. >>> >> Is loop detection a requirement? That is something that we do not >> currently support in NEMO... >> > > > Not a requirement at this stage of the game. > Is this something that you are prepared to state explicitly? FWIW, I think it is a reasonable expectation that in a carefully controlled environment such as the aircraft communications, loops will not happen. >>> using Plain >>> Old Aircraft Communication Addressing and Reporting System >>> >> (ACARS) >> >> Unless "Plain Old" is the formal name, I would use "using the old >> Aircraft ..." instead. >> >> It would be good to get references to a few of the concepts and >> technologies. E.g., Section 2 talks about ACARDS, VDL modes, Electronic >> Flight Bags, B-AMC, AMACS, P34, LDL, WCDMA, 802.16, etc. Some of these >> acronyms were not defined either. >> > > > "Plain Old ACARS" is actually the industry-used term :), sometimes > abbreviated POA (Plain Old ACARS). We can put in pointers to a couple > of references on these things. > OK >>> satcom links employed by Connexion by Boeing support much higher data >>> >> rates than current ATS links. >> >> Isn't this history now? I would suggest rephrasing this without any >> mention of specific products. E.g, satcom links employed by passenger >> Internet access systems support much higher... >> > > > Not totally history; Boeing Broadband Satcom Network lives on and is > contracted at least through Feb 2010, based on public announcements. > I suppose the name of the consumer-oriented service (Connexion) is > history though, but the system is largely the same, I believe. > Ok -- interesting! Jari From marcelo@it.uc3m.es Mon Jul 20 02:34:11 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E433A6B52 for ; Mon, 20 Jul 2009 02:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vGBVyc93I6OY for ; Mon, 20 Jul 2009 02:34:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 327AD3A68D1 for ; Mon, 20 Jul 2009 02:34:03 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap003.it.uc3m.es [163.117.139.45]) by smtp02.uc3m.es (Postfix) with ESMTP id 34F046C1405; Mon, 20 Jul 2009 11:07:10 +0200 (CEST) Message-ID: <4A6433BE.50804@it.uc3m.es> Date: Mon, 20 Jul 2009 11:07:10 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16774.005 Cc: mext Subject: Re: [MEXT] About flow binding directionality X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:34:11 -0000 Hesham Soliman escribió: > >>> => Never mind the scenario's simplicity, I have two simple questions that I >>> need an answer for in order to be able to consider this scenario: >>> 1. How does the HA learn the Path corresponding to a particular CoA? >>> Assuming that the internet is a bit complex with potentially one or more >>> transit networks that are meshed in some cases. >>> >>> >> correct (this is why i stated that the described scenario was simplistic) >> I think that this can be obtained from BGP. >> > > => Ok how do you actually get that from BGP, what protocol does the HA run > to the BGP router to get this? yes. The HA would run BGP and would obtain what is the next hop for each of the CoAs. Based on that the HA would know which ISP is being used to send traffic to each of the CoAs. Now, the next point is what direction is congested. If the direction from the HA to the MN is the one that is congested, then the HA has a very tight control and knows that if it starts sending the traffic to the other CoA it would move traffic from one ISP to the other one. that would solve half of the problem (i.e. one direction). In order to solve the other part, we need to assume that the traffic will flow simetrically. While this is not guranteed, it is as i stated before, not uncommon espcially in the fringes. > SNMP? > > I mean, If the home site is > >> multihomed it is not uncommon it runs BGP. >> BGP will know what CoA prefix is reachable through which ISP. >> > > => But how common is that for a multihomed site? I mean, when a site is > multihomed, how common is it that 50% of the Internet reaches me through > ISP1 and the other 50% reaches me through ISP2? If you have two links of the same capacity, this is exaclty what you want, right? So, there are a bunch of Traffic enginnering technique to try to achieve exactly that. The point that i am trying to make is that the HA could also help in this task. > And how can that policy be > enforced for inbound traffic assuming that these are independent ISPs? > There is no enforcement here. It is more about playing the game to try to get what you want. People tweak BGP to try to move traffic from one link to another. this is exactly the same game the HA would start playing in order to get load balancing > Are we making too many assumptions due to the simplification of the > scenario? > > for me, the strongest assumption being made is about the traffic being symmetric. However, this only affects half of the traffic (i.e. on one of the directions) and when you are delaing with load balancing, it is pretty much a game that is played by approximation, so, you start moving knobs until you get what you want. > >>> 2. If the HA is not a border router on its site, how does it know which >>> ISP's link is up/congested in real time? Is there an RFC or best practices >>> link? This has to be in real time for the scenario to make sense. >>> >>> >>> >> Well, i think management protocols like SNMP can tell the HA link load >> information, correct? >> > > => I don't know if they give that information in real time. AFAIK, they can provide information about the number of bytes course over the last n seconds. If the HA gets that information periodically, it can estimate the bandwidth consumption on each link > I also don't > know what kind of heuristics we're expecting the HA to follow to come to an > intelligent decision to move some MNs given that it has no idea about how > useful that move is for the MN's other destinations or applications that it > may be using. > > well, if the HA knows the BGP information and knows the link load of each exit link, it can know what CoA is reachable through each link and can decide to move some of the ones that are using the CoA that corresponds to the congested link to the non congested link this will provide very precise load balancing for the HA to the MN direction and it is likely to have a significant effect on the reverse direction as well. >> That information can be used by the HA to tell which link is more loaded. >> >> In general, today, when multihomed sites want to move traffic from one >> link to another, they simply move a bunch of destiantions that are >> coming from one link to anohter one. You actually could do the same here. >> > > => Yes but this is different from what you're describing, you want to signal > to a remote host to change it's source because you think that that src will > come through ISPX. You have to be sure that: > > - This is *always* the case > not really I am trying to achieve load balancing If this is true for a significant number of the cases, it is good enough. > - The new address is not going to suffer a worse performance (don't know how > you can know that) > As i said earlier, the point being made is that the HA can provide some input information to make the decision. If both paths are equally acceptable to the MN, why wouldn't the MN take into account the HA preferences? Of course, if the MN knows that one CoA is much worse than the other one, it is likely that the MN will keep on sending the traffic through the good one, no matter what the HA asks. But that is ok. This is usually the case in traffic management. Eahc party does what the other is asking unless it goes against their own interests. So this applies both the the direction from the HA to the MN. If the HA knows that the path to CoA1 is worse for it than the one through the CoA2. it will use the one through CoA2 no matter what the MN says. So, the point being made is that this is useful input for the MN to consider in its decision process. > - The information you have is based on a trend and is timely > > right, but this is the best you can do when it comes to load balancing, right? >> Suppose that you have half of your MN using CoA1 and half of them using >> CoA2 (just to have a simple example). >> Now, the link with ISP1 is heavily loaded and the one with ISP2 has >> little traffic. >> It would be enough to start moving MNs that are using CoA1 to use CoA2. >> > > => I think everything is simple on this level, but it all relies on your > assumption that the HA can know that path to always be true. as i stated earlier, it dones' have to be always true. It has to be true a significant number of times (at least more than half of the times :-) > How realistic > is it that an unknown part of the IP address space can reach a site through > 1 ISP? > > As i said above, it is certianly always true in the HA to the MN direction. In the reverse direction, it is more uncertain, and it will depend on the peering agreements and on the topology of the home network. I think it will be true in some cases and not so true in other cases. However, this can actually be enforced by peering agreements. >> I know this all sounds a bit complex, but i think in general traffic >> engineering across domains is something pretty complex, so i am not sure >> this is beyond what current bgp techniques require. >> > > => It may be understood for BGP but we're dealing with a different scenario > here that involves end hosts making choices based on completely different > factors and relying on e2e measurements to know what's good for them and > their apps. I think doing something like this from the HA can lead to many > uninformed decisions as oppsosed to keeping things e2e. > > while i am sympathetic to the e2e argument, i think that if we actually go that path, we actually need to do things very differently and use multipath TCP or SCTP The reason why i say that is that the IP layer cannot properly characterize the e2e path cause it cannot measure e2e congestion. So, having the HA provide additional path information could help the MN to get a more complete view. >> Makes sense? >> > > => Not to me. I'm not convinced that the HA can detect paths for all > scenarios and know enough to move traffic ...etc, especially when the > alternative (e2e) seems to be working so far. What advantage does this > solution (if it works) have over e2e approaches? > As i said above, what do you mean by e2e? Current MIP approach cannot characterize the congestion of the e2e path. Moreover, current MIP approach cannot even detect e2e failures. So, i would believe that multipath tcp is a superior alternative, but the case it is not so clear to me for the flow binding case. Regards, marcelo > Hesham > > >> Regards, marcelo >> >> >>> I think the second scenario is making way too many assumptions that it's >>> almost a scenario for corner cases that don't exist, so I'll stick with >>> discussing this scenario for now. >>> >>> Hesham >>> >>> >>> >>>> So, for obvious reasons, the traffic flowing from the MN to the HA through >>>> CoA1 will flow through ISP1 and the traffic flowing from the MN to the >>>> HA through CoA2 will flow through ISP2. >>>> >>>> Now, suppose that the link between the ISP1 and the home network is >>>> becoming >>>> congested, or is about to reach the expected quota or whatever traffic >>>> management issue that is perfectly known to the home network. >>>> >>>> Since the HA, as it is located in the home network, it would make sense >>>> that the HA can have easy access to that circumstance and it would >>>> make sense that the HA asks the MN to move the traffic from the CoA1 to the >>>> CoA2. >>>> >>>> Of course, this is not all the information that is needed to actually >>>> decide >>>> what is the best CoA, but i think that the point is that this is relevant >>>> information for the MN to have. Of course, the problem is that what if >>>> the MN >>>> actually believes that the other CoA is the right one to use? >>>> I believe that this is up to the MN policy and internal heuristics, about >>>> how to make a reasonable decision considering all the input it has. >>>> At this point, the point that i am trying to make is that the HA may have >>>> access to information that the MN has not and if anything, if the MN >>>> has no preference, it can follow the HA suggestions. >>>> >>>> Does this makes sense to you? >>>> >>>> Let me try the second case i.e. >>>> >>>> The HA has enough information to make a clue-full decision and >>>> we want to support a model where the network side influences the MN >>>> choices. >>>> >>>> Now, in order for this work, we need to assume a bunch of things, >>>> which will certainly not be true in the general case, but may be >>>> true in some specific cases. >>>> >>>> First of all, we need to agree whether there is some value in allowing >>>> the HA (i.e. the network side) to micro manage the MN. >>>> If not, then, this case has no value. >>>> If yes, then i guess that under a set of assumptions, this can be done. >>>> I understand that the assumptions basically comes down to the things >>>> that are needed for the HA to have the information. >>>> >>>> So these assumptions include: >>>> - The HA knows what access is associated to each CoA >>>> - The HA knows the situation of the visited network, including >>>> the radio access link with the MN. This essentially >>>> implies that the HA and the visited network are the same admin domain. >>>> - The HA also knows the situation of the rest of the network, in order >>>> to have a full picture of the different paths. >>>> - The HA knows something about the flows. This can be achieved cause >>>> the apps running in the MN are managed by the network, or cause they >>>> usually use the well known ports in a reasonable way or because they >>>> the late binding approach (i.e. the HA moves the existent flows once >>>> it is aware of their characteristics e.g. the rate fo the flow) >>>> >>>> So, maybe the assumptions can be relaxed, but i think that the point is >>>> that under a set of assumptions that may match to a viable scenario, >>>> it is possible for the HA to manage the MN. >>>> >>>> So, does people agree that this is a viable scenario? >>>> And does people see any value in having the network side managing the MN? >>>> >>>> Fire up. >>>> >>>> We should try to wrap this up for ietf75.... >>>> >>>> Regards, marcelo >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> >>> >>> > > > > From hesham@elevatemobile.com Mon Jul 20 04:19:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF503A6A04 for ; Mon, 20 Jul 2009 04:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Siqk4vp0wyfR for ; Mon, 20 Jul 2009 04:19:38 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 9FA573A6959 for ; Mon, 20 Jul 2009 04:19:37 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MSqsx-0006sq-0m; Mon, 20 Jul 2009 21:18:23 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 20 Jul 2009 21:18:17 +1000 From: Hesham Soliman To: marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] About flow binding directionality Thread-Index: AcoJK8eSljIAWUp1s0W7UbcIYEIEig== In-Reply-To: <4A6433BE.50804@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: mext Subject: Re: [MEXT] About flow binding directionality X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 11:19:40 -0000 >> >> => Ok how do you actually get that from BGP, what protocol does the HA run >> to the BGP router to get this? > > yes. > The HA would run BGP and would obtain what is the next hop for each of > the CoAs. > Based on that the HA would know which ISP is being used to send traffic > to each of the CoAs. > > Now, the next point is what direction is congested. > If the direction from the HA to the MN is the one that is congested, > then the HA > has a very tight control and knows that if it starts sending the traffic > to the other > CoA it would move traffic from one ISP to the other one. => The HA can't decide to send traffic to a different CoA from the one in the BC. I think you mean it will tell the MN to switch CoA, that's all it can do. that would > solve half of the > problem (i.e. one direction). In order to solve the other part, we need > to assume that > the traffic will flow simetrically. While this is not guranteed, it is > as i stated before, not > uncommon espcially in the fringes. => But do you mean it's common regardless of where the MN is located? I mean if I'm in NY and have a split VPN configuratation and my HA is in Madrid, we can still be ok with this symmetry? >> >> => But how common is that for a multihomed site? I mean, when a site is >> multihomed, how common is it that 50% of the Internet reaches me through >> ISP1 and the other 50% reaches me through ISP2? > If you have two links of the same capacity, this is exaclty what you > want, right? > So, there are a bunch of Traffic enginnering technique to try to achieve > exactly that. => I don't know them but I'll take your word, although I don't really know how you can be sure about forcing packets from certain sources anywhere on the Internet to come in a certain inbound link. > > The point that i am trying to make is that the HA could also help in > this task. => "Help" is fine, "sending rules" is not fine. So if you only want to send a suggestion (there is a lot to discuss about the content of such suggestion) then I can understand that a lot more than telling the MN to switch. There is also a good case for sending policies of course but that's another topic. >> Are we making too many assumptions due to the simplification of the >> scenario? >> >> > for me, the strongest assumption being made is about the traffic being > symmetric. => Yes that's a significant one. > However, this only affects half of the traffic (i.e. on one of the > directions) and > when you are delaing with load balancing, it is pretty much a game that > is played by > approximation, so, you start moving knobs until you get what you want. => I don't really care about how good the load balancing outcome will be, I'm only concerned about sending the wrong information to the MN. >> >> => I don't know if they give that information in real time. > AFAIK, they can provide information about the number of bytes course > over the last n seconds. > If the HA gets that information periodically, it can estimate the > bandwidth consumption > on each link => ok. > > >> I also don't >> know what kind of heuristics we're expecting the HA to follow to come to an >> intelligent decision to move some MNs given that it has no idea about how >> useful that move is for the MN's other destinations or applications that it >> may be using. >> >> > well, if the HA knows the BGP information and knows the link load of > each exit link, it can > know what CoA is reachable through each link and can decide to move some > of the > ones that are using the CoA that corresponds to the congested link to > the non congested link => So, given your earlier statement about how traffic engineering can be used to move inbound traffic from one ISP to another, why do you need to change the src address in this case instead of using the same traffic engineering techniques to do load balancing? Is it not something that can be done dynamically? Or is it because you need finer control? >> - This is *always* the case >> > not really > I am trying to achieve load balancing > If this is true for a significant number of the cases, it is good enough. => Yes but if half the time you detect the path incorrectly you will be sending the wrong information to the MN half the time. You might still get load balancing but you make the MNs switch addresses for no reason. I don't know if that has drastic consequences but it only seems to work for large numbers. So that part of the protocol will be labelled "For large numbers only" :) > > >> - The new address is not going to suffer a worse performance (don't know how >> you can know that) >> > > As i said earlier, the point being made is that the HA can provide some > input information to make > the decision. > If both paths are equally acceptable to the MN, why wouldn't the MN take > into account the HA > preferences? => Ok, a suggestion makes me feel a bit better about this, but you could still end up disrupting service if the MN switches then discovered that the e2e nature of the other address is terrible for its connection. > Of course, if the MN knows that one CoA is much worse than the other > one, it is likely that > the MN will keep on sending the traffic through the good one, no matter > what the HA asks. => Ok, if it knows apriori, I agree. > So this applies both the the direction from the HA to the MN. > If the HA knows that the path to CoA1 is worse for it than the one > through the CoA2. it will > use the one through CoA2 no matter what the MN says. > > So, the point being made is that this is useful input for the MN to > consider in its decision process. > > >> - The information you have is based on a trend and is timely >> >> > right, but this is the best you can do when it comes to load balancing, > right? > >>> Suppose that you have half of your MN using CoA1 and half of them using >>> CoA2 (just to have a simple example). >>> Now, the link with ISP1 is heavily loaded and the one with ISP2 has >>> little traffic. >>> It would be enough to start moving MNs that are using CoA1 to use CoA2. >>> >> >> => I think everything is simple on this level, but it all relies on your >> assumption that the HA can know that path to always be true. > as i stated earlier, it dones' have to be always true. > It has to be true a significant number of times (at least more than half > of the times :-) => Understood, from the home network admin's point of view this is fine, I don't think it's fine from a protocol design point of view to say "this will work for large numbers only". >> > > while i am sympathetic to the e2e argument, i think that if we actually > go that path, > we actually need to do things very differently and use multipath TCP or SCTP > The reason why i say that is that the IP layer cannot properly > characterize the e2e > path cause it cannot measure e2e congestion. => Why not? e2e delays and connection quality are used by content adaptation techniques regularly. You don't need multi-path TCP for that. You're only trying to work out the e2e properties of a particular connection. >> >> => Not to me. I'm not convinced that the HA can detect paths for all >> scenarios and know enough to move traffic ...etc, especially when the >> alternative (e2e) seems to be working so far. What advantage does this >> solution (if it works) have over e2e approaches? >> > As i said above, what do you mean by e2e? > Current MIP approach cannot characterize the congestion of the e2e path. => MIP is only a tool that acts on the request of another engine making decisions. The input to such decisions can be e2e information coming from the transport layer. So, yes of course MIPv6 can't do this e2e, but it doesn't mean it can't be done by the host. MIP is only a tool in the toolset and doesn't actually provide any intelligence in decision making process involved in selecting an interface. > Moreover, current MIP approach cannot even detect e2e failures. => Like I said, it's not a MIP function, a transport layer can detect failure and provide hints. RFC 4861 mentions such hints that can be useful. Only a very small part of the puzzle is solved by MIP. Hesham From hesham@elevatemobile.com Mon Jul 20 06:18:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821FE3A6BD5 for ; Mon, 20 Jul 2009 06:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rpmuhhXuxx7N for ; Mon, 20 Jul 2009 06:18:15 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 22CA53A6D42 for ; Mon, 20 Jul 2009 06:18:14 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MSo0Q-00038C-CN; Mon, 20 Jul 2009 18:13:55 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Mon, 20 Jul 2009 18:13:48 +1000 From: Hesham Soliman To: marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] About flow binding directionality Thread-Index: AcoJEgHv3mTJzydscUK9B+bChi8NdQ== In-Reply-To: <4A641402.5020101@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: mext Subject: Re: [MEXT] About flow binding directionality X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 13:18:16 -0000 >> >> => Never mind the scenario's simplicity, I have two simple questions that I >> need an answer for in order to be able to consider this scenario: >> 1. How does the HA learn the Path corresponding to a particular CoA? >> Assuming that the internet is a bit complex with potentially one or more >> transit networks that are meshed in some cases. >> > > correct (this is why i stated that the described scenario was simplistic) > I think that this can be obtained from BGP. => Ok how do you actually get that from BGP, what protocol does the HA run to the BGP router to get this? SNMP? I mean, If the home site is > multihomed it is not uncommon it runs BGP. > BGP will know what CoA prefix is reachable through which ISP. => But how common is that for a multihomed site? I mean, when a site is multihomed, how common is it that 50% of the Internet reaches me through ISP1 and the other 50% reaches me through ISP2? And how can that policy be enforced for inbound traffic assuming that these are independent ISPs? Are we making too many assumptions due to the simplification of the scenario? >> 2. If the HA is not a border router on its site, how does it know which >> ISP's link is up/congested in real time? Is there an RFC or best practices >> link? This has to be in real time for the scenario to make sense. >> >> > Well, i think management protocols like SNMP can tell the HA link load > information, correct? => I don't know if they give that information in real time. I also don't know what kind of heuristics we're expecting the HA to follow to come to an intelligent decision to move some MNs given that it has no idea about how useful that move is for the MN's other destinations or applications that it may be using. > > That information can be used by the HA to tell which link is more loaded. > > In general, today, when multihomed sites want to move traffic from one > link to another, they simply move a bunch of destiantions that are > coming from one link to anohter one. You actually could do the same here. => Yes but this is different from what you're describing, you want to signal to a remote host to change it's source because you think that that src will come through ISPX. You have to be sure that: - This is *always* the case - The new address is not going to suffer a worse performance (don't know how you can know that) - The information you have is based on a trend and is timely > > Suppose that you have half of your MN using CoA1 and half of them using > CoA2 (just to have a simple example). > Now, the link with ISP1 is heavily loaded and the one with ISP2 has > little traffic. > It would be enough to start moving MNs that are using CoA1 to use CoA2. => I think everything is simple on this level, but it all relies on your assumption that the HA can know that path to always be true. How realistic is it that an unknown part of the IP address space can reach a site through 1 ISP? > > I know this all sounds a bit complex, but i think in general traffic > engineering across domains is something pretty complex, so i am not sure > this is beyond what current bgp techniques require. => It may be understood for BGP but we're dealing with a different scenario here that involves end hosts making choices based on completely different factors and relying on e2e measurements to know what's good for them and their apps. I think doing something like this from the HA can lead to many uninformed decisions as oppsosed to keeping things e2e. > > Makes sense? => Not to me. I'm not convinced that the HA can detect paths for all scenarios and know enough to move traffic ...etc, especially when the alternative (e2e) seems to be working so far. What advantage does this solution (if it works) have over e2e approaches? Hesham > > Regards, marcelo > >> I think the second scenario is making way too many assumptions that it's >> almost a scenario for corner cases that don't exist, so I'll stick with >> discussing this scenario for now. >> >> Hesham >> >> >>> So, for obvious reasons, the traffic flowing from the MN to the HA through >>> CoA1 will flow through ISP1 and the traffic flowing from the MN to the >>> HA through CoA2 will flow through ISP2. >>> >>> Now, suppose that the link between the ISP1 and the home network is >>> becoming >>> congested, or is about to reach the expected quota or whatever traffic >>> management issue that is perfectly known to the home network. >>> >>> Since the HA, as it is located in the home network, it would make sense >>> that the HA can have easy access to that circumstance and it would >>> make sense that the HA asks the MN to move the traffic from the CoA1 to the >>> CoA2. >>> >>> Of course, this is not all the information that is needed to actually >>> decide >>> what is the best CoA, but i think that the point is that this is relevant >>> information for the MN to have. Of course, the problem is that what if >>> the MN >>> actually believes that the other CoA is the right one to use? >>> I believe that this is up to the MN policy and internal heuristics, about >>> how to make a reasonable decision considering all the input it has. >>> At this point, the point that i am trying to make is that the HA may have >>> access to information that the MN has not and if anything, if the MN >>> has no preference, it can follow the HA suggestions. >>> >>> Does this makes sense to you? >>> >>> Let me try the second case i.e. >>> >>> The HA has enough information to make a clue-full decision and >>> we want to support a model where the network side influences the MN >>> choices. >>> >>> Now, in order for this work, we need to assume a bunch of things, >>> which will certainly not be true in the general case, but may be >>> true in some specific cases. >>> >>> First of all, we need to agree whether there is some value in allowing >>> the HA (i.e. the network side) to micro manage the MN. >>> If not, then, this case has no value. >>> If yes, then i guess that under a set of assumptions, this can be done. >>> I understand that the assumptions basically comes down to the things >>> that are needed for the HA to have the information. >>> >>> So these assumptions include: >>> - The HA knows what access is associated to each CoA >>> - The HA knows the situation of the visited network, including >>> the radio access link with the MN. This essentially >>> implies that the HA and the visited network are the same admin domain. >>> - The HA also knows the situation of the rest of the network, in order >>> to have a full picture of the different paths. >>> - The HA knows something about the flows. This can be achieved cause >>> the apps running in the MN are managed by the network, or cause they >>> usually use the well known ports in a reasonable way or because they >>> the late binding approach (i.e. the HA moves the existent flows once >>> it is aware of their characteristics e.g. the rate fo the flow) >>> >>> So, maybe the assumptions can be relaxed, but i think that the point is >>> that under a set of assumptions that may match to a viable scenario, >>> it is possible for the HA to manage the MN. >>> >>> So, does people agree that this is a viable scenario? >>> And does people see any value in having the network side managing the MN? >>> >>> Fire up. >>> >>> We should try to wrap this up for ietf75.... >>> >>> Regards, marcelo >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> >> > From julien.laganier.ietf@googlemail.com Tue Jul 21 11:40:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B303A6A68 for ; Tue, 21 Jul 2009 11:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.847 X-Spam-Level: X-Spam-Status: No, score=-100.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, 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 DytIDmVITgY6 for ; Tue, 21 Jul 2009 11:40:28 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 5E08B3A69E2 for ; Tue, 21 Jul 2009 11:40:28 -0700 (PDT) Received: by bwz28 with SMTP id 28so2781891bwz.37 for ; Tue, 21 Jul 2009 11:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=FRku82EF/Er658YNkjDQrPz4dGeaZuQHdf6B/uqaT9U=; b=m7+3dR0Jk1NxRy4odmpkH0tE06O4cl/4wGT79d+vn5EkdtI7+JDD/RVhUY9VfpkEVI IcWPoGsn12DYfZomBbq3FPcXvur1ebtCkjCfeRqUYYmb8ZI+BxB+v/tUy8ymRd345ixe PVbNXEsdCOL784aS2Ho4I7+fCRgY4oV1Sddfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ohndsbx+QOlsnu20zzS+cgGVESLfzWoUGGIrVKOpY1VNkPa0cHvJUERqKTqoa2mL6E HPzNpZ6PcQno9dKiHlwFo3oteK3Cpw8ep6fsWFnz2cFbPkHt/OKsmjXlMil2nlJ7rhph /7k5GQtZ+lqUzsyXVi2C+2lAgyhEFN23ymgZw= MIME-Version: 1.0 Sender: julien.laganier.ietf@googlemail.com Received: by 10.204.55.15 with SMTP id s15mr5848705bkg.53.1248201625161; Tue, 21 Jul 2009 11:40:25 -0700 (PDT) In-Reply-To: References: <695837.42158.qm@web27802.mail.ukl.yahoo.com> Date: Tue, 21 Jul 2009 11:40:25 -0700 X-Google-Sender-Auth: 108a42545a2b5828 Message-ID: <7ad6d6db0907211140pac4de0fw894e39a80df5a4fd@mail.gmail.com> From: "Laganier, Julien" To: Hesham Soliman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 18:40:29 -0000 Hesham & Christian: On Thu, Jul 16, 2009 at 3:59 AM, Hesham Soliman w= rote: > > On 16/07/09 8:43 PM, "Christian Kaas-Petersen" > wrote: > >>> =3D> I actually prefer RFC 2460's definition: >>> A flow is a sequence of packets sent from a particular source to a >>> particular (unicast or multicast) destination for which the source >>> desires special handling by the intervening routers >> >> I agree to reuse as much as possible. =A0The RFC 2460 definition says >> a flow is from a specific source. =A0However, the first entry in the >> Ordered Flow Binding table of section 4.4 describes a flow as TCP >> packets from any source, not a specific source. =A0So I don't think >> the RFC 2460 definition fully covers the needs for flow bindings. > > =3D> Sure but it's essentially a wildcard tool that translates to any src= . If > it makes it easier we can simply s/particular/a. I don't see an issue wit= h > that. I realize it's a bit late, but in light of this discussion, given the flow definition of RFC 2460, and given the mechanism we want to provide, namely, "extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address", I'm feeling that most of the time when the draft refers to a "flow" it should instead refer to a "flow aggregate" because multiple RFC 2460 "flows" can correspond to a single "flow descriptor", as Christian has pointed out with the TCP example. A less important thing is the use of "descriptor" which, while not necessarily incorrect, has been quite often used as a number pointing to an item in a repository, in a similar fashion to identifier. I was thinking that "selector" might be more appropriate... In light of this, I'm now wondering whether the terminology would be more consistent if we'd refer to RFC 2460 for the definition of a flow and renamed throughout the ID: - flow =3D> flow aggregate - flow descriptor =3D> flow aggregate selector - flow ID =3D> flow aggregate ID / flow aggregate descriptor What do you think? --julien From hesham@elevatemobile.com Tue Jul 21 18:33:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA293A69B6 for ; Tue, 21 Jul 2009 18:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 b6ulT631QLkH for ; Tue, 21 Jul 2009 18:33:17 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 393713A6853 for ; Tue, 21 Jul 2009 18:33:16 -0700 (PDT) Received: from [114.75.63.125] (helo=[192.168.0.4]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MTQhi-0003kK-VQ; Wed, 22 Jul 2009 11:33:12 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 22 Jul 2009 11:33:05 +1000 From: Hesham Soliman To: "Laganier, Julien" Message-ID: Thread-Topic: [MEXT] flow binding draft 3 Thread-Index: AcoKbFwEUVEp5H/gKUaJrvdBn/t7FQ== In-Reply-To: <7ad6d6db0907211140pac4de0fw894e39a80df5a4fd@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 01:33:18 -0000 On 22/07/09 4:40 AM, "Laganier, Julien" wrote: > Hesham & Christian: >=20 > On Thu, Jul 16, 2009 at 3:59 AM, Hesham Soliman > wrote: >>=20 >> On 16/07/09 8:43 PM, "Christian Kaas-Petersen" >> wrote: >>=20 >>>> =3D> I actually prefer RFC 2460's definition: >>>> A flow is a sequence of packets sent from a particular source to a >>>> particular (unicast or multicast) destination for which the source >>>> desires special handling by the intervening routers >>>=20 >>> I agree to reuse as much as possible. =A0The RFC 2460 definition says >>> a flow is from a specific source. =A0However, the first entry in the >>> Ordered Flow Binding table of section 4.4 describes a flow as TCP >>> packets from any source, not a specific source. =A0So I don't think >>> the RFC 2460 definition fully covers the needs for flow bindings. >>=20 >> =3D> Sure but it's essentially a wildcard tool that translates to any src.= If >> it makes it easier we can simply s/particular/a. I don't see an issue wi= th >> that. >=20 > I realize it's a bit late, but in light of this discussion, given the > flow definition of RFC 2460, and given the mechanism we want to > provide, namely, "extensions to Mobile IPv6 that allow nodes to bind > one or more flows to a care-of address", I'm feeling that most of the > time when the draft refers to a "flow" it should instead refer to a > "flow aggregate" because multiple RFC 2460 "flows" can correspond to a > single "flow descriptor", as Christian has pointed out with the TCP > example. >=20 > A less important thing is the use of "descriptor" which, while not > necessarily incorrect, has been quite often used as a number pointing > to an item in a repository, in a similar fashion to identifier. I was > thinking that "selector" might be more appropriate... >=20 > In light of this, I'm now wondering whether the terminology would be > more consistent if we'd refer to RFC 2460 for the definition of a flow > and renamed throughout the ID: >=20 > - flow =3D> flow aggregate > - flow descriptor =3D> flow aggregate selector > - flow ID =3D> flow aggregate ID / flow aggregate descriptor >=20 > What do you think? =3D> I'm wondering whether we would have to always write "flow or flow aggregate" in the doc because it's not always about a bunch of flows. Alternatively, if we don't define a flow as being from a single source, the= n we can just use "flow". I don't have a problem with the other two terms you suggest above.=20 Hesham >=20 > --julien From julienl@qualcomm.com Tue Jul 21 20:39:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226BC3A6909 for ; Tue, 21 Jul 2009 20:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 otR8EbOZJblF for ; Tue, 21 Jul 2009 20:39:56 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id F0B903A6853 for ; Tue, 21 Jul 2009 20:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1248233996; x=1279769996; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Hesham=20Soliman=20|CC: =20Christian=20Kaas-Petersen=20, =0D=0A=20=20=20=20=20=20=20=20"mext@ietf.org"=0D=0A=09|Date:=20Tue,=2021=20Jul=202009=2020:39:47=20 -0700|Subject:=20RE:=20[MEXT]=20flow=20binding=20draft=20 3|Thread-Topic:=20[MEXT]=20flow=20binding=20draft=203 |Thread-Index:=20AcoKbFwEUVEp5H/gKUaJrvdBn/t7FQAEAIcA |Message-ID:=20|References:=20<7ad6d6db090 7211140pac4de0fw894e39a80df5a4fd@mail.gmail.com>=0D=0A=20 |In-Reply-To:=20< C68CA971.E616%hesham@elevatemobile.com>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5683"=3B=20a=3D"21057233"; bh=DUQAvVkRsQLR3S3FvqyqFg7cswzW81rVX1l9r+xd/K4=; b=gUNc3nqdwc67T6c0PNhrREJVNFiTvgUNWG8kaFjf3zZ7jSYfAaUH1K8t PLlOpFv3O+i5qP5WWCsKKmDrlNZTQQhOSxVk0e3JEeWdsu7e1Am3LDgu9 tpYFwQgDfEqxfVhdpB1YGg2ffqxTS0Lbp0D24nze7KOfnTgzeBLp6Re0j U=; X-IronPort-AV: E=McAfee;i="5300,2777,5683"; a="21057233" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jul 2009 20:39:54 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6M3drYY021904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Jul 2009 20:39:53 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6M3dqTV011000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jul 2009 20:39:53 -0700 (PDT) Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 21 Jul 2009 20:39:52 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Tue, 21 Jul 2009 20:39:51 -0700 From: "Laganier, Julien" To: Hesham Soliman Date: Tue, 21 Jul 2009 20:39:47 -0700 Thread-Topic: [MEXT] flow binding draft 3 Thread-Index: AcoKbFwEUVEp5H/gKUaJrvdBn/t7FQAEAIcA Message-ID: References: <7ad6d6db0907211140pac4de0fw894e39a80df5a4fd@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 03:39:57 -0000 > Hesham Soliman wrote: >=20 > On 22/07/09 4:40 AM, "Laganier, Julien" wrote: > > > > I realize it's a bit late, but in light of this discussion, given the > > flow definition of RFC 2460, and given the mechanism we want to > > provide, namely, "extensions to Mobile IPv6 that allow nodes to bind > > one or more flows to a care-of address", I'm feeling that most of > the > > time when the draft refers to a "flow" it should instead refer to a > > "flow aggregate" because multiple RFC 2460 "flows" can correspond to > a > > single "flow descriptor", as Christian has pointed out with the TCP > > example. > > > > A less important thing is the use of "descriptor" which, while not > > necessarily incorrect, has been quite often used as a number pointing > > to an item in a repository, in a similar fashion to identifier. I was > > thinking that "selector" might be more appropriate... > > > > In light of this, I'm now wondering whether the terminology would be > > more consistent if we'd refer to RFC 2460 for the definition of a > flow > > and renamed throughout the ID: > > > > - flow =3D> flow aggregate > > - flow descriptor =3D> flow aggregate selector > > - flow ID =3D> flow aggregate ID / flow aggregate descriptor > > > > What do you think? >=20 > =3D> I'm wondering whether we would have to always write "flow or flow > aggregate" in the doc because it's not always about a bunch of flows. > Alternatively, if we don't define a flow as being from a single source, > then we can just use "flow". I don't have a problem with the other two te= rms > you suggest above. I think we should stick to RFC 2460 for the definition of a flow, i.e., "a = sequence of packets sent from a particular source to a particular (unicast = or multicast) destination for which the source desires special handling by = the intervening routers." After thinking a bit more to the term "aggregate", I do not think anymore t= hat "flow aggregate" is a good term because in a situation where we have a = traffic selector that matches all HTTP flows (i.e., proto tcp port 80), it'= s likely that the traffic is disaggregated since every flow goes to a diffe= rent web server. How about we use "flow" in the sense of 2460 and its plural form where requ= ired, and "traffic selector" and "traffic selector descriptor/ID" where tal= king about the object that matches a bunch of "flows", and the reference to= it? --julien From hesham@elevatemobile.com Tue Jul 21 20:44:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E574A3A67A6 for ; Tue, 21 Jul 2009 20:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] 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 oDs-yb+zAmdb for ; Tue, 21 Jul 2009 20:44:23 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 136E73A635F for ; Tue, 21 Jul 2009 20:44:22 -0700 (PDT) Received: from [114.75.41.93] (helo=[192.168.0.3]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MTSkb-0003nT-VQ; Wed, 22 Jul 2009 13:44:18 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 22 Jul 2009 13:44:09 +1000 From: Hesham Soliman To: "Laganier, Julien" Message-ID: Thread-Topic: [MEXT] flow binding draft 3 Thread-Index: AcoKbFwEUVEp5H/gKUaJrvdBn/t7FQAEAIcAAACTTNo= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: "mext@ietf.org" Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 03:44:24 -0000 >> >> => I'm wondering whether we would have to always write "flow or flow >> aggregate" in the doc because it's not always about a bunch of flows. >> Alternatively, if we don't define a flow as being from a single source, >> then we can just use "flow". I don't have a problem with the other two terms >> you suggest above. > > I think we should stick to RFC 2460 for the definition of a flow, i.e., "a > sequence of packets sent from a particular source to a particular (unicast or > multicast) destination for which the source desires special handling by the > intervening routers." > => Agreed. > > After thinking a bit more to the term "aggregate", I do not think anymore that > "flow aggregate" is a good term because in a situation where we have a traffic > selector that matches all HTTP flows (i.e., proto tcp port 80), it's likely > that the traffic is disaggregated since every flow goes to a different web > server. => Yes. > > How about we use "flow" in the sense of 2460 and its plural form where > required, => Right, or we can say somewhere early in the doc that we will use the word "flow" to indicate the singular and plural. and "traffic selector" and "traffic selector descriptor/ID" where > talking about the object that matches a bunch of "flows", and the reference to > it? => I'm ok with that. Hesham > > --julien From julienl@qualcomm.com Wed Jul 22 12:13:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A9F3A6BF9 for ; Wed, 22 Jul 2009 12:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 sXQpq1hj9076 for ; Wed, 22 Jul 2009 12:13:03 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7196B3A68AE for ; Wed, 22 Jul 2009 12:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1248289984; x=1279825984; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Hesham=20Soliman=20|CC: =20Christian=20Kaas-Petersen=20, =0D=0A=20=20=20=20=20=20=20=20"mext@ietf.org"=0D=0A=09|Date:=20Wed,=2022=20Jul=202009=2012:12:12=20 -0700|Subject:=20RE:=20[MEXT]=20flow=20binding=20draft=20 3|Thread-Topic:=20[MEXT]=20flow=20binding=20draft=203 |Thread-Index:=20AcoKbFwEUVEp5H/gKUaJrvdBn/t7FQAEAIcAAACT TNoAIEu9kA=3D=3D|Message-ID:=20 |References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5684"=3B=20a=3D"21077705"; bh=xtX0VyVaDAkJSRcVpdEQNnrGQvhin53wnPp5jUJnG+4=; b=AWTJHVTHCJ5ty0ePeeirPlK2CURbXEGQgQ5wbXuPgjqhTWHcpkfaKn/U LzSNMoN+oqgTM33u5LJ4g3e7yv6rhyrmoJBTSYNALzgaVm8jJb+7J10+7 IYuXnKTZWTNdyPpALftREIa0eiyeCRkFlrdtcFjtlHH72RAE73G2MvLol c=; X-IronPort-AV: E=McAfee;i="5300,2777,5684"; a="21077705" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2009 12:12:25 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6MJCOso003018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jul 2009 12:12:25 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6MJCEBL013929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Jul 2009 12:12:14 -0700 (PDT) Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 22 Jul 2009 12:12:14 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Wed, 22 Jul 2009 12:12:14 -0700 From: "Laganier, Julien" To: Hesham Soliman Date: Wed, 22 Jul 2009 12:12:12 -0700 Thread-Topic: [MEXT] flow binding draft 3 Thread-Index: AcoKbFwEUVEp5H/gKUaJrvdBn/t7FQAEAIcAAACTTNoAIEu9kA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:14:11 -0000 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Tuesday, July 21, 2009 8:44 PM > To: Laganier, Julien > Cc: Christian Kaas-Petersen; mext@ietf.org > Subject: Re: [MEXT] flow binding draft 3 >=20 >=20 > >> > >> =3D> I'm wondering whether we would have to always write "flow or flow > >> aggregate" in the doc because it's not always about a bunch of > flows. > >> Alternatively, if we don't define a flow as being from a single > source, > >> then we can just use "flow". I don't have a problem with the other > two terms > >> you suggest above. > > > > I think we should stick to RFC 2460 for the definition of a flow, > > i.e., "a sequence of packets sent from a particular source to a=20 > > particular (unicast or multicast) destination for which the=20 > > source desires special handling by the intervening routers." >=20 > =3D> Agreed. >=20 > > After thinking a bit more to the term "aggregate", I do not think > > anymore that "flow aggregate" is a good term because > > in a situation where we have a traffic selector that matches all=20 > > HTTP flows (i.e., proto tcp port 80), it's likely > > that the traffic is disaggregated since every flow goes to a > > different web server. >=20 > =3D> Yes. >=20 > > How about we use "flow" in the sense of 2460 and its plural form > > where required, >=20 > =3D> Right, or we can say somewhere early in the doc that we will use the > word "flow" to indicate the singular and plural. I think easiest is to use "flow" when we talk about one, "flows" when we ta= lk about more than one, and "flow(s)" where we talk about one or more flow(= s). =20 > > and "traffic selector" and "traffic selector descriptor/ID" where > > talking about the object that matches a bunch of "flows", and the > reference to > > it? >=20 > =3D> I'm ok with that. All right then. --julien=20 From marcelo@it.uc3m.es Wed Jul 22 12:44:59 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327073A6A5C for ; Wed, 22 Jul 2009 12:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, 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 OdY4OJR0othJ for ; Wed, 22 Jul 2009 12:44:58 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 29AF93A6C38 for ; Wed, 22 Jul 2009 12:44:50 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (34.pool85-53-136.dynamic.orange.es [85.53.136.34]) by smtp01.uc3m.es (Postfix) with ESMTP id 07936BA010D for ; Wed, 22 Jul 2009 21:12:21 +0200 (CEST) Message-ID: <4A676495.8020007@it.uc3m.es> Date: Wed, 22 Jul 2009 21:12:21 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16778.007 Subject: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:44:59 -0000 Hi, There has been a long discussion about the possibility of supporting the HA to send flow bindings to the MN. Currently, we don't think there is clear use case for that (in the sense that the use case doesn't seem to be widely understood by the WG). Since there are some WG members that have stated that they do have a clear use case for this, we would like to suggest them to present it in the next meeting, to see if we can move move forward with figuring out if we need to support this or not. So, we would like to ask to all those that have stated that there is a use for this, to contact the chairs in the case they are willing to make a presentation about this in the next meeting. Please note well that the presentation we are asking for is NOT about the protocols extensions that are needed to send a flow binding from the HA to the MN. What we are asking for is a clear use case, that includes depicting a complete scenario where it makes sense and it is useful for the HA to send a flow binding to the MN. If nobody is able to make this case, i guess we will have to assume that this use case does not exist and act accordingly. Regards, marcelo From marcelo@it.uc3m.es Wed Jul 22 13:34:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C49A3A6800 for ; Wed, 22 Jul 2009 13:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 T13mv5-v1n+R for ; Wed, 22 Jul 2009 13:34:13 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 6E7573A67AF for ; Wed, 22 Jul 2009 13:34:12 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (34.pool85-53-136.dynamic.orange.es [85.53.136.34]) by smtp03.uc3m.es (Postfix) with ESMTP id B017B7F2B82; Wed, 22 Jul 2009 22:32:59 +0200 (CEST) Message-ID: <4A67777B.8090707@it.uc3m.es> Date: Wed, 22 Jul 2009 22:32:59 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Frank Xia References: <4A676495.8020007@it.uc3m.es> <003601ca0b0a$e0187c40$3e0c7c0a@china.huawei.com> In-Reply-To: <003601ca0b0a$e0187c40$3e0c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16778.007 Cc: mext Subject: Re: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 20:34:14 -0000 this is not exactly what we are asking for. What we asked for is that the people that are willing to make such presentation, contact the chairs so we can coordinate how to do this. So, thanks for volunteering, we will wait of there is more people who is willing to do this, so we can coordiante. Regards, marcelo Frank Xia escribió: > Hi Marcelo > > We will make a presentation on use cases > that need HA->MN flow binding operation. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "mext" > Sent: Wednesday, July 22, 2009 2:12 PM > Subject: [MEXT] Flow bindings in the HA->MN direction > > >> Hi, >> >> There has been a long discussion about the possibility >> of supporting the HA to send flow bindings to the MN. >> >> Currently, we don't think there is clear use case for that >> (in the sense that the use case doesn't seem to be widely >> understood by the WG). >> >> Since there are some WG members that have stated that they >> do have a clear use case for this, we would like to suggest >> them to present it in the next meeting, to see if we can move >> move forward with figuring out if we need to support this >> or not. >> >> So, we would like to ask to all those that have stated that >> there is a use for this, to contact the chairs in the >> case they are willing to make a presentation about this in >> the next meeting. >> >> Please note well that the presentation we are asking for is >> NOT about the protocols extensions that are needed to send >> a flow binding from the HA to the MN. >> What we are asking for is a clear use case, that includes >> depicting a complete scenario where it makes sense and it is >> useful for the HA to send a flow binding to the MN. >> >> If nobody is able to make this case, i guess we will >> have to assume that this use case does not exist and >> act accordingly. >> >> Regards, marcelo >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > From xiayangsong@huawei.com Wed Jul 22 13:50:58 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775613A6B64 for ; Wed, 22 Jul 2009 13:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 nSaW75hCcIIP for ; Wed, 22 Jul 2009 13:50:57 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A4DDC28C107 for ; Wed, 22 Jul 2009 13:50:57 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN7003Y0B7HM5@szxga03-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 04:50:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN7007C5B7HYW@szxga03-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 04:50:05 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN7007P3B7FD7@szxml04-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 04:50:05 +0800 (CST) Date: Wed, 22 Jul 2009 15:50:03 -0500 From: Frank Xia To: marcelo bagnulo braun , mext Message-id: <005801ca0b0d$fdd697a0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A676495.8020007@it.uc3m.es> Subject: Re: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 20:50:58 -0000 Hi Marcelo Here is a comment on you summary. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "mext" Sent: Wednesday, July 22, 2009 2:12 PM Subject: [MEXT] Flow bindings in the HA->MN direction > Hi, > > There has been a long discussion about the possibility > of supporting the HA to send flow bindings to the MN. > > Currently, we don't think there is clear use case for that > (in the sense that the use case doesn't seem to be widely > understood by the WG). Frank=>IMHO, there is clear consensus that HA should be able to send flow bindings revocation to MN. > > Since there are some WG members that have stated that they > do have a clear use case for this, we would like to suggest > them to present it in the next meeting, to see if we can move > move forward with figuring out if we need to support this > or not. > > So, we would like to ask to all those that have stated that > there is a use for this, to contact the chairs in the > case they are willing to make a presentation about this in > the next meeting. > > Please note well that the presentation we are asking for is > NOT about the protocols extensions that are needed to send > a flow binding from the HA to the MN. > What we are asking for is a clear use case, that includes > depicting a complete scenario where it makes sense and it is > useful for the HA to send a flow binding to the MN. > > If nobody is able to make this case, i guess we will > have to assume that this use case does not exist and > act accordingly. > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From xiayangsong@huawei.com Wed Jul 22 13:58:58 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046643A6AC1 for ; Wed, 22 Jul 2009 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 5KqsjMg7kYK8 for ; Wed, 22 Jul 2009 13:58:57 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9E4633A6AA8 for ; Wed, 22 Jul 2009 13:58:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700ME1A6BSA@szxga04-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 04:27:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN7000AAA6BJT@szxga04-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 04:27:47 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN70014HA69GN@szxml04-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 04:27:47 +0800 (CST) Date: Wed, 22 Jul 2009 15:27:44 -0500 From: Frank Xia To: marcelo bagnulo braun , mext Message-id: <003601ca0b0a$e0187c40$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A676495.8020007@it.uc3m.es> Subject: Re: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 20:58:58 -0000 Hi Marcelo We will make a presentation on use cases that need HA->MN flow binding operation. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "mext" Sent: Wednesday, July 22, 2009 2:12 PM Subject: [MEXT] Flow bindings in the HA->MN direction > Hi, > > There has been a long discussion about the possibility > of supporting the HA to send flow bindings to the MN. > > Currently, we don't think there is clear use case for that > (in the sense that the use case doesn't seem to be widely > understood by the WG). > > Since there are some WG members that have stated that they > do have a clear use case for this, we would like to suggest > them to present it in the next meeting, to see if we can move > move forward with figuring out if we need to support this > or not. > > So, we would like to ask to all those that have stated that > there is a use for this, to contact the chairs in the > case they are willing to make a presentation about this in > the next meeting. > > Please note well that the presentation we are asking for is > NOT about the protocols extensions that are needed to send > a flow binding from the HA to the MN. > What we are asking for is a clear use case, that includes > depicting a complete scenario where it makes sense and it is > useful for the HA to send a flow binding to the MN. > > If nobody is able to make this case, i guess we will > have to assume that this use case does not exist and > act accordingly. > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From Basavaraj.Patil@nokia.com Wed Jul 22 14:04:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C2D28C11B for ; Wed, 22 Jul 2009 14:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, 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 fXiICyDoHKvW for ; Wed, 22 Jul 2009 14:04:41 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 2C5523A69BC for ; Wed, 22 Jul 2009 14:04:40 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6ML3e2E004390; Thu, 23 Jul 2009 00:03:41 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 00:03:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 00:03:49 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 22 Jul 2009 23:03:48 +0200 From: To: , Date: Wed, 22 Jul 2009 23:04:03 +0200 Thread-Topic: [MEXT] Flow bindings in the HA->MN direction Thread-Index: AcoLBO1dfBp8O1WnQfmsM8nW7epRHQACwOtp Message-ID: In-Reply-To: <4A676495.8020007@it.uc3m.es> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jul 2009 21:03:49.0406 (UTC) FILETIME=[E8F1DBE0:01CA0B0F] X-Nokia-AV: Clean Subject: Re: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:04:42 -0000 Hi Marcelo, On 7/22/09 2:12 PM, "Marcelo Bagnulo" wrote: > Hi, >=20 > There has been a long discussion about the possibility > of supporting the HA to send flow bindings to the MN. >=20 > Currently, we don't think there is clear use case for that > (in the sense that the use case doesn't seem to be widely > understood by the WG). Correct. I have yet to see a good use case which illustrates the need for the HA to be involved in creating the flow-bindings. >=20 > Since there are some WG members that have stated that they > do have a clear use case for this, we would like to suggest > them to present it in the next meeting, to see if we can move > move forward with figuring out if we need to support this > or not. I think not :) -Raj >=20 > So, we would like to ask to all those that have stated that > there is a use for this, to contact the chairs in the > case they are willing to make a presentation about this in > the next meeting. >=20 > Please note well that the presentation we are asking for is > NOT about the protocols extensions that are needed to send > a flow binding from the HA to the MN. > What we are asking for is a clear use case, that includes > depicting a complete scenario where it makes sense and it is > useful for the HA to send a flow binding to the MN. >=20 > If nobody is able to make this case, i guess we will > have to assume that this use case does not exist and > act accordingly. >=20 > Regards, marcelo >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Wed Jul 22 14:19:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DF23A6C04 for ; Wed, 22 Jul 2009 14:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, 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 ielPJ-AaqHOp for ; Wed, 22 Jul 2009 14:19:14 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id AEB313A67AA for ; Wed, 22 Jul 2009 14:19:13 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (34.pool85-53-136.dynamic.orange.es [85.53.136.34]) by smtp02.uc3m.es (Postfix) with ESMTP id 179556BAC47; Wed, 22 Jul 2009 23:17:05 +0200 (CEST) Message-ID: <4A6781D0.9020202@it.uc3m.es> Date: Wed, 22 Jul 2009 23:17:04 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Frank Xia References: <4A676495.8020007@it.uc3m.es> <005801ca0b0d$fdd697a0$3e0c7c0a@china.huawei.com> In-Reply-To: <005801ca0b0d$fdd697a0$3e0c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16780.000 Cc: mext Subject: Re: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:19:14 -0000 Frank Xia escribió: > Hi Marcelo > > Here is a comment on you summary. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "mext" > Sent: Wednesday, July 22, 2009 2:12 PM > Subject: [MEXT] Flow bindings in the HA->MN direction > > >> Hi, >> >> There has been a long discussion about the possibility >> of supporting the HA to send flow bindings to the MN. >> >> Currently, we don't think there is clear use case for that >> (in the sense that the use case doesn't seem to be widely >> understood by the WG). > Frank=>IMHO, there is clear consensus that HA should > be able to send flow bindings revocation to MN. > you are perfectly entitled to have that opinion, but i guess that the "designed consensus meters" are the chairs and i am afraid they don't share your opinion. Morevoer, as i stated earlier, it is not clear what the use case or application scenario is for such functionality Regards, marcelo >> >> Since there are some WG members that have stated that they >> do have a clear use case for this, we would like to suggest >> them to present it in the next meeting, to see if we can move >> move forward with figuring out if we need to support this >> or not. >> >> So, we would like to ask to all those that have stated that >> there is a use for this, to contact the chairs in the >> case they are willing to make a presentation about this in >> the next meeting. >> >> Please note well that the presentation we are asking for is >> NOT about the protocols extensions that are needed to send >> a flow binding from the HA to the MN. >> What we are asking for is a clear use case, that includes >> depicting a complete scenario where it makes sense and it is >> useful for the HA to send a flow binding to the MN. >> >> If nobody is able to make this case, i guess we will >> have to assume that this use case does not exist and >> act accordingly. >> >> Regards, marcelo >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > From xiayangsong@huawei.com Wed Jul 22 15:11:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4313A6B12 for ; Wed, 22 Jul 2009 15:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 MkYS4NYuuoL5 for ; Wed, 22 Jul 2009 15:11:13 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0F6703A67F3 for ; Wed, 22 Jul 2009 15:11:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN7001M7E45B3@szxga04-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 05:52:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700LYLE45YF@szxga04-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 05:52:53 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN70077UE43D7@szxml04-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 05:52:53 +0800 (CST) Date: Wed, 22 Jul 2009 16:52:51 -0500 From: Frank Xia To: marcelo bagnulo braun Message-id: <010b01ca0b16$c3be86f0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A676495.8020007@it.uc3m.es> <005801ca0b0d$fdd697a0$3e0c7c0a@china.huawei.com> <4A6781D0.9020202@it.uc3m.es> Cc: mext Subject: Re: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:11:14 -0000 Hi Marcelo See inline... BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "Frank Xia" Cc: "mext" Sent: Wednesday, July 22, 2009 4:17 PM Subject: Re: [MEXT] Flow bindings in the HA->MN direction > Frank Xia escribió: >> Hi Marcelo >> >> Here is a comment on you summary. >> >> BR >> Frank >> >> ----- Original Message ----- From: "marcelo bagnulo braun" >> >> To: "mext" >> Sent: Wednesday, July 22, 2009 2:12 PM >> Subject: [MEXT] Flow bindings in the HA->MN direction >> >> >>> Hi, >>> >>> There has been a long discussion about the possibility >>> of supporting the HA to send flow bindings to the MN. >>> >>> Currently, we don't think there is clear use case for that >>> (in the sense that the use case doesn't seem to be widely >>> understood by the WG). >> Frank=>IMHO, there is clear consensus that HA should >> be able to send flow bindings revocation to MN. >> > you are perfectly entitled to have that opinion, but i guess that the > "designed consensus meters" are the chairs and i am afraid they don't > share your opinion. > Morevoer, as i stated earlier, it is not clear what the use case or > application scenario is for such functionality Frank=>Not very sure what is your point. Just let me be clear. As for flow binding revocation, Hesham said "Some people mentioned that the HA should be able to revoke flows on the MN. I'm perfectly fine with that". http://www.ietf.org/mail-archive/web/mext/current/msg03407.html Nicolas said "As said in previous emails in this thread, yes, this is a valid use case IMHO." http://www.ietf.org/mail-archive/web/mext/current/msg03399.html So far, no one is against. > > Regards, marcelo > > >>> >>> Since there are some WG members that have stated that they >>> do have a clear use case for this, we would like to suggest >>> them to present it in the next meeting, to see if we can move >>> move forward with figuring out if we need to support this >>> or not. >>> >>> So, we would like to ask to all those that have stated that >>> there is a use for this, to contact the chairs in the >>> case they are willing to make a presentation about this in >>> the next meeting. >>> >>> Please note well that the presentation we are asking for is >>> NOT about the protocols extensions that are needed to send >>> a flow binding from the HA to the MN. >>> What we are asking for is a clear use case, that includes >>> depicting a complete scenario where it makes sense and it is >>> useful for the HA to send a flow binding to the MN. >>> >>> If nobody is able to make this case, i guess we will >>> have to assume that this use case does not exist and >>> act accordingly. >>> >>> Regards, marcelo >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> > From hesham@elevatemobile.com Wed Jul 22 18:44:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D663A6C82 for ; Wed, 22 Jul 2009 18:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 n3y6seI2smiQ for ; Wed, 22 Jul 2009 18:44:06 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id F30A73A6AFA for ; Wed, 22 Jul 2009 18:44:05 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MTmHy-0006tc-DI; Thu, 23 Jul 2009 10:36:02 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 23 Jul 2009 10:35:58 +1000 From: Hesham Soliman To: Frank Xia , marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] Flow bindings in the HA->MN direction Thread-Index: AcoLLYvH6Z3VCPBBM0ydJRlJFDoHew== In-Reply-To: <010b01ca0b16$c3be86f0$3e0c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: mext Subject: Re: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 01:44:07 -0000 Frank,=20 Obviusly not speaking on behalf of Marcelo, but since you're referring to m= y statement, I want to explain that my understanding of Marcelo's email is that it is not related to revokation of flows. He's talking about something else (installing flows). My email was saying that I'm ok with the HA revoking bindings, including flow bindings as a simple extension to binding revokation in general, which is already approved by the WG. So, if your concern is revokation of flow bindings I don't think you need t= o worry.=20 Hesham On 23/07/09 7:52 AM, "Frank Xia" wrote: > Hi Marcelo >=20 > See inline... >=20 > BR > Frank > ----- Original Message ----- > From: "marcelo bagnulo braun" > To: "Frank Xia" > Cc: "mext" > Sent: Wednesday, July 22, 2009 4:17 PM > Subject: Re: [MEXT] Flow bindings in the HA->MN direction >=20 >=20 >> Frank Xia escribi=F3: >>> Hi Marcelo >>>=20 >>> Here is a comment on you summary. >>>=20 >>> BR >>> Frank >>>=20 >>> ----- Original Message ----- From: "marcelo bagnulo braun" >>> >>> To: "mext" >>> Sent: Wednesday, July 22, 2009 2:12 PM >>> Subject: [MEXT] Flow bindings in the HA->MN direction >>>=20 >>>=20 >>>> Hi, >>>>=20 >>>> There has been a long discussion about the possibility >>>> of supporting the HA to send flow bindings to the MN. >>>>=20 >>>> Currently, we don't think there is clear use case for that >>>> (in the sense that the use case doesn't seem to be widely >>>> understood by the WG). >>> Frank=3D>IMHO, there is clear consensus that HA should >>> be able to send flow bindings revocation to MN. >>>=20 >> you are perfectly entitled to have that opinion, but i guess that the >> "designed consensus meters" are the chairs and i am afraid they don't >> share your opinion. >> Morevoer, as i stated earlier, it is not clear what the use case or >> application scenario is for such functionality > Frank=3D>Not very sure what is your point. Just let me be clear. >=20 > As for flow binding revocation, Hesham > said "Some people mentioned that the HA should be able > to revoke flows on the MN. I'm perfectly fine with that". > http://www.ietf.org/mail-archive/web/mext/current/msg03407.html >=20 > Nicolas said "As said in previous emails in this thread, yes, > this is a valid use case IMHO." > http://www.ietf.org/mail-archive/web/mext/current/msg03399.html >=20 > So far, no one is against. >=20 >>=20 >> Regards, marcelo >>=20 >>=20 >>>>=20 >>>> Since there are some WG members that have stated that they >>>> do have a clear use case for this, we would like to suggest >>>> them to present it in the next meeting, to see if we can move >>>> move forward with figuring out if we need to support this >>>> or not. >>>>=20 >>>> So, we would like to ask to all those that have stated that >>>> there is a use for this, to contact the chairs in the >>>> case they are willing to make a presentation about this in >>>> the next meeting. >>>>=20 >>>> Please note well that the presentation we are asking for is >>>> NOT about the protocols extensions that are needed to send >>>> a flow binding from the HA to the MN. >>>> What we are asking for is a clear use case, that includes >>>> depicting a complete scenario where it makes sense and it is >>>> useful for the HA to send a flow binding to the MN. >>>>=20 >>>> If nobody is able to make this case, i guess we will >>>> have to assume that this use case does not exist and >>>> act accordingly. >>>>=20 >>>> Regards, marcelo >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From xiayangsong@huawei.com Wed Jul 22 19:05:49 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB663A6A0E for ; Wed, 22 Jul 2009 19:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 IT22a96mSptQ for ; Wed, 22 Jul 2009 19:05:49 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 707B53A67F0 for ; Wed, 22 Jul 2009 19:05:48 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700K60PRHSK@szxga01-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 10:04:30 +0800 (CST) Received: from X24512z ([10.51.0.61]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN7000WYPREOF@szxga01-in.huawei.com> for mext@ietf.org; Thu, 23 Jul 2009 10:04:29 +0800 (CST) Date: Wed, 22 Jul 2009 20:07:37 -0500 From: Frank Xia To: Hesham Soliman , marcelo bagnulo braun Message-id: <015b01ca0b31$fa308fb0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: mext Subject: Re: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 02:05:50 -0000 Hi Hesham Thank for your explanation. IMHO, the goal should be the clarification of ambiguious charter which says " A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport" It is better to specify which kinds of HA->MN flowing binding operation are enabled. BR Frank ----- Original Message ----- From: "Hesham Soliman" To: "Frank Xia" ; "marcelo bagnulo braun" Cc: "mext" Sent: Wednesday, July 22, 2009 7:35 PM Subject: Re: [MEXT] Flow bindings in the HA->MN direction Frank, Obviusly not speaking on behalf of Marcelo, but since you're referring to my statement, I want to explain that my understanding of Marcelo's email is that it is not related to revokation of flows. He's talking about something else (installing flows). My email was saying that I'm ok with the HA revoking bindings, including flow bindings as a simple extension to binding revokation in general, which is already approved by the WG. So, if your concern is revokation of flow bindings I don't think you need to worry. Hesham On 23/07/09 7:52 AM, "Frank Xia" wrote: > Hi Marcelo > > See inline... > > BR > Frank > ----- Original Message ----- > From: "marcelo bagnulo braun" > To: "Frank Xia" > Cc: "mext" > Sent: Wednesday, July 22, 2009 4:17 PM > Subject: Re: [MEXT] Flow bindings in the HA->MN direction > > >> Frank Xia escribió: >>> Hi Marcelo >>> >>> Here is a comment on you summary. >>> >>> BR >>> Frank >>> >>> ----- Original Message ----- From: "marcelo bagnulo braun" >>> >>> To: "mext" >>> Sent: Wednesday, July 22, 2009 2:12 PM >>> Subject: [MEXT] Flow bindings in the HA->MN direction >>> >>> >>>> Hi, >>>> >>>> There has been a long discussion about the possibility >>>> of supporting the HA to send flow bindings to the MN. >>>> >>>> Currently, we don't think there is clear use case for that >>>> (in the sense that the use case doesn't seem to be widely >>>> understood by the WG). >>> Frank=>IMHO, there is clear consensus that HA should >>> be able to send flow bindings revocation to MN. >>> >> you are perfectly entitled to have that opinion, but i guess that the >> "designed consensus meters" are the chairs and i am afraid they don't >> share your opinion. >> Morevoer, as i stated earlier, it is not clear what the use case or >> application scenario is for such functionality > Frank=>Not very sure what is your point. Just let me be clear. > > As for flow binding revocation, Hesham > said "Some people mentioned that the HA should be able > to revoke flows on the MN. I'm perfectly fine with that". > http://www.ietf.org/mail-archive/web/mext/current/msg03407.html > > Nicolas said "As said in previous emails in this thread, yes, > this is a valid use case IMHO." > http://www.ietf.org/mail-archive/web/mext/current/msg03399.html > > So far, no one is against. > >> >> Regards, marcelo >> >> >>>> >>>> Since there are some WG members that have stated that they >>>> do have a clear use case for this, we would like to suggest >>>> them to present it in the next meeting, to see if we can move >>>> move forward with figuring out if we need to support this >>>> or not. >>>> >>>> So, we would like to ask to all those that have stated that >>>> there is a use for this, to contact the chairs in the >>>> case they are willing to make a presentation about this in >>>> the next meeting. >>>> >>>> Please note well that the presentation we are asking for is >>>> NOT about the protocols extensions that are needed to send >>>> a flow binding from the HA to the MN. >>>> What we are asking for is a clear use case, that includes >>>> depicting a complete scenario where it makes sense and it is >>>> useful for the HA to send a flow binding to the MN. >>>> >>>> If nobody is able to make this case, i guess we will >>>> have to assume that this use case does not exist and >>>> act accordingly. >>>> >>>> Regards, marcelo >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Wed Jul 22 20:45:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B182E3A6A27 for ; Wed, 22 Jul 2009 20:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] 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 SVfmxA3YhX1l for ; Wed, 22 Jul 2009 20:45:46 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id C71F63A67B0 for ; Wed, 22 Jul 2009 20:45:46 -0700 (PDT) Received: from [114.75.61.88] (helo=[192.168.0.3]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MTorS-0006sN-JB; Thu, 23 Jul 2009 13:20:51 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 23 Jul 2009 13:20:39 +1000 From: Hesham Soliman To: "Laganier, Julien" Message-ID: Thread-Topic: [MEXT] flow binding draft 3 Thread-Index: AcoKbFwEUVEp5H/gKUaJrvdBn/t7FQAEAIcAAACTTNoAIEu9kAARLMOZ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: "mext@ietf.org" Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 03:45:47 -0000 Sorry I got distracted by a few things and forgot to reply earlier. Yes I'm fine with your suggestion about the use of "flow(s)". Hesham On 23/07/09 5:12 AM, "Laganier, Julien" wrote: > > >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Tuesday, July 21, 2009 8:44 PM >> To: Laganier, Julien >> Cc: Christian Kaas-Petersen; mext@ietf.org >> Subject: Re: [MEXT] flow binding draft 3 >> >> >>>> >>>> => I'm wondering whether we would have to always write "flow or flow >>>> aggregate" in the doc because it's not always about a bunch of >> flows. >>>> Alternatively, if we don't define a flow as being from a single >> source, >>>> then we can just use "flow". I don't have a problem with the other >> two terms >>>> you suggest above. >>> >>> I think we should stick to RFC 2460 for the definition of a flow, >>> i.e., "a sequence of packets sent from a particular source to a >>> particular (unicast or multicast) destination for which the >>> source desires special handling by the intervening routers." >> >> => Agreed. >> >>> After thinking a bit more to the term "aggregate", I do not think >>> anymore that "flow aggregate" is a good term because >>> in a situation where we have a traffic selector that matches all >>> HTTP flows (i.e., proto tcp port 80), it's likely >>> that the traffic is disaggregated since every flow goes to a >>> different web server. >> >> => Yes. >> >>> How about we use "flow" in the sense of 2460 and its plural form >>> where required, >> >> => Right, or we can say somewhere early in the doc that we will use the >> word "flow" to indicate the singular and plural. > > I think easiest is to use "flow" when we talk about one, "flows" when we talk > about more than one, and "flow(s)" where we talk about one or more flow(s). > >>> and "traffic selector" and "traffic selector descriptor/ID" where >>> talking about the object that matches a bunch of "flows", and the >> reference to >>> it? >> >> => I'm ok with that. > > All right then. > > --julien > From hesham@elevatemobile.com Wed Jul 22 21:15:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723EE3A6B34 for ; Wed, 22 Jul 2009 21:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] 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 X7kDTOqcbyur for ; Wed, 22 Jul 2009 21:15:06 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 36DD53A69DC for ; Wed, 22 Jul 2009 21:15:05 -0700 (PDT) Received: from [114.75.61.88] (helo=[192.168.0.3]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MTpGy-0002Bg-Lu; Thu, 23 Jul 2009 13:47:13 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 23 Jul 2009 13:47:04 +1000 From: Hesham Soliman To: Frank Xia , marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] Flow bindings in the HA->MN direction Thread-Index: AcoLSD4L++eIrpqB2ESlF5+drhMgAA== In-Reply-To: <015b01ca0b31$fa308fb0$3e0c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: mext Subject: Re: [MEXT] Flow bindings in the HA->MN direction X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 04:15:07 -0000 That's a completely different point and that's addressed by the chair's email. I was referring to the specific quotes you mentioned earlier. Hesham On 23/07/09 11:07 AM, "Frank Xia" wrote: > Hi Hesham >=20 > Thank for your explanation. >=20 > IMHO, the goal should be the clarification of ambiguious > charter which says " > A "Flow/binding policies exchange" solution for > an exchange of policies from the mobile host/router > to the Home Agent and from the Home Agent to the > mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution > involves two specifications, one for the policy format > and another for its transport" >=20 > It is better to specify which kinds of HA->MN flowing > binding operation are enabled. >=20 > BR > Frank >=20 > ----- Original Message ----- > From: "Hesham Soliman" > To: "Frank Xia" ; "marcelo bagnulo braun" > > Cc: "mext" > Sent: Wednesday, July 22, 2009 7:35 PM > Subject: Re: [MEXT] Flow bindings in the HA->MN direction >=20 >=20 > Frank, >=20 > Obviusly not speaking on behalf of Marcelo, but since you're referring to= my > statement, I want to explain that my understanding of Marcelo's email is > that it is not related to revokation of flows. He's talking about somethi= ng > else (installing flows). My email was saying that I'm ok with the HA > revoking bindings, including flow bindings as a simple extension to bindi= ng > revokation in general, which is already approved by the WG. >=20 > So, if your concern is revokation of flow bindings I don't think you need= to > worry. >=20 > Hesham >=20 >=20 > On 23/07/09 7:52 AM, "Frank Xia" wrote: >=20 >> Hi Marcelo >>=20 >> See inline... >>=20 >> BR >> Frank >> ----- Original Message ----- >> From: "marcelo bagnulo braun" >> To: "Frank Xia" >> Cc: "mext" >> Sent: Wednesday, July 22, 2009 4:17 PM >> Subject: Re: [MEXT] Flow bindings in the HA->MN direction >>=20 >>=20 >>> Frank Xia escribi=F3: >>>> Hi Marcelo >>>>=20 >>>> Here is a comment on you summary. >>>>=20 >>>> BR >>>> Frank >>>>=20 >>>> ----- Original Message ----- From: "marcelo bagnulo braun" >>>> >>>> To: "mext" >>>> Sent: Wednesday, July 22, 2009 2:12 PM >>>> Subject: [MEXT] Flow bindings in the HA->MN direction >>>>=20 >>>>=20 >>>>> Hi, >>>>>=20 >>>>> There has been a long discussion about the possibility >>>>> of supporting the HA to send flow bindings to the MN. >>>>>=20 >>>>> Currently, we don't think there is clear use case for that >>>>> (in the sense that the use case doesn't seem to be widely >>>>> understood by the WG). >>>> Frank=3D>IMHO, there is clear consensus that HA should >>>> be able to send flow bindings revocation to MN. >>>>=20 >>> you are perfectly entitled to have that opinion, but i guess that the >>> "designed consensus meters" are the chairs and i am afraid they don't >>> share your opinion. >>> Morevoer, as i stated earlier, it is not clear what the use case or >>> application scenario is for such functionality >> Frank=3D>Not very sure what is your point. Just let me be clear. >>=20 >> As for flow binding revocation, Hesham >> said "Some people mentioned that the HA should be able >> to revoke flows on the MN. I'm perfectly fine with that". >> http://www.ietf.org/mail-archive/web/mext/current/msg03407.html >>=20 >> Nicolas said "As said in previous emails in this thread, yes, >> this is a valid use case IMHO." >> http://www.ietf.org/mail-archive/web/mext/current/msg03399.html >>=20 >> So far, no one is against. >>=20 >>>=20 >>> Regards, marcelo >>>=20 >>>=20 >>>>>=20 >>>>> Since there are some WG members that have stated that they >>>>> do have a clear use case for this, we would like to suggest >>>>> them to present it in the next meeting, to see if we can move >>>>> move forward with figuring out if we need to support this >>>>> or not. >>>>>=20 >>>>> So, we would like to ask to all those that have stated that >>>>> there is a use for this, to contact the chairs in the >>>>> case they are willing to make a presentation about this in >>>>> the next meeting. >>>>>=20 >>>>> Please note well that the presentation we are asking for is >>>>> NOT about the protocols extensions that are needed to send >>>>> a flow binding from the HA to the MN. >>>>> What we are asking for is a clear use case, that includes >>>>> depicting a complete scenario where it makes sense and it is >>>>> useful for the HA to send a flow binding to the MN. >>>>>=20 >>>>> If nobody is able to make this case, i guess we will >>>>> have to assume that this use case does not exist and >>>>> act accordingly. >>>>>=20 >>>>> Regards, marcelo >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 From arno@natisbad.org Thu Jul 23 04:15:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793623A6AAF for ; Thu, 23 Jul 2009 04:15:42 -0700 (PDT) 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 JuzoqhqVbLwN for ; Thu, 23 Jul 2009 04:15:39 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id A2E823A6A43 for ; Thu, 23 Jul 2009 04:15:38 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MTvgR-0002QH-4p; Thu, 23 Jul 2009 12:37:55 +0200 X-Hashcash: 1:20:090723:mext@ietf.org::oY2t0DxOGaIaQ6UJ:00001iKS X-Hashcash: 1:20:090723:basavaraj.patil@nokia.com::SZC0ViCuK0NZlams:0000000000000000000000000000000000003v7n From: arno@natisbad.org (Arnaud Ebalard) To: mext@ietf.org X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Thu, 23 Jul 2009 12:38:32 +0200 Message-ID: <87k51zfzvb.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Basavaraj Patil Subject: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 11:15:42 -0000 Hi, below is a review of draft-patil-mext-mip6issueswithipsec-01. > 1. Introduction > > Mobile IPv6 as specified in RFC3775 [RFC3775] requires an IPsec > security association between the mobile node (MN) and home agent > (HA). The IPsec SA protects the mobility signaling messages between > the MN and HA. The user data may be optionally protected by the > IPsec SA but is not required. > > The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified > in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6 > working groups in the IETF chose to mandate IPsec as the default > security protocol for Mobile IPv6 based on various criteria and > lengthy discussions that occured between the years 2000 and 2004. > Implementation experience with Mobile IPv6 and the security variants > with which it has been specified in some SDOs You should introduce the SDOs here i.e. have "some SDOs (XXX, YYY, ...). They are *never* cited in the whole document. The issues common and specific to each of those about IPsec/IKE should be summarized in the document. > indicates a need to > revisit the design choice for MIP6 signaling security. The analysis > and recommendation to revisit the security protocol architecture for > MIP6 should not be interpreted as a recommendation for Authentication > Protocol for Mobile IPv6 [RFC4285]. The objective is to highlight > the misfit of IPsec and IKEv2 as the security protocol for MIP6 and > hence the need for considering alternatives. > > > 2. Terminology and Abbreviations > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > This document refers to [RFC3775][RFC4877] for terminology. > > > 3. Background > > IP mobility support in IPv6 was considered to be an integral feature > of the IPv6 stack based on the experience gained from developing > mobility support for IPv4. The design of Mobile IPv6 was worked on > by the Mobile IP WG in the late 90s and by the MIP6 WG until its > publication as [RFC3775] in 2004. > > IPsec [RFC4301] was also intended to be a default component of the > IPv6 stack and was the preferred protocol choice for use by any other > IPv6 protocol that needed security. Rather than design security into > every protocol feature, the intent was to reuse a well-defined > security protocol to meet the security needs. Hence Mobile IPv6 has > been designed with the security architecture relying on IPsec. > > The Mobile IPv6 specification [RFC3775] was published along with the > companion specification "Using IPsec to Protect Mobile IPv6 Signaling > Between Mobile Nodes and Home Agents", [RFC3776]. The establishment > of the IPsec SA between the MN and HA as per RFC 3776 is based on the > use of IKE. Optional use of IKE. Nonetheless, I agree that using IKE is the only possible way to go when you need to scale. > The use of IKE in the context of Mobile IPv6 for IPsec > SA establishment did not gain traction because of factors such as > complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG > completed the specification, Mobile IPv6 Operation with IKEv2 and the > Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] > is considered as the default security protocol solution for MIP6 and > updates [RFC3776]. I agree. > 4. Problem Statement > > Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an > implementation and deployment perspective. As a protocol solution > for host based mobility, MIP6 can be simpler without the IPsec > baggage. The issues with IPsec are even more exacerbated in the case > of dual-stack MIP6 [RFC5555]. Sorry, but the design decisions taken for DSMIPv6 make it the way it is. You cannot blame IPsec/IKE for IPv4/NAT issues. The problem with DS-MIPv6 is that it does not provide IPv6 connectivity for the MN that could be used transparently by the stack (Teredo does that). When the protocol has been designed, it has been decided to open the door to IPv4, which let the NAT issue enter. Due to that decision, the difficulties of IPv4/NAT have also impacted the use of DSMIPv6 with IPsec/IKE. I would be interested to have the honest opinion of the main contributors of RFC 5555 on that topic. > IPsec SAs between the MN and HA are established either manually or > via the use of IKEv2 [RFC4306]. Manual SA configuration is not a > scalable solution and hence MIP6 hosts and Home agents rely on IKEv2 > for establishing dynamically IPsec SAs. As a result MIP6 depends on > the existence of IPsec and IKEv2 for successful operation. yes. > IPsec is unable to provide security protection for MIP6 in a > transparent way, and numerous interactions between the host's > security subsystems and the MIP6 application are needed in the course > of the regular operation of the MIP6 application. For common scenario, MIGRATE/KMADDRESS solution is sufficient. This requires small changes to the IPsec stack, the IKE daemon and the MIPv6 module. After 3776, it is my feeling that MEXT documents have slowly shifted towards tighter relationships between the MIPv6 module and the IKE (address assignment) module to the point that it would be difficult today to provide all the functionalities pushed so far without having a common MIPv6/IKE module (or at least complex interactions between those). > Besides requiring an extensive communications channel between the > security subsystems and the MIP6 application, those interactions > often also require modification of the MNs security subsystems > code. Well, I expect all possible L3 solutions to require changes to the security subsystems to support MIPv6 needs but I'd like to be proven wrong. > The situation today is such that the communications channel > between the IPsec subsystems and the MIP6 application is non > existent and this is generally true for most of the commercially > available platforms. The sentence is correct. Well, I won't advocate for other platforms but at least Linux has that now, which proves it is feasible: - Upstream Kernel supports full MIGRATE/KMADDRESS since 2.6.28. Current is 2.6.30. - racoon (IKEv1) has support for MIGRATE/KMADDRESS for a while now - StrongSwan developers have added support for MIGRATE/KMADDRESS to Charon, their IKEv2 daemon. - patches exist for racoon2 I can't say about *BSD platform. > Even if such a channel were to be available, there does not exist a > standardized protocol over that channel which would enable the MIP6 > application to communicate with the security modules in a non- > implementation specific way. Well, I already pointed that and even provided follow-up work for MIGRATE/KMADDRESS but this was considered out of scope for the WG. Having that work done in the context of ipsecme WG was not possible either. But thanks for stressing that point. > Considering a third party application developer who would like to > provide a MIP6 application for a particular platform, the need for > numerous interactions with the IPsec subsystem and the unavailability > of the standardized communications channel through which such > interactions could take place is a major obstacle to the > implementation of the mobility protocol. Without such a > communication channel being available it is not possible to implement > a MIP6 application as a third party developer. 3 main possible solutions: - standardize the interface - make MIPv6 module and IKEv2 module a common module (as progressively expected by MEXT documents published after 3775) - give up on the use of IPsec/IKE > Even if the platform would provide such a communication interface for > the MIP6 daemon, this is still insufficient as the MIP6 protocol > standardized today [RFC3775] requires numerous changes to the host's > IPsec and IKEv2 implementation. This document enumerates various > implementation issues related to the interactions between the MIP6 > application and the host's security subsystems. > > An argument can be made that the MIP6 application itself should > provide the required changes to the IPsec subsystems of the platform > (maybe in the form of patches). While this is possible at least for > some open source platforms to provide modifications to the host's > IPsec implementation as well as the key management application(s), > this is still an issue for several reasons: > > o Target platform could be a commercial platform for which no source > code is available. > o If the MIP6 application were to patch the IPsec subsystems, then > multiple MIP6 applications from different developers would > implement it in different ways, which would inevitably lead to > variations and problems with interoperability at a minimum, for > instance when the user tries to install several MIP6 applications > it is difficult to determine which one is the best suited for his/ > her needs. > o Key management daemons are usually provided as third party > software for which no source code may be available, even if the > platform itself is available as open source. > o Even if the MIP6 application developer would be willing to provide > patches for the key management daemon to make it work with his > MIP6 application, how would the MIP6 application developer know > which of the several available key management daemons the user is > running? > o Each application would be able to work only with a single key > management daemon, namely the one for which the MIP6 application > provides the patches. The user may be running another key > management daemon and may be unwilling to change its daemon to the > one that comes as part of the MIP6 application. > o Patches for the IPsec part in the kernel and the key management > daemon would typically be valid only for the particular version of > the kernel and the key management daemon for which they were > written. This might prevent the user from upgrading the platform > or applying OS security patches that are provided as part of the > regular platform maintenance since this would in all probability > make the MIP6 application defunct. > o Modifying the security subsystems by a third party is a security > issue and users are generally advised to refrain from allowing the > security subsystems to be modified in any way. > o The developer may not have the knowledge or the time to modify the > platform's IPsec subsystems, although it might be perfectly > capable to deliver the MIP6 application itself. > o There could be copyright issues as well that would prevent > modifications of the platform's security subsystems or the > delivery of the modifications by the third party. > o Even if the MIP6 application developer is able to come up with the > necessary patches for the security subsystem, it is not realistic > to expect the prospective user of MIPv6 to first patch the kernel > and the key management daemons before using the MIPv6 service. > > The above discussion shows why it is unrealistic to expect that the > MIP6 application could provide the needed modifications to the IPsec > subsystems of the host. Section 6 presents a more technical > discussion of various implementation issues related to the > interworking between the MIP6 application and the IPsec/key > management modules. > > The problem in a nutshell for MIP6 is the dependence on IPsec and > IKEv2 for successful operation. I respectfully disagree, not with the various points above, but with the way you interpret them. Vendors implement features in their products based on business case and possibly the availability of a standard. If open source product already have the feature, I think may indicate the issue is not the technical feasibility ... >From a discussion I had with some MS engineers after they unleashed the details on Vista's IPv6 stack, asking them for the reasons why it had no MIPv6 support: no business case and no standard interface to secure it. There are some people working for vendors (Cisco, ...) on MEXT so they can probably provide valuable comments on the reason why they don't have support for IPsec/IKE w/ MIPv6. Vendors that have support could also comment on how they did it and why. I think the points you give above shoud be interpreted the following way: to be easiliy implemented on a *commercial* platform without interactions with the associated vendors (implying business cases and money), it would be easier for MIPv6 to be self contained and with the least possible interactions with the networking stack, security stack and other third party applications (like IKE module). Hence a possible reason not to rely on IPsec and IKE. But this is only one side of the coin, i.e. there are drawbacks in taking such a path: how do you provide security? from scratch or based on another building block? can you support protection of IP data? What interface do you provide to users to enable the various protection modes? Does the solution target the IPv6 internet or only a small subset of it? > 5. General issues with the use of IPsec for MIP6 security > > This section captures several issues with the use of IPsec by MIP6. > > (1) The design of Mobile IPv6 emphasized the reuse of IPv6 features > such as IPsec. IPsec for IPv4 was a bolt-on solution. With the > increasing need for security, IPv6 designers chose to > incorporate IPsec as a default feature. There existed an > assumption in the MIP6 working group that every IPv6 host would > have IPsec capability as a standard feature. While this is true > in many host implementations today, the existence of IPsec in > every IPv6 stack is not a given. 3775 and 4877 provide a *generic* solution for the Internet environment, i.e. common platforms and systems. As you write, "[IPsec as a default feature] is true in many host implementations today". If specific systems have specific needs which do not fit with a generic solution, then they need a specific solution. If they are so specific, they may simply not be in the scope of MIPv6 generic solution. > Hence a host which needs to > implement Mobile IPv6 must ensure that IPsec and IKEv2 are also > available. As a result of this dependence, MIP6 is no longer a > standalone host-based mobility protocol. A good example of a > host based mobility protocol that works as a self-sufficient > module is Mobile IPv4 [RFC3344]. Section 5.5 (Privacy) of RFC 3344 has the following: Users who have sensitive data that they do not wish others to see should use mechanisms outside the scope of this document (such as encryption) to provide appropriate protection. Users concerned about traffic analysis should consider appropriate use of link encryption. The difference is that MIPv6 tries and address that instead of leaving the user alone. With MIPv4, extensions of the protocol to support full security have (what I consider) funny drawings like the following (RFC 5265): .------------------------------------------------------- - ! IP ! IP ! ESP ! IP ! IP ! user \ ! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../ ! x-HA ! VPN-GW ! ! i-HA ! CN ! \ `------------------------------------------------------- - - - -----------------. \..user ! ESP ! / protocol ! trailer ! \ ! ! - - -----------------' It was decided to make MIPv6 compatible with IPsec/IKE (and use those for the security). This allows more from a security standpoint but requires more initial investment. That initial investment seems to be considered too high a price for environments with different assumptions or existing security mechanisms. > MIP4 signaling is integrated into the protocol itself. MIP4 has > been successfully deployed on a large scale in several networks. Can you describe the assumptions about those network? Do they come with link layer security for instance? Can a user of those networks move to the Starbuck at the corner and use the wifi there without the need to care about how its data are protected on that foreign network? RFC 3775 Introduction starts with: "This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet" > (2) IPsec use in most hosts is generally for the purpose of VPN > connectivity to enterprises. It has not evolved into a generic > security protocol that can be used by Mobile IPv6 easily. While > RFC4877 does specify the details which enable only the MIP6 > signaling to be encapsulated with IPsec, the general method of > IPsec usage has been such that all traffic between a host and > the IPsec gateway is carried via the tunnel. Selective > application of IPsec to protocols is not the norm. Use of IPsec > with Mobile IPv6 requires configuration which in many cases is > not easily done because of reasons such as enterprise > environments preventing changes to IPsec policies or other. > (3) A MIP6 home agent is one end of the IPsec SA in a many-to-one > relationship. A MIP6 HA may support a very large number of > mobile nodes which could be in the hundreds of thousands to > millions. The ability to terminate a large number of IPsec SAs > (millions) requires signifiant hardware and platform capability. > The cost issues of such an HA are detrimental and hence act as a > barrier to deployment. Can some vendor comment on that. Do we agree that the amount of traffic is not the issue but the initial IKE negotiation and the number of SA might be? > (4) The implementation complexity of Mobile IPv6 is greatly > increased because of the interaction with IPsec and IKEv2. A > standalone MIP6 protocol is easier to implement and deploy (such > as MIP4 [RFC3344]). The complexity of the protocol > implementation is even more so in the case of Dual stack MIP6 > [RFC5555]. MIPv6 and MIPv4 do not have equivalent feature security-wise. MIPv6 is certainly more complex on that aspect than MIPv4 but it allows more. Moreover, it builds (even if some bits may be missing interface-wise) on existing and mature protocol (not speaking about IKEv2 yet ;-) ) which prevents reinventing the wheel. > (5) IPsec and IKEv2 are not implemented or available by default in > every IPv6 or dual stack host. Can you list some (2 or 3) systems that are of common use today and that do not have that? > Mobile IPv6 support on such devices is not an option. Many > low-end cellular hosts have IP stacks. The need for IPsec and > IKEv2 in these devices is not important whereas mobility > support is needed in many cases. I may be wrong but the way I see it is that current trend if for cellular devices to come with complete systems today: what does the iPhone runs? Nokia is currently shifting towards Linux based solutions (ofono, maemo, ...)? Many phones runs Windows Mobile too, ... If you consider the previous devices and most of the laptop (99% of the latter running Mac OS X, Linux or Windows), I think you have the initial targets MIPv6 is trying to provide mobility for. Or am I missing your point? > A simpler security protocol than the use of IPsec/IKEv2 would make > MIP6 much more attractive to implement and deploy. Those sepecific devices may need a specific solution. I agree on that. > (6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile > IPv6 essentially results in a variant of IPsec which is specific > to Mobile IP. No. IPsec stack and IKE daemon may already have support for MOBIKE which does exactly what we need. The only difference is that the signaling goes through the IKE channel. With MIPv6, signaling is MIPv6 one (BU/BA). In all cases, extending the IPsec stack to support MIPv6 is light. Same for IKE. > Hence this results in added complexity to implementations. No. Compare the small required extensions (MIGRATE/KMADRESS is short to read) with what it would cost to provide the same amount of features (protecting signaling and possibly data) but by designing and implementing a specific protocol in the MIPv6 module. IMHO, a simple extension cost less than a complete new design. And considering you are speaking about a security solution, designing from ground a new security solution for your own need is starting looking for trouble, all the more if you are trying to provide a L3 security solution, i.e. trying to compete with IPsec/IKE. > (7) Mobile IPv6 needs to be capable of being deployed in situations > where alternative security mechanisms are already well- > understood by the network administration. It should be possible > to enable Mobile IPv6 to work in situations where alternative > security mechanisms already supply the necessary authentication > and privacy. Agree. > (8) IPsec has been successfully applied to VPN and other > infrastructure operations, but less so for general end-to-end > applications. Thus, the granularity for selectors was > originally not at all sufficient for Mobile IPv6. Yes. The use of new IPsec architecture and IKEv2 in 4877 solved that issue. > (9) The way that the IPsec code sits in the usual kernel, and the > access mechanisms for the SA database, are not very convenient > for use by straightforward implementations of Mobile IPv6. > Unusual calling sequences and parameter passing seems to be > required on many platforms. Yes. Standardizing or at least providing some guidance on that would be helpful. > (10) In certain environments the use of IPsec and IKEv2 for > establishing the SA is considered as an overhead. Bandwidth > constrained links such as cellular networks and air interfaces > which are in the licensed spectrum tend to be optimized for user > traffic. Future Aeronautical environments have those constraints. Nonetheless, they will rely on IPsec and IKEv2 (see ICAO 9896 document). > MIP6 signaling with the IPsec overhead and the IKEv2 messages > are viewed negatively. It is more acceptable to have > signaling without IPsec encapsulation. Well, a security mechanism to protect MIPv6 signaling will certainly require some bits in each packet. Let's compare that to what ESP adds to be fair. > The issues listed above can be attributed as some of the causes for > MIP6 not being implemented widely. ;-) > 6. Implementation Issues with IPsec > > 6.1. Triggering IKEv2 on the MN > > When the MIP6 application is invoked on the MN, as part of the > initialization steps it is expected to install the appropriate SPD > entries for protecting the mobility management signaling. Creation > of the SPD entry works fine assuming that the MN is statically > preconfigured with the HoA information since the HoA address is > needed to create the SPD entries. Once the SPD entries are created, > the MIP6 application generates the BU message and sends it via the > socket. Based on the previously installed SPD entry the IP stack > detects that the BU message needs IPsec protection and since there is > no appropriate IPsec SA available, the OS kernel triggers the key > management daemon to establish the needed IPsec SA. Right. > Things are not that straightforward when the HoA is assigned > dynamically. MIP6 allows the MN to obtain the HoA dynamically during > the establishment of the initial IPsec SA with the HA [RFC4877] and > in this case the HoA is provided in the CONF IKEv2 payload. How is > the key management daemon triggered to establish the IPsec SA with > the HA in this case? Thanks for asking that question about section 9 of RFC 4877. I am on your side here. > Normally there should be an SPD entry in the SPD with the HoA > address as part of the selector and the outgoing BU message would > be matched against that entry and this would trigger the kernel to > request the establishment of the IPsec SA. But the > MIP6 application is not able to install the appropriate SPD entry nor > to generate the BU message since it doesn't have yet the HoA that is > needed for this, the HoA becomes available only later as part of the > IPsec SA establishment. So this is sort of a chicken and egg > problem: the HoA is needed to trigger the establishment of the IPsec > SAs, but the HoA is not available prior to the IPsec SA being > established. +1 > The solution to this issue could be an out-of-band communication > channel between the MIP6 application and the key management daemon > through which the MIP6 application could request the establishment of > the appropriate IPsec SA from the key management daemon without > having to install the appropriate SPD entries and generate the BU > message. yes. Or as it appears to be the underlying assumption a merged MIPv6/IKE module (I don't advocate for that). > 6.2. Instructing IKEv2 to ask for the MN HoA/prefix > > In case of dynamic HoA assignment, the MIP6 application needs to > instruct the key management daemon to request the HoA information > from the HA. The MIP6 application must be able to tell whether it > would like to get the complete address or only the prefix [RFC5026] > from the HA, and also whether it would like to get the IPv4 HoA as > part of the IKEv2 exchange. This requires an interface between the > MIP6 application and the key management daemon. If the feature is needed, yes. > 6.3. Providing the MN prefix to the IKEv2 daemon > > When the key management daemon on the HA side receives a request from > the initiator to allocate the MIP6_HOME_PREFIX it needs to get the > prefix from the MIP6 daemon running on the HA. Therefore there must > be a communication channel between the key management daemon and the > MIP6 application through which the key management daemon could > request the HoA/prefix information. Further, when assigning the > prefix, the MIP6 application needs to create state and save the > assigned address information and associate it with the MN which > created the IPsec SA. So this looks like at this point there is a > need to create the BCE in a some type of a "larval" state as a place > where to save this information on the HA side. > > Request to assign an address (IPv6 and/or IPv4) via the CONF payload > raises an additional concern, namely, how does the key management > daemon know that it needs to obtain the address from the MIP6 > application? A generic key management daemon would by default have > some other means to provide the addresses in the CONF payload without > consulting the MIP6 application, so there must be some method to tell > the key management daemon that it should request the addresses from > the MIP6 application. The author is not aware of any such method > being available currently. me neither. > 6.4. Registering the MN's FQDN in DNS > > [RFC4877] allows the HA to register the MN's FQDN in the DNS. In > this case the MN must provide the FQDN in the IDi payload in the > IKE_AUTH step of the IKEv2 exchange. Consequently, there must be > some interface between the key management daemon and the MIP6 > application on the HA side through which the FQDN could be made > available to the MIP6 application so that it can register the FQDN in > DNS. Can you point a specific section of RFC 4877. I fail to find where this feature is discussed. > 6.5. Providing the Home Network Prefix to the MIP6 application > > When the key management daemon on the MN side obtains the home > network prefix information from the HA, it needs to relay this > information to the MIP6 application. This again requires a > communication channel between the key management daemon and the MIP6 > application. yes. > 6.6. SPD Entry for the HoA on the MN side > > Once the MIP6 application on the MN obtains the HoA (either assigned > via the CONF IKEv2 payload [RFC4877] or autoconfigured from the > MIP6_HOME_PREFIX [RFC5026]), the appropriate SPD entries need to be > created in the SPD. Some key management daemons may require that > they have full control of the SPD. In such cases the MIP6 > application should not create the SPD entries by itself as this might > confuse the MIP6 daemon and cause inconsistent state. Instead, the > MIP6 application would need to instruct the key management daemon to > create the appropriate SPD entries. StrongSwan developers hit that issue when implementing MIGRATE/KMADDRESS because UMIP (the Mobile IPv6 daemon for Linux) handles all the policies. It just let the IKE daemon perform the SA nego for those policies. I think this is handled via the installpolicy=no in the configuration described on the following page: http://wiki.strongswan.org/wiki/strongswan/MobileNodeSetup For racoon (IKEv1 daemon), this was not an issue: racoon monitors the in-kernel SPD. > So depending on the expectations > of the key management daemon, the MIP6 application should either > instruct the key management daemon to create the SPD entries or the > MIP6 application should create them by itself at this point. yes. > If the policy requires protection of the data traffic the SPD entries > for the data traffic would also need to be created at this point. yes. > 6.7. SPD Entry for the HoA on the HA side > > The creation of the SPD entry on the HA side for protecting the MN's > mobility signaling is similar to what is happening on the MN side and > is described in the previous section. As soon as the HA assigns an > HoA it may proceed with the creation of the appropriate SPD entry. > The SPD entries for protecting the data traffic should also be > created at this time. Another reason for having the Mobile IPv6 daemons interact with the SPD directly. > However, the issue gets more complicated in the case where the HA > provides the prefix to the MN and the MN autoconfigures the HoA. In > this case neither the key management daemon nor the MIP6 application > on the HA are aware of the MN's autoconfigured HoA so neither of them > is in a position to install an appropriate SPD entry during (or > immediately after) the IKEv2 exchange. Even worse, since the > autoconfigured MN address is not known on the HA side it is not clear > what is the contents of the TSi and TSr payloads in the final > IKE_AUTH message sent by the HA. It is unclear whether or not the SA > for protecting the MN's mobility signaling gets established at all in > such a situation. > > TBD: verify whether this is really a problem... > > 6.8. The K bit > > The K bit [RFC3775] requires an interface between the IPsec subsystem > and the MIP6 application that is not available today, at least not in > a standardized form. Such an interface that would enable the support > for the K bit has been proposed before and additional information how > it might look like is available in [I-D.sugimoto-mip6-pfkey-migrate] > and [I-D.ebalard-mext-pfkey-enhanced-migrate]. the latter is a follow-up of the former. Implementation feedback provided by the implementation of the former showed that SADB_X_EXT_PACKET mechanism had drawbacks. Hence the extension to use KMADDRESS. [I-D.ebalard-mext-pfkey-enhanced-migrate] is currently available as a draft and implemented. I had discussion with the chairs to go further in the context of MEXT but the WG is not supposed to work on that kind of item. > However, those > proposals were not standardized and as such there is no publicly > available interface specification that could be used by the third > party MIP6 application developers to invoke the key management daemon > and IPsec kernel. Note also that the MIP6 application must have a > detailed knowledge about the established IPsec SAs (complete SPD > entries, old and new tunnel end points) in order to be able to > indicate to the key management daemon which SAs needs to be updated, > which is not in the spirit of the original IPsec intention to provide > security to the applications in a transparent manner. Well, this is the work of the MIPv6 module to perform that, i.e. keep that information updated. > 6.9. UDP encapsulation of DSMIP6 signaling I will not comment on DSMIPv6 because, IMHO, the problem of DSMIPv6 is NAT, not IPsec/IKE. But I agree that DSMIPv6 is way too complex on many aspects, including its relationships with IPsec/IKE. Personally, even if one can argue on the associated drawbacks of the solution in term of encapsultation (IPv4/UDP/IPv6/ESP/IPv6/TCP/HTTP for common traffic exchanged with my HA, which mean I lose at least 24 bytes of MTU) and some other aspects (I don't have an IPv4 HoA), I use Teredo: it has been designed to be smart about NAT and only that, it is good at it and provides a very good abstraction: a usable IPv6 link. My MIPv6 module is not IPv4 -aware and my IKE daemon is compiled with --disable-natt ;-) > 7. Conclusion > > Examples in Section 6 show that there is a need for an extensive > communication between the MIP6 application and the IPsec subsystem on > the host. If you don't need the HoA assignment and additional features provided in some section of 4877 and 5026, "extensive" is a bit too much. > Standardizing such communication channel and having it > available in a commercial OS implementations is not a realistic > proposal in any practical time frame. Please, site names of vendors and OS, not in the draft but on the list. This is looks like a vendor issue more than anything else. I don't like the logic but if you have a business case for them then previous issue vanishes. > On the technical side, this is > due to the fact that the IPsec is usually provided as part of the OS > kernel and it is always difficult to convince the OS vendor to change > the kernel and in particular the security related subsystems. The > other difficulty is that the key management is usually provided as > the user space service and as such there are multiple key management > daemons available. Convincing vendors of various key management > daemons to provide a unified or standardized communication channel > for the MIP6 application might prove equally difficult and is not a > realistic option either. You don't have to convince vendors. If the protocol is available (documented) and the feature is worth implementing for their clients, I don't see why they would refuse if other vendors would agree. > Besides the technical reasons, there are > also other non-technical reasons of business or political nature why > such proposals would be unrealistic. Can you extend that sentence into a paragraph. It looks promising ;-) > Therefore this draft recommends that an alternate security framework > be considered for MIP6. This alternate mechanism should be self > contained so that it can be developed and delivered as part of the > MIP6 application itself (from an implementation perspective analogous > to the way web browsers handle security today). This would enable > third party developers that have no access or are otherwise not in a > position to change the IPsec code of the platform they are developing > for to come up with a self contained and working MIP6 application. > Such alternative security mechanisms would remove one of the major > impediments, i.e the interactions with IPsec - why it is so difficult > today to implement a working MIP6 application. This would foster the > diversity of the MIP6 solutions and should therefore have beneficial > effects on the availability of MIP6 solutions and promote the > adoption of MIP6 in general. Why is there a need to modify the generic solution (I mean changing 3775 for instance) if an alternative document is sufficient (like what 4285 does, for the reasons described in RFC 5419) In the end, it's all about serving the Internet or specific SDOs/vendors. I think the IETF in general and MIPv6 in particular try and do the former. > In order to make the Mobile IPv6 protocol a solution that is easy to > implement and available in even low-end devices, it is necessary to > simplify the protocol. The design or the security architecture for > MIP6 needs to be revisited and a solution that simplifies the > implementability of the protocol considered. The implementation > experience shows that a working solution of Mobile IPv6 is possible > to build. However it is not easily done. > 8. Security Considerations > > This I-D discusses the security architecture of Mobile IPv6 which is > based on IPsec. The dependency on IPsec for security of MIP6 > signaling is a detriment to the protocol implementation and > deployment. Hence the current security architecture needs to be > reconsidered. > > The experience gained over the last few years indicates that IPsec > cannot necessarily be used as a generic solution for security. IPsec cannot be used to protect all protocols. Hence the specification of SEND for instance. But I think MIPv6 is among the few protocols which have made effort to build their security on IPsec/IKE without relying only on a simple sentence somewhere in the document stating "for security needs, IPsec should be use". I would agree that more work is needed on some aspects (interfaces) even if the WG is more interested by pushing additional features. If the security work on IPsec/IKE integration with MIPv6 had been completed before the extension of the protocol (DSMIPv6, ...), this may have prevented such issues. I agree that some of the features described in companion documents of MIPv6 have been described at a too high level and cannot be implemented easily. > The design choice made for MIP6 in the initial stages no longer are > valid and is hampering the implementation and use. > > > 9. IANA Considerations > > This document does not have any information which requires IANA > review. > > > 10. Acknowledgements > > Jouni Korhonen would like to point out the importance of sustained > supply of caffeine rich coffee when doing IETF work. Fully agree ;-) > Authors would also like to recognize Satyabrata Sahu, NK Garg, > Sandeep Minocha and Harsh Verma for working on the implementation. What about discussing the specific technical details of the problems they found during the implementation on the list and try and address them one by one. Can I also ask what they implemented precisely and for which specific platform? I would understand if that cannot be discussed publicly, obviously. Cheers, a+ From hesham@elevatemobile.com Thu Jul 23 04:31:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4524C3A67E7 for ; Thu, 23 Jul 2009 04:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 vLGAjlxZzSqI for ; Thu, 23 Jul 2009 04:31:17 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 504C03A6358 for ; Thu, 23 Jul 2009 04:31:16 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MTwUP-0001BK-4b; Thu, 23 Jul 2009 21:29:33 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 23 Jul 2009 21:29:26 +1000 From: Hesham Soliman To: Arnaud Ebalard , Message-ID: Thread-Topic: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 Thread-Index: AcoLiNWR1byql1ik9kyWRXoyVRMjIQ== In-Reply-To: <87k51zfzvb.fsf@small.ssi.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: Basavaraj Patil Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 11:31:18 -0000 >> >> Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an >> implementation and deployment perspective. As a protocol solution >> for host based mobility, MIP6 can be simpler without the IPsec >> baggage. The issues with IPsec are even more exacerbated in the case >> of dual-stack MIP6 [RFC5555]. > > Sorry, but the design decisions taken for DSMIPv6 make it the way it > is. You cannot blame IPsec/IKE for IPv4/NAT issues. The problem with > DS-MIPv6 is that it does not provide IPv6 connectivity for the MN that > could be used transparently by the stack (Teredo does that). When the > protocol has been designed, it has been decided to open the door to > IPv4, which let the NAT issue enter. => That's because the whole point of DSMIPv6 is to open the door for using IPv4 use as a home address and a CoA (DS=Dual Stack). Teredo doesn't do that, and it was never bound by the same security requirements of MIPv6. I'm not advocating the points in the draft, I actually agree with your other comments. But the problems with DSMIPv6/IKE interactions *are* due to NATs and having two different NAT traversal mechanisms running in parallel without a standard API between them. Due to that decision, the > difficulties of IPv4/NAT have also impacted the use of DSMIPv6 with > IPsec/IKE. > > I would be interested to have the honest opinion of the main > contributors of RFC 5555 on that topic. > => I hope this helps. Hesham From xiayangsong@huawei.com Thu Jul 23 09:34:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB173A67A4 for ; Thu, 23 Jul 2009 09:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 nmgOxPjivExc for ; Thu, 23 Jul 2009 09:34:04 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id DD7D728C0EE for ; Thu, 23 Jul 2009 09:33:52 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN800F4MTWENV@szxga02-in.huawei.com> for mext@ietf.org; Fri, 24 Jul 2009 00:31:26 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN800LH2TWB27@szxga02-in.huawei.com> for mext@ietf.org; Fri, 24 Jul 2009 00:31:26 +0800 (CST) Date: Thu, 23 Jul 2009 12:31:23 -0400 From: Frank Xia To: Hesham Soliman , "Laganier, Julien" Message-id: <002a01ca0bb3$0611ecd0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 16:34:05 -0000 Hi Hesham IMHO, we, IETF partipants, play by rules which are documented in charters. The whole arguments back and forth are just because of the ambiguious charter. BR Frank ----- Original Message ----- From: "Hesham Soliman" To: "Laganier, Julien" Cc: Sent: Wednesday, July 22, 2009 11:20 PM Subject: Re: [MEXT] flow binding draft 3 > Sorry I got distracted by a few things and forgot to reply earlier. Yes > I'm > fine with your suggestion about the use of "flow(s)". > > Hesham > > > On 23/07/09 5:12 AM, "Laganier, Julien" wrote: > >> >> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Tuesday, July 21, 2009 8:44 PM >>> To: Laganier, Julien >>> Cc: Christian Kaas-Petersen; mext@ietf.org >>> Subject: Re: [MEXT] flow binding draft 3 >>> >>> >>>>> >>>>> => I'm wondering whether we would have to always write "flow or flow >>>>> aggregate" in the doc because it's not always about a bunch of >>> flows. >>>>> Alternatively, if we don't define a flow as being from a single >>> source, >>>>> then we can just use "flow". I don't have a problem with the other >>> two terms >>>>> you suggest above. >>>> >>>> I think we should stick to RFC 2460 for the definition of a flow, >>>> i.e., "a sequence of packets sent from a particular source to a >>>> particular (unicast or multicast) destination for which the >>>> source desires special handling by the intervening routers." >>> >>> => Agreed. >>> >>>> After thinking a bit more to the term "aggregate", I do not think >>>> anymore that "flow aggregate" is a good term because >>>> in a situation where we have a traffic selector that matches all >>>> HTTP flows (i.e., proto tcp port 80), it's likely >>>> that the traffic is disaggregated since every flow goes to a >>>> different web server. >>> >>> => Yes. >>> >>>> How about we use "flow" in the sense of 2460 and its plural form >>>> where required, >>> >>> => Right, or we can say somewhere early in the doc that we will use the >>> word "flow" to indicate the singular and plural. >> >> I think easiest is to use "flow" when we talk about one, "flows" when we >> talk >> about more than one, and "flow(s)" where we talk about one or more >> flow(s). >> >>>> and "traffic selector" and "traffic selector descriptor/ID" where >>>> talking about the object that matches a bunch of "flows", and the >>> reference to >>>> it? >>> >>> => I'm ok with that. >> >> All right then. >> >> --julien >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From arno@natisbad.org Thu Jul 23 11:46:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F1C3A6A48 for ; Thu, 23 Jul 2009 11:46:31 -0700 (PDT) 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 Uzw8-IazWnTA for ; Thu, 23 Jul 2009 11:46:30 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id AD5BE3A69C0 for ; Thu, 23 Jul 2009 11:46:30 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MTwk1-0003wq-Jl; Thu, 23 Jul 2009 13:45:41 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Hesham Soliman References: X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090723:hesham@elevatemobile.com::vRECLmRWjOppNolK:00000000000000000000000000000000000000VoI X-Hashcash: 1:20:090723:mext@ietf.org::43tvdEULFHPBLEu2:00001BVU X-Hashcash: 1:20:090723:basavaraj.patil@nokia.com::ntQQPflMdJHkQMzv:0000000000000000000000000000000000005GT5 Date: Thu, 23 Jul 2009 13:46:18 +0200 In-Reply-To: (Hesham Soliman's message of "Thu, 23 Jul 2009 21:29:26 +1000") Message-ID: <878wiffwqd.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Basavaraj Patil , mext@ietf.org Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:46:31 -0000 Hi Hesham, Hesham Soliman writes: >>> >>> Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an >>> implementation and deployment perspective. As a protocol solution >>> for host based mobility, MIP6 can be simpler without the IPsec >>> baggage. The issues with IPsec are even more exacerbated in the case >>> of dual-stack MIP6 [RFC5555]. >> >> Sorry, but the design decisions taken for DSMIPv6 make it the way it >> is. You cannot blame IPsec/IKE for IPv4/NAT issues. The problem with >> DS-MIPv6 is that it does not provide IPv6 connectivity for the MN that >> could be used transparently by the stack (Teredo does that). When the >> protocol has been designed, it has been decided to open the door to >> IPv4, which let the NAT issue enter. > > => That's because the whole point of DSMIPv6 is to open the door for using > IPv4 use as a home address and a CoA (DS=Dual Stack). Teredo doesn't > do that, and it was never bound by the same security requirements of > MIPv6. I'm not advocating the points in the draft, I actually agree > with your other comments. But the problems with DSMIPv6/IKE > interactions *are* due to NATs and having two different NAT traversal > mechanisms running in parallel without a standard API between them. I agree. >> Due to that decision, the difficulties of IPv4/NAT have also impacted >> the use of DSMIPv6 with IPsec/IKE. >> >> I would be interested to have the honest opinion of the main >> contributors of RFC 5555 on that topic. >> > > => I hope this helps. Yes. Thanks. Cheers, a+ From marcelo@it.uc3m.es Fri Jul 24 02:33:22 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278D628C175 for ; Fri, 24 Jul 2009 02:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 erO-puDEImCz for ; Fri, 24 Jul 2009 02:33:21 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 6229528C171 for ; Fri, 24 Jul 2009 02:33:21 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (34.pool85-53-136.dynamic.orange.es [85.53.136.34]) by smtp03.uc3m.es (Postfix) with ESMTP id D82DC7F2D56 for ; Fri, 24 Jul 2009 11:33:20 +0200 (CEST) Message-ID: <4A697FE0.2090400@it.uc3m.es> Date: Fri, 24 Jul 2009 11:33:20 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16782.003 Subject: [MEXT] updated agenda posted X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 09:33:22 -0000 check http://www.ietf.org/proceedings/75/agenda/mext.txt From Basavaraj.Patil@nokia.com Fri Jul 24 13:35:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC5A3A685C for ; Fri, 24 Jul 2009 13:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, 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 Wq3DxbmanTKl for ; Fri, 24 Jul 2009 13:35:47 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D5DF83A67FD for ; Fri, 24 Jul 2009 13:35:45 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6OKY3MT027564; Fri, 24 Jul 2009 23:34:06 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 23:34:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 23:34:05 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 24 Jul 2009 22:34:05 +0200 From: To: , Date: Fri, 24 Jul 2009 22:34:18 +0200 Thread-Topic: Review of draft draft-patil-mext-mip6issueswithipsec-01 Thread-Index: AcoLgaezEkSB0taCQVi9v7DSQ5AI3QBHHY4Y Message-ID: In-Reply-To: <87k51zfzvb.fsf@small.ssi.corp> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jul 2009 20:34:05.0851 (UTC) FILETIME=[16B076B0:01CA0C9E] X-Nokia-AV: Clean Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 20:35:50 -0000 Hello, >Hi, > >below is a review of draft-patil-mext-mip6issueswithipsec-01. > >> 1. Introduction >> >> Mobile IPv6 as specified in RFC3775 [RFC3775] requires an IPsec >> security association between the mobile node (MN) and home agent >> (HA). The IPsec SA protects the mobility signaling messages between >> the MN and HA. The user data may be optionally protected by the >> IPsec SA but is not required. >> >> The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified >> in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6 >> working groups in the IETF chose to mandate IPsec as the default >> security protocol for Mobile IPv6 based on various criteria and >> lengthy discussions that occured between the years 2000 and 2004. >> Implementation experience with Mobile IPv6 and the security variants >> with which it has been specified in some SDOs > >You should introduce the SDOs here i.e. have "some SDOs (XXX, YYY, >...). They are *never* cited in the whole document. The issues common >and specific to each of those about IPsec/IKE should be summarized in >the document. MIP6 itself has been specified as a solution by NWG in WiMAX forum, 3GPP2 and DSMIP6 has been specified by 3GPP in Rel 8. Will mention in the next rev of the I-D. > >> indicates a need to >> revisit the design choice for MIP6 signaling security. The analysis >> and recommendation to revisit the security protocol architecture for >> MIP6 should not be interpreted as a recommendation for Authentication >> Protocol for Mobile IPv6 [RFC4285]. The objective is to highlight >> the misfit of IPsec and IKEv2 as the security protocol for MIP6 and >> hence the need for considering alternatives. >> >> >> 2. Terminology and Abbreviations >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119]. >> >> This document refers to [RFC3775][RFC4877] for terminology. >> >> >> 3. Background >> >> IP mobility support in IPv6 was considered to be an integral feature >> of the IPv6 stack based on the experience gained from developing >> mobility support for IPv4. The design of Mobile IPv6 was worked on >> by the Mobile IP WG in the late 90s and by the MIP6 WG until its >> publication as [RFC3775] in 2004. >> >> IPsec [RFC4301] was also intended to be a default component of the >> IPv6 stack and was the preferred protocol choice for use by any other >> IPv6 protocol that needed security. Rather than design security into >> every protocol feature, the intent was to reuse a well-defined >> security protocol to meet the security needs. Hence Mobile IPv6 has >> been designed with the security architecture relying on IPsec. >> >> The Mobile IPv6 specification [RFC3775] was published along with the >> companion specification "Using IPsec to Protect Mobile IPv6 Signaling >> Between Mobile Nodes and Home Agents", [RFC3776]. The establishment >> of the IPsec SA between the MN and HA as per RFC 3776 is based on the >> use of IKE. > >Optional use of IKE. Nonetheless, I agree that using IKE is the only >possible way to go when you need to scale. Right. You could configure the SAs manually. But that is not really an option. > >> The use of IKE in the context of Mobile IPv6 for IPsec >> SA establishment did not gain traction because of factors such as >> complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG >> completed the specification, Mobile IPv6 Operation with IKEv2 and the >> Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] >> is considered as the default security protocol solution for MIP6 and >> updates [RFC3776]. > >I agree. > >> 4. Problem Statement >> >> Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an >> implementation and deployment perspective. As a protocol solution >> for host based mobility, MIP6 can be simpler without the IPsec >> baggage. The issues with IPsec are even more exacerbated in the case >> of dual-stack MIP6 [RFC5555]. > >Sorry, but the design decisions taken for DSMIPv6 make it the way it >is. You cannot blame IPsec/IKE for IPv4/NAT issues. The problem with >DS-MIPv6 is that it does not provide IPv6 connectivity for the MN that >could be used transparently by the stack (Teredo does that). When the >protocol has been designed, it has been decided to open the door to >IPv4, which let the NAT issue enter. Due to that decision, the >difficulties of IPv4/NAT have also impacted the use of DSMIPv6 with >IPsec/IKE. Agree. But the point is because of the security architecture of MIP6 is based on IPsec, the issues with IPv4/NAT are inherited by DSMIP6 and as a result the protocol becomes much more complex... At least from implementations perspective. > >I would be interested to have the honest opinion of the main >contributors of RFC 5555 on that topic. My opinion is that DSMIP6 [RFC5555] did not really want to change the fundamentals of MIP6 and hence did not really tackle the security architecture issue. > >> IPsec SAs between the MN and HA are established either manually or >> via the use of IKEv2 [RFC4306]. Manual SA configuration is not a >> scalable solution and hence MIP6 hosts and Home agents rely on IKEv2 >> for establishing dynamically IPsec SAs. As a result MIP6 depends on >> the existence of IPsec and IKEv2 for successful operation. > >yes. > >> IPsec is unable to provide security protection for MIP6 in a >> transparent way, and numerous interactions between the host's >> security subsystems and the MIP6 application are needed in the course >> of the regular operation of the MIP6 application. > >For common scenario, MIGRATE/KMADDRESS solution is sufficient. This >requires small changes to the IPsec stack, the IKE daemon and the MIPv6 >module. After 3776, it is my feeling that MEXT documents have slowly >shifted towards tighter relationships between the MIPv6 module and the >IKE (address assignment) module to the point that it would be difficult >today to provide all the functionalities pushed so far without having a >common MIPv6/IKE module (or at least complex interactions between >those). Agree. And the issue is with the fact that complex interactions are needed between the modules. Basically you cannot expect to use the existing IPsec/IKEv2 engine on a host to work with your MIP6 implementation with no changes. You end up having to modify the security module to work with (DS)MIP6 module and this is not a task for the faint-hearted. > >> Besides requiring an extensive communications channel between the >> security subsystems and the MIP6 application, those interactions >> often also require modification of the MNs security subsystems >> code. > >Well, I expect all possible L3 solutions to require changes to the >security subsystems to support MIPv6 needs but I'd like to be proven >wrong. Take a look at the TLS based security architecture framework solution proposed in I-D: draft-korhonen-mext-mip6-altsec-01.txt We believe that it does not require changes to the security engine on the host. It is a solution which uses the APIs and libraries of TLS on the host without having to modify them. The problem with IPsec/IKEv2 and MIP6 is that we end up having to modify the security subsystem to make it work and this is not a feasible option in all instances. > >> The situation today is such that the communications channel >> between the IPsec subsystems and the MIP6 application is non >> existent and this is generally true for most of the commercially >> available platforms. > >The sentence is correct. > >Well, I won't advocate for other platforms but at least Linux has that >now, which proves it is feasible: > > - Upstream Kernel supports full MIGRATE/KMADDRESS since 2.6.28. Current > is 2.6.30. > - racoon (IKEv1) has support for MIGRATE/KMADDRESS for a while now > - StrongSwan developers have added support for MIGRATE/KMADDRESS to > Charon, their IKEv2 daemon. Right... And this is what we have worked with on our implementation as well. While we can use these interfaces, I should say that it is still not easy and again these are not available on all platforms. > - patches exist for racoon2 > >I can't say about *BSD platform. Or for that matter Symbian or Maemo (linux) etc.. > >> Even if such a channel were to be available, there does not exist a >> standardized protocol over that channel which would enable the MIP6 >> application to communicate with the security modules in a non- >> implementation specific way. > >Well, I already pointed that and even provided follow-up work for >MIGRATE/KMADDRESS but this was considered out of scope for the >WG. Having that work done in the context of ipsecme WG was not possible >either. > >But thanks for stressing that point. Right.. We did note work (reference) done by you in this context. But it has not really progressed. > >> Considering a third party application developer who would like to >> provide a MIP6 application for a particular platform, the need for >> numerous interactions with the IPsec subsystem and the unavailability >> of the standardized communications channel through which such >> interactions could take place is a major obstacle to the >> implementation of the mobility protocol. Without such a >> communication channel being available it is not possible to implement >> a MIP6 application as a third party developer. > >3 main possible solutions: > > - standardize the interface > - make MIPv6 module and IKEv2 module a common module (as > progressively expected by MEXT documents published after 3775) > - give up on the use of IPsec/IKE Yes... The last option is what we are recommending. The others do not seem to be easily surmountable. > >> Even if the platform would provide such a communication interface for >> the MIP6 daemon, this is still insufficient as the MIP6 protocol >> standardized today [RFC3775] requires numerous changes to the host's >> IPsec and IKEv2 implementation. This document enumerates various >> implementation issues related to the interactions between the MIP6 >> application and the host's security subsystems. >> >> An argument can be made that the MIP6 application itself should >> provide the required changes to the IPsec subsystems of the platform >> (maybe in the form of patches). While this is possible at least for >> some open source platforms to provide modifications to the host's >> IPsec implementation as well as the key management application(s), >> this is still an issue for several reasons: >> >> o Target platform could be a commercial platform for which no source >> code is available. >> o If the MIP6 application were to patch the IPsec subsystems, then >> multiple MIP6 applications from different developers would >> implement it in different ways, which would inevitably lead to >> variations and problems with interoperability at a minimum, for >> instance when the user tries to install several MIP6 applications >> it is difficult to determine which one is the best suited for his/ >> her needs. >> o Key management daemons are usually provided as third party >> software for which no source code may be available, even if the >> platform itself is available as open source. >> o Even if the MIP6 application developer would be willing to provide >> patches for the key management daemon to make it work with his >> MIP6 application, how would the MIP6 application developer know >> which of the several available key management daemons the user is >> running? >> o Each application would be able to work only with a single key >> management daemon, namely the one for which the MIP6 application >> provides the patches. The user may be running another key >> management daemon and may be unwilling to change its daemon to the >> one that comes as part of the MIP6 application. >> o Patches for the IPsec part in the kernel and the key management >> daemon would typically be valid only for the particular version of >> the kernel and the key management daemon for which they were >> written. This might prevent the user from upgrading the platform >> or applying OS security patches that are provided as part of the >> regular platform maintenance since this would in all probability >> make the MIP6 application defunct. >> o Modifying the security subsystems by a third party is a security >> issue and users are generally advised to refrain from allowing the >> security subsystems to be modified in any way. >> o The developer may not have the knowledge or the time to modify the >> platform's IPsec subsystems, although it might be perfectly >> capable to deliver the MIP6 application itself. >> o There could be copyright issues as well that would prevent >> modifications of the platform's security subsystems or the >> delivery of the modifications by the third party. >> o Even if the MIP6 application developer is able to come up with the >> necessary patches for the security subsystem, it is not realistic >> to expect the prospective user of MIPv6 to first patch the kernel >> and the key management daemons before using the MIPv6 service. >> >> The above discussion shows why it is unrealistic to expect that the >> MIP6 application could provide the needed modifications to the IPsec >> subsystems of the host. Section 6 presents a more technical >> discussion of various implementation issues related to the >> interworking between the MIP6 application and the IPsec/key >> management modules. >> >> The problem in a nutshell for MIP6 is the dependence on IPsec and >> IKEv2 for successful operation. > >I respectfully disagree, not with the various points above, but with the >way you interpret them. Vendors implement features in their products >based on business case and possibly the availability of a standard. If >open source product already have the feature, I think may indicate the >issue is not the technical feasibility ... Having worked on this implementation, I am not arguing that it cannot be done. All I am saying is that it is a real pain to implement it and get it working. Additionally while it is possible to do this on open source where you have control of all the modules, it is not necessarily the case on all platforms. For example you would not be able to modify the IPsec/IKEv2 modules on Symbian if you were building the MIP6 module. Only Symbian could do that. And the same goes for many other platforms as well. > >From a discussion I had with some MS engineers after they unleashed the >details on Vista's IPv6 stack, asking them for the reasons why it had no >MIPv6 support: no business case and no standard interface to secure >it. No business case from the perspective of MS... Maybe. But I am not sure I understand what you meant by "no standard interface to secure it". > >There are some people working for vendors (Cisco, ...) on MEXT so they >can probably provide valuable comments on the reason why they don't have >support for IPsec/IKE w/ MIPv6. Vendors that have support could also >comment on how they did it and why. Support for IPsec/IKEv2 can be built. But most vendors would shy away from it. To make this protocol even have half-a-chance of being implemented by vendors the security architecture needs to be a lot more simpler than the current one. > >I think the points you give above shoud be interpreted the following >way: to be easiliy implemented on a *commercial* platform without >interactions with the associated vendors (implying business cases and >money), it would be easier for MIPv6 to be self contained and with the >least possible interactions with the networking stack, security stack >and other third party applications (like IKE module). Hence a possible >reason not to rely on IPsec and IKE. But this is only one side of the >coin, i.e. there are drawbacks in taking such a path: how do you provide >security? from scratch or based on another building block? can you >support protection of IP data? What interface do you provide to users to >enable the various protection modes? Does the solution target the IPv6 >internet or only a small subset of it? Again, note a proposed solution in the I-D mentioned above which is based on TLS (reuse of another existing security building block). > >> 5. General issues with the use of IPsec for MIP6 security >> >> This section captures several issues with the use of IPsec by MIP6. >> >> (1) The design of Mobile IPv6 emphasized the reuse of IPv6 features >> such as IPsec. IPsec for IPv4 was a bolt-on solution. With the >> increasing need for security, IPv6 designers chose to >> incorporate IPsec as a default feature. There existed an >> assumption in the MIP6 working group that every IPv6 host would >> have IPsec capability as a standard feature. While this is true >> in many host implementations today, the existence of IPsec in >> every IPv6 stack is not a given. > >3775 and 4877 provide a *generic* solution for the Internet environment, >i.e. common platforms and systems. As you write, "[IPsec as a default >feature] is true in many host implementations today". If specific >systems have specific needs which do not fit with a generic solution, >then they need a specific solution. If they are so specific, they may >simply not be in the scope of MIPv6 generic solution. Let me give you an example.. A mobile phone (not the smartphone types lets say) does not need IPsec/IKEv2. However it does not need mobility support on networks which would provide mobility via an HA. So the point is mobility may be a requirement in certain cases, whereas IPsec/IKEv2 is not. > >> Hence a host which needs to >> implement Mobile IPv6 must ensure that IPsec and IKEv2 are also >> available. As a result of this dependence, MIP6 is no longer a >> standalone host-based mobility protocol. A good example of a >> host based mobility protocol that works as a self-sufficient >> module is Mobile IPv4 [RFC3344]. > >Section 5.5 (Privacy) of RFC 3344 has the following: > > Users who have sensitive data that they do not wish others to see > should use mechanisms outside the scope of this document (such as > encryption) to provide appropriate protection. Users concerned about > traffic analysis should consider appropriate use of link encryption. > >The difference is that MIPv6 tries and address that instead of leaving >the user alone. But I would find it very hard to see it actually being used. > >With MIPv4, extensions of the protocol to support full security have >(what I consider) funny drawings like the following (RFC 5265): > > .------------------------------------------------------- - > ! IP ! IP ! ESP ! IP ! IP ! user \ > ! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../ > ! x-HA ! VPN-GW ! ! i-HA ! CN ! \ > `------------------------------------------------------- - > - - -----------------. > \..user ! ESP ! > / protocol ! trailer ! > \ ! ! > - - -----------------' > >It was decided to make MIPv6 compatible with IPsec/IKE (and use those >for the security). This allows more from a security standpoint but >requires more initial investment. That initial investment seems to be >considered too high a price for environments with different assumptions >or existing security mechanisms. > IPsec in hosts is used primarily (and probably only) by VPN applications. Is there any other protocol on a host which requires IPsec? So why is MIP6 having to rely on IPsec and IKEv2. The design goals in the late 90s were based on some principles which are not very practical today. >> MIP4 signaling is integrated into the protocol itself. MIP4 has >> been successfully deployed on a large scale in several networks. > >Can you describe the assumptions about those network? Do they come with >link layer security for instance? Yes. They do have security at the lower layers. >Can a user of those networks move to >the Starbuck at the corner and use the wifi there without the need to >care about how its data are protected on that foreign network? They could. Depends on the type of data and how concerned they are about protecting it (i.e level of paranoia). > >RFC 3775 Introduction starts with: "This document specifies a protocol >which allows nodes to remain reachable while moving around in the IPv6 >Internet" > >> (2) IPsec use in most hosts is generally for the purpose of VPN >> connectivity to enterprises. It has not evolved into a generic >> security protocol that can be used by Mobile IPv6 easily. While >> RFC4877 does specify the details which enable only the MIP6 >> signaling to be encapsulated with IPsec, the general method of >> IPsec usage has been such that all traffic between a host and >> the IPsec gateway is carried via the tunnel. Selective >> application of IPsec to protocols is not the norm. Use of IPsec >> with Mobile IPv6 requires configuration which in many cases is >> not easily done because of reasons such as enterprise >> environments preventing changes to IPsec policies or other. >> (3) A MIP6 home agent is one end of the IPsec SA in a many-to-one >> relationship. A MIP6 HA may support a very large number of >> mobile nodes which could be in the hundreds of thousands to >> millions. The ability to terminate a large number of IPsec SAs >> (millions) requires signifiant hardware and platform capability. >> The cost issues of such an HA are detrimental and hence act as a >> barrier to deployment. > >Can some vendor comment on that. Do we agree that the amount of traffic >is not the issue but the initial IKE negotiation and the number of SA >might be? The number of messages exchanged to setup the IPsec SA is an issue. Especially when you compare it with the registration process required for MIP4. So if you compare the number of steps for registration of an MN for MIP6 vs MIP4, you would see the difference. > >> (4) The implementation complexity of Mobile IPv6 is greatly >> increased because of the interaction with IPsec and IKEv2. A >> standalone MIP6 protocol is easier to implement and deploy (such >> as MIP4 [RFC3344]). The complexity of the protocol >> implementation is even more so in the case of Dual stack MIP6 >> [RFC5555]. > >MIPv6 and MIPv4 do not have equivalent feature security-wise. MIPv6 is >certainly more complex on that aspect than MIPv4 but it allows >more. More is not necessarily good :) (Kitchen sink protocol design) > Moreover, it builds (even if some bits may be missing >interface-wise) on existing and mature protocol (not speaking about >IKEv2 yet ;-) ) which prevents reinventing the wheel. Well show me another protocol on the host which relies on the reuse of an existing and mature protocol like IPsec. > >> (5) IPsec and IKEv2 are not implemented or available by default in >> every IPv6 or dual stack host. > >Can you list some (2 or 3) systems that are of common use today and that >do not have that? Proprietary OS' come to mind. Devices with these types of OS' are fairly common. > >> Mobile IPv6 support on such devices is not an option. Many >> low-end cellular hosts have IP stacks. The need for IPsec and >> IKEv2 in these devices is not important whereas mobility >> support is needed in many cases. > >I may be wrong but the way I see it is that current trend if for >cellular devices to come with complete systems today: what does the >iPhone runs? Nokia is currently shifting towards Linux based solutions >(ofono, maemo, ...)? Many phones runs Windows Mobile too, ... > >If you consider the previous devices and most of the laptop (99% of >the latter running Mac OS X, Linux or Windows), I think you have the >initial targets MIPv6 is trying to provide mobility for. Or am I missing >your point? Well.. Nokia devices based on Maemo and Symbian do include IPsec support. But for lower end devices which are primarily intended for voice service and some data, there is no IPsec even though there is an IP stack. Additionally I dont know about many other devices which are becoming capable of connecting to the Internet but do not need an IPsec stack. > >> A simpler security protocol than the use of IPsec/IKEv2 would ma= ke >> MIP6 much more attractive to implement and deploy. > >Those sepecific devices may need a specific solution. I agree on that. > >> (6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile >> IPv6 essentially results in a variant of IPsec which is specific >> to Mobile IP. > >No. IPsec stack and IKE daemon may already have support for MOBIKE which >does exactly what we need. The only difference is that the signaling >goes through the IKE channel. With MIPv6, signaling is MIPv6 one >(BU/BA). In all cases, extending the IPsec stack to support MIPv6 is >light. Same for IKE. I think this where I would disagree. At least from our experience of doing a DSMIP6 implementation, the challenges are primarily in the interactions between the mobility module and the IPsec/IKEv2 modules. YMMV. > >> Hence this results in added complexity to implementations. > >No. Compare the small required extensions (MIGRATE/KMADRESS is short to >read) with what it would cost to provide the same amount of features >(protecting signaling and possibly data) but by designing and >implementing a specific protocol in the MIPv6 module. > Making changes to the IPsec or IKEv2 modules may not always be an option. Especially if you have no control of those modules on a host. You would then have to rely on these interfaces being standardized and implemented on all hosts for the mobility module to rely on. >IMHO, a simple extension cost less than a complete new design. And >considering you are speaking about a security solution, designing from >ground a new security solution for your own need is starting looking for >trouble, all the more if you are trying to provide a L3 security >solution, i.e. trying to compete with IPsec/IKE. I think we can do simpler security solution than IPsec/IKEv2 which would simplify the implementation vastly while preserving the security aspects of the MN-HA communications. > >> (7) Mobile IPv6 needs to be capable of being deployed in situations >> where alternative security mechanisms are already well- >> understood by the network administration. It should be possible >> to enable Mobile IPv6 to work in situations where alternative >> security mechanisms already supply the necessary authentication >> and privacy. > >Agree. > >> (8) IPsec has been successfully applied to VPN and other >> infrastructure operations, but less so for general end-to-end >> applications. Thus, the granularity for selectors was >> originally not at all sufficient for Mobile IPv6. > >Yes. The use of new IPsec architecture and IKEv2 in 4877 solved that >issue. True. > >> (9) The way that the IPsec code sits in the usual kernel, and the >> access mechanisms for the SA database, are not very convenient >> for use by straightforward implementations of Mobile IPv6. >> Unusual calling sequences and parameter passing seems to be >> required on many platforms. > >Yes. Standardizing or at least providing some guidance on that would be >helpful. A tall order IMO. > >> (10) In certain environments the use of IPsec and IKEv2 for >> establishing the SA is considered as an overhead. Bandwidth >> constrained links such as cellular networks and air interfaces >> which are in the licensed spectrum tend to be optimized for user >> traffic. > >Future Aeronautical environments have those constraints. Nonetheless, >they will rely on IPsec and IKEv2 (see ICAO 9896 document). > >> MIP6 signaling with the IPsec overhead and the IKEv2 messages >> are viewed negatively. It is more acceptable to have >> signaling without IPsec encapsulation. > >Well, a security mechanism to protect MIPv6 signaling will certainly >require some bits in each packet. Let's compare that to what ESP adds to >be fair. > >> The issues listed above can be attributed as some of the causes for >> MIP6 not being implemented widely. > >;-) YMMV (a disclaimer would have helped I guess) > >> 6. Implementation Issues with IPsec >> >> 6.1. Triggering IKEv2 on the MN >> >> When the MIP6 application is invoked on the MN, as part of the >> initialization steps it is expected to install the appropriate SPD >> entries for protecting the mobility management signaling. Creation >> of the SPD entry works fine assuming that the MN is statically >> preconfigured with the HoA information since the HoA address is >> needed to create the SPD entries. Once the SPD entries are created, >> the MIP6 application generates the BU message and sends it via the >> socket. Based on the previously installed SPD entry the IP stack >> detects that the BU message needs IPsec protection and since there is >> no appropriate IPsec SA available, the OS kernel triggers the key >> management daemon to establish the needed IPsec SA. > >Right. > >> Things are not that straightforward when the HoA is assigned >> dynamically. MIP6 allows the MN to obtain the HoA dynamically during >> the establishment of the initial IPsec SA with the HA [RFC4877] and >> in this case the HoA is provided in the CONF IKEv2 payload. How is >> the key management daemon triggered to establish the IPsec SA with >> the HA in this case? > >Thanks for asking that question about section 9 of RFC 4877. I am on >your side here. > >> Normally there should be an SPD entry in the SPD with the HoA >> address as part of the selector and the outgoing BU message would >> be matched against that entry and this would trigger the kernel to >> request the establishment of the IPsec SA. But the >> MIP6 application is not able to install the appropriate SPD entry nor >> to generate the BU message since it doesn't have yet the HoA that is >> needed for this, the HoA becomes available only later as part of the >> IPsec SA establishment. So this is sort of a chicken and egg >> problem: the HoA is needed to trigger the establishment of the IPsec >> SAs, but the HoA is not available prior to the IPsec SA being >> established. > >+1 > >> The solution to this issue could be an out-of-band communication >> channel between the MIP6 application and the key management daemon >> through which the MIP6 application could request the establishment of >> the appropriate IPsec SA from the key management daemon without >> having to install the appropriate SPD entries and generate the BU >> message. > >yes. Or as it appears to be the underlying assumption a merged MIPv6/IKE >module (I don't advocate for that). A merged MIP6/IKE module is not a feasible option. Given that IKE is used as a means to setup an IPsec SA for VPN purposes only, I dont see the case for a MIP6 capable IKE module. > >> 6.2. Instructing IKEv2 to ask for the MN HoA/prefix >> >> In case of dynamic HoA assignment, the MIP6 application needs to >> instruct the key management daemon to request the HoA information >> from the HA. The MIP6 application must be able to tell whether it >> would like to get the complete address or only the prefix [RFC5026] >> from the HA, and also whether it would like to get the IPv4 HoA as >> part of the IKEv2 exchange. This requires an interface between the >> MIP6 application and the key management daemon. > >If the feature is needed, yes. > >> 6.3. Providing the MN prefix to the IKEv2 daemon >> >> When the key management daemon on the HA side receives a request from >> the initiator to allocate the MIP6_HOME_PREFIX it needs to get the >> prefix from the MIP6 daemon running on the HA. Therefore there must >> be a communication channel between the key management daemon and the >> MIP6 application through which the key management daemon could >> request the HoA/prefix information. Further, when assigning the >> prefix, the MIP6 application needs to create state and save the >> assigned address information and associate it with the MN which >> created the IPsec SA. So this looks like at this point there is a >> need to create the BCE in a some type of a "larval" state as a place >> where to save this information on the HA side. >> >> Request to assign an address (IPv6 and/or IPv4) via the CONF payload >> raises an additional concern, namely, how does the key management >> daemon know that it needs to obtain the address from the MIP6 >> application? A generic key management daemon would by default have >> some other means to provide the addresses in the CONF payload without >> consulting the MIP6 application, so there must be some method to tell >> the key management daemon that it should request the addresses from >> the MIP6 application. The author is not aware of any such method >> being available currently. > >me neither. > >> 6.4. Registering the MN's FQDN in DNS >> >> [RFC4877] allows the HA to register the MN's FQDN in the DNS. In >> this case the MN must provide the FQDN in the IDi payload in the >> IKE_AUTH step of the IKEv2 exchange. Consequently, there must be >> some interface between the key management daemon and the MIP6 >> application on the HA side through which the FQDN could be made >> available to the MIP6 application so that it can register the FQDN in >> DNS. > >Can you point a specific section of RFC 4877. I fail to find where this >feature is discussed. I hope Domagoj can answer this. > >> 6.5. Providing the Home Network Prefix to the MIP6 application >> >> When the key management daemon on the MN side obtains the home >> network prefix information from the HA, it needs to relay this >> information to the MIP6 application. This again requires a >> communication channel between the key management daemon and the MIP6 >> application. > >yes. > >> 6.6. SPD Entry for the HoA on the MN side >> >> Once the MIP6 application on the MN obtains the HoA (either assigned >> via the CONF IKEv2 payload [RFC4877] or autoconfigured from the >> MIP6_HOME_PREFIX [RFC5026]), the appropriate SPD entries need to be >> created in the SPD. Some key management daemons may require that >> they have full control of the SPD. In such cases the MIP6 >> application should not create the SPD entries by itself as this might >> confuse the MIP6 daemon and cause inconsistent state. Instead, the >> MIP6 application would need to instruct the key management daemon to >> create the appropriate SPD entries. > >StrongSwan developers hit that issue when implementing >MIGRATE/KMADDRESS because UMIP (the Mobile IPv6 daemon for Linux) >handles all the policies. It just let the IKE daemon perform the SA nego >for those policies. I think this is handled via the installpolicy=3Dno in >the configuration described on the following page: > > http://wiki.strongswan.org/wiki/strongswan/MobileNodeSetup Right.. Our implementation experience has been with Strongswan as well. > >For racoon (IKEv1 daemon), this was not an issue: racoon monitors the >in-kernel SPD. > >> So depending on the expectations >> of the key management daemon, the MIP6 application should either >> instruct the key management daemon to create the SPD entries or the >> MIP6 application should create them by itself at this point. > >yes. > >> If the policy requires protection of the data traffic the SPD entries >> for the data traffic would also need to be created at this point. > >yes. > > >> 6.7. SPD Entry for the HoA on the HA side >> >> The creation of the SPD entry on the HA side for protecting the MN's >> mobility signaling is similar to what is happening on the MN side and >> is described in the previous section. As soon as the HA assigns an >> HoA it may proceed with the creation of the appropriate SPD entry. >> The SPD entries for protecting the data traffic should also be >> created at this time. > >Another reason for having the Mobile IPv6 daemons interact with the SPD >directly. > >> However, the issue gets more complicated in the case where the HA >> provides the prefix to the MN and the MN autoconfigures the HoA. In >> this case neither the key management daemon nor the MIP6 application >> on the HA are aware of the MN's autoconfigured HoA so neither of them >> is in a position to install an appropriate SPD entry during (or >> immediately after) the IKEv2 exchange. Even worse, since the >> autoconfigured MN address is not known on the HA side it is not clear >> what is the contents of the TSi and TSr payloads in the final >> IKE_AUTH message sent by the HA. It is unclear whether or not the SA >> for protecting the MN's mobility signaling gets established at all in >> such a situation. >> >> TBD: verify whether this is really a problem... >> >> 6.8. The K bit >> >> The K bit [RFC3775] requires an interface between the IPsec subsystem >> and the MIP6 application that is not available today, at least not in >> a standardized form. Such an interface that would enable the support >> for the K bit has been proposed before and additional information how >> it might look like is available in [I-D.sugimoto-mip6-pfkey-migrate] >> and [I-D.ebalard-mext-pfkey-enhanced-migrate]. > >the latter is a follow-up of the former. Implementation feedback >provided by the implementation of the former showed that >SADB_X_EXT_PACKET mechanism had drawbacks. Hence the extension to use >KMADDRESS. > >[I-D.ebalard-mext-pfkey-enhanced-migrate] is currently available as a >draft and implemented. I had discussion with the chairs to go further in >the context of MEXT but the WG is not supposed to work on that kind of >item. Bummer.. And hence essentially no real solution being available. > >> However, those >> proposals were not standardized and as such there is no publicly >> available interface specification that could be used by the third >> party MIP6 application developers to invoke the key management daemon >> and IPsec kernel. Note also that the MIP6 application must have a >> detailed knowledge about the established IPsec SAs (complete SPD >> entries, old and new tunnel end points) in order to be able to >> indicate to the key management daemon which SAs needs to be updated, >> which is not in the spirit of the original IPsec intention to provide >> security to the applications in a transparent manner. > >Well, this is the work of the MIPv6 module to perform that, i.e. keep >that information updated. Agree. > >> 6.9. UDP encapsulation of DSMIP6 signaling > >I will not comment on DSMIPv6 because, IMHO, the problem of DSMIPv6 is >NAT, not IPsec/IKE. But I agree that DSMIPv6 is way too complex on many >aspects, including its relationships with IPsec/IKE. Guess we agree on some aspects... But I concur about the fact that DSMIP6 istelf does not really make the security architecture any more complex than it is as specified by MIP6. It suffers from the security paradigm adopted by MIP6. > >Personally, even if one can argue on the associated drawbacks of the >solution in term of encapsultation (IPv4/UDP/IPv6/ESP/IPv6/TCP/HTTP for >common traffic exchanged with my HA, which mean I lose at least 24 bytes >of MTU) and some other aspects (I don't have an IPv4 HoA), I use Teredo: >it has been designed to be smart about NAT and only that, it is good at >it and provides a very good abstraction: a usable IPv6 link. My MIPv6 >module is not IPv4 -aware and my IKE daemon is compiled with >--disable-natt ;-) > >> 7. Conclusion >> >> Examples in Section 6 show that there is a need for an extensive >> communication between the MIP6 application and the IPsec subsystem on >> the host. > >If you don't need the HoA assignment and additional features provided in >some section of 4877 and 5026, "extensive" is a bit too much. Okay.. But you know "Objects in mirror..." > >> Standardizing such communication channel and having it >> available in a commercial OS implementations is not a realistic >> proposal in any practical time frame. > >Please, site names of vendors and OS, not in the draft but on the >list. This is looks like a vendor issue more than anything else. I don't >like the logic but if you have a business case for them then previous >issue vanishes. > >> On the technical side, this is >> due to the fact that the IPsec is usually provided as part of the OS >> kernel and it is always difficult to convince the OS vendor to change >> the kernel and in particular the security related subsystems. The >> other difficulty is that the key management is usually provided as >> the user space service and as such there are multiple key management >> daemons available. Convincing vendors of various key management >> daemons to provide a unified or standardized communication channel >> for the MIP6 application might prove equally difficult and is not a >> realistic option either. > >You don't have to convince vendors. If the protocol is available >(documented) and the feature is worth implementing for their clients, I >don't see why they would refuse if other vendors would agree. I think vendors will shy away from (DS)MIP6 implementation after they see the complexity or have made some attempts to experiment with it. Making the protocol easier to implement at least would spur further implementations and hopefully gain some traction. > >> Besides the technical reasons, there are >> also other non-technical reasons of business or political nature why >> such proposals would be unrealistic. > >Can you extend that sentence into a paragraph. It looks promising ;-) Will try in the next rev... But I dont know if we want to be sidetracked into a discussion of why MIP6 is not implented in more platforms today. > >> Therefore this draft recommends that an alternate security framework >> be considered for MIP6. This alternate mechanism should be self >> contained so that it can be developed and delivered as part of the >> MIP6 application itself (from an implementation perspective analogous >> to the way web browsers handle security today). This would enable >> third party developers that have no access or are otherwise not in a >> position to change the IPsec code of the platform they are developing >> for to come up with a self contained and working MIP6 application. >> Such alternative security mechanisms would remove one of the major >> impediments, i.e the interactions with IPsec - why it is so difficult >> today to implement a working MIP6 application. This would foster the >> diversity of the MIP6 solutions and should therefore have beneficial >> effects on the availability of MIP6 solutions and promote the >> adoption of MIP6 in general. > >Why is there a need to modify the generic solution (I mean changing >3775 for instance) if an alternative document is sufficient (like what >4285 does, for the reasons described in RFC 5419) > >In the end, it's all about serving the Internet or specific >SDOs/vendors. I think the IETF in general and MIPv6 in particular try >and do the former. And the IETF could do a better job and make the life of vendors easier by providing solutions which are pragmatic and not based on some design philosophies which are outdated. There is IMO no shame in admitting that IPsec/IKEv2 is not the best security framework for MIP6. Either the IETF does something to address the concerns raised by vendors and implementers to develop something that can simplify the protocol or let it sit on the shelves and die. > >> In order to make the Mobile IPv6 protocol a solution that is easy to >> implement and available in even low-end devices, it is necessary to >> simplify the protocol. The design or the security architecture for >> MIP6 needs to be revisited and a solution that simplifies the >> implementability of the protocol considered. The implementation >> experience shows that a working solution of Mobile IPv6 is possible >> to build. However it is not easily done. > > >> 8. Security Considerations >> >> This I-D discusses the security architecture of Mobile IPv6 which is >> based on IPsec. The dependency on IPsec for security of MIP6 >> signaling is a detriment to the protocol implementation and >> deployment. Hence the current security architecture needs to be >> reconsidered. >> >> The experience gained over the last few years indicates that IPsec >> cannot necessarily be used as a generic solution for security. > >IPsec cannot be used to protect all protocols. Hence the specification >of SEND for instance. But I think MIPv6 is among the few protocols which >have made effort to build their security on IPsec/IKE without relying >only on a simple sentence somewhere in the document stating "for >security needs, IPsec should be use". I would agree that more work is >needed on some aspects (interfaces) even if the WG is more interested by >pushing additional features. > >If the security work on IPsec/IKE integration with MIPv6 had been >completed before the extension of the protocol (DSMIPv6, ...), this >may have prevented such issues. > >I agree that some of the features described in companion documents of >MIPv6 have been described at a too high level and cannot be implemented >easily. Thank you. I think you will realize the complexities of the implementation when you go through an exercise of doing so. > >> The design choice made for MIP6 in the initial stages no longer are >> valid and is hampering the implementation and use. >> >> >> 9. IANA Considerations >> >> This document does not have any information which requires IANA >> review. >> >> >> 10. Acknowledgements >> >> Jouni Korhonen would like to point out the importance of sustained >> supply of caffeine rich coffee when doing IETF work. > >Fully agree ;-) > >> Authors would also like to recognize Satyabrata Sahu, NK Garg, >> Sandeep Minocha and Harsh Verma for working on the implementation. > >What about discussing the specific technical details of the problems >they found during the implementation on the list and try and address >them one by one. Can I also ask what they implemented precisely and for >which specific platform? I would understand if that cannot be discussed >publicly, obviously. We can discuss this offline. But I can say that the implementation of DSMIP6 was done on a RHEL version of Linux. Thanks for your comments. -Raj > >Cheers, > >a+ From jari.arkko@piuha.net Sat Jul 25 07:13:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24D13A68A9 for ; Sat, 25 Jul 2009 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599] 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 HCvW-VlECkqE for ; Sat, 25 Jul 2009 07:13:17 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 073223A6810 for ; Sat, 25 Jul 2009 07:13:17 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 3C11A198781; Sat, 25 Jul 2009 17:13:08 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id DA3631986E2; Sat, 25 Jul 2009 17:13:07 +0300 (EEST) Message-ID: <4A6B12F2.5060608@piuha.net> Date: Sat, 25 Jul 2009 17:13:06 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: draft-ietf-mext-binding-revocation@tools.ietf.org, "mext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [MEXT] AD review of draft-ietf-metxt-binding-revocation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 14:13:18 -0000 I have reviewed this draft. It is basically in very good shape, but I did see a few minor issues which I would like to get corrected before last call. Here are my detailed comments: Section 5 talks about NATs and UDP encapsulation, but only with respect to proxy mobility. Client mobility case should be handled as well. The list of fields after Figure 4 might be more readable if you included all fields, such as MH Type. > Indication message, the responder MUST constructs the Binding MUST construct > Since some mobility entities, e.g., local mobility anchor and mobile > access gateway, are allowed to receive and possibly send a Binding > Revocation Indication or Binding Revocation Acknowledgement for > different cases, therefore, if IPsec is used to secure signaling > between the them, it prevents any possible man in the middle > reflection attack. > Its not clear to me what attacks you are talking about here. Reflection attacks normally mean that the attacker sends a packet that a third party responds to and sends the response to the victim. Perhaps you meant to say "... prevents the processing of a message not constructed by an authorized party"? > BCE that belong to a specific realm, e.g. @companyabc.com, that are Please use example.com instead. > wildcard > NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs > that need to be removed. > You need to specify what the syntax of the wildcard format is. Note that '*' is a legal character in the username portion of a NAI [RFC4282], so I would recommend considering another syntax (such as @example.com). I would like to change the retranmission procedure to use an exponential back-off, in a style similar to RFC 3775, Section 11.8. This procedure is both more friendly to other traffic in a congestion situation, as well as faster in resending a lost first packet. Jari From julienl@qualcomm.com Mon Jul 27 01:43:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883C628C245 for ; Mon, 27 Jul 2009 01:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-1.250, 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 e-dd78+I8eKK for ; Mon, 27 Jul 2009 01:43:29 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A8DC128C242 for ; Mon, 27 Jul 2009 01:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1248684211; x=1280220211; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"marcelo@i t.uc3m.es"=20,=0D=0A=20=20=20=20=20 =20=20=20"Laganier,=20Julien"=0D=0A=09|Date:=20Mon,=2027=20Jul=202009=2001:43:23=20-0700 |Subject:=20Volunteer=20as=20a=20MEXT=20Jabber=20Scribe =20and/or=20Note-taker|Thread-Topic:=20Volunteer=20as=20a =20MEXT=20Jabber=20Scribe=20and/or=20Note-taker |Thread-Index:=20AcoOlkzTqrtPRSUMTemmfLza2jbvuw=3D=3D |Message-ID:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5689"=3B=20a=3D"21278587"; bh=2DbrN0pPg2Z+Ao9V45bU7bNset+AV7inATGUIYJS4x8=; b=XR9HCLYlvj/P8pUhxa9159dTbL7wiYxDnw7J+dSpOADbrN4iwK7qCK3V N/OvnzdAAtDJxavaeWHEH/7oumXeGl3A2sbLmDg0jCDP7nInOAWdOyPgv 0R2Q6L5EQNbrZuRiX1Rktr6rEnkfnYn114nGInE7KBBkTlt8O5xdAtvf0 A=; X-IronPort-AV: E=McAfee;i="5300,2777,5689"; a="21278587" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2009 01:43:30 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6R8hUIM028065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Jul 2009 01:43:30 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6R8hTLo010388 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jul 2009 01:43:30 -0700 (PDT) Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 27 Jul 2009 01:43:29 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Mon, 27 Jul 2009 01:43:29 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Mon, 27 Jul 2009 01:43:23 -0700 Thread-Topic: Volunteer as a MEXT Jabber Scribe and/or Note-taker Thread-Index: AcoOlkzTqrtPRSUMTemmfLza2jbvuw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Laganier, Julien" Subject: [MEXT] Volunteer as a MEXT Jabber Scribe and/or Note-taker X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:43:30 -0000 Greetings, We'd need volunteers for taking notes and scribing on Jabber for tomorrow's= two MEXT sessions (TUESDAY, July 28, 2009, 1520-1700 Afternoon Session II,= 1710-1810 Afternoon Session III.) Our Agenda is full and as usual we won't= be able to start the meeting before finding them, so please volunteer by c= ontacting the chairs and help to increase meeting productivity. We do appreciate your support. --julien & Marcelo, MEXT chairs From AMUHANNA@nortel.com Mon Jul 27 07:37:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7157528C153 for ; Mon, 27 Jul 2009 07:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 vOQmjhBR65h9 for ; Mon, 27 Jul 2009 07:37:49 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8ECD328C142 for ; Mon, 27 Jul 2009 07:37:45 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6RESt304698; Mon, 27 Jul 2009 14:28:55 GMT 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: Mon, 27 Jul 2009 09:28:53 -0500 Message-ID: In-Reply-To: <4A6B12F2.5060608@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-metxt-binding-revocation thread-index: AcoNMhHuc+0Jj6pfTVWGg8ESLlhuUABkn7bQ References: <4A6B12F2.5060608@piuha.net> From: "Ahmad Muhanna" To: "Jari Arkko" , , Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 14:37:51 -0000 Hello Jari, Thanks for the review and comments. Please see inline. Regards, Ahmad > -----Original Message----- > From: Jari Marko [mailto:jari.arkko@piuha.net]=20 > Sent: Saturday, July 25, 2009 9:13 AM > To: draft-ietf-mext-binding-revocation@tools.ietf.org; mext@ietf.org > Subject: AD review of draft-ietf-metxt-binding-revocation >=20 > I have reviewed this draft. It is basically in very good=20 > shape, but I did see a few minor issues which I would like to=20 > get corrected before last call. >=20 > Here are my detailed comments: >=20 > Section 5 talks about NATs and UDP encapsulation, but only=20 > with respect to proxy mobility. Client mobility case should=20 > be handled as well. [Ahmad] Sure, we will address client MIP6 case. >=20 > The list of fields after Figure 4 might be more readable if=20 > you included all fields, such as MH Type. [Ahmad] No problem. Will do. >=20 > > Indication message, the responder MUST constructs the Binding > MUST construct >=20 > > Since some mobility entities, e.g., local mobility=20 > anchor and mobile > > access gateway, are allowed to receive and possibly send=20 > a Binding > > Revocation Indication or Binding Revocation Acknowledgement for > > different cases, therefore, if IPsec is used to secure signaling > > between the them, it prevents any possible man in the middle > > reflection attack. > > =20 >=20 > Its not clear to me what attacks you are talking about here.=20 > Reflection attacks normally mean that the attacker sends a=20 > packet that a third party responds to and sends the response=20 > to the victim. >=20 > Perhaps you meant to say "... prevents the processing of a=20 > message not constructed by an authorized party"? [Ahmad] I was thinking that if a man in the middle was able to capture a packet which contains a BRI from the MAG, for example, the attacker will not be able to send the packet back to the MAG as if it is coming from the LMA. Thinking about this a little more, the consequences is not so critical since if the MAG has sent a BRI to the LMA, it is already revoking the MN session anyway. However, I was initially thinking even if the MAG receives that packet and processes it as if it is coming from the LMA, it is a problem, but IPsec prevents that since IPsec SA in unidirectional with different SPIs. That why I mentioned it. If you think it is not necessary, we can remove it. >=20 > > BCE that belong to a specific realm, e.g.=20 > @companyabc.com, that are >=20 > Please use example.com instead. [Ahmad] Sure. >=20 > > wildcard > > NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs > > that need to be removed. > > =20 > You need to specify what the syntax of the wildcard format=20 > is. Note that '*' is a legal character in the username=20 > portion of a NAI [RFC4282], so I would recommend considering=20 > another syntax (such as @example.com). [Ahmad] Sure. Will fix it. >=20 > I would like to change the retranmission procedure to use an=20 > exponential back-off, in a style similar to RFC 3775, Section=20 > 11.8. This procedure is both more friendly to other traffic=20 > in a congestion situation, as well as faster in resending a=20 > lost first packet. [Ahmad] No problem, we can adopt an exponential back-off scheme similar to RFC3775. We will update the draft and post as soon as possible. Thanks again. Best Regards, Ahmad >=20 > Jari >=20 >=20 From arno@natisbad.org Mon Jul 27 12:29:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC313A6A6B for ; Mon, 27 Jul 2009 12:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 DYDygSufF+mT for ; Mon, 27 Jul 2009 12:29:21 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 79ED53A693C for ; Mon, 27 Jul 2009 12:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: Message-ID:MIME-Version:Content-Type; bh=jLGbtM3kRQDkmJH/q58UUeL mw2g6gSec9aGF2XxYJC0=; b=ANcXO+RGToXgST2ShLb/9JeguRjip5d80e4SpQa UEwbOWqNHqvv9sCoLNOiHAfzV9eEALgag1lxFPCzbaQe4QCMt6hbIgexa128V45d 6ZRJ+Z8XWJG+TfMwE9t1/j9GdIgp1sVs+o3+8q1b85LEmUGoXWQEItdYOCufRf9s /l/A= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MVVsr-0001cR-R8; Mon, 27 Jul 2009 21:29:18 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: References: X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090724:basavaraj.patil@nokia.com::dEjTgGUFi35+nFHg:0000000000000000000000000000000000003IYY X-Hashcash: 1:20:090724:mext@ietf.org::EC3MXVPAQfnQ9uEc:00007VQL Date: Mon, 27 Jul 2009 21:29:51 +0200 Message-ID: <87tz0xkjps.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 19:29:25 -0000 Hi, writes: >>You should introduce the SDOs here i.e. have "some SDOs (XXX, YYY, >>...). They are *never* cited in the whole document. The issues common >>and specific to each of those about IPsec/IKE should be summarized in >>the document. > > MIP6 itself has been specified as a solution by NWG in WiMAX forum, > 3GPP2 and DSMIP6 has been specified by 3GPP in Rel 8. Will mention in > the next rev of the I-D. Thanks. >>> 4. Problem Statement >>> >>> Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an >>> implementation and deployment perspective. As a protocol solution >>> for host based mobility, MIP6 can be simpler without the IPsec >>> baggage. The issues with IPsec are even more exacerbated in the case >>> of dual-stack MIP6 [RFC5555]. >> >>Sorry, but the design decisions taken for DSMIPv6 make it the way it >>is. You cannot blame IPsec/IKE for IPv4/NAT issues. The problem with >>DS-MIPv6 is that it does not provide IPv6 connectivity for the MN that >>could be used transparently by the stack (Teredo does that). When the >>protocol has been designed, it has been decided to open the door to >>IPv4, which let the NAT issue enter. Due to that decision, the >>difficulties of IPv4/NAT have also impacted the use of DSMIPv6 with >>IPsec/IKE. > > Agree. But the point is because of the security architecture of MIP6 > is based on IPsec, the issues with IPv4/NAT are inherited by DSMIP6 > and as a result the protocol becomes much more complex... At least > from implementations perspective. Trying to provide a mobility solution that support all combinations of IPv4/IPv6 CoA w/ IPv4/IPv6 HoA in environments which include NAT is the main explanation. That been said, IPsec/IKE are not known to be very NAT friendly. Said otherwise, NAT prevents IPsec/IKE deployment. It depends on the way you see it. I think MIPv6 (and IPv6) designers made the hypothesis IPsec and IKE were usable on IPv6 networks. It was kind of decided to take a new start w/o NAT i.e. w/ the hypothesis of flat and E2E-friendly networks. Accepting regressions in our security solutions to keep coping w/ NAT is IMHO a bad path to follow. >>> IPsec is unable to provide security protection for MIP6 in a >>> transparent way, and numerous interactions between the host's >>> security subsystems and the MIP6 application are needed in the course >>> of the regular operation of the MIP6 application. >> >>For common scenario, MIGRATE/KMADDRESS solution is sufficient. This >>requires small changes to the IPsec stack, the IKE daemon and the MIPv6 >>module. After 3776, it is my feeling that MEXT documents have slowly >>shifted towards tighter relationships between the MIPv6 module and the >>IKE (address assignment) module to the point that it would be difficult >>today to provide all the functionalities pushed so far without having a >>common MIPv6/IKE module (or at least complex interactions between >>those). > > Agree. And the issue is with the fact that complex interactions are > needed between the modules. Basically you cannot expect to use the > existing IPsec/IKEv2 engine on a host to work with your MIP6 > implementation with no changes. You end up having to modify the > security module to work with (DS)MIP6 module and this is not a task > for the faint-hearted. I think we agree. IMHO, supporting suspend (to RAM) for recent laptops which includes a lot of features and devices is also not a task for the faint-hearted. Nonetheless, people managed to implement it and make it work. I think there are thinsg that are far more complex than the required basic (I don't consider the dynamic address assignment extension) interactions between the modules. My best arguments are: - spec is quite short. - implementation exist and work. >>> Besides requiring an extensive communications channel between the >>> security subsystems and the MIP6 application, those interactions >>> often also require modification of the MNs security subsystems >>> code. >> >>Well, I expect all possible L3 solutions to require changes to the >>security subsystems to support MIPv6 needs but I'd like to be proven >>wrong. > > Take a look at the TLS based security architecture framework solution > proposed in I-D: draft-korhonen-mext-mip6-altsec-01.txt I read the draft. If I had to summarize the protocol the protocol I would say the HAC provides the same function as a KDC in Kerberos domains, granting HTTP tickets using TLS. Then, is looks like a kerberos-based relying on TLS (or even DTLS) for MIPv6 is IMHO a bad design idea. I did not resist to take a *quick* look: o there is an additional box in the picture, the HAC o "This specification defines a generic packet format, where everything is encapsulated inside an UDP." o You implement a mapping between TLS1.2 negotiated ciphersuite and ESP algs. o The only notable difference is that the SPI is prefixed with 4-bit PType field leaving 28-bit SPI value, although from the ESP processing point of view, the 4-bit PType and 28-bit SPI are handled as one "32-bit SPI". o section 5.2, the LS_RSA_WITH_AES_256_CBC_SHA is wrong, isn't it? It should map to AES-256 instead of AES-128. o The treatment of MN-CN route optimization is outside the scope of the document. o In 5.4.2, "The MN or the HA MAY switch between the encryption and plain text at any time based on local policies": what if an attacker knows the SPI and the sequence number. Can she start sending plaintext packets to one or another endpoint just by changing the ptype? o You use the IPsec stack to protect traffic using ESP. You use SA for that purpose. There is nothing in the document about associated Security Policies (SP). Are the ones defined in 3776 reused? Can you clarify that point? At some point, considering you drop RO, I wonder why not going for one of the following solutions instead of keeping MIPv6 in the picture: - use of a DTLS-based VPN w/ session resumption - use of an IKEv2 MOBIKE-enabled VPN > We believe that it does not require changes to the security engine on > the host. It is a solution which uses the APIs and libraries of TLS on > the host without having to modify them. > The problem with IPsec/IKEv2 and MIP6 is that we end up having to > modify the security subsystem to make it work and this is not a > feasible option in all instances. One of the problem you have with MIPv6 are the required interactions with IPsec/IKE, for instance in order to update the SA endpoints. In draft-korhonen-mext-mip6-altsec-01.txt, you skip this point and do not explain how the interactions with the IPsec stack are done. Can you clarify? >>> The situation today is such that the communications channel >>> between the IPsec subsystems and the MIP6 application is non >>> existent and this is generally true for most of the commercially >>> available platforms. >> >>The sentence is correct. >> >>Well, I won't advocate for other platforms but at least Linux has that >>now, which proves it is feasible: >> >> - Upstream Kernel supports full MIGRATE/KMADDRESS since 2.6.28. Current >> is 2.6.30. >> - racoon (IKEv1) has support for MIGRATE/KMADDRESS for a while now >> - StrongSwan developers have added support for MIGRATE/KMADDRESS to >> Charon, their IKEv2 daemon. > > Right... And this is what we have worked with on our implementation as > well. While we can use these interfaces, I should say that it is still > not easy and again these are not available on all platforms. > >> - patches exist for racoon2 >> >>I can't say about *BSD platform. > > Or for that matter Symbian or Maemo (linux) etc.. Considering current work of Nokia developers in Linux Kernel, I expect the future brother of the N810 which will run Maemo 5 to include a post-2.6.28 kernel, which will make it almost directly MIPv6 w/ IPsec/IKE capable. BTW, you may be interested by what is on http://natisbad.org/N810 + the armel packages for Debian now available on the repository advertised on http://natisbad.org/MIPv6. >>> Even if such a channel were to be available, there does not exist a >>> standardized protocol over that channel which would enable the MIP6 >>> application to communicate with the security modules in a non- >>> implementation specific way. >> >>Well, I already pointed that and even provided follow-up work for >>MIGRATE/KMADDRESS but this was considered out of scope for the >>WG. Having that work done in the context of ipsecme WG was not possible >>either. >> >>But thanks for stressing that point. > > Right.. We did note work (reference) done by you in this context. But > it has not really progressed. I could have kept incrementing the number at the end of the draft every 6 months or so but this is pointless if the chairs consider that the WG should not work on such interfaces. >>> Considering a third party application developer who would like to >>> provide a MIP6 application for a particular platform, the need for >>> numerous interactions with the IPsec subsystem and the unavailability >>> of the standardized communications channel through which such >>> interactions could take place is a major obstacle to the >>> implementation of the mobility protocol. Without such a >>> communication channel being available it is not possible to implement >>> a MIP6 application as a third party developer. >> >>3 main possible solutions: >> >> - standardize the interface >> - make MIPv6 module and IKEv2 module a common module (as >> progressively expected by MEXT documents published after 3775) >> - give up on the use of IPsec/IKE > > Yes... The last option is what we are recommending. The others do not > seem to be easily surmountable. I think we just disagree on that part ;-) I prefer the first option. >>> The problem in a nutshell for MIP6 is the dependence on IPsec and >>> IKEv2 for successful operation. >> >>I respectfully disagree, not with the various points above, but with the >>way you interpret them. Vendors implement features in their products >>based on business case and possibly the availability of a standard. If >>open source product already have the feature, I think may indicate the >>issue is not the technical feasibility ... > > Having worked on this implementation, I am not arguing that it cannot > be done. All I am saying is that it is a real pain to implement it and > get it working. Additionally while it is possible to do this on open > source where you have control of all the modules, it is not > necessarily the case on all platforms. For example you would not be > able to modify the IPsec/IKEv2 modules on Symbian if you were building > the MIP6 module. Only Symbian could do that. And the same goes for > many other platforms as well. > >> >>From a discussion I had with some MS engineers after they unleashed the >>details on Vista's IPv6 stack, asking them for the reasons why it had no >>MIPv6 support: no business case and no standard interface to secure >>it. > > No business case from the perspective of MS... Maybe. But I am not > sure I understand what you meant by "no standard interface to secure > it". [Probably] Due to their history, MS now consider the security aspects of a protocol before putting it in their system. It's nice to have a feature. It's a pain if it can be subverted with no way to prevent that. >>3775 and 4877 provide a *generic* solution for the Internet environment, >>i.e. common platforms and systems. As you write, "[IPsec as a default >>feature] is true in many host implementations today". If specific >>systems have specific needs which do not fit with a generic solution, >>then they need a specific solution. If they are so specific, they may >>simply not be in the scope of MIPv6 generic solution. > > Let me give you an example.. A mobile phone (not the smartphone types > lets say) does not need IPsec/IKEv2. However it does not need mobility > support on networks which would provide mobility via an HA. So the > point is mobility may be a requirement in certain cases, whereas > IPsec/IKEv2 is not. I wonder if in two years Nokia (or other phone vendors) will have non-smartphone phones. It's like looking today for a phone without a camera. > IPsec in hosts is used primarily (and probably only) by VPN > applications. Is there any other protocol on a host which requires > IPsec? So why is MIP6 having to rely on IPsec and IKEv2. Because MIPv6 is not a L4 protocol but an extension of IPv6. > The design goals in the late 90s were based on some principles which > are not very practical today. You are thinking about "Client/Server" model forced by NAT I presume ? ;-) >>> MIP4 signaling is integrated into the protocol itself. MIP4 has >>> been successfully deployed on a large scale in several networks. >> >>Can you describe the assumptions about those network? Do they come with >>link layer security for instance? > > Yes. They do have security at the lower layers. > >>Can a user of those networks move to >>the Starbuck at the corner and use the wifi there without the need to >>care about how its data are protected on that foreign network? > > They could. Depends on the type of data and how concerned they are > about protecting it (i.e level of paranoia). > >> >>RFC 3775 Introduction starts with: "This document specifies a protocol >>which allows nodes to remain reachable while moving around in the IPv6 >>Internet" >> >>> (2) IPsec use in most hosts is generally for the purpose of VPN >>> connectivity to enterprises. It has not evolved into a generic >>> security protocol that can be used by Mobile IPv6 easily. While >>> RFC4877 does specify the details which enable only the MIP6 >>> signaling to be encapsulated with IPsec, the general method of >>> IPsec usage has been such that all traffic between a host and >>> the IPsec gateway is carried via the tunnel. Selective >>> application of IPsec to protocols is not the norm. Use of IPsec >>> with Mobile IPv6 requires configuration which in many cases is >>> not easily done because of reasons such as enterprise >>> environments preventing changes to IPsec policies or other. >>> (3) A MIP6 home agent is one end of the IPsec SA in a many-to-one >>> relationship. A MIP6 HA may support a very large number of >>> mobile nodes which could be in the hundreds of thousands to >>> millions. The ability to terminate a large number of IPsec SAs >>> (millions) requires signifiant hardware and platform capability. >>> The cost issues of such an HA are detrimental and hence act as a >>> barrier to deployment. >> >>Can some vendor comment on that. Do we agree that the amount of traffic >>is not the issue but the initial IKE negotiation and the number of SA >>might be? > > The number of messages exchanged to setup the IPsec SA is an > issue. Especially when you compare it with the registration process > required for MIP4. So if you compare the number of steps for > registration of an MN for MIP6 vs MIP4, you would see the difference. Can you compare the amount of traffic exchanged between a MN and a HA using IKEv2 to setup the SA with the traffic exchanged in an alternate solution, say draft-korhonen-mext-mip6-altsec-01.txt? >>> (4) The implementation complexity of Mobile IPv6 is greatly >>> increased because of the interaction with IPsec and IKEv2. A >>> standalone MIP6 protocol is easier to implement and deploy (such >>> as MIP4 [RFC3344]). The complexity of the protocol >>> implementation is even more so in the case of Dual stack MIP6 >>> [RFC5555]. >> >>MIPv6 and MIPv4 do not have equivalent feature security-wise. MIPv6 is >>certainly more complex on that aspect than MIPv4 but it allows >>more. > > More is not necessarily good :) (Kitchen sink protocol design) > >> Moreover, it builds (even if some bits may be missing >>interface-wise) on existing and mature protocol (not speaking about >>IKEv2 yet ;-) ) which prevents reinventing the wheel. > > Well show me another protocol on the host which relies on the reuse of > an existing and mature protocol like IPsec. All the TCP and UDP based protocols my VPN carry without the need to worry about the environment in which I am at a given moment. >>> (5) IPsec and IKEv2 are not implemented or available by default in >>> every IPv6 or dual stack host. >> >>Can you list some (2 or 3) systems that are of common use today and that >>do not have that? > > Proprietary OS' come to mind. Devices with these types of OS' are > fairly common. Can you cite vendors and devices? >>> Mobile IPv6 support on such devices is not an option. Many >>> low-end cellular hosts have IP stacks. The need for IPsec and >>> IKEv2 in these devices is not important whereas mobility >>> support is needed in many cases. >> >>I may be wrong but the way I see it is that current trend if for >>cellular devices to come with complete systems today: what does the >>iPhone runs? Nokia is currently shifting towards Linux based solutions >>(ofono, maemo, ...)? Many phones runs Windows Mobile too, ... >> >>If you consider the previous devices and most of the laptop (99% of >>the latter running Mac OS X, Linux or Windows), I think you have the >>initial targets MIPv6 is trying to provide mobility for. Or am I missing >>your point? > > Well.. Nokia devices based on Maemo and Symbian do include IPsec > support. But for lower end devices which are primarily intended for > voice service and some data, there is no IPsec even though there is an > IP stack. Additionally I dont know about many other devices which are > becoming capable of connecting to the Internet but do not need an > IPsec stack. Is that what you meant in the last sentence? >>> A simpler security protocol than the use of IPsec/IKEv2 would make >>> MIP6 much more attractive to implement and deploy. >> >>Those sepecific devices may need a specific solution. I agree on that. >> >>> (6) [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile >>> IPv6 essentially results in a variant of IPsec which is specific >>> to Mobile IP. >> >>No. IPsec stack and IKE daemon may already have support for MOBIKE which >>does exactly what we need. The only difference is that the signaling >>goes through the IKE channel. With MIPv6, signaling is MIPv6 one >>(BU/BA). In all cases, extending the IPsec stack to support MIPv6 is >>light. Same for IKE. > > I think this where I would disagree. At least from our experience of > doing a DSMIP6 implementation, the challenges are primarily in the > interactions between the mobility module and the IPsec/IKEv2 > modules. YMMV. I won't argue for DSMIPv6. >>> Hence this results in added complexity to implementations. >> >>No. Compare the small required extensions (MIGRATE/KMADRESS is short to >>read) with what it would cost to provide the same amount of features >>(protecting signaling and possibly data) but by designing and >>implementing a specific protocol in the MIPv6 module. >> > > Making changes to the IPsec or IKEv2 modules may not always be an > option. Especially if you have no control of those modules on a > host. You would then have to rely on these interfaces being > standardized and implemented on all hosts for the mobility module to > rely on. > >>IMHO, a simple extension cost less than a complete new design. And >>considering you are speaking about a security solution, designing from >>ground a new security solution for your own need is starting looking for >>trouble, all the more if you are trying to provide a L3 security >>solution, i.e. trying to compete with IPsec/IKE. > > I think we can do simpler security solution than IPsec/IKEv2 which > would simplify the implementation vastly while preserving the security > aspects of the MN-HA communications. At the moment, draft-korhonen-mext-mip6-altsec-01 relies on TLS, IPsec, HTTP, BNF, RFC3948, ... and an additional box. >>> (7) Mobile IPv6 needs to be capable of being deployed in situations >>> where alternative security mechanisms are already well- >>> understood by the network administration. It should be possible >>> to enable Mobile IPv6 to work in situations where alternative >>> security mechanisms already supply the necessary authentication >>> and privacy. >> >>Agree. >> >>> (8) IPsec has been successfully applied to VPN and other >>> infrastructure operations, but less so for general end-to-end >>> applications. Thus, the granularity for selectors was >>> originally not at all sufficient for Mobile IPv6. >> >>Yes. The use of new IPsec architecture and IKEv2 in 4877 solved that >>issue. > > True. > >> >>> (9) The way that the IPsec code sits in the usual kernel, and the >>> access mechanisms for the SA database, are not very convenient >>> for use by straightforward implementations of Mobile IPv6. >>> Unusual calling sequences and parameter passing seems to be >>> required on many platforms. >> >>Yes. Standardizing or at least providing some guidance on that would be >>helpful. > > A tall order IMO. I am not the one you need to convince ;-) >>> The solution to this issue could be an out-of-band communication >>> channel between the MIP6 application and the key management daemon >>> through which the MIP6 application could request the establishment of >>> the appropriate IPsec SA from the key management daemon without >>> having to install the appropriate SPD entries and generate the BU >>> message. >> >>yes. Or as it appears to be the underlying assumption a merged MIPv6/IKE >>module (I don't advocate for that). > > A merged MIP6/IKE module is not a feasible option. Given that IKE is > used as a means to setup an IPsec SA for VPN purposes only, I dont see > the case for a MIP6 capable IKE module. Think RO. IMHO, if you consider MIPv6 and remove the RO, you may obtain something that can easily replaced by a common VPN software w/ MOBIKE support. >>> 6.4. Registering the MN's FQDN in DNS >>> >>> [RFC4877] allows the HA to register the MN's FQDN in the DNS. In >>> this case the MN must provide the FQDN in the IDi payload in the >>> IKE_AUTH step of the IKEv2 exchange. Consequently, there must be >>> some interface between the key management daemon and the MIP6 >>> application on the HA side through which the FQDN could be made >>> available to the MIP6 application so that it can register the FQDN in >>> DNS. >> >>Can you point a specific section of RFC 4877. I fail to find where this >>feature is discussed. > > I hope Domagoj can answer this. I'll wait for his answer. >>> 6.5. Providing the Home Network Prefix to the MIP6 application >>> >>> When the key management daemon on the MN side obtains the home >>> network prefix information from the HA, it needs to relay this >>> information to the MIP6 application. This again requires a >>> communication channel between the key management daemon and the MIP6 >>> application. >> >>yes. >> >>> 6.6. SPD Entry for the HoA on the MN side >>> >>> Once the MIP6 application on the MN obtains the HoA (either assigned >>> via the CONF IKEv2 payload [RFC4877] or autoconfigured from the >>> MIP6_HOME_PREFIX [RFC5026]), the appropriate SPD entries need to be >>> created in the SPD. Some key management daemons may require that >>> they have full control of the SPD. In such cases the MIP6 >>> application should not create the SPD entries by itself as this might >>> confuse the MIP6 daemon and cause inconsistent state. Instead, the >>> MIP6 application would need to instruct the key management daemon to >>> create the appropriate SPD entries. >> >>StrongSwan developers hit that issue when implementing >>MIGRATE/KMADDRESS because UMIP (the Mobile IPv6 daemon for Linux) >>handles all the policies. It just let the IKE daemon perform the SA nego >>for those policies. I think this is handled via the installpolicy=no in >>the configuration described on the following page: >> >> http://wiki.strongswan.org/wiki/strongswan/MobileNodeSetup > > Right.. Our implementation experience has been with Strongswan as well. The feature is available upstream now. >>> 6.8. The K bit >>> >>> The K bit [RFC3775] requires an interface between the IPsec subsystem >>> and the MIP6 application that is not available today, at least not in >>> a standardized form. Such an interface that would enable the support >>> for the K bit has been proposed before and additional information how >>> it might look like is available in [I-D.sugimoto-mip6-pfkey-migrate] >>> and [I-D.ebalard-mext-pfkey-enhanced-migrate]. >> >>the latter is a follow-up of the former. Implementation feedback >>provided by the implementation of the former showed that >>SADB_X_EXT_PACKET mechanism had drawbacks. Hence the extension to use >>KMADDRESS. >> >>[I-D.ebalard-mext-pfkey-enhanced-migrate] is currently available as a >>draft and implemented. I had discussion with the chairs to go further in >>the context of MEXT but the WG is not supposed to work on that kind of >>item. > > Bummer.. And hence essentially no real solution being available. You can help me push things forward ;-) >>> Standardizing such communication channel and having it >>> available in a commercial OS implementations is not a realistic >>> proposal in any practical time frame. >> >>Please, site names of vendors and OS, not in the draft but on the >>list. This is looks like a vendor issue more than anything else. I don't >>like the logic but if you have a business case for them then previous >>issue vanishes. >> >>> On the technical side, this is >>> due to the fact that the IPsec is usually provided as part of the OS >>> kernel and it is always difficult to convince the OS vendor to change >>> the kernel and in particular the security related subsystems. The >>> other difficulty is that the key management is usually provided as >>> the user space service and as such there are multiple key management >>> daemons available. Convincing vendors of various key management >>> daemons to provide a unified or standardized communication channel >>> for the MIP6 application might prove equally difficult and is not a >>> realistic option either. >> >>You don't have to convince vendors. If the protocol is available >>(documented) and the feature is worth implementing for their clients, I >>don't see why they would refuse if other vendors would agree. > > I think vendors will shy away from (DS)MIP6 implementation after they > see the complexity or have made some attempts to experiment with > it. Making the protocol easier to implement at least would spur > further implementations and hopefully gain some traction. We do not need to change the whole protocol for that purpose. Mainly specify the missing parts ... >>> Besides the technical reasons, there are >>> also other non-technical reasons of business or political nature why >>> such proposals would be unrealistic. >> >>Can you extend that sentence into a paragraph. It looks promising ;-) > > Will try in the next rev... But I dont know if we want to be > sidetracked into a discussion of why MIP6 is not implented in more > platforms today. I am Looking forward to read it. >>> In order to make the Mobile IPv6 protocol a solution that is easy to >>> implement and available in even low-end devices, it is necessary to >>> simplify the protocol. The design or the security architecture for >>> MIP6 needs to be revisited and a solution that simplifies the >>> implementability of the protocol considered. The implementation >>> experience shows that a working solution of Mobile IPv6 is possible >>> to build. However it is not easily done. >> >> >>> 8. Security Considerations >>> >>> This I-D discusses the security architecture of Mobile IPv6 which is >>> based on IPsec. The dependency on IPsec for security of MIP6 >>> signaling is a detriment to the protocol implementation and >>> deployment. Hence the current security architecture needs to be >>> reconsidered. >>> >>> The experience gained over the last few years indicates that IPsec >>> cannot necessarily be used as a generic solution for security. >> >>IPsec cannot be used to protect all protocols. Hence the specification >>of SEND for instance. But I think MIPv6 is among the few protocols which >>have made effort to build their security on IPsec/IKE without relying >>only on a simple sentence somewhere in the document stating "for >>security needs, IPsec should be use". I would agree that more work is >>needed on some aspects (interfaces) even if the WG is more interested by >>pushing additional features. >> >>If the security work on IPsec/IKE integration with MIPv6 had been >>completed before the extension of the protocol (DSMIPv6, ...), this >>may have prevented such issues. >> >>I agree that some of the features described in companion documents of >>MIPv6 have been described at a too high level and cannot be implemented >>easily. > > Thank you. I think you will realize the complexities of the > implementation when you go through an exercise of doing so. I won't. I just don't support DSMIPv6. Reread my email address more carefully ;-) >>> Authors would also like to recognize Satyabrata Sahu, NK Garg, >>> Sandeep Minocha and Harsh Verma for working on the implementation. >> >>What about discussing the specific technical details of the problems >>they found during the implementation on the list and try and address >>them one by one. Can I also ask what they implemented precisely and for >>which specific platform? I would understand if that cannot be discussed >>publicly, obviously. > > We can discuss this offline. But I can say that the implementation of > DSMIP6 was done on a RHEL version of Linux. let's do that part offline. Cheers, a+ From jouni.nospam@gmail.com Mon Jul 27 12:46:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0143A6CAD for ; Mon, 27 Jul 2009 12:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 GWSOa2oL1bPU for ; Mon, 27 Jul 2009 12:46:31 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 63A9E3A6D1F for ; Mon, 27 Jul 2009 12:46:31 -0700 (PDT) Received: by ewy26 with SMTP id 26so3451637ewy.37 for ; Mon, 27 Jul 2009 12:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=+2AUXZbVwuGEE1RLya1MAbxwd3En8wxKAppwS9AJuZ0=; b=U68hSvxCfJ4Jg+vjjMbONlZofzqKRHZKTVuOf6Nf206OHNLO032u2JpQ+O6vZ/E2tc 5oy89MykutjoRA7fOJsyFWI4yTDoAuDRR6QHjouTWMEqO0bwEcnTPpg+sLRvjxv2dVUm utLiIB6goPUhOhT5/dp1d7t5nQJt/r6M6GXlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=QwvzCYPtXiVeXy6QEn1I1i8hxeV+jS37agzcACTpVLm9bjsr8MbXfTwTJB1LW2OOY4 0v5OjXAXfVrVioWl8UQtoiZq1MWFeX3KjYSIexEEhoCwLuLOHtXHkGfzoCclJsBYb5+4 lhrgZSaK4ZCngn9zOZk1svgX/q9qrJeUAND0I= Received: by 10.210.63.18 with SMTP id l18mr8747268eba.67.1248723988178; Mon, 27 Jul 2009 12:46:28 -0700 (PDT) Received: from ?10.102.80.55? ([77.241.100.67]) by mx.google.com with ESMTPS id 10sm475616eyd.46.2009.07.27.12.46.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 12:46:27 -0700 (PDT) Message-Id: From: jouni korhonen To: Arnaud Ebalard In-Reply-To: <87tz0xkjps.fsf@small.ssi.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 22:46:25 +0300 References: <87tz0xkjps.fsf@small.ssi.corp> X-Mailer: Apple Mail (2.935.3) Cc: mext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 19:46:32 -0000 Hi Arnaud, Commenting one point here at this time. On Jul 27, 2009, at 10:29 PM, Arnaud Ebalard wrote: [snip] > > o You use the IPsec stack to protect traffic using ESP. You use SA for > that purpose. There is nothing in the document about associated > Security Policies (SP). Are the ones defined in 3776 reused? > Can you clarify that point? This is a common misunderstanding due to using term 'ESP' in the I-D. There is no reference nor intent to use IPsec as per RFC4301. The I-D only *reuses* the ESP format for encapsulation as what we came up ourselves looked more or less ESP format. We will (most probably) remove all references to 'ESP' in the future to avoid this mixup. Cheers, Jouni From arno@natisbad.org Mon Jul 27 13:32:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436833A6D2B for ; Mon, 27 Jul 2009 13:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 dHw6L2uXC5EW for ; Mon, 27 Jul 2009 13:32:31 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 2E98A3A6C7B for ; Mon, 27 Jul 2009 13:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=xk6lk2RRfXf 1+AW9DBflVZx60reCLnZRyi5WjG3gplI=; b=jJPRAaLOIfQlBEGhNiwxCVdH9rA +I/BnjwnIMkvxBHFXNSyj0zX8hbRYq6LSpaMqHrBdtr1SHCjdcoX4Vk4t58fepZj aACo+Km4BXiVzSxdmAN7IKyNG8aGEhG7fBzJG/ZQEaHrjGwYS54FUfMpYDvxXN0R J9NuHTTs+ENsaL9E= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MVWs0-00022J-Sb; Mon, 27 Jul 2009 22:32:29 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: jouni korhonen References: <87tz0xkjps.fsf@small.ssi.corp> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090727:mext@ietf.org::hJEEoijxP3EHuDMy:000013ob X-Hashcash: 1:20:090727:jouni.nospam@gmail.com::EgZ3OsyTCr5bnxCn:00000000000000000000000000000000000000021Ki X-Hashcash: 1:20:090727:basavaraj.patil@nokia.com::5Q6IJJjp7sMwVCsC:0000000000000000000000000000000000003aIh Date: Mon, 27 Jul 2009 22:33:03 +0200 In-Reply-To: (jouni korhonen's message of "Mon, 27 Jul 2009 22:46:25 +0300") Message-ID: <87r5w1j280.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 20:32:32 -0000 Hi, jouni korhonen writes: > Hi Arnaud, > > Commenting one point here at this time. > > On Jul 27, 2009, at 10:29 PM, Arnaud Ebalard wrote: > > [snip] > >> >> o You use the IPsec stack to protect traffic using ESP. You use SA for >> that purpose. There is nothing in the document about associated >> Security Policies (SP). Are the ones defined in 3776 reused? >> Can you clarify that point? > > This is a common misunderstanding due to using term 'ESP' in the > I-D. There is no reference nor intent to use IPsec as per RFC4301. The > I-D only *reuses* the ESP format for encapsulation as what we came up > ourselves looked more or less ESP format. We will (most probably) > remove all references to 'ESP' in the future to avoid this mixup. Just to be sure: you mean you will not use the algorithms implemented in the IPsec kernel stack but reimplement everything in userland? Cheers, a+ From jouni.nospam@gmail.com Mon Jul 27 14:26:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374553A6C12 for ; Mon, 27 Jul 2009 14:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 wkMMvjIbJsI0 for ; Mon, 27 Jul 2009 14:26:51 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id C36813A685C for ; Mon, 27 Jul 2009 14:26:50 -0700 (PDT) Received: by ewy26 with SMTP id 26so3525963ewy.37 for ; Mon, 27 Jul 2009 14:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=ec65RsGnQOEmAjJCw3kjAIlSTDa71uyLI+gkXcsiofA=; b=gXBfmKOmUZKqy/eC78F1Be8jiqq3oM/luZoK6sNohIz3aZcXNGdI/ocxdR6C+idgCB FT+Jkt3AG8V+Nn0UNsOZtpKzH7FBuOByhG22KU2x8v0TLw3JUywRCjBAHt17Nvh1exjX RZ0fv/SGwX/d91g1fqkz9NgKEY+0Ds9JbqUpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=MXoEO8QLnNWHQ+XzWnhNnjeLO+kQTGss5NPLRGn1DdgLeMuuZEb+JNf36Xwbz6eIzB XFpSTCG0uroGAqoi0P/Rr367QqmV0jdaXlDrASvG6LHfA+ttbrqqfy/gwr640IX5Euo0 mkXEnPPcRs8Ev6BJh3BqBaZT3oY+ATBOao6Yg= Received: by 10.210.28.4 with SMTP id b4mr8995415ebb.47.1248729972218; Mon, 27 Jul 2009 14:26:12 -0700 (PDT) Received: from ?10.102.80.55? ([77.241.100.67]) by mx.google.com with ESMTPS id 24sm614388eyx.43.2009.07.27.14.26.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 14:26:11 -0700 (PDT) Message-Id: <9F72E813-4169-44E4-BA07-D70DC1C7070C@gmail.com> From: jouni korhonen To: Arnaud Ebalard In-Reply-To: <87tz0xkjps.fsf@small.ssi.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 00:26:06 +0300 References: <87tz0xkjps.fsf@small.ssi.corp> X-Mailer: Apple Mail (2.935.3) Cc: mext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 21:26:52 -0000 Hi Arnaud, Some more comments inline: On Jul 27, 2009, at 10:29 PM, Arnaud Ebalard wrote: [snip] >> >> Take a look at the TLS based security architecture framework solution >> proposed in I-D: draft-korhonen-mext-mip6-altsec-01.txt > > I read the draft. If I had to summarize the protocol the protocol I > would say the HAC provides the same function as a KDC in Kerberos > domains, granting HTTP tickets using TLS. Then, is looks > like a kerberos-based relying on TLS (or even DTLS) for MIPv6 is > IMHO a bad design idea. I Looks bad why? Please, list the points that lead to this conclusion. I would help us greatly. > did not resist to take a *quick* look: > > o there is an additional box in the picture, the HAC [snip] > > o The treatment of MN-CN route optimization is outside the scope of > the document. > > o In 5.4.2, "The MN or the HA MAY switch between the encryption and > plain text at any time based on local policies": what if an attacker > knows the SPI and the sequence number. Can she start sending > plaintext packets to one or another endpoint just by changing the > ptype? Anyone who gets on the link between the MN and the HA, could inject false packets if payload protection is not used. This would be true for plain MIP6 as well when IPsec is not used. If user payload protection (as per I-D) is used, then the change of PType will be noticed and those forged packets get dropped. [snip] > > At some point, considering you drop RO, I wonder why not going for one > of the following solutions instead of keeping MIPv6 in the picture: No one so far (from the MIP6 point of view) I have worked with has seriously requested it. Anyway, with the solution the I-D proposes, if the CN also implements the HAC functionality, the MN could bootstrap a security context with the CN and talk directly to the CN. RO can be brought in, but I am not sure if it is worth the effort in this particular I-D. [snip] > > >> We believe that it does not require changes to the security engine on >> the host. It is a solution which uses the APIs and libraries of TLS >> on >> the host without having to modify them. >> The problem with IPsec/IKEv2 and MIP6 is that we end up having to >> modify the security subsystem to make it work and this is not a >> feasible option in all instances. > > One of the problem you have with MIPv6 are the required interactions > with IPsec/IKE, for instance in order to update the SA endpoints. In > draft-korhonen-mext-mip6-altsec-01.txt, you skip this point and do not > explain how the interactions with the IPsec stack are done. Can you > clarify? There is no interaction with IPsec stack. [snip] >> >> The number of messages exchanged to setup the IPsec SA is an >> issue. Especially when you compare it with the registration process >> required for MIP4. So if you compare the number of steps for >> registration of an MN for MIP6 vs MIP4, you would see the difference. > > Can you compare the amount of traffic exchanged between a MN and a HA > using IKEv2 to setup the SA with the traffic exchanged in an alternate > solution, say draft-korhonen-mext-mip6-altsec-01.txt? You mean the IKEv2 generated traffic between MN and HA versus TLS- based generated traffic between the MN and the HAC? We could provide such. [snip] >> >> I think we can do simpler security solution than IPsec/IKEv2 which >> would simplify the implementation vastly while preserving the >> security >> aspects of the MN-HA communications. > > At the moment, draft-korhonen-mext-mip6-altsec-01 relies on TLS, > IPsec, > HTTP, BNF, RFC3948, ... and an additional box. TLS and HTTP. BNF processing is part of HTTP parsing anyway. From Section 5.4. "Actually, when data protection is used, the construction of the packet on the wire is the same as an UDP encapsulated ESP packet in a tunnel mode as defined in [RFC3948]." This does not mandate anything. It is an example. Will be removed to avoid the confusion. [snap] Cheers, Jouni From jouni.nospam@gmail.com Mon Jul 27 14:32:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2F93A6D64 for ; Mon, 27 Jul 2009 14:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 UCQwit+2Nv71 for ; Mon, 27 Jul 2009 14:32:34 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 588143A6B29 for ; Mon, 27 Jul 2009 14:32:34 -0700 (PDT) Received: by ewy26 with SMTP id 26so3530401ewy.37 for ; Mon, 27 Jul 2009 14:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=ARzLNCx9vpK+1/a1kbcCpyqAoznFyj7sG5JgtLkAkwI=; b=wF4TokMTKdlq/PscLCdEMcQpJlHd30UlEZcLewVxHgq72E+X9zt5gQ0jchHQ4vM3y7 2MHwaA2VECQYzNR9sUw3nitPp1xHghK7lZ9G1UjdwS2wCjkmqDm9YSnh72YWtH/6FKpU FJ1SxbaiTd3SwmkfNC1BX7s/nkVJcUvMlNAd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Pfto78a5ZB7ht7jVSlt07GAffs4kmFIH/8/FDYJECdIeoWOnZ7osaoq+6Wnagt7rku qXofDPkGgwV7zs7wIu6sKzVETEz07d25uasxUG00kkZ+QI6yj7gRHUKYnhKxyaAvGpEH UvA+tBCrUAJA7fJ0uaL20bLnrrM/RKz+pN/S4= Received: by 10.210.86.1 with SMTP id j1mr8921892ebb.27.1248730352962; Mon, 27 Jul 2009 14:32:32 -0700 (PDT) Received: from ?10.102.80.55? ([77.241.100.67]) by mx.google.com with ESMTPS id 24sm761184eyx.33.2009.07.27.14.32.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 14:32:32 -0700 (PDT) Message-Id: From: jouni korhonen To: Arnaud Ebalard In-Reply-To: <87r5w1j280.fsf@small.ssi.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 00:32:27 +0300 References: <87tz0xkjps.fsf@small.ssi.corp> <87r5w1j280.fsf@small.ssi.corp> X-Mailer: Apple Mail (2.935.3) Cc: mext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 21:32:35 -0000 Hi Arnaud, On Jul 27, 2009, at 11:33 PM, Arnaud Ebalard wrote: > Hi, > > jouni korhonen writes: > >> Hi Arnaud, >> >> Commenting one point here at this time. >> >> On Jul 27, 2009, at 10:29 PM, Arnaud Ebalard wrote: >> >> [snip] >> >>> >>> o You use the IPsec stack to protect traffic using ESP. You use SA >>> for >>> that purpose. There is nothing in the document about associated >>> Security Policies (SP). Are the ones defined in 3776 reused? >>> Can you clarify that point? >> >> This is a common misunderstanding due to using term 'ESP' in the >> I-D. There is no reference nor intent to use IPsec as per RFC4301. >> The >> I-D only *reuses* the ESP format for encapsulation as what we came >> up >> ourselves looked more or less ESP format. We will (most probably) >> remove all references to 'ESP' in the future to avoid this mixup. > > Just to be sure: you mean you will not use the algorithms > implemented in > the IPsec kernel stack but reimplement everything in userland? No IPsec kernel stack involved. I am not sure what algorithms you are referring here. Cheers, Jouni > > Cheers, > > a+ From arno@natisbad.org Tue Jul 28 01:01:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594B63A6D27 for ; Tue, 28 Jul 2009 01:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 a+3HjJcTxIQi for ; Tue, 28 Jul 2009 01:01:36 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 98D003A691A for ; Tue, 28 Jul 2009 01:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: Message-ID:MIME-Version:Content-Type; bh=i7HFzXh/Nym/DFvHq+ZxdPZ 3UcMgbSrdJ2JrMn5/G+E=; b=XEvLv8SsqT3mS0nUk1QWdVu+RpVo0PeMz74p+7G qKa6HsI8i/MCpBNweZDlaCMXLWSnPhdUIqamM7Y/H0OiCRr+ymeIIo9PT+uDJRsD hiBy/S3R96YARwLXiC/n2WzIE1OfVcDjzj7RZteJV7wvrhgJIbcEpdX2rcvNLMeT jvHE= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MVhcp-0000xL-Br; Tue, 28 Jul 2009 10:01:31 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: jouni korhonen References: <87tz0xkjps.fsf@small.ssi.corp> <9F72E813-4169-44E4-BA07-D70DC1C7070C@gmail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090728:basavaraj.patil@nokia.com::UQZGwFcxtXBEEZqq:0000000000000000000000000000000000000YxC X-Hashcash: 1:20:090728:jouni.nospam@gmail.com::VqdB+McMLBS3GePS:0000000000000000000000000000000000000001HSt X-Hashcash: 1:20:090728:mext@ietf.org::pP7PqDy/+HvxV3iB:0000Rn5A Date: Tue, 28 Jul 2009 10:02:08 +0200 Message-ID: <871vo18ccf.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:01:37 -0000 Hi Jouni, jouni korhonen writes: > [snip] relying on TLS (or even DTLS) for MIPv6 is IMHO a bad design > idea. > > Looks bad why? Please, list the points that lead to this conclusion. I > would help us greatly. - Because TLS has been designed to secure transport streams .. - ... not as a key exchange mechanism for L3 - Because you map TLS ciphersuites to some enc and hash algs to be used with IPsec. - Because, pratically, you create yet another variation of what EAP-TLS does, but using HTTP and without reusing the guaranteed key material generated by TLS. Again, can you argue why you don't directly use DTLS instead of some TLS+ESP headers variations? >> o In 5.4.2, "The MN or the HA MAY switch between the encryption and >> plain text at any time based on local policies": what if an attacker >> knows the SPI and the sequence number. Can she start sending >> plaintext packets to one or another endpoint just by changing the >> ptype? > > Anyone who gets on the link between the MN and the HA, could inject > false packets if payload protection is not used. This would be true > for plain MIP6 as well when IPsec is not used. Sure. But my concern is about the reverse scenario. Protection of data is used. > If user payload protection (as per I-D) is used, then the change of > PType will be noticed and those forged packets get dropped. How? As pointed previously, there is nothing about the equivalent of Security Policies discussed in the draft and you have that sentence: "The MN or the HA MAY switch between the encryption and plain text at any time based on local policies". IMHO, this is unclear to say the least. >> At some point, considering you drop RO, I wonder why not going for one >> of the following solutions instead of keeping MIPv6 in the picture: > > No one so far (from the MIP6 point of view) I have worked with has > seriously requested it. Anyway, with the solution the I-D proposes, if > the CN also implements the HAC functionality, the MN could bootstrap a > security context with the CN and talk directly to the CN. > > RO can be brought in, but I am not sure if it is worth the effort in > this particular I-D. Maybe it is just me but without RO, mobility can be provided to clients by a common VPN software. >>> We believe that it does not require changes to the security engine on >>> the host. It is a solution which uses the APIs and libraries of TLS >>> on >>> the host without having to modify them. >>> The problem with IPsec/IKEv2 and MIP6 is that we end up having to >>> modify the security subsystem to make it work and this is not a >>> feasible option in all instances. >> >> One of the problem you have with MIPv6 are the required interactions >> with IPsec/IKE, for instance in order to update the SA endpoints. In >> draft-korhonen-mext-mip6-altsec-01.txt, you skip this point and do not >> explain how the interactions with the IPsec stack are done. Can you >> clarify? > > There is no interaction with IPsec stack. So you reuse ESP format but have no interaction with the IPsec stack. Am I correct on the following: you reimplement in userland all the ESP related parsing which is available in the kernel stack. >>> The number of messages exchanged to setup the IPsec SA is an >>> issue. Especially when you compare it with the registration process >>> required for MIP4. So if you compare the number of steps for >>> registration of an MN for MIP6 vs MIP4, you would see the difference. >> >> Can you compare the amount of traffic exchanged between a MN and a HA >> using IKEv2 to setup the SA with the traffic exchanged in an alternate >> solution, say draft-korhonen-mext-mip6-altsec-01.txt? > > You mean the IKEv2 generated traffic between MN and HA versus TLS- > based generated traffic between the MN and the HAC? We could provide > such. Yes. Thanks. >>> I think we can do simpler security solution than IPsec/IKEv2 which >>> would simplify the implementation vastly while preserving the >>> security >>> aspects of the MN-HA communications. >> >> At the moment, draft-korhonen-mext-mip6-altsec-01 relies on TLS, >> IPsec, >> HTTP, BNF, RFC3948, ... and an additional box. > > TLS and HTTP. BNF processing is part of HTTP parsing anyway. > > From Section 5.4. > "Actually, when data protection is used, the construction of the > packet on the wire is the same as an UDP encapsulated ESP packet in a > tunnel mode as defined in [RFC3948]." > > This does not mandate anything. It is an example. Will be removed to > avoid the confusion. Ack. But I think you should clarify what (from the IPsec stack) needs to be reimplemented in userland (ESP parsing, SADB?, SPD?, ...). BTW, I think my question on how movement is handled (what needs to be done on HA and MN) was worth asking. It was skipped in your reply. Cheers, a+ From dirk.kroeselberg@nsn.com Tue Jul 28 01:24:03 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92293A6D3B for ; Tue, 28 Jul 2009 01:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 c4-N7jIHVy7S for ; Tue, 28 Jul 2009 01:24:03 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E48283A6D15 for ; Tue, 28 Jul 2009 01:23:58 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6S8NvBr004415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2009 10:23:57 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6S8Nsfi017312; Tue, 28 Jul 2009 10:23:57 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 10:23:55 +0200 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, 28 Jul 2009 10:23:54 +0200 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67019CB73E@DEMUEXC030.nsn-intra.net> In-Reply-To: <871vo18ccf.fsf@small.ssi.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 Thread-Index: AcoPWakkjw6Qg8l+RsSZnai5O47hhQAAaorg References: <87tz0xkjps.fsf@small.ssi.corp><9F72E813-4169-44E4-BA07-D70DC1C7070C@gmail.com> <871vo18ccf.fsf@small.ssi.corp> From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "Arnaud Ebalard" , "jouni korhonen" X-OriginalArrivalTime: 28 Jul 2009 08:23:55.0995 (UTC) FILETIME=[BFA1F2B0:01CA0F5C] Cc: Basavaraj.Patil@nokia.com, mext@ietf.org Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:24:03 -0000 Arnaud,=20 > > [snip] relying on TLS (or even DTLS) for MIPv6 is IMHO a bad design > > idea. > > > > Looks bad why? Please, list the points that lead to this=20 > conclusion. I > > would help us greatly. >=20 > - Because TLS has been designed to secure transport streams .. > - ... not as a key exchange mechanism for L3 Would there be any technical problem with this? With EAP-TLS that you are mentioning below, TLS does the same thing for L2. =20 Thanks, Dirk From Basavaraj.Patil@nokia.com Tue Jul 28 01:32:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9783A6DA8 for ; Tue, 28 Jul 2009 01:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, 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 HzoFQF168EVV for ; Tue, 28 Jul 2009 01:32:15 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 538423A6DA3 for ; Tue, 28 Jul 2009 01:32:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6S8VBal027248; Tue, 28 Jul 2009 03:32:01 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:31:43 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:31:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:31:38 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 28 Jul 2009 10:31:37 +0200 From: To: Date: Tue, 28 Jul 2009 10:31:37 +0200 Thread-Topic: Review of draft draft-patil-mext-mip6issueswithipsec-01 Thread-Index: AcoO8ItbnFUOJ9NlQ9+j3cuH4QrLjgAbJKt0 Message-ID: References: , <87tz0xkjps.fsf@small.ssi.corp> In-Reply-To: <87tz0xkjps.fsf@small.ssi.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jul 2009 08:31:38.0358 (UTC) FILETIME=[D338F160:01CA0F5D] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:32:16 -0000 Hi Arnaud, I will respond to your other comments as soon as I get some time.. But just one thing: ________________________________________ From: ext Arnaud Ebalard [arno@natisbad.org] Sent: Monday, July 27, 2009 2:29 PM To: Patil Basavaraj (Nokia-D/Dallas) Cc: mext@ietf.org Subject: Re: Review of draft draft-patil-mext-mip6issueswithipsec-01 >> >>No. IPsec stack and IKE daemon may already have support for MOBIKE which >>does exactly what we need. The only difference is that the signaling >>goes through the IKE channel. With MIPv6, signaling is MIPv6 one >>(BU/BA). In all cases, extending the IPsec stack to support MIPv6 is >>light. Same for IKE. > > I think this where I would disagree. At least from our experience of > doing a DSMIP6 implementation, the challenges are primarily in the > interactions between the mobility module and the IPsec/IKEv2 > modules. YMMV. I won't argue for DSMIPv6. Raj> MIP6 by itself is useless today. Maybe 10 years from now when we hopef= ully have some deployment of IPv6 networks and is available natively on lin= ks, it would be an option. The only practical solution at this time is DSMIP6 because it deals with th= e reality of the fact that MNs will be mostly attached via IPv4 and NATed n= etworks. > Thank you. I think you will realize the complexities of the > implementation when you go through an exercise of doing so. I won't. I just don't support DSMIPv6. Reread my email address more carefully ;-) Raj> Right... I noticed that already. I dont understand your reasons for no= t supporting DSMIP6. Is it only because of the fact that DSMIP6 has to deal with NATs ;) ? As I said for all practical purposes, implementing only MIP6 by itself is p= urely an academic exercise. -Raj= From arno@natisbad.org Tue Jul 28 01:54:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61AF73A6DA6 for ; Tue, 28 Jul 2009 01:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 HOrFf+YoxJCS for ; Tue, 28 Jul 2009 01:54:34 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 21D2B3A6D37 for ; Tue, 28 Jul 2009 01:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=5CfIIunJOWv Uuz5g1utGiM+f5MHEua6CQV0v0ZTs8jo=; b=iayON5TIcD4QwwnKmd4/A0iIrly SAtZzlWaSZyQXqzAcHdOKezXN1zfVdefnF3trbgYBkVnmKNxzDv4Ej1TkusldAiM H9O97k0+walAzEbelcsflQ59tgxRZPXKDjIfWuLsdPYeUeiwbLiMB8xtOx93Fbbv NrKG+P1pQghKz1fI= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MViS7-0001zl-6g; Tue, 28 Jul 2009 10:54:31 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Kroeselberg\, Dirk \(NSN - DE\/Munich\)" References: <87tz0xkjps.fsf@small.ssi.corp> <9F72E813-4169-44E4-BA07-D70DC1C7070C@gmail.com> <871vo18ccf.fsf@small.ssi.corp> <8C51C7A529FC9D49843ACF5AE2FFBF67019CB73E@DEMUEXC030.nsn-intra.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090728:mext@ietf.org::htPgRtwUWfw153sZ:00000P/j X-Hashcash: 1:20:090728:basavaraj.patil@nokia.com::9HGQ9x5uGZEr/mTI:0000000000000000000000000000000000000Qvg X-Hashcash: 1:20:090728:dirk.kroeselberg@nsn.com::bRVwxhVumdASTnUk:00000000000000000000000000000000000001/P7 X-Hashcash: 1:20:090728:jouni.nospam@gmail.com::q1QRKm1thsPj0D5J:0000000000000000000000000000000000000002NbN Date: Tue, 28 Jul 2009 10:55:07 +0200 In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF67019CB73E@DEMUEXC030.nsn-intra.net> (Dirk Kroeselberg's message of "Tue, 28 Jul 2009 10:23:54 +0200") Message-ID: <87ocr56vbo.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: jouni korhonen , Basavaraj.Patil@nokia.com, mext@ietf.org Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:54:35 -0000 Hi, "Kroeselberg, Dirk (NSN - DE/Munich)" writes: >> > [snip] relying on TLS (or even DTLS) for MIPv6 is IMHO a bad design >> > idea. >> > >> > Looks bad why? Please, list the points that lead to this >> conclusion. I >> > would help us greatly. >> >> - Because TLS has been designed to secure transport streams .. >> - ... not as a key exchange mechanism for L3 > > Would there be any technical problem with this? I should have written key provisioning. Anyway, I don't think there is any *technical* problem with this apart from changing the initial purpose of the protocol. The comment was meant to be generic, i.e. against trying to do X at layer Y with a protocol that has been done to do Z at layer W. > With EAP-TLS that you are mentioning below, TLS does the same thing > for L2. Yes, that's the reason I wonder why the draft doesn't use the same scheme instead of creating a new one, i.e. it doesn't reuse the *derived* key material instead of having the HAC push it over https. There may be reasons but they are not discussed. Cheers, a+ From dirk.kroeselberg@nsn.com Tue Jul 28 02:13:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F9C3A6B26 for ; Tue, 28 Jul 2009 02:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rckPZ6j44nkT for ; Tue, 28 Jul 2009 02:13:06 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4624A3A6D91 for ; Tue, 28 Jul 2009 02:13:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6S9D6eU003800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2009 11:13:06 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6S9D4IE025113; Tue, 28 Jul 2009 11:13:05 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:13:04 +0200 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, 28 Jul 2009 11:13:03 +0200 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67019F6414@DEMUEXC030.nsn-intra.net> In-Reply-To: <87ocr56vbo.fsf@small.ssi.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 Thread-Index: AcoPYQlZ6jWkQaSdTr2J8nkZ1/iKgwAALVAA References: <87tz0xkjps.fsf@small.ssi.corp><9F72E813-4169-44E4-BA07-D70DC1C7070C@gmail.com><871vo18ccf.fsf@small.ssi.corp><8C51C7A529FC9D49843ACF5AE2FFBF67019CB73E@DEMUEXC030.nsn-intra.net> <87ocr56vbo.fsf@small.ssi.corp> From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "Arnaud Ebalard" X-OriginalArrivalTime: 28 Jul 2009 09:13:04.0274 (UTC) FILETIME=[9CF19F20:01CA0F63] Cc: jouni korhonen , Basavaraj.Patil@nokia.com, mext@ietf.org Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:13:07 -0000 Hi Arnaud, =20 > -----Original Message----- > From: Arnaud Ebalard [mailto:arno@natisbad.org]=20 > Sent: Tuesday, July 28, 2009 10:55 AM > To: Kroeselberg, Dirk (NSN - DE/Munich) > Cc: jouni korhonen; mext@ietf.org; Basavaraj.Patil@nokia.com > Subject: Re: AW: [MEXT] Review of draft=20 > draft-patil-mext-mip6issueswithipsec-01 >=20 > Hi, >=20 > "Kroeselberg, Dirk (NSN - DE/Munich)"=20 > writes: >=20 > >> > [snip] relying on TLS (or even DTLS) for MIPv6 is IMHO a=20 > bad design > >> > idea. > >> > > >> > Looks bad why? Please, list the points that lead to this=20 > >> conclusion. I > >> > would help us greatly. > >>=20 > >> - Because TLS has been designed to secure transport streams .. > >> - ... not as a key exchange mechanism for L3 > > > > Would there be any technical problem with this? >=20 > I should have written key provisioning. Anyway, I don't think there is > any *technical* problem with this apart from changing the initial > purpose of the protocol. The comment was meant to be generic, > i.e. against trying to do X at layer Y with a protocol that has been > done to do Z at layer W. I agree with the general comment. But it is always a problem to do such thing.=20 You can also see it as just establishing a TLS-secured tunnel and some other http based 'key provisioning' scheme can be run through this tunnel (I think this is the idea of the current draft). The advantage of this is that other http-based exchanges than the default one can easily be plugged in. TLS just secures the transport. Of course this requires to look at stuff like man-in-the-middle attacks. =20 >=20 > > With EAP-TLS that you are mentioning below, TLS does the same thing > > for L2. =20 >=20 > Yes, that's the reason I wonder why the draft doesn't use the same > scheme instead of creating a new one, i.e. it doesn't reuse the > *derived* key material instead of having the HAC push it over https. > There may be reasons but they are not discussed. See above. >=20 > Cheers, >=20 > a+ >=20 From jouni.nospam@gmail.com Tue Jul 28 02:16:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874F03A6CED for ; Tue, 28 Jul 2009 02:16:24 -0700 (PDT) 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=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 zsJid7MGPDXh for ; Tue, 28 Jul 2009 02:16:23 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id E04C73A6E5B for ; Tue, 28 Jul 2009 02:16:22 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so923876eye.31 for ; Tue, 28 Jul 2009 02:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=dw+PMcr+RnzhfehdLoIV55p0jxV8hsroXuBhpZFr5oE=; b=VIvSTvI1juT95oMWhi4CO7yH25MLdEcOkxd0S1R4IDnX5Fw+BGZ4KzufpwEJbYG+Ff 3hHzhs2ZANmWMw5Jcp1GIftHtaXv/ESOCOyuoESMZSEZ04+fi1m4XbZonX0rL7tu3VG8 +bLCtz06A7iUzipG9m8GNSuAgR+pNg+jbElyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=AkYYQPDQpqrs903YFmS1rPWQhfJmSwYWcM9SPCfX4Qr8E1p30GFp3vgkaIwfq8aq67 x2zO8kd4L3Hua709FZKueYNPK3iv9Q2Rl64yDD/36XXxePdLagBycmLOM9wm4kBLkNj2 fyZx8FzBcUddPLdxElw/c0SVEUtnRILYKa5MY= Received: by 10.210.57.3 with SMTP id f3mr6352788eba.94.1248772577125; Tue, 28 Jul 2009 02:16:17 -0700 (PDT) Received: from retrace-ap15.americas.nokia.com ([130.129.7.129]) by mx.google.com with ESMTPS id 5sm1543738eyf.44.2009.07.28.02.16.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Jul 2009 02:16:16 -0700 (PDT) Message-Id: From: jouni korhonen To: Arnaud Ebalard In-Reply-To: <871vo18ccf.fsf@small.ssi.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 12:16:14 +0300 References: <87tz0xkjps.fsf@small.ssi.corp> <9F72E813-4169-44E4-BA07-D70DC1C7070C@gmail.com> <871vo18ccf.fsf@small.ssi.corp> X-Mailer: Apple Mail (2.935.3) Cc: mext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:16:24 -0000 Hi Arnaud, Thanks for another round of questions & comments. See my answers inline. On Jul 28, 2009, at 11:02 AM, Arnaud Ebalard wrote: > Hi Jouni, > > jouni korhonen writes: > >> [snip] relying on TLS (or even DTLS) for MIPv6 is IMHO a bad design >> idea. >> >> Looks bad why? Please, list the points that lead to this >> conclusion. I >> would help us greatly. > > - Because TLS has been designed to secure transport streams .. Ok. > - ... not as a key exchange mechanism for L3 Do you have a better candidate if IKE is out of question? > - Because you map TLS ciphersuites to some enc and hash algs to be > used with IPsec. Hmm.. Didn't we agree already that there is no IPsec per se? > - Because, pratically, you create yet another variation of what EAP- > TLS > does, but using HTTP and without reusing the guaranteed key material > generated by TLS. OK. I don't understand what do you mean by "without reusing the guaranteed key material generated by TLS"? > > Again, can you argue why you don't directly use DTLS instead of some > TLS+ESP headers variations? I don't have a good answer to this. Basically, we do not want to run the TLS handshake between the MN and the HA. That would have undesired implications during the handover. > >>> o In 5.4.2, "The MN or the HA MAY switch between the encryption and >>> plain text at any time based on local policies": what if an >>> attacker >>> knows the SPI and the sequence number. Can she start sending >>> plaintext packets to one or another endpoint just by changing the >>> ptype? >> >> Anyone who gets on the link between the MN and the HA, could inject >> false packets if payload protection is not used. This would be true >> for plain MIP6 as well when IPsec is not used. > > Sure. But my concern is about the reverse scenario. Protection of data > is used. If protection of reverse tunneled traffic is used, then any modification of UDP encapsulated payload will be detected. Of course this requires that integrity check is done. > >> If user payload protection (as per I-D) is used, then the change of >> PType will be noticed and those forged packets get dropped. > > How? As pointed previously, there is nothing about the equivalent of > Security Policies discussed in the draft and you have that sentence: > "The MN or the HA MAY switch between the encryption and plain text at > any time based on local policies". IMHO, this is unclear to say the > least. You do integrity verification? The integrity check also covers the PType. That is "described" (cough) in section 5.5. I admit that the I- D need much more details and clarifications in the next revisions regarding these details, but going for +100 pages in the first revisions was not that appealing ;) Point taken though. > >>> At some point, considering you drop RO, I wonder why not going for >>> one >>> of the following solutions instead of keeping MIPv6 in the picture: >> >> No one so far (from the MIP6 point of view) I have worked with has >> seriously requested it. Anyway, with the solution the I-D proposes, >> if >> the CN also implements the HAC functionality, the MN could >> bootstrap a >> security context with the CN and talk directly to the CN. >> >> RO can be brought in, but I am not sure if it is worth the effort in >> this particular I-D. > > Maybe it is just me but without RO, mobility can be provided to > clients > by a common VPN software. Well, that is true. However, MOBIKE has not been out that long yet (it is getting deployed now though). Again, the experience with interfacing with folks deploying mobility & VPN services is that they don't like the idea of protecting everything due for whatever reason. That usually kills the argument of using mobile VPNs for consumers. > >>>> We believe that it does not require changes to the security >>>> engine on >>>> the host. It is a solution which uses the APIs and libraries of TLS >>>> on >>>> the host without having to modify them. >>>> The problem with IPsec/IKEv2 and MIP6 is that we end up having to >>>> modify the security subsystem to make it work and this is not a >>>> feasible option in all instances. >>> >>> One of the problem you have with MIPv6 are the required interactions >>> with IPsec/IKE, for instance in order to update the SA endpoints. In >>> draft-korhonen-mext-mip6-altsec-01.txt, you skip this point and do >>> not >>> explain how the interactions with the IPsec stack are done. Can you >>> clarify? >> >> There is no interaction with IPsec stack. > > So you reuse ESP format but have no interaction with the IPsec > stack. Am > I correct on the following: you reimplement in userland all the ESP > related parsing which is available in the kernel stack. Parsing is no brainer tbh. But yes, you more or less replicate the encapsulation parsing. > >>>> The number of messages exchanged to setup the IPsec SA is an >>>> issue. Especially when you compare it with the registration process >>>> required for MIP4. So if you compare the number of steps for >>>> registration of an MN for MIP6 vs MIP4, you would see the >>>> difference. >>> >>> Can you compare the amount of traffic exchanged between a MN and a >>> HA >>> using IKEv2 to setup the SA with the traffic exchanged in an >>> alternate >>> solution, say draft-korhonen-mext-mip6-altsec-01.txt? >> >> You mean the IKEv2 generated traffic between MN and HA versus TLS- >> based generated traffic between the MN and the HAC? We could provide >> such. > > Yes. Thanks. > >>>> I think we can do simpler security solution than IPsec/IKEv2 which >>>> would simplify the implementation vastly while preserving the >>>> security >>>> aspects of the MN-HA communications. >>> >>> At the moment, draft-korhonen-mext-mip6-altsec-01 relies on TLS, >>> IPsec, >>> HTTP, BNF, RFC3948, ... and an additional box. >> >> TLS and HTTP. BNF processing is part of HTTP parsing anyway. >> >> From Section 5.4. >> "Actually, when data protection is used, the construction of the >> packet on the wire is the same as an UDP encapsulated ESP packet in a >> tunnel mode as defined in [RFC3948]." >> >> This does not mandate anything. It is an example. Will be removed to >> avoid the confusion. > > Ack. But I think you should clarify what (from the IPsec stack) > needs to > be reimplemented in userland (ESP parsing, SADB?, SPD?, ...). Point taken. We'll add more clarification about this. Currently only the parsing of encapsulation is needed. > > BTW, I think my question on how movement is handled (what needs to be > done on HA and MN) was worth asking. It was skipped in your reply. Hm. I seem to have missed it. I'll check that. Cheers, Jouni > > Cheers, > > a+ From arno@natisbad.org Tue Jul 28 02:17:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC503A6E14 for ; Tue, 28 Jul 2009 02:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Wp3DnhyBIcRY for ; Tue, 28 Jul 2009 02:17:08 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 80FDD3A685A for ; Tue, 28 Jul 2009 02:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=Oa2J725XKOT hPlWxfMMR1f6sq4B9wNJVEyPwwgyGcP8=; b=FrJ0BvOcHMo1+U1e798uJnut4nG eUhEOw1xUK90LvtivoaPClVABaYZpW88cuxUiJYAPDnNGff9fFuDyAgZEgCSq7Di VAsqKDqmap6nOpCiraz9RDbztHCN7zmfKPFUIir8RgOG0XPP+wdG5TkR/s2YqNX0 tSNW60Kg9bkQtv7s= Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MVinw-0002Qi-TF; Tue, 28 Jul 2009 11:17:05 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: References: <87tz0xkjps.fsf@small.ssi.corp> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090728:mext@ietf.org::8AP0mu7fFEye7jQP:00002Dhx X-Hashcash: 1:20:090728:basavaraj.patil@nokia.com::xyh4NDnSjN0xVguH:0000000000000000000000000000000000005Pz+ Date: Tue, 28 Jul 2009 11:17:41 +0200 In-Reply-To: (Basavaraj Patil's message of "Tue, 28 Jul 2009 10:31:37 +0200") Message-ID: <87k51t6ua2.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:17:09 -0000 Hi, writes: > I will respond to your other comments as soon as I get some time.. ok. > Raj> MIP6 by itself is useless today. Maybe 10 years from now when we > hopefully have some deployment of IPv6 networks and is available > natively on links, it would be an option. Well, you should come to France ;-) At work, I have IPv6 (Nerim as a provider). At Home, I have IPv6 (Free as a provider, which has more than 5 millions clients who can activate IPv6 at home via a simple clic (/64)). > The only practical solution at this time is DSMIP6 because it deals > with the reality of the fact that MNs will be mostly attached via IPv4 > and NATed networks. In order to be more useful than MIPv6 (using Teredo when in IPv4 networks) or a direct use of the available private IPv4 address in a common network, I think one needs a public IPv4 address as HoA. IMHO, this is a non starter in term of deployment. For me, MIPv6 provides address stability and e2e. >> Thank you. I think you will realize the complexities of the >> implementation when you go through an exercise of doing so. > > I won't. I just don't support DSMIPv6. Reread my email address more > carefully ;-) > > Raj> Right... I noticed that already. I dont understand your reasons > for not supporting DSMIP6. - Complexity - No availability of the protocol as an open source implementation - No public IPv4 address to use for a deployment (or expensive) - MIPv6 + Teredo works fine with me > Is it only because of the fact that DSMIP6 has to deal with NATs ;) ? > As I said for all practical purposes, implementing only MIP6 by itself > is purely an academic exercise. It may depend where you live. a+ From root@core3.amsl.com Thu Jul 30 00:45:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4115628C142; Thu, 30 Jul 2009 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090730074501.4115628C142@core3.amsl.com> Date: Thu, 30 Jul 2009 00:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binary-ts-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 07:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Binary Traffic Selectors for FB Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mext-binary-ts-00.txt Pages : 16 Date : 2009-07-29 This document defines binary format for IPv4 and IPv6 traffic selectors to be used in conjuction with flow bindings for Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binary-ts-00.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-mext-binary-ts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-30003414.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Thu Jul 30 01:51:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52C43A7182 for ; Thu, 30 Jul 2009 01:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 XD7iilrrf2R3 for ; Thu, 30 Jul 2009 01:51:00 -0700 (PDT) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by core3.amsl.com (Postfix) with ESMTP id E78393A7180 for ; Thu, 30 Jul 2009 01:50:59 -0700 (PDT) Received: by fxm22 with SMTP id 22so587343fxm.9 for ; Thu, 30 Jul 2009 01:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer; bh=seQ6aaAzTimR72nVzX44EVGLH+qEEhiQSaMm4ve9PA8=; b=GTpZ8SBFBQNwLAZio29qxCN0hTVYfW7rR84a5pM2ynCH2reYzb4HyKCoCOD0GpHI4/ OChehSW3lbHrXGuVbKKXhpBeg4uYRxo7fpOrd9Kgs0ZGG3dhWYPbHqtrnyi5ZIWUhYcb z+AvLdbPYCKGsj1/G8Nfh2v6eQ+qe4H0Nbp50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=IOO/uI40Gl09g4UCVwWQrvhLiTxVFJ8uR7uIFxppqTMmwM2GQrbXZbZQ8SzAGvTjyk 0L91at3y6nu3QoWKvcDDJAeQvXHJm7XqYcoha/kczsy1ihL/Zn+l1wm+GaWupd98lc6Q bhPaONVNDdz3kmuGdXYs4IiAjumQWEAOzKGeY= Received: by 10.103.167.14 with SMTP id u14mr507578muo.81.1248943858160; Thu, 30 Jul 2009 01:50:58 -0700 (PDT) Received: from dhcp-54f6.meeting.ietf.org (dhcp-54f6.meeting.ietf.org [130.129.84.246]) by mx.google.com with ESMTPS id y37sm11686824mug.57.2009.07.30.01.50.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 01:50:57 -0700 (PDT) Message-Id: <06395505-254A-4213-88C8-DAC6A3DDAB44@gmail.com> From: jouni korhonen To: mext Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 11:50:56 +0300 X-Mailer: Apple Mail (2.935.3) Cc: mext chair Subject: [MEXT] About IPv4 Support for DSMIPv6 IPv6 Home Link X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:51:00 -0000 Hi all, In SFO IETF74 there was a presentation of IPv4-HoA support for DSMIPv6 when a MN is on its IPv6 home link. There was also some discussion whether the draft-premec-mext-extended-home-link-02 should be adopted as a WG document or just have it let die. I cannot remember if there were any promises or agreements regarding the document adoption. We did a revision of the document recently and cut a lot of stuff away among other updates. I am just asking what to do with the document and what the WG thinks about it. Cheers, Jouni From jari.arkko@piuha.net Fri Jul 31 12:39:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63DB03A6AE0 for ; Fri, 31 Jul 2009 12:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 kRZWyRqV8IQQ for ; Fri, 31 Jul 2009 12:39:40 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EBA053A6B75 for ; Fri, 31 Jul 2009 12:39:37 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 02ABC19872A; Fri, 31 Jul 2009 22:39:39 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id A2E5E1986E3; Fri, 31 Jul 2009 22:39:38 +0300 (EEST) Message-ID: <4A734879.7050709@piuha.net> Date: Fri, 31 Jul 2009 22:39:37 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ahmad Muhanna References: <4A6B12F2.5060608@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 19:39:41 -0000 Ahmad, >> Section 5 talks about NATs and UDP encapsulation, but only >> with respect to proxy mobility. Client mobility case should >> be handled as well. >> > [Ahmad] > Sure, we will address client MIP6 case. > OK >> The list of fields after Figure 4 might be more readable if >> you included all fields, such as MH Type. >> > > [Ahmad] > No problem. Will do. OK >>> Revocation Indication or Binding Revocation Acknowledgement for >>> different cases, therefore, if IPsec is used to secure signaling >>> between the them, it prevents any possible man in the middle >>> reflection attack. >>> >>> >> Its not clear to me what attacks you are talking about here. >> Reflection attacks normally mean that the attacker sends a >> packet that a third party responds to and sends the response >> to the victim. >> >> Perhaps you meant to say "... prevents the processing of a >> message not constructed by an authorized party"? >> > > [Ahmad] > I was thinking that if a man in the middle was able to capture a packet > which contains a BRI from the MAG, for example, the attacker will not be > able to send the packet back to the MAG as if it is coming from the LMA. > Thinking about this a little more, the consequences is not so critical > since if the MAG has sent a BRI to the LMA, it is already revoking the > MN session anyway. However, I was initially thinking even if the MAG > receives that packet and processes it as if it is coming from the LMA, > it is a problem, but IPsec prevents that since IPsec SA in > unidirectional with different SPIs. That why I mentioned it. If you > think it is not necessary, we can remove it. > Its not so much that this is unnecessary. I'm more concerned that the text focuses on a relatively weird corner case and without explaining it well. And yet there's the more general issue that if you use IPsec to secure the packets, you can be sure that only an authorized party can have sent a particular message. So I would suggest focusing on the general property which covers even your special case. >> You need to specify what the syntax of the wildcard format >> is. Note that '*' is a legal character in the username >> portion of a NAI [RFC4282], so I would recommend considering >> another syntax (such as @example.com). >> > > [Ahmad] > Sure. Will fix it. > Ok. It would be good to see the change here, because unlike the other changes that I requested, this one may not be trivial. Perhaps the chairs can find some RADIUS and NAI capable reviewers to make sure the wildcard format doesn't have any unexpected side effects? >> I would like to change the retranmission procedure to use an >> exponential back-off, in a style similar to RFC 3775, Section >> 11.8. This procedure is both more friendly to other traffic >> in a congestion situation, as well as faster in resending a >> lost first packet. >> > [Ahmad] > No problem, we can adopt an exponential back-off scheme similar to > RFC3775. > We will update the draft and post as soon as possible. > Thanks Jari From AMUHANNA@nortel.com Fri Jul 31 23:30:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD543A6894 for ; Fri, 31 Jul 2009 23:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, 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 CQ9goboSwnVf for ; Fri, 31 Jul 2009 23:30:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A94EE3A6804 for ; Fri, 31 Jul 2009 23:30:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n716TiV23824; Sat, 1 Aug 2009 06:29:45 GMT 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: Sat, 1 Aug 2009 01:29:40 -0500 Message-ID: In-Reply-To: <4A734879.7050709@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-metxt-binding-revocation thread-index: AcoSFqbLPtyXRmP7R/qgcbgNqxrYTAAWT1IQ References: <4A6B12F2.5060608@piuha.net> <4A734879.7050709@piuha.net> From: "Ahmad Muhanna" To: "Jari Arkko" Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 06:30:04 -0000 Thanks Jari, Please see inline. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > > [Ahmad] > > I was thinking that if a man in the middle was able to capture a=20 > > packet which contains a BRI from the MAG, for example, the attacker=20 > > will not be able to send the packet back to the MAG as if=20 > it is coming from the LMA. > > Thinking about this a little more, the consequences is not=20 > so critical=20 > > since if the MAG has sent a BRI to the LMA, it is already=20 > revoking the=20 > > MN session anyway. However, I was initially thinking even=20 > if the MAG=20 > > receives that packet and processes it as if it is coming=20 > from the LMA,=20 > > it is a problem, but IPsec prevents that since IPsec SA in=20 > > unidirectional with different SPIs. That why I mentioned it. If you=20 > > think it is not necessary, we can remove it. > > =20 >=20 > Its not so much that this is unnecessary. I'm more concerned=20 > that the text focuses on a relatively weird corner case and=20 > without explaining it well. And yet there's the more general=20 > issue that if you use IPsec to secure the packets, you can be=20 > sure that only an authorized party can have sent a particular=20 > message. So I would suggest focusing on the general property=20 > which covers even your special case. [Ahmad] Sure; will modify the text to address the more general case. >=20 > >> You need to specify what the syntax of the wildcard format=20 > is. Note=20 > >> that '*' is a legal character in the username portion of a NAI=20 > >> [RFC4282], so I would recommend considering another syntax=20 > (such as=20 > >> @example.com). > >> =20 > > > > [Ahmad] > > Sure. Will fix it. > > =20 >=20 > Ok. It would be good to see the change here, because unlike=20 > the other changes that I requested, this one may not be=20 > trivial. Perhaps the chairs can find some RADIUS and NAI=20 > capable reviewers to make sure the wildcard format doesn't=20 > have any unexpected side effects? [Ahmad] Good idea.=20 Will post the text before publishing the draft, hopefully early next week. =20 Regards, Ahmad