From hipsec-bounces@ietf.org Wed Jun 1 03:48:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02751 for ; Wed, 1 Jun 2005 03:48:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdNwQ-0008IB-AR; Wed, 01 Jun 2005 03:47:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdNwO-0008I6-Pb for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 03:47:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02719 for ; Wed, 1 Jun 2005 03:47:02 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdOGA-0002xO-A1 for hipsec@ietf.org; Wed, 01 Jun 2005 04:07:31 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 809D0212C40; Wed, 1 Jun 2005 10:46:54 +0300 (EEST) Message-ID: <429D67EE.7030908@nomadiclab.com> Date: Wed, 01 Jun 2005 10:46:54 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B8A@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B8A@xch-nw-27.nw.nos.boeing.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Re: ECHO_* parameters X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: > The ECHO_REQUEST and ECHO_RESPONSE are listed as non-critical parameters > inside the signature, and critical outside the signature. > > As presently defined, they should be "critical" in both places. While > their use is optional in some packets, it seems to me that if > ECHO_REQUEST is present, ECHO_RESPONSE MUST be sent. At least this is > the case in the CLOSE/CLOSE_ACK packets. True. This was indicated by Jeff at some point, and changed to the previous version (25.5.05). /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 1 04:04:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03797 for ; Wed, 1 Jun 2005 04:04:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdOCC-0002Ti-F2; Wed, 01 Jun 2005 04:03:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdOCA-0002Td-FH for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 04:03:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03747 for ; Wed, 1 Jun 2005 04:03:20 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdOVv-0003ma-Lr for hipsec@ietf.org; Wed, 01 Jun 2005 04:23:49 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 883F6212C40; Wed, 1 Jun 2005 11:03:11 +0300 (EEST) Message-ID: <429D6BBF.7060501@nomadiclab.com> Date: Wed, 01 Jun 2005 11:03:11 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" References: <6938661A6EDA8A4EA8D1419BCE46F24C066493BA@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C066493BA@xch-nw-27.nw.nos.boeing.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Re: Numbering of TLVs X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > have been spaced to allow for future protocol extensions. Parameters > numbered between 0-1023 are used in HIP handshake and update procedures Was there any reasoning ealier to put them below 512? > to insert a new parameter between two existing ones, it is numbered to > split the difference between the two, etc. Ok. Any objections to the proposed numbering? > For example: > OLD NEW > ESP_INFO 1 65 (2^6+1) > R1_COUNTER 2 128 (2*2^6) > LOCATOR 3 193 (3*2^6 + 1, etc.) > PUZZLE 5 257 > SOLUTION 7 321 > SEQ 11 385 > ACK 13 449 > DIFFIE_HELLMAN 15 513 > HIP_TRANSFORM 17 577 > ENCRYPTED 21 641 > HOST_ID 35 705 > CERT 64 768 > NOTIFY 256 832 > > ECHO_REQUEST 1022 896 > ECHO_RESPONSE 1024 960 > > ESP_TRANSFORM 2048 2048 > > HMAC 65245 61505 > HMAC_2 65247 61569 > HIP_SIGNATURE_2 65277 61633 > HIP_SIGNATURE 65279 61697 > > ECHO_REQUEST 65281 63661 > ECHO_RESPONSE 65283 63425 > > FROM 65470 63552 > RVS_HMAC 65472 63616 > VIA_RVS 65474 63680 /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From mailman-bounces@ietf.org Wed Jun 1 06:54:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02979 for ; Wed, 1 Jun 2005 06:54:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdP9W-0005H9-Vm for hip-archive@lists.ietf.org; Wed, 01 Jun 2005 05:04:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: hip-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Jun 2005 05:01:16 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for hip-archive@lists.ietf.org: List Password // URL ---- -------- hipsec@lists.ietf.org udgise https://www1.ietf.org/mailman/options/hipsec/hip-archive%40lists.ietf.org From hipsec-bounces@ietf.org Wed Jun 1 07:03:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03828 for ; Wed, 1 Jun 2005 07:03:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdR0Y-0002he-VU; Wed, 01 Jun 2005 07:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdR0X-0002gn-Db for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 07:03:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03814 for ; Wed, 1 Jun 2005 07:03:30 -0400 (EDT) Received: from newyork.ucdavis.edu ([169.237.104.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdRKK-00044g-HH for hipsec@ietf.org; Wed, 01 Jun 2005 07:24:02 -0400 Received: from citheronia.ucdavis.edu (citheronia.ucdavis.edu [169.237.104.183]) by newyork.ucdavis.edu (8.13.3/8.13.1/it-defang-5.3.0) with ESMTP id j51B3TlE029037 for ; Wed, 1 Jun 2005 04:03:29 -0700 (PDT) Received: from citheronia.ucdavis.edu (localhost [127.0.0.1]) by citheronia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j51B3TgD022691 for ; Wed, 1 Jun 2005 04:03:29 -0700 (PDT) Received: (from www@localhost) by citheronia.ucdavis.edu (8.12.10/8.12.9/Submit) id j51B3T3r022690; Wed, 1 Jun 2005 04:03:29 -0700 (PDT) Date: Wed, 1 Jun 2005 04:03:29 -0700 (PDT) Message-Id: <200506011103.j51B3T3r022690@citheronia.ucdavis.edu> To: hipsec@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [Hipsec] Deadline extended: JSAC-MRNM X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY The deadline is extened until June 5th. http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 5, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 1 08:19:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11260 for ; Wed, 1 Jun 2005 08:19:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdS9x-00076s-Rt; Wed, 01 Jun 2005 08:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdS9w-00076l-3l for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 08:17:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11164 for ; Wed, 1 Jun 2005 08:17:16 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdSTj-0008CX-7M for hipsec@ietf.org; Wed, 01 Jun 2005 08:37:48 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 1D7E8212C40; Wed, 1 Jun 2005 15:17:07 +0300 (EEST) Message-ID: <429DA742.7040508@nomadiclab.com> Date: Wed, 01 Jun 2005 15:17:06 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Re: ESP draft snapshot 31.05.05 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Ahrenholz, Jeffrey M wrote: > Petri, > please see below... >>I couldn't now find the place in text. Can you give a pointer to that? > > > (using pre310505) > Section 4.1.2 Updating an Existing ESP SA -- this mentions the keymat > index. > Section 4.1.1 Setting up an ESP Security Association -- this contains no > mention of the keymat index. > The keymat index is described in detail in 5.1.1 ESP_INFO, then for > packet processing, it is described for sections 6.8, 6.9, 6.9.1, 6.9.2, > 6.9.3, 6.10, but not in sections 6.5 and 6.6. > > Section 7 Keying Material says "After the HIP association keys have been > drawn, the ESP keys are drawn..." and this is the first advice given to > the reader on what value the keymat index should have during the base > exchange. Some fixes: 4.1.1: "...be used by the peer host. The ESP_INFO Keymat Index value MUST be set to zero." 6.5 (provided already by Tom): "For this initial ESP SA establishment, the Old SPI value MUST be zero. The Keymat Index field MUST be zero." 6.6: "...to the peer. The ESP_INFO Keymat Index field MUST be zero." Question: should the Keymat Index be something else than zero during the base exchange? Basically, the Keymat Index points to the place where keys are drawn and in _this_ specification we are defining ESP_INFO that is used to get the ESP SA established. We are not "interested" in HIP keys. Thus, the Keymat Index during the base exchange should point already to the point from where the ESP keys are drawn. Of course, keeping the Keymat Index value zero during base exchange, does not break anything because we say that the ESP keys are drawn after the HIP association keys. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 1 10:59:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23827 for ; Wed, 1 Jun 2005 10:59:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUdz-0000sI-4e; Wed, 01 Jun 2005 10:56:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUdx-0000s5-Gi for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 10:56:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23593 for ; Wed, 1 Jun 2005 10:56:27 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUxm-00080b-Ke for hipsec@ietf.org; Wed, 01 Jun 2005 11:17:00 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA24454; Wed, 1 Jun 2005 07:56:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j51EuFn00893; Wed, 1 Jun 2005 07:56:15 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 07:56:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jun 2005 07:56:15 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C066493CC@xch-nw-27.nw.nos.boeing.com> Thread-Topic: Numbering of TLVs Thread-Index: AcVmgGMrVP1x1WlkS8ulFkoBtfeYZgAOWmMA From: "Henderson, Thomas R" To: "Petri Jokela" X-OriginalArrivalTime: 01 Jun 2005 14:56:15.0483 (UTC) FILETIME=[0F3244B0:01C566BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] RE: Numbering of TLVs X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Wednesday, June 01, 2005 1:03 AM > To: Henderson, Thomas R > Cc: hipsec@ietf.org > Subject: Re: Numbering of TLVs >=20 >=20 > > have been spaced to allow for future protocol extensions. =20 > Parameters > > numbered between 0-1023 are used in HIP handshake and=20 > update procedures >=20 > Was there any reasoning ealier to put them below 512? I do not know any such reason. The below scheme is somewhat arbitrary too, but one has to draw lines somewhere. >=20 > > to insert a new parameter between two existing ones, it is=20 > numbered to > > split the difference between the two, etc. >=20 > Ok. Any objections to the proposed numbering? >=20 > >=20 > > ECHO_REQUEST 1022 896 > > ECHO_RESPONSE 1024 960 > >=20 Just that these should also be bumped up by 1 (as per previous message on critical bit for these parameters). Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 1 11:01:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24121 for ; Wed, 1 Jun 2005 11:01:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUc2-0000VU-OV; Wed, 01 Jun 2005 10:54:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUc1-0000VP-Lg for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 10:54:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23373 for ; Wed, 1 Jun 2005 10:54:27 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUvq-0007r2-Iw for hipsec@ietf.org; Wed, 01 Jun 2005 11:15:00 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA14166; Wed, 1 Jun 2005 07:54:11 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j51EsAp04870; Wed, 1 Jun 2005 09:54:10 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 07:53:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Re: ESP draft snapshot 31.05.05 Date: Wed, 1 Jun 2005 07:53:45 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C066493CB@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Re: ESP draft snapshot 31.05.05 Thread-Index: AcVmpBEyPQExUKIcQni4pHOza7g8HQAFSQaQ From: "Henderson, Thomas R" To: "Petri Jokela" X-OriginalArrivalTime: 01 Jun 2005 14:53:46.0294 (UTC) FILETIME=[B645D560:01C566B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Wednesday, June 01, 2005 5:17 AM > To: Ahrenholz, Jeffrey M > Cc: hipsec@ietf.org > Subject: [Hipsec] Re: ESP draft snapshot 31.05.05 >=20 >=20 > Question: should the Keymat Index be something else than zero=20 > during the > base exchange? Basically, the Keymat Index points to the place where > keys are drawn and in _this_ specification we are defining=20 > ESP_INFO that > is used to get the ESP SA established. We are not "interested" in HIP > keys. Thus, the Keymat Index during the base exchange should point > already to the point from where the ESP keys are drawn. >=20 > Of course, keeping the Keymat Index value zero during base exchange, > does not break anything because we say that the ESP keys are=20 > drawn after > the HIP association keys. >=20 I had similar thoughts when reviewing it. The only argument that I could see for having it be zero is if it were burdensome to compute the actual offset when ESP_INFO is created because possibly the HIP key sizes are not known yet. But I do not think such a case applies. =20 So I would vote for keeping it consistent as you suggest-- even during base exchange, it points to the right place to start drawing ESP keys (not zero). Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Thu Jun 2 01:51:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14030 for ; Thu, 2 Jun 2005 01:51:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddiax-0003VP-FP; Thu, 02 Jun 2005 01:50:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddiaw-0003Ty-L7 for hipsec@megatron.ietf.org; Thu, 02 Jun 2005 01:50:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13880 for ; Thu, 2 Jun 2005 01:50:17 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddiut-0006vP-Fj for hipsec@ietf.org; Thu, 02 Jun 2005 02:10:57 -0400 Received: from localhost (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id 8400F212C40; Thu, 2 Jun 2005 08:50:06 +0300 (EEST) From: Jan Mikael Melen Date: Thu, 2 Jun 2005 08:49:29 +0300 User-Agent: KMail/1.7.1 To: mobike@machshav.com, hipsec@ietf.org MIME-Version: 1.0 Message-Id: <200506020849.37110.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Hipsec] Fwd: I-D ACTION:draft-nikander-esp-beet-mode-03.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0923127224==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============0923127224== Content-Type: multipart/signed; boundary="nextPart3897362.bIfzanmjPT"; protocol="application/pgp-signature"; micalg=pgp-sha1 --nextPart3897362.bIfzanmjPT Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit ---------- Forwarded Message ---------- Subject: I-D ACTION:draft-nikander-esp-beet-mode-03.txt Date: Wednesday 01 June 2005 23:03 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bound End-to-End Tunnel (BEET) mode for ESP Author(s) : P. Nikander, J. Melen Filename : draft-nikander-esp-beet-mode-03.txt Pages : 29 Date : 2005-6-1 This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-esp-beet-mode-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nikander-esp-beet-mode-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------- --nextPart3897362.bIfzanmjPT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCnp3wp4iklvjQtTgRAh1LAJ907tNq0IQuGRsavEROBWwxo5UYbQCfXqrk Rj3R0thZ5HV+o8zubBMJBNA= =P7Xo -----END PGP SIGNATURE----- --nextPart3897362.bIfzanmjPT-- --===============0923127224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0923127224==-- From hipsec-bounces@ietf.org Fri Jun 3 08:59:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24433 for ; Fri, 3 Jun 2005 08:59:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBju-0002e4-Al; Fri, 03 Jun 2005 08:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBjt-0002dt-1u for hipsec@megatron.ietf.org; Fri, 03 Jun 2005 08:57:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24225 for ; Fri, 3 Jun 2005 08:57:27 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeC44-0003KR-E4 for hipsec@ietf.org; Fri, 03 Jun 2005 09:18:23 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 19A20212C40 for ; Fri, 3 Jun 2005 15:57:12 +0300 (EEST) Message-ID: <42A053A7.5060705@nomadiclab.com> Date: Fri, 03 Jun 2005 15:57:11 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Hipsec] ESP draft snapshot 03.06.2005 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit The latest version of ESP usage with HIP is available at http://hip4inter.net/drafts.php (date 03.06.05) - Initial version of the security considerations section has been written. - IANA consideratios has been added (two new parameter types). - Few fixes (see the diff file between 31.05 and this version). o During base exchange, keymat index points to the ESP SA keys o REKEYING state taken away completely o few typos known, 6.9.3: Pfaket, empty bullet 5 I haven't yet made any changes regarding possible problems when UDPATEs are crossing each other. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 6 11:07:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08713 for ; Mon, 6 Jun 2005 11:07:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJBx-00067E-MJ; Mon, 06 Jun 2005 11:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJBv-000674-Lj for hipsec@megatron.ietf.org; Mon, 06 Jun 2005 11:07:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08705 for ; Mon, 6 Jun 2005 11:07:01 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfJWl-00036m-0k for hipsec@ietf.org; Mon, 06 Jun 2005 11:28:37 -0400 Received: from [192.168.10.123] (62.206.52.42) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 4291895A00846412; Mon, 6 Jun 2005 17:06:43 +0200 From: Julien Laganier To: namedroppers@ops.ietf.org User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 6 Jun 2005 16:20:50 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200506061620.53254.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] review of draft-ietf-hip-dns-01 (DNS extension for HIP ) X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear dnsext members, I am editor for draft-ietf-hip-dns-01 (DNS extensions for the Host Identity Protocol), which defines two new RRs for storing HIP nodes public keys and rendezvous servers IP addresses in the DNS. Our intent is to publish it as an EXPERIMENTAL RFC to allow further experimentations with HIP. Because the document is now quite mature w.r.t. to the HIP WG, I'd like to solicit some help from the DNS experts to do a cross-area review of the document (which is short and very similar to RFC4025 - IPSECKEY RR). Do you have an idea of the best way to proceed? Thanks. Best Regards, -- Julien Laganier _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Thu Jun 9 07:00:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13302 for ; Thu, 9 Jun 2005 07:00:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgKko-0006Go-69; Thu, 09 Jun 2005 06:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgKkm-0006Ec-LF for hipsec@megatron.ietf.org; Thu, 09 Jun 2005 06:59:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13253 for ; Thu, 9 Jun 2005 06:59:13 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgL5j-000472-1i for hipsec@ietf.org; Thu, 09 Jun 2005 07:20:56 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 5F14F212C40 for ; Thu, 9 Jun 2005 13:58:11 +0300 (EEST) Message-ID: <42A820C3.4050202@nomadiclab.com> Date: Thu, 09 Jun 2005 13:58:11 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Subject: [Hipsec] ESP draft - state machine and simultaneous UPDATEs X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, We tried to figure out how the system should behave when UPDATE messages for rekeying or ESP transform changes are initiated simultaneously and cross each other in the network. With the current UPDATE ACK system the state machine became a chaos because the ACK is not necessarily included in the response packet (response packet = response to the change request, not response to the UPDATE packet), but can arrive in a separate UPDATE packet later. One way to manage this is to make it mandatory to send the ACK in the same packet as SEQ in the following way: UPD(SEQ...) ----------------> UPD(SEQ, ACK...) <---------------- UPD(ACK) ----------------> This would help a host that has initialized rekeying/family change so that it knows if the received packet is an answer or if it is an initialization message. The other way would be to include some "initialization" parameter in the ESP_INFO/ESP_TRANSFORM parameters that could be used to track the packets. But that would be adding yet another acknowledgement system on top of the UPDATE ack system. We created a following state machine, when the middle UPDATE message must contain both SEQ and ACK: EI = ESP_INFO TR = ESP_TRANSFORM [C] = conditional, the behaviour is based on the HIT value comparison (if local HIT is greater, choose one path and if smaller, choose the other path) DIFFIE_HELLMAN is not included in the picture, as it is OPTIONAL and not necessary included in messages to both directions TR_CH_IN = ESP transform family change initiated by the peer host TR_CH_OUT = ESP transform family change initiated by this host REKEY_IN = rekeying initiated by the peer host REKEY_OUT = rekeying initiated by this host +---------------------------------------+[C]<-+ | | | |out: EI+TR+ACK (drop)| |in: EI+TR V V | +-----------+ +-----------+ +>| TR_CH_IN |<-----------+ +------->| TR_CH_OUT | | +-----------+ | | +-----------+ | | | | | ^ in: EI | | in: EI+TR| | | | out: EI+TR | | out: EI+TR+ACK| |out: EI+TR +--+ | | | | | | | | | |in: ACK | | | | | | | | +-------------+ | +-------------->| ESTABLISHED |<---------+ | +-------------+ | | | ^ | |in: EI+ACK | +------------+ | | |out: ACK | | | | | | |in: EI | |out: EI | | |out: EI+ACK | | | | | | | | | v | | | | +-----------+ | | +-----------+ | | REKEY_IN |---------------+ +------->| REKEY_OUT | | +-----------+ in: ACK +-----------+ | | ^ ^ | ^ | | | | | in: EI | | | | +--+ | V |drop | in: EI+TR | in: EI +--------------------------------[C]-+ | out:EI+TR+ACK | out: EI+ACK out: EI+ACK | | | +--------------------------------------------------------+ /Petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Thu Jun 9 10:18:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05359 for ; Thu, 9 Jun 2005 10:18:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNoA-0000vO-Bp; Thu, 09 Jun 2005 10:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNo5-0000uX-61 for hipsec@megatron.ietf.org; Thu, 09 Jun 2005 10:14:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04786 for ; Thu, 9 Jun 2005 10:14:49 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgO9W-0005Qr-Jz for hipsec@ietf.org; Thu, 09 Jun 2005 10:37:03 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 80460212C3D; Thu, 9 Jun 2005 17:14:29 +0300 (EEST) In-Reply-To: <42A820C3.4050202@nomadiclab.com> References: <42A820C3.4050202@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] ESP draft - state machine and simultaneous UPDATEs Date: Thu, 9 Jun 2005 10:14:28 -0400 To: Petri Jokela X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I don't have time to consider this now in detail, but just an idea: Can't we apply ideas from the TCP state machine? It allows SYNs and FINs to be crossing in parallel and handles them nicely, and IIRC in a simpler way than what you are now suggesting. --Pekka On Jun 9, 2005, at 6:58, Petri Jokela wrote: > Hi, > > We tried to figure out how the system should behave when UPDATE > messages > for rekeying or ESP transform changes are initiated simultaneously and > cross each other in the network. With the current UPDATE ACK system the > state machine became a chaos because the ACK is not necessarily > included > in the response packet (response packet = response to the change > request, not response to the UPDATE packet), but can arrive in a > separate UPDATE packet later. > > One way to manage this is to make it mandatory to send the ACK in the > same packet as SEQ in the following way: > > > UPD(SEQ...) > ----------------> > UPD(SEQ, ACK...) > <---------------- > UPD(ACK) > ----------------> > > This would help a host that has initialized rekeying/family change so > that it knows if the received packet is an answer or if it is an > initialization message. > > The other way would be to include some "initialization" parameter in > the > ESP_INFO/ESP_TRANSFORM parameters that could be used to track the > packets. But that would be adding yet another acknowledgement system on > top of the UPDATE ack system. > > We created a following state machine, when the middle UPDATE message > must contain both SEQ and ACK: > > EI = ESP_INFO > TR = ESP_TRANSFORM > [C] = conditional, the behaviour is based on the HIT value comparison > (if local HIT is greater, choose one path and if smaller, choose the > other path) > > DIFFIE_HELLMAN is not included in the picture, as it is OPTIONAL and > not > necessary included in messages to both directions > > TR_CH_IN = ESP transform family change initiated by the peer host > TR_CH_OUT = ESP transform family change initiated by this host > REKEY_IN = rekeying initiated by the peer host > REKEY_OUT = rekeying initiated by this host > > > +---------------------------------------+[C]<-+ > | | | > |out: EI+TR+ACK (drop)| |in: EI+TR > V V | > +-----------+ +-----------+ > +>| TR_CH_IN |<-----------+ +------->| TR_CH_OUT | > | +-----------+ | | +-----------+ > | | | | | ^ in: EI > | | in: EI+TR| | | | out: EI+TR > | | out: EI+TR+ACK| |out: EI+TR +--+ > | | | | > | | | | > | |in: ACK | | > | | | | > | | +-------------+ > | +-------------->| ESTABLISHED |<---------+ > | +-------------+ | > | | ^ | |in: EI+ACK > | +------------+ | | |out: ACK > | | | | | > | |in: EI | |out: EI | > | |out: EI+ACK | | | > | | | | | > | v | | | > | +-----------+ | | +-----------+ > | | REKEY_IN |---------------+ +------->| REKEY_OUT | > | +-----------+ in: ACK +-----------+ > | | ^ ^ | ^ | > | | | | in: EI | | | > | +--+ | V |drop | in: EI+TR > | in: EI +--------------------------------[C]-+ | > out:EI+TR+ACK > | out: EI+ACK out: EI+ACK | > | | > +--------------------------------------------------------+ > > > /Petri > > > -- > Petri Jokela Tel: +358 9 299 2413 > Research scientist Fax: +358 9 299 3535 > NomadicLab, Ericsson Research Mobile: +358 44 299 2413 > Oy L M Ericsson Ab email: petri.jokela@ericsson.com > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Sun Jun 12 12:02:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15939 for ; Sun, 12 Jun 2005 12:02:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhUt3-0000Sc-8C; Sun, 12 Jun 2005 12:00:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhUt1-0000SX-Q3 for hipsec@megatron.ietf.org; Sun, 12 Jun 2005 12:00:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15820 for ; Sun, 12 Jun 2005 12:00:33 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+B/Hj1FmH/SXpYK+6h47+wm9yLuCAggng=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhVF7-0007r6-By for hipsec@ietf.org; Sun, 12 Jun 2005 12:23:26 -0400 Received: from hsi-kbw-085-216-018-203.hsi.kabelbw.de ([85.216.18.203] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DhUsZ-0004xV-6u; Sun, 12 Jun 2005 18:00:13 +0200 Message-ID: <42AC5C02.1000702@tm.uka.de> Date: Sun, 12 Jun 2005 18:00:02 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Thomas Henderson , Pekka Nikander , Gregory Perkins , Jari Arkko , hipsec@ietf.org X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -102.5 (---------------------------------------------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Hipsec] Review of draft-ietf-hip-mm-01 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0237114440==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0237114440== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig393013829B1490D394A1C003" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig393013829B1490D394A1C003 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, reviewing draft-ietf-hip-mm-01, a couple of things came to my mind: (1) Address verification. The draft mentiones in several places that a correspondent host may omit address verification for a mobile or multi-homed peer in case that peer is sufficiently trusted to provide the right addresses. I don't think trust eliminates the need for an address check, however. James Kempf brought this up on the Mobopts mailing list [1]. If we omit the address check for "trusted" nodes, those nodes could still be compromised by malware and start to redirect packets. In other words, a node redirecting packets to the wrong address may not do this by intention; the perpetrator could be someone else who brought that node under his control through a viral software. Admittedly, the use of IPsec ESP would probably require a very sophisticated virus/worm... Anyway, I'd propose to make address verification a MUST in all cases. Note that the verification won't delay communications since we are now using Credit-Based Authorization (CBA). I drafted possible modifications for the affected paragraphs and sent them to the co-editors of draft-ietf-hip-mm-01 as part of my CBA-related modifications. (2) Section 7.1 (Sending LOCATORs) and 7.2 (Handling received LOCATORs): There is mentioning of an "SPI field" inside the LOCATOR parameter. Is this a relict from draft-ietf-hip-mm-00? There used to be a SPI field in the REA parameter, but there is none in the LOCATOR parameter. As far as I understand, the SPI is now part of the Locator field. (3) Section 7.1 (Sending LOCATORs). Paragraph 8 says: "If there are multiple LOCATOR parameters leading to a packet size that exceeds the MTU, the host SHOULD send multiple packets, each smaller than the MTU. In the case of R1 and I2, the additional packets should be UPDATE packets that are sent after the base exchange has been completed." My concern is this: Any locator not in the first packet will (temporarily) be set to DEPRECATED status according to paragraph 5 of this section. Even when it shows up in a subsequent packet, it will first go to UNVERIFIED status, and address verification will have to be accomplished even if the locator was in ACTIVE status before the first packet arrived. So it seems that splitting the locator set over multiple packets would be sub-optimal. Would it be possible to change the semantics of the LOCATOR parameter such that existing locators are not removed when they do not show up? The readdressing host could explicitly remove a locator by advertising it with a zero Locator Lifetime, e.g. Regards, - Christian [1] http://www1.ietf.org/mail-archive/web/mip6/current/msg02936.html -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ --------------enig393013829B1490D394A1C003 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCrFwGwstEk8gl2rURAj19AJ43P05vcYwgUbSZliHdGZwildO/AwCgmq8u wrq/yo53YGvCla4q8OXdtIE= =HrOV -----END PGP SIGNATURE----- --------------enig393013829B1490D394A1C003-- --===============0237114440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0237114440==-- From hipsec-bounces@ietf.org Mon Jun 13 03:16:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13622 for ; Mon, 13 Jun 2005 03:16:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhj9j-0004Ta-EI; Mon, 13 Jun 2005 03:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhj9f-0004TN-ES for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 03:14:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13510 for ; Mon, 13 Jun 2005 03:14:42 -0400 (EDT) Received: from ntp1.niksula.cs.hut.fi ([130.233.40.5] helo=twilight.cs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhjVt-0005Ce-66 for hipsec@ietf.org; Mon, 13 Jun 2005 03:37:42 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id B25772DB3; Mon, 13 Jun 2005 10:14:24 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5D2F82DA6; Mon, 13 Jun 2005 10:14:20 +0300 (EEST) In-Reply-To: <42AC5C02.1000702@tm.uka.de> References: <42AC5C02.1000702@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8ce426317c0fae13af48790697ed040a@iki.fi> Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [Hipsec] Review of draft-ietf-hip-mm-01 Date: Mon, 13 Jun 2005 00:14:22 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Jari Arkko X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 12, 2005, at 9:00, Christian Vogt wrote: Christian, > reviewing draft-ietf-hip-mm-01, a couple of things came to my mind: > > (1) Address verification. The draft mentiones in several places that > a > correspondent host may omit address verification for a mobile or > multi-homed peer in case that peer is sufficiently trusted to provide > the right addresses. I don't think trust eliminates the need for an > address check, however. Actually, I have been thinking the same issue of whether to do the address verification or not, but from a slightly different viewpoint. IMHO, there might be certain use cases where you would like to know for sure whether the remote peer is about to send an address verification or not. One example, perhaps a bit artificial though, that comes to my mind is related to power management: a mobile device sends an UPDATE and begins to wait for an UPDATE with ACK. Now, if the device would know whether the peer is *not* about to respond with an address verification check, it could shutdown the transmitter components of its radio right after sending the UPDATE with new locator. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 13 06:34:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27770 for ; Mon, 13 Jun 2005 06:34:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhmDi-0001bi-3k; Mon, 13 Jun 2005 06:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhmDN-0001bU-62 for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 06:30:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27397 for ; Mon, 13 Jun 2005 06:30:42 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhmZa-0005Uh-C7 for hipsec@ietf.org; Mon, 13 Jun 2005 06:53:45 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id E2F3B212C3C; Mon, 13 Jun 2005 13:30:18 +0300 (EEST) Message-ID: <42AD603A.2040605@nomadiclab.com> Date: Mon, 13 Jun 2005 13:30:18 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Re: ESP draft snapshot 31.05.05 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Ahrenholz, Jeffrey M wrote: >>>- The 64-bit sequence number is interesting, but: To >> >>implement it, you >> >>>just keep an additional 32-bit counter representing the >> >>upper bits? Upon >> >>>rollover of the lower 32-bits, you increment the upper. What is the >>>usefulness of this? i.e. how can the replay window be >> >>enforced if it is >> >>>not part of each packet? Maybe we could have more text on >> >>this or an >> >>>appropriate reference. >> >>Hmm.. I'm not sure how to fix this. Earlier there was some talk about >>having AES-CBC IV vectors from the sequence number, but the >>RFC3602 states >>that the IV must be random. > > > So is there a benefit to using these 64-bit sequence numbers? Why do we > need them? Nobody has reacted on this issue. There seems not to be need for the 64-bit sequence numbers. So, if there is no reason to keep it there I will remove it from the next version. Comments? /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 13 08:22:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04902 for ; Mon, 13 Jun 2005 08:22:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhnvE-0002SM-8N; Mon, 13 Jun 2005 08:20:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhnud-0002LD-GN for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 08:19:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04618 for ; Mon, 13 Jun 2005 08:19:30 -0400 (EDT) Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DhoGt-0001yf-T3 for hipsec@ietf.org; Mon, 13 Jun 2005 08:42:33 -0400 Received: (qmail 89967 invoked from network); 13 Jun 2005 12:19:19 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 13 Jun 2005 12:19:19 -0000 Received: (qmail 37032 invoked from network); 13 Jun 2005 08:19:19 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.78) by mail1.oct.nac.net with SMTP; 13 Jun 2005 08:19:19 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j5D97Wk08030; Mon, 13 Jun 2005 05:07:32 -0400 Date: Mon, 13 Jun 2005 05:07:32 -0400 (EDT) From: George Gross To: Petri Jokela Subject: Re: [Hipsec] Re: ESP draft snapshot 31.05.05 In-Reply-To: <42AD603A.2040605@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.7 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi, inline.... On Mon, 13 Jun 2005, Petri Jokela wrote: > > So is there a benefit to using these 64-bit sequence numbers? Why do we > > need them? > > Nobody has reacted on this issue. There seems not to be need for the > 64-bit sequence numbers. So, if there is no reason to keep it there I > will remove it from the next version. Comments? see the draft rfc2401-bis section 4.4.2.1, now in RFC editor queue. If you want to keep alignment with IPsec definition of a SAD, 64-bit sequence numbers are a MUST. The intent of 64-bit sequence numbers is to handle high volume (>Gbps) packet flows that would overwise overflow the 32 bit sequence counter too frequently. hth, George > > /petri > > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 13 15:04:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10593 for ; Mon, 13 Jun 2005 15:04:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuDC-0006Ii-03; Mon, 13 Jun 2005 15:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuD9-0006II-AD for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 15:03:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10376 for ; Mon, 13 Jun 2005 15:03:01 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+Jyc/2KE/11Z2MBjFnKplPWF7oUk9prnY=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhuZS-0003iZ-0g for hipsec@ietf.org; Mon, 13 Jun 2005 15:26:08 -0400 Received: from hsi-kbw-085-216-018-203.hsi.kabelbw.de ([85.216.18.203] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DhuCX-0004se-GG; Mon, 13 Jun 2005 21:02:30 +0200 Message-ID: <42ADD83B.3000505@tm.uka.de> Date: Mon, 13 Jun 2005 21:02:19 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Teemu Koponen Subject: Re: [Hipsec] Review of draft-ietf-hip-mm-01 References: <42AC5C02.1000702@tm.uka.de> <8ce426317c0fae13af48790697ed040a@iki.fi> In-Reply-To: <8ce426317c0fae13af48790697ed040a@iki.fi> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -102.5 (---------------------------------------------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: hipsec@ietf.org, Jari Arkko X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2038252798==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2038252798== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B085AB892548B2391D9B8A1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B085AB892548B2391D9B8A1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Teemu, yes, what you say definitely makes sense. If we make address verification mandatory in all cases (*), which I think we should, then hosts would not wait in vain for the challenge. Would this solve your concern? (*) The one and only exception would be a new primary locator advertised as part of the R1 message. We don't need to verify reachability of that locator because, if the locator was false, then... ==> the I2 message would not reach the responder (because it's sent to the new locator) ==> the responder could not create the DH secret ==> the responder could not compute the HMAC for the R2 ==> the initiator would detect the fraud. Since address verification is unnessary in this case, it shouldn't be performed either because it could delay (or even confuse) the base exchange. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Teemu Koponen wrote: > On Jun 12, 2005, at 9:00, Christian Vogt wrote: > > Christian, > >> reviewing draft-ietf-hip-mm-01, a couple of things came to my mind: >> >> (1) Address verification. The draft mentiones in several places that a >> correspondent host may omit address verification for a mobile or >> multi-homed peer in case that peer is sufficiently trusted to provide >> the right addresses. I don't think trust eliminates the need for an >> address check, however. > > > Actually, I have been thinking the same issue of whether to do the > address verification or not, but from a slightly different viewpoint. > IMHO, there might be certain use cases where you would like to know for > sure whether the remote peer is about to send an address verification or > not. > > One example, perhaps a bit artificial though, that comes to my mind is > related to power management: a mobile device sends an UPDATE and begins > to wait for an UPDATE with ACK. Now, if the device would know whether > the peer is *not* about to respond with an address verification check, > it could shutdown the transmitter components of its radio right after > sending the UPDATE with new locator. > > Teemu --------------enig8B085AB892548B2391D9B8A1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCrdg+wstEk8gl2rURAinhAJ4/XlyLJzDOxwTk5TghIAQs/QAj6QCgkaCb CJ78lFfjxvQepbpzt4/O3+M= =zD9v -----END PGP SIGNATURE----- --------------enig8B085AB892548B2391D9B8A1-- --===============2038252798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============2038252798==-- From hipsec-bounces@ietf.org Mon Jun 13 16:01:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24023 for ; Mon, 13 Jun 2005 16:01:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhv1Q-0003mV-Jn; Mon, 13 Jun 2005 15:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhv1P-0003mK-4J for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 15:54:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21123 for ; Mon, 13 Jun 2005 15:54:57 -0400 (EDT) Received: from ns.niksula.cs.hut.fi ([130.233.40.5] helo=twilight.cs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhvNi-0007yx-HV for hipsec@ietf.org; Mon, 13 Jun 2005 16:18:04 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D87482EE5; Mon, 13 Jun 2005 22:54:46 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9DAC82EBF; Mon, 13 Jun 2005 22:54:44 +0300 (EEST) In-Reply-To: <42ADD83B.3000505@tm.uka.de> References: <42AC5C02.1000702@tm.uka.de> <8ce426317c0fae13af48790697ed040a@iki.fi> <42ADD83B.3000505@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3c641c22c9aa7cb1eb7b2b6361bd9010@iki.fi> Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [Hipsec] Review of draft-ietf-hip-mm-01 Date: Mon, 13 Jun 2005 12:54:46 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Jari Arkko X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 13, 2005, at 12:02, Christian Vogt wrote: Christian, > If we make address verification mandatory in all cases (*), which I > think we should, then hosts would not wait in vain for the challenge. > Would this solve your concern? Yes it certainly would, as my main concern was exactly the ambiguity. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 13 16:19:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02533 for ; Mon, 13 Jun 2005 16:19:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhvI6-0007iR-7h; Mon, 13 Jun 2005 16:12:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhvI2-0007hB-Lm for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 16:12:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29983 for ; Mon, 13 Jun 2005 16:12:07 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhveK-0002o4-B4 for hipsec@ietf.org; Mon, 13 Jun 2005 16:35:15 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA21030; Mon, 13 Jun 2005 13:11:31 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5DKBU528639; Mon, 13 Jun 2005 15:11:30 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 13:10:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2005 13:12:43 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0959C7@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: Review of draft-ietf-hip-mm-01 Thread-Index: AcVvZ/PG9Q2s6kITSWerQJglcsx6KwAw8txw From: "Henderson, Thomas R" To: "Christian Vogt" , "Pekka Nikander" , "Gregory Perkins" , "Jari Arkko" , X-OriginalArrivalTime: 13 Jun 2005 20:10:57.0954 (UTC) FILETIME=[02FBB020:01C57054] X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Subject: [Hipsec] RE: Review of draft-ietf-hip-mm-01 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Christian Vogt [mailto:chvogt@tm.uka.de]=20 > Sent: Sunday, June 12, 2005 9:00 AM > To: Henderson, Thomas R; Pekka Nikander; Gregory Perkins;=20 > Jari Arkko; hipsec@ietf.org > Cc: Jan.Melen@nomadiclab.com; Ahrenholz, Jeffrey M > Subject: Review of draft-ietf-hip-mm-01 >=20 > Hi everybody, >=20 > reviewing draft-ietf-hip-mm-01, a couple of things came to my mind: >=20 > (1) Address verification. The draft mentiones in several=20 > places that a > correspondent host may omit address verification for a mobile or > multi-homed peer in case that peer is sufficiently trusted to provide > the right addresses. I don't think trust eliminates the need for an > address check, however. James Kempf brought this up on the Mobopts > mailing list [1]. If we omit the address check for "trusted" nodes, > those nodes could still be compromised by malware and start=20 > to redirect > packets. In other words, a node redirecting packets to the wrong > address may not do this by intention; the perpetrator could be someone > else who brought that node under his control through a viral software. >=20 > Admittedly, the use of IPsec ESP would probably require a very > sophisticated virus/worm... >=20 > Anyway, I'd propose to make address verification a MUST in all cases. > Note that the verification won't delay communications since we are now > using Credit-Based Authorization (CBA). Disclaimer: I was one who originally pushed for making address check a MAY instead of a MUST, to save transmissions and latency in certain (wireless) environments. However, I think your security rationale may trump this (and as you mention, CBA solves the latency issue). There is an additional consideration that may bias towards always sending the address check-- if one wants HIP-aware middleboxes to be able to learn SPI/identity bindings, there needs to be a packet in each direction. So I would agree with your proposal now-- make address verification prior to address use a MUST for hosts that have received an UPDATE (but, as presently specified, do not require the peer host to enforce this MUST condition). > (2) Section 7.1 (Sending LOCATORs) and 7.2 (Handling received > LOCATORs): There is mentioning of an "SPI field" inside the LOCATOR > parameter. Is this a relict from draft-ietf-hip-mm-00? There used to > be a SPI field in the REA parameter, but there is none in the LOCATOR > parameter. As far as I understand, the SPI is now part of the Locator > field. >=20 Yes, the text in this section has fallen inconsistent with the LOCATOR format. > (3) Section 7.1 (Sending LOCATORs). Paragraph 8 says: >=20 > "If there are multiple LOCATOR parameters leading to a packet size > that exceeds the MTU, the host SHOULD send multiple packets, each > smaller than the MTU. In the case of R1 and I2, the additional > packets should be UPDATE packets that are sent after the base > exchange has been completed." >=20 > My concern is this: Any locator not in the first packet will > (temporarily) be set to DEPRECATED status according to paragraph 5 of > this section. Even when it shows up in a subsequent packet, it will > first go to UNVERIFIED status, and address verification will=20 > have to be > accomplished even if the locator was in ACTIVE status before the first > packet arrived. So it seems that splitting the locator set over > multiple packets would be sub-optimal. It may be worse than this if the subsequent packets deprecate the locators of the all previous packets. =20 >=20 > Would it be possible to change the semantics of the LOCATOR parameter > such that existing locators are not removed when they do not show up? > The readdressing host could explicitly remove a locator by advertising > it with a zero Locator Lifetime, e.g. >=20 I do not recall the entire history of this issue, but if I recall correctly, both variants (explicit and implicit removal) have been supported at different times during the history of this draft. Presently, it is implicit removal (removed if locator is not present in the UPDATE). =20 One argument in favor of the status quo might be that, if the common case is single-interface mobility, the implicit removal avoids having to explicitly deprecate the old locator. =20 I think that the "large packet" issue might be better handled via IP fragmentation-- although it seems an unlikely scenario for IPv6 in particular. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 15 02:04:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13818 for ; Wed, 15 Jun 2005 02:04:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQsn-00018w-K7; Wed, 15 Jun 2005 01:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQsl-00018i-Dg for hipsec@megatron.ietf.org; Wed, 15 Jun 2005 01:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09468 for ; Wed, 15 Jun 2005 01:56:10 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiRFO-0007Xv-C0 for hipsec@ietf.org; Wed, 15 Jun 2005 02:19:34 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BA839212C3C; Wed, 15 Jun 2005 08:55:48 +0300 (EEST) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0959C7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D0959C7@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <64bc4189ceb4d45ccd1a34e60efa88c3@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 15 Jun 2005 08:55:50 +0300 To: Thomas R Henderson , Christian Vogt X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Jari Arkko , "" Subject: [Hipsec] Re: Review of draft-ietf-hip-mm-01 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >> (3) Section 7.1 (Sending LOCATORs). Paragraph 8 says: >> >> "If there are multiple LOCATOR parameters leading to a packet size >> that exceeds the MTU, the host SHOULD send multiple packets, each >> smaller than the MTU. In the case of R1 and I2, the additional >> packets should be UPDATE packets that are sent after the base >> exchange has been completed." >> >> My concern is this: Any locator not in the first packet will >> (temporarily) be set to DEPRECATED status according to paragraph 5 of >> this section. Even when it shows up in a subsequent packet, it will >> first go to UNVERIFIED status, and address verification will >> have to be >> accomplished even if the locator was in ACTIVE status before the first >> packet arrived. So it seems that splitting the locator set over >> multiple packets would be sub-optimal. > > It may be worse than this if the subsequent packets deprecate the > locators of the all previous packets. I don't think anyone has thought about that before; at least the problem didn't occur to me nor had I heard about it before. IIRC, the original reason for the behaviour was to make the method to work also if UPDATEs are lost. That is, the idea was that each address update would include complete information, making them idempotent. However, as UPDATEs are now acked there is less reason for this, though still some. >> Would it be possible to change the semantics of the LOCATOR parameter >> such that existing locators are not removed when they do not show up? >> The readdressing host could explicitly remove a locator by advertising >> it with a zero Locator Lifetime, e.g. > > I do not recall the entire history of this issue, but if I recall > correctly, both variants (explicit and implicit removal) have been > supported at different times during the history of this draft. > Presently, it is implicit removal (removed if locator is not present in > the UPDATE). IIRC, we originally had the interface identifiers there, grouping IP addresses by logical interfaces, where the logical interfaces were basically whatever groups the sender decided to have. These were later removed. > One argument in favor of the status quo might be that, if the common > case is single-interface mobility, the implicit removal avoids having > to > explicitly deprecate the old locator. Does this imply that in the case of multi-interface mobility we perhaps should reconsider interface IDs? > I think that the "large packet" issue might be better handled via IP > fragmentation-- although it seems an unlikely scenario for IPv6 in > particular. Agreed. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Thu Jun 16 08:16:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12433 for ; Thu, 16 Jun 2005 08:16:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitGY-0006MY-3r; Thu, 16 Jun 2005 08:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitGW-0006LH-Qx for hipsec@megatron.ietf.org; Thu, 16 Jun 2005 08:14:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12216 for ; Thu, 16 Jun 2005 08:14:31 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DitdO-0002Ol-DG for hipsec@ietf.org; Thu, 16 Jun 2005 08:38:15 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 10601212C3C; Thu, 16 Jun 2005 15:14:13 +0300 (EEST) Message-ID: <42B16D14.9080705@nomadiclab.com> Date: Thu, 16 Jun 2005 15:14:12 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [Hipsec] Re: ESP draft snapshot 31.05.05 References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit George Gross wrote: > Hi, > > inline.... > > On Mon, 13 Jun 2005, Petri Jokela wrote: > > > >>>So is there a benefit to using these 64-bit sequence numbers? Why do we >>>need them? >> >>Nobody has reacted on this issue. There seems not to be need for the >>64-bit sequence numbers. So, if there is no reason to keep it there I >>will remove it from the next version. Comments? > > > see the draft rfc2401-bis section 4.4.2.1, now in RFC editor queue. If you > want to keep alignment with IPsec definition of a SAD, 64-bit sequence > numbers are a MUST. The intent of 64-bit sequence numbers is to handle > high volume (>Gbps) packet flows that would overwise overflow the 32 bit > sequence counter too frequently. Valid point. I'll add a reference to this draft. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Thu Jun 16 15:46:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00309 for ; Thu, 16 Jun 2005 15:46:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0Ib-0005et-Bs; Thu, 16 Jun 2005 15:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0IY-0005eo-TI for hipsec@megatron.ietf.org; Thu, 16 Jun 2005 15:45:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00287 for ; Thu, 16 Jun 2005 15:45:05 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj0fV-00080M-CR for hipsec@ietf.org; Thu, 16 Jun 2005 16:08:54 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 90C662DB4; Thu, 16 Jun 2005 22:44:55 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 61D852D7C for ; Thu, 16 Jun 2005 22:44:53 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <75335f2e8cc57966fc019caa2a856f27@iki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed To: hipsec@ietf.org From: Teemu Koponen Date: Thu, 16 Jun 2005 12:44:56 -0700 X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Hipsec] Packet reordering, certificates and base exchange X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit All, The latest base-03-pre defines a control bit for both I2 and R2 to inform a peer to wait for shortly arriving certificate packets. However, I did not find any discussion how the peer should behave if a certificate packet arrives before I2/R2. Packet reordering is not anything rare in Internet, so it should be considered. From initiator's point of view, I think it just means that the responder's certificate packets should be cached for a short period of time. Someone else probably has a better understanding of the required time window, so I do not even try suggest any practical time. :-) However, introducing caching in responder is not an option due to the fact that it should remain stateless until it receives I2. As the initiator cannot enforce the I2 to arrive before the certificates, without a significant delay between I2 and certificate packets, I wonder if it might make sense to alter the I2 to optionally contain a number of certificate parameters. Then, initiator could actually send multiple I2s, each containing a different certificate, or a single I2 that possibly gets fragmented. If R2 gets the same enhancement, the certificate packet eventually becomes useless, I think. Comments? Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri Jun 17 03:24:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20170 for ; Fri, 17 Jun 2005 03:24:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjBC2-0007Hh-5B; Fri, 17 Jun 2005 03:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjBBz-0007Hc-QD for hipsec@megatron.ietf.org; Fri, 17 Jun 2005 03:23:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20105 for ; Fri, 17 Jun 2005 03:23:05 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjBZ2-0003ZQ-23 for hipsec@ietf.org; Fri, 17 Jun 2005 03:46:57 -0400 Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id A457B212C3C; Fri, 17 Jun 2005 10:22:51 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [193.234.219.2]) by outside.nomadiclab.com (Postfix) with ESMTP id 977CEBDC0C; Fri, 17 Jun 2005 10:22:51 +0300 (EEST) Message-ID: <42B27A49.7010007@nomadiclab.com> Date: Fri, 17 Jun 2005 10:22:49 +0300 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Teemu Koponen Subject: Re: [Hipsec] Packet reordering, certificates and base exchange References: <75335f2e8cc57966fc019caa2a856f27@iki.fi> In-Reply-To: <75335f2e8cc57966fc019caa2a856f27@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, Teemu Koponen wrote: > All, > > The latest base-03-pre defines a control bit for both I2 and R2 to > inform a peer to wait for shortly arriving certificate packets. > However, I did not find any discussion how the peer should behave if a > certificate packet arrives before I2/R2. Packet reordering is not > anything rare in Internet, so it should be considered. > > From initiator's point of view, I think it just means that the > responder's certificate packets should be cached for a short period of > time. Someone else probably has a better understanding of the required > time window, so I do not even try suggest any practical time. :-) > > However, introducing caching in responder is not an option due to the > fact that it should remain stateless until it receives I2. As the > initiator cannot enforce the I2 to arrive before the certificates, > without a significant delay between I2 and certificate packets, I > wonder if it might make sense to alter the I2 to optionally contain a > number of certificate parameters. Then, initiator could actually send > multiple I2s, each containing a different certificate, or a single I2 > that possibly gets fragmented. If R2 gets the same enhancement, the > certificate packet eventually becomes useless, I think. > > Comments? > How about adding the solved puzzle to each certificate packet (also carried in the I2 packet) going to the responder? The responder may establish a soft-state for the certificate packets after validating the puzzle, and release the state, if I2 does not arrive in the assumed time frame. -- Jukka > Teemu > > -- > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri Jun 17 04:11:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22925 for ; Fri, 17 Jun 2005 04:11:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjBue-0007dk-V8; Fri, 17 Jun 2005 04:09:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjBuc-0007bN-MD for hipsec@megatron.ietf.org; Fri, 17 Jun 2005 04:09:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22812 for ; Fri, 17 Jun 2005 04:09:12 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjCHe-0006xk-BV for hipsec@ietf.org; Fri, 17 Jun 2005 04:33:04 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3114815271 for ; Fri, 17 Jun 2005 10:24:49 +0200 (CEST) Received: from [10.1.1.112] ([10.1.1.112]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Jun 2005 10:10:03 +0200 Mime-Version: 1.0 (Apple Message framework v730) To: hipsec@ietf.org Message-Id: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> References: From: Lars Eggert Date: Fri, 17 Jun 2005 10:08:54 +0200 X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 17 Jun 2005 08:10:03.0367 (UTC) FILETIME=[F6E47F70:01C57313] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: [Hipsec] Fwd: I-D ACTION:draft-ietf-hip-rvs-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1070547434==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============1070547434== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--1045385487; protocol="application/pkcs7-signature" --Apple-Mail-8--1045385487 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit For some reasons, this announcement hasn't made it to the list yet. We'd appreciate comments on this revision! Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: June 16, 2005 21:50:02 GMT+02:00 > To: i-d-announce@ietf.org > Cc: hipsec@ietf.org > Subject: I-D ACTION:draft-ietf-hip-rvs-02.txt > Reply-To: internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Host Identity Protocol Working > Group of the IETF. > > Title : Host Identity Protocol (HIP) Rendezvous Extension > Author(s) : J. Laganier, L. Eggert > Filename : draft-ietf-hip-rvs-02.txt > Pages : 16 > Date : 2005-6-16 > > This document discusses a rendezvous extension for the Host Identity > Protocol (HIP). The rendezvous extension extends HIP and the HIP > registration extension for initiating communication between HIP > nodes > via HIP rendezvous servers. Rendezvous servers improve > reachability > and operation when HIP nodes are multi-homed or mobile. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-hip-rvs-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-hip-rvs-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-6-16151000.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-8--1045385487 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILRDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggPhMIIDSqADAgECAgMO8MUwDQYJKoZI hvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1 MDYxNzA3MzQzM1oXDTA2MDYxNzA3MzQzM1owgfMxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UEKhME TGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxIzAhBgkqhkiG9w0BCQEWFGxhcnMuZWdnZXJ0QGll ZWUub3JnMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBhY20ub3JnMSgwJgYJKoZIhvcNAQkB FhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBn bXgubmV0MSQwIgYJKoZIhvcNAQkBFhVlZ2dlcnRAYWx1bW5pLnVzYy5lZHUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCl+oudGX8XAtHhDH8R09G04C+RbQFvmG1Ctau5/8a3cuIuFcWH 8qPmxWpsIcvZR0MQ6r8Q7sPQXV5QFQKw1KijyHXF3TK2qZAl61b7keOYVFThYY6adgZyFDUTrx5E uLkpdZyzZ6ODk72OZFbOSFXBcgw5P5keVwDoeoi4Wb+XkZq6dTlqQD18j0UJAGdHTU6FXbzv5uzn ClKuUX3MOkYBa05zVCT+0uJc5hPtEIpAk0y9GRLoDjvliDKnlOvZEKje0eT/AR0CmwO8ghcW6wlQ JUWpakfoKV5CWoIfimEn0R2pD+ggmpbRwQ4BYfpFMnMFej7mFmOnbQZMHr7OtgmhAgMBAAGjgY4w gYswewYDVR0RBHQwcoEUbGFycy5lZ2dlcnRAaWVlZS5vcmeBE2xhcnMuZWdnZXJ0QGFjbS5vcmeB GWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWBE2xhcnMuZWdnZXJ0QGdteC5uZXSBFWVnZ2VydEBh bHVtbmkudXNjLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFAOwi4S0MKEr6LQ olKerPDcwpkbtgOrCopWBtATDr+ifk57LFpGiYTrWbfsSogIQbM2EUO91bpZvSaaMMim/0ChtAFb Md4l/L22fol1SkbwGvG1Q/Y6e7yVaswykhK/BLgzT6IEyREIPd/rX44m1SOXX8xM5tmxQeANXdbp w5YAMIIEGDCCA4GgAwIBAgIBADANBgkqhkiG9w0BAQUFADCBvzELMAkGA1UEBhMCREUxHDAaBgNV BAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5F QyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29i ZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MB4XDTA0MDYxODExNTMwOFoXDTA5MDYxNzExNTMwOFowgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQI FBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMg RXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUu bmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtDkMLBPOka7dGbNBjgrGJpBqT8HAhb1aTooyD79X RqJa+WvPu4V0gIEZVMqHJavcX4bFE8JVNapL1UQ9/0Dn0Mj1MUJLcW2tpLH7DwClB6LyJ1snQuq7 y1PPY7WBhHZ0QsgPnBAf13EgA23ds/f1yuANnMZjEImKVyKYWEAMSAcCAwEAAaOCASAwggEcMB0G A1UdDgQWBBToey/Xqhh5wIWyXTuD2C2M8QmjTTCB7AYDVR0jBIHkMIHhgBToey/Xqhh5wIWyXTuD 2C2M8QmjTaGBxaSBwjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJl cmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQL ExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJ KoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlggEAMAwGA1UdEwQFMAMBAf8wDQYJ KoZIhvcNAQEFBQADgYEAl+iKXdwBfdxQ8wWsN2Vb0M8wr/5BjwQc86yd5+bvuHkKaZjon4blh2X2 /IfEvvo6nKDxxlY45T+T2hW/sC9DUaYgWpUXJYpA98SGP4RaMSdQBwjtAM3xcRH5TtdG+PrJjKwW CbZOXfRAIa+YRIKBgjO0IowbZwsGQSiyPaRYFtcxggOlMIIDoQIBATBpMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDvDFMAkGBSsOAwIaBQCgggIRMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDYxNzA4MDg1NVowIwYJKoZIhvcN AQkEMRYEFDPBHICdfUkq9y9nvGR2z/rPQSrdMIHWBgkrBgEEAYI3EAQxgcgwgcUwgb8xCzAJBgNV BAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJn MRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMx GzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRA bmV0bGFiLm5lYy5kZQIBADCB2AYLKoZIhvcNAQkQAgsxgciggcUwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZQIBADANBgkqhkiG9w0BAQEFAASCAQCgpWVJPSijSv9WrO0VEN6Vcht/slq0sSCp/WxO16ce gEEXYK5nnxDFg22qhTMza//vfig24nk7vLwCeechY9I2y6dOMLrsZex08SkheP2lFssV/BOcZO0I 8amqVBi7JJJOO2xJbUAD5psOUHaXG1uh+Dak3olsQ9Z76qmBsV15t84a9g+pIkKeKacU+umHX8dc 34ZT2pCmf1SbvUis/1Fp0CH3Iaf+uQX1RAK725cX9r+mvwNOvaPgUFY97hAqDMXlkqKyB8r2DQJ5 jaz6llLwlVWYKLPsyJkU4a+2rRqVCUpGTCvLyZPB+ijmKGcV69XhyTQvHMnOYCYOlAz4idVYAAAA AAAA --Apple-Mail-8--1045385487-- --===============1070547434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1070547434==-- From hipsec-bounces@ietf.org Fri Jun 17 07:10:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05559 for ; Fri, 17 Jun 2005 07:10:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjEiq-0003nG-8C; Fri, 17 Jun 2005 07:09:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjEio-0003n6-GZ for hipsec@megatron.ietf.org; Fri, 17 Jun 2005 07:09:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05397 for ; Fri, 17 Jun 2005 07:09:10 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjF5s-0002WK-Gs for hipsec@ietf.org; Fri, 17 Jun 2005 07:33:05 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 2221F212C3C for ; Fri, 17 Jun 2005 14:08:34 +0300 (EEST) Message-ID: <42B2AF31.6040503@nomadiclab.com> Date: Fri, 17 Jun 2005 14:08:33 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Hipsec] Base draft - 17.6 preliminary version X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit The current version of the base draft is at http://hip4inter.net/drafts.php dated 170605. Please give all the input that you have for it. I'm planning to submit it to IETF next week. /Petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Sat Jun 18 01:32:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22019 for ; Sat, 18 Jun 2005 01:32:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVtc-0008Cg-Mm; Sat, 18 Jun 2005 01:29:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVta-0008CY-Pp for hipsec@megatron.ietf.org; Sat, 18 Jun 2005 01:29:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21863 for ; Sat, 18 Jun 2005 01:29:29 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjWGm-0000ES-V2 for hipsec@ietf.org; Sat, 18 Jun 2005 01:53:32 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EB21AD3D for ; Sat, 18 Jun 2005 07:29:04 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Jun 2005 07:29:03 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Jun 2005 07:29:03 +0200 Received: from [131.160.126.70] (rvi2-126-70.lmf.ericsson.se [131.160.126.70]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 64BDF2546 for ; Sat, 18 Jun 2005 08:29:03 +0300 (EEST) Message-ID: <42B3B11E.1060202@ericsson.com> Date: Sat, 18 Jun 2005 08:29:02 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2005 05:29:03.0785 (UTC) FILETIME=[A3BF0190:01C573C6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: [Hipsec] 63rd IETF in Paris - Important Meeting Dates X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit FYI: http://www.ietf.org/meetings/cutoff_dates_63.html Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 20 02:23:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27494 for ; Mon, 20 Jun 2005 02:23:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkFeV-0001j8-DE; Mon, 20 Jun 2005 02:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkFeT-0001iy-43 for hipsec@megatron.ietf.org; Mon, 20 Jun 2005 02:20:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26186 for ; Mon, 20 Jun 2005 02:20:56 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkG25-0008Eq-5f for hipsec@ietf.org; Mon, 20 Jun 2005 02:45:24 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id E23B02DA7; Mon, 20 Jun 2005 09:20:35 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id AB4182C46; Mon, 20 Jun 2005 09:20:34 +0300 (EEST) In-Reply-To: <42B27A49.7010007@nomadiclab.com> References: <75335f2e8cc57966fc019caa2a856f27@iki.fi> <42B27A49.7010007@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05a5073ebb3c3828ac5b1bf9935ab123@iki.fi> Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [Hipsec] Packet reordering, certificates and base exchange Date: Sun, 19 Jun 2005 23:20:38 -0700 To: Jukka Ylitalo X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 17, 2005, at 0:22, Jukka Ylitalo wrote: Jukka, >> The latest base-03-pre defines a control bit for both I2 and R2 to >> inform a peer to wait for shortly arriving certificate packets. >> However, I did not find any discussion how the peer should behave if >> a certificate packet arrives before I2/R2. Packet reordering is not >> anything rare in Internet, so it should be considered. >> >> From initiator's point of view, I think it just means that the >> responder's certificate packets should be cached for a short period >> of time. Someone else probably has a better understanding of the >> required time window, so I do not even try suggest any practical >> time. :-) >> >> However, introducing caching in responder is not an option due to the >> fact that it should remain stateless until it receives I2. As the >> initiator cannot enforce the I2 to arrive before the certificates, >> without a significant delay between I2 and certificate packets, I >> wonder if it might make sense to alter the I2 to optionally contain a >> number of certificate parameters. Then, initiator could actually send >> multiple I2s, each containing a different certificate, or a single I2 >> that possibly gets fragmented. If R2 gets the same enhancement, the >> certificate packet eventually becomes useless, I think. >> > How about adding the solved puzzle to each certificate packet (also > carried in the I2 packet) > going to the responder? The responder may establish a soft-state for > the certificate packets > after validating the puzzle, and release the state, if I2 does not > arrive in the assumed time frame. Adding the solved puzzle to CER packets seems to me to be the smallest possible change to overcome the problem. However, at the moment I'm unable to see if a) adding the puzzle has any additional side-effects, b) is it enough alone. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 20 11:15:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09005 for ; Mon, 20 Jun 2005 11:15:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNxp-00053w-1V; Mon, 20 Jun 2005 11:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNxn-00053P-39 for hipsec@megatron.ietf.org; Mon, 20 Jun 2005 11:13:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08891 for ; Mon, 20 Jun 2005 11:13:25 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkOLV-0004Bk-Sm for hipsec@ietf.org; Mon, 20 Jun 2005 11:37:59 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9F7DBD96D for ; Mon, 20 Jun 2005 17:29:56 +0200 (CEST) Received: from [10.1.1.112] ([10.1.1.112]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 17:14:32 +0200 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: References: Message-Id: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Mon, 20 Jun 2005 17:13:10 +0200 X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 20 Jun 2005 15:14:32.0630 (UTC) FILETIME=[C2FEDD60:01C575AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0035830384==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============0035830384== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--760728540; protocol="application/pkcs7-signature" --Apple-Mail-9--760728540 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, On Feb 15, 2005, at 18:51 , Teemu Koponen wrote: > > A new draft that is a spin-off from the rendezvous draft: > > Title : Host Identity Protocol (HIP) Registration Extension > Author(s) : T. Koponen, et al. > Filename : draft-koponen-hip-registration-00.txt > Pages : 13 > Date : 2005-2-14 we haven't received much feedback on this ID and would much appreciate if some WG people could take a look at it. (FWIW, it's only a few pages long! :-) Thanks, Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-9--760728540 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw7yUjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjE4MDczODIzWhcNMDYwNjE4MDczODIzWjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAwC64+CjRjFft0NL8szfPoms1+W/AsJ96uZ0SxhZXWynorOKPLaoCYWuE3a9SsUY5Pfj5 KQjMh6Dcv1F3LwQ/cdkiFzGBYkHU8IxKMjhZtCanKHTwyKC4Zhuy4pSArJUhsl/3z7FNKUaK7HXn JEfAvheuXQ7ve+vF+IF4uorvTmjQrvQJWjpJBIqgmya2GSnv7eZJIJmXE1sfCrVHes2eiLsxWNz+ ZB/N5h8v6NxxcrWcJa0C/IvMc2nH8dYwIk5++LV/0Ua2IDxWV/dodXxMxWoihkNUiMIZIDwgvITi 7eyStEddqzUFiTQtsasSfC2KQDrFu2J3IrdE2kkpOJ/unwIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAFxcPmBBZLSD6vhqZW 852TSPZfQZFNWg+y5lT/+Jbb5qlYjd6pTEYQIZ4I5JAcN1T8a5JkAU3ZKB0eP5mhFrptyHtpQ1hy KSq8BBF/RVFYt1Irz88+SgQ6L+1LT4lcgvxy4PGIQCLtqbvr0w29w/i7MGr+mUpjI+T1F+nKAI4m GTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMO8lIwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUwNjIwMTUxMzEyWjAjBgkqhkiG9w0BCQQxFgQU1MsjWlWhDT9SYk8RlGpb l451eJowgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBABIkMRWllVc39jKSqzqDLq2y4qNSnLHYfJgdI+gF+5n/+Z3Ejbt9JZuehnJJipNzluuniaAp S3OKBFChANMMWkZqPDxIYtEO77tp2DQDsQ9wkq6MZk8XDTLFC+e7K51aSveVmDKbHPqdNpB4uhsV vdEgEPQ/k3zVstH+MZkWXDw7iTtENuJczpY7ok9PswRKbiIIcShr7k4BBKddDc79g2IAftN/RHio UbKzoGZIHvAzcSBtNrxf+eWdB0GVxI4FBcTTASKNuIyV9iB89z/+VFoaoozDD/kGDqEfGhfJV6GZ OUKL0zuhV9RfW10iZP/71sjUC7aKWnX9Rl9F/2nxKR4AAAAAAAA= --Apple-Mail-9--760728540-- --===============0035830384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0035830384==-- From hipsec-bounces@ietf.org Mon Jun 20 13:17:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20011 for ; Mon, 20 Jun 2005 13:17:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPsK-0004jy-KL; Mon, 20 Jun 2005 13:15:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPsJ-0004jr-A6 for hipsec@megatron.ietf.org; Mon, 20 Jun 2005 13:15:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19873 for ; Mon, 20 Jun 2005 13:15:52 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkQG2-0007QI-4d for hipsec@ietf.org; Mon, 20 Jun 2005 13:40:28 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA29410; Mon, 20 Jun 2005 10:15:17 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5KHFHn29893; Mon, 20 Jun 2005 10:15:17 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 10:14:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Packet reordering, certificates and base exchange Date: Mon, 20 Jun 2005 10:14:13 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Packet reordering, certificates and base exchange Thread-Index: AcVyrEW6ZuEMHzwVRiyUWL+4cJZKhQDDmjow From: "Henderson, Thomas R" To: "Teemu Koponen" , X-OriginalArrivalTime: 20 Jun 2005 17:14:14.0657 (UTC) FILETIME=[7BD13710:01C575BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Teemu Koponen [mailto:tkoponen@iki.fi]=20 > Sent: Thursday, June 16, 2005 12:45 PM > To: hipsec@ietf.org > Subject: [Hipsec] Packet reordering, certificates and base exchange >=20 > All, >=20 > The latest base-03-pre defines a control bit for both I2 and R2 to=20 > inform a peer to wait for shortly arriving certificate packets.=20 > However, I did not find any discussion how the peer should=20 > behave if a=20 > certificate packet arrives before I2/R2. Packet reordering is not=20 > anything rare in Internet, so it should be considered. >=20 > From initiator's point of view, I think it just means that the=20 > responder's certificate packets should be cached for a short=20 > period of=20 > time. Someone else probably has a better understanding of the=20 > required=20 > time window, so I do not even try suggest any practical time. :-) >=20 > However, introducing caching in responder is not an option due to the=20 > fact that it should remain stateless until it receives I2. As the=20 > initiator cannot enforce the I2 to arrive before the certificates,=20 > without a significant delay between I2 and certificate packets, I=20 > wonder if it might make sense to alter the I2 to optionally contain a=20 > number of certificate parameters. Then, initiator could actually send=20 > multiple I2s, each containing a different certificate, or a single I2=20 > that possibly gets fragmented. If R2 gets the same enhancement, the=20 > certificate packet eventually becomes useless, I think. >=20 > Comments? >=20 I think it makes sense to add capability to include certificates in the base exchange packets. I'm not that sure it makes the utility of stand-alone CER packets go away, though. However, I would suggest that such a topic (using HIP with certificate infrastructure) could be separate work item for future, and not try to fix the base spec now with little experience on the approach. For that matter, I would probably be more in favor of taking out CER from the existing base spec rather than trying to improve its definition at this time. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Jun 21 16:32:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10022 for ; Tue, 21 Jun 2005 16:32:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp5A-0003jF-Cv; Tue, 21 Jun 2005 16:10:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp58-0003dE-Sh for hipsec@megatron.ietf.org; Tue, 21 Jun 2005 16:10:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29949 for ; Tue, 21 Jun 2005 16:10:48 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpT6-0000ks-8J for hipsec@ietf.org; Tue, 21 Jun 2005 16:35:37 -0400 Received: from inside.nomadiclab.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 3B533212C3C; Tue, 21 Jun 2005 23:10:27 +0300 (EEST) Date: Tue, 21 Jun 2005 23:10:27 +0300 (EEST) From: Petri Jokela To: "Henderson, Thomas R" Subject: RE: [Hipsec] Packet reordering, certificates and base exchange In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org On Mon, 20 Jun 2005, Henderson, Thomas R wrote: > However, I would suggest that such a topic (using HIP with certificate > infrastructure) could be separate work item for future, and not try to > fix the base spec now with little experience on the approach. For that > matter, I would probably be more in favor of taking out CER from the > existing base spec rather than trying to improve its definition at this > time. > > Tom We have now three options: 1) Try to fix the CER packet in base spec 2) Take it out and submit as a separate draft 3) Leave it as it is now 1) firstly, we should identify all the possibilities to fix the problem (some proposals exists) and secondly, validate the solutions. This requires time, and I think that we should avoid spending too much time on fixing things now. 2) is a quite easy-to-do procedure (at least removing it from the base specification). 3) is not an option, because the CER system is now broken. >From 1) and 2), I would vote for 2). /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Jun 21 16:35:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11894 for ; Tue, 21 Jun 2005 16:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp1X-0001LL-4C; Tue, 21 Jun 2005 16:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp1W-0001Kv-3A for hipsec@megatron.ietf.org; Tue, 21 Jun 2005 16:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28538 for ; Tue, 21 Jun 2005 16:07:03 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpPT-0000G2-Ls for hipsec@ietf.org; Tue, 21 Jun 2005 16:31:53 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CF7F92D4F; Tue, 21 Jun 2005 23:06:53 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A86822D44; Tue, 21 Jun 2005 23:06:52 +0300 (EEST) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [Hipsec] Packet reordering, certificates and base exchange Date: Tue, 21 Jun 2005 13:06:56 -0700 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 20, 2005, at 10:14, Henderson, Thomas R wrote: Tom, > I think it makes sense to add capability to include certificates in the > base exchange packets. I'm not that sure it makes the utility of > stand-alone CER packets go away, though. If CER packet was removed, all other packets should be able to carry CER parameter then I think. > However, I would suggest that such a topic (using HIP with certificate > infrastructure) could be separate work item for future, and not try to > fix the base spec now with little experience on the approach. For that > matter, I would probably be more in favor of taking out CER from the > existing base spec rather than trying to improve its definition at this > time. I agree, CER should be removed from the base specification. IMHO the current approach is anyway broken and thus requires further consideration. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Jun 21 21:30:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05471 for ; Tue, 21 Jun 2005 21:30:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dku0s-0003N6-09; Tue, 21 Jun 2005 21:26:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dku0r-0003N1-2v for hipsec@megatron.ietf.org; Tue, 21 Jun 2005 21:26:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05255 for ; Tue, 21 Jun 2005 21:26:43 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkuOp-0005XF-S7 for hipsec@ietf.org; Tue, 21 Jun 2005 21:51:35 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA16108 for ; Tue, 21 Jun 2005 18:26:26 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5M1QPn01399 for ; Tue, 21 Jun 2005 18:26:25 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 18:26:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] changes to base spec? Date: Tue, 21 Jun 2005 18:26:25 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095A46@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] changes to base spec? Thread-Index: AcVdHuQKafxTcUyjTHS8k+lid/1mLQAXxUHQBlKUxlA= From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 22 Jun 2005 01:26:25.0584 (UTC) FILETIME=[6808D300:01C576C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I reviewed Petri's recent draft with an eye towards making changes to align with the proposals in the Aura et al. paper that we discussed last month, but found that Petri had already made most of them. I still suggest a few changes below and have sent the diffs directly to Petri. Tom ** Proposal 1: Add nonce to I1 and to unsigned part of R1=20 Action: No list consensus on adding this. ** Proposal 2: Hash nonces I and J into key material Action: Petri already made the change to Section 6.4=20 ** Proposal 3/4/5: Changes to secure the cookie mechanism Action: Petri already updated the Appendix C to correspond to the=20 stronger cookie selection mechanism. However, there is leftover from the past some guidance in 4.1.1=20 (and also in the appendix itself) to explicitly recommend against using=20 the algorithm in Appendix C. I don't think that the guidance applies anymore-- I think that we would be fine if people implement Appendix C now, with the changes proposed. Also, there is still guidance in the Appendix to allow Responder to keep state about failed puzzles. I replaced that with the following: "The Responder SHOULD NOT keep state about failed puzzle solutions." Specific diffs provided to Petri. ** Proposal 6: Do not encrypt Initiator HI in I2 Action: Petri already made this a MAY (Section 5.3.3) ** Proposal 7a: Move from R2-SENT to Unassociated upon timeout Action: Per discussion on list, do not move to Unassociated upon timeout, but only after "Unused Association Lifetime" has been exceeded Define "Unused Association Lifetime" in the Definitions section. Specific text change in R2-SENT state: From: "If no data is received during an implementation specific time, move to UNASSOCIATED" To: "No packet sent/received during UAL minutes, send CLOSE and go to CLOSING." ** Proposal 7b, 7c, and 8: Tiebreaker rules for handshake packet collisions Action: Petri seems to already have made these changes. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 22 02:17:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13727 for ; Wed, 22 Jun 2005 02:17:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkyWI-0002qR-NG; Wed, 22 Jun 2005 02:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkyWG-0002qG-LO for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 02:15:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11067 for ; Wed, 22 Jun 2005 02:15:26 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkyuJ-0004A1-VF for hipsec@ietf.org; Wed, 22 Jun 2005 02:40:21 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 06E71212C3C; Wed, 22 Jun 2005 09:15:17 +0300 (EEST) In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Packet reordering, certificates and base exchange Date: Wed, 22 Jun 2005 09:15:19 +0300 To: Petri Jokela , David Ward , Gonzalo Camarillo X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > We have now three options: > > 1) Try to fix the CER packet in base spec > 2) Take it out and submit as a separate draft > 3) Leave it as it is now I think 2) is the best way to go now. I would go even a little bit further and merely define a code point (parameter type) for the certificate parameter, and state that the exact syntax, semantics, and use are to be defined elsewhere. That is, IMHO, we should include some text about certificates in the base spec lest the SEC ADs come to us and ask about this. If it is clear from the text that we have considered the situation and decided to leave it for later, that should be fine. Chairs, if the WG decided to take this way, it would be good to consider another milestone for the certificate spec. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 22 09:07:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06587 for ; Wed, 22 Jun 2005 09:07:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4qV-0002lG-CM; Wed, 22 Jun 2005 09:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4qP-0002kJ-4V for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 09:00:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05845 for ; Wed, 22 Jun 2005 09:00:39 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5EU-0006v3-0K for hipsec@ietf.org; Wed, 22 Jun 2005 09:25:37 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id C29AA212C64; Wed, 22 Jun 2005 16:00:18 +0300 (EEST) Message-ID: <42B960E2.3020400@nomadiclab.com> Date: Wed, 22 Jun 2005 16:00:18 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Packet reordering, certificates and base exchange References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pekka Nikander wrote: >> We have now three options: >> >> 1) Try to fix the CER packet in base spec >> 2) Take it out and submit as a separate draft >> 3) Leave it as it is now > > > I think 2) is the best way to go now. I would go even a little bit further > and merely define a code point (parameter type) for the certificate > parameter, > and state that the exact syntax, semantics, and use are to be defined > elsewhere. I admit that I haven't waited too long time after these comments, but I edited the draft and took certificates out. I left the CERT type definition and a short piece of text. The current pre version is available at http://hip4inter.net/drafts.php dated 220605. However, if there comes still need for the certificates in the base spec, it is not a big effort to put them back. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 22 09:15:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07670 for ; Wed, 22 Jun 2005 09:15:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4wK-000455-SJ; Wed, 22 Jun 2005 09:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4wG-00042w-Tj for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 09:06:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06538 for ; Wed, 22 Jun 2005 09:06:42 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5KO-000790-14 for hipsec@ietf.org; Wed, 22 Jun 2005 09:31:41 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 89634212C64; Wed, 22 Jun 2005 16:06:34 +0300 (EEST) In-Reply-To: <42B960E2.3020400@nomadiclab.com> References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> <42B960E2.3020400@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6dc19f1817df1d57a70045c938eb0b39@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [Hipsec] Packet reordering, certificates and base exchange Date: Wed, 22 Jun 2005 16:06:36 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >>> 1) Try to fix the CER packet in base spec >>> 2) Take it out and submit as a separate draft >>> 3) Leave it as it is now >> >> I think 2) is the best way to go now. I would go even a little bit=20= >> further >> and merely define a code point (parameter type) for the certificate >> parameter, >> and state that the exact syntax, semantics, and use are to be defined >> elsewhere. > > I admit that I haven't waited too long time after these comments, but = I > edited the draft and took certificates out. I left the CERT type > definition and a short piece of text. The current pre version is > available at > > http://hip4inter.net/drafts.php > > dated 220605. However, if there comes still need for the certificates=20= > in > the base spec, it is not a big effort to put them back. Ref [16]=A0(X.509) seems to be a leftover from this change. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 22 09:52:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11409 for ; Wed, 22 Jun 2005 09:52:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5d0-0008Gw-9P; Wed, 22 Jun 2005 09:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5cz-0008Gr-0E for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 09:50:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11271 for ; Wed, 22 Jun 2005 09:50:50 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl617-0000JK-4T for hipsec@ietf.org; Wed, 22 Jun 2005 10:15:49 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 723D6212C3C; Wed, 22 Jun 2005 16:50:43 +0300 (EEST) In-Reply-To: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v622) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Wed, 22 Jun 2005 16:50:45 +0300 To: Lars Eggert X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I read this document again, and in general it looks good to me. The language could be improved, now it is a little bit too "abstract" or fluffy to my taste. Changing some of the terminology and especially the definitions of terms would make it easier to read. Also considering advice from draft-iab-model-XX.txt might help. But content-wise, once a proper security considerations section is added, I think the document starts to be ready for a WG LC, though most probably we have to wait for the base spec to first advance to WG LC. Major detail: Did we discuss using exponential seconds instead of seconds for the lifetimes? I don't remember any more. In general, I'm in favour of fixed point exponential times instead of integer times... The parameter type values need to be checked against base-03. Can a reply include both REG_RESPONSE and REG_FAILED params if some of the registrations succeeded and some failed? Minor details: Sec 3, bullet 3: > 3. At this point, the registrar tries to authenticate the requester > based on currently available information. The details of this > authentication procedure are not specified in this document. If It would be good to be more specific in the second statement, and refer directly to the base spec. Also make the difference between authentication (as a part of the base exchange) vs. authorisation (which is a matter local to the registrar). Sec 3, second list, bullet 1: > exchanges or later announces its capabilities by sending the It might be good to discuss briefly when REG_INFO might be sent in an UPDATE; i.e., when the registrar changes its configuration. It would also be good to note that there may be a long time between R1 with REG_INFO and UPDATE with REG_REQUEST... Sec 3, second list, bullet 3: Please clarify the authenticate vs. authorise language. I think the first sentence uses authenticate while it should use authorise. Sec 3, 2nd para after second list: > Both the requester and > registrar can cancel the created registration before its expiration. I don't understand what that is trying to say. I guess this is part of the language being too abstract or fluffy... Or otherwise I just need more coffee.... Sec 4.2: > REG_REQUEST parameter is in an UPDATE packet, the registrar SHOULD > NOT modify the registrations of registration types which are not > listed in the parameter. Moreover, the requester SHOULD NOT include IMHO these "SHOULD NOT"s should be "MUST NOT"s.... In the former case, violating the rule would lead to inconsistent state (enough for a MUST), in the latter case apply the "be strict in what you sent (and liberal in what you expect) principle". > the parameter unless the registrar's I1 packet or an earlier > received s/an earlier/latest/ > signature. The requester SHOULD support inclusion of multiple > instances of the REG_REQUEST parameter in its I2 packets. What happens if it does not? Sec 4.3: > The registrar SHOULD include the REG_RESPONSE parameter in its R2 or > UPDATE packet only if a registration has successfully completed. I don't understand why we have here a "SHOULD"?? What is the rationale? Doesn't the registrar just include it if and only if the rgistration has been succesfully completed? Sec 4.4: > The registrar SHOULD include the REG_FAILED parameter in its R2 or > UPDATE packet if registering with registration types listed has not > completed successfully and a requester is asked to try again with > additional credentials. I don't understand the rationale for the SHOULD here either. Sec 5: > REG_RESPONSE parameters. Therefore, registration type definitions > MAY define dependencies for HIP parameters that are not defined in ... specifications that define different registration types and corresponding services MAY define ... --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 22 10:17:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14846 for ; Wed, 22 Jun 2005 10:17:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl618-0001iD-Iq; Wed, 22 Jun 2005 10:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl615-0001gD-Os for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 10:15:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14498 for ; Wed, 22 Jun 2005 10:15:45 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl6PD-0001E4-4g for hipsec@ietf.org; Wed, 22 Jun 2005 10:40:44 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 87996212C3C; Wed, 22 Jun 2005 17:15:27 +0300 (EEST) In-Reply-To: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> References: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v622) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9c54ce75535a0c4ee82aa997ea915e0b@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Fwd: I-D ACTION:draft-ietf-hip-rvs-02.txt Date: Wed, 22 Jun 2005 17:15:29 +0300 To: Lars Eggert X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Comments: Consider removing or greatly condensing the first two paragraphs from Introduction, and mostly replacing them with a reference to the arch document. I don't think this kind of architectural discussion belongs to this kind of a fairly-low-level protocol description. But YMMV. If you decide to make this change, also update the beginning of the third paragraph to reflect what is above in the new revision. If you want to have architectural discussion in the beginning, I would refer to the mobility discussion in the original Mobile IP(v4) architecture paper by Bhagwat, Tripathi and Perkins (1995), and discuss the need for a rendezvous point in the light of that (see the section about Location Directory). In the spirit of the above, I would also propose removing or rewriting the first paragraph of section 3. It looks like all text on how construct a proper R1 at the Responder end is missing, as well as how the Initiator verifies the received R1 with an VIA:RVS parameter. [12] needs to be a normative reference due to the text in section 3, third para after Figure 1. Minor: Sec 3.3: > If a HIP node and one of its rendezvous servers have a rendezvous > registration, the rendezvous servers MUST relay inbound I1 packets Why the "MUST" here? What danger is avoided? I would just say "servers relay" without the must. > Because of egress filtering on the path from the RVS to the client, > a > HIP rendezvous server MAY also need to replace the source IP > address, I think this "MAY" should be a "SHOULD", i.e., replacing the IP address is the RECOMMENDED way of doing it. Also update 4.4. to reflect this. > The RVS MUST verify the checksum field of an I1 packet doing any A missing "before" here? Also, the "MUST" should be a "SHOULD" because no danger to external nodes or security is involved if the RVS doesn't check the incoming checksum. Is there some text missing between the last and second last paras of Sec 3.3? I1 doesn't include SIG or HMAC paras, don't they? Sec 4.5: > When a rendezvous server receives an I1 whose destination HIT is not > its own, it MUST consult its registration database to find a > registration for the rendezvous service established by the HIT > owner. > If it finds an appropriate registration, it MUST relay the packet to > the registered IP address. If it does not find an appropriate > registration, is MUST drop the packet. Inappropriate "MUST"s (all three of them)? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Thu Jun 23 04:59:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18252 for ; Thu, 23 Jun 2005 04:59:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlNYQ-0000Pg-Tj; Thu, 23 Jun 2005 04:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlNYQ-0000Pb-0i for hipsec@megatron.ietf.org; Thu, 23 Jun 2005 04:59:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18228 for ; Thu, 23 Jun 2005 04:59:20 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlNwg-0008TW-EN for hipsec@ietf.org; Thu, 23 Jun 2005 05:24:28 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C16B8212C3C for ; Thu, 23 Jun 2005 11:58:47 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <7777cc9a3a59050808dadde38717da64@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: hipsec@ietf.org From: Pekka Nikander Date: Thu, 23 Jun 2005 11:58:50 +0300 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Hipsec] Puzzle hash function? X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit While reading the pre-version of the forthcoming -03 of the base spec, I realised that we now use a fixed hash algorithm for the puzzle, while we have the possibility of updating the HIT-generation hash function. Without thinking too much, I would propose that we define that the puzzle hash function is the same as used for generating the Responder's HIT. This change won't make it to -03, but anyway. Opinions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Thu Jun 23 08:27:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04052 for ; Thu, 23 Jun 2005 08:27:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQnS-0007bp-VO; Thu, 23 Jun 2005 08:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQnQ-0007bk-Sr for hipsec@megatron.ietf.org; Thu, 23 Jun 2005 08:27:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04012 for ; Thu, 23 Jun 2005 08:27:04 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlRBk-0000tT-AR for hipsec@ietf.org; Thu, 23 Jun 2005 08:52:13 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 876F1212CB2 for ; Thu, 23 Jun 2005 14:44:04 +0300 (EEST) Message-ID: <42BAA084.6020600@nomadiclab.com> Date: Thu, 23 Jun 2005 14:44:04 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Hipsec] Base draft -03 & ESP draft -00 submitted X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi all, I just submitted base draft version -03 and ESP draft version -00 to IETF. Drafts and diffs can also be found from: http://hip4inter.net/drafts.php BR, Petri (I will be on vacation until 25th of July) -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri Jun 24 09:43:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09063 for ; Fri, 24 Jun 2005 09:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloQc-0007jB-MI; Fri, 24 Jun 2005 09:41:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloQc-0007j5-31 for hipsec@megatron.ietf.org; Fri, 24 Jun 2005 09:41:06 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08827 for ; Fri, 24 Jun 2005 09:41:03 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69E03002EE1D8 for hipsec@lists.ietf.org; Fri, 24 Jun 2005 15:40:34 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] Fwd: I-D ACTION:draft-ietf-hip-rvs-02.txt User-Agent: KMail/1.8 References: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> <9c54ce75535a0c4ee82aa997ea915e0b@nomadiclab.com> In-Reply-To: <9c54ce75535a0c4ee82aa997ea915e0b@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline Date: Fri, 24 Jun 2005 15:41:52 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200506241541.52328.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pekka, Thanks for reviewing the draft. I agree with your comments, hence if no contradictory opinions are expressed, I will update the I-D accordingly. I have however one question regarding the validation of an R1. On Wednesday 22 June 2005 14:15, Pekka Nikander wrote: > > It looks like all text on how construct a proper R1 at the > Responder end is missing, as well as how the Initiator > verifies the received R1 with an VIA:RVS parameter. I will add text on how to construct a proper R1. Now concerning the validation of an incoming R1 in presence of a RVS, my understanding was that the VIA_RVS parameter was mainly intended to help debugging, and has only an informal nature and does not modify processing of the packet itself (hence its position after the signature in R1). Consequently I thought that processing an incoming R1 replying to a relayed I1 is no different from processing a "regular" R1. The base specification says: A system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., it is in state I1-SENT). Because the state is indexed by source and destination HI/HITs, and not IP address, I assume that we don't need specific text on how to handle an R1 when a RVS was involved in I1 delivery, with or without presence of a VIA_RVS parameter. Is that correct or I am missing something? Perhaps we might also want to consider the case where the responder want to securely assert its RVS IP address to the initiator, but I am really not sure about that. Any insights appreciated. Thanks. --julien -- julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Sat Jun 25 05:14:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09125 for ; Sat, 25 Jun 2005 05:14:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm6iR-000298-CX; Sat, 25 Jun 2005 05:12:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm6iQ-000292-BD for hipsec@megatron.ietf.org; Sat, 25 Jun 2005 05:12:42 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08975 for ; Sat, 25 Jun 2005 05:12:39 -0400 (EDT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A8680212C3C; Sat, 25 Jun 2005 12:12:09 +0300 (EEST) In-Reply-To: <200506241524.52846.julien.laganier@laposte.net> References: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> <9c54ce75535a0c4ee82aa997ea915e0b@nomadiclab.com> <200506241524.52846.julien.laganier@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Fwd: I-D ACTION:draft-ietf-hip-rvs-02.txt Date: Sat, 25 Jun 2005 12:12:12 +0300 To: Julien Laganier X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > Now concerning the validation of an incoming R1 in presence of a RVS, > my understanding was that the VIA_RVS parameter was mainly intended > to help debugging, and has only an informal nature and does not > modify processing of the packet itself (hence its position after the > signature in R1). Consequently I thought that processing an incoming > R1 replying to a relayed I1 is no different from processing a > "regular" R1. The base specification says: > > A system receiving an R1 MUST first check to see > if it has sent an I1 to the originator of the R1 > (i.e., it is in state I1-SENT). > > Because the state is indexed by source and destination HI/HITs, and > not IP address, I assume that we don't need specific text on how to > handle an R1 when a RVS was involved in I1 delivery, with or without > presence of a VIA_RVS parameter. > > Is that correct or I am missing something? Hmm. I can see some implementations checking also the IP fields in incoming R1s in order to weed out potential replay attacks. Hence, I think we should include a few sentences here stating the perhaps obvious: that incoming R1s SHOULD be verified based on state on HITs only, and if IP addresses are checked, also include RVS to the check.... Or what do you think? Perhaps I am missing something? > Perhaps we might also want > to consider the case where the responder want to securely assert its > RVS IP address to the initiator, but I am really not sure about that. Hmm. If we want add that, it should be in R2, I think. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 27 04:28:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23835 for ; Mon, 27 Jun 2005 04:28:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmov5-0000cr-Ek; Mon, 27 Jun 2005 04:24:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlaWI-0003KU-CD; Thu, 23 Jun 2005 18:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11140; Thu, 23 Jun 2005 18:49:59 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlaui-000267-BG; Thu, 23 Jun 2005 19:15:16 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DlaWH-0007zv-Bo; Thu, 23 Jun 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 23 Jun 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-Mailman-Approved-At: Mon, 27 Jun 2005 04:24:41 -0400 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-03.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-03.txt Pages : 96 Date : 2005-6-23 This memo specifies the details of the Host Identity Protocol (HIP). HIP provides a rapid exchange of Host Identities (public keys) between hosts and uses a Sigma-compliant [REF] Diffie-Hellman key exchange to establish shared secrets between such endpoints. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the-middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP) [24], it provides encryption and/or authentication protection for upper layer protocols such as TCP and UDP, while enabling continuity of communications across network layer address changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-23161104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-23161104.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@ietf.org Mon Jun 27 08:59:43 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17496 for ; Mon, 27 Jun 2005 08:59:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmt7r-0002zt-BX; Mon, 27 Jun 2005 08:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmt7p-0002zk-Ip for hipsec@megatron.ietf.org; Mon, 27 Jun 2005 08:54:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16887 for ; Mon, 27 Jun 2005 08:54:07 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmtWw-0003RO-Gm for hipsec@ietf.org; Mon, 27 Jun 2005 09:20:09 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DA1D1A9C; Mon, 27 Jun 2005 14:53:55 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 14:53:55 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 14:53:54 +0200 Received: from [131.160.126.95] (rvi2-126-95.lmf.ericsson.se [131.160.126.95]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 65706262D; Mon, 27 Jun 2005 15:53:54 +0300 (EEST) Message-ID: <42BFF6E1.3060302@ericsson.com> Date: Mon, 27 Jun 2005 15:53:53 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Packet reordering, certificates and base exchange References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2005 12:53:54.0916 (UTC) FILETIME=[469E2240:01C57B17] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, > Chairs, if the WG decided to take this way, it would be good to consider > another milestone for the certificate spec. yes, we would need to do that. In any case, our focus should still be on requesting the publication of the base and the ESP specs right after Paris. This means that we have a very tight deadline. Thanks, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 27 10:18:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25730 for ; Mon, 27 Jun 2005 10:18:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmuJu-0002jU-1a; Mon, 27 Jun 2005 10:10:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmuJr-0002ic-On for hipsec@megatron.ietf.org; Mon, 27 Jun 2005 10:10:39 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24315 for ; Mon, 27 Jun 2005 10:10:37 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69F97005D4084; Mon, 27 Jun 2005 16:10:00 +0200 From: Julien Laganier To: Pekka Nikander Date: Mon, 27 Jun 2005 16:11:21 +0000 User-Agent: KMail/1.8 References: <200506241524.52846.julien.laganier@laposte.net> <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> In-Reply-To: <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506271611.21480.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org Subject: [Hipsec] Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > > Because the state is indexed by source and destination HI/HITs, > > and not IP address, I assume that we don't need specific text on > > how to handle an R1 when a RVS was involved in I1 delivery, with > > or without presence of a VIA_RVS parameter. > > > > Is that correct or I am missing something? > > Hmm. I can see some implementations checking also the IP > fields in incoming R1s in order to weed out potential replay > attacks. Hence, I think we should include a few sentences here > stating the perhaps obvious: that incoming R1s SHOULD be verified > based on state on HITs only, and if IP addresses are checked, > also include RVS to the check.... > > Or what do you think? Perhaps I am missing something? No that is fine. Do you think we should have also a SHOULD requirement for the case where IP address are also checked? > > Perhaps we might also want > > to consider the case where the responder want to securely assert > > its RVS IP address to the initiator, but I am really not sure > > about that. > > Hmm. If we want add that, it should be in R2, I think. Ok. Not sure we want it, so I'll not consider it further. Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Jun 27 10:44:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29059 for ; Mon, 27 Jun 2005 10:44:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmupV-0000v0-T0; Mon, 27 Jun 2005 10:43:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmupU-0000uv-G3 for hipsec@megatron.ietf.org; Mon, 27 Jun 2005 10:43:20 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28981 for ; Mon, 27 Jun 2005 10:43:17 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69E80005F627F; Mon, 27 Jun 2005 16:42:48 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] Puzzle hash function? Date: Mon, 27 Jun 2005 16:44:10 +0000 User-Agent: KMail/1.8 References: <7777cc9a3a59050808dadde38717da64@nomadiclab.com> In-Reply-To: <7777cc9a3a59050808dadde38717da64@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506271644.10311.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Thursday 23 June 2005 08:58, Pekka Nikander wrote: > While reading the pre-version of the forthcoming -03 of the base > spec, I realised that we now use a fixed hash algorithm for the > puzzle, while we have the possibility of updating the > HIT-generation hash function. > > Without thinking too much, I would propose that we define that > the puzzle hash function is the same as used for generating the > Responder's HIT. > > This change won't make it to -03, but anyway. > > Opinions? FWIW I agree with the change you proposed. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Jun 28 07:52:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26939 for ; Tue, 28 Jun 2005 07:52:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEdP-00085X-Qa; Tue, 28 Jun 2005 07:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEdN-00085K-4d for hipsec@megatron.ietf.org; Tue, 28 Jun 2005 07:52:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26906 for ; Tue, 28 Jun 2005 07:52:07 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnF2b-00011K-1G for hipsec@ietf.org; Tue, 28 Jun 2005 08:18:20 -0400 Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69F970069BFEF; Tue, 28 Jun 2005 13:51:04 +0200 From: Julien Laganier To: hipsec@ietf.org, hipsec@ietf.org Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Tue, 28 Jun 2005 13:52:22 +0000 User-Agent: KMail/1.8 References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> In-Reply-To: <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506281352.23011.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: 7bit Cc: Lars Eggert X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Pekka, On Wednesday 22 June 2005 13:50, Pekka Nikander wrote: > I read this document again, and in general it looks good to me. Thanks for reviewing it. Please find answers, but also questions :) inlined below. > The language could be improved, now it is a little bit too > "abstract" or fluffy to my taste. Changing some of the terminology > and especially the definitions of terms would make it easier to > read. Also considering advice from draft-iab-model-XX.txt might > help. But content-wise, once a proper security considerations > section is added, I think the document starts to be ready > for a WG LC, though most probably we have to wait for the base spec > to first advance to WG LC. I will try to improve the terminology and definitions following advices from draft-iab-model-03.txt > Major detail: > > Did we discuss using exponential seconds instead of seconds for > the lifetimes? I don't remember any more. In general, I'm in > favour of fixed point exponential times instead of integer > times... I don't think we discussed them yet. Right now the specification uses 32-bits integer lifetimes, with a MUST minimum of 10s and a SHOULD maximum of 120s. First of all, even if we stick to integer lifetimes, I think we can at least reduce the field size from 32-bits (~136 years) to 16-bits (~18 hours), that it is still enough, in my opinion. Then yes, we can also use exponential times; with 8-bits fields (or perhaps even less, i.e. 4 bits) that would allow to pack most of the REG_* TLV parameter into 8-bytes. For instance: 4.1 REG_INFO 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min LifeT Exp | Max LifeT Exp | Reg Type #1 | Reg Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What does other people think about having a 2^(Lifetime exponent) lifetime then? > > Can a reply include both REG_RESPONSE and REG_FAILED params > if some of the registrations succeeded and some failed? > Yes. I tried to clarify the current wording, please see later below. > Minor details: > > Sec 3, bullet 3: > > 3. At this point, the registrar tries to authenticate the > > requester based on currently available information. The details > > of this authentication procedure are not specified in this > > document. If > > It would be good to be more specific in the second statement, and > refer directly to the base spec. Also make the difference between > authentication (as a part of the base exchange) vs. authorisation > (which is a matter local to the registrar). What about: At this point, the registrar is able to authenticate the requester based on the Host Identity it includes in I2. Then, it has to verify that this Host Identity is in fact authorized to register for the requested service(s), based on policy local to the registrar. The details of this authorization procedure are dependent on the type of the requested service(s) and on the registrar local policy, and are therefore not specified in this document. Then, the registrar includes in its R2 response a REG_RESPONSE parameter containing the service(s) type(s) for which the registration was authorized, and one or more REG_FAILED parameter containing the service(s) type(s) for which registration failed or was not authorized. In particular a REG_FAILED with a failure type of zero would contain the service(s) type(s) for which registration requires further credentials. > Sec 3, second list, bullet 1: > > exchanges or later announces its capabilities by sending > > the > > It might be good to discuss briefly when REG_INFO might be sent in > an UPDATE; i.e., when the registrar changes its configuration. > It would also be good to note that there may be a long time between > R1 with REG_INFO and UPDATE with REG_REQUEST... What about: A host that is capable and willing to act as a registrar includes a REG_INFO parameter in the R1 packets it sends during base exchanges, or later in an UPDATE packet when a change of its registar-related configuration occurs. > Sec 3, second list, bullet 3: > > Please clarify the authenticate vs. authorise language. I think > the first sentence uses authenticate while it should use authorise. How about: The registrar has to verify that the requester is in fact authorized to register for the requested service(s), based on policy local to the registrar. Then, the registrar includes in its UPDATE response a REG_RESPONSE parameter containing the service(s) type(s) for which the registration was authorized, and one or more REG_FAILED parameter containing the service(s) type(s) for which registration failed or was not authorized. In particular a REG_FAILED with a failure type of zero would contain the service(s) type(s) for which registration requires further credentials. > Sec 3, 2nd para after second list: > > Both the requester and registrar can cancel the created > > registration before its expiration. > > I don't understand what that is trying to say. I guess this is > part of the language being too abstract or fluffy... Or otherwise > I just need more coffee.... What about: Both the requester and registrar can cancel a registration before it expires, if the services afforded by this registration are no longer needed by the requester, or cannot be provided any longuer by the registrar (for instance because its configuration changed). > Sec 4.2: > > REG_REQUEST parameter is in an UPDATE packet, the registrar > > SHOULD NOT modify the registrations of registration types which > > are not listed in the parameter. Moreover, the requester SHOULD > > NOT include > > IMHO these "SHOULD NOT"s should be "MUST NOT"s.... In the former > case, violating the rule would lead to inconsistent state (enough > for a MUST), in the latter case apply the "be strict in what you > sent (and liberal in what you expect) principle". I'll make the change. > > the parameter unless the registrar's I1 packet or an earlier > > received > > s/an earlier/latest/ > > > signature. The requester SHOULD support inclusion of multiple > > instances of the REG_REQUEST parameter in its I2 packets. > > What happens if it does not? Hhmm... nothing :) So perhaps it is better to say: The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. > Sec 4.3: > > The registrar SHOULD include the REG_RESPONSE parameter in its > > R2 or UPDATE packet only if a registration has successfully > > completed. > > I don't understand why we have here a "SHOULD"?? What is the > rationale? Doesn't the registrar just include it if and only if the > rgistration has been succesfully completed? Yep. What about: The registrar include the REG_RESPONSE parameter in its R2 or UPDATE packet when a registration has successfully completed. And then if we apply the "be (strict in what you sent and) liberal in what you accept" principle once more, is it okay to modify the following paragraph like this: The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets, while the requester MUST be able to process one or more REG_REQUEST parameters in received R2 or UPDATE packets. > Sec 4.4: > > The registrar SHOULD include the REG_FAILED parameter in its > > R2 or UPDATE packet if registering with registration types listed > > has not completed successfully and a requester is asked to try > > again with additional credentials. > > I don't understand the rationale for the SHOULD here either. So let's remove it. > Sec 5: > > REG_RESPONSE parameters. Therefore, registration type > > definitions MAY define dependencies for HIP parameters that are > > not defined in > > ... specifications that define different registration types and > corresponding services MAY define ... I'll make the change. Thank you very much for your comments, it surely helps to improve the document. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Jun 28 07:53:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26993 for ; Tue, 28 Jun 2005 07:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEcw-0007zO-Il; Tue, 28 Jun 2005 07:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEcu-0007zJ-D0 for hipsec@megatron.ietf.org; Tue, 28 Jun 2005 07:51:42 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26886 for ; Tue, 28 Jun 2005 07:51:38 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69F970069BFEF; Tue, 28 Jun 2005 13:51:04 +0200 From: Julien Laganier To: hipsec@ietf.org, hipsec@ietf.org Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Tue, 28 Jun 2005 13:52:22 +0000 User-Agent: KMail/1.8 References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> In-Reply-To: <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506281352.23011.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: Lars Eggert X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Pekka, On Wednesday 22 June 2005 13:50, Pekka Nikander wrote: > I read this document again, and in general it looks good to me. Thanks for reviewing it. Please find answers, but also questions :) inlined below. > The language could be improved, now it is a little bit too > "abstract" or fluffy to my taste. Changing some of the terminology > and especially the definitions of terms would make it easier to > read. Also considering advice from draft-iab-model-XX.txt might > help. But content-wise, once a proper security considerations > section is added, I think the document starts to be ready > for a WG LC, though most probably we have to wait for the base spec > to first advance to WG LC. I will try to improve the terminology and definitions following advices from draft-iab-model-03.txt > Major detail: > > Did we discuss using exponential seconds instead of seconds for > the lifetimes? I don't remember any more. In general, I'm in > favour of fixed point exponential times instead of integer > times... I don't think we discussed them yet. Right now the specification uses 32-bits integer lifetimes, with a MUST minimum of 10s and a SHOULD maximum of 120s. First of all, even if we stick to integer lifetimes, I think we can at least reduce the field size from 32-bits (~136 years) to 16-bits (~18 hours), that it is still enough, in my opinion. Then yes, we can also use exponential times; with 8-bits fields (or perhaps even less, i.e. 4 bits) that would allow to pack most of the REG_* TLV parameter into 8-bytes. For instance: 4.1 REG_INFO 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min LifeT Exp | Max LifeT Exp | Reg Type #1 | Reg Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What does other people think about having a 2^(Lifetime exponent) lifetime then? > > Can a reply include both REG_RESPONSE and REG_FAILED params > if some of the registrations succeeded and some failed? > Yes. I tried to clarify the current wording, please see later below. > Minor details: > > Sec 3, bullet 3: > > 3. At this point, the registrar tries to authenticate the > > requester based on currently available information. The details > > of this authentication procedure are not specified in this > > document. If > > It would be good to be more specific in the second statement, and > refer directly to the base spec. Also make the difference between > authentication (as a part of the base exchange) vs. authorisation > (which is a matter local to the registrar). What about: At this point, the registrar is able to authenticate the requester based on the Host Identity it includes in I2. Then, it has to verify that this Host Identity is in fact authorized to register for the requested service(s), based on policy local to the registrar. The details of this authorization procedure are dependent on the type of the requested service(s) and on the registrar local policy, and are therefore not specified in this document. Then, the registrar includes in its R2 response a REG_RESPONSE parameter containing the service(s) type(s) for which the registration was authorized, and one or more REG_FAILED parameter containing the service(s) type(s) for which registration failed or was not authorized. In particular a REG_FAILED with a failure type of zero would contain the service(s) type(s) for which registration requires further credentials. > Sec 3, second list, bullet 1: > > exchanges or later announces its capabilities by sending > > the > > It might be good to discuss briefly when REG_INFO might be sent in > an UPDATE; i.e., when the registrar changes its configuration. > It would also be good to note that there may be a long time between > R1 with REG_INFO and UPDATE with REG_REQUEST... What about: A host that is capable and willing to act as a registrar includes a REG_INFO parameter in the R1 packets it sends during base exchanges, or later in an UPDATE packet when a change of its registar-related configuration occurs. > Sec 3, second list, bullet 3: > > Please clarify the authenticate vs. authorise language. I think > the first sentence uses authenticate while it should use authorise. How about: The registrar has to verify that the requester is in fact authorized to register for the requested service(s), based on policy local to the registrar. Then, the registrar includes in its UPDATE response a REG_RESPONSE parameter containing the service(s) type(s) for which the registration was authorized, and one or more REG_FAILED parameter containing the service(s) type(s) for which registration failed or was not authorized. In particular a REG_FAILED with a failure type of zero would contain the service(s) type(s) for which registration requires further credentials. > Sec 3, 2nd para after second list: > > Both the requester and registrar can cancel the created > > registration before its expiration. > > I don't understand what that is trying to say. I guess this is > part of the language being too abstract or fluffy... Or otherwise > I just need more coffee.... What about: Both the requester and registrar can cancel a registration before it expires, if the services afforded by this registration are no longer needed by the requester, or cannot be provided any longuer by the registrar (for instance because its configuration changed). > Sec 4.2: > > REG_REQUEST parameter is in an UPDATE packet, the registrar > > SHOULD NOT modify the registrations of registration types which > > are not listed in the parameter. Moreover, the requester SHOULD > > NOT include > > IMHO these "SHOULD NOT"s should be "MUST NOT"s.... In the former > case, violating the rule would lead to inconsistent state (enough > for a MUST), in the latter case apply the "be strict in what you > sent (and liberal in what you expect) principle". I'll make the change. > > the parameter unless the registrar's I1 packet or an earlier > > received > > s/an earlier/latest/ > > > signature. The requester SHOULD support inclusion of multiple > > instances of the REG_REQUEST parameter in its I2 packets. > > What happens if it does not? Hhmm... nothing :) So perhaps it is better to say: The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. > Sec 4.3: > > The registrar SHOULD include the REG_RESPONSE parameter in its > > R2 or UPDATE packet only if a registration has successfully > > completed. > > I don't understand why we have here a "SHOULD"?? What is the > rationale? Doesn't the registrar just include it if and only if the > rgistration has been succesfully completed? Yep. What about: The registrar include the REG_RESPONSE parameter in its R2 or UPDATE packet when a registration has successfully completed. And then if we apply the "be (strict in what you sent and) liberal in what you accept" principle once more, is it okay to modify the following paragraph like this: The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets, while the requester MUST be able to process one or more REG_REQUEST parameters in received R2 or UPDATE packets. > Sec 4.4: > > The registrar SHOULD include the REG_FAILED parameter in its > > R2 or UPDATE packet if registering with registration types listed > > has not completed successfully and a requester is asked to try > > again with additional credentials. > > I don't understand the rationale for the SHOULD here either. So let's remove it. > Sec 5: > > REG_RESPONSE parameters. Therefore, registration type > > definitions MAY define dependencies for HIP parameters that are > > not defined in > > ... specifications that define different registration types and > corresponding services MAY define ... I'll make the change. Thank you very much for your comments, it surely helps to improve the document. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue Jun 28 07:59:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27680 for ; Tue, 28 Jun 2005 07:59:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEi8-0000xu-3r; Tue, 28 Jun 2005 07:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEi5-0000xp-W1 for hipsec@megatron.ietf.org; Tue, 28 Jun 2005 07:57:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27373 for ; Tue, 28 Jun 2005 07:57:00 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnF7Q-0001Vl-EN for hipsec@ietf.org; Tue, 28 Jun 2005 08:23:13 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 201AD149FE; Tue, 28 Jun 2005 14:15:23 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 13:58:22 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id E1A3E12F372; Tue, 28 Jun 2005 13:56:46 +0200 (CEST) In-Reply-To: <200506281352.23011.julien.IETF@laposte.net> References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> <200506281352.23011.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <71712981-E8F5-4E99-A9C7-FF9D8A3108F1@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Tue, 28 Jun 2005 13:56:44 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 28 Jun 2005 11:58:22.0495 (UTC) FILETIME=[AEC0CAF0:01C57BD8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0643289302==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============0643289302== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-54--81315462; protocol="application/pkcs7-signature" --Apple-Mail-54--81315462 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On 2005-6-28, at 15:52 , Julien Laganier wrote: >> Major detail: >> >> Did we discuss using exponential seconds instead of seconds for >> the lifetimes? I don't remember any more. In general, I'm in >> favour of fixed point exponential times instead of integer >> times... ... > Then yes, we can also use exponential times; with 8-bits fields (or > perhaps even less, i.e. 4 bits) that would allow to pack most of the > REG_* TLV parameter into 8-bytes. For instance: ... > What does other people think about having a 2^(Lifetime exponent) > lifetime then? In a recent tcpm draft, we used a "granularity" bit, i.e.: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind = X | Length = 4 |G| User Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Granularity (1 bit) Granularity bit, indicating the granularity of the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout" field MUST be interpreted as minutes. Otherwise (G = 0), the time interval in the "User Timeout" field MUST be interpreted as seconds. User Timeout (15 bits) Specifies the user timeout suggestion for this connection. It MUST be interpreted as a 15-bit unsigned integer. The granularity of the timeout (minutes or seconds) depends on the "G" field. This may be another choice in this case as well. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-54--81315462 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw7yUjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjE4MDczODIzWhcNMDYwNjE4MDczODIzWjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAwC64+CjRjFft0NL8szfPoms1+W/AsJ96uZ0SxhZXWynorOKPLaoCYWuE3a9SsUY5Pfj5 KQjMh6Dcv1F3LwQ/cdkiFzGBYkHU8IxKMjhZtCanKHTwyKC4Zhuy4pSArJUhsl/3z7FNKUaK7HXn JEfAvheuXQ7ve+vF+IF4uorvTmjQrvQJWjpJBIqgmya2GSnv7eZJIJmXE1sfCrVHes2eiLsxWNz+ ZB/N5h8v6NxxcrWcJa0C/IvMc2nH8dYwIk5++LV/0Ua2IDxWV/dodXxMxWoihkNUiMIZIDwgvITi 7eyStEddqzUFiTQtsasSfC2KQDrFu2J3IrdE2kkpOJ/unwIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAFxcPmBBZLSD6vhqZW 852TSPZfQZFNWg+y5lT/+Jbb5qlYjd6pTEYQIZ4I5JAcN1T8a5JkAU3ZKB0eP5mhFrptyHtpQ1hy KSq8BBF/RVFYt1Irz88+SgQ6L+1LT4lcgvxy4PGIQCLtqbvr0w29w/i7MGr+mUpjI+T1F+nKAI4m GTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMO8lIwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUwNjI4MTE1NjQ1WjAjBgkqhkiG9w0BCQQxFgQU6BRmFEULmBBDwhF8UpHn sqUeiQ8wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAGV8R6iifgO2iEvzcUlqjaD91ibHIKmBe3xm7PZoS3NymwU3CftYFV8UVQNTL5VI8O5ZO877 7vRc9WWmMPm+U25KYehkShKfjIFbgcIA/CHSMJJtQ250zzOod6LfDHv2WopnwGtTGPWbKQ/MUIc6 81Vjc0NMb0V9R1JWDzxTWe/MTL7uVRtYa3JKEPTz9Ot9kX3cukx798kQLk1/Td4M7hfBguJX6nWu adcYlas5qqJlXU1iEpa1lCVaVRMgeKQymoAq4QjxIxHIlL/kDZWHrVpF1KRr04astDk0/wtv0Wdk ZM64lL329zXt3OpEz787/0y1OiUTa4u/5ewvhbg+ZjoAAAAAAAA= --Apple-Mail-54--81315462-- --===============0643289302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0643289302==-- From hipsec-bounces@ietf.org Tue Jun 28 08:03:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28561 for ; Tue, 28 Jun 2005 08:03:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEiP-00010O-KR; Tue, 28 Jun 2005 07:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEiO-00010H-EL for hipsec@megatron.ietf.org; Tue, 28 Jun 2005 07:57:20 -0400 Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27403 for ; Tue, 28 Jun 2005 07:57:18 -0400 (EDT) Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 201AD149FE; Tue, 28 Jun 2005 14:15:23 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 13:58:22 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id E1A3E12F372; Tue, 28 Jun 2005 13:56:46 +0200 (CEST) In-Reply-To: <200506281352.23011.julien.IETF@laposte.net> References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> <200506281352.23011.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <71712981-E8F5-4E99-A9C7-FF9D8A3108F1@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Tue, 28 Jun 2005 13:56:44 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 28 Jun 2005 11:58:22.0495 (UTC) FILETIME=[AEC0CAF0:01C57BD8] Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0677899077==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============0677899077== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-54--81315462; protocol="application/pkcs7-signature" --Apple-Mail-54--81315462 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On 2005-6-28, at 15:52 , Julien Laganier wrote: >> Major detail: >> >> Did we discuss using exponential seconds instead of seconds for >> the lifetimes? I don't remember any more. In general, I'm in >> favour of fixed point exponential times instead of integer >> times... ... > Then yes, we can also use exponential times; with 8-bits fields (or > perhaps even less, i.e. 4 bits) that would allow to pack most of the > REG_* TLV parameter into 8-bytes. For instance: ... > What does other people think about having a 2^(Lifetime exponent) > lifetime then? In a recent tcpm draft, we used a "granularity" bit, i.e.: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind = X | Length = 4 |G| User Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Granularity (1 bit) Granularity bit, indicating the granularity of the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout" field MUST be interpreted as minutes. Otherwise (G = 0), the time interval in the "User Timeout" field MUST be interpreted as seconds. User Timeout (15 bits) Specifies the user timeout suggestion for this connection. It MUST be interpreted as a 15-bit unsigned integer. The granularity of the timeout (minutes or seconds) depends on the "G" field. This may be another choice in this case as well. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-54--81315462 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw7yUjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjE4MDczODIzWhcNMDYwNjE4MDczODIzWjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAwC64+CjRjFft0NL8szfPoms1+W/AsJ96uZ0SxhZXWynorOKPLaoCYWuE3a9SsUY5Pfj5 KQjMh6Dcv1F3LwQ/cdkiFzGBYkHU8IxKMjhZtCanKHTwyKC4Zhuy4pSArJUhsl/3z7FNKUaK7HXn JEfAvheuXQ7ve+vF+IF4uorvTmjQrvQJWjpJBIqgmya2GSnv7eZJIJmXE1sfCrVHes2eiLsxWNz+ ZB/N5h8v6NxxcrWcJa0C/IvMc2nH8dYwIk5++LV/0Ua2IDxWV/dodXxMxWoihkNUiMIZIDwgvITi 7eyStEddqzUFiTQtsasSfC2KQDrFu2J3IrdE2kkpOJ/unwIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAFxcPmBBZLSD6vhqZW 852TSPZfQZFNWg+y5lT/+Jbb5qlYjd6pTEYQIZ4I5JAcN1T8a5JkAU3ZKB0eP5mhFrptyHtpQ1hy KSq8BBF/RVFYt1Irz88+SgQ6L+1LT4lcgvxy4PGIQCLtqbvr0w29w/i7MGr+mUpjI+T1F+nKAI4m GTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMO8lIwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUwNjI4MTE1NjQ1WjAjBgkqhkiG9w0BCQQxFgQU6BRmFEULmBBDwhF8UpHn sqUeiQ8wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAGV8R6iifgO2iEvzcUlqjaD91ibHIKmBe3xm7PZoS3NymwU3CftYFV8UVQNTL5VI8O5ZO877 7vRc9WWmMPm+U25KYehkShKfjIFbgcIA/CHSMJJtQ250zzOod6LfDHv2WopnwGtTGPWbKQ/MUIc6 81Vjc0NMb0V9R1JWDzxTWe/MTL7uVRtYa3JKEPTz9Ot9kX3cukx798kQLk1/Td4M7hfBguJX6nWu adcYlas5qqJlXU1iEpa1lCVaVRMgeKQymoAq4QjxIxHIlL/kDZWHrVpF1KRr04astDk0/wtv0Wdk ZM64lL329zXt3OpEz787/0y1OiUTa4u/5ewvhbg+ZjoAAAAAAAA= --Apple-Mail-54--81315462-- --===============0677899077== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0677899077==-- From hipsec-bounces@ietf.org Wed Jun 29 13:55:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dngmc-0000cw-QT for hip-archive@megatron.ietf.org; Wed, 29 Jun 2005 13:55:34 -0400 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17903 for ; Wed, 29 Jun 2005 13:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dngld-0000Qz-Qk; Wed, 29 Jun 2005 13:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnglc-0000Qu-Ho for hipsec@megatron.ietf.org; Wed, 29 Jun 2005 13:54:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17863 for ; Wed, 29 Jun 2005 13:54:31 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnhBC-0000Wh-Oe for hipsec@ietf.org; Wed, 29 Jun 2005 14:21:00 -0400 Message-ID: <08d601c57cd3$c86541b0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Wed, 29 Jun 2005 10:55:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [Hipsec] BOF at IETF 63 on Network-based Localized Mobility Management X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Phil Roberts and I are organizing a BOF on network based localized mobility management (netlmm) for IETF 63. The idea is to provide support in the local access network for mobility management so that a mobile node doesn't have to change its IP address so frequently. The BOF description is at: http://www.geocities.com/kempf42/netlmm-bof.txt There's a mailing list: netlmm@ngnet.it https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm, to subscribe Currently, the list is being used by co-authors of the problem statement and requirements drafts, but please subscribe and join in discussion if you would like. Please don't respond to this message, since any discussion on the proposed BOF should be on the BOF list. The problem statement draft is available from the Internet Drafts repository: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=13248 The requirements draft is about complete and will be posted to the Internet Drafts repository by the end of the week. I'll send email to the list about it when its posted. Phil and I are working on a proposed WG charter, we'll post the charter to the list when its complete. jak _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed Jun 29 17:01:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnjgk-0004pv-OK for hip-archive@megatron.ietf.org; Wed, 29 Jun 2005 17:01:42 -0400 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25273 for ; Wed, 29 Jun 2005 17:01:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnjcz-0004Je-JM; Wed, 29 Jun 2005 16:57:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnjcx-0004Il-NO for hipsec@megatron.ietf.org; Wed, 29 Jun 2005 16:57:48 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24916 for ; Wed, 29 Jun 2005 16:57:44 -0400 (EDT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 79BC0212C4E; Wed, 29 Jun 2005 23:57:12 +0300 (EEST) In-Reply-To: <200506271611.21480.julien.IETF@laposte.net> References: <200506241524.52846.julien.laganier@laposte.net> <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> <200506271611.21480.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 29 Jun 2005 22:57:10 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org Subject: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>> Because the state is indexed by source and destination HI/HITs, >>> and not IP address, I assume that we don't need specific text on >>> how to handle an R1 when a RVS was involved in I1 delivery, with >>> or without presence of a VIA_RVS parameter. >>> >>> Is that correct or I am missing something? >> >> Hmm. I can see some implementations checking also the IP >> fields in incoming R1s in order to weed out potential replay >> attacks. Hence, I think we should include a few sentences here >> stating the perhaps obvious: that incoming R1s SHOULD be verified >> based on state on HITs only, and if IP addresses are checked, >> also include RVS to the check.... >> >> Or what do you think? Perhaps I am missing something? > > No that is fine. Do you think we should have also a SHOULD requirement > for the case where IP address are also checked? FWIW, I think that the base spec should simply say that when matching an incoming R1, the IP addresses SHOULD be ignored and the match SHOULD be based on HITs only. Of course, that is usually impossible for opportunistic connections, though. The RVS spec could then state that if an implementation checks the IP addresses anyway, it MUST check for an VIA_RVS parameter and use that for matching. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec