From hipsec-bounces@ietf.org Sun May 1 03:44: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 DAA02229 for ; Sun, 1 May 2005 03:44: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 1DS92F-0001KO-53; Sun, 01 May 2005 03:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS92D-0001KE-Nk for hipsec@megatron.ietf.org; Sun, 01 May 2005 03:38:37 -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 DAA02008 for ; Sun, 1 May 2005 03:38:36 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DS9Fd-0002J5-Sk for hipsec@ietf.org; Sun, 01 May 2005 03:52:30 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j417cTh5029121 for ; Sun, 1 May 2005 09:38:29 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 09:38:29 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 09:38:29 +0200 Received: from [131.160.126.43] (rvi2-126-43.lmf.ericsson.se [131.160.126.43]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EA6F518AAA for ; Sun, 1 May 2005 10:38:28 +0300 (EEST) Message-ID: <42748773.4060103@ericsson.com> Date: Sun, 01 May 2005 10:38:27 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) 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: 01 May 2005 07:38:29.0584 (UTC) FILETIME=[C4B1E500:01C54E20] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: [Hipsec] TEST, please ignore 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 Testing the new HIP WG mailing list. Please ignore this message. Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun May 1 03:56:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02729 for ; Sun, 1 May 2005 03:56:35 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id F269A7307; Sun, 1 May 2005 03:56:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by honor.icsalabs.com (Postfix) with ESMTP id 5B3D47305 for ; Sun, 1 May 2005 03:55:07 -0400 (EDT) Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j417sfh5000034; Sun, 1 May 2005 09:54:45 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 09:54:41 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 09:54:40 +0200 Received: from [131.160.126.43] (rvi2-126-43.lmf.ericsson.se [131.160.126.43]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 419F718AAA; Sun, 1 May 2005 10:54:40 +0300 (EEST) Message-ID: <42748B3E.6010707@ericsson.com> From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Cc: David Ward , Pekka Nikander , Thomas Henderson Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2005 07:54:41.0071 (UTC) FILETIME=[07BF0BF0:01C54E23] Subject: [Hipsec] MAILING LIST MIGRATION Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 01 May 2005 10:54:38 +0300 Date: Sun, 01 May 2005 10:54:38 +0300 Content-Transfer-Encoding: 7bit Folks, at this point, we are moving the official mailing list of the HIP WG to a server at ietf.org. To send messages to the new mailing list, use the following address: hipsec@ietf.org From now on, do not use hipsec@honor.trusecure.com. This mailing list will be shut down shortly. We have migrated all the subscribers in this list to the new list. In any case, if you notice that your address did not make it to the new list for some reason, you can manually subscribe to the new list using the link below: https://www1.ietf.org/mailman/listinfo/hipsec Make sure you configure your incoming email filters appropriately. We will migrate the current archives to the ietf.org server shortly as well. Regards, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From mailman-bounces@ietf.org Sun May 1 05:32:40 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 FAA07983 for ; Sun, 1 May 2005 05:32: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 1DSAZf-0000At-QB for hip-archive@lists.ietf.org; Sun, 01 May 2005 05:17:15 -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: Sun, 01 May 2005 05:02:38 -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 mailman-bounces@ietf.org Sun May 1 05:40: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 FAA09319 for ; Sun, 1 May 2005 05:40: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 1DSAZf-0000At-QB for hip-archive@lists.ietf.org; Sun, 01 May 2005 05:17:15 -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: Sun, 01 May 2005 05:02:38 -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 ticsa-info-admin@honor.trusecure.com Sun May 1 11:01:18 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27031 for ; Sun, 1 May 2005 11:01:18 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 33CAB731A for ; Sun, 1 May 2005 11:00:47 -0400 (EDT) Date: Sun, 01 May 2005 11:00:47 -0400 Message-ID: <20050501150047.29750.70523.Mailman@honor> Subject: honor.trusecure.com mailing list memberships reminder From: mailman-owner@honor.icsalabs.com To: hip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: ticsa-info-admin@honor.trusecure.com Errors-To: ticsa-info-admin@honor.trusecure.com X-BeenThere: ticsa-info@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk This is a reminder, sent out once a month, about your honor.trusecure.com 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, hipsec-request@honor.trusecure.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@honor. Thanks! Passwords for hip-archive@lists.ietf.org: List Password // URL ---- -------- hipsec@honor.trusecure.com fewefo http://honor.trusecure.com/mailman/options/hipsec/hip-archive%40lists.ietf.org From hipsec-admin@honor.trusecure.com Tue May 3 13:59:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15755 for ; Tue, 3 May 2005 13:59:35 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5CA2F7324; Tue, 3 May 2005 13:59:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from havana.ucdavis.edu (havana.ucdavis.edu [169.237.104.156]) by honor.icsalabs.com (Postfix) with ESMTP id 8E0D87303 for ; Tue, 3 May 2005 13:58:29 -0400 (EDT) Received: from lymeon.ucdavis.edu (lymeon.ucdavis.edu [169.237.104.171]) by havana.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j43HwQQI023947 for ; Tue, 3 May 2005 10:58:27 -0700 (PDT) Received: from lymeon.ucdavis.edu (localhost [127.0.0.1]) by lymeon.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j43HwQ27004985 for ; Tue, 3 May 2005 10:58:26 -0700 (PDT) Received: (from www@localhost) by lymeon.ucdavis.edu (8.12.10/8.12.9/Submit) id j43HwQXr004984; Tue, 3 May 2005 10:58:26 -0700 (PDT) Message-Id: <200505031758.j43HwQXr004984@lymeon.ucdavis.edu> To: hipsec@honor.trusecure.com 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 Subject: [Hipsec] Call for Paper: JSAC-MRNM Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 3 May 2005 10:58:26 -0700 (PDT) Date: Tue, 3 May 2005 10:58:26 -0700 (PDT) PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY 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 1, 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@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon May 9 13:26:15 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 NAA09093 for ; Mon, 9 May 2005 13:26:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVByg-0005dm-5a; Mon, 09 May 2005 13:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVBye-0005dh-Ny for hipsec@megatron.ietf.org; Mon, 09 May 2005 13:23:32 -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 NAA08722 for ; Mon, 9 May 2005 13:23:29 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVCDm-0001DA-UW for hipsec@ietf.org; Mon, 09 May 2005 13:39:12 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA03218; Mon, 9 May 2005 10:23:18 -0700 (PDT) Received: from XCH-NWBH-02.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 j49HNHG16356; Mon, 9 May 2005 12:23:17 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 10:23:17 -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, 9 May 2005 10:23:17 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7EE3@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: more clarifications to the base draft Thread-Index: AcVUu8lknZvzg/GrSUSlNVYXk3PZZQ== From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" X-OriginalArrivalTime: 09 May 2005 17:23:17.0435 (UTC) FILETIME=[C9FD10B0:01C554BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] more clarifications to the base draft 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 Petri, I have some comments/suggestions after reviewing the packet formats and packet processing sections of the base draft, while going over our implementation. Checksum - It's a little confusing that the HIP header's IPV6 next header should be IPPROTO_NONE=3D59 but when computing the HIP checksum the = pseudo-header is IPPROTO_HIP=3D99. These values make sense though, so I'm not = suggesting any changes. General note: may want to consistently write "Initiator" versus "initiator", and "Responder" versus "responder" TLV format - mentions transport formats using values 2048 to 4095 "Currently, one transport format is defined: the ESP transport format [23]." What does this mean, since ESP does not use parameters that are 2048-4095? HIP_TRANSFORM Although it says there are 6 maximum suite IDs, this is for the R1, and the I2 HIP_TRANSFORM contains 1 maximum suite ID (the chosen suite actually used in the I2.) HMAC Can there be both types of ECHO_REQUESTs (covered/not covered by HMAC+SIG) in a HIP packet? In the section on the I2 Packet, the "either" hints at there being only one possible type, but I think this came up once during an interop. CER The description for this packet seems unclear and may need to be rewritten. These two statements seem slightly contradictory: (Processing incoming I1) Under no circumstances does the HIP state machine transition upon sending an R1. (R1 management) An implementation MAY keep state about received I1s and match the received I2s against the state, as discussed in Section 4.1.1. Instead of RFC 2451, when referring to AES we probably want RFC 3602. (RFC 2451 is older and contains no mention of AES.) -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed May 11 08:46:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00030 for ; Wed, 11 May 2005 08:46:34 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 263C97360; Wed, 11 May 2005 08:46:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (unknown [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id E6A9672F2 for ; Wed, 11 May 2005 08:45:49 -0400 (EDT) Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 82BD5212C90; Wed, 11 May 2005 15:45:40 +0300 (EEST) Message-ID: <4281FE74.2030207@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrei Gurtov Cc: hipsec@honor.trusecure.com, Tuomas Aura Subject: Re: [Hipsec] changes to base spec? References: <426C950A.3020706@cs.helsinki.fi> In-Reply-To: <426C950A.3020706@cs.helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 11 May 2005 15:45:40 +0300 Date: Wed, 11 May 2005 15:45:40 +0300 Content-Transfer-Encoding: 7bit Andrei Gurtov wrote: > Hi, > > Tuomas and Aarthi wrote a paper on the Analysis of the HIP Base Exchange > Protocol that will appear in ACISP'05, July 2005. > http://www.cs.helsinki.fi/u/gurtov/papers/analysis_hip.pdf > > They suggest several changes to the HIP specs for improving security. Do > you think we should adopt any of the changes for the base spec? Few comments: Problem 1 & solution: Adding the nonce to I1 and R1 is not a big problem, but I currently can't see much help of it. The attacker should know when the I1 is sent from the initiator and send the R1 at a suitable moment. The attacker, being not on the path, does not know when the I1 is sent, so it must just guess when to attack. Maybe there are cases, when this is easy to do and I just can't see them now... If the attacker is on the path, it gets the nonce in I1, in which case there is naturally no protection from that. Problem 2 & solution: Adding the I and J to the initial hash input for generating the keying material can be done. But this affects also the possible rekeying done later. The I and J values have to be stored for that purpose. Currently, we don't have to store them. Is this a problem from the implementation point of view? Problems 3&4: These seems to affect mostly on the appendix part of the document. No comments from me at the moment. Problem 5 & solution: Fine with me. Problem 6 & solution: "Do not encrypt the Initiator HI". We could make the encryption optional, still providing the possibility to encrypt the HI. How does this sound? Problem 7 & solution: Moving from R2-SENT to UNASSOCIATED during timeout seems to be ok (+ HIT comparisons). Problem 8 & solution: This seems to be ok also. I have received a lot of reformatted text from Tom and Jeff and try to get a pre version of 03 out soon. I will also make some changes to the draft based on above issues. /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@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri May 13 08:18:18 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 IAA08818 for ; Fri, 13 May 2005 08:18:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZ5z-0007zW-I4; Fri, 13 May 2005 08:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZ5x-0007zQ-5U for hipsec@megatron.ietf.org; Fri, 13 May 2005 08:16:45 -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 IAA08723 for ; Fri, 13 May 2005 08:16:43 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWZLq-0004XI-Cm for hipsec@ietf.org; Fri, 13 May 2005 08:33:12 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7EE2E2E62; Fri, 13 May 2005 15:16:32 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id DDF282E40; Fri, 13 May 2005 15:16:30 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j4DCGUc23196; Fri, 13 May 2005 15:16:30 +0300 (EEST) Date: Fri, 13 May 2005 15:16:30 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Petri Jokela Subject: Re: [Hipsec] changes to base spec? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.3-niksula20040914 (2005-04-27) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.3-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: hipsec@ietf.org, Tuomas Aura 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 Wed, 11 May 2005, Petri Jokela wrote: > Problem 1 & solution: > > Adding the nonce to I1 and R1 is not a big problem, but I currently > can't see much help of it. The attacker should know when the I1 is sent > from the initiator and send the R1 at a suitable moment. The attacker, > being not on the path, does not know when the I1 is sent, so it must > just guess when to attack. Maybe there are cases, when this is easy to > do and I just can't see them now... > > If the attacker is on the path, it gets the nonce in I1, in which case > there is naturally no protection from that. Agree, seems like this is rather difficult to achieve in practice because there are so many obstacles for the attack (prebuilt R1 lifetime, prebuilt R1 indexing based on IP addreses, guessing the proper attack time, expiration time of existing SAs). Maybe it should be at least mentioned in the appendix. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri May 13 09:08:12 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 JAA12700 for ; Fri, 13 May 2005 09:08:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZry-0007fb-OR; Fri, 13 May 2005 09:06:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZrx-0007fS-Sk for hipsec@megatron.ietf.org; Fri, 13 May 2005 09:06: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 JAA12450 for ; Fri, 13 May 2005 09:06:19 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWa7s-0006U9-Ek for hipsec@ietf.org; Fri, 13 May 2005 09:22:50 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id EE856212C90 for ; Fri, 13 May 2005 16:06:08 +0300 (EEST) Message-ID: <4284A640.9010705@nomadiclab.com> Date: Fri, 13 May 2005 16:06:08 +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 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Subject: [Hipsec] Pre-version: ESP and Base drafts 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 Folks, Pre-versions of both the HIP ESP and Base drafts are available at http://hip4inter.net/drafts.php draft-ietf-hip-base-03-pre130505 draft-ietf-hip-esp-00-pre130505 I didn't make diffs to previous versions, because the changes were so big= . Base draft: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The draft has been modified quite a lot since -02, b=FAt the changes are mostly related to the structure of the document. The old one was difficult to read and understand, and the new structure should be better. Thanks to Tom for the main work. I have made some modifications to the draft based on Aura's comments in their research paper. There haven't been too much discussion on the list about the proposed changes. Please read and comment now: Problem 2: the KEYMAT generation has now been modified so that I and J values are also included in the keying material generation. Due to possible rekeying, implementations must now keep the I and J values as long as the HIP association exists. Problem 6: The HI encryption is now optional. Problem 7 & 8: modifications to state machine and to packet handlings (processing I1 and I2 packets). I have not yet done anything related to problems 1, 3, 4, and 5. Please, give comments on those. Problems 3,4, and 5 seem to affect the appendix describing puzzles. ESP draft: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There are no conceptual packets any longer. Basic idea is now roughly: 1) Create HIP association as well as ESP association during base exchange (ESP SA can be with NULL encryption). This would be mandatory, and solves the problem how data packets are identified. In previous version when the ESP SA could be setup later, you couln't identify data packets after base exchange, if no ESP SA was set up (no SPIs to look at). 2) Use UPDATE to make ESP SA update, including change in transform family and rekeying. Rekeying: UPDATE(ESP_INFO, [DH]) -----------------------> UPDATE(ESP_INFO, [DH]) <----------------------- Transform update UPDATE(ESP_INFO, ESP_TRANSFORM, [DH]) ---------------------------------------> UPDATE(ESP_INFO, ESP_TRANSFORM, [DH]) <--------------------------------------- And UPDATE acks naturally in both cases. There can still be conflicting things due to big changes. Please read=20 and comment. /petri --=20 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 May 16 14:45:12 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 OAA22264 for ; Mon, 16 May 2005 14:45: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 1DXkZU-0002ur-OR; Mon, 16 May 2005 14:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkZT-0002uV-0H for hipsec@megatron.ietf.org; Mon, 16 May 2005 14:44:07 -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 OAA22132 for ; Mon, 16 May 2005 14:44:05 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXkq3-00081S-Lb for hipsec@ietf.org; Mon, 16 May 2005 15:01:16 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA17390; Mon, 16 May 2005 13:43:51 -0500 (CDT) Received: from XCH-NWBH-02.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 j4GIhoN17040; Mon, 16 May 2005 11:43:50 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 11:43:49 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Pre-version: ESP and Base drafts Date: Mon, 16 May 2005 11:42:55 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7EF0@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Pre-version: ESP and Base drafts Thread-Index: AcVXvN4hX1rcmzMyS/6hX5au2aDPuwCiHVvQ From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" , X-OriginalArrivalTime: 16 May 2005 18:43:49.0656 (UTC) FILETIME=[331BB980:01C55A47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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 have some comments after reviewing the esp-00 draft, please see below. = I think it looks a lot better now without the conceptual packets. Petri, = I'll send an xml diff of typos/minor edits separately. - section "ESP packet processing" "As these mechanisms can be located..." - this sentence is unclear to = me, but I do not have a suggested rewrite. - For all AES references (3 occurrences), RFC 2451 should be RFC 3602; = RFC 2451 contains no mention of AES, should be removed from references - 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. - For the sentence "...exchange information about the used protocols and = other...", is there another term besides "used protocols" that should be = used here, such as "transforms used"? - the key index field of the ESP_INFO parameter is mentioned for the = rekeying section, but not in the preceding section when discussing the = ESP_INFO. - When talking about the IP address to HIT conversion, what about the = IPv4 case? Should LSIs be mentioned also? - In the "finalizing rekeying" section it says to use the lowest Keymat = Index of the two ESP_INFO parameters, but earlier in the = "transform_reply" section, is says "it is RECOMMENDED that the system = use the greater value received from the peer" ??? - It should be noted somewhere that HIP packets should bypass IPsec = policies, i.e. UPDATE packet transmitted in the clear even though an = active association is in place, or all protocol 99 packets bypass IPsec = processing, etc. -Jeff > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Friday, May 13, 2005 6:06 AM > To: hipsec@ietf.org > Subject: [Hipsec] Pre-version: ESP and Base drafts >=20 >=20 > Folks, >=20 > Pre-versions of both the HIP ESP and Base drafts are available at >=20 > http://hip4inter.net/drafts.php >=20 > draft-ietf-hip-base-03-pre130505 > draft-ietf-hip-esp-00-pre130505 >=20 > I didn't make diffs to previous versions, because the changes=20 > were so big. >=20 >=20 > Base draft: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The draft has been modified quite a lot since -02, b=FAt the changes > are mostly related to the structure of the document. The old one was > difficult to read and understand, and the new structure should be > better. Thanks to Tom for the main work. >=20 > I have made some modifications to the draft based on Aura's=20 > comments in > their research paper. There haven't been too much discussion=20 > on the list > about the proposed changes. Please read and comment now: >=20 > Problem 2: the KEYMAT generation has now been modified so that I and J > values are also included in the keying material generation. Due to > possible rekeying, implementations must now keep the I and J values > as long as the HIP association exists. >=20 > Problem 6: The HI encryption is now optional. >=20 > Problem 7 & 8: modifications to state machine and to packet handlings > (processing I1 and I2 packets). >=20 > I have not yet done anything related to problems 1, 3, 4, and=20 > 5. Please, > give comments on those. Problems 3,4, and 5 seem to affect=20 > the appendix > describing puzzles. >=20 >=20 > ESP draft: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > There are no conceptual packets any longer. Basic idea is now > roughly: >=20 > 1) Create HIP association as well as ESP association during base > exchange (ESP SA can be with NULL encryption). >=20 > This would be mandatory, and solves the problem how data packets are > identified. In previous version when the ESP SA could be setup later, > you couln't identify data packets after base exchange, if no=20 > ESP SA was > set up (no SPIs to look at). >=20 > 2) Use UPDATE to make ESP SA update, including change in transform > family and rekeying. >=20 > Rekeying: > UPDATE(ESP_INFO, [DH]) > -----------------------> >=20 > UPDATE(ESP_INFO, [DH]) > <----------------------- >=20 > Transform update > UPDATE(ESP_INFO, ESP_TRANSFORM, [DH]) > ---------------------------------------> >=20 > UPDATE(ESP_INFO, ESP_TRANSFORM, [DH]) > <--------------------------------------- >=20 > And UPDATE acks naturally in both cases. >=20 > There can still be conflicting things due to big changes. Please read=20 > and comment. >=20 > /petri >=20 > --=20 > 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 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon May 16 15:16:27 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 PAA26879 for ; Mon, 16 May 2005 15:16:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXl19-0000ZB-QZ; Mon, 16 May 2005 15: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 1DXl18-0000Z6-35 for hipsec@megatron.ietf.org; Mon, 16 May 2005 15:12:42 -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 PAA26215 for ; Mon, 16 May 2005 15:12:40 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlHh-0000xE-Tp for hipsec@ietf.org; Mon, 16 May 2005 15:29:51 -0400 Received: from [192.168.1.50] (194.2.144.31) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309D501ACD36D for hipsec@ietf.org; Mon, 16 May 2005 21:12:30 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <4281FE74.2030207@nomadiclab.com> In-Reply-To: <4281FE74.2030207@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 16 May 2005 21:13:11 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200505162113.11273.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Hi, On Wednesday 11 May 2005 14:45, Petri Jokela wrote: > Andrei Gurtov wrote: > > Hi, > > > > Tuomas and Aarthi wrote a paper on the Analysis of the HIP Base > > Exchange Protocol that will appear in ACISP'05, July 2005. > > http://www.cs.helsinki.fi/u/gurtov/papers/analysis_hip.pdf > > > > They suggest several changes to the HIP specs for improving > > security. Do you think we should adopt any of the changes for the > > base spec? > > Few comments: > > Problem 1 & solution: > > Adding the nonce to I1 and R1 is not a big problem, but I currently > can't see much help of it. The attacker should know when the I1 is > sent from the initiator and send the R1 at a suitable moment. The > attacker, being not on the path, does not know when the I1 is sent, > so it must just guess when to attack. Maybe there are cases, when > this is easy to do and I just can't see them now... > > If the attacker is on the path, it gets the nonce in I1, in which > case there is naturally no protection from that. There is a related problem when an opportunistic initiator tries to reach a node via its rendezvous server. The initiator sends an I1 to the NULL destination HIT at the RVS IP address, which relays it to the responder. If the responder replies an R1 directly to the initiator, there's currently no way for the initiator to identify the correct context, apart from the RVS IP address included in an optional VIA_RVS parameter. A similar problem exists if an opportunistic initiator which accept from an off-path attacker an R1 containing its HIT and a LOCATOR parameter pointing to its own location (like below in the figure 10 excerpted from hip-mm-01). Having nonce in I1/R1 would help w.r.t. to this scenario, and can be implemented with ECHO_REQUEST in I1, and an ECHO_REPLY placed after the R1's SIGNATURE. What do you think? Thanks. --julien ---------------------------------------------------------------- Initiator Responder R1 with LOCATOR <----------------------------------- record additional addresses change responder address I2 with new SPI in SPI parameter -----------------------------------> (process R2 normally) <----------------------------------- (process normally) Figure 10: LOCATOR inclusion in R1 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue May 17 15:46:50 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 PAA01760 for ; Tue, 17 May 2005 15:46:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wz-0006l5-Ei; Tue, 17 May 2005 15:41:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wy-0006l0-7k for hipsec@megatron.ietf.org; Tue, 17 May 2005 15:41:56 -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 PAA01302 for ; Tue, 17 May 2005 15:41:53 -0400 (EDT) Received: from localhost (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id 69C6B212C40; Tue, 17 May 2005 22:41:23 +0300 (EEST) From: Jan Mikael Melen To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? Date: Tue, 17 May 2005 22:41:03 +0300 User-Agent: KMail/1.7.1 References: <426C950A.3020706@cs.helsinki.fi> <4281FE74.2030207@nomadiclab.com> <200505162113.11273.julien.IETF@laposte.net> In-Reply-To: <200505162113.11273.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505172241.11952.Jan.Melen@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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, On Monday 16 May 2005 22:13, Julien Laganier wrote: > > There is a related problem when an opportunistic initiator tries to > reach a node via its rendezvous server. > > The initiator sends an I1 to the NULL destination HIT at the RVS IP > address, which relays it to the responder. If the responder replies > an R1 directly to the initiator, there's currently no way for the > initiator to identify the correct context, apart from the RVS IP > address included in an optional VIA_RVS parameter. You are probably referring to a case where RVS acts as an sentinel node for a farm of servers. This is really a special case but yes you have a valid point that in order this kind of scenario to work you would need a nonce. Perhaps the solution would be to add optional ECHO_REQUEST to I1 and a ECHO_RESPONSE that is outside the signature to R1 as you suggested. If this kind of scenario should be supported at all? Normally the destination HITs of these computer farms are probably well known. > A similar problem exists if an opportunistic initiator which accept > from an off-path attacker an R1 containing its HIT and a LOCATOR > parameter pointing to its own location (like below in the figure 10 > excerpted from hip-mm-01). Still the off-path attacker would have to know the source IP address and the HIT of the node that is sending the I1 with NULL HIT and also the timing must be correct. One can't just randomly send the R1's because if the host has not sent a I1 it will drop the packet and if the destination HIT is wrong it should drop the packet so the probability of getting these right is not really that big unless the attacker is on the path when even the nonce doesn't protect you. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue May 17 16:10:28 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 QAA09502 for ; Tue, 17 May 2005 16:10:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wq-0006kX-5c; Tue, 17 May 2005 15:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wn-0006gh-VB for hipsec@megatron.ietf.org; Tue, 17 May 2005 15:41:46 -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 PAA01284 for ; Tue, 17 May 2005 15:41:42 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8Da-0002bS-CY for hipsec@ietf.org; Tue, 17 May 2005 15:59:07 -0400 Received: from localhost (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id 69C6B212C40; Tue, 17 May 2005 22:41:23 +0300 (EEST) From: Jan Mikael Melen To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? Date: Tue, 17 May 2005 22:41:03 +0300 User-Agent: KMail/1.7.1 References: <426C950A.3020706@cs.helsinki.fi> <4281FE74.2030207@nomadiclab.com> <200505162113.11273.julien.IETF@laposte.net> In-Reply-To: <200505162113.11273.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505172241.11952.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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, On Monday 16 May 2005 22:13, Julien Laganier wrote: > > There is a related problem when an opportunistic initiator tries to > reach a node via its rendezvous server. > > The initiator sends an I1 to the NULL destination HIT at the RVS IP > address, which relays it to the responder. If the responder replies > an R1 directly to the initiator, there's currently no way for the > initiator to identify the correct context, apart from the RVS IP > address included in an optional VIA_RVS parameter. You are probably referring to a case where RVS acts as an sentinel node for a farm of servers. This is really a special case but yes you have a valid point that in order this kind of scenario to work you would need a nonce. Perhaps the solution would be to add optional ECHO_REQUEST to I1 and a ECHO_RESPONSE that is outside the signature to R1 as you suggested. If this kind of scenario should be supported at all? Normally the destination HITs of these computer farms are probably well known. > A similar problem exists if an opportunistic initiator which accept > from an off-path attacker an R1 containing its HIT and a LOCATOR > parameter pointing to its own location (like below in the figure 10 > excerpted from hip-mm-01). Still the off-path attacker would have to know the source IP address and the HIT of the node that is sending the I1 with NULL HIT and also the timing must be correct. One can't just randomly send the R1's because if the host has not sent a I1 it will drop the packet and if the destination HIT is wrong it should drop the packet so the probability of getting these right is not really that big unless the attacker is on the path when even the nonce doesn't protect you. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 18 01:02: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 BAA26792 for ; Wed, 18 May 2005 01:02: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 1DYGfy-0000yP-SA; Wed, 18 May 2005 01:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGfx-0000yK-7o for hipsec@megatron.ietf.org; Wed, 18 May 2005 01:00:57 -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 BAA26648 for ; Wed, 18 May 2005 01:00:56 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYGwo-0002cL-Ux for hipsec@ietf.org; Wed, 18 May 2005 01:18:24 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D18AE89879; Wed, 18 May 2005 08:00:44 +0300 (EEST) Message-ID: <428ACC07.60000@piuha.net> Date: Wed, 18 May 2005 08:00:55 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org, "Petri Jokela (JO/LMF)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: [Hipsec] some hip base spec nits 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 Some nits that I noticed while reading the spec (looking at draft-ietf-hip-base-03-pre130505 version): > NAI Network Access Identifier, in binary > format. The > format of the NAI is login@FQDN. A reference to draft-ietf-radext-rfc2486bis-05.txt would be useful here. And I'm not sure what the "binary format" of the NAI is... suggest "Network Access Identifier [ref]." > This needs to be changed to "full3978" (and a possible update to the xml2rfc tool). > > 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 |C| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > / Contents / > / +-+-+-+-+-+-+-+-+ > | | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type field is 15 bits according to this... and then later: > | | | | | > | HMAC | 65245 | 20 | HMAC based message | > | | | | authentication code, with | > | | | | key material from | > | | | | HIP_TRANSFORM | > Which seems to assume its at least 16 bits. Perhaps the picture is misaligned somehow? I think it should be 16 bits and the length field should be correspondingly smaller. --Jari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 18 07:39:25 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 HAA08366 for ; Wed, 18 May 2005 07:39: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 1DYMsX-0007IO-4d; Wed, 18 May 2005 07:38:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYMsV-0007IJ-72 for hipsec@megatron.ietf.org; Wed, 18 May 2005 07:38:19 -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 HAA08291 for ; Wed, 18 May 2005 07:38:17 -0400 (EDT) Received: from kulho194.adsl.netsonic.fi ([81.17.193.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYN9Q-0007se-Hi for hipsec@ietf.org; Wed, 18 May 2005 07:55:50 -0400 Received: from [192.168.1.175] (n175.local.pnr.iki.fi [192.168.1.175]) by kulho194.adsl.netsonic.fi (8.13.1/8.13.1) with ESMTP id j4IBbwXe008250; Wed, 18 May 2005 14:38:01 +0300 (EEST) (envelope-from pekka.nikander@nomadiclab.com) In-Reply-To: <428ACC07.60000@piuha.net> References: <428ACC07.60000@piuha.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] some hip base spec nits Date: Wed, 18 May 2005 14:37:52 +0300 To: Jari Arkko X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, "Petri Jokela \(JO/LMF\)" 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 >> >> 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 |C| Length >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | >> | >> / Contents >> / >> / >> +-+-+-+-+-+-+-+-+ >> | | Padding >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type field is 15 bits according to this... and then later: > >> | | | | >> | >> | HMAC | 65245 | 20 | HMAC based message >> | >> | | | | authentication code, with >> | >> | | | | key material from >> | >> | | | | HIP_TRANSFORM >> | >> > > Which seems to assume its at least 16 bits. Perhaps the picture > is misaligned somehow? I think it should be 16 bits and the length > field should be correspondingly smaller. The C bit is counted as a part of the type. Probably a sentence somewhere is needed to clarify this. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 18 07:45:18 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 HAA08841 for ; Wed, 18 May 2005 07:45:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYMvw-000084-6S; Wed, 18 May 2005 07:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYMvv-000079-7q for hipsec@megatron.ietf.org; Wed, 18 May 2005 07:41:51 -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 HAA08640 for ; Wed, 18 May 2005 07:41:49 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYNCq-00082y-Uz for hipsec@ietf.org; Wed, 18 May 2005 07:59:22 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EE89C89869; Wed, 18 May 2005 14:41:39 +0300 (EEST) Message-ID: <428B29FE.5060104@piuha.net> Date: Wed, 18 May 2005 14:41:50 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] some hip base spec nits References: <428ACC07.60000@piuha.net> <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> In-Reply-To: <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, "Petri Jokela \(JO/LMF\)" 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: > The C bit is counted as a part of the type. Probably a sentence > somewhere > is needed to clarify this. Ok, that explains it. The spec may well have text about this but I just missed that. --Jari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 18 08:33: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 IAA12818 for ; Wed, 18 May 2005 08:33: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 1DYNfh-0006Le-L1; Wed, 18 May 2005 08:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYNff-0006LZ-D6 for hipsec@megatron.ietf.org; Wed, 18 May 2005 08:29:08 -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 IAA12435 for ; Wed, 18 May 2005 08:29:05 -0400 (EDT) Received: from kulho194.adsl.netsonic.fi ([81.17.193.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYNwb-0002VJ-Q1 for hipsec@ietf.org; Wed, 18 May 2005 08:46:38 -0400 Received: from [192.168.1.175] (n175.local.pnr.iki.fi [192.168.1.175]) by kulho194.adsl.netsonic.fi (8.13.1/8.13.1) with ESMTP id j4ICSuQe008311; Wed, 18 May 2005 15:28:56 +0300 (EEST) (envelope-from pekka.nikander@nomadiclab.com) In-Reply-To: <200505172241.11952.Jan.Melen@nomadiclab.com> References: <426C950A.3020706@cs.helsinki.fi> <4281FE74.2030207@nomadiclab.com> <200505162113.11273.julien.IETF@laposte.net> <200505172241.11952.Jan.Melen@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] changes to base spec? Date: Wed, 18 May 2005 15:28:50 +0300 To: Jan Mikael Melen X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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 Monday 16 May 2005 22:13, Julien Laganier wrote: >> >> There is a related problem when an opportunistic initiator tries to >> reach a node via its rendezvous server. >> >> The initiator sends an I1 to the NULL destination HIT at the RVS IP >> address, which relays it to the responder. If the responder replies >> an R1 directly to the initiator, there's currently no way for the >> initiator to identify the correct context, apart from the RVS IP >> address included in an optional VIA_RVS parameter. I think we should forbid that behavior. Firstly, if the destination HIT is NULL then the rendezvous server cannot reliably know to which destination the I1 is really intended to, unless it is serving just a single destination host. IMHO the right way forward here is to state (in the rendezvous doc) that if you want to support rvs with NULL dest HITs, then the return R1 *MUST* go through the rendezvous server and appear coming from the rendezvous server's IP address. Or am I missing something? > You are probably referring to a case where RVS acts as an sentinel > node for a > farm of servers. This is really a special case but yes you have a > valid point > that in order this kind of scenario to work you would need a nonce. > Perhaps > the solution would be to add optional ECHO_REQUEST to I1 and a > ECHO_RESPONSE > that is outside the signature to R1 as you suggested. If this kind of > scenario should be supported at all? Normally the destination HITs of > these > computer farms are probably well known. I have no objection in adding *optional* (for Initiator) support for that. Apparently, the support in the Responder should be RECOMMENDED or REQUIRED. I'd be in favor of making it RECOMMENDED, meaning that the Initiator must be prepared to receive an R1 without an ECHO_RESPONSE even if they sent an ECHO_REQUEST in I1. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 18 08:35: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 IAA13124 for ; Wed, 18 May 2005 08:35: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 1DYNjt-0007G5-AV; Wed, 18 May 2005 08:33:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYNjs-0007FC-Ie for hipsec@megatron.ietf.org; Wed, 18 May 2005 08:33:28 -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 IAA12844 for ; Wed, 18 May 2005 08:33:27 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYO0o-0002jU-Eg for hipsec@ietf.org; Wed, 18 May 2005 08:50:59 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id CB615212C40; Wed, 18 May 2005 15:33:16 +0300 (EEST) Message-ID: <428B360C.702@nomadiclab.com> Date: Wed, 18 May 2005 15:33:16 +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] some hip base spec nits References: <428ACC07.60000@piuha.net> <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> In-Reply-To: <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, "Petri Jokela \(JO/LMF\)" 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: >>> >>> 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 |C| Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> / Contents / >>> / +-+-+-+-+-+-+-+-+ >>> | | Padding | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Type field is 15 bits according to this... and then later: >> >>> | | | | | >>> | HMAC | 65245 | 20 | HMAC based message | >>> | | | | authentication code, with | >>> | | | | key material from | >>> | | | | HIP_TRANSFORM | >>> >> >> Which seems to assume its at least 16 bits. Perhaps the picture >> is misaligned somehow? I think it should be 16 bits and the length >> field should be correspondingly smaller. > > > The C bit is counted as a part of the type. Probably a sentence somewhere > is needed to clarify this. The C-bit definition covers it, but is not clear. Is it enough if I add the following to Type definition: Type Type code for the parameter. 16 bits long, C-bit being part of the Type code. C Critical. One if this parameter is critical, and MUST be recognized by the recipient, zero otherwise. The C bit is considered to be a part of the Type field. Consequently, critical parameters are always odd and non-critical ones have an even value. /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 May 18 08:48: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 IAA14466 for ; Wed, 18 May 2005 08:48: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 1DYNtR-00024p-ET; Wed, 18 May 2005 08: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 1DYNtO-00024k-60 for hipsec@megatron.ietf.org; Wed, 18 May 2005 08:43: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 IAA13825 for ; Wed, 18 May 2005 08:43:16 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYOAJ-0003Gp-Uc for hipsec@ietf.org; Wed, 18 May 2005 09:00:49 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 03D5589869; Wed, 18 May 2005 15:43:05 +0300 (EEST) Message-ID: <428B3864.60102@piuha.net> Date: Wed, 18 May 2005 15:43:16 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petri Jokela Subject: Re: [Hipsec] some hip base spec nits References: <428ACC07.60000@piuha.net> <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> <428B360C.702@nomadiclab.com> In-Reply-To: <428B360C.702@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, "Petri Jokela \(JO/LMF\)" 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 Ok. Petri Jokela wrote: > Pekka Nikander wrote: > >>>> >>>> 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 |C| >>>> Length | >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> | | >>>> / >>>> Contents / >>>> / >>>> +-+-+-+-+-+-+-+-+ >>>> | | >>>> Padding | >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> >>> Type field is 15 bits according to this... and then later: >>> >>>> | | | >>>> | | >>>> | HMAC | 65245 | 20 | HMAC based >>>> message | >>>> | | | | authentication code, >>>> with | >>>> | | | | key material >>>> from | >>>> | | | | >>>> HIP_TRANSFORM | >>>> >>> >>> Which seems to assume its at least 16 bits. Perhaps the picture >>> is misaligned somehow? I think it should be 16 bits and the length >>> field should be correspondingly smaller. >> >> >> >> The C bit is counted as a part of the type. Probably a sentence >> somewhere >> is needed to clarify this. > > > The C-bit definition covers it, but is not clear. Is it enough if I > add the following to Type definition: > > Type Type code for the parameter. 16 bits long, C-bit being > part of the Type code. > C Critical. One if this parameter is critical, and > MUST be recognized by the recipient, zero otherwise. > The C bit is considered to be a part of the Type field. > Consequently, critical parameters are always odd > and non-critical ones have an even value. > > /petri > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 18 09:49:03 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 JAA21225 for ; Wed, 18 May 2005 09:49:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOse-0005oh-KY; Wed, 18 May 2005 09:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOsc-0005o0-6Q for hipsec@megatron.ietf.org; Wed, 18 May 2005 09:46:34 -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 JAA20877 for ; Wed, 18 May 2005 09:46:31 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYP9X-0007Hr-Rg for hipsec@ietf.org; Wed, 18 May 2005 10:04:05 -0400 Received: from [192.168.1.50] (194.2.144.31) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309C601B421B7 for hipsec@ietf.org; Wed, 18 May 2005 15:46:18 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <200505172241.11952.Jan.Melen@nomadiclab.com> <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> In-Reply-To: <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline Date: Wed, 18 May 2005 15:47:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200505181547.01639.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Wednesday 18 May 2005 14:28, Pekka Nikander wrote: > > On Monday 16 May 2005 22:13, Julien Laganier wrote: > >> There is a related problem when an opportunistic initiator tries > >> to reach a node via its rendezvous server. > >> > >> The initiator sends an I1 to the NULL destination HIT at the RVS > >> IP address, which relays it to the responder. If the responder > >> replies an R1 directly to the initiator, there's currently no > >> way for the initiator to identify the correct context, apart > >> from the RVS IP address included in an optional VIA_RVS > >> parameter. > > I think we should forbid that behavior. Okay. I'd like to hear more opinions before we take a decision. > Firstly, if the > destination HIT is NULL then the rendezvous server cannot reliably > know to which destination the I1 is really intended to, unless it > is serving just a single destination host. With IPv6 there is an additional possibility: it might be reasonable for a RVS to have a per-client IPv6 address, and to demultiplex incoming I1s based on their destination IP address. > IMHO the right way forward here is to state (in the rendezvous doc) > that if you want to support rvs with NULL dest HITs, then the > return R1 *MUST* go through the rendezvous server and appear coming > from the rendezvous server's IP address. > > Or am I missing something? That's in the current draft. Security considerations says: If an Initiator has not an a priori knowledge of the Responder's HI (so called Opportunistic Initiators), it is almost impossible to defend the HIP exchange against MitM attacks (cannot authenticate public keys exchanged). The only solution is to mitigate hijacking threats on the HIP state by requiring an R1 answering an Opportunistic I1 to come from the IP address where the I1 was initially sent. That way we retain a level of security which is equivalent to what exists today in the Internet: By sending an IP packet to an IP address, and receiving an answered IP packet from this same IP address, I know that the routing fabric trusts my correspondent to be represented by this IP address. While it is true that such security is weak, it is better than none, and avoids to introduce additional threats at the IP layer. > > You are probably referring to a case where RVS acts as an > > sentinel node for a > > farm of servers. This is really a special case but yes you have a > > valid point > > that in order this kind of scenario to work you would need a > > nonce. Perhaps > > the solution would be to add optional ECHO_REQUEST to I1 and a > > ECHO_RESPONSE > > that is outside the signature to R1 as you suggested. If this > > kind of scenario should be supported at all? Normally the > > destination HITs of these > > computer farms are probably well known. > > I have no objection in adding *optional* (for Initiator) support > for that. > Apparently, the support in the Responder should be RECOMMENDED or > REQUIRED. > I'd be in favor of making it RECOMMENDED, meaning that the > Initiator must be prepared to receive an R1 without an > ECHO_RESPONSE even if they sent an ECHO_REQUEST in I1. Okay. So I'd like to hear more voice for/against the opportunistic mode with RVS. Do we keep the current text (reply R1 via the RVS) or do we forbid this behavior as Pekka proposed? Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Thu May 19 09:24: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 JAA04066 for ; Thu, 19 May 2005 09:24: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 1DYl0K-0004JB-CN; Thu, 19 May 2005 09:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYl0I-0004Iq-6o for hipsec@megatron.ietf.org; Thu, 19 May 2005 09:23:58 -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 JAA04032 for ; Thu, 19 May 2005 09:23:56 -0400 (EDT) Message-Id: <200505191323.JAA04032@ietf.org> Received: from mail-01.iinet.net.au ([203.59.3.33] helo=mail.iinet.net.au) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYlHM-0001Zo-9H for hipsec@ietf.org; Thu, 19 May 2005 09:41:42 -0400 Received: (qmail 16670 invoked from network); 19 May 2005 13:22:27 -0000 Received: from unknown (HELO T40) (203.217.44.138) by mail.iinet.net.au with SMTP; 19 May 2005 13:22:26 -0000 From: "Joseph" To: Date: Thu, 19 May 2005 23:22:22 +1000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Thread-Index: AcVcdco+E8ftc/VbRRmoCu7uDKWq0w== X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Hipsec] Did anyone develop the HIP model for simulation software? 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="===============0953576343==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0953576343== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C55CC9.9D2B9C30" This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C55CC9.9D2B9C30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, Did anyone develop the HIP model in simulation software, such as Opnet or NS-2? Or did anyone know where I can find those? Thanks Joseph ------=_NextPart_000_0018_01C55CC9.9D2B9C30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear = All,
    Did anyone=20 develop the HIP model in simulation software, such as Opnet or NS-2? Or = did=20 anyone know where I can find those?
Thanks
Joseph
------=_NextPart_000_0018_01C55CC9.9D2B9C30-- --===============0953576343== 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 --===============0953576343==-- From hipsec-bounces@ietf.org Fri May 20 04:14:21 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 EAA18365 for ; Fri, 20 May 2005 04:14:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2bQ-0006Gy-7f; Fri, 20 May 2005 04:11:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2bO-0006Gp-Jd for hipsec@megatron.ietf.org; Fri, 20 May 2005 04:11:26 -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 EAA17897 for ; Fri, 20 May 2005 04:11:24 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ2sh-0002HE-Ic for hipsec@ietf.org; Fri, 20 May 2005 04:29:20 -0400 Received: from [10.0.0.68] (83.145.97.42) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309D301E6E2F5 for hipsec@ietf.org; Fri, 20 May 2005 10:10:36 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? Date: Fri, 20 May 2005 10:11:15 +0200 User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> <200505181547.01639.julien.IETF@laposte.net> In-Reply-To: <200505181547.01639.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201011.16068.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Folks, On Wednesday 18 May 2005 15:47, Julien Laganier wrote: > On Wednesday 18 May 2005 14:28, Pekka Nikander wrote: > > > On Monday 16 May 2005 22:13, Julien Laganier wrote: > > >> There is a related problem when an opportunistic initiator > > >> tries to reach a node via its rendezvous server. > > >> > > >> The initiator sends an I1 to the NULL destination HIT at the > > >> RVS IP address, which relays it to the responder. If the > > >> responder replies an R1 directly to the initiator, there's > > >> currently no way for the initiator to identify the correct > > >> context, apart from the RVS IP address included in an optional > > >> VIA_RVS parameter. > > > > I think we should forbid that behavior. (...) > So I'd like to hear more voice for/against the opportunistic mode > with RVS. Do we keep the current text (reply R1 via the RVS) or do > we forbid this behavior as Pekka proposed? Until now nobody has objected to Pekka's proposal, so if nobody still don't object in the following days, I will put some text in the draft to forbid opportunistic mode with rendezvous relaying: -An initiator MUST not send an I1 with a NULL destination HIT to an IP address which is known to be a rendezvous server address. -A rendezvous server MUST drop incoming I1 with a NULL destination HIT. -A rendezvous client, acting as responder, MUST drop incoming I1 with a NULL destination HIT which were relayed by a rendezvous server. I'm not sure of the requirements level, however. Perhaps MUST is too strong, and SHOULD would be sufficient. Opinions? Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri May 20 04:54:28 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 EAA21437 for ; Fri, 20 May 2005 04:54:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3FT-000897-6F; Fri, 20 May 2005 04:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3FR-000870-4l for hipsec@megatron.ietf.org; Fri, 20 May 2005 04:52:49 -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 EAA21345 for ; Fri, 20 May 2005 04:52:46 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ3Wj-0003NW-Fb for hipsec@ietf.org; Fri, 20 May 2005 05:10:43 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 96F07212CAE; Fri, 20 May 2005 11:52:35 +0300 (EEST) In-Reply-To: <200505201011.16068.julien.IETF@laposte.net> References: <426C950A.3020706@cs.helsinki.fi> <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> <200505181547.01639.julien.IETF@laposte.net> <200505201011.16068.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 Subject: Re: [Hipsec] changes to base spec? Date: Fri, 20 May 2005 11:52:21 +0300 To: Julien Laganier X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 > -A rendezvous server MUST drop incoming I1 with a NULL destination > HIT. Alternatively, it could interpret it as an I1 to itself. That would be perfectly OK from a semantics point of view, provided that the rendezvous server is a HIP host itself. > -A rendezvous client, acting as responder, MUST drop incoming I1 with > a NULL destination HIT which were relayed by a rendezvous server. I don't quite understand the rationale of this. In some cases the client may not even know that it is coming from its rendezvous server and not directly from another host? Or am I missing something here? > I'm not sure of the requirements level, however. Perhaps MUST is too > strong, and SHOULD would be sufficient. I think SHOULD is enough. Little harm is done if someone acts badly, so we shouldn't use MUST. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri May 20 05:25: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 FAA23615 for ; Fri, 20 May 2005 05:25: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 1DZ3iw-00075R-LI; Fri, 20 May 2005 05:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3iv-00075M-PT for hipsec@megatron.ietf.org; Fri, 20 May 2005 05:23:17 -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 FAA23523 for ; Fri, 20 May 2005 05:23:15 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ40F-00042j-DS for hipsec@ietf.org; Fri, 20 May 2005 05:41:12 -0400 Received: from [10.0.0.68] (83.145.97.42) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309EF01E70425; Fri, 20 May 2005 11:20:35 +0200 From: Julien Laganier To: Pekka Nikander Subject: Re: [Hipsec] changes to base spec? Date: Fri, 20 May 2005 11:20:30 +0200 User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <200505201011.16068.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201120.30556.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Pekka, Thanks for your quick answer. More below, On Friday 20 May 2005 10:52, Pekka Nikander wrote: > > -A rendezvous server MUST drop incoming I1 with a NULL > > destination HIT. > > Alternatively, it could interpret it as an I1 to itself. That > would be perfectly OK from a semantics point of view, provided > that the rendezvous server is a HIP host itself. You're right. Let's have this text: -A rendezvous server SHOULD interpret any incoming opportunistic I1 (i.e. with a NULL destination HIT) as an I1 to itself and SHOULD NOT attempt to relay it to one of its clients. > > -A rendezvous client, acting as responder, MUST drop incoming I1 > > with a NULL destination HIT which were relayed by a rendezvous > > server. > > I don't quite understand the rationale of this. In some cases the > client may not even know that it is coming from its rendezvous > server and not directly from another host? Or am I missing > something here? I should have been more precise: I was thinking to the case where the responder get an opportunistic I1 including a FROM:ip_address parameter, indicating that the packet was relayed. I propose this text: -A rendezvous client acting as responder SHOULD drop opportunistic I1s including a FROM parameter because that means the I1 has been relayed. Along with their initiator counterparts: -An initiator SHOULD not send an opportunistic I1 with a NULL destination HIT to an IP address which is known to be a rendezvous server address. -An initiator SHOULD drop R1s replying to an opportunistic I1 if it does not come from the IP address the I1 was sent to. Is that okay with everybody? Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri May 20 05:32: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 FAA24034 for ; Fri, 20 May 2005 05:32: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 1DZ3qU-00008n-NQ; Fri, 20 May 2005 05: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 1DZ3qT-00008i-Qg for hipsec@megatron.ietf.org; Fri, 20 May 2005 05:31: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 FAA23991 for ; Fri, 20 May 2005 05:31:03 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ47o-0004Al-LA for hipsec@ietf.org; Fri, 20 May 2005 05:49:01 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 48F7A212C40; Fri, 20 May 2005 12:30:56 +0300 (EEST) In-Reply-To: <200505201120.30556.julien.IETF@laposte.net> References: <426C950A.3020706@cs.helsinki.fi> <200505201011.16068.julien.IETF@laposte.net> <200505201120.30556.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1bc932ece5edd4a6d576165bff32e341@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] changes to base spec? Date: Fri, 20 May 2005 12:31:26 +0300 To: Julien Laganier X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > -A rendezvous server SHOULD interpret any incoming opportunistic I1 > (i.e. with a NULL destination HIT) as an I1 to itself and SHOULD NOT > attempt to relay it to one of its clients. > > -A rendezvous client acting as responder SHOULD drop opportunistic I1s > including a FROM parameter because that means the I1 has been > relayed. > > Along with their initiator counterparts: > > -An initiator SHOULD not send an opportunistic I1 with a NULL > destination HIT to an IP address which is known to be a rendezvous > server address. You might want to add in parenthesis: (If the Initiator knows that a given IP address belongs to a rendezvous server, it most probably also knows the HIT of this rendezvous server.) Or, alternatively, you could simply add: , unless it wants to establish a HIP association with the rendezvous server itself and does not know the HIT of the rendezvous server. I am not quite sure which one is the right choice. > -An initiator SHOULD drop R1s replying to an opportunistic I1 if it > does not come from the IP address the I1 was sent to. > > Is that okay with everybody? Thanks. Other than the note above, looks very good to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri May 20 08:32:52 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 IAA08759 for ; Fri, 20 May 2005 08:32:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6du-0006Kj-Dc; Fri, 20 May 2005 08:30:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6dt-0006Ke-G0 for hipsec@megatron.ietf.org; Fri, 20 May 2005 08:30:17 -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 IAA08545 for ; Fri, 20 May 2005 08:30:15 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ6vE-0000DV-Io for hipsec@ietf.org; Fri, 20 May 2005 08:48:13 -0400 Received: from [10.0.0.68] (83.145.97.42) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309D301EA30EF; Fri, 20 May 2005 14:29:27 +0200 From: Julien Laganier To: hipsec@ietf.org Date: Fri, 20 May 2005 14:29:57 +0200 User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <200505201120.30556.julien.IETF@laposte.net> <1bc932ece5edd4a6d576165bff32e341@nomadiclab.com> In-Reply-To: <1bc932ece5edd4a6d576165bff32e341@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201429.57964.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: lars.eggert@netlab.nec.de Subject: [Hipsec] Preliminary -02 RVS draft 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 Folks, Here is the pre-version of the updated rendezvous draft (based on feedback from the hipsec ML) that we plan to submit before the end of May. Changelog from -01 to -02-200505: Removed multiple relaying techniques but simple I1 header rewriting. Updated new HIP parameters type numbers (consistent with new layout and assigning rules from draft-ietf-hip-base.) Updated IANA Considerations. Please take a look and let me know if you disagree with the approach we took. Thanks in advance, --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri May 20 18:13: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 SAA19781 for ; Fri, 20 May 2005 18:13:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZFhH-0001pc-J3; Fri, 20 May 2005 18:10:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZFhF-0001nH-QB for hipsec@megatron.ietf.org; Fri, 20 May 2005 18:10: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 SAA19320 for ; Fri, 20 May 2005 18:10:18 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZFyg-0002Tp-77 for hipsec@ietf.org; Fri, 20 May 2005 18:28:23 -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 PAA00340; Fri, 20 May 2005 15:10:02 -0700 (PDT) Received: from XCH-NWBH-10.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 j4KMA1D29623; Fri, 20 May 2005 15:10:01 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 May 2005 15:10:00 -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] changes to base spec? Date: Fri, 20 May 2005 15:09:59 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5A@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] changes to base spec? Thread-Index: AcVdHuQKafxTcUyjTHS8k+lid/1mLQAXxUHQ From: "Henderson, Thomas R" To: "Pekka Nikander" , "Julien Laganier" X-OriginalArrivalTime: 20 May 2005 22:10:00.0272 (UTC) FILETIME=[AA38ED00:01C55D88] 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 > > Is that okay with everybody? Thanks. >=20 > Other than the note above, looks very good to me. >=20 I also agree with the changes hashed out regarding the rendezvous case. However, I don't sense any convergence in agreeing on the initial proposal to include nonce in I1 and R1, now that this rendezvous case has been defused. It seems to me that consensus is that the stated vulnerability is unlikely to occur (off-path attacker who obtains correct signed parts of R1 and times the fake R1 successfully so that it tricks the initiator to solve the wrong puzzle). Regarding the other changes proposed in the paper: 2- I do not think it is burdensome to retain I and J for this purpose, so I would agree with the proposal 3,4,5- These are all related to the puzzle implementation. Perhaps we could put the proposed puzzle mechanism into the appendix and reference the paper? (5 would require some change in section 4.1.1 and appendix C) 6- I don't object to this proposed change (reveal HI in I2)-- I don't know the original requirement for this encryption, and the paper points out that it seems to be flawed. 7a)- Let me respond to this in a separate post. 7b),7c),8- These are all related to achieving consistency in=20 Initiator/Responder roles when I1s or I2s collide, and seem OK to me. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Sat May 21 17:15: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 RAA27958 for ; Sat, 21 May 2005 17:15: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 1DZbI0-0002ZQ-7X; Sat, 21 May 2005 17:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZbHx-0002ZL-Ky for hipsec@megatron.ietf.org; Sat, 21 May 2005 17:13:41 -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 RAA27876 for ; Sat, 21 May 2005 17:13:38 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZbZb-0000b3-2e for hipsec@ietf.org; Sat, 21 May 2005 17:31:55 -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 OAA08904; Sat, 21 May 2005 14:13:31 -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 j4LLDUD18978; Sat, 21 May 2005 14:13:30 -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); Sat, 21 May 2005 14:13:30 -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: Sat, 21 May 2005 14:13:29 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5B@xch-nw-27.nw.nos.boeing.com> Thread-Topic: moving from R2-SENT to UNASSOCIATED Thread-Index: AcVdHuQKafxTcUyjTHS8k+lid/1mLQAZwffw From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 21 May 2005 21:13:30.0450 (UTC) FILETIME=[F024E320:01C55E49] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: Tuomas Aura , aarthi.nagarajan@tu-harburg.de Subject: [Hipsec] moving from R2-SENT to UNASSOCIATED 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 In the paper by Aura et al., there is a proposal: "7a) The timeout transition from the R2-SENT state should lead to the UNASSOCIATED state." Earlier, it is said: "The reason for waiting for the ESP packet is key confirmation; only after receiving the ESP packet the Responder knows that the Initiator received a fresh Diffie-Hellman key (rather than a replay) in R1 and has computed the valid session key. The timeout transition breaks this mechanism." Actually, key confirmation is not the reason-- instead, the reason is the desire to avoid distinguishing between Initiator and Responder after the exchange completes, yet be able to properly handle the possible transmission loss of R2. See: http://honor.trusecure.com/pipermail/hipsec/2004-April/000672.html The Responder can learn that the Initiator received a fresh DH-key when it checks the HMAC on the I2. But getting back to proposal 7a), I question whether transition to UNASSOCIATED is solving the real problem. It may be that we do not want to have any special timeout transition from R2-SENT. The reason that R2-SENT is a useful state is that it allows the Responder to reply to a duplicate (retransmitted, or replayed) I2 without changing its state. If R2 was truly lost, this reply will serve the same purpose as the original R2. If R2 were not lost, the retransmitted R2 will simply be ignored. Consider if the timeout value of R2-SENT is too short (or zero), and the following situation occurs-- the first R2 sent is successfully received (moving Initiator to ESTABLISHED) but I2 is retransmitted or replayed (or retransmission of I2 crosses paths with the initial R2). The (previous) Responder may process this I2 as if it were a new one, following the rules for ESTABLISHED state, and cycle back into R2-SENT or ESTABLISHED. The new R2 (with new SPI) will be sent to the previous Initiator, but it will discard it. The two sides will be out of sync now. The situation would be the same if R2-SENT transitioned to UNASSOCIATED. Because of this, the timeout value to move from R2-SENT should be large enough to avoid such possibilities. And that makes me question whether any timer is needed. Moving from R2-SENT to ESTABLISHED could instead just be triggered based on reception of a packet (data on a SPI, HIP UPDATE) that indicates that the peer got the R2. If the group agrees, I'll propose some text to change this behavior. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Sun May 22 00:15:32 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 AAA22098 for ; Sun, 22 May 2005 00:15:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZhpw-0002el-4t; Sun, 22 May 2005 00:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZhpv-0002eg-6W for hipsec@megatron.ietf.org; Sun, 22 May 2005 00:13:11 -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 AAA21999 for ; Sun, 22 May 2005 00:13:08 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZi7b-0001m8-OJ for hipsec@ietf.org; Sun, 22 May 2005 00:31:29 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E0AB5212C40; Sun, 22 May 2005 07:12:58 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5B@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23f5fbefd962941dcc75305fd284ed80@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Sun, 22 May 2005 07:13:30 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Tuomas Aura , aarthi.nagarajan@tu-harburg.de 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 of this, the timeout value to move from R2-SENT > should be large enough to avoid such possibilities. And > that makes me question whether any timer is needed. Moving > from R2-SENT to ESTABLISHED could instead just be triggered > based on reception of a packet (data on a SPI, HIP UPDATE) > that indicates that the peer got the R2. > > If the group agrees, I'll propose some text to change this > behavior. In principle, sounds fine to me. OTOH, I think it might be good to allow a *long* timeout after which the Responder MAY revert to UNASSOCIATED. That timeout could be in the order of the default inactivity timeout of the association... --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Sun May 22 16:25: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 QAA22914 for ; Sun, 22 May 2005 16:25:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwzK-0005ed-DC; Sun, 22 May 2005 16:23:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwzJ-0005c4-AX for hipsec@megatron.ietf.org; Sun, 22 May 2005 16:23:53 -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 QAA22806 for ; Sun, 22 May 2005 16:23:48 -0400 (EDT) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZxH6-0002ge-4H for hipsec@ietf.org; Sun, 22 May 2005 16:42:16 -0400 Received: from celerio.ucdavis.edu (celerio.ucdavis.edu [169.237.104.178]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j4MKN3LH020173 for ; Sun, 22 May 2005 13:23:47 -0700 (PDT) Received: from celerio.ucdavis.edu (localhost [127.0.0.1]) by celerio.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j4MKN3JO010033 for ; Sun, 22 May 2005 13:23:03 -0700 (PDT) Received: (from www@localhost) by celerio.ucdavis.edu (8.12.10/8.12.9/Submit) id j4MKN3eN010032; Sun, 22 May 2005 13:23:03 -0700 (PDT) Date: Sun, 22 May 2005 13:23:03 -0700 (PDT) Message-Id: <200505222023.j4MKN3eN010032@celerio.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: c83ccb5cc10e751496398f1233ca9c3a Subject: [Hipsec] Call for Paper: JSAC-MRNM (The deadline is approaching.) 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 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 1, 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 Mon May 23 10:53:25 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 KAA02785 for ; Mon, 23 May 2005 10:53: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 1DaEHB-0005mg-FM; Mon, 23 May 2005 10:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaEH9-0005mV-68 for hipsec@megatron.ietf.org; Mon, 23 May 2005 10:51:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02447 for ; Mon, 23 May 2005 10:51:25 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaEZ7-0006Wl-5B for hipsec@ietf.org; Mon, 23 May 2005 11:10:03 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA05505; Mon, 23 May 2005 09:51:12 -0500 (CDT) Received: from XCH-NWBH-10.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 j4NEpBw18961; Mon, 23 May 2005 09:51:12 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 May 2005 07:51:10 -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] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 07:51:09 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] moving from R2-SENT to UNASSOCIATED Thread-Index: AcVehIt6lKKCjBnLTLadEaIKsNGr0wBIa1QA From: "Henderson, Thomas R" To: "Pekka Nikander" X-OriginalArrivalTime: 23 May 2005 14:51:10.0092 (UTC) FILETIME=[DB738CC0:01C55FA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org, Tuomas Aura , aarthi.nagarajan@tu-harburg.de 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: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Saturday, May 21, 2005 9:14 PM > To: Henderson, Thomas R > Cc: aarthi.nagarajan@tu-harburg.de; hipsec@ietf.org; Tuomas Aura > Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED >=20 > > Because of this, the timeout value to move from R2-SENT > > should be large enough to avoid such possibilities. And > > that makes me question whether any timer is needed. Moving > > from R2-SENT to ESTABLISHED could instead just be triggered > > based on reception of a packet (data on a SPI, HIP UPDATE) > > that indicates that the peer got the R2. > > > > If the group agrees, I'll propose some text to change this > > behavior. >=20 > In principle, sounds fine to me. OTOH, I think it might be > good to allow a *long* timeout after which the Responder > MAY revert to UNASSOCIATED. That timeout could be in the > order of the default inactivity timeout of the association... >=20 We have such a timeout in ESTABLISHED state, but it moves to CLOSING. I agree that there could be a long timeout after which the Responder MAY change state, but I would suggest trying to pass through CLOSING state, so as to avoid cases where one side silently drops the association without notifying the other side. (note that the acronym "UAL", which I assume is the "default inactivity timeout", appears in the state machine but is nowhere defined in the document). Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon May 23 11:42: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 LAA06499 for ; Mon, 23 May 2005 11:42:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaF2m-00038h-6R; Mon, 23 May 2005 11:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaF2k-00038Z-Hg for hipsec@megatron.ietf.org; Mon, 23 May 2005 11:40:38 -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 LAA06335 for ; Mon, 23 May 2005 11:40:35 -0400 (EDT) Received: from [192.168.1.50] (194.2.144.31) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 429188A00005AA3A; Mon, 23 May 2005 17:39:57 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 17:39:52 +0200 User-Agent: KMail/1.7 References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505231739.53429.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 Monday 23 May 2005 16:51, Henderson, Thomas R wrote: > (note that the acronym "UAL", which I assume is the "default > inactivity timeout", appears in the state machine but is nowhere > defined in the document). Sorry it's my mistake (when I merged Erik's CLOSE/CLOSE_ACK handshake with the HIP state machine). UAL signification (Unused Association Lifetime) is given in the CLOSING state text, so after it has been used in the ESTABLISHED state text. I think we should at least move this signification in the ESTABLISHED state text, and perhaps define it properly prior to states description. For wxample: "When a HIP node hasn't used a HIP association for Unused Association Lifetime (UAL) minutes, it will begin to tear down the association". It might also be good to suggest a typical value (5 min?) for implementors. Thoughts? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon May 23 12:09: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 MAA09990 for ; Mon, 23 May 2005 12:09: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 1DaFQp-0006g7-Og; Mon, 23 May 2005 12:05:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaFQn-0006fz-TH for hipsec@megatron.ietf.org; Mon, 23 May 2005 12:05:30 -0400 Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09626 for ; Mon, 23 May 2005 12:05:27 -0400 (EDT) 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 JAA17923; Mon, 23 May 2005 09:04:58 -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 j4NG4ve04236; Mon, 23 May 2005 09:04:57 -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); Mon, 23 May 2005 09:04:57 -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] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 09:04:56 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0664934F@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] moving from R2-SENT to UNASSOCIATED Thread-Index: AcVfrk31PmNVFRzGTP66GJAzTLn2QQAAni1g From: "Henderson, Thomas R" To: "Julien Laganier" , X-OriginalArrivalTime: 23 May 2005 16:04:57.0531 (UTC) FILETIME=[2A6920B0:01C55FB1] 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: Julien Laganier [mailto:julien.IETF@laposte.net]=20 > Sent: Monday, May 23, 2005 8:40 AM > To: hipsec@lists.ietf.org > Cc: Henderson, Thomas R > Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED >=20 > I think we should at least move this signification in the ESTABLISHED=20 > state text, and perhaps define it properly prior to states=20 > description. For wxample: "When a HIP node hasn't used a HIP=20 > association for Unused Association Lifetime (UAL) minutes, it will=20 > begin to tear down the association". >=20 > It might also be good to suggest a typical value (5 min?) for=20 > implementors. >=20 5 minutes seems short to me. I don't know what magic number (if any) is appropriate. Here is what IKEv2 Section 2.8 says about the matter: " ... If an SA bundle has been inactive for a long time and if an endpoint would not initiate the SA in the absence of traffic, the endpoint MAY choose to close the SA instead of rekeying it when its lifetime expires. It SHOULD do so if there has been no traffic since the last time the SA was rekeyed." _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon May 23 13:47:15 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 NAA18613 for ; Mon, 23 May 2005 13:47:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGzB-0001p0-2v; Mon, 23 May 2005 13:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGz9-0001oH-JM for hipsec@megatron.ietf.org; Mon, 23 May 2005 13:45:04 -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 NAA18408 for ; Mon, 23 May 2005 13:45:02 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHH9-0005i4-QZ for hipsec@ietf.org; Mon, 23 May 2005 14:03:41 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 43A6A212C40; Mon, 23 May 2005 20:44:47 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7514092d185d4f94b24c6a7e05d59500@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 20:45:20 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Tuomas Aura , aarthi.nagarajan@tu-harburg.de 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 of this, the timeout value to move from R2-SENT >>> should be large enough to avoid such possibilities. And >>> that makes me question whether any timer is needed. Moving >>> from R2-SENT to ESTABLISHED could instead just be triggered >>> based on reception of a packet (data on a SPI, HIP UPDATE) >>> that indicates that the peer got the R2. >> >> In principle, sounds fine to me. OTOH, I think it might be >> good to allow a *long* timeout after which the Responder >> MAY revert to UNASSOCIATED. That timeout could be in the >> order of the default inactivity timeout of the association... > > We have such a timeout in ESTABLISHED state, but it moves > to CLOSING. I agree that there could be a long timeout > after which the Responder MAY change state, but I would suggest > trying to pass through CLOSING state, so as to avoid cases > where one side silently drops the association without notifying > the other side. OK to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon May 23 13:53: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 NAA18928 for ; Mon, 23 May 2005 13:53: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 1DaH3M-0002P5-Vf; Mon, 23 May 2005 13:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaH3K-0002P0-Uk for hipsec@megatron.ietf.org; Mon, 23 May 2005 13:49:23 -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 NAA18727 for ; Mon, 23 May 2005 13:49:21 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHLL-0005qL-83 for hipsec@ietf.org; Mon, 23 May 2005 14:08:00 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 21866212C40; Mon, 23 May 2005 20:49:09 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0664934F@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0664934F@xch-nw-27.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] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 20:49:41 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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 >> [About UAL] >> >> It might also be good to suggest a typical value (5 min?) for >> implementors. >> > > 5 minutes seems short to me. I don't know what magic number (if > any) is appropriate. UAL has been traditionally 15 minutes, but I don't know the origin of that value. It came from Bob Moskowitz, and I don't know the rationale behind that. IMHO each implementation SHOULD implement per-HIT configuration of UAL, allowing statically configured HIP associations to stay alive days, even when inactive. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon May 23 16:56: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 QAA20360 for ; Mon, 23 May 2005 16:56: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 1DaJwk-0007re-5e; Mon, 23 May 2005 16:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaJwe-0007qw-FH for hipsec@megatron.ietf.org; Mon, 23 May 2005 16:54:41 -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 QAA20211 for ; Mon, 23 May 2005 16:54:38 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKEg-0000Tj-3p for hipsec@ietf.org; Mon, 23 May 2005 17:13:19 -0400 Received: from [10.10.10.11] (pD9E61C21.dip0.t-ipconnect.de [217.230.28.33]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3D57F1BAC9E; Mon, 23 May 2005 22:54:29 +0200 (CEST) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0664934F@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <05471F2E-F565-480D-9B4F-767169A6EF33@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 22:54:25 +0200 To: Pekka Nikander X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: hipsec@ietf.org, Julien Laganier 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="===============0379888113==" Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --===============0379888113== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-31--1011970721; protocol="application/pkcs7-signature" --Apple-Mail-31--1011970721 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 23, 2005, at 19:49 , Pekka Nikander wrote: > IMHO each implementation SHOULD implement per-HIT configuration > of UAL, allowing statically configured HIP associations to stay > alive days, even when inactive. Yes, please. We're pushing a similar change to TCP right now. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-31--1011970721 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGdTCCAy4w ggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAzWjCBhDEPMA0GA1UE BBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEoMCYGCSqGSIb3 DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqGSIb3DQEJARYTbGFycy5lZ2dl cnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOowMZjwQREXIdWxQacJ DyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugUzjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+ AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsLuAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9 eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhfS6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1x isltw2eRT0txoUCqq0mjFEp8LgJ+s6p14M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8U OH5GsH+Vkjbz5yFO1SsCAwEAAaNLMEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AE9rOnUtJERYLNbDztLIsH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZ L9kb8RZnzGBii8a/XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5k IHRjNvXpNGYeC7S3K8YsMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UE BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQK ExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIz NTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph 8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4H v0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQI MAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+ whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FX JY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucw ggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMhVow CQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDUwNTIzMjA1NDI2WjAjBgkqhkiG9w0BCQQxFgQUbFMIGpRQepd6fb64D6DZv4NJV28weAYJKwYB BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMMhVowDQYJKoZIhvcNAQEBBQAEggEACP6zktDAAWYI/fMxB6N/ILBievDJjyBJgo+f arR9/IJzep3nOb9GhJYpalCu2GCpWQdJ7qmn6ol9KSBIhlyQqaWQaX0QkXs/c0WiWb+FHMPqPKEf vpv4P2urjKGvsE6Sir5Fi2Q7fqyWIcmLiy9JOCLcfzCa5yxl/v9m4qW4zbFxcVlM+u7RvP1ep7ZS mo7OMxTkX4aCntW5RBN81a+5o3NUS8nrDNKUHzaEaqW7Vm6G6vTwmCGEeJcosOY6OR4hvkt0dnd5 j1z3nrRWu5d+fc9JTPzrI5R0EyaOgG8zmoxgSnakGansX3UrUxNFA3l/R8gOMAe9yDfcPp7hM9OS IQAAAAAAAA== --Apple-Mail-31--1011970721-- --===============0379888113== 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 --===============0379888113==-- From hipsec-bounces@ietf.org Tue May 24 08:06: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 IAA21831 for ; Tue, 24 May 2005 08:06: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 1DaY5G-0007pG-RC; Tue, 24 May 2005 08:00:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaY5E-0007p9-SC for hipsec@megatron.ietf.org; Tue, 24 May 2005 08:00: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 IAA21052 for ; Tue, 24 May 2005 08:00:27 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaYNO-000080-GB for hipsec@ietf.org; Tue, 24 May 2005 08:19:16 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BF0F7212C40; Tue, 24 May 2005 15:00:15 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5A@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5A@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4b46d92102b16472ba05027329a1973f@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] changes to base spec? Date: Tue, 24 May 2005 15:00:49 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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 > However, I don't sense any convergence in agreeing on the initial > proposal to include nonce in I1 and R1, now that this rendezvous > case has been defused. It seems to me that consensus is that the > stated vulnerability is unlikely to occur (off-path attacker who > obtains correct signed parts of R1 and times the fake R1 successfully > so that it tricks the initiator to solve the wrong puzzle). I agree. OTOH, I don't see much harm in allowing (MAY) the Initiator to include an ECHO_REQUEST in I1, with the provisioning that the Responder is recommended (SHOULD) to reply with an ECHO_RESPONSE. Furthermore, if the Initiator does implement this option, it MUST be prepared for the case that the Responder does not reply with a ECHO_RESPONSE. The only problem with this is that it adds complexity and optional behaviour, though in a fairly mild manner, IMHO. That is, most of the complexity is carried by the Initiator implementing this; at the Responder end implementing the SHOULD is fairly simple. > Regarding the other changes proposed in the paper: > > 2- I do not think it is burdensome to retain I and J for this purpose, > so I would agree with the proposal Fine with me. > 3,4,5- These are all related to the puzzle implementation. Perhaps > we could put the proposed puzzle mechanism into the appendix and > reference the paper? (5 would require some change in section 4.1.1 > and appendix C) Fine wiht me. > 6- I don't object to this proposed change (reveal HI in I2)-- I don't > know the original requirement for this encryption, and the paper > points out that it seems to be flawed. I think we could easily allow both, i.e., both encrypted and unencrypted initiator HI. Then the question boils down to which should be the preferred (MUST implement) style, which optional (MAY/SHOULD). > 7b),7c),8- These are all related to achieving consistency in > Initiator/Responder roles when I1s or I2s collide, and seem OK > to me. I don't remember the details of these any more, but my vague recollection was that some of them may not be a problem as the HITs identify the context. However, I may be very wrong here. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue May 24 10:45: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 KAA06113 for ; Tue, 24 May 2005 10:45: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 1Daadf-0000yY-0W; Tue, 24 May 2005 10:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daadd-0000yT-9S for hipsec@megatron.ietf.org; Tue, 24 May 2005 10:44:09 -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 KAA06037 for ; Tue, 24 May 2005 10:44: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 1Daavo-0005jq-Cc for hipsec@ietf.org; Tue, 24 May 2005 11:02:58 -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 HAA06280; Tue, 24 May 2005 07:43:50 -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 j4OEhon08377; Tue, 24 May 2005 07:43:50 -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); Tue, 24 May 2005 07:43:49 -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] Pre-version: ESP draft Date: Tue, 24 May 2005 07:43:48 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Pre-version: ESP draft Thread-Index: AcVXvN5bfchjzs4MQbuCt+ItHjb2rQIsafPg From: "Henderson, Thomas R" To: "Petri Jokela" , X-OriginalArrivalTime: 24 May 2005 14:43:49.0380 (UTC) FILETIME=[FF2DFC40:01C5606E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Comments on draft-ietf-hip-esp-00-pre130505.txt I have a number of minor edits (non-technical) that I will send to=20 Petri in a separate message. Below are some technical issues: 1) There is presently one open issue in the HIP WG issue tracker for=20 this draft (http://hip4inter.net/cgi-bin/roundup.cgi/hip-esp/index). It relates to use of NULL encryption and integrity. As I suggested in a previous post (http://www1.ietf.org/mail-archive/web/hipsec/current/msg01317.html), the current pre-draft has removed the statement that ESP NULL is=20 deprecated. Instead, it has added some material describing how one=20 might want to migrate from a NULL SA to an encrypted SA (suggested=20 by Gonzalo in: http://www1.ietf.org/mail-archive/web/hipsec/current/msg01329.html). =20 This has resulted in possible inclusion of ESP_TRANSFORM parameter in the UPDATE. The remaining sub-issue (whether we should have the statement that=20 "All HIP implementations must implement, at minimum, the ESP transport format") never generated any more discussion on the list, so I guess=20 the WG sentiment is to keep this as it is. I am OK with that. So maybe this issue is now closed? 2) What is the status of the BEET draft-- it has expired some time ago, and I don't know of any (SAAG?) discussion of it. Do we need to incorporate the core elements of the BEET draft into this draft to make HIP ESP stand alone? Or will BEET draft be introduced again? If BEET continues to be referenced, will it be a blocking reference for this draft? 3) One question I have about BEET operation is whether IP addresses are ever checked to see whether they match known addresses of the peer. It seemed to me upon quick reread of BEET draft that such IP address check is not done. That is, the packet is looked up=20 by SPI only in the SADB, and can come in from any address. Now, it seems a nice feature that IP addresses no longer matter at this=20 IPsec layer, but I wonder whether people will still want to impose some sanity checking of the inbound addresses in some cases (e.g., a "upon receiving a packet, MAY check whether the packet's=20 source IP address is known to be associated with the peer's HIT that it is about to be overwritten with"). I don't know whether such addition would constrain NAT interoperability in the future. This may also pertain to the last sentence of the first paragraph in=20 Section 3.2 regarding possible DoS vulnerabilities of this new=20 mode of operation, or maybe handled in the Security section. 4) In section 3.3.7, there is the inactive SA timeout default=20 that Pekka mentioned, of 15 minutes. I suggest that we adopt his suggested text here: "Each implementation SHOULD implement per-HIT configuration of=20 the inactivity timeout, allowing statically configured HIP=20 associations to stay alive for days, even when inactive." 5) At the Minneapolis WG meeting, when we were discussing future extensibility of HIP, Pekka brought up a suggestion that we maybe renumber the parameters and message types so as to leave some room for insertion. Although mainly a base spec issue, I bring this up here because we have selected ESP_INFO to be parameter=20 number 1 (so that it is easily accessible for inspection by middleboxes). =20 Do we want to leave some room at the top end of this parameter space for future parameters, and get better spacing between the ones we have? =20 6) Section 6.8 may need some refinement based on resolution of similar "simultaneous handshake" issues raised by Aura (regarding who takes role of Initiator and Responder if=20 UPDATEs cross on the wire). 7) In the definition of ESP_INFO, there is some language=20 regarding the binding of SPIs to addresses: " Old SPI Old SPI for data sent to the source address of this packet. If this is an initial SA setup, the Old SPI value is zero. New SPI New SPI for data sent to the source address of this packet." I wonder whether this should be slightly modified, to cover the case where REA associates different addresses with an SPI. Perhaps it should be, instead: " Old SPI Old SPI for data sent to address(es) associated with this SA. If this is an initial SA setup, the Old SPI value is zero. New SPI New SPI for data sent to address(es) associated with this SA." 8) There is not much mention of REKEYING state (actually, there is one mention about leaving REKEYING, but none on entering it). I added a reference to transitioning to REKEYING state in=20 Section 6.8 (Initiating ESP SA update) 9) The "Security" section is not written yet. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue May 24 10:57:32 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 KAA07636 for ; Tue, 24 May 2005 10:57:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaanE-0002cT-2Y; Tue, 24 May 2005 10:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaanA-0002bS-I1 for hipsec@megatron.ietf.org; Tue, 24 May 2005 10:54:02 -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 KAA07004 for ; Tue, 24 May 2005 10:53:58 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dab5L-0006Al-W6 for hipsec@ietf.org; Tue, 24 May 2005 11:12:49 -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 HAA20732; Tue, 24 May 2005 07:53:06 -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 j4OEr5p26101; Tue, 24 May 2005 09:53:06 -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); Tue, 24 May 2005 07:52:59 -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: Tue, 24 May 2005 07:52:58 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B67@xch-nw-27.nw.nos.boeing.com> Thread-Topic: IPR status of "Analysis of the HIP Base Exchange Proposal" Thread-Index: AcVdHuQKafxTcUyjTHS8k+lid/1mLQAZwffwALpHEiA= From: "Henderson, Thomas R" To: , "Tuomas Aura" , "Andrei Gurtov" X-OriginalArrivalTime: 24 May 2005 14:52:59.0809 (UTC) FILETIME=[4742C910:01C56070] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] IPR status of "Analysis of the HIP Base Exchange Proposal" 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 Tuomas, Aarthi, and Andrei, Since the WG is considering some modifications of the protocol based on your recent paper, could you please clarify whether the proposals have any IPR associated with them? Thanks, Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue May 24 11:18: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 LAA09579 for ; Tue, 24 May 2005 11:18: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 1Dab2w-0006xp-Gx; Tue, 24 May 2005 11:10:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dab2v-0006xk-QY for hipsec@megatron.ietf.org; Tue, 24 May 2005 11:10:17 -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 LAA08914 for ; Tue, 24 May 2005 11:10:15 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DabL7-00070W-7h for hipsec@ietf.org; Tue, 24 May 2005 11:29:06 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA14585 for ; Tue, 24 May 2005 08:10:02 -0700 (PDT) Received: from XCH-NWBH-10.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 j4OFA2p23812 for ; Tue, 24 May 2005 10:10:02 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 May 2005 08:10:01 -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: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Date: Tue, 24 May 2005 08:10:00 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06649357@xch-nw-27.nw.nos.boeing.com> Thread-Topic: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Thread-Index: AcVGlkIVbmy3SYsRSo2+SEw3zO5P1AWw8yjwAMXV9AA= From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 24 May 2005 15:10:01.0082 (UTC) FILETIME=[A7FCADA0:01C56072] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Pekka, Tim, and I have been discussing this thread off-line. The subject was how to define the prefix that is prepended to the hashed bits of the HIT. I think that we agreed that 8 bits was sufficient, but we had some debates over whether to further divide this field into Prefix/Hash Algorithm, and how many bits to assign to each subfield, if so. =20 Below is the present text in Petri's preview draft. Pekka and Tim indicated that they are fine with this proposal. Pekka indicated slight preference for a 5 bit prefix and 3 bit hash algorithm, so that the group could in the future try to get a /5 allocation for HITs from IANA, and allow us to change the hash algorithm without revisiting IANA. Tim commented that it may be hard to predict what IANA wants to do. My current thinking is that the below is fine for now-- if HIP goes standards track in the future, I'm sure there will be more understanding of what to put in there, but for now, the below seems general enough for our experimental purposes. Tom There are two types of HITs. HITs of the first type, called _Type 1 HIT_, consist of an 8-bit prefix followed by 120 bits of the hash of the public key. HITs of the second type (Type 2 HIT) consist of a Host Assigning Authority Field (HAA), and only the last 64 bits come from a SHA-1 hash of the Host Identity. This latter format for HIT is recommended for 'well known' systems. It is possible to support a resolution mechanism for these names in hierarchical directories, like the DNS. Another use of HAA is in policy controls, see Section 7. The following figure shows the structure of a Type 1 HIT. 1 0 2 0 1 2 3 4 5 6 7 8 ... 7 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | Hash | +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (8 bits) - Fixed prefix. 0x40 - SHA-1 hash algorithm All other values reserved. Hash (120 bits) - Lower-order bits of the hash (as specified by the hash algorithm) of the public key Additional values for the prefix (including different hash algorithms, or other information) may be defined in the future. A host may receive a HIT for which it does not understand the prefix. In such a case, it will not be able to check the mapping between HI and HIT. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue May 24 11:33:50 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 LAA11203 for ; Tue, 24 May 2005 11:33:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabMV-0002mt-S5; Tue, 24 May 2005 11:30:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabMT-0002mo-Oi for hipsec@megatron.ietf.org; Tue, 24 May 2005 11:30: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 LAA10793 for ; Tue, 24 May 2005 11:30:27 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dabef-0007rJ-O0 for hipsec@ietf.org; Tue, 24 May 2005 11:49:19 -0400 Received: from [82.181.111.233] (cs181111233.pp.htv.fi [82.181.111.233]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 24 May 2005 18:30:25 +0300 id 0008FEC9.42934891.0000539B Message-ID: <42934836.5040003@cs.helsinki.fi> Date: Tue, 24 May 2005 18:28:54 +0300 From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B67@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B67@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Tuomas Aura , aarthi.nagarajan@tu-harburg.de Subject: [Hipsec] Re: IPR status of "Analysis of the HIP Base Exchange Proposal" 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 Tom, I'm not aware of any iprs and I suppose there are none, since all the authors are from academia. Andrei Henderson, Thomas R wrote: >Tuomas, Aarthi, and Andrei, >Since the WG is considering some modifications of the protocol >based on your recent paper, could you please clarify whether >the proposals have any IPR associated with them? > >Thanks, >Tom > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 25 03:25:40 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 DAA14501 for ; Wed, 25 May 2005 03:25: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 1DaqEg-0004AC-DD; Wed, 25 May 2005 03:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaqEe-00049n-VM for hipsec@megatron.ietf.org; Wed, 25 May 2005 03:23:25 -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 DAA14268 for ; Wed, 25 May 2005 03:23:23 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaqWy-0004BF-O2 for hipsec@ietf.org; Wed, 25 May 2005 03:42:22 -0400 Received: from n51.nomadiclab.com (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id BAC70212C40 for ; Wed, 25 May 2005 10:23:03 +0300 (EEST) From: Jan Mikael Melen To: hipsec@ietf.org Date: Wed, 25 May 2005 10:23:01 +0300 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505251023.02290.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Hipsec] HIP4BSD FAQ 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 have collected few most frequently asked qustions about our implementation and put them in to a web page: http://www.hip4inter.net/faq.php Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 25 05:29: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 FAA22086 for ; Wed, 25 May 2005 05:29: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 1Das8q-00083v-NV; Wed, 25 May 2005 05:25:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Das8o-00083q-Om for hipsec@megatron.ietf.org; Wed, 25 May 2005 05:25: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 FAA21927 for ; Wed, 25 May 2005 05:25:28 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DasR9-0007S0-8T for hipsec@ietf.org; Wed, 25 May 2005 05:44:28 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1F858212C40; Wed, 25 May 2005 12:25:17 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.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 Date: Wed, 25 May 2005 12:25:50 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] BEET (was Re: Pre-version: ESP draft) 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 > 2) What is the status of the BEET draft-- it has expired some time > ago, and I don't know of any (SAAG?) discussion of it. Do we need > to incorporate the core elements of the BEET draft into this draft > to make HIP ESP stand alone? Or will BEET draft be introduced again? > If BEET continues to be referenced, will it be a blocking > reference for this draft? AFAIK, Jan is in the process of submitting a slightly updated version of the BEET draft. I have no real idea what would be the best way forward with it; I'm inclined to think that probably as an individual submission through Sam Hartman. > 3) One question I have about BEET operation is whether IP addresses > are ever checked to see whether they match known addresses of the > peer. It seemed to me upon quick reread of BEET draft that such > IP address check is not done. That is, the packet is looked up > by SPI only in the SADB, and can come in from any address. Now, it > seems a nice feature that IP addresses no longer matter at this > IPsec layer, but I wonder whether people will still want to impose > some sanity checking of the inbound addresses in some cases > (e.g., a "upon receiving a packet, MAY check whether the packet's > source IP address is known to be associated with the peer's HIT > that it is about to be overwritten with"). I don't know whether such > addition would constrain NAT interoperability in the future. This > may also pertain to the last sentence of the first paragraph in > Section 3.2 regarding possible DoS vulnerabilities of this new > mode of operation, or maybe handled in the Security section. I'd be inclined to include some text to the sec cons section about potential DOS, and leave it there. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 25 05:30:28 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 FAA22224 for ; Wed, 25 May 2005 05:30:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DasBx-0008HU-Vg; Wed, 25 May 2005 05:28:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DasBw-0008HK-1P for hipsec@megatron.ietf.org; Wed, 25 May 2005 05:28:44 -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 FAA22049 for ; Wed, 25 May 2005 05:28:42 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DasUI-0007Vo-9X for hipsec@ietf.org; Wed, 25 May 2005 05:47:42 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6255D212C40; Wed, 25 May 2005 12:28:34 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <425830fc9bd5c885439aff8606dfa506@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Pre-version: ESP draft Date: Wed, 25 May 2005 12:29:07 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) 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 > Comments on draft-ietf-hip-esp-00-pre130505.txt > > 1) There is presently one open issue in the HIP WG issue tracker for > this draft > So maybe this issue is now closed? Fine with me. [BEET comments in a separate mail.] > 4) In section 3.3.7, there is the inactive SA timeout default > that Pekka mentioned, of 15 minutes. I suggest that we adopt > his suggested text here: > "Each implementation SHOULD implement per-HIT configuration of > the inactivity timeout, allowing statically configured HIP > associations to stay alive for days, even when inactive." Needless to say but fine with me. > 5) At the Minneapolis WG meeting, when we were discussing future > extensibility of HIP, Pekka brought up a suggestion that we maybe > renumber the parameters and message types so as to leave some > room for insertion. Although mainly a base spec issue, I bring > this up here because we have selected ESP_INFO to be parameter > number 1 (so that it is easily accessible for inspection by > middleboxes). > > Do we want to leave some room at the top end of this parameter > space for future parameters, and get better spacing between > the ones we have? I think it would be wise. > 6) Section 6.8 may need some refinement based on resolution > of similar "simultaneous handshake" issues raised by Aura > (regarding who takes role of Initiator and Responder if > UPDATEs cross on the wire). [Can't make any quick comments until there is text to comment; Petri are you planning to address this?] > 7) In the definition of ESP_INFO, there is some language > regarding the binding of SPIs to addresses: Fine as such with me, but maybe we should add some explanation w.r.t. the wording and REAs? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Wed May 25 15:22: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 PAA11998 for ; Wed, 25 May 2005 15:22: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 1Db1Rv-0005GC-Sq; Wed, 25 May 2005 15:21:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1Ru-0005Fk-LS for hipsec@megatron.ietf.org; Wed, 25 May 2005 15:21:50 -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 PAA11847 for ; Wed, 25 May 2005 15:21:49 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db1kK-0006E7-Uz for hipsec@ietf.org; Wed, 25 May 2005 15:40:54 -0400 Received: from inside.nomadiclab.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 6A237212C40 for ; Wed, 25 May 2005 22:21:38 +0300 (EEST) Date: Wed, 25 May 2005 22:21:38 +0300 (EEST) From: Petri Jokela To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Hipsec] Base draft, snapshot 25.05.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 I uploaded the current version of the base draft to our server, the snapshot is dated 25.5.2005 (250505): http://hip4inter.net/draft.php The diff is between the 13th of May and this newer version. The diff is, unfortunately, a bit broken at the end of the document. Open issue: There is one comment about the CER packet: the description is unclear. I haven't yet touched that, but the question is: should I? The following editions have been made: - New IANA section - New Appendix C (sample Cookie handling at the Responder, based on Aura's comments) - ECHO_REQ/RESP messages numbering changed so that both are now critical (earlier, ECHO_REQ/RESP inside the SIGNATURE were not marked as critical, but outside they were). I couldn't find any reasoning for the different numbering from earlier mails. - ENCRYPTED parameter description and HMAC calculation (6.3.1) changed (based on Miika's and Jeff's mail) - 6.6 Changed the statement "Under no circumstances does the HIP state machine transition upon sending an R1" to only recommendation. In another place in the document it is said that the host may keep information about incoming I1s which means keeping some kind of state. Because this is an implementation issue, I don't think that we can mandate the implementation not to keep state based on I1-messages. But: please comment this edition. /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 May 25 16:15: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 QAA22566 for ; Wed, 25 May 2005 16:15: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 1Db280-0006qI-WC; Wed, 25 May 2005 16:05:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db27z-0006q3-SX for hipsec@megatron.ietf.org; Wed, 25 May 2005 16:05: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 QAA18919 for ; Wed, 25 May 2005 16:05:18 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db2QQ-0008S6-NW for hipsec@ietf.org; Wed, 25 May 2005 16:24:24 -0400 Received: from inside.nomadiclab.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 20F3D212C40; Wed, 25 May 2005 23:05:09 +0300 (EEST) Date: Wed, 25 May 2005 23:05:09 +0300 (EEST) From: Petri Jokela To: "Henderson, Thomas R" Subject: RE: [Hipsec] Pre-version: ESP draft In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.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: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Tue, 24 May 2005, Henderson, Thomas R wrote: > 1) There is presently one open issue in the HIP WG issue tracker for > this draft (http://hip4inter.net/cgi-bin/roundup.cgi/hip-esp/index). Unfortunately, the ESP tracker has been broken (seems to work now...) and is badly out of date. > So maybe this issue is now closed? I closed the original issue. > 5) At the Minneapolis WG meeting, when we were discussing future > extensibility of HIP, Pekka brought up a suggestion that we maybe > renumber the parameters and message types so as to leave some > room for insertion. Although mainly a base spec issue, I bring > this up here because we have selected ESP_INFO to be parameter > number 1 (so that it is easily accessible for inspection by > middleboxes). > > Do we want to leave some room at the top end of this parameter > space for future parameters, and get better spacing between > the ones we have? I'll see this together with the base spec parameter numbering and make a new proposal about numbering. I opened some issues on the tracker related to rest of the 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 May 30 07:48: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 HAA07924 for ; Mon, 30 May 2005 07:48: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 1Dcij6-00024W-QT; Mon, 30 May 2005 07:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcij5-00024Q-HT for hipsec@megatron.ietf.org; Mon, 30 May 2005 07:46:35 -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 HAA07799 for ; Mon, 30 May 2005 07:46:34 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcj2T-0006wq-9x for hipsec@ietf.org; Mon, 30 May 2005 08:06:38 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 22340212C40; Mon, 30 May 2005 14:46:23 +0300 (EEST) Message-ID: <429AFD0F.2040002@nomadiclab.com> Date: Mon, 30 May 2005 14:46:23 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petri Jokela References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.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: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] 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 Petri Jokela wrote: > On Tue, 24 May 2005, Henderson, Thomas R wrote: >> 5) At the Minneapolis WG meeting, when we were discussing future >> extensibility of HIP, Pekka brought up a suggestion that we maybe >> renumber the parameters and message types so as to leave some >> room for insertion. Although mainly a base spec issue, I bring >> this up here because we have selected ESP_INFO to be parameter >> number 1 (so that it is easily accessible for inspection by >> middleboxes). >> >> Do we want to leave some room at the top end of this parameter >> space for future parameters, and get better spacing between >> the ones we have? > > > I'll see this together with the base spec parameter numbering and make a > new proposal about numbering. > > I opened some issues on the tracker related to rest of the comments. Here is a set type values for TLVs to get some space for possible additions (in the type value area 1-511). Comments on the following values? OLD NEW ESP draft: ESP_INFO 1 41 Base draft: R1_COUNTER 2 64 PUZZLE 5 91 SOLUTION 7 101 SEQ 11 131 ACK 13 141 DIFFIE_HELLMAN 15 171 HIP_TRANSFORM 17 201 ENCRYPTED 21 257 HOST_ID 35 321 CERT 64 384 NOTIFY 256 448 /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 May 31 09:19:15 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 JAA08221 for ; Tue, 31 May 2005 09:19:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd6as-0007yI-G8; Tue, 31 May 2005 09:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd6ap-0007y5-UO for hipsec@megatron.ietf.org; Tue, 31 May 2005 09:15:40 -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 JAA07882 for ; Tue, 31 May 2005 09:15:38 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd6uS-0002GK-Do for hipsec@ietf.org; Tue, 31 May 2005 09:35:56 -0400 Received: from inside.nomadiclab.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id DBAB2212C40; Tue, 31 May 2005 16:15:27 +0300 (EEST) Date: Tue, 31 May 2005 16:15:27 +0300 (EEST) From: Petri Jokela To: "Ahrenholz, Jeffrey M" In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D7EF0@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: References: <0DF156EE7414494187B087A3C279BDB40D7EF0@XCH-NW-6V1.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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: hipsec@ietf.org Subject: [Hipsec] 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 I uploaded the ESP draft (snapshot + diff from previous) to: http://hip4inter.net/drafts.php (version dated 31.05.05) There are three open issues at the moment in the roundup tracker http://hip4inter.net/cgi-bin/roundup.cgi/hip-esp/index Two of them are commented inline in the following answer. In addition to those, the security section is still empty. Fixed also: timeout issue (issue #2), renumbering of ESP_INFO (issue #3), and ESP_INFO definition (issue #5). On Mon, 16 May 2005, Ahrenholz, Jeffrey M wrote: > Date: Mon, 16 May 2005 11:42:55 -0700 > From: "Ahrenholz, Jeffrey M" > To: Petri Jokela , hipsec@ietf.org > Subject: RE: [Hipsec] Pre-version: ESP and Base drafts > > - section "ESP packet processing" > "As these mechanisms can be located..." - this sentence is unclear to > me, but I do not have a suggested rewrite. I made a change to the text. "These mechanisms can be considered to be on the network side of IPsec, thus they cannot add any integrity or conficentiality problems that would not exist without them." Is this any better? > - For all AES references (3 occurrences), RFC 2451 should be RFC 3602; > RFC 2451 contains no mention of AES, should be removed from references Fixed. > - 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. > - For the sentence "...exchange information about the used protocols and > other...", is there another term besides "used protocols" that should be > used here, such as "transforms used"? Fixed as proposed. > - the key index field of the ESP_INFO parameter is mentioned for the > rekeying section, but not in the preceding section when discussing the > ESP_INFO. I couldn't now find the place in text. Can you give a pointer to that? > - When talking about the IP address to HIT conversion, what about the > IPv4 case? Should LSIs be mentioned also? A new bullet in "Processing incoming application data": If LSIs are used, the address field is converted to contain the LSI value before the packet is sent to the application. > - In the "finalizing rekeying" section it says to use the lowest Keymat > Index of the two ESP_INFO parameters, but earlier in the > "transform_reply" section, is says "it is RECOMMENDED that the system > use the greater value received from the peer" ??? Fixed this. It should bet the greater of the two values. > - It should be noted somewhere that HIP packets should bypass IPsec > policies, i.e. UPDATE packet transmitted in the clear even though an > active association is in place, or all protocol 99 packets bypass IPsec > processing, etc. 6. Packet processing Packet processing is mainly defined in the HIP base specification [5]. This section describes the changes and new requirements for packet handling when the ESP transport format is used. Note that all HIP packets (currently protocol 99) MUST bypass IPsec processing. /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 May 31 11:05: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 LAA16847 for ; Tue, 31 May 2005 11:05:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8Hq-0007XP-Ty; Tue, 31 May 2005 11:04:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8Hp-0007Wv-5L for hipsec@megatron.ietf.org; Tue, 31 May 2005 11:04:09 -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 LAA16793 for ; Tue, 31 May 2005 11:04:07 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd8bO-0004La-L3 for hipsec@ietf.org; Tue, 31 May 2005 11:24:27 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA08831; Tue, 31 May 2005 10:03:50 -0500 (CDT) 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 j4VF3op04267; Tue, 31 May 2005 10:03:50 -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); Tue, 31 May 2005 08:03:47 -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: Tue, 31 May 2005 08:03:47 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C066493BA@xch-nw-27.nw.nos.boeing.com> Thread-Topic: Numbering of TLVs Thread-Index: AcVlDTXV3X4lvwWcQZmp8TGMtWRBUAA23Hcg From: "Henderson, Thomas R" To: "Petri Jokela" X-OriginalArrivalTime: 31 May 2005 15:03:47.0969 (UTC) FILETIME=[F27C6710:01C565F1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 > Comments on the following values? >=20 > OLD NEW > ESP draft: > ESP_INFO 1 41 >=20 > Base draft: > R1_COUNTER 2 64 > PUZZLE 5 91 > SOLUTION 7 101 > SEQ 11 131 > ACK 13 141 > DIFFIE_HELLMAN 15 171 > HIP_TRANSFORM 17 201 > ENCRYPTED 21 257 > HOST_ID 35 321 > CERT 64 384 > NOTIFY 256 448 >=20 I strongly support getting improved spacing. I have been staring at the above list for a few minutes, trying to discern the numbering pattern. Is there one? The numbering patterns that seem to be in effect are: - parameters protected by signature are in the range 1-4096 - except for nonces and transforms, the range is really 1-511 - nonces are numbered in the range 1022-1024 - transforms are numbered 2048-4096 - crypto parameters are numbered between (2^16 - 291) and (2^16 - 257) While we are doing this, we should consider also the known parameters that exist in the other core drafts, and that are likely to form the complete set of parameters approved in this cycle of WG documents: OLD ESP_INFO 1 R1_COUNTER 2 LOCATOR 3 PUZZLE 5 SOLUTION 7 SEQ 11 ACK 13 DIFFIE_HELLMAN 15 HIP_TRANSFORM 17 ENCRYPTED 21 HOST_ID 35 CERT 64 NOTIFY 256 ECHO_REQUEST 1022 ECHO_RESPONSE 1024 ESP_TRANSFORM 2048=09 HMAC 65245 HMAC_2 65247 HIP_SIGNATURE_2 65277 HIP_SIGNATURE 65279 ECHO_REQUEST 65281 ECHO_RESPONSE 65283 FROM 65470 RVS_HMAC 65472 VIA_RVS 65474 I think it might be useful to state the numbering rationale, and then go for equal spacing in the various sub-ranges: "Because the ordering (from lowest to highest) of HIP parameters is strictly enforced, the parameter type values for existing parameters have been spaced to allow for future protocol extensions. Parameters numbered between 0-1023 are used in HIP handshake and update procedures and are covered by signatures. Parameters numbered between 1024-2047 are reserved. Parameters numbered between 2048-4095 are used for parameters related to HIP transform types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 are reserved. Parameters numbered beteween 61440-62463 are used for signatures and signed MACs. Parameters numbered between 62464-63487 are used for parameters that fall outside of the signed area of the packet. Parameters numbered between 63488-64511 are used for rendezvous and other relaying services. Parameters numbered between 64512-65535 are reserved." Then, I suggest taking these ranges and allocating each parameter to be roughly equally spaced by some increment, and in the future, if we need to insert a new parameter between two existing ones, it is numbered to split the difference between the two, etc. 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=09 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 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue May 31 11:17:37 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 LAA17880 for ; Tue, 31 May 2005 11:17:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8U3-0001W5-2P; Tue, 31 May 2005 11:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8U1-0001Vj-9D for hipsec@megatron.ietf.org; Tue, 31 May 2005 11:16:45 -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 LAA17795 for ; Tue, 31 May 2005 11:16:43 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd8ne-0004cx-SR for hipsec@ietf.org; Tue, 31 May 2005 11:37:03 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA24587; Tue, 31 May 2005 10:16:34 -0500 (CDT) 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 j4VFGYp24556; Tue, 31 May 2005 10:16:34 -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); Tue, 31 May 2005 08:16:27 -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: Tue, 31 May 2005 08:16:26 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B8A@xch-nw-27.nw.nos.boeing.com> Thread-Topic: ECHO_* parameters Thread-Index: AcVlDTXV3X4lvwWcQZmp8TGMtWRBUAA5VfIg From: "Henderson, Thomas R" To: "Petri Jokela" X-OriginalArrivalTime: 31 May 2005 15:16:27.0468 (UTC) FILETIME=[B72EC0C0:01C565F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] 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: quoted-printable 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. Tom=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Tue May 31 12:25: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 MAA23064 for ; Tue, 31 May 2005 12:25: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 1Dd9WL-0003qH-CB; Tue, 31 May 2005 12:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd9WI-0003qC-SY for hipsec@megatron.ietf.org; Tue, 31 May 2005 12:23:11 -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 MAA22973 for ; Tue, 31 May 2005 12:23:08 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd9pv-00060t-Vl for hipsec@ietf.org; Tue, 31 May 2005 12:43:29 -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 JAA19159; Tue, 31 May 2005 09:22:57 -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 j4VGMun26698; Tue, 31 May 2005 09:22:56 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 09:22:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2005 09:21:59 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: ESP draft snapshot 31.05.05 Thread-Index: AcVl4tIPMmZWKAXGR0q6qX7a0KLKmwAE18mQ From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" X-OriginalArrivalTime: 31 May 2005 16:22:53.0678 (UTC) FILETIME=[FF2620E0:01C565FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Petri, please see below... > "These mechanisms can be considered to be on the network side=20 > of IPsec,=20 > thus they cannot add any integrity or conficentiality=20 > problems that would=20 > not exist without them." >=20 > Is this any better? Yes, this is better. > > - The 64-bit sequence number is interesting, but: To=20 > implement it, you=20 > > just keep an additional 32-bit counter representing the=20 > upper bits? Upon=20 > > rollover of the lower 32-bits, you increment the upper. What is the=20 > > usefulness of this? i.e. how can the replay window be=20 > enforced if it is=20 > > not part of each packet? Maybe we could have more text on=20 > this or an=20 > > appropriate reference. >=20 > Hmm.. I'm not sure how to fix this. Earlier there was some talk about=20 > having AES-CBC IV vectors from the sequence number, but the=20 > RFC3602 states=20 > that the IV must be random. So is there a benefit to using these 64-bit sequence numbers? Why do we need them? > > - the key index field of the ESP_INFO parameter is=20 > mentioned for the=20 > > rekeying section, but not in the preceding section when=20 > discussing the=20 > > ESP_INFO. >=20 > 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. The other various revisions noted in this email look good. -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec