From ticsa-info-admin@honor.trusecure.com Tue Feb 1 05:01:20 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 FAA08952 for ; Tue, 1 Feb 2005 05:01:20 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 72FCA7366 for ; Tue, 1 Feb 2005 05:00:43 -0500 (EST) Date: Tue, 01 Feb 2005 05:00:43 -0500 Message-ID: <20050201100043.17430.43652.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 Wed Feb 2 00:27:38 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 AAA29095 for ; Wed, 2 Feb 2005 00:27:38 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1E7137323; Wed, 2 Feb 2005 00:27:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 6CD5C7321 for ; Wed, 2 Feb 2005 00:26:42 -0500 (EST) 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 XAA19369; Tue, 1 Feb 2005 23:26:36 -0600 (CST) Received: from xch-nwbh-01.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 j125QXJ19672; Tue, 1 Feb 2005 23:26:33 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Feb 2005 21:26:35 -0800 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] (Temporarily) restricting HIT values to ones starting with 01 and 10? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648E03@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? Thread-Index: AcUHlZ/ZszDQ/LaVSCSPF/Bz2KZuBQBUP1gA From: "Henderson, Thomas R" To: "Pekka Nikander" Cc: X-OriginalArrivalTime: 02 Feb 2005 05:26:35.0083 (UTC) FILETIME=[C2EEE1B0:01C508E7] 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, 1 Feb 2005 21:26:34 -0800 Date: Tue, 1 Feb 2005 21:26:34 -0800 Content-Transfer-Encoding: quoted-printable > Since I haven't seen any objections to this proposed=20 > restriction, I hereby suggest that we add the following text=20 > to the HIT section in the base specification. Comments? >=20 > --Pekka Generally OK with me-- a few minor comments below. >=20 > To facilitate experimentation and make certain kind of=20 > implementations easier, the following restrictions are=20 > temporarily placed on HITs. =20 > These restriction are to be lifted at the end of 2008. That=20 > is, after January 1st 2009, any implementation claiming=20 > conformance to this specification MUST accept any HITs from=20 > peers and be able to process them normally. >=20 > The restrictions: Before the end of 2008, all implementations=20 > SHOULD restrict the HITs they generate to ones whose=20 > upper-most (left-most) two bits are either binary 01 or 10. =20 > That is, when generating new HIs, if the resulting HIT has as=20 > its first two bits as 00 or 11, the implementation SHOULD=20 > generate new HIs until it generates one that fulfils this=20 s/fulfils/fulfills/ > restriction. Additionally, a conforming implementation MAY=20 > refuse to communicate with a peer that has a HIT with the=20 > upper-most bits either 00 or 11. When refusing a HIP=20 > connection on this bases, the implementation MUST send an R2=20 > with a NOTIFY payload, with the NOTIFY code being=20 > UNSUPPORTED_HIT_VALUE_RANGE. MAY instead of MUST (since NOTIFY is optional), and add "Any such NOTIFYs may be rate-limited" >=20 > A rationale: One way to implement HIP is to use unmodified=20 > IPv6, TCP and UDP implementations in the stack, using HITs in=20 > the place of IPv6 addresses. In such an implementation,=20 > modifications are only needed at the API level, where it may=20 > be necessary to convert HITs into LSIs and vice versa, and at=20 > or below ESP, where it is necessary to convert HITs into=20 > locators (IP addresses) and vice versa. However, if the IPv6=20 > address space and the HIT value space overlap, it becomes=20 > quite hard to define secure IPsec policies. Furthermore,=20 > there is also the possibility of having a conflict between a=20 > HIT value and an IPv6 address, leading to potential confusion=20 > within the stack. >=20 > This restriction temporarily allows such simple minded=20 > implementations.=20 > It is expected that such implementations will eventually=20 > migrate to a different implementation details, e.g., by=20 > tagging the values either as HITs or IPv6 addresses. =20 > However, tagging the values may be hard in existing IPv6=20 > implementations; the purpose of this restriction is to allow=20 > such HIP implementations that rely on and patch on existing=20 > IPv6 implementations. >=20 I suggest replacing the above two paragraphs with: A rationale: One way to experimentally implement HIP is to use=20 unmodified IPv6, TCP and UDP implementations in the stack, using HITs=20 in the place of IPv6 addresses. This modification makes it easier to=20 use existing IPv6 data structures to hold HITs and to distinguish=20 between the two data types. If the IPv6 address space and the HIT value space overlap, it becomes hard to define secure IPsec policies without explicitly tagging the values either as HITs or IPv6 addresses. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 2 08:03:21 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 IAA01324 for ; Wed, 2 Feb 2005 08:03:20 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id BEA92731B; Wed, 2 Feb 2005 05:57:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 48C347309 for ; Wed, 2 Feb 2005 05:56:01 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 546C2212C0A; Wed, 2 Feb 2005 12:55:49 +0200 (EET) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648E03@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648E03@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Pekka Nikander Subject: Re: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619.2) 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, 2 Feb 2005 12:56:13 +0200 Date: Wed, 2 Feb 2005 12:56:13 +0200 Content-Transfer-Encoding: 7bit >> ... Additionally, a conforming implementation MAY >> refuse to communicate with a peer that has a HIT with the >> upper-most bits either 00 or 11. When refusing a HIP >> connection on this bases, the implementation MUST send an R2 >> with a NOTIFY payload, with the NOTIFY code being >> UNSUPPORTED_HIT_VALUE_RANGE. > > MAY instead of MUST (since NOTIFY is optional), and add > "Any such NOTIFYs may be rate-limited" Ok. > I suggest replacing the above two paragraphs with: > > A rationale: One way to experimentally implement HIP is to use > unmodified IPv6, TCP and UDP implementations in the stack, using HITs > in the place of IPv6 addresses. This modification makes it easier to > use existing IPv6 data structures to hold HITs and to distinguish > between the two data types. If the IPv6 address space and the HIT > value > space overlap, it becomes hard to define secure IPsec policies without > explicitly tagging the values either as HITs or IPv6 addresses. Looks good to me. If nobody has any objections or comments, I suggest that Petri would add the resulting text to the next version. Opinions, others? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 2 08:53:21 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 IAA03955 for ; Wed, 2 Feb 2005 08:53:21 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C98487325; Wed, 2 Feb 2005 06:03:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from enso.acheron.indranet.co.nz (unknown [203.167.203.10]) by honor.icsalabs.com (Postfix) with ESMTP id 1A3877325 for ; Wed, 2 Feb 2005 06:02:04 -0500 (EST) Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id AAA22067; Thu, 3 Feb 2005 00:02:01 +1300 In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C06648E03@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <392a4561db826a26fbf7a796548f7c46@indranet.co.nz> Content-Transfer-Encoding: 7bit Cc: "Henderson, Thomas R" , From: Andrew McGregor Subject: Re: [Hipsec] (Temporarily) restricting HIT values to ones starting with 01 and 10? To: Pekka Nikander X-Mailer: Apple Mail (2.619.2) 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: Thu, 3 Feb 2005 00:01:19 +1300 Date: Thu, 3 Feb 2005 00:01:19 +1300 Content-Transfer-Encoding: 7bit On 2/02/2005, at 11:56 PM, Pekka Nikander wrote: >> >> A rationale: One way to experimentally implement HIP is to use >> unmodified IPv6, TCP and UDP implementations in the stack, using HITs >> in the place of IPv6 addresses. This modification makes it easier to >> use existing IPv6 data structures to hold HITs and to distinguish >> between the two data types. If the IPv6 address space and the HIT >> value >> space overlap, it becomes hard to define secure IPsec policies without >> explicitly tagging the values either as HITs or IPv6 addresses. > > Looks good to me. > > If nobody has any objections or comments, I suggest that Petri > would add the resulting text to the next version. > > Opinions, others? > > --Pekka (unlurks) Looks good to me. I had no other comments, and Tom has just answered the last one. Andrew _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Feb 3 05:55:37 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 FAA09428 for ; Thu, 3 Feb 2005 05:55:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 4A51F731C; Thu, 3 Feb 2005 05:55:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 28F8B7304 for ; Thu, 3 Feb 2005 05:54:54 -0500 (EST) Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id A49CD212CAB; Thu, 3 Feb 2005 12:54:56 +0200 (EET) Message-ID: <42020300.5040302@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Draft: ESP usage in HIP 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: Thu, 03 Feb 2005 12:54:56 +0200 Date: Thu, 03 Feb 2005 12:54:56 +0200 Content-Transfer-Encoding: 7bit Folks, The ESP text is moved now from the Base specification into a new draft. The preliminary version 1 of this draft is available at: http://www.hip4inter.net/drafts.php Some notes: The ESP setup and rekeying processes are defined as conceptual protocols HIP ESP Setup (HES) and HIP ESP Rekeying (HER). In a usual implementation, the contents of these packets is put in base exchange packets and UPDATEs, respectively. The NES and SPI are proposed to be replaced with a single parameter: ESP_INFO. Comments are appreciated. The intention is to make fixes during next week and submit the draft before the IETF deadline for -00 drafts (Feb 14) BR, 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-admin@honor.trusecure.com Thu Feb 3 10:01:37 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 KAA29308 for ; Thu, 3 Feb 2005 10:01:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 17594731C; Thu, 3 Feb 2005 10:01:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from nairobi.ucdavis.edu (nairobi.ucdavis.edu [169.237.104.168]) by honor.icsalabs.com (Postfix) with ESMTP id 3CCD57304 for ; Thu, 3 Feb 2005 06:31:15 -0500 (EST) Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by nairobi.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j13BUtYg029649; Thu, 3 Feb 2005 03:30:56 -0800 (PST) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j13BUtXr021963; Thu, 3 Feb 2005 03:30:55 -0800 (PST) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id j13BUgUv021962; Thu, 3 Feb 2005 03:30:42 -0800 (PST) Message-Id: <200502031130.j13BUgUv021962@tremex.ucdavis.edu> To: fanzhao@ucdavis.edu 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: Thu, 3 Feb 2005 03:30:42 -0800 (PST) Date: Thu, 3 Feb 2005 03:30:42 -0800 (PST) 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-admin@honor.trusecure.com Thu Feb 3 13:51:38 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 NAA26001 for ; Thu, 3 Feb 2005 13:51:38 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A5416730D; Thu, 3 Feb 2005 13:51:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-bedford-dr.mitre.org (smtpproxy2.mitre.org [192.160.51.65]) by honor.icsalabs.com (Postfix) with ESMTP id 455567304 for ; Thu, 3 Feb 2005 13:50:19 -0500 (EST) Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j13IoMa00506 for ; Thu, 3 Feb 2005 13:50:22 -0500 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 57AEC4F8DA for ; Thu, 3 Feb 2005 13:50:22 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id j13IoMl00465 for ; Thu, 3 Feb 2005 13:50:22 -0500 Received: from mm123645-pc.mitre.org (129.83.57.15) by mailhub2.mitre.org with SMTP id 8112742; Thu, 03 Feb 2005 13:50:16 -0500 Message-ID: <42027267.5090503@mitre.org> From: Kevin Grace User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Rendezvous Server Concerns 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: Thu, 03 Feb 2005 13:50:15 -0500 Date: Thu, 03 Feb 2005 13:50:15 -0500 Content-Transfer-Encoding: 7bit After cogitating on the topic of Rendezvous Servers for HIP, some concerns have emerged that should probably be discussed within the WG. It seems that these concerns are pretty fundamental and may ultimately limit the desire to pursue Rendezvous Servers. From reading draft-ietf-hip-rvs-00.txt, two reasons are given to motivate the use of Rendezvous Servers. The first has to do with the cost of resigning DNS zones after an update, the second has to do with stale entries in caches being used to respond to queries...the relevant pararaphs are: One drawback of using dynamic DNS updates in this way is the cost of updating secure zones. Re-signing an entire zone whenever the IP addresses of one entry change places a high cost on the DNS server. Using dynamic DNS to update HI->IP mappings may thus not be appropriate when changes of IP addresses are frequent. .... Another concern with using the DNS to support HIP node mobility is the propagation time of updated DNS entries. DNS servers frequently cache DNS responses to reduce the load on the primary servers. During the time-to-live associated with a DNS response, DNS servers may answer additional requests for the same DNS entry from their local caches instead of contacting the primary servers. Thus, even after a HIP node updates its DNS entry, the DNS can still serve the old entry until the cached responses expire. This can lead to communication problems, because peers may try to contact a HIP node at an IP address it is no longer reachable at. The Rendezvous Server approach seeks to avoid sending dynamic updates to DNS for mobile nodes and instead creates a new resource record type in DNS that will allow HIP aware nodes to learn of the IP address(es) or hostname(s) of a mobile node's relatively static Rendezvous Server. It seems that this approach will prevent a mobile HIP node from being reachable by *all* non-HIP nodes, whenever it moves and its current IP address is not the IP address stored in DNS. This seems like an unacceptable outcome. Does it not make more sense for the mobile node to perform a dynamic DNS update so that it can be reached by non-HIP nodes? And if that's the case, then doesn't the RVS become unnecessary since its raison d'etre was to avoid dynamic DNS updates? The second reason given to motivate the use of Rendezvous Servers was to avoid cache staleness problems. It seems that this can be directly solved simply by setting time-to-live values on mobile node resource records to very small values...again, Rendezvous Servers seem unnecessary. Are there any compelling reasons to pursue Rendezvous Servers that outweigh the loss of reachability that non-HIP nodes will experience? Regards, Kevin _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Feb 3 14:50:39 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 OAA00790 for ; Thu, 3 Feb 2005 14:50:39 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id AB112734D; Thu, 3 Feb 2005 14:50:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id B0661733F for ; Thu, 3 Feb 2005 14:49:12 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7940C212CB1; Thu, 3 Feb 2005 21:49:12 +0200 (EET) In-Reply-To: <42027267.5090503@mitre.org> References: <42027267.5090503@mitre.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Rendezvous Server Concerns To: Kevin Grace X-Mailer: Apple Mail (2.619.2) 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: Thu, 3 Feb 2005 21:49:36 +0200 Date: Thu, 3 Feb 2005 21:49:36 +0200 Content-Transfer-Encoding: 7bit > It seems that this approach will prevent a mobile HIP node from being > reachable by *all* non-HIP nodes, whenever it moves and its current IP > address is not the IP address stored in DNS. This seems like an > unacceptable outcome. Nothing prevents you from using some non-HIP mechanism to remain reachable by non-HIP nodes. For example, if you can arrange one of your rendezvous servers (or some other node) to forward packets to you and packets sent by you, i.e. what is sometimes called a HIP proxy, you can certainly make your A / AAAA record to point to that node. But that is beyond the scope of core HIP, and beyond the scope of the current WG charter. Two questions: - Have you read what the architecture draft says about rendezvous? Does that make sense to you? http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-02.txt - Are you familiar with more advanced rendezvous concepts, like Hi3 or rendezvous-based NAT traversal? http://www.watersprings.org/pub/id/draft-nikander-hiprg-hi3-00.txt Note that the advanced rendezvous issues are being discussed at the *Research* Group side, as they go beyond the current WG charter. --Pekka Nikander _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Feb 3 15:58: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 PAA08065 for ; Thu, 3 Feb 2005 15:58:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 16502734D; Thu, 3 Feb 2005 15:58:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by honor.icsalabs.com (Postfix) with ESMTP id 1ABEB733F for ; Thu, 3 Feb 2005 15:57:54 -0500 (EST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j13KvtS18638 for ; Thu, 3 Feb 2005 15:57:55 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id AE283BF7D for ; Thu, 3 Feb 2005 15:57:55 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j13Kvtm18558; Thu, 3 Feb 2005 15:57:55 -0500 Received: from mm123645-pc.mitre.org (129.83.57.15) by mailhub1.mitre.org with SMTP id 12864746; Thu, 03 Feb 2005 15:57:49 -0500 Message-ID: <4202904C.8070909@mitre.org> From: Kevin Grace User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Rendezvous Server Concerns References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> In-Reply-To: <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> 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: Thu, 03 Feb 2005 15:57:48 -0500 Date: Thu, 03 Feb 2005 15:57:48 -0500 Content-Transfer-Encoding: 7bit Hi Pekka, Thanks for the response. My comments are interspersed below... >> It seems that this approach will prevent a mobile HIP node from being >> reachable by *all* non-HIP nodes, whenever it moves and its current IP >> address is not the IP address stored in DNS. This seems like an >> unacceptable outcome. > > > Nothing prevents you from using some non-HIP mechanism to remain > reachable by non-HIP nodes. For example, if you can arrange one > of your rendezvous servers (or some other node) to forward packets > to you and packets sent by you, i.e. what is sometimes called a > HIP proxy, you can certainly make your A / AAAA record to point > to that node. But that is beyond the scope of core HIP, and > beyond the scope of the current WG charter. > So rather than just letting mobile nodes do dynamic DNS updates, you are suggesting a better alternative is to: 1) Implement and deploy rendezvous servers 2) Modify existing DNS implementations to support a new resource record type for the rendezvous server (doubtful that proprietary implementations would ever evolve to support it) 3) Specify, implement, and deploy HIP proxies (all of which are challenging) and then possibly suffer the resultant triangle based routing Doesn't that seem like alot of effort just to avoid dynamic DNS updates from mobile nodes? > Two questions: > > - Have you read what the architecture draft says about rendezvous? Yep. > Does that make sense to you? No...not given that dynamic DNS updates appear to obviate the need for Rendezvous Servers. As for the problem of both nodes changing their addresses at the same time, HIP implementations could detect the loss of connectivity and query DNS for the peer's new IP address... > - Are you familiar with more advanced rendezvous concepts, like > Hi3 or rendezvous-based NAT traversal? > Not really, though I did quickly skim the doc and honestly I don't see how it makes a compelling argument in support of Rendezvous Servers when someone wants to use HIP simply for the purpose of maintaining connectivity with mobile nodes. Are there reasons beside not wanting to perform dynamic DNS updates that justify all the implementation and deployment costs that Rendezvous Servers seem to require? Thanks, Kevin _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Feb 3 16:13: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 QAA10532 for ; Thu, 3 Feb 2005 16:13:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 4DB78732C; Thu, 3 Feb 2005 16:13:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from enso.acheron.indranet.co.nz (unknown [203.167.203.10]) by honor.icsalabs.com (Postfix) with ESMTP id 164CE7304 for ; Thu, 3 Feb 2005 16:12:15 -0500 (EST) Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id KAA11849; Fri, 4 Feb 2005 10:11:59 +1300 In-Reply-To: <4202904C.8070909@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Pekka Nikander , hipsec@honor.trusecure.com From: Andrew McGregor Subject: Re: [Hipsec] Rendezvous Server Concerns To: Kevin Grace X-Mailer: Apple Mail (2.619.2) 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: Fri, 4 Feb 2005 10:11:20 +1300 Date: Fri, 4 Feb 2005 10:11:20 +1300 Content-Transfer-Encoding: 7bit On 4/02/2005, at 9:57 AM, Kevin Grace wrote: > Hi Pekka, > > Thanks for the response. My comments are interspersed below... >> > So rather than just letting mobile nodes do dynamic DNS updates, you > are suggesting a better alternative is to: > 1) Implement and deploy rendezvous servers > 2) Modify existing DNS implementations to support a new resource > record type for the rendezvous server (doubtful that proprietary > implementations would ever evolve to support it) > 3) Specify, implement, and deploy HIP proxies (all of which are > challenging) and then possibly suffer the resultant triangle based > routing > > Doesn't that seem like alot of effort just to avoid dynamic DNS > updates from mobile nodes? Not if you want to support really low-latency mobility. Personally, I've always thought of the RVS as being supplementary to dynamic DNS; use it when either you can't do a DNS update (for example if you're not routable, and the RVS is going to send you to a proxy) or you want it done too fast (in the middle of a VoIP call, for example). > >> Two questions: >> >> - Have you read what the architecture draft says about rendezvous? > > Yep. > >> Does that make sense to you? > > No...not given that dynamic DNS updates appear to obviate the need for > Rendezvous Servers. As for the problem of both nodes changing their > addresses at the same time, HIP implementations could detect the loss > of connectivity and query DNS for the peer's new IP address... And lose connectivity for several seconds, at the very least. RVS does take a few round trips, but in most of the cases of interest that's much better than seconds. > > Are there reasons beside not wanting to perform dynamic DNS updates > that justify all the implementation and deployment costs that > Rendezvous Servers seem to require? Latency and providing some basics for the research group results to build on. Andrew _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Feb 4 05:10: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 FAA08855 for ; Fri, 4 Feb 2005 05:10:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 436BA7316; Fri, 4 Feb 2005 05:10:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 5EDDE7310 for ; Fri, 4 Feb 2005 05:09:31 -0500 (EST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id EF185212C0A; Fri, 4 Feb 2005 12:09:26 +0200 (EET) In-Reply-To: References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Andrew McGregor , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Rendezvous Server Concerns To: Kevin Grace X-Mailer: Apple Mail (2.619.2) 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: Fri, 4 Feb 2005 08:01:44 +0200 Date: Fri, 4 Feb 2005 08:01:44 +0200 Content-Transfer-Encoding: 7bit Trying to summarise, the WG motivation for rendezvous servers is latency. You just can't get sub-second (or even sub-10-second) latencies from the DNS. Going to anywhere below 30 minutes will have DNS performance consequences that will make the DNS WG to object, and possibly IESG to reject. At the RG side, the situation is richer. We have the new possibilities, such as Hi3. We have the need to act without DNS names, i.e., using HITs as primary identity handles. Thirdly, there is some tendency in seeking for alternatives for the DNS. What comes to your comment: >> So rather than just letting mobile nodes do dynamic DNS updates, you >> are suggesting a better alternative is to: >> 1) Implement and deploy rendezvous servers >> 2) Modify existing DNS implementations to support a new resource >> record type for the rendezvous server (doubtful that proprietary >> implementations would ever evolve to support it) >> 3) Specify, implement, and deploy HIP proxies (all of which are >> challenging) and then possibly suffer the resultant triangle based >> routing >> >> Doesn't that seem like alot of effort just to avoid dynamic DNS >> updates from mobile nodes? If you are saying that the requirements for added infrastructure may make HIP deployment harder, you are certainly right. To mitigate or counter that argument, we have to consider the following: - You can achieve small scale HIP deployment without DNS. That is what is happening now. People are using /etc/hosts to configure their peers' HITs. - For wider scale early deployment, you need proxies anyway. - There are concrete plans to deploy Hi3 in PlanetLab during this year. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Feb 4 09:16: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 JAA29410 for ; Fri, 4 Feb 2005 09:16:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C04277334; Fri, 4 Feb 2005 09:16:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-bedford.mitre.org (smtp-bedford-x.mitre.org [192.160.51.76]) by honor.icsalabs.com (Postfix) with ESMTP id 1425A7316 for ; Fri, 4 Feb 2005 09:15:11 -0500 (EST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j14EFAv25850 for ; Fri, 4 Feb 2005 09:15:10 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 2ED5DBF7E for ; Fri, 4 Feb 2005 09:15:10 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j14EF9V25753; Fri, 4 Feb 2005 09:15:09 -0500 Received: from mm123645-pc.mitre.org (129.83.82.66) by mailhub1.mitre.org with SMTP id 12880487; Fri, 04 Feb 2005 09:15:04 -0500 Message-ID: <42038367.5030507@mitre.org> From: Kevin Grace User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: Andrew McGregor , hipsec@honor.trusecure.com Subject: Re: [Hipsec] Rendezvous Server Concerns References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> In-Reply-To: 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: Fri, 04 Feb 2005 09:15:03 -0500 Date: Fri, 04 Feb 2005 09:15:03 -0500 Content-Transfer-Encoding: 7bit > Trying to summarise, the WG motivation for rendezvous servers is > latency. You just can't get sub-second (or even sub-10-second) > latencies from the DNS. Going to anywhere below 30 minutes will > have DNS performance consequences that will make the DNS WG to > object, and possibly IESG to reject. > Today, using readily available DNS implementations and without Rendezvous Servers, one can create an A record in an authoritative name server for a mobile host and assign it a time-to-live of 1 second. The longest the record could possibly be cached by non-authoritative name servers then is 1 second.When the node moves and changes IP addresses, it can successfully update its A record within the authoritative name server in less than a second. The total latency between when a node's address changes and when DNS is properly updated need not exceed a couple seconds and could well be closer to one second. This appears to be a perfectly legitimate usage of DNS. Why would the DNS WG or IESG have any authority or control over what an individual mobile node chooses for its time-to-live? On the other hand, using Rendezvous Servers will require modifications to DNS to support a new resource record type...this would definitely require acceptance by the DNS WG and unless demand for HIP is high, proprietary implementations of DNS may never be modified regardless of acceptance for the modifications within the DNS WG. The prospects here seem much less certain than simply adjusting time-to-live fields. >>> So rather than just letting mobile nodes do dynamic DNS updates, you >>> are suggesting a better alternative is to: >>> 1) Implement and deploy rendezvous servers >>> 2) Modify existing DNS implementations to support a new resource >>> record type for the rendezvous server (doubtful that proprietary >>> implementations would ever evolve to support it) >>> 3) Specify, implement, and deploy HIP proxies (all of which are >>> challenging) and then possibly suffer the resultant triangle based >>> routing >>> >>> Doesn't that seem like alot of effort just to avoid dynamic DNS >>> updates from mobile nodes? >> > > If you are saying that the requirements for added infrastructure > may make HIP deployment harder, you are certainly right. To > mitigate or counter that argument, we have to consider the > following: > > - You can achieve small scale HIP deployment without DNS. > That is what is happening now. People are using /etc/hosts > to configure their peers' HITs. One can achieve large scale HIP deployment without modifying DNS and without Rendezvous Servers. The HIP protocol appears to support optional certificates within the base exchange messages. By combining these certificates with HIP's opportunistic mode, there is a very simple and elegant way of obtaining a peer's host identity that is not vulnerable to man-in-the-middle attacks...and it doesn't require HIT's to be stored in DNS. > > - For wider scale early deployment, you need proxies anyway. Not if you avoid using Rendezvous Servers... HIP appears to be a wonderful mobility enabler and hopefully will be deployed widely. In order for that to happen though, it seems to make alot of sense to minimize the amount of complexity, effort, and acceptance which is required. Rendezvous Servers, modifying DNS, and HIP proxies seem to add lots of new challenges that are not really necessary in order for HIP to be widely deployable. The arguments in support of Rendezvous Servers (possibly reduced update latency, and "providing some basics for the research group results to build on") seem pretty thin; the arguments against them seem much more compelling...IMHO. Regards, Kevin _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Feb 4 10:46:37 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 KAA08352 for ; Fri, 4 Feb 2005 10:46:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 70E277334; Fri, 4 Feb 2005 10:46:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id C4C197311 for ; Fri, 4 Feb 2005 10:45:22 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id B55DC212C0A; Fri, 4 Feb 2005 17:45:18 +0200 (EET) In-Reply-To: <42038367.5030507@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Andrew McGregor , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Rendezvous Server Concerns To: Kevin Grace X-Mailer: Apple Mail (2.619.2) 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: Fri, 4 Feb 2005 17:45:43 +0200 Date: Fri, 4 Feb 2005 17:45:43 +0200 Content-Transfer-Encoding: 7bit Kevin, > Today, using readily available DNS implementations and without > Rendezvous Servers, one can create an A record in an authoritative > name server for a mobile host and assign it a time-to-live of 1 > second. The longest the record could possibly be cached by > non-authoritative name servers then is 1 second.When the node moves > and changes IP addresses, it can successfully update its A record > within the authoritative name server in less than a second. The total > latency between when a node's address changes and when DNS is properly > updated need not exceed a couple seconds and could well be closer to > one second. This is very good news indeed. Would you care to share us with a reference? > This appears to be a perfectly legitimate usage of DNS. Why would the > DNS WG or IESG have any authority or control over what an individual > mobile node chooses for its time-to-live? Well, I am certainly not a DNS expert. However, I have been told that you SHOULD not use TTL less than 30 minutes, or you will cause bad performance. But maybe all those people have been wrong. Googling revealed the following paper, which seems to indicate reverse: Performance and the Effectiveness of Caching, Jaeyeon Jung, Emil Sit, Hari Balakrishnan, Robert Morris Proc. ACM SIGCOMM Internet Measurement Workshop, 2001 http://nms.lcs.mit.edu/papers/dns-imw2001.html But they "fast" TTL seems still to be a few hundred seconds? >> - You can achieve small scale HIP deployment without DNS. >> That is what is happening now. People are using /etc/hosts >> to configure their peers' HITs. > > One can achieve large scale HIP deployment without modifying DNS and > without Rendezvous Servers. > The HIP protocol appears to support optional certificates within the > base exchange messages. By combining these certificates with HIP's > opportunistic mode, there is a very simple and elegant way of > obtaining a peer's host identity that is not vulnerable to > man-in-the-middle attacks...and it doesn't require HIT's to be stored > in DNS. If what you indicate about DNS is true, I would certain agree. OTOH, you still need a CA for that, but so do you need for many uses anyway. >> - For wider scale early deployment, you need proxies anyway. > > Not if you avoid using Rendezvous Servers... Yes, you do, as you have to support legacy hosts. They just don't work if you change your IP address dynamically. > HIP appears to be a wonderful mobility enabler and hopefully will be > deployed widely. In order for that to happen though, it seems to make > alot of sense to minimize the amount of complexity, effort, and > acceptance which is required. I fully agree. > Rendezvous Servers, modifying DNS, and HIP proxies seem to add lots of > new challenges that are not really necessary in order for HIP to be > widely deployable. I'm afraid we can't avoid proxies, but it would be great if we could do without DNS modifications, and initially without rendezvous servers. > The arguments in support of Rendezvous Servers (possibly reduced > update latency, and "providing some basics for the research group > results to build on") seem pretty thin; the arguments against them > seem much more compelling...IMHO. If you manage to convince the DNS WG that zero or near-zero TTL A/AAAA records are fine, my guess is that there are very few if any members of this WG that insist on rendezvous servers. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Feb 7 08:41: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 IAA29017 for ; Mon, 7 Feb 2005 08:41:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 29C877309; Mon, 7 Feb 2005 08:41:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by honor.icsalabs.com (Postfix) with ESMTP id 0D4247305 for ; Mon, 7 Feb 2005 08:40:58 -0500 (EST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j17Deu222204 for ; Mon, 7 Feb 2005 08:40:56 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 4BFE9BF01 for ; Mon, 7 Feb 2005 08:40:56 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j17Deto22056; Mon, 7 Feb 2005 08:40:55 -0500 Received: from mm123645-pc.mitre.org (129.83.82.66) by mailhub1.mitre.org with SMTP id 12926911; Mon, 07 Feb 2005 08:40:52 -0500 Message-ID: <42076FE3.3070304@mitre.org> From: Kevin Grace User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: Andrew McGregor , hipsec@honor.trusecure.com Subject: Re: [Hipsec] Rendezvous Server Concerns References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> In-Reply-To: <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> 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: Mon, 07 Feb 2005 08:40:51 -0500 Date: Mon, 07 Feb 2005 08:40:51 -0500 Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > Kevin, > >> Today, using readily available DNS implementations and without >> Rendezvous Servers, one can create an A record in an authoritative >> name server for a mobile host and assign it a time-to-live of 1 >> second. The longest the record could possibly be cached by >> non-authoritative name servers then is 1 second.When the node moves >> and changes IP addresses, it can successfully update its A record >> within the authoritative name server in less than a second. The total >> latency between when a node's address changes and when DNS is >> properly updated need not exceed a couple seconds and could well be >> closer to one second. > > > This is very good news indeed. Would you care to share us with a > reference? Sure. From the London Communications Symposium in 2002: http://www.ee.ucl.ac.uk/lcs/papers2002/LCS072.pdf The authors in the referenced paper demonstrate empirically how fast DNS can perform zone transfers and the maximum update rate it can support for a given configuration. Note, they are using what today would be considered slow platforms (650 MHz PIII) and even better performance results can be obtained today. My own organization has conducted similar tests using faster hardware and have been able to support over 300 individual dynamic updates/sec where each mobile node has a unique TSIG key; each individual update completes in well under a second. >>> - For wider scale early deployment, you need proxies anyway. >> >> >> Not if you avoid using Rendezvous Servers... > > > Yes, you do, as you have to support legacy hosts. They just don't > work if you change your IP address dynamically. No, legacy hosts can be directly supported without proxies and without Rendezvous Servers. If a mobile node moves and updates DNS with its new IP address, it can be reached by HIP aware and HIP unaware (legacy) nodes. Why do you think proxies are required? Regards, Kevin _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 8 11:48: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 LAA23867 for ; Tue, 8 Feb 2005 11:48:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 47A137319; Tue, 8 Feb 2005 11:48:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 4E88D7311 for ; Tue, 8 Feb 2005 11:47:54 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 006F5212C2D; Tue, 8 Feb 2005 18:47:41 +0200 (EET) In-Reply-To: <42076FE3.3070304@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Rendezvous Server Concerns To: Kevin Grace X-Mailer: Apple Mail (2.619.2) 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, 8 Feb 2005 18:48:08 +0200 Date: Tue, 8 Feb 2005 18:48:08 +0200 Content-Transfer-Encoding: 7bit > Sure. From the London Communications Symposium in 2002... Sounds interesting. I'll return to this once I've read the paper. > Why do you think proxies are required? To me, mobility does not only mean reachability or initial rendezvous, but also session continuity. In other words, IP mobility means that you can keep your active TCP connections running when you change your address. That's why. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 8 12:43:39 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 MAA28104 for ; Tue, 8 Feb 2005 12:43:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C25977321; Tue, 8 Feb 2005 12:43:03 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by honor.icsalabs.com (Postfix) with ESMTP id D10757319 for ; Tue, 8 Feb 2005 12:42:34 -0500 (EST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j18HgV817512 for ; Tue, 8 Feb 2005 12:42:31 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id C6A66BF7C for ; Tue, 8 Feb 2005 12:42:31 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j18HgVG17441; Tue, 8 Feb 2005 12:42:31 -0500 Received: from mm123645-pc.mitre.org (129.83.82.66) by mailhub2.mitre.org with SMTP id 8243600; Tue, 08 Feb 2005 12:42:27 -0500 Message-ID: <4208FA03.6050503@mitre.org> From: Kevin Grace User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Rendezvous Server Concerns References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> In-Reply-To: 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: Tue, 08 Feb 2005 12:42:27 -0500 Date: Tue, 08 Feb 2005 12:42:27 -0500 Content-Transfer-Encoding: 7bit Pekka Nikander wrote: >> Why do you think proxies are required? > > > To me, mobility does not only mean reachability or initial rendezvous, > but also session continuity. In other words, IP mobility means that > you can keep your active TCP connections running when you change your > address. That's why. Session continuity is achievable without proxies. In the case where only one of the HIP peers moves at a time and changes its address, the mobile node can readily send a HIP UPDATE to its peer (whose address has not changed) to indicate its new IP address, thus maintaining all existing transport layer sessions between them. In the more challenging case where both nodes move simultaneously and change addresses, upon detecting that HIP UPDATE messages are not getting ACK'd, a node can query DNS for the peer's new IP address and then proceed to send HIP UPDATE messages to the peer at the new address. This seems like a pretty straightforward modification to a HIP implementation...and it doesn't require proxies. The only requirement is for mobile nodes to dynamically update DNS. There are some additional pertinent details to this approach. One is: how does a HIP implementation learn a peer's hostname? This can be done in a variety of ways. One promising way is for a hostnames to be included in the optional CERT's during the base exchange. The nice thing about using CERT's during the base exchange is not only does it allow hostnames to be exchanged (which enables the above solution to the problem of both peers simultaneously moving) but it also allows HI's to be exchanged in "opportunistic mode" without exposing either to a man-in-the-middle attack. And since HI's can be securely exchanged, there is no longer a need to modify DNS to store HIPHI (as well as HIPRVS) records. Regards, Kevin _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 8 23:13: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 XAA21291 for ; Tue, 8 Feb 2005 23:13:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 4F249731E; Tue, 8 Feb 2005 23:13:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 3FAC97304 for ; Tue, 8 Feb 2005 23:12:14 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6D15F212C2D; Wed, 9 Feb 2005 06:12:10 +0200 (EET) In-Reply-To: <4208FA03.6050503@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> <4208FA03.6050503@mitre.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9e97eb483461c837801e4edb0f28494e@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Rendezvous Server Concerns To: Kevin Grace X-Mailer: Apple Mail (2.619.2) 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, 9 Feb 2005 06:12:37 +0200 Date: Wed, 9 Feb 2005 06:12:37 +0200 Content-Transfer-Encoding: 7bit >> To me, mobility does not only mean reachability or initial rendezvous, >> but also session continuity. In other words, IP mobility means that >> you can keep your active TCP connections running when you change your >> address. That's why. > > Session continuity is achievable without proxies. Towards legacy nodes? Remember, it was communication between HIP and legacy nodes that we were discussing about in the context of proxies. For HIP double jump you may still want to have HIP *rendezvous* servers, not proxies, or perhaps you can come along without, as you suggest. But I am getting a feeling that you are personally stuck to the idea of using the DNS. I agree that the DNS would be one nice alternative, provided that it works, which remains to be seen. OTOH, I don't think either rendezvous or DNS are a panacea; more probably both are needed. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 9 03:19: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 DAA09364 for ; Wed, 9 Feb 2005 03:19:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EAC9F731E; Wed, 9 Feb 2005 03:19:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 9945A7304 for ; Wed, 9 Feb 2005 03:18:08 -0500 (EST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 90AF12DF2; Wed, 9 Feb 2005 10:18:10 +0200 (EET) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id E50B82DF2; Wed, 9 Feb 2005 10:18:09 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j198I9A28972; Wed, 9 Feb 2005 10:18:09 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Kevin Grace Cc: Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: [Hipsec] Rendezvous Server Concerns In-Reply-To: <4208FA03.6050503@mitre.org> Message-ID: References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> <4208FA03.6050503@mitre.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.2-niksula20040914 (2004-11-16) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2-niksula20040914 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, 9 Feb 2005 10:18:09 +0200 (EET) Date: Wed, 9 Feb 2005 10:18:09 +0200 (EET) On Tue, 8 Feb 2005, Kevin Grace wrote: > Session continuity is achievable without proxies. In the case where only > one of the HIP peers moves at a time and changes its address, the mobile > node can readily send a HIP UPDATE to its peer (whose address has not > changed) to indicate its new IP address, thus maintaining all existing > transport layer sessions between them. In the more challenging case > where both nodes move simultaneously and change addresses, upon > detecting that HIP UPDATE messages are not getting ACK'd, a node can > query DNS for the peer's new IP address and then proceed to send HIP > UPDATE messages to the peer at the new address. This seems like a pretty > straightforward modification to a HIP implementation...and it doesn't > require proxies. The only requirement is for mobile nodes to dynamically > update DNS. If we talk about implementation stuff, I think you don't want to *require* the dependency on DNS. For example, the HIPL implementation is completely kernel based and you generally don't want to do DNS look-ups from the HIP module in such an implementation. According to the layering principle, it is better to keep the HIP layer independent from the "DNS layer" (i.e. application layer) after the initial contact. I haven't considered NA(P)Ts yet. Is there an advantage of using DNS vs. rendezvous with NATs? > There are some additional pertinent details to this approach. One is: > how does a HIP implementation learn a peer's hostname? This can be done > in a variety of ways. One promising way is for a hostnames to be > included in the optional CERT's during the base exchange. The HI can already include the hostname. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 9 04:31: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 EAA12657 for ; Wed, 9 Feb 2005 04:31:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 06B57733D; Wed, 9 Feb 2005 04:31:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 49ABF733C for ; Wed, 9 Feb 2005 04:30:34 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j199UZnK006914 for ; Wed, 9 Feb 2005 02:30:35 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBN00FEM12YSI@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Wed, 09 Feb 2005 02:30:34 -0700 (MST) Received: from [10.0.0.68] ([83.145.97.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBN005JY12WUK@mail.sun.net> for hipsec@honor.trusecure.com; Wed, 09 Feb 2005 02:30:34 -0700 (MST) From: Julien Laganier Subject: Re: [Hipsec] Rendezvous Server Concerns In-reply-to: <42038367.5030507@mitre.org> To: hipsec@honor.trusecure.com Cc: Kevin Grace , Pekka Nikander , Andrew McGregor Message-id: <200502091033.39400.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <42027267.5090503@mitre.org> <42038367.5030507@mitre.org> 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, 09 Feb 2005 10:33:39 +0100 Date: Wed, 09 Feb 2005 10:33:39 +0100 Content-Transfer-Encoding: 7BIT Hi Kevin, Please find my answer inlined below, On Friday 04 February 2005 15:15, Kevin Grace wrote: > On the other hand, using Rendezvous Servers will require > modifications to DNS to support a new resource record type...this > would definitely require acceptance by the DNS WG and unless demand > for HIP is high, proprietary implementations of DNS may never be > modified regardless of acceptance for the modifications within the > DNS WG. The prospects here seem much less certain than simply > adjusting time-to-live fields. Using Rendezvous Servers does not require to modify DNS per se. You can use a Rendezvous Servers (1) without DNS, (2) with non-HIP-aware DNS, and (3) with HIP-aware DNS. In (1), you are not using DNS so you supposedly gain knowledge of the IP address of your peer by out-of-band means. Hence, you're likely to be in position to also obtain the peers's HI/HIT, and possibly its RVS IP address. In (2), you are using non-HIP-aware DNS, hence you can resolve a FQDN into an A/AAAA RR. The A/AAAA record can also be used to store the RVS IP address, provided it is returned as the last RR in the RR set. The AAAA record can also be used to store the HIT (or IPv6 LSI), still if it is returned as the last RR in the RR set. In (3), you use A, AAAA, HIPHI and HIPRVS to store the appropriate informations. In both (2) and (3) you can still use DynDNS. RVS may is usefol when the scenario includes highly mobile or NATed nodes, or a more elaborated rendezvous architecture (ala Hi3). > > If you are saying that the requirements for added infrastructure > > may make HIP deployment harder, you are certainly right. To > > mitigate or counter that argument, we have to consider the > > following: > > > > - You can achieve small scale HIP deployment without DNS. > > That is what is happening now. People are using /etc/hosts > > to configure their peers' HITs. > > One can achieve large scale HIP deployment without modifying DNS > and without Rendezvous Servers. That's why the rendezvous server protocol and DNS extensions are in separate documents and not in the base protocol. > > - For wider scale early deployment, you need proxies anyway. > > Not if you avoid using Rendezvous Servers... > > HIP appears to be a wonderful mobility enabler and hopefully will > be deployed widely. In order for that to happen though, it seems to > make alot of sense to minimize the amount of complexity, effort, > and acceptance which is required. Rendezvous Servers, modifying > DNS, and HIP proxies seem to add lots of new challenges that are > not really necessary in order for HIP to be widely deployable. I am quite sure nobody in the WG would object if you choose to use HIP without rendezvous servers and without using the DNS extensions. These are optional components of HIP and are not required per se to use HIP. Even if you don't support RVS you should still be able to contacts nodes staying behind a RVS if you know their IP address or those of the RVS. The RVS protocol has been designed to be mostly transparent to Initiators. If you don't support DNS extensions you can store your IP addresses in A/AAAA RRs, and the HITs in the last AAAA RR returned in a set (yes, this is a hack). Thanks, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 9 09:23: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 JAA05011 for ; Wed, 9 Feb 2005 09:23:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id AE512733C; Wed, 9 Feb 2005 09:23:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-bedford.mitre.org (smtp-bedford-x.mitre.org [192.160.51.76]) by honor.icsalabs.com (Postfix) with ESMTP id F01127304 for ; Wed, 9 Feb 2005 09:22:07 -0500 (EST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j19EM7713697 for ; Wed, 9 Feb 2005 09:22:07 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id D9C97BF7E for ; Wed, 9 Feb 2005 09:22:06 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j19EM6D13661; Wed, 9 Feb 2005 09:22:06 -0500 Received: from mm123645-pc.mitre.org (129.83.82.66) by mailhub2.mitre.org with SMTP id 8273565; Wed, 09 Feb 2005 09:22:04 -0500 Message-ID: <420A1C8B.2080108@mitre.org> From: Kevin Grace User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Rendezvous Server Concerns References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> <4208FA03.6050503@mitre.org> <9e97eb483461c837801e4edb0f28494e@nomadiclab.com> In-Reply-To: <9e97eb483461c837801e4edb0f28494e@nomadiclab.com> 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, 09 Feb 2005 09:22:03 -0500 Date: Wed, 09 Feb 2005 09:22:03 -0500 Content-Transfer-Encoding: 7bit Pekka Nikander wrote: >>> To me, mobility does not only mean reachability or initial rendezvous, >>> but also session continuity. In other words, IP mobility means that >>> you can keep your active TCP connections running when you change your >>> address. That's why. >> >> >> Session continuity is achievable without proxies. > > > Towards legacy nodes? Remember, it was communication between HIP and > legacy nodes that we were discussing about in the context of proxies. Perhaps if there was a draft on the HIP proxy, some of the discussion here about its purpose and functionality would be simpler. An earlier part of this thread seemed to indicate that HIP proxies were intended to make HIP nodes behind an RVS be reachable by legacy nodes. Now it seems that proxies are intended to allow mobile HIP nodes to maintain sessions with stationary legacy nodes regardless of whether RVS's are present. The former purpose, by itself, did not seem compelling enough to warrant the creation of HIP proxies if simply by avoiding RVS's the problem went away. On the other hand, the latter purpose seems to have alot of merit as one can envision numerous cases where it would be useful to maintain sessions between legacy nodes and mobile HIP nodes. Is a draft description of HIP proxies on the horizon? Is it envisioned that HIP proxies will be able to maintain sessions between legacy nodes and mobile HIP nodes without the existence of an RVS? > > For HIP double jump you may still want to have HIP *rendezvous* > servers, not proxies, or perhaps you can come along without, as you > suggest. But I am getting a feeling that you are personally stuck > to the idea of using the DNS. I agree that the DNS would be one > nice alternative, provided that it works, which remains to be seen. > OTOH, I don't think either rendezvous or DNS are a panacea; more > probably both are needed. > You may be right. If one really needs sub-second mobile update latencies, then RVS's may be warranted. If, on the other hand, one can get by with one second update latencies, then the additional RVS requirements of a HIP proxy server (for legacy node connectivity) and modifications to DNS for the HIPRVS records seem pretty steep. Thanks for the discussion. Kevin _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 9 16:12:40 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 QAA19660 for ; Wed, 9 Feb 2005 16:12:39 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B266A733E; Wed, 9 Feb 2005 16:12:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id 4D2B7733C for ; Wed, 9 Feb 2005 16:11:06 -0500 (EST) 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 NAA21072; Wed, 9 Feb 2005 13:10:58 -0800 (PST) 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 j19LAwK12048; Wed, 9 Feb 2005 13:10:58 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Feb 2005 13:10:57 -0800 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] Draft: ESP usage in HIP Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Draft: ESP usage in HIP Thread-Index: AcUJ3tnTxCboktp4RfiqbCA6NbPpUgE7/pag From: "Henderson, Thomas R" To: "Petri Jokela" , X-OriginalArrivalTime: 09 Feb 2005 21:10:57.0027 (UTC) FILETIME=[D8F9A530:01C50EEB] 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, 9 Feb 2005 13:10:56 -0800 Date: Wed, 9 Feb 2005 13:10:56 -0800 Content-Transfer-Encoding: quoted-printable Petri, thanks for producing this draft. I have several comments: More substantial: - I have previously suggested not making ESP a MUST implement. For now, I think it can stay that way but I would like to have some further discussion, perhaps after I submit a more lengthy draft on this topic. - I did not find the new conceptual protocols helpful-- to me, it seems unnecessary to add this terminology, unless you have some downstream plan to do something different with these packet exchanges. Wording such as "In a typical implementation, the parameters are included in R1, I2, and R2" seems to suggest that atypical implementations also may exist that include these parameters in other messages, and that we therefore have to be prepared for all possible situations, which I don't think is what is intended. I would suggest using the explicit R1, I2, R2, and UPDATE names for the packets instead of HES and HER.=20 - There are probably some additional things that need to be specified to cover some cases of multihoming, but I think we will need to collaborate a bit in the future on this point, since I don't have a concrete proposal for you now. For example, there are statements like (in 7.1) "Ensure that the outgoing ESP protected packet has proper IP addresses in its IP header" but it doesn't say explicitly how such bindings are maintained-- maybe need a reference to the mobility draft. =20 - I agree with the new ESP_INFO parameter - Section 4.1 (Implementation options) seems misplaced, perhaps. Maybe as an appendix? In any case, I don't think that the spec should RECOMMEND how to implement (last sentence). I would rather just see an explanation of what has to happen to the packets. For example, Section 3 of RFC 2406 describes ESP packet processing (both inbound and outbound). We should just have a similar section that points to RFC 2406 and mentions any differences in the processing. For example, Sections 3 and 4 (and maybe need to consider also Sections 7.1 and 7.2) could be reoutlined as follows: 3. Using ESP with HIP 3.1 ESP packet format (pointer to Sec 2 of RFC 2406) 3.2 ESP packet processing (pointer to Sec 3 of RFC 2406, explaining any diffs resulting from BEET mode, and perhaps add the existing Sec 3.2 on SPI semantics) 3.3 Security Association establishment and maintenance (existing Sec. 4.2-4.7) - Section 4.6, I disagree with disallowing ESP NULL-- it may have some operational use (maybe allow null encryption-- if both enc and auth are null, all ESP is providing is the SPI and sequence number, and there may be a better way to compress the HITs in such a case). Minor: - page 4: s/a symmetric pair of ESP/a pair of ESP/=20 - page 6: s/require some minor modifications in/require some minor additions to/ s/One new parameter is introduced for this purpose; the ESP_INFO parameter./The ESP_INFO parameter introduced above is also used for this purpose./ - page 6, 2nd paragraph. I found this confusing to read at first, then it was clearer after I read section 4.1. Perhaps the text needs to point forward to that. The next-to-last sentence doesn't make sense (the word "problems" seems misplaced). =20 - page 7, s/that are conceptually included in every packet// s/at every given/at any given/ - page 10, s/both HITs since a/both local and remote HITs since a/ - page 10, it is not clear from reading this document whether AES and HMAC-SHA-1-96 should be offered in the R1, or whether they are implicit and do not ever need to be offered as possible transforms. - page 11, s/that have been authenticated// s/conseptual/conceptual - page 18, s/ones carrying a HER1 information/ones carrying HER1 information/ - page 19, s/MAY responder, rate limited,/MAY respond (subject to rate limiting the responses)/ - page 20, sections 7.1 and 7.2 might need some similar reference to 2401bis for how to do security association lookup? - page 21, s/piggypacked/piggybacked/=20 > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Thursday, February 03, 2005 2:55 AM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Draft: ESP usage in HIP >=20 > Folks, >=20 > The ESP text is moved now from the Base specification into a=20 > new draft.=20 > The preliminary version 1 of this draft is available at: >=20 > http://www.hip4inter.net/drafts.php >=20 > Some notes: >=20 > The ESP setup and rekeying processes are defined as=20 > conceptual protocols HIP ESP Setup (HES) and HIP ESP Rekeying=20 > (HER). In a usual implementation, the contents of these=20 > packets is put in base exchange packets and UPDATEs, respectively. >=20 > The NES and SPI are proposed to be replaced with a single parameter:=20 > ESP_INFO. >=20 > Comments are appreciated. The intention is to make fixes=20 > during next week and submit the draft before the IETF=20 > deadline for -00 drafts (Feb 14) >=20 > BR, 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 > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 >=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Feb 10 11:44: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 LAA15231 for ; Thu, 10 Feb 2005 11:44:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7BDDC731C; Thu, 10 Feb 2005 11:44:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 3440A7316 for ; Thu, 10 Feb 2005 11:43:46 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 21D05212C2D; Thu, 10 Feb 2005 18:43:40 +0200 (EET) From: Petri Jokela To: "Henderson, Thomas R" Cc: Petri Jokela , hipsec@honor.trusecure.com Subject: RE: [Hipsec] Draft: ESP usage in HIP In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Thu, 10 Feb 2005 18:43:40 +0200 (EET) Date: Thu, 10 Feb 2005 18:43:40 +0200 (EET) On Wed, 9 Feb 2005, Henderson, Thomas R wrote: > More substantial: > - I have previously suggested not making ESP a MUST implement. For now, > I think it can stay that way but I would like to have some further > discussion, perhaps after I submit a more lengthy draft on this topic. Ok. We leave it as it is (for the time being). > - I did not find the new conceptual protocols helpful-- to me, it seems > unnecessary to add this terminology, unless you have some downstream > plan to do something different with these packet exchanges. Wording > such as "In a typical implementation, the parameters are included in R1, > I2, and R2" seems to suggest that atypical implementations also may > exist that include these parameters in other messages, and that we > therefore have to be prepared for all possible situations, which I don't > think is what is intended. I would suggest using the explicit R1, I2, > R2, and UPDATE names for the packets instead of HES and HER. The idea was that we do not bind the required information exchange to these particular HIP packets. Perhaps we could set up the ESP Security Association afterwards using UPDATE messages. I must admit that I have a similar feeling that the current text is not very reader friendly. I am not going to change this before the initial submission (Friday), but I would like to hear more comments on this. Based on the discussion, changes can be made to the next version of the draft. > - There are probably some additional things that need to be specified to > cover some cases of multihoming, but I think we will need to collaborate > a bit in the future on this point, since I don't have a concrete > proposal for you now. For example, there are statements like (in 7.1) > "Ensure that the outgoing ESP protected packet has proper IP addresses > in its IP header" but it doesn't say explicitly how such bindings are > maintained-- maybe need a reference to the mobility draft. Ok. I'll see the text tomorrow, but I suppose all changes go to the next version and we can discuss them later. > - I agree with the new ESP_INFO parameter Ok. > - Section 4.1 (Implementation options) seems misplaced, perhaps. Maybe > as an appendix? In any case, I don't think that the spec should > RECOMMEND how to implement (last sentence). > I would rather just see an > explanation of what has to happen to the packets. For example, Section > 3 of RFC 2406 describes ESP packet processing (both inbound and > outbound). We should just have a similar section that points to RFC > 2406 and mentions any differences in the processing. For example, > Sections 3 and 4 (and maybe need to consider also Sections 7.1 and 7.2) > could be reoutlined as follows: > 3. Using ESP with HIP > 3.1 ESP packet format > (pointer to Sec 2 of RFC 2406) > 3.2 ESP packet processing > (pointer to Sec 3 of RFC 2406, explaining any diffs resulting from BEET > mode, and perhaps add the existing Sec 3.2 on SPI semantics) > 3.3 Security Association establishment and maintenance > (existing Sec. 4.2-4.7) I'll come up with a proposal before next draft. I have only one day to fix the draft before my submission deadline. > - Section 4.6, I disagree with disallowing ESP NULL-- it may have some > operational use (maybe allow null encryption-- if both enc and auth are > null, all ESP is providing is the SPI and sequence number, and there may > be a better way to compress the HITs in such a case). I read 4.6 so that it is not illegal to use ESP NULL, but you have to configure it separately. In this case, data would "never" be in the network unprotected, unless you explicitly allow the host to do so. I would stick with the current text. Any opinions? Clarifications / changes needed to the text? BR, 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-admin@honor.trusecure.com Fri Feb 11 08:01: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 IAA24759 for ; Fri, 11 Feb 2005 08:01:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 13D667317; Fri, 11 Feb 2005 08:01:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 3B5B37315 for ; Fri, 11 Feb 2005 08:00:31 -0500 (EST) Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 9DFBA212C2D; Fri, 11 Feb 2005 15:00:23 +0200 (EET) Message-ID: <420CAC67.7090301@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Draft: ESP usage in HIP References: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> 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: Fri, 11 Feb 2005 15:00:23 +0200 Date: Fri, 11 Feb 2005 15:00:23 +0200 Content-Transfer-Encoding: 7bit Hi! I submitted the ESP draft to IETF. The document can also be found from: http://www.hip4inter.net/drafts.php I didn't have time to make any big changes base on Tom's comments. I made only one change in the text in addition to the typo fixes. > - page 10, it is not clear from reading this document whether AES and > HMAC-SHA-1-96 should be offered in the R1, or whether they are implicit > and do not ever need to be offered as possible transforms. I changed this a bit to make it mandatory to include the transport in the packet. Otherwise the negotiation is cancelled. Any opinions? "All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2]. If the Initiator does not support any of the transforms offered by the Responder in the R1 HIP packet, it should abandon the negotiation and inform peer with a NOTIFY message about a non-supported transform." BR, 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-admin@honor.trusecure.com Fri Feb 11 11:49: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 LAA14729 for ; Fri, 11 Feb 2005 11:49:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E6F7B731D; Fri, 11 Feb 2005 11:49:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 38703731C for ; Fri, 11 Feb 2005 11:48:41 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7FBE9212C2D; Fri, 11 Feb 2005 18:48:34 +0200 (EET) In-Reply-To: <420CAC67.7090301@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060A36@xch-nw-27.nw.nos.boeing.com> <420CAC67.7090301@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7bf421bcd16d663547a3c6cc4fca0cb3@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Henderson, Thomas R" , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Draft: ESP usage in HIP To: Petri Jokela X-Mailer: Apple Mail (2.619.2) 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: Fri, 11 Feb 2005 18:49:00 +0200 Date: Fri, 11 Feb 2005 18:49:00 +0200 Content-Transfer-Encoding: 7bit > I changed this a bit to make it mandatory to include the transport in > the packet. Otherwise the negotiation is cancelled. Any opinions? > > "All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2]. > If the Initiator does not support any of the transforms offered by > the Responder in the R1 HIP packet, it should abandon the negotiation > and inform peer with a NOTIFY message about a non-supported > transform." Looks good other than that the NOTIFY packet is unnecessary. The responder doesn't have any state; it will simply ignore the NOTIFY. Having it to process an unprotected NOTIFY and change its policy would pose a security risk. In general, if the responder and initiator policies are incompatible, there is nothing one can do. The responder won't even know, unless the initiator completes the base exchange (without ESP) and THEN sends a NOTIFY. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 15 06:13:37 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 GAA18585 for ; Tue, 15 Feb 2005 06:13:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C251A73DF; Tue, 15 Feb 2005 06:13:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by honor.icsalabs.com (Postfix) with ESMTP id CAB007307 for ; Tue, 15 Feb 2005 06:12:20 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtps (Exim 4.43 #1) id 1D10cp-00014Q-Oy; Tue, 15 Feb 2005 12:12:24 +0100 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1D10cm-0004LN-00; Tue, 15 Feb 2005 12:12:12 +0100 Message-ID: <4211D90C.7080400@tm.uka.de> From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Cc: Pekka Nikander , David Ward , Gonzalo Camarillo X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -9.8 (---------) X-Spam-Status: No Subject: [Hipsec] New I-D: draft-vogt-hip-credit-based-authorization-00.txt 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, 15 Feb 2005 12:12:12 +0100 Date: Tue, 15 Feb 2005 12:12:12 +0100 Content-Transfer-Encoding: 7bit Hi HIP folks. End-Host Mobility with HIP as well as Mobile IPv6 require a reachability test of a mobile node's new IP address. This test must be performed before packets are sent to this new IP address to prevent malicious redirection attacks and third-party flooding. In the MIP6 and Mobopts groups, we have thought about a secure way to check a mobile node's reachability at a new IP address, subsequent to handover, *in parallel* with already having communications go through this new IP address. We particularly discussed a credit-based solution, Credit-Based Authorization (CBA). It turns out that CBA can be applied to End-Host Mobility with HIP as well. Pekka and I talked about this at the IETF 61 meeting in Washington D.C. The draft cited below gives an overview on CBA and explains its integration with HIP mobility. Your folks' opinions on this topic are greatly appreciated. Best regards, - Christian PS: I posted this email on the HIP RG's mailing list as well. Title...: Credit-Based Authorization for HIP Mobility with Concurrent IP-Address Tests Author..: Christian Vogt http://www.tm.uka.de/~chvogt/ro2/pub/2005/draft-vogt-hip-credit-based-authorization-00.txt Abstract End-host mobility with the Host Identity Protocol uses IP-address tests to protect against malicious packet redirection and third-party flooding. The tests cause handover signaling delays to increase by one round-trip time. This document proposes a credit-based strategy that allows peers to securely resume active communications after handover as soon as possible, and to pursue a concurrent IP-address test subsequently. The optimization thus eliminates the additional handover delay that IP-address tests entail. -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ "No great genius has ever existed without some touch of madness." (Aristotle) _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 15 12:52:38 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 MAA26569 for ; Tue, 15 Feb 2005 12:52:38 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 363267367; Tue, 15 Feb 2005 12:52:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 411947313 for ; Tue, 15 Feb 2005 12:51:52 -0500 (EST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0D21A2E4F; Tue, 15 Feb 2005 19:51:53 +0200 (EET) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 637DA2E19 for ; Tue, 15 Feb 2005 19:51:51 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: hipsec@honor.trusecure.com From: Teemu Koponen X-Mailer: Apple Mail (2.619.2) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.2-niksula20040914 (2004-11-16) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2-niksula20040914 Subject: [Hipsec] A new I-D: HIP Registration Extension 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, 15 Feb 2005 19:51:46 +0200 Date: Tue, 15 Feb 2005 19:51:46 +0200 Content-Transfer-Encoding: 7bit Folks, A new draft that is a spin-off from the rendezvous draft: Title : Host Identity Protocol (HIP) Registration Extension Author(s) : T. Koponen, et al. Filename : draft-koponen-hip-registration-00.txt Pages : 13 Date : 2005-2-14 This document specifies a registration mechanism for the Host Identity Protocol that allows hosts to register with services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-koponen-hip-registration -00.txt Teemu -- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 15 22:16: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 WAA29634 for ; Tue, 15 Feb 2005 22:16:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 52D987313; Tue, 15 Feb 2005 22:16:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id 3D23E72F5 for ; Tue, 15 Feb 2005 22:15:52 -0500 (EST) 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 TAA06292; Tue, 15 Feb 2005 19:15:32 -0800 (PST) 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 j1G3FfI01694; Tue, 15 Feb 2005 19:15:41 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 19:15:41 -0800 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] Base HIP: 02 PRE1 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED8@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base HIP: 02 PRE1 Thread-Index: AcUHgH9abkrLVyJBRumShcfWa/GqygMVAxzA From: "Henderson, Thomas R" To: "Pekka Nikander" Cc: "Petri Jokela" , X-OriginalArrivalTime: 16 Feb 2005 03:15:41.0105 (UTC) FILETIME=[CB617210:01C513D5] 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, 15 Feb 2005 19:15:40 -0800 Date: Tue, 15 Feb 2005 19:15:40 -0800 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Monday, January 31, 2005 2:35 AM > To: Henderson, Thomas R > Cc: Petri Jokela; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Base HIP: 02 PRE1 >=20 > >>>> 3.2 Local Scope Identifier (LSI) > >> > >> While I think that we are doing good progress with LSIs=20 > currently at=20 > >> the RG discussion, it might still be a good option to move=20 > LSIs into=20 > >> a separate draft. Such a document could discuss LSIs, how=20 > they are=20 > >> used at the APIs and by applications, and _also_ define a HIP=20 > >> protocol extension for informing about used/assigned LSIs. > >> Opinions? > > > > I would favor such a document, scoped as "Using HIP with=20 > legacy APIs"=20 > > and it could contain more discussion about the LSIs and incorporate=20 > > the material in current Appendix A. > > > > I'd be willing to take a first cut at it. >=20 > Great! A draft should be hitting the IETF-announce list soon that is intended to replace Appendix A. I would suggest that Appendix A be removed from the base draft at some point. However, the new draft does not cover LSIs in detail, so I will back off (for now) the request to remove LSIs from the base draft. Some other comments on the pre2 draft: I reviewed only looking at the UPDATE portions, since they are coupled to the mobility draft (which will soon be updated as well). In Section 8.9, someone (Petri?) raised the issue of whether=20 UPDATE retransmissions should be exponentially backed off, like in TCP and many other protocols. I agree.. perhaps change 8.9 item 4 to say also "The UPDATE timer MAY be exponentially backed=20 off for subsequent retransmissions." Section 8.10, item 3 should start: "Additionally (or alternatively),..." since item 2 may not hold. For now, that is all I have on the UPDATE-- I think that it was a good first cut at extracting out the NES/ESP material. =20 Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 15 22:26:32 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 WAA07133 for ; Tue, 15 Feb 2005 22:26:32 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1A86973CB; Tue, 15 Feb 2005 22:26:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from enso.acheron.indranet.co.nz (unknown [203.167.203.10]) by honor.icsalabs.com (Postfix) with ESMTP id 7E6CA7313 for ; Tue, 15 Feb 2005 22:25:22 -0500 (EST) Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id QAA03054; Wed, 16 Feb 2005 16:25:14 +1300 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED8@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED8@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <065d719af7ac51466e18d8bd94b4d19d@indranet.co.nz> Content-Transfer-Encoding: 7bit Cc: "Petri Jokela" , , "Pekka Nikander" From: Andrew McGregor Subject: Re: [Hipsec] Base HIP: 02 PRE1 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619.2) 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, 16 Feb 2005 16:24:18 +1300 Date: Wed, 16 Feb 2005 16:24:18 +1300 Content-Transfer-Encoding: 7bit On 16/02/2005, at 4:15 PM, Henderson, Thomas R wrote: > > In Section 8.9, someone (Petri?) raised the issue of whether > UPDATE retransmissions should be exponentially backed off, like in > TCP and many other protocols. I agree.. perhaps change 8.9 item > 4 to say also "The UPDATE timer MAY be exponentially backed > off for subsequent retransmissions." > May I recommend SHOULD? Andrew _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 15 22:31:32 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 WAA09238 for ; Tue, 15 Feb 2005 22:31:32 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6414B7367; Tue, 15 Feb 2005 22:31:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 2C8877313 for ; Tue, 15 Feb 2005 22:30:36 -0500 (EST) 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 VAA02472; Tue, 15 Feb 2005 21:30:33 -0600 (CST) 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 j1G3UVJ15567; Tue, 15 Feb 2005 21:30:31 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 19:30:31 -0800 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] Base HIP: 02 PRE1 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED9@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base HIP: 02 PRE1 Thread-Index: AcUT1ynMaySJPGwQQni58jmuc/m2XAAAKRFg From: "Henderson, Thomas R" To: "Andrew McGregor" Cc: "Petri Jokela" , , "Pekka Nikander" X-OriginalArrivalTime: 16 Feb 2005 03:30:31.0703 (UTC) FILETIME=[DE37EA70:01C513D7] 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, 15 Feb 2005 19:30:31 -0800 Date: Tue, 15 Feb 2005 19:30:31 -0800 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Andrew McGregor [mailto:andrew@indranet.co.nz]=20 > Sent: Tuesday, February 15, 2005 7:24 PM > To: Henderson, Thomas R > Cc: Petri Jokela; hipsec@honor.trusecure.com; Pekka Nikander > Subject: Re: [Hipsec] Base HIP: 02 PRE1 >=20 >=20 > On 16/02/2005, at 4:15 PM, Henderson, Thomas R wrote: >=20 > > > > In Section 8.9, someone (Petri?) raised the issue of whether UPDATE=20 > > retransmissions should be exponentially backed off, like in TCP and=20 > > many other protocols. I agree.. perhaps change 8.9 item > > 4 to say also "The UPDATE timer MAY be exponentially backed off for=20 > > subsequent retransmissions." > > >=20 > May I recommend SHOULD? >=20 Yes, I guess that these are generally SHOULDs instead of MAYs. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 16 04:34:43 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 EAA17766 for ; Wed, 16 Feb 2005 04:34:42 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 89A7F72E8; Wed, 16 Feb 2005 04:34:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id D1A9F72E0 for ; Wed, 16 Feb 2005 04:33:08 -0500 (EST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 697F92DE6; Wed, 16 Feb 2005 11:33:12 +0200 (EET) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id C26132DD0 for ; Wed, 16 Feb 2005 11:33:10 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j1G9XAO22531; Wed, 16 Feb 2005 11:33:10 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@honor.trusecure.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.2-niksula20040914 (2004-11-16) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2-niksula20040914 Subject: [Hipsec] SHA1 broken? 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, 16 Feb 2005 11:33:10 +0200 (EET) Date: Wed, 16 Feb 2005 11:33:10 +0200 (EET) http://www.schneier.com/blog/archives/2005/02/sha1_broken.html -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 16 07:00:32 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 HAA29602 for ; Wed, 16 Feb 2005 07:00:32 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B30F272F9; Wed, 16 Feb 2005 07:00:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id E390A72E8 for ; Wed, 16 Feb 2005 06:59:17 -0500 (EST) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1D1Npf-00011F-00; Wed, 16 Feb 2005 06:59:03 -0500 From: Tim Shepard To: Miika Komu Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] SHA1 broken? In-reply-to: Your message of Wed, 16 Feb 2005 11:33:10 +0200. Message-Id: 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, 16 Feb 2005 06:59:03 -0500 Date: Wed, 16 Feb 2005 06:59:03 -0500 > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html Does this mean that HITs will need to be 256 bits long now (for there are no crypto hash functions left standing with output shorter than 256 bits)? I think so. I wonder how long SHA256 will remain standing. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 16 07:05: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 HAA00055 for ; Wed, 16 Feb 2005 07:05:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7F39C72F9; Wed, 16 Feb 2005 07:05:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by honor.icsalabs.com (Postfix) with ESMTP id 466DD72E8 for ; Wed, 16 Feb 2005 07:04:26 -0500 (EST) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CABA889883; Wed, 16 Feb 2005 14:04:26 +0200 (EET) Message-ID: <42133673.5040907@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Shepard Cc: Miika Komu , hipsec@honor.trusecure.com Subject: Re: [Hipsec] SHA1 broken? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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, 16 Feb 2005 14:02:59 +0200 Date: Wed, 16 Feb 2005 14:02:59 +0200 Content-Transfer-Encoding: 7bit Tim Shepard wrote: > Does this mean that HITs will need to be 256 bits long now (for there > are no crypto hash functions left standing with output shorter than > 256 bits)? I think so. Well, if those other functions are secure, do you have to use all the output bits? Seems like an output cut to 128 would suffice too, unless there's some weakness in the hash function. Presumably the SHA-1 weaknesses, if real, relate to some problem in the definition of the function rather than the mere insufficiency of the bits... --Jari _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 16 07:27:33 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 HAA01821 for ; Wed, 16 Feb 2005 07:27:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id F0A7B72F9; Wed, 16 Feb 2005 07:27:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-bedford-dr.mitre.org (smtp-bedford-dr-x.mitre.org [192.160.51.65]) by honor.icsalabs.com (Postfix) with ESMTP id 7E5F872E8 for ; Wed, 16 Feb 2005 07:26:45 -0500 (EST) Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j1GCQjN22156 for ; Wed, 16 Feb 2005 07:26:45 -0500 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id E1D664F8D9 for ; Wed, 16 Feb 2005 07:26:44 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id j1GCQi222038; Wed, 16 Feb 2005 07:26:44 -0500 Received: from mm123645-pc.mitre.org (129.83.82.66) by mailhub2.mitre.org with SMTP id 8487428; Wed, 16 Feb 2005 07:26:39 -0500 Message-ID: <42133BFF.2050309@mitre.org> From: Kevin Grace User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Cc: Andrew McGregor , Petri Jokela , hipsec@honor.trusecure.com, Pekka Nikander Subject: Re: [Hipsec] Base HIP: 02 PRE1 References: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED9@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648ED9@xch-nw-27.nw.nos.boeing.com> 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, 16 Feb 2005 07:26:39 -0500 Date: Wed, 16 Feb 2005 07:26:39 -0500 Content-Transfer-Encoding: 7bit Considering that retransmissions could be due to lossy wireless links, recommending exponential backoff (a congestion avoidance mechanism) may not be always appropriate. "MAY" seems to recognize this possibility more than "SHOULD". Kevin Henderson, Thomas R wrote: > > > > >>-----Original Message----- >>From: Andrew McGregor [mailto:andrew@indranet.co.nz] >>Sent: Tuesday, February 15, 2005 7:24 PM >>To: Henderson, Thomas R >>Cc: Petri Jokela; hipsec@honor.trusecure.com; Pekka Nikander >>Subject: Re: [Hipsec] Base HIP: 02 PRE1 >> >> >>On 16/02/2005, at 4:15 PM, Henderson, Thomas R wrote: >> >> >> >>>In Section 8.9, someone (Petri?) raised the issue of whether UPDATE >>>retransmissions should be exponentially backed off, like in TCP and >>>many other protocols. I agree.. perhaps change 8.9 item >>>4 to say also "The UPDATE timer MAY be exponentially backed off for >>>subsequent retransmissions." >>> >>> >>> >>May I recommend SHOULD? >> >> >> > >Yes, I guess that these are generally SHOULDs instead of MAYs. > >Tom >_______________________________________________ >Hipsec mailing list >Hipsec@honor.trusecure.com >http://honor.trusecure.com/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 16 17:09:38 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 RAA02805 for ; Wed, 16 Feb 2005 17:09:38 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 486717317; Wed, 16 Feb 2005 17:09:03 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id A60B77315; Wed, 16 Feb 2005 17:08:43 -0500 (EST) 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 OAA07608; Wed, 16 Feb 2005 14:08:40 -0800 (PST) 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 j1GM8cJ04286; Wed, 16 Feb 2005 16:08:38 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 14:08:37 -0800 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 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648EE6@xch-nw-27.nw.nos.boeing.com> Thread-Topic: I-D ACTION:draft-henderson-hip-generalize-00.txt Thread-Index: AcUUR5IilY2sOVOCTMiW9b5aElfj+gAK8BBw From: "Henderson, Thomas R" To: Cc: X-OriginalArrivalTime: 16 Feb 2005 22:08:37.0990 (UTC) FILETIME=[10C2F060:01C51474] Subject: [Hipsec] FW: I-D ACTION:draft-henderson-hip-generalize-00.txt 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, 16 Feb 2005 14:08:34 -0800 Date: Wed, 16 Feb 2005 14:08:34 -0800 Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 16, 2005 7:11 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-henderson-hip-generalize-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generalizing the HIP base protocol Author(s) : T. Henderson Filename : draft-henderson-hip-generalize-00.txt Pages : 19 Date : 2005-2-15 =09 The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. This draft observes that HIP can be viewed as an instance of a more general migration towards decoupling identity from location in the Internet architecture, and shows how other proposals (mobile IP, multi6, mobike, and i3) fit into this framework. We argue that if the HIP base protocol were to be slightly generalized, it might be useful to other related efforts and might allow more experimental flexibility. Specifically, an extensible identifier TLV, the ability to define usage profiles for the HIP handshake, and a relaxation of the requirements that specific HIP messages carry specific parameters are the three changes suggested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henderson-hip-generalize-00.tx t _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Feb 16 17:12: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 RAA02999 for ; Wed, 16 Feb 2005 17:12:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 49A1A7316; Wed, 16 Feb 2005 17:12:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id 02FDD7315 for ; Wed, 16 Feb 2005 17:11:56 -0500 (EST) 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 OAA11089 for ; Wed, 16 Feb 2005 14:12:01 -0800 (PST) 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 j1GMC0I04766 for ; Wed, 16 Feb 2005 14:12:00 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 14:11:44 -0800 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 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648EE7@xch-nw-27.nw.nos.boeing.com> Thread-Topic: I-D ACTION:draft-henderson-hip-applications-00.txt Thread-Index: AcUUWR+aixzjOTXdR3atyPot2J15VwAGvewg From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 16 Feb 2005 22:11:44.0088 (UTC) FILETIME=[7FAF3D80:01C51474] Subject: [Hipsec] FW: I-D ACTION:draft-henderson-hip-applications-00.txt 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, 16 Feb 2005 14:11:43 -0800 Date: Wed, 16 Feb 2005 14:11:43 -0800 Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 16, 2005 7:23 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-henderson-hip-applications-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using HIP with Legacy Applications Author(s) : T. Henderson Filename : draft-henderson-hip-applications-00.txt Pages : 9 Date : 2005-2-15 =09 The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family (e.g., AF_HOST), but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is HIP-aware but the applications are not. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-00. txt _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun Feb 20 03:30:45 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 DAA12063 for ; Sun, 20 Feb 2005 03:30:45 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7836F7321; Sun, 20 Feb 2005 03:30:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by honor.icsalabs.com (Postfix) with ESMTP id 93B5E731F for ; Sun, 20 Feb 2005 03:29:58 -0500 (EST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1K8Rifm018609; Sun, 20 Feb 2005 09:27:44 +0100 (MET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 20 Feb 2005 09:28:18 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 20 Feb 2005 09:28:18 +0100 Received: from ericsson.com (unknown [131.160.126.13]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6C160189CC; Sun, 20 Feb 2005 10:27:41 +0200 (EET) Message-ID: <42184A21.8040008@ericsson.com> From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Cc: David Ward , Pekka Nikander , Thomas Henderson Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2005 08:28:18.0562 (UTC) FILETIME=[21593E20:01C51726] Subject: [Hipsec] Agenda requests, IETF 62 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, 20 Feb 2005 10:28:17 +0200 Date: Sun, 20 Feb 2005 10:28:17 +0200 Content-Transfer-Encoding: 7bit Folks, we are officially starting to gather agenda requests for the HIP WG meeting in Minneapolis. The agenda needs to be ready by March 28th. So, please, send your requests by the end of this week (Friday, March 25th). You should send your agenda request to the chairs indicating: 1) the topic you want to present 2) related Internet-Drafts 3) length of the requested agenda-slot Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 22 06:48:45 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 GAA19507 for ; Tue, 22 Feb 2005 06:48:45 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EDF027323; Tue, 22 Feb 2005 06:48:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 975577315 for ; Tue, 22 Feb 2005 06:47:22 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1MBlHKw019244 for ; Tue, 22 Feb 2005 04:47:17 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ICB00KC9A2SDO@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Tue, 22 Feb 2005 04:47:17 -0700 (MST) Received: from [140.77.15.31] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ICB00D679YI94@mail.sun.net> for hipsec@honor.trusecure.com; Tue, 22 Feb 2005 04:47:16 -0700 (MST) From: Julien Laganier Subject: Re: [Hipsec] Agenda requests, IETF 62 In-reply-to: <42184A21.8040008@ericsson.com> To: hipsec@honor.trusecure.com Cc: Gonzalo Camarillo , David Ward Message-id: <200502221248.00080.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <42184A21.8040008@ericsson.com> 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, 22 Feb 2005 12:47:59 +0100 Date: Tue, 22 Feb 2005 12:47:59 +0100 Content-Transfer-Encoding: 7BIT On Sunday 20 February 2005 09:28, Gonzalo Camarillo wrote: > Folks, > > we are officially starting to gather agenda requests for the HIP WG > meeting in Minneapolis. The agenda needs to be ready by March 28th. > So, please, send your requests by the end of this week (Friday, > March 25th). Dear HIP WG chairs, I'd like to request three presentation slots for the next HIP WG meeting in Minneapolis, with the following specifics: --------------------------------------------- > 1) the topic you want to present o HIP Registration Extensions > 2) related Internet-Drafts o draft-koponen-hip-registration-00.txt > 3) length of the requested agenda-slot o 10 min. --------------------------------------------- > 1) the topic you want to present o HIP Rendezvous Servers Extensions > 2) related Internet-Drafts o draft-ietf-hip-rvs-01.txt > 3) length of the requested agenda-slot o 10 min. --------------------------------------------- > 1) the topic you want to present o HIP Domain Name System Extensions > 2) related Internet-Drafts o draft-ietf-hip-dns-01.txt > 3) length of the requested agenda-slot o 5 min. Thanks, -- Julien Laganier Sun Microsystems, Inc. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 22 15:44:21 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 PAA17675 for ; Tue, 22 Feb 2005 15:44:21 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DDC017440; Tue, 22 Feb 2005 15:42:41 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id 44897741D for ; Tue, 22 Feb 2005 15:39:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17171; Tue, 22 Feb 2005 15:39:32 -0500 (EST) Message-Id: <200502222039.PAA17171@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-02.txt 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, 22 Feb 2005 15:39:32 -0500 Date: Tue, 22 Feb 2005 15:39:32 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-02.txt Pages : 95 Date : 2005-2-22 This memo specifies the details of the Host Identity Protocol (HIP). The overall description of protocol and the underlying architectural thinking is available in the separate HIP architecture specification. The Host Identity Protocol is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The various forms of the Host Identity, Host Identity Tag (HIT) and Local Scope Identifier (LSI), are covered in detail. It is described how they are used to support authentication and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secured communication channel between the hosts. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many denial-of-service (DoS)attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered elsewhere. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22155716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155716.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 22 15:44:44 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 PAA17732 for ; Tue, 22 Feb 2005 15:44:43 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id CC8807444; Tue, 22 Feb 2005 15:42:43 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id F034C7415 for ; Tue, 22 Feb 2005 15:39:16 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17136; Tue, 22 Feb 2005 15:39:12 -0500 (EST) Message-Id: <200502222039.PAA17136@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-mm-01.txt 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, 22 Feb 2005 15:39:12 -0500 Date: Tue, 22 Feb 2005 15:39:12 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : End-Host Mobility and Multi-Homing with Host Identity Protocol Author(s) : P. Nikander, et al. Filename : draft-ietf-hip-mm-01.txt Pages : 34 Date : 2005-2-22 This document defines a "locator" parameter for the Host Identity Protocol and specifies an end-host mobility mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-mm-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-mm-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22155710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-mm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-mm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155710.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 22 15:45:15 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 PAA17802 for ; Tue, 22 Feb 2005 15:45:15 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9FA5F744A; Tue, 22 Feb 2005 15:42:46 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id F374A7423 for ; Tue, 22 Feb 2005 15:39:40 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17188; Tue, 22 Feb 2005 15:39:42 -0500 (EST) Message-Id: <200502222039.PAA17188@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-dns-01.txt 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, 22 Feb 2005 15:39:42 -0500 Date: Tue, 22 Feb 2005 15:39:42 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Author(s) : P. Nikander, J. Laganier Filename : draft-ietf-hip-dns-01.txt Pages : 27 Date : 2005-2-22 This document specifies two new resource records (RRs) for the Domain Name System (DNS), and how to use them with the Host Identity Protocol (HIP). These RRs allow a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Name or IP addresses of its Rendezvous Servers (RVS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-dns-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-dns-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22155722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-dns-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-dns-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155722.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 22 15:45:51 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 PAA17868 for ; Tue, 22 Feb 2005 15:45:49 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EA43B7439; Tue, 22 Feb 2005 15:42:51 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id B412D7424 for ; Tue, 22 Feb 2005 15:39:49 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17195; Tue, 22 Feb 2005 15:39:51 -0500 (EST) Message-Id: <200502222039.PAA17195@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-rvs-01.txt 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, 22 Feb 2005 15:39:51 -0500 Date: Tue, 22 Feb 2005 15:39:51 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Rendezvous Extensions Author(s) : J. Laganier, L. Eggert Filename : draft-ietf-hip-rvs-01.txt Pages : 21 Date : 2005-2-22 This document discusses a Rendezvous extension for the Host Identity Protocol (HIP). The Rendezvous extension extend HIP and the HIP registration extension for initiating communication between HIP nodes via HIP Rendezvous Servers. Rendezvous Servers improve operation when HIP nodes are multi-homed or mobile. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-rvs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-rvs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22155727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-rvs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-rvs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155727.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Feb 22 16:34:11 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 QAA24715 for ; Tue, 22 Feb 2005 16:34:08 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 147FF743A; Tue, 22 Feb 2005 16:33:04 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by honor.icsalabs.com (Postfix) with ESMTP id 17A5C7438 for ; Tue, 22 Feb 2005 16:32:56 -0500 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j1MLWcUd021813 for ; Tue, 22 Feb 2005 16:32:38 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 8013C3C818F for ; Tue, 22 Feb 2005 16:30:24 -0500 (EST) Received: from gmp (dhcp239.Research.Panasonic.COM [150.169.1.239])by redwood.research.panasonic.com (Postfix) with SMTP id 749A93C8178for ; Tue, 22 Feb 2005 16:30:24 -0500 (EST) Message-ID: <073b01c51928$36411bb0$ef01a996@gmp> From: "Greg Perkins" To: References: <42133673.5040907@piuha.net> Subject: Re: [Hipsec] SHA1 broken? MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:94.10942 C:21 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) 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, 22 Feb 2005 16:48:14 -0500 Date: Tue, 22 Feb 2005 16:48:14 -0500 Content-Transfer-Encoding: 7bit The HIT needs two properties: 1) probably unique 2) a identifier for the HI SHA1 will still supply property 1). As for property 2), I thought HIP was using a non-keyed SHA1 hash for HI=>HIT computation? Basically, HIP is using SHA1's "randomness" property to meet property 1), yes? In this case, there is nothing to break and property 2) holds as well. As for using keyed SHA1 for say, signing a packet or whatnot, then yes, looks like SHA256 will have to be used soon. Greg Perkins ----- Original Message ----- From: "Jari Arkko" To: "Tim Shepard" Cc: "Miika Komu" ; Sent: Wednesday, February 16, 2005 7:02 AM Subject: Re: [Hipsec] SHA1 broken? > Tim Shepard wrote: > > > Does this mean that HITs will need to be 256 bits long now (for there > > are no crypto hash functions left standing with output shorter than > > 256 bits)? I think so. > > Well, if those other functions are secure, do you have to use > all the output bits? Seems like an output cut to 128 would > suffice too, unless there's some weakness in the hash > function. Presumably the SHA-1 weaknesses, if real, > relate to some problem in the definition of the function > rather than the mere insufficiency of the bits... > > --Jari > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun Feb 27 11:53:41 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 LAA12136 for ; Sun, 27 Feb 2005 11:53:40 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id F07A4730C; Sun, 27 Feb 2005 11:53:04 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by honor.icsalabs.com (Postfix) with ESMTP id 31D9772EA; Sun, 27 Feb 2005 11:52:32 -0500 (EST) Received: from [128.214.112.88] (hippy.hiit.fi [128.214.112.88]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sun, 27 Feb 2005 18:52:30 +0200 id 00070E8B.4221FACE.00001A4E Message-ID: <4221FACD.3020401@cs.helsinki.fi> From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec-rg@honor.trusecure.com, hipsec@honor.trusecure.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] InfraHIP update 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, 27 Feb 2005 18:52:29 +0200 Date: Sun, 27 Feb 2005 18:52:29 +0200 Content-Transfer-Encoding: 7bit Hi, The project "Infrastructure for HIP" got a new webpage at http://infrahip.hiit.fi. We plan a next release of HIPL compatible with current drafts on March 14th. Andrei _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Feb 28 09:18:37 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 JAA23275 for ; Mon, 28 Feb 2005 09:18:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 84A5072F3; Mon, 28 Feb 2005 09:18:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by honor.icsalabs.com (Postfix) with ESMTP id CBDEF72EA for ; Mon, 28 Feb 2005 09:17:49 -0500 (EST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1SEHHOu003904; Mon, 28 Feb 2005 15:17:27 +0100 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 15:18:01 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 15:18:01 +0100 Received: from [131.160.37.196] (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9D5E5189CC; Mon, 28 Feb 2005 16:17:14 +0200 (EET) Message-ID: <42232818.1080805@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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2005 14:18:01.0551 (UTC) FILETIME=[4F7D45F0:01C51DA0] Subject: [Hipsec] Agenda IETF 62 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: Mon, 28 Feb 2005 16:18:00 +0200 Date: Mon, 28 Feb 2005 16:18:00 +0200 Content-Transfer-Encoding: 7bit Folks, this is the preliminary agenda for the Minneapolis meeting: http://hip.piuha.net/meetings/ietf62/agenda.html Note that every speaker has gotten more time than he requested. Regards, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Feb 28 09:33:32 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 JAA24602 for ; Mon, 28 Feb 2005 09:33:32 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 68D1672F3; Mon, 28 Feb 2005 09:33:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 45A7072EA for ; Mon, 28 Feb 2005 09:32:23 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1SEWMX8013516 for ; Mon, 28 Feb 2005 07:32:22 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ICM00ICBLPX6M@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 28 Feb 2005 07:32:21 -0700 (MST) Received: from [192.168.1.50] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ICM005M2LPUUN@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 28 Feb 2005 07:32:21 -0700 (MST) From: Julien Laganier Subject: Re: [Hipsec] Agenda IETF 62 In-reply-to: <42232818.1080805@ericsson.com> To: hipsec@honor.trusecure.com Cc: Gonzalo Camarillo , David Ward Message-id: <200502281535.41127.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <42232818.1080805@ericsson.com> 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: Mon, 28 Feb 2005 15:35:40 +0100 Date: Mon, 28 Feb 2005 15:35:40 +0100 Content-Transfer-Encoding: 7BIT Hi Gonzalo, On Monday 28 February 2005 15:18, Gonzalo Camarillo wrote: > Folks, > > this is the preliminary agenda for the Minneapolis meeting: > > http://hip.piuha.net/meetings/ietf62/agenda.html Thanks. I wonder if it would make sense to move the HIP registration slot before the HIP rendezvous slot (or vice versa), because a node use registration protocol to register with its rendezvous server. --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Feb 28 11:48:33 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 LAA07769 for ; Mon, 28 Feb 2005 11:48:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 38FC572F4; Mon, 28 Feb 2005 11:48:02 -0500 (EST) 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 B824072F3 for ; Mon, 28 Feb 2005 11:47:43 -0500 (EST) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1SGlWh5006972 for ; Mon, 28 Feb 2005 17:47:40 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 17:48:18 +0100 Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id F5NBFYM9; Mon, 28 Feb 2005 17:50:34 +0100 Received: from [131.160.126.21] (unknown [131.160.126.21]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B36A8189CC; Mon, 28 Feb 2005 18:47:31 +0200 (EET) Message-ID: <42234B51.4030208@ericsson.com> X-Sybari-Trust: 70ee416a b8ec86c7 841b62c0 00000139 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier Cc: hipsec@honor.trusecure.com, David Ward Subject: Re: [Hipsec] Agenda IETF 62 References: <42232818.1080805@ericsson.com> <200502281535.41127.julien.laganier@sun.com> In-Reply-To: <200502281535.41127.julien.laganier@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2005 16:48:18.0660 (UTC) FILETIME=[4E1AEA40:01C51DB5] 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: Mon, 28 Feb 2005 18:48:17 +0200 Date: Mon, 28 Feb 2005 18:48:17 +0200 Content-Transfer-Encoding: 7bit Done. Gonzalo Julien Laganier wrote: > Hi Gonzalo, > > On Monday 28 February 2005 15:18, Gonzalo Camarillo wrote: > >>Folks, >> >>this is the preliminary agenda for the Minneapolis meeting: >> >>http://hip.piuha.net/meetings/ietf62/agenda.html > > > Thanks. > > I wonder if it would make sense to move the HIP registration slot > before the HIP rendezvous slot (or vice versa), because a node use > registration protocol to register with its rendezvous server. > > --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Feb 28 12:04: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 MAA09673 for ; Mon, 28 Feb 2005 12:04:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 0F40C72F4; Mon, 28 Feb 2005 12:04:04 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id BA65372F3 for ; Mon, 28 Feb 2005 12:03:19 -0500 (EST) 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 JAA17490; Mon, 28 Feb 2005 09:02:54 -0800 (PST) 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 j1SH2sE11807; Mon, 28 Feb 2005 11:02:54 -0600 (CST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 09:02:53 -0800 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] Agenda IETF 62 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06648F5F@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Agenda IETF 62 Thread-Index: AcUdoFnrk1LaH6PoSm+FZOxvxTmTXQAFpXUg From: "Henderson, Thomas R" To: "Gonzalo Camarillo" Cc: "David Ward" , "HIP" X-OriginalArrivalTime: 28 Feb 2005 17:02:53.0291 (UTC) FILETIME=[576D03B0:01C51DB7] 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: Mon, 28 Feb 2005 09:02:52 -0800 Date: Mon, 28 Feb 2005 09:02:52 -0800 Content-Transfer-Encoding: quoted-printable Gonzalo, i) it would seem to make sense to keep the discussion on HIP-MM draft together-- suggest moving my presentation on hip-mm to just before Christian's slot ii) likewise, the draft on generalizing HIP pertains to the base spec and could be moved up to the third slot. Tom=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Monday, February 28, 2005 6:18 AM > To: HIP > Cc: David Ward > Subject: [Hipsec] Agenda IETF 62 >=20 > Folks, >=20 > this is the preliminary agenda for the Minneapolis meeting: >=20 > http://hip.piuha.net/meetings/ietf62/agenda.html >=20 > Note that every speaker has gotten more time than he requested. >=20 > Regards, >=20 > Gonzalo > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 >=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec