From samu.varjonen@hiit.fi Wed May 6 03:02:16 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08B33A69A0 for ; Wed, 6 May 2009 03:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRDwvf-fxIDo for ; Wed, 6 May 2009 03:02:15 -0700 (PDT) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 64B3E3A6825 for ; Wed, 6 May 2009 03:02:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id C9A4321AF61 for ; Wed, 6 May 2009 13:03:41 +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 15647-04; Wed, 6 May 2009 13:03:37 +0300 (EEST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 26F7821AF56 for ; Wed, 6 May 2009 13:03:37 +0300 (EEST) Received: from [128.214.113.196] (sutherland.hiit.fi [128.214.113.196]) by argo.otaverkko.fi (Postfix) with ESMTP id 1EBFA25ED06 for ; Wed, 6 May 2009 13:03:37 +0300 (EEST) Message-ID: <4A0160EB.4090204@hiit.fi> Date: Wed, 06 May 2009 13:05:31 +0300 From: Samu Varjonen User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at otaverkko.fi Subject: [Hipsec] Comments on draft-ietf-hip-nat-base-06 May 6 version X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 06 May 2009 10:02:16 -0000 Hi, Just read the new version of the NAT Traversal draft and found few points that need more clarifications. In Fig.1 I was wondering the need for TURN and STUN servers because in the Fig. they are not part of the signaling. Also in the text only the TURN server is referred to. STUN server seems to be only mentioned in the glossary. At least some titles, section 4.9 and Appendix C. uses "packets" and most of the text talks about "messages", when discussed of HIP control packets... In section 4.1 in paragraph "in step2, ..." in the end it says: "The support for HIP-over-UDP relaying is denoted by the Registration Type [RFC5203] value RELAY_UDP_HIP." This is a bit confusing 5203 defines the registration extensions but the RELAY_UDP_HIP is defined in this document but it is hidden into section 5.9. Maybe a clarification like "(see section 5.9)" should be added here. Section 4.2, in my opinion should be named "ICE candidate Gathering in BEX" because it covers only BEX and not mobility related gathering. I had a brief discussion with Miika on the topic and he said that mobility is out of scope of this document. But I did not find it clearly written anywhere. So maybe a clarification to the scope should be added. In section 4.3 "("critical" parameters are defined in[RFC5201])", why the quotation characters around critical. Does this point to RFC 5201 section 5.2.1 and field C and its meaning or does it mean that all the critical parameters are defined in 5201 or ... some pseudo critical stuff :) ... Table 4.3 introduces the NAT_TRAVERSAL_MODES and section 5.4 contains their numerical values. Just before the table it says they are defined in this document. We know where so why not mention the section number. Fig. 4 step 6 in my opinion the NAT_TM should be indented to the same column as LOCATOR in the same step. It would look nicer... Section 4.5 "in step2, the HIP..." if says RELAY_HMAC as described in [RFC5204]" RFC 5204 defines RVS_HMAC. Section 5.8 in this document defines the RELAY_HMAC to be similar than RVS_HMAC. In section 4.3 "Host MUST include ..." says "if they intend to use such servers ..." The need to use such servers may come after the BEX. This is probably also out of scope as stated earlier about mobility. In section 4.9 about the wait times. Its a local policy also on how long to wait for a timeout when waiting for R1s. consider the case "If I send UDP encapsulated I1 and plain I1 to the responder and receive UDP one first should I start to using it or how long should I wait for the plain one that might work". Now the policy contains only the interval in which the packets are sent out and the order but nothing on the inbound R1s and their timeouts. Should I actually wait for the both to arrive or timeout before I continue. Next paragraph "The I1 packet without UDP encapsulation may arrive directly at the Responder. When the recipient is the Responder, the procedures in [RFC5201] are followed for the rest of the base exchange." The part where it says "When the recipient is the Responder" seems to be useless. Recipient of the I1 packet is always Responder OR does this have something to do with the relay/RVS? Section 5.4 last paragraph, it should be added that "Conversely, a recipient MUST be prepared to handle received transport parameters that contain more than six Mode IDs by accepting the first six Mode IDs and dropping the rest." Just to make it uniform with HIP_TRANSFORM and ESP_TRANSFORM. Fig. 8 should the address be locator as defined in glossary and to make it uniform with LOCATOR in the next section? In section 6.1 the privacy reasons should be stated or referred to. For example RFC 4555 section 5.5 has discussion on the topic. Hopefully these are helpful :) BR, Samu Varjonen From ari.keranen@nomadiclab.com Wed May 6 05:20:09 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9053A6F2A for ; Wed, 6 May 2009 05:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrWE5t+4bfiA for ; Wed, 6 May 2009 05:20:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 116E43A6825 for ; Wed, 6 May 2009 05:16:39 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-85-4a017fd23322 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 09.CC.19078.2DF710A4; Wed, 6 May 2009 14:17:24 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 14:14:18 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 May 2009 14:14:17 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8C3102461; Wed, 6 May 2009 15:14:16 +0300 (EEST) Message-ID: <4A017F1B.6080908@nomadiclab.com> Date: Wed, 06 May 2009 15:14:19 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Samu Varjonen References: <4A0160EB.4090204@hiit.fi> In-Reply-To: <4A0160EB.4090204@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2009 12:14:17.0988 (UTC) FILETIME=[2DE57440:01C9CE44] X-Brightmail-Tracker: AAAAAA== Cc: hipsec@ietf.org Subject: Re: [Hipsec] Comments on draft-ietf-hip-nat-base-06 May 6 version X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 06 May 2009 12:20:09 -0000 Hi Samu, Thanks for the review and good comments! My comments inline. Samu Varjonen wrote: > In Fig.1 I was wondering the need for TURN and STUN servers because in > the Fig. they are not part of the signaling. Also in the text only the > TURN server is referred to. STUN server seems to be only mentioned in > the glossary. I think they are useful in the figure to show where they are in network topology (i.e., in the public Internet as the HIP relay server). Also it nicely shows how the architecture aligns with the ICE draft (there's a similar figure in the overview section of the ICE draft). There's no text about the usage of STUN server since it's assumed that one uses it as defined in the ICE draft. Section 4.2 (ICE Candidate Gathering) tells you to do so. > At least some titles, section 4.9 and Appendix C. uses "packets" and > most of the text talks about "messages", when discussed of HIP control > packets... Yes, they are used as synonyms, and both seem to be used quite frequently. Do you think they should all be "packets" (or "messages")? > In section 4.1 in paragraph "in step2, ..." in the end it says: > "The support for HIP-over-UDP relaying is denoted by the Registration > Type [RFC5203] value RELAY_UDP_HIP." This is a bit confusing 5203 > defines the registration extensions but the RELAY_UDP_HIP is defined in > this document but it is hidden into section 5.9. Maybe a clarification > like "(see section 5.9)" should be added here. The reference to 5203 was there to clarify what is meant by "Registration Type", but you're right that a pointer to sec 5.9 would be more helpful. Fixed that. > Section 4.2, in my opinion should be named "ICE candidate Gathering in > BEX" because it covers only BEX and not mobility related gathering. I > had a brief discussion with Miika on the topic and he said that mobility > is out of scope of this document. But I did not find it clearly written > anywhere. So maybe a clarification to the scope should be added. Actually I see no reason why you couldn't use those candidates for mobility too -- but, as you said, that is out of scope of the document. And the candidates of sec 4.2 are not really for (or usually gathered during) the BeX, so I think the current title is more appropriate. > In section 4.3 "("critical" parameters are defined in[RFC5201])", why > the quotation characters around critical. Does this point to RFC 5201 > section 5.2.1 and field C and its meaning or does it mean that all the > critical parameters are defined in 5201 or ... some pseudo critical > stuff :) ... That parenthetical part was added there because of a comment that the meaning of "critical" parameters might not be that obvious for everyone. And yes, we're referring to the C field -- not to any pseudo critical things of our own :) I changed the last sentence into: As the parameter is non-critical (as defined in Section 5.2.1 of [RFC5201]), it can be ignored by an end-host which means that the host does not support or is not willing to use these extensions. That's better? > Table 4.3 introduces the NAT_TRAVERSAL_MODES and section 5.4 contains > their numerical values. Just before the table it says they are defined > in this document. We know where so why not mention the section number. Good point. Fixed it. > Fig. 4 step 6 in my opinion the NAT_TM should be indented to the same > column as LOCATOR in the same step. It would look nicer... True. Fixed that too. > Section 4.5 "in step2, the HIP..." if says RELAY_HMAC as described in > [RFC5204]" RFC 5204 defines RVS_HMAC. Section 5.8 in this document > defines the RELAY_HMAC to be similar than RVS_HMAC. The whole sentence is: The relay protects the I1 packet with RELAY_HMAC as described in [RFC5204], except that the parameter type is different (see Section 5.8). Do you think that needs further clarification? I think the latter part of the sentence makes it clear how RVS_HMAC and RELAY_HMAC relate to each other. > In section 4.3 "Host MUST include ..." says "if they intend to use such > servers ..." The need to use such servers may come after the BEX. This > is probably also out of scope as stated earlier about mobility. Yes, that should be defined by the mobility draft. I added "immediately" to the sentence to be more clear that you can signal more relay servers after the BeX. The first sentence of that paragraph says now: Hosts MUST include the address of one or more HIP relay servers (including the one that is being used for the initial signaling) in the LOCATOR parameter in I2/R2 if they intend to use such servers for relaying HIP signaling immediately after the base exchange completes. > In section 4.9 about the wait times. Its a local policy also on how long > to wait for a timeout when waiting for R1s. consider the case "If I send > UDP encapsulated I1 and plain I1 to the responder and receive UDP one > first should I start to using it or how long should I wait for the plain > one that might work". Now the policy contains only the interval in which > the packets are sent out and the order but nothing on the inbound R1s > and their timeouts. Should I actually wait for the both to arrive or > timeout before I continue. I'd say it's totally up to you (i.e., local policy) and we shouldn't restrict that in the draft. > Next paragraph "The I1 packet without UDP encapsulation may arrive > directly at the Responder. When the recipient is the Responder, the > procedures in [RFC5201] are followed for the rest of the base exchange." > The part where it says "When the recipient is the Responder" seems to > be useless. Recipient of the I1 packet is always Responder OR does this > have something to do with the relay/RVS? Yes, it refers to the fact that you receive I1 *without* relaying (i.e., not via RVS or relay). I changed that into: The I1 packet without UDP encapsulation may arrive directly, without any relays, at the Responder. When this happens, the procedures in [RFC5201] are followed for the rest of the base exchange. Hopefully this version is more clear on that. > Section 5.4 last paragraph, it should be added that "Conversely, a > recipient MUST be prepared to handle received transport parameters that > contain more than six Mode IDs by accepting the first six Mode IDs and > dropping the rest." Just to make it uniform with HIP_TRANSFORM and > ESP_TRANSFORM. Why not. Here's the new text: The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE parameter. Conversely, a recipient MUST be prepared to handle received NAT traversal mode parameters that contain more than six Mode IDs by accepting the first six Mode IDs and dropping the rest. (BTW, I guess there's a typo in 5202: s/transport/transform/) > Fig. 8 should the address be locator as defined in glossary and to make > it uniform with LOCATOR in the next section? Actually the "Locator" from glossary is more generic than the one we're referring to here and also the LOCATOR parameter contains a lot more stuff (traffic type, lifetime, priority, etc) than what is needed here. I think the current format is good for the purpose. > In section 6.1 the privacy reasons should be stated or referred to. For > example RFC 4555 section 5.5 has discussion on the topic. OK, we'll look into this and see if there's room for improvement. > Hopefully these are helpful :) Yes they were -- thank you! Cheers, Ari From ari.keranen@nomadiclab.com Fri May 15 01:29:31 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBAD3A6C55 for ; Fri, 15 May 2009 01:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaId81x79h2H for ; Fri, 15 May 2009 01:29:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4BCC23A6AF3 for ; Fri, 15 May 2009 01:29:29 -0700 (PDT) X-AuditID: c1b4fb3e-b7b8fae000000a4a-29-4a0d2836b469 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 38.92.02634.6382D0A4; Fri, 15 May 2009 10:30:46 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 10:29:59 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 10:29:58 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BC3E92450 for ; Fri, 15 May 2009 11:29:58 +0300 (EEST) Message-ID: <4A0D2808.4090707@nomadiclab.com> Date: Fri, 15 May 2009 11:30:00 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2009 08:29:59.0058 (UTC) FILETIME=[55777720:01C9D537] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] NAT traversal interoperability test report X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 15 May 2009 08:29:31 -0000 Hi all, Here's a status update on the NAT traversal design team efforts. Now all major features of the NAT traversal base draft are implemented in both HIPL and hip4inter.net implementations. We run a set of interoperability tests between the two implementations and (after some bug squashing) they seem to work together nicely. We tested registering, Base Exchange via a HIP relay, ICE mode, plain UDP mode and keepalives using different topologies (hosts behind NATs and hosts in public network) and NAT types. You can find more detailed information about different tested scenarios from our test plan below. We also made some small modifications and clarifications to the draft, and the current up-to-date pre-version (containing also the improvements Samu suggested earlier) is available here: http://users.piuha.net/akeranen/drafts/draft-ietf-hip-nat-traversal-07-pre1.txt Cheers, Ari The test plan ============= 1st test case category: registration ------------------------------------ Registering to other implementation's relay and doing a BeX via it. Successful outcome: registering and BeX works without errors. 2nd test case category: BeX and ICE ----------------------------------- Legend: Pub: host with public IP, BeX directly Pub with relay: host not behind NAT but BeX via relay Priv: Host behind NAT, BeX via relay Test case topologies: Pub - Pub Pub - Pub with relay Priv - Pub Priv - Pub with relay Priv - Priv Both implementations taking each role in turn and working both as Initiator and Responder. All priv cases with both nasty (Linux) NAT and with a P2P friendly (endpoint independent mapping) NAT. Successful outcome: working SA with the best (as measured by ICE priority) usable path in use. ICE check pacing is negotiated correctly. No errors in the relay or at endpoints. Hosts can ping each other using the UDP encapsulated ESP. 3rd test case category: keepalives ---------------------------------- After hosts have setup a connection, they should keep it alive with keepalives. Successful outcome: keepalives are sent and processed correctly. 4th test case category: just UDP -------------------------------- A host with public IP address does not propose/select the ICE NAT traversal mode, but (just) the UDP-ENCAPSULATION mode. Successful outcome: no ICE is run, but SAs with just UDP encapsulation are created and used. From root@core3.amsl.com Fri May 22 01:45:01 2009 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DFF7A3A6DB5; Fri, 22 May 2009 01:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090522084501.DFF7A3A6DB5@core3.amsl.com> Date: Fri, 22 May 2009 01:45:01 -0700 (PDT) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-native-api-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 22 May 2009 08:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Basic Socket Interface Extensions for Host Identity Protocol (HIP) Author(s) : M. Komu, T. Henderson Filename : draft-ietf-hip-native-api-06.txt Pages : 17 Date : 2009-05-22 This document defines extensions to the current sockets API for Host Identity Protocol (HIP). The extensions focus on the use of public- key based identifiers discovered via DNS resolution, but define also interfaces for manual bindings between HITs and locators. With the extensions, the application can also support more relaxed security models where the communication can be non-HIP based, according to local policies. The extensions in document are experimental and provide basic tools for futher experimentation with policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-native-api-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-22013826.I-D@ietf.org> --NextPart-- From miika.komu@hiit.fi Fri May 22 04:03:58 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308AE3A6E78 for ; Fri, 22 May 2009 04:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIr24GIOBoVL for ; Fri, 22 May 2009 04:03:54 -0700 (PDT) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 09A2E3A6F05 for ; Fri, 22 May 2009 04:03:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 477A821AF4E for ; Fri, 22 May 2009 14:05:32 +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 20062-05; Fri, 22 May 2009 14:05:25 +0300 (EEST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id B1D0321AF3F for ; Fri, 22 May 2009 14:05:25 +0300 (EEST) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id A9E7425ED06 for ; Fri, 22 May 2009 14:05:25 +0300 (EEST) Message-ID: <4A1686F5.6020207@hiit.fi> Date: Fri, 22 May 2009 14:05:25 +0300 From: Miika Komu User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: hipsec@ietf.org References: <20090522084501.DFF7A3A6DB5@core3.amsl.com> In-Reply-To: <20090522084501.DFF7A3A6DB5@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at otaverkko.fi Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-native-api-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 11:03:58 -0000 Internet-Drafts@ietf.org wrote: Hi, the diff the the old version: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-hip-native-api-06.txt The new version includes mainly changes to the boilerplate and updated references. We added a compatibility statement with RFC5014 to section 4.2 based on feedback from Joakim Koskela (based on his SIP-over-HIP experiments): The system may have a HIP-aware interposing DNS agent as described in section 3.2 in [RFC5014]. In such a case, the DNS agent returns transparently LSIs or HITs in sockaddr_in and sockaddr_in6 structures when available. To disable this behaviour, the application sets AI_EXTFLAGS and AI_NO_ORCHID flags. Comments are welcome. Authors believe that this work has been iterated long enough to proceed towards IESG. > 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 : Basic Socket Interface Extensions for Host Identity Protocol (HIP) > Author(s) : M. Komu, T. Henderson > Filename : draft-ietf-hip-native-api-06.txt > Pages : 17 > Date : 2009-05-22 > > This document defines extensions to the current sockets API for Host > Identity Protocol (HIP). The extensions focus on the use of public- > key based identifiers discovered via DNS resolution, but define also > interfaces for manual bindings between HITs and locators. With the > extensions, the application can also support more relaxed security > models where the communication can be non-HIP based, according to > local policies. The extensions in document are experimental and > provide basic tools for futher experimentation with policies. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From samu.varjonen@hiit.fi Fri May 22 10:14:44 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201503A6CCF for ; Fri, 22 May 2009 10:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIZAUlz68LaX for ; Fri, 22 May 2009 10:14:42 -0700 (PDT) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 55F893A6C6B for ; Fri, 22 May 2009 10:14:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id EE77F21AF4E; Fri, 22 May 2009 20:16:00 +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 10390-07; Fri, 22 May 2009 20:15:56 +0300 (EEST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 50F9921AF45; Fri, 22 May 2009 20:15:56 +0300 (EEST) Received: from [10.0.0.145] (kone171183.ippnet.fi [62.197.171.183]) by argo.otaverkko.fi (Postfix) with ESMTP id 0473825ED06; Fri, 22 May 2009 20:15:55 +0300 (EEST) Message-ID: <4A16DDC9.8040000@hiit.fi> Date: Fri, 22 May 2009 20:15:53 +0300 From: Varjonen Samu User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Ari Keranen References: <4A0160EB.4090204@hiit.fi> <4A017F1B.6080908@nomadiclab.com> In-Reply-To: <4A017F1B.6080908@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at otaverkko.fi Cc: hipsec@ietf.org Subject: Re: [Hipsec] Comments on draft-ietf-hip-nat-base-06 May 6 version X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 22 May 2009 17:14:44 -0000 Ari Keranen wrote: > Hi Samu, > > Thanks for the review and good comments! My comments inline. > > Samu Varjonen wrote: >> In Fig.1 I was wondering the need for TURN and STUN servers because in >> the Fig. they are not part of the signaling. Also in the text only the >> TURN server is referred to. STUN server seems to be only mentioned in >> the glossary. > > I think they are useful in the figure to show where they are in network > topology (i.e., in the public Internet as the HIP relay server). Also it > nicely shows how the architecture aligns with the ICE draft (there's a > similar figure in the overview section of the ICE draft). > OK > There's no text about the usage of STUN server since it's assumed that > one uses it as defined in the ICE draft. Section 4.2 (ICE Candidate > Gathering) tells you to do so. > Thats 2 pages forward... but its mentioned. Maybe addition to the text like "as depicted in Fig. 1". Noticed one more thing in Section 4.2 " However, if no TURN server is used, and the host has only a single local IP address to use, the host MAY use the local address as the only host candidate and the address from the REG_FROM parameter discovered during the relay registration as a server reflexive candidate " Should this be "However, if no TURN or STUN server..."? >> At least some titles, section 4.9 and Appendix C. uses "packets" and >> most of the text talks about "messages", when discussed of HIP control >> packets... > > Yes, they are used as synonyms, and both seem to be used quite > frequently. Do you think they should all be "packets" (or "messages")? > I think they should be "packets" as they are in RFC 5201. >> In section 4.1 in paragraph "in step2, ..." in the end it says: >> "The support for HIP-over-UDP relaying is denoted by the Registration >> Type [RFC5203] value RELAY_UDP_HIP." This is a bit confusing 5203 >> defines the registration extensions but the RELAY_UDP_HIP is defined >> in this document but it is hidden into section 5.9. Maybe a >> clarification like "(see section 5.9)" should be added here. > > The reference to 5203 was there to clarify what is meant by > "Registration Type", but you're right that a pointer to sec 5.9 would be > more helpful. Fixed that. OK > >> Section 4.2, in my opinion should be named "ICE candidate Gathering in >> BEX" because it covers only BEX and not mobility related gathering. I >> had a brief discussion with Miika on the topic and he said that >> mobility is out of scope of this document. But I did not find it >> clearly written anywhere. So maybe a clarification to the scope should >> be added. > > Actually I see no reason why you couldn't use those candidates for > mobility too -- but, as you said, that is out of scope of the document. > And the candidates of sec 4.2 are not really for (or usually gathered > during) the BeX, so I think the current title is more appropriate. > OK >> In section 4.3 "("critical" parameters are defined in[RFC5201])", why >> the quotation characters around critical. Does this point to RFC 5201 >> section 5.2.1 and field C and its meaning or does it mean that all the >> critical parameters are defined in 5201 or ... some pseudo critical >> stuff :) ... > > That parenthetical part was added there because of a comment that the > meaning of "critical" parameters might not be that obvious for everyone. > And yes, we're referring to the C field -- not to any pseudo critical > things of our own :) > > I changed the last sentence into: > > As the parameter is non-critical (as defined in Section > 5.2.1 of [RFC5201]), it can be ignored by an end-host which means > that the host does not support or is not willing to use these > extensions. > > That's better? > At least I am happy with this >> Table 4.3 introduces the NAT_TRAVERSAL_MODES and section 5.4 contains >> their numerical values. Just before the table it says they are defined >> in this document. We know where so why not mention the section number. > > Good point. Fixed it. > >> Fig. 4 step 6 in my opinion the NAT_TM should be indented to the same >> column as LOCATOR in the same step. It would look nicer... > > True. Fixed that too. > OK >> Section 4.5 "in step2, the HIP..." if says RELAY_HMAC as described in >> [RFC5204]" RFC 5204 defines RVS_HMAC. Section 5.8 in this document >> defines the RELAY_HMAC to be similar than RVS_HMAC. > > The whole sentence is: > The relay protects the I1 packet with > RELAY_HMAC as described in [RFC5204], except that the parameter type > is different (see Section 5.8). > > Do you think that needs further clarification? I think the latter part > of the sentence makes it clear how RVS_HMAC and RELAY_HMAC relate to > each other. > Must have somehow missed the rest of the sentence... :) Its fine as it is. >> In section 4.3 "Host MUST include ..." says "if they intend to use >> such servers ..." The need to use such servers may come after the BEX. >> This is probably also out of scope as stated earlier about mobility. > > Yes, that should be defined by the mobility draft. I added "immediately" > to the sentence to be more clear that you can signal more relay servers > after the BeX. The first sentence of that paragraph says now: > > Hosts MUST include the address of one or more HIP relay servers > (including the one that is being used for the initial signaling) in > the LOCATOR parameter in I2/R2 if they intend to use such servers for > relaying HIP signaling immediately after the base exchange completes. > OK >> In section 4.9 about the wait times. Its a local policy also on how >> long to wait for a timeout when waiting for R1s. consider the case "If >> I send UDP encapsulated I1 and plain I1 to the responder and receive >> UDP one first should I start to using it or how long should I wait for >> the plain one that might work". Now the policy contains only the >> interval in which the packets are sent out and the order but nothing >> on the inbound R1s and their timeouts. Should I actually wait for the >> both to arrive or timeout before I continue. > > I'd say it's totally up to you (i.e., local policy) and we shouldn't > restrict that in the draft. > OK >> Next paragraph "The I1 packet without UDP encapsulation may arrive >> directly at the Responder. When the recipient is the Responder, the >> procedures in [RFC5201] are followed for the rest of the base >> exchange." The part where it says "When the recipient is the >> Responder" seems to be useless. Recipient of the I1 packet is always >> Responder OR does this have something to do with the relay/RVS? > > Yes, it refers to the fact that you receive I1 *without* relaying (i.e., > not via RVS or relay). I changed that into: > > The I1 packet without UDP encapsulation may arrive directly, without > any relays, at the Responder. When this happens, the procedures in > [RFC5201] are followed for the rest of the base exchange. > > Hopefully this version is more clear on that. > Yes its better >> Section 5.4 last paragraph, it should be added that "Conversely, a >> recipient MUST be prepared to handle received transport parameters >> that contain more than six Mode IDs by accepting the first six Mode >> IDs and dropping the rest." Just to make it uniform with HIP_TRANSFORM >> and ESP_TRANSFORM. > > Why not. Here's the new text: > > The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that > there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE > parameter. Conversely, a recipient MUST be prepared to handle > received NAT traversal mode parameters that contain more than six > Mode IDs by accepting the first six Mode IDs and dropping the rest. > > (BTW, I guess there's a typo in 5202: s/transport/transform/) > OK >> Fig. 8 should the address be locator as defined in glossary and to >> make it uniform with LOCATOR in the next section? > > Actually the "Locator" from glossary is more generic than the one we're > referring to here and also the LOCATOR parameter contains a lot more > stuff (traffic type, lifetime, priority, etc) than what is needed here. > I think the current format is good for the purpose. > Then I think it should be clarified in Section 5.6 that how it differs from the more generic address ...? >> In section 6.1 the privacy reasons should be stated or referred to. >> For example RFC 4555 section 5.5 has discussion on the topic. > > OK, we'll look into this and see if there's room for improvement. > OK >> Hopefully these are helpful :) > > Yes they were -- thank you! > > > Cheers, > Ari BR, Samu From Pascal.Urien@enst.fr Sun May 24 10:13:14 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19623A69ED for ; Sun, 24 May 2009 10:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUxSgWY3y-6c for ; Sun, 24 May 2009 10:13:13 -0700 (PDT) Received: from smtp2.enst.fr (revol2.enst.fr [IPv6:2001:660:330f:2::e]) by core3.amsl.com (Postfix) with ESMTP id A539B3A67AE for ; Sun, 24 May 2009 10:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 60BA4B89F3 for ; Sun, 24 May 2009 19:14:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from PC-de-pascal.enst.fr (pptp21-108.enst.fr [137.194.21.108]) by smtp2.enst.fr (Postfix) with ESMTP id E9A3AB8375 for ; Sun, 24 May 2009 19:14:51 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 May 2009 19:14:39 +0200 To: hipsec@ietf.org From: Pascal Urien Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090524171451.E9A3AB8375@smtp2.enst.fr> Subject: [Hipsec] HIP-TAGS resources page X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Sun, 24 May 2009 17:13:14 -0000 Hi All, I have created a resource page for the HIP-TAGS item http://perso.telecom-paristech.fr/~urien/hiptag/index.html A java code is now available for proofs of concepts purposes The T2TIT research project will release an experimental platform, before the end of 2009 Comments and discussion about HIP fot the Internet Of Things are welcome ! Best Regards Pascal From ppatil@cc.hut.fi Mon May 25 00:27:29 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906623A6842 for ; Mon, 25 May 2009 00:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehxvQDCcQTqr for ; Mon, 25 May 2009 00:27:22 -0700 (PDT) Received: from mx01.hut.fi (mx01.hut.fi [130.233.228.108]) by core3.amsl.com (Postfix) with ESMTP id 957F93A6A06 for ; Mon, 25 May 2009 00:27:22 -0700 (PDT) Received: from mx01.hut.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 62D8BE80A0 for ; Mon, 25 May 2009 10:29:02 +0300 (EEST) Received: from materazzi.hut.fi (materazzi.hut.fi [130.233.229.166]) by mx01.hut.fi (Postfix) with ESMTP id 3CC03E809F for ; Mon, 25 May 2009 10:29:02 +0300 (EEST) Received: by materazzi.hut.fi (Postfix, from userid 518) id 0EE6E8077; Mon, 25 May 2009 10:29:02 +0300 (EEST) Received: from tko-add-222.cs.hut.fi (tko-add-222.cs.hut.fi [130.233.194.222]) by webmail1.tkk.fi (Horde MIME library) with HTTP; Mon, 25 May 2009 10:29:02 +0300 Message-ID: <20090525102902.90av0asbaoow88gg@webmail1.tkk.fi> Date: Mon, 25 May 2009 10:29:02 +0300 From: Prabhu Patil To: hipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Originating-IP: 130.233.194.222 X-Authenticated-User: ppatil X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.5.25.71659 X-Spam-Probability: 8% X-PMX-Spam: Gauge=IIIIIII, Probability=8%, Report='BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_500_599 0, BODY_SIZE_7000_LESS 0, TO_NO_NAME 0, WEBMAIL_SOURCE 0, WEBMAIL_USER_AGENT 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __CD 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __DATE_TZ_RU 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0' Subject: [Hipsec] Fwd: [hipl-users] HMAC Field in HIP DATA Packets X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 25 May 2009 07:27:29 -0000 Hi, I am in the process of implementing HIP DATA packets draft. Facing problem in implementing HMAC field in DATA Packets (HICCUPS Draft) As I understand from hip draft 5201 that, HMAC key is derived from the key matrix (Section 6.5 ) i.e HIP-gl/HIP-lg integrity (HMAC). But these are available only when there is the Diffie-Hellman session key (Kij). Do you have any idea how to get HMAC key without base exchange? Thanks Prabhu Patil ----- End forwarded message ----- From ari.keranen@nomadiclab.com Wed May 27 08:44:12 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21383A689C for ; Wed, 27 May 2009 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rc7L3cjzieN for ; Wed, 27 May 2009 08:44:11 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7115F3A67FD for ; Wed, 27 May 2009 08:44:11 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-e6-4a1d5fdf5472 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 61.7C.30868.FDF5D1A4; Wed, 27 May 2009 17:44:31 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 17:44:31 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 17:44:30 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D05FD24D6; Wed, 27 May 2009 18:44:30 +0300 (EEST) Message-ID: <4A1D5FDD.9010302@nomadiclab.com> Date: Wed, 27 May 2009 18:44:29 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Varjonen Samu References: <4A0160EB.4090204@hiit.fi> <4A017F1B.6080908@nomadiclab.com> <4A16DDC9.8040000@hiit.fi> In-Reply-To: <4A16DDC9.8040000@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2009 15:44:30.0824 (UTC) FILETIME=[06683E80:01C9DEE2] X-Brightmail-Tracker: AAAAAA== Cc: hipsec@ietf.org Subject: Re: [Hipsec] Comments on draft-ietf-hip-nat-base-06 May 6 version X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 27 May 2009 15:44:12 -0000 Hi, Varjonen Samu wrote: > Ari Keranen wrote: >> Samu Varjonen wrote: [removed all the parts that were already OK] >>> In Fig.1 I was wondering the need for TURN and STUN servers because >>> in the Fig. they are not part of the signaling. Also in the text only >>> the TURN server is referred to. STUN server seems to be only >>> mentioned in the glossary. >> >> I think they are useful in the figure to show where they are in >> network topology (i.e., in the public Internet as the HIP relay >> server). Also it nicely shows how the architecture aligns with the ICE >> draft (there's a similar figure in the overview section of the ICE >> draft). >> > > OK > >> There's no text about the usage of STUN server since it's assumed that >> one uses it as defined in the ICE draft. Section 4.2 (ICE Candidate >> Gathering) tells you to do so. >> > > Thats 2 pages forward... but its mentioned. Maybe addition to the text > like "as depicted in Fig. 1". You have point. I added a comment about the role of TURN and STUN servers to the introduction part (where the Figure 1 is). Now the second paragraph says: The first steps are for both the Initiator and Responder to register with a relay server (need not be the same one) and gather a set of address candidates. The hosts may use TURN and STUN servers for gathering the candidates. [...] > Noticed one more thing in Section 4.2 > " > However, if no TURN server > is used, and the host has only a single local IP address to use, the > host MAY use the local address as the only host candidate and the > address from the REG_FROM parameter discovered during the relay > registration as a server reflexive candidate > " > > Should this be "However, if no TURN or STUN server..."? Actually no. If you have only a single local IP address, you don't need STUN servers at all since you already get the server reflexive address from the HIP relay server. Of course there's a chance that due to some strange routing arrangements you may get different server reflexive addresses from different servers, but I'd say that's out of scope for this document. >>> At least some titles, section 4.9 and Appendix C. uses "packets" and >>> most of the text talks about "messages", when discussed of HIP >>> control packets... >> >> Yes, they are used as synonyms, and both seem to be used quite >> frequently. Do you think they should all be "packets" (or "messages")? >> > > I think they should be "packets" as they are in RFC 5201. Actually RFC 5201 uses both, but you're right that "packets" are used much more often. I changed all the HIP "messages" to "packets". >>> Fig. 8 should the address be locator as defined in glossary and to >>> make it uniform with LOCATOR in the next section? >> >> Actually the "Locator" from glossary is more generic than the one >> we're referring to here and also the LOCATOR parameter contains a lot >> more stuff (traffic type, lifetime, priority, etc) than what is needed >> here. I think the current format is good for the purpose. >> > > Then I think it should be clarified in Section 5.6 that how it differs > from the more generic address ...? I think the explanation of "Address" in Section 5.6, Figure 8 ('an IPv6 address or an IPv4 address in "IPv4-Mapped IPv6 address" format') does this already. I.e., it is just "plain IP address". Or can you propose some better way to clarify this? Cheers, Ari From samu.varjonen@hiit.fi Thu May 28 01:08:24 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB493A6AC2 for ; Thu, 28 May 2009 01:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04tu4k99GR6E for ; Thu, 28 May 2009 01:08:23 -0700 (PDT) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 5EC393A6A2E for ; Thu, 28 May 2009 01:08:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 8CE8321AF44; Thu, 28 May 2009 11:10:04 +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 16268-10; Thu, 28 May 2009 11:09:57 +0300 (EEST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id D545821AF4B; Thu, 28 May 2009 11:09:57 +0300 (EEST) Received: from [128.214.114.26] (midian.pc.hiit.fi [128.214.114.26]) by argo.otaverkko.fi (Postfix) with ESMTP id 9874825ED06; Thu, 28 May 2009 11:09:57 +0300 (EEST) Message-ID: <4A1E46D4.5010205@hiit.fi> Date: Thu, 28 May 2009 11:09:56 +0300 From: Varjonen Samu User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Ari Keranen References: <4A0160EB.4090204@hiit.fi> <4A017F1B.6080908@nomadiclab.com> <4A16DDC9.8040000@hiit.fi> <4A1D5FDD.9010302@nomadiclab.com> In-Reply-To: <4A1D5FDD.9010302@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at otaverkko.fi Cc: hipsec@ietf.org Subject: Re: [Hipsec] Comments on draft-ietf-hip-nat-base-06 May 6 version X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 28 May 2009 08:08:24 -0000 Ari Keranen wrote: > Hi, > > Varjonen Samu wrote: >> Ari Keranen wrote: >>> Samu Varjonen wrote: > > [removed all the parts that were already OK] > >>>> In Fig.1 I was wondering the need for TURN and STUN servers because >>>> in the Fig. they are not part of the signaling. Also in the text >>>> only the TURN server is referred to. STUN server seems to be only >>>> mentioned in the glossary. >>> >>> I think they are useful in the figure to show where they are in >>> network topology (i.e., in the public Internet as the HIP relay >>> server). Also it nicely shows how the architecture aligns with the >>> ICE draft (there's a similar figure in the overview section of the >>> ICE draft). >>> >> >> OK >> >>> There's no text about the usage of STUN server since it's assumed >>> that one uses it as defined in the ICE draft. Section 4.2 (ICE >>> Candidate Gathering) tells you to do so. >>> >> >> Thats 2 pages forward... but its mentioned. Maybe addition to the text >> like "as depicted in Fig. 1". > > You have point. I added a comment about the role of TURN and STUN > servers to the introduction part (where the Figure 1 is). Now the second > paragraph says: > > The first steps are for both the Initiator and Responder to register > with a relay server (need not be the same one) and gather a set of > address candidates. The hosts may use TURN and STUN servers for > gathering the candidates. [...] > OK >> Noticed one more thing in Section 4.2 >> " >> However, if no TURN server >> is used, and the host has only a single local IP address to use, the >> host MAY use the local address as the only host candidate and the >> address from the REG_FROM parameter discovered during the relay >> registration as a server reflexive candidate >> " >> >> Should this be "However, if no TURN or STUN server..."? > > Actually no. If you have only a single local IP address, you don't need > STUN servers at all since you already get the server reflexive address > from the HIP relay server. > > Of course there's a chance that due to some strange routing arrangements > you may get different server reflexive addresses from different servers, > but I'd say that's out of scope for this document. > OK >>>> At least some titles, section 4.9 and Appendix C. uses "packets" and >>>> most of the text talks about "messages", when discussed of HIP >>>> control packets... >>> >>> Yes, they are used as synonyms, and both seem to be used quite >>> frequently. Do you think they should all be "packets" (or "messages")? >>> >> >> I think they should be "packets" as they are in RFC 5201. > > Actually RFC 5201 uses both, but you're right that "packets" are used > much more often. I changed all the HIP "messages" to "packets". > OK >>>> Fig. 8 should the address be locator as defined in glossary and to >>>> make it uniform with LOCATOR in the next section? >>> >>> Actually the "Locator" from glossary is more generic than the one >>> we're referring to here and also the LOCATOR parameter contains a lot >>> more stuff (traffic type, lifetime, priority, etc) than what is >>> needed here. I think the current format is good for the purpose. >>> >> >> Then I think it should be clarified in Section 5.6 that how it differs >> from the more generic address ...? > > I think the explanation of "Address" in Section 5.6, Figure 8 ('an IPv6 > address or an IPv4 address in "IPv4-Mapped IPv6 address" format') does > this already. I.e., it is just "plain IP address". Or can you propose > some better way to clarify this? OK, but if I follow this correctly we can say that the "locator" in the LOCATOR parameter should actually be "address" because the locator is address + the extra information like priority etc. This has been fun. Waiting for the next revision, Samu From ari.keranen@nomadiclab.com Fri May 29 00:48:21 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164E13A6E63 for ; Fri, 29 May 2009 00:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqCpycsIcoEd for ; Fri, 29 May 2009 00:48:20 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2F97E3A68AC for ; Fri, 29 May 2009 00:48:17 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-3f-4a1f93a72832 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id CE.E2.30868.7A39F1A4; Fri, 29 May 2009 09:49:59 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 09:49:59 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 09:49:59 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DDB11245E; Fri, 29 May 2009 10:49:58 +0300 (EEST) Message-ID: <4A1F93A6.9040904@nomadiclab.com> Date: Fri, 29 May 2009 10:49:58 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Varjonen Samu References: <4A0160EB.4090204@hiit.fi> <4A017F1B.6080908@nomadiclab.com> <4A16DDC9.8040000@hiit.fi> <4A1D5FDD.9010302@nomadiclab.com> <4A1E46D4.5010205@hiit.fi> In-Reply-To: <4A1E46D4.5010205@hiit.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2009 07:49:59.0287 (UTC) FILETIME=[10DFF870:01C9E032] X-Brightmail-Tracker: AAAAAA== Cc: hipsec@ietf.org Subject: Re: [Hipsec] Comments on draft-ietf-hip-nat-base-06 May 6 version X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 29 May 2009 07:48:21 -0000 Hi, Varjonen Samu wrote: > Ari Keranen wrote: >> Varjonen Samu wrote: >>> Ari Keranen wrote: >>>> Samu Varjonen wrote: >>>>> Fig. 8 should the address be locator as defined in glossary and to >>>>> make it uniform with LOCATOR in the next section? >>>> >>>> Actually the "Locator" from glossary is more generic than the one >>>> we're referring to here and also the LOCATOR parameter contains a >>>> lot more stuff (traffic type, lifetime, priority, etc) than what is >>>> needed here. I think the current format is good for the purpose. >>>> >>> >>> Then I think it should be clarified in Section 5.6 that how it >>> differs from the more generic address ...? >> >> I think the explanation of "Address" in Section 5.6, Figure 8 ('an >> IPv6 address or an IPv4 address in "IPv4-Mapped IPv6 address" format') >> does this already. I.e., it is just "plain IP address". Or can you >> propose some better way to clarify this? > > OK, but if I follow this correctly we can say that the "locator" in the > LOCATOR parameter should actually be "address" because the locator is > address + the extra information like priority etc. You're right. So, actually the problem was not in Figure 8, but rather in Figure 9 (depicting the LOCATOR parameter) and Table 2 (explaining the Figure 9). I'll change the "locator" there into "address". Good catch! > This has been fun. I'm glad you've enjoyed reviewing the draft :) > Waiting for the next revision, > Samu We'll do some final brushing for the draft and publish the next version soon. Cheers, Ari From gonzalo.camarillo@ericsson.com Fri May 29 07:09:57 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA833A6C1E for ; Fri, 29 May 2009 07:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.492 X-Spam-Level: X-Spam-Status: No, score=-5.492 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIAlaafIRf5x for ; Fri, 29 May 2009 07:09:57 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DCA7D3A6B24 for ; Fri, 29 May 2009 07:09:55 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-af-4a1fe2410e39 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 23.8C.30868.142EF1A4; Fri, 29 May 2009 15:25:21 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 15:25:21 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 15:25:21 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EBFF1245E; Fri, 29 May 2009 16:25:20 +0300 (EEST) Message-ID: <4A1FE240.20504@ericsson.com> Date: Fri, 29 May 2009 16:25:20 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2009 13:25:21.0226 (UTC) FILETIME=[EA7C32A0:01C9E060] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Agenda requests X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 29 May 2009 14:09:57 -0000 Folks, the HIP WG will be meeting in Stockholm. If you would like to present something there, please send your agenda request to the chairs. Thanks, Gonzalo HIP co-chair From gonzalo.camarillo@ericsson.com Fri May 29 09:38:21 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236C13A68D0 for ; Fri, 29 May 2009 09:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPANys--w6zG for ; Fri, 29 May 2009 09:38:20 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 314CB3A687F for ; Fri, 29 May 2009 09:38:19 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-f1-4a1fd977b667 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2C.B8.30868.779DF1A4; Fri, 29 May 2009 14:47:51 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 14:47:51 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 14:47:50 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A633127BA; Fri, 29 May 2009 15:47:50 +0300 (EEST) Message-ID: <4A1FD976.3090409@ericsson.com> Date: Fri, 29 May 2009 15:47:50 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2009 12:47:51.0078 (UTC) FILETIME=[AD4ADC60:01C9E05B] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Removing our supplemental page X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Fri, 29 May 2009 16:38:21 -0000 Folks, FYI: we have removed our supplemental web page. We were not really using it any longer and keeping such a web page up to date did not make much sense. Cheers, Gonzalo HIP co-chair