From hipsec-bounces@lists.ietf.org Mon Jul 02 10:14:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Mfq-0000yo-3x; Mon, 02 Jul 2007 10:14:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Mfn-0000ye-Sn for hipsec@lists.ietf.org; Mon, 02 Jul 2007 10:14:39 -0400 Received: from creon.otaverkko.fi ([212.68.0.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5MfR-0008Vb-9e for hipsec@lists.ietf.org; Mon, 02 Jul 2007 10:14:39 -0400 Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 625F921AF57 for ; Mon, 2 Jul 2007 17:14:16 +0300 (EEST) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10235-02; Mon, 2 Jul 2007 17:14:13 +0300 (EEST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 4282021AF43 for ; Mon, 2 Jul 2007 17:14:13 +0300 (EEST) Received: from localhost (hydra.otaverkko.fi [212.68.0.4]) by argo.otaverkko.fi (Postfix) with ESMTP id 3CD7725ED06 for ; Mon, 2 Jul 2007 17:14:13 +0300 (EEST) Received: from ip94.infrahip.net (ip94.infrahip.net [193.167.187.94]) by webmail.hiit.fi (IMP) with HTTP for ; Mon, 02 Jul 2007 17:14:13 +0300 Message-ID: <1183385653.46890835352e5@webmail.hiit.fi> Date: Mon, 02 Jul 2007 17:14:13 +0300 From: Alberto Garcia To: hipsec@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 193.167.187.94 X-Virus-Scanned: amavisd-new at otaverkko.fi Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Hipsec] HIPL interoperability tests X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hello everybody, Recently in HIPL we have implemented a couple of changes that may affect = the interoperability between implementations. The first important change is t= he update to the new HIT prefix allocated by IANA (2001:10::/28). The secon= d is the support for multiple Diffie-Hellman keys. Therefore, it is possible t= o select whether sending 1 or 2 DH Public Values in the R1 packets. As well= , upon reception of 2 DH keys, the Initiator can choose the stronger or weaker k= ey and send it back in the I2 packet. Due to those changes, we tested again the interoperability with the other implementations, focusing in the base exchange. We had these results: - HIP for BSD (Ericsson, NomadicLab): Currently not reachable using HIP d= ue to some problems in the test network. However, some weeks ago the base excha= nge was working fine with these changes. - OpenHIP (Boeing): The test is successful: the base exchange is performe= d and the ESTABLISHED state is reached. Of course, HIPL was tested against itself successfully. The testing sever= for HIPL is ashenvale.infrahip.net (Currently, it sends 2 DH keys in the R1s)= : HIT: 2001:15:cf89:912:d2da:10af:411f:1252 IPv6: 2001:db8:0:f101::6 IPv4: 193.167.187.133 Please, let us know the results of your interoperability tests against HI= PL. Best Regards, Alberto Garc=EDa _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 02 20:55:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Wfu-0007hY-8A; Mon, 02 Jul 2007 20:55:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Wfs-0007hT-Oa for hipsec@ietf.org; Mon, 02 Jul 2007 20:55:24 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Wfo-0000RI-FT for hipsec@ietf.org; Mon, 02 Jul 2007 20:55:24 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l630tHdJ023118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Jul 2007 19:55:17 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l630tGZj000388; Mon, 2 Jul 2007 17:55:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l630tGpl000379; Mon, 2 Jul 2007 17:55:16 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.46]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 17:55:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Re: ICE-for-HIP: the design choices Date: Mon, 2 Jul 2007 17:55:16 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049576@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Re: ICE-for-HIP: the design choices Thread-Index: Ace3H4XOy+V7rx+cSGmaPFi9EzXg9wF7OMDQ From: "Henderson, Thomas R" To: "Miika Komu" , "Pekka Nikander" X-OriginalArrivalTime: 03 Jul 2007 00:55:16.0763 (UTC) FILETIME=[D23A1EB0:01C7BD0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: HIP WG , Hannes Tschofenig , Hannes Tschofenig , Philip Matthews X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 I'm catching up on this extensive thread and will respond to other points once I'm caught up with the drafts, but I'll respond now to this specific question addressed to me below. > I believe the main reason why the LOCATOR is in R1 is that=20 > the Responder=20 > can "force" the Initiator to switch immediately to an=20 > alternative address=20 > already in I2. However, this cannot be applied to NAT=20 > traversal because=20 > reachability detection for working addresss pairs must be done first. >=20 > Tom, can you comment this? >=20 Yes, this is the reason for LOCATOR in R1, but NAT traversal considerations were not taken into account at that time. - Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 05 16:18:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6XmJ-00069B-K3; Thu, 05 Jul 2007 16:18:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6XmD-0005yu-6q for hipsec@ietf.org; Thu, 05 Jul 2007 16:18:09 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6XmB-0004OH-VA for hipsec@ietf.org; Thu, 05 Jul 2007 16:18:09 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 249BF20739; Thu, 5 Jul 2007 22:17:59 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-f6-468d51f758ed Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 09180206A7; Thu, 5 Jul 2007 22:17:59 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:17:58 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:17:58 +0200 Received: from [131.160.126.81] (rvi2-126-81.lmf.ericsson.se [131.160.126.81]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EB9FE2342; Thu, 5 Jul 2007 23:17:57 +0300 (EEST) Message-ID: <468D51F5.5090503@ericsson.com> Date: Thu, 05 Jul 2007 23:17:57 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 20:17:58.0136 (UTC) FILETIME=[94125F80:01C7BF41] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Hipsec] NAT traversal drafts X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, we have been asked by Miika whether or not he can submit a new revision of his NAT traversal draft as a WG item, given all the discussions on the list and the fact that there are currently two approaches documented in two different drafts on the table. At this point, we believe that Miika should go ahead and submit the revision that has been discussed on the list as a WG item so that it is properly archived. Of course, that does not mean that the WG cannot change its mind and decide to go for a different approach at some point. It just ensures that the draft is properly archived. Regarding the technical discussions on both approaches, it is unfortunate that when this topic started getting traction on the list, it was already too late to request a slot to meet in Chicago. Therefore, we will need to continue these discussions on the list for the time being. In any case, we may try and organize a small ad-hoc meeting in Chicago to discuss this issue. Please, send an email to the chairs if you would be interested in actively participating (i.e., no tourists allowed) in such an ad-hoc meeting. Cheers, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 06 04:11:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6iuf-0001oB-KC; Fri, 06 Jul 2007 04:11:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6iue-0001iX-8S for hipsec@ietf.org; Fri, 06 Jul 2007 04:11:36 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6iud-0001Cd-VR for hipsec@ietf.org; Fri, 06 Jul 2007 04:11:36 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6356D203E4; Fri, 6 Jul 2007 10:10:46 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-3f-468df906d23e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5155F20AB0; Fri, 6 Jul 2007 10:10:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 10:10:45 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 10:10:45 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9CDC925BE; Fri, 6 Jul 2007 11:10:45 +0300 (EEST) Message-ID: <468DF905.5060909@ericsson.com> Date: Fri, 06 Jul 2007 11:10:45 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 08:10:45.0733 (UTC) FILETIME=[278BC950:01C7BFA5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Hipsec] Potential ICE tutorial in Chicago X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, we may (it is still a possibility, nothing confirmed yet) be able to organize an ICE tutorial in Chicago during a lunch slot. I will come back with more details as soon as we arrange the whole thing. If we manage to arrange it, it will be a good opportunity for folks to get more familiar with ICE. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jul 06 15:15:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tGs-0005Af-2C; Fri, 06 Jul 2007 15:15:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tGq-00054y-NY; Fri, 06 Jul 2007 15:15:12 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6tGq-00055V-6f; Fri, 06 Jul 2007 15:15:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 129F12ACC3; Fri, 6 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6tGf-0006QZ-Pg; Fri, 06 Jul 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Jul 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-nat-traversal-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : HIP Extensions for the Traversal of Network Address Translators Author(s) : V. Schmitt, et al. Filename : draft-ietf-hip-nat-traversal-02.txt Pages : 31 Date : 2007-7-6 The Host Identity Protocol (HIP) provides a new namespace that can be used for uniquely identifying hosts in public and also in private address realms. Usually, HIP control and data traffic cannot traverse Network Address Translators (NATs), that hinders general deployment. This document specifies NAT traversal extensions for HIP. As HIP is located between network and transport layer, the extensions also provide general-purpose NAT traversal support for all high-layer networking applications that run over HIP. The basic design concepts for these extensions have been adopted from the Interactive Connectivity Establishment (ICE) protocol to HIP. Using the specified extensions, two HIP-capable hosts are able to communicate with each other even when they are in different private address realms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-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-nat-traversal-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-nat-traversal-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: <2007-7-6141933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-nat-traversal-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-nat-traversal-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-6141933.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Sun Jul 08 18:15:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7f24-00071x-Qb; Sun, 08 Jul 2007 18:15:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7f1z-00070j-BX; Sun, 08 Jul 2007 18:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7f1y-00038x-UF; Sun, 08 Jul 2007 18:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A2674175E5; Sun, 8 Jul 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7f1y-00027N-8I; Sun, 08 Jul 2007 18:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 08 Jul 2007 18:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-native-api-02.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Native Application Programming Interfaces for SHIM APIs Author(s) : M. Komu Filename : draft-ietf-hip-native-api-02.txt Pages : 12 Date : 2007-7-8 This document defines extensions to the current networking APIs for protocols based on identifier/locator split. Currently, the document focuses on HIP, but the extensions can be used also by other protocols implementing identifier locator split. Using the API extensions, new SHIM aware applications can configure manually mappings between upper layer identifiers and the corresponding locators. Also, the API describes how to handle outbound connection establishment where an application is unaware of the peer identifier but knows the peer locator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-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-native-api-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-native-api-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: <2007-7-8171623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-native-api-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-native-api-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-8171623.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Mon Jul 09 03:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7nQ1-0005xt-PG; Mon, 09 Jul 2007 03:12:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7nQ0-0005xR-T2 for hipsec@ietf.org; Mon, 09 Jul 2007 03:12:24 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7nPw-0005u6-4h for hipsec@ietf.org; Mon, 09 Jul 2007 03:12:24 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 696D521509; Mon, 9 Jul 2007 09:12:19 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-4c-4691dfd327ff Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0013521430; Mon, 9 Jul 2007 09:12:18 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:12:18 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:12:18 +0200 Received: from [131.160.126.32] (rvi2-126-32.lmf.ericsson.se [131.160.126.32]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E8B822465; Mon, 9 Jul 2007 10:12:17 +0300 (EEST) Message-ID: <4691DFCF.2000104@ericsson.com> Date: Mon, 09 Jul 2007 10:12:15 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 07:12:18.0575 (UTC) FILETIME=[7C5B31F0:01C7C1F8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Hipsec] ICE tutorial in Chicago X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, please, find below the announcement for the ICE tutorial in Chicago by Jonathan Rosenberg. Cheers, Gonzalo HIP WG co-chair WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 09 11:39:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vL9-0000Ke-6l; Mon, 09 Jul 2007 11:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vL3-0008UK-KV for hipsec@ietf.org; Mon, 09 Jul 2007 11:39:49 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7vKy-000392-UN for hipsec@ietf.org; Mon, 09 Jul 2007 11:39:49 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7BBD4200F047; Mon, 9 Jul 2007 17:39:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NsGa9zOwF7v; Mon, 9 Jul 2007 17:39:44 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5444B200018A; Mon, 9 Jul 2007 17:39:24 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Hipsec] Rebuilding ICE Date: Mon, 9 Jul 2007 17:39:09 +0200 Message-ID: In-Reply-To: <4683FA66.3000306@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Hipsec] Rebuilding ICE thread-index: Ace5sE9d9o7IWPUuTlWGU6kcAkE2QQIiyXjw References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC34B@MCHP7IDA.ww002.siemens.net> <251E0BEF-97CA-41C6-BCBC-1DC3156109D4@nomadiclab.com> <4683FA66.3000306@gmx.net> From: "Marcus Brunner" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: HIP WG , "Tschofenig, Hannes" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hannes, et al. The basic idea behind HIP NAT version 00 and version 01 was on getting a = first quick hack to experiment with HIP over NATs, for distributed tests = etc. Also version 01 seamed to technically work, for most cases, but not = all of them. Now going down the ICE path, I project another 2-3 years of = discussion on getting it resolved.=20 My proposal would be to have a quick 01 follow-up draft trying to close = that way of doing HIP over legacy NATs, and at the same time really do a = HIP ICE draft, probably in the HIP RG first, because I am not completely = sure whether all the 100 pages of ICE are applicable right away to HIP = (not only the encoding part). Kind regards, Marcus --------------------------------------------------- Dr. Marcus Brunner NEC Laboratories Europe Network Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, June 28, 2007 8:14 PM > To: Marcus Brunner > Cc: Pekka Nikander; Tschofenig, Hannes; HIP WG > Subject: Re: AW: [Hipsec] Rebuilding ICE >=20 > Hi Marcus, >=20 > which parts of ICE do you consider an overkill? >=20 > Ciao > Hannes >=20 > Marcus Brunner wrote: > > Pekka, > > > > Well put. I agree with you statement.=20 > > > > Some parts of the ICE methodoldy are a bit an overkill in=20 > my opinion, so they could be discussed, whether they apply to=20 > HIP. The benefit naturally is that people seam to understand ICE. > > > > Actually, I would even propose that we should have a look=20 > at node-multi-homing, becasue it seams there are similarities=20 > like offered IP addresses/ports/.. to the responding peer. > > > > > > Kind regards, > > > > Marcus > > > > --------------------------------------------------- > > > > Dr. Marcus Brunner > > NEC Laboratories Europe > > Network Division > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,=20 > > London W3 6BL | Registered in England 2832014 > > > > =20 > > > > =20 > >> -----Original Message----- > >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > >> Sent: Tuesday, June 26, 2007 11:26 AM > >> To: Tschofenig, Hannes > >> Cc: HIP WG; Hannes Tschofenig; Marcus Brunner > >> Subject: Re: AW: [Hipsec] Rebuilding ICE > >> > >> Hannes, > >> > >> =20 > >>> ICE is a methodology. We suggest to make extensive use of it. > >>> The only "format" the ICE document suggests is the encoding of=20 > >>> candiates. > >>> I have stated many times that one can think about a more=20 > optimized=20 > >>> encoding. That's OK. > >>> =20 > >> I think we all understand the basic idea of ICE being a=20 > >> methodology. =20 > >> At least I am not objecting to using it, as a methodology. =20 > >> However, in addition to defining the SDP encoding for the=20 > candidates,=20 > >> it also defines how to use STUN and TURN, so there are,=20 > indirectly,=20 > >> more formats and network nodes (TURN and STUN servers) built into=20 > >> ICE. > >> > >> Now, from my point of view an important architectural is=20 > not to make=20 > >> HIP dependent on TURN and STUN servers, nor the UDP encapsulation=20 > >> formats used in STUN, nor any other such details. > >> > >> HIP has already the rendezvous servers defined, and a well-defined=20 > >> mechanism for contacting hosts using the rendezvous=20 > servers. It also=20 > >> already has a mobility mechanism, and a rudimentary mechanism for=20 > >> multi-homing. > >> > >> I may have misunderstood, but from my point of view, using ICE=20 > >> terminology, HIP already seems to have the necessary=20 > mechanisms form=20 > >> Encoding, Offering and Answering, and Completing (I'm=20 > drawing these=20 > >> terms from the ICE tutorial, my apology if the spec uses other=20 > >> terms). > >> > >> What HIP is primarily missing is Gathering and Prioritising, which=20 > >> BTW are not a real protocol issues, and therefore most=20 > probably could=20 > >> be quite easily adopted from ICE, and Checking, where the=20 > past idea=20 > >> was to use the SHIM6 protoocol. > >> For checking, the fact that native HIP uses both a=20 > separate protocol=20 > >> number of HIP control and ESP (or something else) for data traffic=20 > >> necessitates the ICE checking methodology to be modified=20 > anyway. The=20 > >> same applies, as far as I can see, also to the NAT traversal case,=20 > >> where HIP is using the IPsec encoding of UDP, not generic UDP. =20 > >> Hence, I don't think STUN applies there directly. > >> > >> Remember, when HIP is used the UDP and TCP messages are carried=20 > >> encoded somehow, typically in ESP wrappers, and therefore=20 > some of the=20 > >> problems specific to ICE/STUN (like port reuse) don't=20 > apply or apply=20 > >> in a different form. > >> > >> =20 > >>>> It's also fairly clear that there is reason to somewhat=20 > adapt ICE=20 > >>>> anyway; > >>>> =20 > >>> That's fine. For example, I wrote that you could use the RVS as a=20 > >>> reverse tunneling mechanism (in the spirit of TURN) to=20 > avoid using=20 > >>> TURN. In an upcoming draft I will explain why it still > >>> =20 > >> makes a lot of > >> =20 > >>> sense to use TURN but that's another story. > >>> =20 > >> For TURN I don't understand why it would make any sense to use it,=20 > >> but maybe I don't understand it, again. Anyway, I would=20 > consider it=20 > >> undesirable to make HIP dependent on TURN. > >> > >> If you would like to allow *optional* use of TURN, them=20 > I'm fine. As=20 > >> long as the base HIP mechanisms would work with only one=20 > new piece of=20 > >> infrastructure, the RVS servers. > >> > >> But I really would like to hear your detailed list of=20 > issues on the=20 > >> table. > >> > >> --Pekka > >> > >> > >> _______________________________________________ > >> Hipsec mailing list > >> Hipsec@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/hipsec > >> > >> =20 >=20 >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 10 19:48:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8PRi-0007my-TT; Tue, 10 Jul 2007 19:48:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8PRh-0007mt-Bm for hipsec@ietf.org; Tue, 10 Jul 2007 19:48:41 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8PRg-0001NI-KC for hipsec@ietf.org; Tue, 10 Jul 2007 19:48:41 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Jul 2007 16:44:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAa4k0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,524,1175497200"; d="scan'208"; a="179847896:sNHT426227832" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6ANidSn014282; Tue, 10 Jul 2007 16:44:39 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6ANiYmo026125; Tue, 10 Jul 2007 23:44:38 GMT From: "Dan Wing" To: "'Marcus Brunner'" , "'Hannes Tschofenig'" Subject: RE: AW: [Hipsec] Rebuilding ICE Date: Tue, 10 Jul 2007 16:44:34 -0700 Message-ID: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace5sE9d9o7IWPUuTlWGU6kcAkE2QQIiyXjwAEM/vZA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8189; t=1184111079; x=1184975079; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20AW=3A=20[Hipsec]=20Rebuilding=20ICE |Sender:=20; bh=vgZDfyAIJfyXEm89kta5yEfYTy00zcWwT/0f7LHFl3g=; b=G0Dg/l3VKERyG9xyy2wFgh0jxVgnRSZIp39OvT9hklIhSaxpyKFiS632Bg/NtZ+3SStIG04g Vv40vgLOhmt2tL8oNPcY0SSeuCgvfPLfehhEexsXdUos18G4yhDHP0GQrMbeSD8vAa1I14GAmB etf+EJUGhHHx53CitOpx41jdY=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: 'HIP WG' , "'Tschofenig, Hannes'" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Yes, it is clear that not all 100 pages of ICE would apply to HIP. The first version of ICE (draft-rosenberg-sipping-ice-00.txt, Feb-2003) was 34 pages. That is only one page longer than draft-ietf-hip-nat-traversal-00! In four and a half years of design, ICE is now 110 pages long and is used on the Internet (Google, MSN, and Yahoo use ICE for their interactive audio and video features). I expect the HIP working group (or IRTF, as you are proposing) could re-invent ICE in less than 4.5 years -- afterall, ICE can be used as a design guide. However, what is the value in spending IETF/IRTF time and energy re-inventing ICE? Any shortcuts may not work well, whereas ICE was designed (and works) in all NAT scenarios after significant peer review. Those additional 70 pages in ICE weren't added because the author's fingers needed the exercise! There are already ICE libraries available with reasonable licensing terms. There are people willing to help HIP (and MIP, and RTSP) get ICE specified. My attempt to improve HIP's NAT traversal are clearly undesired by the working group. If and when HIP desires a functional, robust, and incrementally-deployable NAT traversal mechanism, that works on the Internet, hopefully someone will drop me an email and I can engage with HIP again. -d > -----Original Message----- > From: Marcus Brunner [mailto:Brunner@netlab.nec.de] > Sent: Monday, July 09, 2007 8:39 AM > To: Hannes Tschofenig > Cc: HIP WG; Tschofenig, Hannes > Subject: RE: AW: [Hipsec] Rebuilding ICE > > Hannes, et al. > > The basic idea behind HIP NAT version 00 and version 01 was > on getting a first quick hack to experiment with HIP over > NATs, for distributed tests etc. Also version 01 seamed to > technically work, for most cases, but not all of them. Now > going down the ICE path, I project another 2-3 years of > discussion on getting it resolved. > > My proposal would be to have a quick 01 follow-up draft > trying to close that way of doing HIP over legacy NATs, and > at the same time really do a HIP ICE draft, probably in the > HIP RG first, because I am not completely sure whether all > the 100 pages of ICE are applicable right away to HIP (not > only the encoding part). > > Kind regards, > > Marcus > > --------------------------------------------------- > > Dr. Marcus Brunner > NEC Laboratories Europe > Network Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, London W3 6BL | Registered in England 2832014 > > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Thursday, June 28, 2007 8:14 PM > > To: Marcus Brunner > > Cc: Pekka Nikander; Tschofenig, Hannes; HIP WG > > Subject: Re: AW: [Hipsec] Rebuilding ICE > > > > Hi Marcus, > > > > which parts of ICE do you consider an overkill? > > > > Ciao > > Hannes > > > > Marcus Brunner wrote: > > > Pekka, > > > > > > Well put. I agree with you statement. > > > > > > Some parts of the ICE methodoldy are a bit an overkill in > > my opinion, so they could be discussed, whether they apply to > > HIP. The benefit naturally is that people seam to understand ICE. > > > > > > Actually, I would even propose that we should have a look > > at node-multi-homing, becasue it seams there are similarities > > like offered IP addresses/ports/.. to the responding peer. > > > > > > > > > Kind regards, > > > > > > Marcus > > > > > > --------------------------------------------------- > > > > > > Dr. Marcus Brunner > > > NEC Laboratories Europe > > > Network Division > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 > Victoria Road, > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > > >> Sent: Tuesday, June 26, 2007 11:26 AM > > >> To: Tschofenig, Hannes > > >> Cc: HIP WG; Hannes Tschofenig; Marcus Brunner > > >> Subject: Re: AW: [Hipsec] Rebuilding ICE > > >> > > >> Hannes, > > >> > > >> > > >>> ICE is a methodology. We suggest to make extensive use of it. > > >>> The only "format" the ICE document suggests is the encoding of > > >>> candiates. > > >>> I have stated many times that one can think about a more > > optimized > > >>> encoding. That's OK. > > >>> > > >> I think we all understand the basic idea of ICE being a > > >> methodology. > > >> At least I am not objecting to using it, as a methodology. > > >> However, in addition to defining the SDP encoding for the > > candidates, > > >> it also defines how to use STUN and TURN, so there are, > > indirectly, > > >> more formats and network nodes (TURN and STUN servers) > built into > > >> ICE. > > >> > > >> Now, from my point of view an important architectural is > > not to make > > >> HIP dependent on TURN and STUN servers, nor the UDP > encapsulation > > >> formats used in STUN, nor any other such details. > > >> > > >> HIP has already the rendezvous servers defined, and a > well-defined > > >> mechanism for contacting hosts using the rendezvous > > servers. It also > > >> already has a mobility mechanism, and a rudimentary > mechanism for > > >> multi-homing. > > >> > > >> I may have misunderstood, but from my point of view, using ICE > > >> terminology, HIP already seems to have the necessary > > mechanisms form > > >> Encoding, Offering and Answering, and Completing (I'm > > drawing these > > >> terms from the ICE tutorial, my apology if the spec uses other > > >> terms). > > >> > > >> What HIP is primarily missing is Gathering and > Prioritising, which > > >> BTW are not a real protocol issues, and therefore most > > probably could > > >> be quite easily adopted from ICE, and Checking, where the > > past idea > > >> was to use the SHIM6 protoocol. > > >> For checking, the fact that native HIP uses both a > > separate protocol > > >> number of HIP control and ESP (or something else) for > data traffic > > >> necessitates the ICE checking methodology to be modified > > anyway. The > > >> same applies, as far as I can see, also to the NAT > traversal case, > > >> where HIP is using the IPsec encoding of UDP, not generic UDP. > > >> Hence, I don't think STUN applies there directly. > > >> > > >> Remember, when HIP is used the UDP and TCP messages are carried > > >> encoded somehow, typically in ESP wrappers, and therefore > > some of the > > >> problems specific to ICE/STUN (like port reuse) don't > > apply or apply > > >> in a different form. > > >> > > >> > > >>>> It's also fairly clear that there is reason to somewhat > > adapt ICE > > >>>> anyway; > > >>>> > > >>> That's fine. For example, I wrote that you could use > the RVS as a > > >>> reverse tunneling mechanism (in the spirit of TURN) to > > avoid using > > >>> TURN. In an upcoming draft I will explain why it still > > >>> > > >> makes a lot of > > >> > > >>> sense to use TURN but that's another story. > > >>> > > >> For TURN I don't understand why it would make any sense > to use it, > > >> but maybe I don't understand it, again. Anyway, I would > > consider it > > >> undesirable to make HIP dependent on TURN. > > >> > > >> If you would like to allow *optional* use of TURN, them > > I'm fine. As > > >> long as the base HIP mechanisms would work with only one > > new piece of > > >> infrastructure, the RVS servers. > > >> > > >> But I really would like to hear your detailed list of > > issues on the > > >> table. > > >> > > >> --Pekka > > >> > > >> > > >> _______________________________________________ > > >> Hipsec mailing list > > >> Hipsec@lists.ietf.org > > >> https://www1.ietf.org/mailman/listinfo/hipsec > > >> > > >> > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 12 13:01:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9236-0007Yo-UC; Thu, 12 Jul 2007 13:01:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9236-0007YV-7Q for hipsec@ietf.org; Thu, 12 Jul 2007 13:01:52 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9231-0002x0-Lv for hipsec@ietf.org; Thu, 12 Jul 2007 13:01:52 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1021679uge for ; Thu, 12 Jul 2007 10:01:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=n+aqcsAVLWQzyNg4h0cFqwO1OeHp8dW/p3ibery7rycvhjzs78IXhqq4ef+JxXPucpTVoGMcynz7msNd7j77CJx/RCyZP1pfDfd5S6BjcYuoQbJ1cQlD8DPvVlKNpBrdKYWYGbhlh006QkZOyVQEXPXvgTLZLGYzhZmj97LQ1rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=pOiH8gVCUiY+ceJCHoi/JhLFKMI1kpIf0vxMDma4MhHsExzEyEbffe1CKLIhAH8AEoIhqJJKtXq5uLLWQRAFuYcylwKBk34llDY7ihvA9PzPrM/L9MXrjF4VSLYV/VyeqKgbYDLTtaMKJinarP/QarCidjNK8E+psSlTi2zoqsk= Received: by 10.82.160.2 with SMTP id i2mr816998bue.1184259706605; Thu, 12 Jul 2007 10:01:46 -0700 (PDT) Received: from ?192.168.1.105? ( [212.119.9.178]) by mx.google.com with ESMTP id 6sm7118208nfv.2007.07.12.10.01.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2007 10:01:45 -0700 (PDT) From: Julien Laganier To: gabriel montenegro Date: Thu, 12 Jul 2007 19:03:33 +0200 User-Agent: KMail/1.9.1 References: <396019.56274.qm@web81907.mail.mud.yahoo.com> In-Reply-To: <396019.56274.qm@web81907.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707121903.33967.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: hipsec@ietf.org Subject: [Hipsec] Re: some comments on draft-ietf-hip-dns-09 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Gabriel, On Tuesday 10 July 2007 09:59, gabriel montenegro wrote: > I realize these comments are soooo late they might > instead be considered early for the next revision of > the document. Your call. Later is better than never :) Thanks for the comments! > I'm not a DNS expert so have no comments on those > aspects of the draft. I do have some concerns. > > First technical comment: > Section 5.1 only specifies RSA and DSA. Suggest > including ECC as well and getting on with the > times... I never thought about this. This is something that the working group may consider. Note however that including ECC in the DNS RR would not be sufficient; the HIP protocol would also need to be extended/modified to be able to handle ECC public keys and signatures. [...] > But my main concern is with the fact that this RR > encodes a raw public component. This is dangerous. > With CGAs, the assumed (as far as I can see) usage > is that they are meant for ephemeral (short-lived) > usage. But by publishing HIs in the DNS, we are > promoting them as long-lived entities. Accordingly, > the usual knee-jerk reaction to any such usage of > public key technology is: how do you handle > revocation? By encoding a raw public component you > now rely on the DNS to control usage of that HI. > This is a dubious proposition. If, however, the > encoding allowed for HIs to be certificates > (self-signed or CA-issued, whatever) then you could > have the flexibility of populating certain fields to > aid in revocation by pointing at OCSPs or aid in CRL > resolution, without *exclusively* relying on > DNS-based mechanisms to limit usage of the HI in > question. I've never thought too much about revocation in the context of HIP... It is possible to control (i.e. limit in time) usage of the HIs by limiting the TTL of the DNS zones in which you store HIP information. As you note the HIP protocol itself has no provisions to handle certificates with OCSPs as HIs. One guess is that it might have been a design choice, that the identifiers used by HIP are purely flat, non-hierarchical, and can't be traced back to any kind of authority. I am however certainly not right, others on the list might know better... Also, and FWIW, HIP would not be the first protocol to store raw public keys in the protocol, since there's already "A Method for Storing IPsec Keying Material in DNS" [RFC4025]. I do not have a strong opinion on the matters. I think your proposal of allowing HIs to be certificates is interesting. What does the WG at large think of that? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 12 15:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94d3-0006uv-C3; Thu, 12 Jul 2007 15:47:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94d0-0006ui-1s for hipsec@ietf.org; Thu, 12 Jul 2007 15:47:06 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I94cz-0006W6-OF for hipsec@ietf.org; Thu, 12 Jul 2007 15:47:05 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1C3D1203A5; Thu, 12 Jul 2007 21:46:49 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-21-469685288621 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E29052019F; Thu, 12 Jul 2007 21:46:48 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 21:46:48 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 21:46:48 +0200 Received: from [131.160.126.22] (rvi2-126-22.lmf.ericsson.se [131.160.126.22]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 075C323F6; Thu, 12 Jul 2007 22:46:47 +0300 (EEST) Message-ID: <46968526.8080203@ericsson.com> Date: Thu, 12 Jul 2007 22:46:46 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dan Wing Subject: Re: AW: [Hipsec] Rebuilding ICE References: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> In-Reply-To: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 19:46:48.0284 (UTC) FILETIME=[6271D9C0:01C7C4BD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "'Tschofenig, Hannes'" , 'HIP WG' , 'Hannes Tschofenig' , 'Marcus Brunner' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Dan, > My attempt to improve HIP's NAT traversal are clearly undesired by the > working group. If and when HIP desires a functional, robust, and > incrementally-deployable NAT traversal mechanism, that works on the > Internet, hopefully someone will drop me an email and I can engage with HIP > again. many people in the HIP WG appreciate your input very much. It is just that some people are not familiar with ICE and have a gut feeling that it is too complex. I hope that the ICE tutorial to be held in Chicago helps everybody understand where the complexity of ICE comes from and why it is there (i.e., it resolves a complex problem). I also hope that, after that tutorial, technical discussions on this topic are somewhat more fruitful than the ones we have had so far. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jul 15 04:16:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9zHh-0000Yw-OD; Sun, 15 Jul 2007 04:16:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9zHg-0000YV-FR for hipsec@ietf.org; Sun, 15 Jul 2007 04:16:52 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9zHZ-0006Qk-Vs for hipsec@ietf.org; Sun, 15 Jul 2007 04:16:52 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 899DE203F9 for ; Sun, 15 Jul 2007 10:15:32 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-76-4699d7a46eca Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7002C20187 for ; Sun, 15 Jul 2007 10:15:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 10:15:32 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 10:15:31 +0200 Received: from [131.160.126.81] (rvi2-126-81.lmf.ericsson.se [131.160.126.81]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D6CAD2339; Sun, 15 Jul 2007 11:15:31 +0300 (EEST) Message-ID: <4699D7A3.6070002@ericsson.com> Date: Sun, 15 Jul 2007 11:15:31 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Hipsec] NAT traversal drafts References: <468D51F5.5090503@ericsson.com> In-Reply-To: <468D51F5.5090503@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2007 08:15:32.0046 (UTC) FILETIME=[4FEB6EE0:01C7C6B8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, > Regarding the technical discussions on both approaches, it is > unfortunate that when this topic started getting traction on the list, > it was already too late to request a slot to meet in Chicago. Therefore, > we will need to continue these discussions on the list for the time > being. In any case, we may try and organize a small ad-hoc meeting in > Chicago to discuss this issue. Please, send an email to the chairs if > you would be interested in actively participating (i.e., no tourists > allowed) in such an ad-hoc meeting. given that very few people showed interest in such an ad-hoc, we will finally not organize it. In any case, I suggest folks attend the ICE tutorial to get familiar with that technology. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jul 15 10:42:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5Il-0000SV-IZ; Sun, 15 Jul 2007 10:42:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5Ik-0000SP-9H for hipsec@ietf.org; Sun, 15 Jul 2007 10:42:22 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IA5Ij-0002a7-CV for hipsec@ietf.org; Sun, 15 Jul 2007 10:42:22 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9D572200017E; Sun, 15 Jul 2007 16:42:04 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsPkZ8K7JUbc; Sun, 15 Jul 2007 16:42:04 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7447C2000178; Sun, 15 Jul 2007 16:41:44 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: AW: [Hipsec] Rebuilding ICE Date: Sun, 15 Jul 2007 16:41:26 +0200 Message-ID: In-Reply-To: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Hipsec] Rebuilding ICE thread-index: Ace5sE9d9o7IWPUuTlWGU6kcAkE2QQIiyXjwAEM/vZAA6SLmQA== References: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> From: "Marcus Brunner" To: "Dan Wing" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: HIP WG , "Tschofenig, Hannes" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > My attempt to improve HIP's NAT traversal are clearly=20 > undesired by the working group. If and when HIP desires a=20 > functional, robust, and incrementally-deployable NAT=20 > traversal mechanism, that works on the Internet, hopefully=20 > someone will drop me an email and I can engage with HIP again. Dan, I am definitly not against improving HIP's NAT traversal, and I am = greatful for good ICE knowledge on board. My main concern is the timing. = I would have liked an RFC on an easy NAT traversal (which does not work = in all circumstances) by now. Because now its time to experiment with = HIP, which is explicitly an experimental RFC. We only gain more = knowledge if we use HIP, which is realistically not possible without NAT = traversal. Marcus >=20 > -d >=20 > > -----Original Message----- > > From: Marcus Brunner [mailto:Brunner@netlab.nec.de] > > Sent: Monday, July 09, 2007 8:39 AM > > To: Hannes Tschofenig > > Cc: HIP WG; Tschofenig, Hannes > > Subject: RE: AW: [Hipsec] Rebuilding ICE > >=20 > > Hannes, et al. > >=20 > > The basic idea behind HIP NAT version 00 and version 01 was=20 > on getting=20 > > a first quick hack to experiment with HIP over NATs, for=20 > distributed=20 > > tests etc. Also version 01 seamed to technically work, for=20 > most cases,=20 > > but not all of them. Now going down the ICE path, I project another=20 > > 2-3 years of discussion on getting it resolved. > >=20 > > My proposal would be to have a quick 01 follow-up draft trying to=20 > > close that way of doing HIP over legacy NATs, and at the same time=20 > > really do a HIP ICE draft, probably in the HIP RG first,=20 > because I am=20 > > not completely sure whether all the 100 pages of ICE are applicable=20 > > right away to HIP (not only the encoding part). > >=20 > > Kind regards, > >=20 > > Marcus > >=20 > > --------------------------------------------------- > >=20 > > Dr. Marcus Brunner > > NEC Laboratories Europe > > Network Division > >=20 > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,=20 > > London W3 6BL | Registered in England 2832014 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Thursday, June 28, 2007 8:14 PM > > > To: Marcus Brunner > > > Cc: Pekka Nikander; Tschofenig, Hannes; HIP WG > > > Subject: Re: AW: [Hipsec] Rebuilding ICE > > >=20 > > > Hi Marcus, > > >=20 > > > which parts of ICE do you consider an overkill? > > >=20 > > > Ciao > > > Hannes > > >=20 > > > Marcus Brunner wrote: > > > > Pekka, > > > > > > > > Well put. I agree with you statement.=20 > > > > > > > > Some parts of the ICE methodoldy are a bit an overkill in > > > my opinion, so they could be discussed, whether they=20 > apply to HIP.=20 > > > The benefit naturally is that people seam to understand ICE. > > > > > > > > Actually, I would even propose that we should have a look > > > at node-multi-homing, becasue it seams there are=20 > similarities like=20 > > > offered IP addresses/ports/.. to the responding peer. > > > > > > > > > > > > Kind regards, > > > > > > > > Marcus > > > > > > > > --------------------------------------------------- > > > > > > > > Dr. Marcus Brunner > > > > NEC Laboratories Europe > > > > Network Division > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 > > Victoria Road, > > > > London W3 6BL | Registered in England 2832014 > > > > > > > > =20 > > > > > > > > =20 > > > >> -----Original Message----- > > > >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > > > >> Sent: Tuesday, June 26, 2007 11:26 AM > > > >> To: Tschofenig, Hannes > > > >> Cc: HIP WG; Hannes Tschofenig; Marcus Brunner > > > >> Subject: Re: AW: [Hipsec] Rebuilding ICE > > > >> > > > >> Hannes, > > > >> > > > >> =20 > > > >>> ICE is a methodology. We suggest to make extensive use of it. > > > >>> The only "format" the ICE document suggests is the=20 > encoding of=20 > > > >>> candiates. > > > >>> I have stated many times that one can think about a more > > > optimized > > > >>> encoding. That's OK. > > > >>> =20 > > > >> I think we all understand the basic idea of ICE being a=20 > > > >> methodology. =20 > > > >> At least I am not objecting to using it, as a methodology. =20 > > > >> However, in addition to defining the SDP encoding for the > > > candidates, > > > >> it also defines how to use STUN and TURN, so there are, > > > indirectly, > > > >> more formats and network nodes (TURN and STUN servers) > > built into > > > >> ICE. > > > >> > > > >> Now, from my point of view an important architectural is > > > not to make > > > >> HIP dependent on TURN and STUN servers, nor the UDP > > encapsulation > > > >> formats used in STUN, nor any other such details. > > > >> > > > >> HIP has already the rendezvous servers defined, and a > > well-defined > > > >> mechanism for contacting hosts using the rendezvous > > > servers. It also > > > >> already has a mobility mechanism, and a rudimentary > > mechanism for > > > >> multi-homing. > > > >> > > > >> I may have misunderstood, but from my point of view, using ICE=20 > > > >> terminology, HIP already seems to have the necessary > > > mechanisms form > > > >> Encoding, Offering and Answering, and Completing (I'm > > > drawing these > > > >> terms from the ICE tutorial, my apology if the spec uses other=20 > > > >> terms). > > > >> > > > >> What HIP is primarily missing is Gathering and > > Prioritising, which > > > >> BTW are not a real protocol issues, and therefore most > > > probably could > > > >> be quite easily adopted from ICE, and Checking, where the > > > past idea > > > >> was to use the SHIM6 protoocol. > > > >> For checking, the fact that native HIP uses both a > > > separate protocol > > > >> number of HIP control and ESP (or something else) for > > data traffic > > > >> necessitates the ICE checking methodology to be modified > > > anyway. The > > > >> same applies, as far as I can see, also to the NAT > > traversal case, > > > >> where HIP is using the IPsec encoding of UDP, not=20 > generic UDP. =20 > > > >> Hence, I don't think STUN applies there directly. > > > >> > > > >> Remember, when HIP is used the UDP and TCP messages=20 > are carried=20 > > > >> encoded somehow, typically in ESP wrappers, and therefore > > > some of the > > > >> problems specific to ICE/STUN (like port reuse) don't > > > apply or apply > > > >> in a different form. > > > >> > > > >> =20 > > > >>>> It's also fairly clear that there is reason to somewhat > > > adapt ICE > > > >>>> anyway; > > > >>>> =20 > > > >>> That's fine. For example, I wrote that you could use > > the RVS as a > > > >>> reverse tunneling mechanism (in the spirit of TURN) to > > > avoid using > > > >>> TURN. In an upcoming draft I will explain why it still > > > >>> =20 > > > >> makes a lot of > > > >> =20 > > > >>> sense to use TURN but that's another story. > > > >>> =20 > > > >> For TURN I don't understand why it would make any sense > > to use it, > > > >> but maybe I don't understand it, again. Anyway, I would > > > consider it > > > >> undesirable to make HIP dependent on TURN. > > > >> > > > >> If you would like to allow *optional* use of TURN, them > > > I'm fine. As > > > >> long as the base HIP mechanisms would work with only one > > > new piece of > > > >> infrastructure, the RVS servers. > > > >> > > > >> But I really would like to hear your detailed list of > > > issues on the > > > >> table. > > > >> > > > >> --Pekka > > > >> > > > >> > > > >> _______________________________________________ > > > >> Hipsec mailing list > > > >> Hipsec@lists.ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/hipsec > > > >> > > > >> =20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jul 15 10:50:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5QC-000195-PE; Sun, 15 Jul 2007 10:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5QB-00016E-PI for hipsec@ietf.org; Sun, 15 Jul 2007 10:50:03 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA5Q6-0004w2-Jr for hipsec@ietf.org; Sun, 15 Jul 2007 10:50:03 -0400 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 CAA10343; Mon, 16 Jul 2007 02:49:45 +1200 In-Reply-To: References: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59254905-99D7-49AF-896F-A360CF4048C6@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: AW: [Hipsec] Rebuilding ICE Date: Mon, 16 Jul 2007 02:49:38 +1200 To: "Marcus Brunner" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: HIP WG , Hannes Tschofenig , "Tschofenig, Hannes" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Having NAT traversal that actually works is more important to have in published form than NAT traversal that kinda, sorta works, downhill with a tail wind. I think it's worth having the existing draft, but the ICE mechanism is simply required for it to work well enough to be worth putting through the full publication process, which is after all extremely expensive. So, I don't think Dan's attempts are undesired. I think this issue is important enough to do right rather than quickly, which makes ICE important. Andrew On 16/07/2007, at 2:41 AM, Marcus Brunner wrote: > >> My attempt to improve HIP's NAT traversal are clearly >> undesired by the working group. If and when HIP desires a >> functional, robust, and incrementally-deployable NAT >> traversal mechanism, that works on the Internet, hopefully >> someone will drop me an email and I can engage with HIP again. > > Dan, > > I am definitly not against improving HIP's NAT traversal, and I am > greatful for good ICE knowledge on board. My main concern is the > timing. I would have liked an RFC on an easy NAT traversal (which > does not work in all circumstances) by now. Because now its time to > experiment with HIP, which is explicitly an experimental RFC. We > only gain more knowledge if we use HIP, which is realistically not > possible without NAT traversal. > > Marcus > >> >> -d >> >>> -----Original Message----- >>> From: Marcus Brunner [mailto:Brunner@netlab.nec.de] >>> Sent: Monday, July 09, 2007 8:39 AM >>> To: Hannes Tschofenig >>> Cc: HIP WG; Tschofenig, Hannes >>> Subject: RE: AW: [Hipsec] Rebuilding ICE >>> >>> Hannes, et al. >>> >>> The basic idea behind HIP NAT version 00 and version 01 was >> on getting >>> a first quick hack to experiment with HIP over NATs, for >> distributed >>> tests etc. Also version 01 seamed to technically work, for >> most cases, >>> but not all of them. Now going down the ICE path, I project another >>> 2-3 years of discussion on getting it resolved. >>> >>> My proposal would be to have a quick 01 follow-up draft trying to >>> close that way of doing HIP over legacy NATs, and at the same time >>> really do a HIP ICE draft, probably in the HIP RG first, >> because I am >>> not completely sure whether all the 100 pages of ICE are applicable >>> right away to HIP (not only the encoding part). >>> >>> Kind regards, >>> >>> Marcus >>> >>> --------------------------------------------------- >>> >>> Dr. Marcus Brunner >>> NEC Laboratories Europe >>> Network Division >>> >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL | Registered in England 2832014 >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Thursday, June 28, 2007 8:14 PM >>>> To: Marcus Brunner >>>> Cc: Pekka Nikander; Tschofenig, Hannes; HIP WG >>>> Subject: Re: AW: [Hipsec] Rebuilding ICE >>>> >>>> Hi Marcus, >>>> >>>> which parts of ICE do you consider an overkill? >>>> >>>> Ciao >>>> Hannes >>>> >>>> Marcus Brunner wrote: >>>>> Pekka, >>>>> >>>>> Well put. I agree with you statement. >>>>> >>>>> Some parts of the ICE methodoldy are a bit an overkill in >>>> my opinion, so they could be discussed, whether they >> apply to HIP. >>>> The benefit naturally is that people seam to understand ICE. >>>>> >>>>> Actually, I would even propose that we should have a look >>>> at node-multi-homing, becasue it seams there are >> similarities like >>>> offered IP addresses/ports/.. to the responding peer. >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> Marcus >>>>> >>>>> --------------------------------------------------- >>>>> >>>>> Dr. Marcus Brunner >>>>> NEC Laboratories Europe >>>>> Network Division >>>>> >>>>> NEC Europe Limited | Registered Office: NEC House, 1 >>> Victoria Road, >>>>> London W3 6BL | Registered in England 2832014 >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] >>>>>> Sent: Tuesday, June 26, 2007 11:26 AM >>>>>> To: Tschofenig, Hannes >>>>>> Cc: HIP WG; Hannes Tschofenig; Marcus Brunner >>>>>> Subject: Re: AW: [Hipsec] Rebuilding ICE >>>>>> >>>>>> Hannes, >>>>>> >>>>>> >>>>>>> ICE is a methodology. We suggest to make extensive use of it. >>>>>>> The only "format" the ICE document suggests is the >> encoding of >>>>>>> candiates. >>>>>>> I have stated many times that one can think about a more >>>> optimized >>>>>>> encoding. That's OK. >>>>>>> >>>>>> I think we all understand the basic idea of ICE being a >>>>>> methodology. >>>>>> At least I am not objecting to using it, as a methodology. >>>>>> However, in addition to defining the SDP encoding for the >>>> candidates, >>>>>> it also defines how to use STUN and TURN, so there are, >>>> indirectly, >>>>>> more formats and network nodes (TURN and STUN servers) >>> built into >>>>>> ICE. >>>>>> >>>>>> Now, from my point of view an important architectural is >>>> not to make >>>>>> HIP dependent on TURN and STUN servers, nor the UDP >>> encapsulation >>>>>> formats used in STUN, nor any other such details. >>>>>> >>>>>> HIP has already the rendezvous servers defined, and a >>> well-defined >>>>>> mechanism for contacting hosts using the rendezvous >>>> servers. It also >>>>>> already has a mobility mechanism, and a rudimentary >>> mechanism for >>>>>> multi-homing. >>>>>> >>>>>> I may have misunderstood, but from my point of view, using ICE >>>>>> terminology, HIP already seems to have the necessary >>>> mechanisms form >>>>>> Encoding, Offering and Answering, and Completing (I'm >>>> drawing these >>>>>> terms from the ICE tutorial, my apology if the spec uses other >>>>>> terms). >>>>>> >>>>>> What HIP is primarily missing is Gathering and >>> Prioritising, which >>>>>> BTW are not a real protocol issues, and therefore most >>>> probably could >>>>>> be quite easily adopted from ICE, and Checking, where the >>>> past idea >>>>>> was to use the SHIM6 protoocol. >>>>>> For checking, the fact that native HIP uses both a >>>> separate protocol >>>>>> number of HIP control and ESP (or something else) for >>> data traffic >>>>>> necessitates the ICE checking methodology to be modified >>>> anyway. The >>>>>> same applies, as far as I can see, also to the NAT >>> traversal case, >>>>>> where HIP is using the IPsec encoding of UDP, not >> generic UDP. >>>>>> Hence, I don't think STUN applies there directly. >>>>>> >>>>>> Remember, when HIP is used the UDP and TCP messages >> are carried >>>>>> encoded somehow, typically in ESP wrappers, and therefore >>>> some of the >>>>>> problems specific to ICE/STUN (like port reuse) don't >>>> apply or apply >>>>>> in a different form. >>>>>> >>>>>> >>>>>>>> It's also fairly clear that there is reason to somewhat >>>> adapt ICE >>>>>>>> anyway; >>>>>>>> >>>>>>> That's fine. For example, I wrote that you could use >>> the RVS as a >>>>>>> reverse tunneling mechanism (in the spirit of TURN) to >>>> avoid using >>>>>>> TURN. In an upcoming draft I will explain why it still >>>>>>> >>>>>> makes a lot of >>>>>> >>>>>>> sense to use TURN but that's another story. >>>>>>> >>>>>> For TURN I don't understand why it would make any sense >>> to use it, >>>>>> but maybe I don't understand it, again. Anyway, I would >>>> consider it >>>>>> undesirable to make HIP dependent on TURN. >>>>>> >>>>>> If you would like to allow *optional* use of TURN, them >>>> I'm fine. As >>>>>> long as the base HIP mechanisms would work with only one >>>> new piece of >>>>>> infrastructure, the RVS servers. >>>>>> >>>>>> But I really would like to hear your detailed list of >>>> issues on the >>>>>> table. >>>>>> >>>>>> --Pekka >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Hipsec mailing list >>>>>> Hipsec@lists.ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/hipsec >>>>>> >>>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 16 02:41:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAKGn-00080Q-VK; Mon, 16 Jul 2007 02:41:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAKGn-00080L-4f for hipsec@ietf.org; Mon, 16 Jul 2007 02:41:21 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAKGV-0004PB-Rs for hipsec@ietf.org; Mon, 16 Jul 2007 02:41:21 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6G6eIsh000784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 15 Jul 2007 23:40:19 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6G6eITP029058; Sun, 15 Jul 2007 23:40:18 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6G6eEjL028987; Sun, 15 Jul 2007 23:40:18 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 23:40:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Hipsec] Rebuilding ICE Date: Sun, 15 Jul 2007 23:40:16 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040495CD@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <59254905-99D7-49AF-896F-A360CF4048C6@indranet.co.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Hipsec] Rebuilding ICE Thread-Index: AcfG73Bxa/uYwrbKT/++PV+NvciR1gAgSF7Q From: "Henderson, Thomas R" To: "Andrew McGregor" , "Marcus Brunner" X-OriginalArrivalTime: 16 Jul 2007 06:40:17.0368 (UTC) FILETIME=[2C1E8580:01C7C774] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: HIP WG , Hannes Tschofenig , "Tschofenig, Hannes" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org >=20 > So, I don't think Dan's attempts are undesired. I think this issue =20 > is important enough to do right rather than quickly, which makes ICE =20 > important. >=20 +1. Before we get too far down the specification path, it would be nice to have good running code, and ICE libraries are worth a serious look. It would also be nice to discuss detailed application-based HIP use cases for NAT traversal, especially in the peer-to-peer scenarios. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jul 16 06:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOEW-0001mJ-7V; Mon, 16 Jul 2007 06:55:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zZ5-0001jX-TY; Thu, 12 Jul 2007 10:22:43 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8zZ5-0002Y7-NA; Thu, 12 Jul 2007 10:22:43 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 704C6175CD; Thu, 12 Jul 2007 14:22:13 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8zYb-0006B0-1Z; Thu, 12 Jul 2007 10:22:13 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 12 Jul 2007 10:22:13 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Mon, 16 Jul 2007 06:55:15 -0400 Cc: hip mailing list , Internet Architecture Board , hip chair , RFC Editor Subject: [Hipsec] Document Action: 'Host Identity Protocol (HIP) Domain Name System (DNS) Extensions' to Experimental RFC X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org The IESG has approved the following document: - 'Host Identity Protocol (HIP) Domain Name System (DNS) Extensions ' as an Experimental RFC This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-09.txt Technical Summary This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP.) This RR allows 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 Names of its rendezvous servers (RVS.) Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No. Document Quality A number of vendors are already implementing this draft. The document was reviewed by the DNS Directorate, with comments addressed in the latest version. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 24 10:21:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLFx-0006pa-NY; Tue, 24 Jul 2007 10:20:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLFw-0006pR-Sm for hipsec@ietf.org; Tue, 24 Jul 2007 10:20:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDLFw-0003Cz-Dd for hipsec@ietf.org; Tue, 24 Jul 2007 10:20:56 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EA1F120B25 for ; Tue, 24 Jul 2007 16:20:54 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-0f-46a60ac6f95d Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DCD382046C for ; Tue, 24 Jul 2007 16:20:54 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 16:20:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 16:20:54 +0200 Received: from [131.160.126.192] (rvi2-126-192.lmf.ericsson.se [131.160.126.192]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 226C423F6 for ; Tue, 24 Jul 2007 17:20:53 +0300 (EEST) Message-ID: <46A60AC3.7080801@ericsson.com> Date: Tue, 24 Jul 2007 17:20:51 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 14:20:54.0660 (UTC) FILETIME=[D8889C40:01C7CDFD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Hipsec] P2PSIP proposals that use HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, FYI: a couple of proposals in the P2PSIP WG use HIP. You may be interested in attending the P2PSIP session to provide early comments on those proposals and to answer questions on HIP people may have. THURSDAY, July 26, 2007 0900-1130 Morning Session I Red Lacquer RAI p2psip Peer-to-Peer Session Initiation Protocol WG Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jul 26 12:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE66E-00010s-Rm; Thu, 26 Jul 2007 12:22:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE66D-00010K-DZ for hipsec@ietf.org; Thu, 26 Jul 2007 12:22:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IE66C-0001hU-Na for hipsec@ietf.org; Thu, 26 Jul 2007 12:22:01 -0400 Received: (qmail invoked by alias); 26 Jul 2007 16:21:59 -0000 Received: from dhcp-15f4.ietf69.org (EHLO [130.129.21.244]) [130.129.21.244] by mail.gmx.net (mp046) with SMTP; 26 Jul 2007 18:21:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/agQ1KcrnaxSEU8s4mg2UlA+v1tegB0FycapuWVr 0jB6Ne0rVwsC9j Message-ID: <46A8CA28.8010509@gmx.net> Date: Thu, 26 Jul 2007 18:22:00 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: 'HIP WG' , mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Hipsec] [Fwd: [BEHAVE] ICE tutorial in Chicago - PLEASE PAY IF YOU ATE LUNCH] X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org FYI -------- Original Message -------- Subject: [BEHAVE] ICE tutorial in Chicago - PLEASE PAY IF YOU ATE LUNCH Date: Thu, 26 Jul 2007 12:19:15 -0400 From: Jonathan Rosenberg To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Lunch during the tutorial was paid out of my pocket, and I was expecting to get re-imbursed by everyone that took a sandwich. Though all of the food was taken by the end of the tutorial, I am several hundred dollars short. Please, if you took lunch and did not give me $20, give it to me before you leave, and if you have not, contact me privately and we can arrange for paper mail. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 31 04:27:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFn4e-0004OZ-EK; Tue, 31 Jul 2007 04:27:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFn4d-0004OP-GG for hipsec@ietf.org; Tue, 31 Jul 2007 04:27:23 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFn4b-0005Da-6l for hipsec@ietf.org; Tue, 31 Jul 2007 04:27:23 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM100H1BBG6U7@szxga03-in.huawei.com> for hipsec@ietf.org; Tue, 31 Jul 2007 16:26:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM1005RHBG6CX@szxga03-in.huawei.com> for hipsec@ietf.org; Tue, 31 Jul 2007 16:26:30 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM100MVIBG0YY@szxml04-in.huawei.com> for hipsec@ietf.org; Tue, 31 Jul 2007 16:26:30 +0800 (CST) Date: Tue, 31 Jul 2007 16:26:24 +0800 From: JiangXingFeng To: 'HIP WG' Message-id: <000801c7d34c$7baa44c0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcfTTHs8giHRtp24QnS9v30ajLbxZA== X-Spam-Score: 1.2 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Hipsec] A question on the replay protection in HIP-base 08.draft X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi: In the section 4.1.4 of draft-ietf-hip-base-08, it says that " Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations'. The generation counter is designed to protect replay attack in HIP. The initiator should not accept R1 with earlier counter, but HIP uses IP protocol to transport message and lack of reliability, so that the R1 message MAY duplicate or out of order. From the above reason, the draft say that "initiator MAY accept puzzles from earlier generations". Is my understanding right? If it is not, what is the reason for that statement? Regards! -- Jiang XingFeng _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jul 31 04:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFnCH-0008Ry-Qx; Tue, 31 Jul 2007 04:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFnCG-0008Rr-Pg for hipsec@ietf.org; Tue, 31 Jul 2007 04:35:16 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFnCF-0005Ye-7h for hipsec@ietf.org; Tue, 31 Jul 2007 04:35:16 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CD355212D71; Tue, 31 Jul 2007 11:35:13 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 521BD212D60; Tue, 31 Jul 2007 11:35:13 +0300 (EEST) In-Reply-To: <000801c7d34c$7baa44c0$6905a40a@china.huawei.com> References: <000801c7d34c$7baa44c0$6905a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] A question on the replay protection in HIP-base 08.draft Date: Tue, 31 Jul 2007 11:35:10 +0300 To: JiangXingFeng X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org AFAICS, your understanding is basically correct. However, IIRC, another consideration we had in mind was very limited hosts. It may be desirable to implement HIP on hosts where it is too costly to store the generation counter for all/some hosts. Furthermore, if you don't store the generation counter, you harm only yourself: you will become vulnerable to certain replay attacks, but that doesn't harm the Internet in the large. So, in the spirit of doing no harm, it seemed safest to allow hosts to pick their own policy depending on their resources etc. --Pekka On 31 Jul 2007, at 11:26, JiangXingFeng wrote: > Hi: > In the section 4.1.4 of draft-ietf-hip-base-08, it says that " > Implementations MUST accept puzzles from the current generation and > MAY > accept puzzles from earlier generations'. > > The generation counter is designed to protect replay attack in HIP. > The > initiator should not accept R1 with earlier counter, but HIP uses IP > protocol to transport message and lack of reliability, so that the R1 > message MAY duplicate or out of order. From the above reason, the > draft say > that "initiator MAY accept puzzles from earlier generations". Is my > understanding right? If it is not, what is the reason for that > statement? > > Regards! > -- > Jiang XingFeng > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec