From hipsec-bounces@ietf.org Fri Feb 1 02:34:27 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6804A3A6951; Fri, 1 Feb 2008 02:34:27 -0800 (PST) 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 core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3Gt2iflBOd8; Fri, 1 Feb 2008 02:34:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70443A694E; Fri, 1 Feb 2008 02:34:25 -0800 (PST) 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 DE4093A694D for ; Fri, 1 Feb 2008 02:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-RICuh7OHJW for ; Fri, 1 Feb 2008 02:34:23 -0800 (PST) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by core3.amsl.com (Postfix) with ESMTP id 1E5593A68F2 for ; Fri, 1 Feb 2008 02:34:19 -0800 (PST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7D2062C8D; Fri, 1 Feb 2008 12:35:52 +0200 (EET) X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id E4FD72C8D; Fri, 1 Feb 2008 12:35:43 +0200 (EET) Date: Fri, 1 Feb 2008 12:35:43 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049BC7@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <474DDBFA.1050509@ericsson.com><77F357662F8BFA4CA7074B0410171B6D04049A98@XCH-NW-5V1.nw.nos.boeing.com><77F357662F8BFA4CA7074B0410171B6D04049B89@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D04049BC7@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-api-03.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org On Thu, 31 Jan 2008, Henderson, Thomas R wrote: Hi Tom, > Miika, > I owe you some more specific text proposals, but I thought I'd respond > to some points inline below. thanks for your comments and I am looking forward for your contributions. Gonzalo, I hope it is ok to bend the deadline? >>>>> In section 4.2 (resolver extensions), the description >> implies that a >>>>> resolver will have to do two queries (nodename to HITs and >>>> nodename to >>>>> IP addresses), and concatenate the results in the rres >> field, before >>>>> returning from getaddrinfo(). Shouldn't the application >>>> instead issue >>>>> two getaddrinfo's for each of the different queries? >>>> >>>> Why complicate things unnecessarily for the developer? The >> current API >>>> is designed so that it can be used in existing apps with minimal >>>> changes (i.e. by adding some flags). >>> >>> This depends perhaps on the perception of what complicates >> things for >>> the developer. I do not agree that trying to make the >> native HIP API >>> deviate as little as possible from the address-based API >> should be the >>> primary goal here. Rather, the main goal should be to have >> an API with >>> clear semantics, which is somewhat in conflict with >> aligning with the >>> address-based API because functions and data structures get >> overloaded. >> >> Have you thought about what the application would look like >> when it is >> going to do two resolver calls and can initiate both HIP and non-HIP >> connections? > > I thought we were going down that path already with the DNS draft (see > section 3.2). There is no such section. If you mean section 4.2, could you be more specific because this section contains quite much information. I don't have any objection if the application wants to resolve the HITs and address separately when it is handling everything manually. However, don't like the idea that application is enforced to do it always. If we do agree that both ways should be possible, please contribute some text to section 4.5 (manual handling of locators). My justification for making double resolving optional is that there is plenty of c-based software out there which could use HIP explictly by just chaning just few lines of code. I think enforcing double resolving would result in an anomaly to the sockets API that would frighten developers away from HIP. > I think that there may be cases where the application gathers the > information it wants through DNS or whatever means directly, and then > uses a low-level API, and cases where the application just wants to use > HITs alone and not have to worry about RVS and addresses. IMO, we should > strive for an API that allows either case, but to me, it is important to > get the first one done first. I assume you mean refer to the low-level API with "first one" here. I think DNS interaction should be a part of the low-level API. I view a high-level API something that is wrapped around the sockets API. It inputs an hostname and service string and outputs an object that can be receiving and sending data. To go even further, we the high-level API could input a search string for data and some ways to publish or subscribe the data. Such a high-level API is clearly out of scope of this work. Well, the low-level API consists of sockaddr_hip structures, new PF/AF families, existing socket calls and some new socket options. I believe they are already specified in the two drafts, but they are not organized under one subsection "low-level API" as you seem to want. Could you explain why such editorial change would make the draft more readable and, more interestingly, to whom? I see the current version targeted to the people who are actually going to implement the extensions to libc or other similar libraries. It is not exactly targeted for developers, but I believe that should be handled in the man (or similar) pages. I agree that the RVS part needs some further clarifications in section 4.5. More specifically, determining whether address belongs to a RVS or end-host should be explained in the native API draft. We have agreed with the authors of multihoming API draft that it is going to contain only the parts that are common between HIP and SHIM6. >>> The sockets API is already roundly criticized for its semantic >>> ambiguity; I think we should not make things worse if we >> can help it. >> >> Can you be more specific what parts of the sockets API have received >> criticism? AFAIK, the main part I've heard of in the apps area is the >> resolver part which has not met its promises in the real world. >> Also, it was not originally designed with multihoming in mind. > > Plus, the mixture of stream and datagram semantics. Excuse my ignorance but may I ask in which forum has this been critized? >> I believe you are suggesting here effectively an additional deployment >> obstacle. Even my futile attempt to introduce an additional abstraction >> ("end-point descriptor") to the HIP sockets API extensions (in draft 02 >> version) was shot down by the research, apps area and hip community. I >> have some serious doubts about the future of such an approach. >> >> I think we need to follow the narrow path of sockets API to its end for >> two reasons. First, to facilititate deployment of HIP-enabled >> applications by introducing minimal changes to the current >> applications. Second, to get experimental-driven feedback on where to >> improve when designing better APIs for the future. Either from the >> scratch, or as python/java/c-library/etc middleware on top of the >> sockets API (apps-area folks think that the latter will be the >> reality). This is getting a little-bit off topic... > > Well, if we announce "this is the native HIP API" and then change it a > few years later, apps developers will not be happy. That is why I'd > prefer to have the raw low-level API done first (which shouldn't have to > change in the future) and then start to engineer abstractions and > performance improvements-- those should be more experimental. Well, I think the bits for the raw-level API are already in the two drafts, particularly if you think there is something missing. Please be more explicit. >>> Here are two main issues I have with the current draft: >>> >>> - it presumes that DNS is the entry point for applications >> to use HIP. >>> Personally, I suspect that HIP-based applications will more >> often than >>> not use something else like a DHT, or other things we >> haven't thought of >>> yet. But the main issue is that this draft delegates >> handling of the >>> HIT/IP address bindings to an intermediate layer; i.e., it >> is kind of a >>> higher-level API. This might be a nice eventual goal in >> some cases but >>> I think that introducing the abstraction immediately (that >> applications >>> never need to handle locators) might be taking too big of an initial >>> step. >> >> I disagree about the DNS presumptions partially. There is one >> section, >> 4.5. Manual Handling of Locators, dedicated completely to non-lookup >> environments. I agree that the draft has more focus on DNS, >> but I believe >> think this is acceptable since most of the current >> applications rely on >> DNS. > > As I commented previously, it requires reading/using the shim6 draft to > really implement the section 4.5, and here it was ambiguous (at least to > me) how these options might apply to HIP. > > For instance: > > "5.6. SHIM_LOC_PEER_PREF > > The SHIM_LOC_PEER_PREF option can be used to read or set preferred > locator on peer side within a given context. Hence this option is > effective only when there is a shim context associated with the > socket." > > Does that apply to HIP? When is there a HIP "shim context" present? I > don't think the use of these options is as clear as it could be, > especially to people who do not know HIP and shim6. Yes it does. Good point, I think "HIP context" should be clarified in the multihoming draft. The multihoming draft should also mention more clearly in the intro that everything in the draft should apply to both SHIM6 and HIP. Tom, we'd appreciate more detailed comments and corrections to the multihoming draft if you have some more. >> I think this was a reasonable call for four reasons. First, the >> locators in sockaddr_hip structure can get depracated quite soon in >> mobile environments and it is easier for the application (developer) to >> misuse them. Second, sockaddr structures have size limits and can hold >> only a number of locators. Third, when the resolver resolves multiple >> HITs, it does not make sense to have the locators spread redundantly in >> multiple socket address structures. Fourth, I think the current version >> of the draft is more compatible with the multihoming draft this way. >> >> This design choice had a consequence on the opportunistic >> mode. Namely, I >> had to introduce the HIP_ADDR_ANY concept because there is no locator >> structure in sockaddr_hip. I don't like it either, but that is rough >> consensus ;) > > The option is to always allow for a (possibly wildcarded) locator > structure. How? >>> The current draft covers a lot of ground; not only is the basic API >>> (partially) covered but also resolver interactions and now (in the >>> latest version) source HIT selection policy. My preference >> would be to >>> focus first on the basic raw API and then move to the other >> points. I >>> would like to suggest the following steps. >> >> I was working on the assumption that you were concurring with >> Andrew on >> the source HIT selection policy because you repeated his >> request on your >> comments: >> >> http://www1.ietf.org/mail-archive/web/hipsec/current/msg02323.html >> >> Hence, I included the source HIT selection policy to the API. > > Yes, I am just mentioning that you have recently added the equivalent of > RFC 3484 and 5014, which makes it cover a lot of ground now. > > I have not carefully thought about the choices in Table 3, although it > occurred to me that key (HI) length is not a criteria in the selection > (should it be?). Good point, but I don't know how to specify this as a list of rules with static prioritity values because the HI lenght is variable. Perhaps we could say that if there is a tie with two keys with same properties, the one with more bits has higher preference? >> Agree that this should be added to the draft and should result in >> EDESTADDRREQ error. > > Yes, this is the point that I am trying to make-- we should try to > clarify these types of things now. Looking forward for a more detailed feedback or contribution. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@ietf.org http://www.ietf.org/mailman/listinfo/hipsec From mailman-bounces@core3.amsl.com Fri Feb 1 06:14:57 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B89F2A2B3C for ; Fri, 1 Feb 2008 06:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH5r1wlyLNXZ for ; Fri, 1 Feb 2008 06:06:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C2D295FE3 for ; Fri, 1 Feb 2008 05:43:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: hipsec-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:58 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/hipsec/hipsec-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:18:32 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E8328C816 for ; Fri, 1 Feb 2008 06:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMu57JJru4VU for ; Fri, 1 Feb 2008 06:11:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9071D2932B9 for ; Fri, 1 Feb 2008 05:43:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: hipsec-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:58 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/hipsec/hipsec-archive%40megatron.ietf.org From hipsec-bounces@ietf.org Sat Feb 9 05:03:19 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCCD28C969; Sat, 9 Feb 2008 05:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTq4ZMal39aL; Sat, 9 Feb 2008 05:03:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056823A79CC; Sat, 9 Feb 2008 05:03:19 -0800 (PST) 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 AFE3A3A79CC for ; Sat, 9 Feb 2008 05:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQlGQsu0ARLX for ; Sat, 9 Feb 2008 05:03:17 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E01F53A76BA for ; Sat, 9 Feb 2008 05:03:16 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C065F206D1; Sat, 9 Feb 2008 14:04:41 +0100 (CET) X-AuditID: c1b4fb3c-ab2eebb0000007e0-94-47ada4e9f75b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9D675204D9; Sat, 9 Feb 2008 14:04:41 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Feb 2008 14:04:41 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Feb 2008 14:04:40 +0100 Received: from [131.160.126.2] (rvi2-126-2.lmf.ericsson.se [131.160.126.2]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D9F832460; Sat, 9 Feb 2008 15:04:40 +0200 (EET) Message-ID: <47ADA4E8.6010903@ericsson.com> Date: Sat, 09 Feb 2008 15:04:40 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Miika Komu References: <474DDBFA.1050509@ericsson.com><77F357662F8BFA4CA7074B0410171B6D04049A98@XCH-NW-5V1.nw.nos.boeing.com><77F357662F8BFA4CA7074B0410171B6D04049B89@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D04049BC7@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-OriginalArrivalTime: 09 Feb 2008 13:04:41.0047 (UTC) FILETIME=[5510A670:01C86B1C] X-Brightmail-Tracker: AAAAAA== Cc: HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-api-03.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi Miika, > thanks for your comments and I am looking forward for your > contributions. Gonzalo, I hope it is ok to bend the deadline? at this point it is more important to get a technically solid document than to meet the deadline (as long as the delay is not too high, of course). Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@ietf.org http://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Feb 25 00:16:20 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E63B28C2C4; Mon, 25 Feb 2008 00:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 RRoZ2reEw1pX; Mon, 25 Feb 2008 00:16:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7538628C266; Mon, 25 Feb 2008 00:16:19 -0800 (PST) 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 AB30028C266 for ; Mon, 25 Feb 2008 00:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 yCnrh-BoTy-F for ; Mon, 25 Feb 2008 00:16:17 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B63E528C1B8 for ; Mon, 25 Feb 2008 00:16:17 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 66E2D21008; Mon, 25 Feb 2008 09:14:15 +0100 (CET) X-AuditID: c1b4fb3c-ad8babb000007e19-69-47c278d7c264 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4DE9620DB0; Mon, 25 Feb 2008 09:14:15 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 09:14:15 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 09:14:07 +0100 Received: from [131.160.37.21] (E000FB0F665DD.lmf.ericsson.se [131.160.37.21]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 172F92461; Mon, 25 Feb 2008 10:14:07 +0200 (EET) Message-ID: <47C278CE.1050007@ericsson.com> Date: Mon, 25 Feb 2008 10:14:06 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: HIP X-OriginalArrivalTime: 25 Feb 2008 08:14:07.0207 (UTC) FILETIME=[644BC770:01C87786] X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Native API draft: way forward 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Folks, as you know, the WGLC on the native API draft finished a while ago. There were a few technical comments on the draft during the WGLC, most of which have been incorporated into the draft. Now we need to make a decision on how to proceed with this draft. There are some concerns that the API defined in this document may need to change as soon as we have a little more experience with NAT traversal and HIP-based overlays. With this in mind, we have two options: 1) publish the draft now stressing that it defines an experimental API and, as soon as we understand how NAT traversal and HIP-based overlays will affect the API, publish a new spec, most likely modifying the API. 2) wait for the NAT traversal and HIP-based overlays work to be more mature before publishing this draft. This way, the API defined by the draft will have better chances to be future proof. I lean towards doing 2), but I would like to get feedback from the community on what is the best way forward. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@ietf.org http://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Feb 25 10:48:20 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5044E28C766; Mon, 25 Feb 2008 10:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 GNWXtGi-fhHV; Mon, 25 Feb 2008 10:48:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AEB628C7D8; Mon, 25 Feb 2008 10:45:06 -0800 (PST) X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 66B4D28C796; Mon, 25 Feb 2008 10:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225184501.66B4D28C796@core3.amsl.com> Date: Mon, 25 Feb 2008 10:45:01 -0800 (PST) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-native-api-04.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: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Basic Socket Interface Extensions for Host Identity Protocol (HIP) Author(s) : M. Komu, T. Henderson Filename : draft-ietf-hip-native-api-04.txt Pages : 18 Date : 2008-02-25 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-04.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-04.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-04.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: <2008-02-25103250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-native-api-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-native-api-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25103250.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@ietf.org http://www.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@ietf.org Mon Feb 25 10:54:03 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59363A6E30; Mon, 25 Feb 2008 10:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 zhnzsUE3eFpZ; Mon, 25 Feb 2008 10:54:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF18F28C95B; Mon, 25 Feb 2008 10:48:53 -0800 (PST) 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 DBF1128C944 for ; Mon, 25 Feb 2008 10:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 a3Qv+LhMBwzo for ; Mon, 25 Feb 2008 10:48:51 -0800 (PST) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by core3.amsl.com (Postfix) with ESMTP id 25CD128C94B for ; Mon, 25 Feb 2008 10:46:11 -0800 (PST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id BEF4A2DA8; Mon, 25 Feb 2008 20:46:04 +0200 (EET) X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7B9192D79; Mon, 25 Feb 2008 20:45:58 +0200 (EET) Date: Mon, 25 Feb 2008 20:45:58 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Gonzalo Camarillo In-Reply-To: <47C278CE.1050007@ericsson.com> Message-ID: References: <47C278CE.1050007@ericsson.com> MIME-Version: 1.0 Cc: HIP Subject: Re: [Hipsec] Native API draft: way forward 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org On Mon, 25 Feb 2008, Gonzalo Camarillo wrote: The latest version of the draft is here: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-04.txt > Folks, > > as you know, the WGLC on the native API draft finished a while ago. There > were a few technical comments on the draft during the WGLC, most of which > have been incorporated into the draft. Now we need to make a decision on how > to proceed with this draft. > > There are some concerns that the API defined in this document may need to > change as soon as we have a little more experience with NAT traversal and > HIP-based overlays. With this in mind, we have two options: > > 1) publish the draft now stressing that it defines an experimental API and, > as soon as we understand how NAT traversal and HIP-based overlays will affect > the API, publish a new spec, most likely modifying the API. > > 2) wait for the NAT traversal and HIP-based overlays work to be more mature > before publishing this draft. This way, the API defined by the draft will > have better chances to be future proof. > > > I lean towards doing 2), but I would like to get feedback from the community > on what is the best way forward. > > Thanks, > > Gonzalo > HIP co-chair > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@ietf.org http://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Feb 25 11:02:56 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3967F28C917; Mon, 25 Feb 2008 11:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 YEDrrCG5Jod2; Mon, 25 Feb 2008 11:02:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A454828C9D5; Mon, 25 Feb 2008 10:57:50 -0800 (PST) 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 A252228C849 for ; Mon, 25 Feb 2008 10:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 CE67vZ3y5Dii for ; Mon, 25 Feb 2008 10:57:48 -0800 (PST) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by core3.amsl.com (Postfix) with ESMTP id E0AEB28C869 for ; Mon, 25 Feb 2008 10:54:55 -0800 (PST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1B63B2DB1; Mon, 25 Feb 2008 20:54:50 +0200 (EET) X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 849A72CF6 for ; Mon, 25 Feb 2008 20:54:49 +0200 (EET) Date: Mon, 25 Feb 2008 20:54:49 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Subject: [Hipsec] new nat draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Folks, the nat design team has published a new version of the draft based on STUN/ICE: http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-03.txt This version concentrates on the NAT extensions for base exchange, HIP Relay and CLOSE. Mobility and multihoming will be addressed on a separated draft. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@ietf.org http://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Mon Feb 25 11:03:52 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C8028C72B; Mon, 25 Feb 2008 11:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 PAPu-9BMS35S; Mon, 25 Feb 2008 11:03:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131CA28CA4A; Mon, 25 Feb 2008 11:00:04 -0800 (PST) X-Original-To: hipsec@ietf.org Delivered-To: hipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5DA1828C9FC; Mon, 25 Feb 2008 11:00:00 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225190001.5DA1828C9FC@core3.amsl.com> Date: Mon, 25 Feb 2008 11:00:01 -0800 (PST) Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-nat-traversal-03.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: , Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Basic HIP Extensions for Traversal of Network Address Translators and Firewalls Author(s) : M. Komu, et al. Filename : draft-ietf-hip-nat-traversal-03.txt Pages : 26 Date : 2008-02-25 The Host Identity Protocol (HIP) provides a new namespace that can be used for uniquely identifying hosts. Existing HIP experimental specifications do not specify protocol operations across Network Address Translators (NATs). This document specifies NAT traversal extensions for HIP. The HIP shim layer is located between the network and transport layer, the extensions can also provide a more general-purpose NAT traversal support for higher-layer networking applications. The extensions are based on the use of the The Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts. Using the specified extensions, two HIP-capable hosts are able to communicate with each other even when both nodes are behind NATs or firewalls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-nat-traversal-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-nat-traversal-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25104924.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-nat-traversal-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-nat-traversal-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25104924.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@ietf.org http://www.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@ietf.org Tue Feb 26 01:34:44 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976003A6BF8; Tue, 26 Feb 2008 01:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 zWT41GXfT5ez; Tue, 26 Feb 2008 01:34:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0953A6C1C; Tue, 26 Feb 2008 01:34:43 -0800 (PST) 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 364CA3A6BF2 for ; Tue, 26 Feb 2008 01:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 aPpnSPDX7Bts for ; Tue, 26 Feb 2008 01:34:42 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BE37A3A6BF8 for ; Tue, 26 Feb 2008 01:34:41 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A3E262C009E8E; Tue, 26 Feb 2008 10:34:35 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC-ZbGqRurh3; Tue, 26 Feb 2008 10:34:35 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 9087D2C009E8D; Tue, 26 Feb 2008 10:34:25 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 10:34:24 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DD9B@mx1.office> In-Reply-To: <47C278CE.1050007@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Native API draft: way forward Thread-Index: Ach3hsW/wRcEd+1GSMiB53wPfyHL0wA08MPQ References: <47C278CE.1050007@ericsson.com> From: "Martin Stiemerling" To: "Gonzalo Camarillo" , "HIP" Subject: Re: [Hipsec] Native API draft: way forward 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Hi, > -----Original Message----- > From: hipsec-bounces@ietf.org > [mailto:hipsec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Monday, February 25, 2008 9:14 AM > To: HIP > Subject: [Hipsec] Native API draft: way forward > > Folks, > > as you know, the WGLC on the native API draft finished a while ago. > There were a few technical comments on the draft during the > WGLC, most of which have been incorporated into the draft. > Now we need to make a decision on how to proceed with this draft. > > There are some concerns that the API defined in this document > may need to change as soon as we have a little more > experience with NAT traversal and HIP-based overlays. With > this in mind, we have two options: > > 1) publish the draft now stressing that it defines an > experimental API and, as soon as we understand how NAT > traversal and HIP-based overlays will affect the API, publish > a new spec, most likely modifying the API. > > 2) wait for the NAT traversal and HIP-based overlays work to > be more mature before publishing this draft. This way, the > API defined by the draft will have better chances to be future proof. I also would tend to 2) as HIP is not yet a protocol that is used outside the IETF community to a large extend. This gives us more time to get done really. Martin stiemerling@nw.neclab.eu <== NEW ADDRESS NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Hipsec mailing list Hipsec@ietf.org http://www.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@ietf.org Fri Feb 29 05:20:51 2008 Return-Path: X-Original-To: ietfarch-hipsec-archive@core3.amsl.com Delivered-To: ietfarch-hipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712D628C4B3; Fri, 29 Feb 2008 05:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 8xFezZm8NbH0; Fri, 29 Feb 2008 05:20:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7AB28C655; Fri, 29 Feb 2008 05:20:45 -0800 (PST) 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 8DFB228C52D for ; Fri, 29 Feb 2008 05:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 WY5AvcL8+p22 for ; Fri, 29 Feb 2008 05:20:41 -0800 (PST) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 9866B3A6EEC for ; Fri, 29 Feb 2008 05:20:41 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JV5A9-00064z-32 for hipsec@ietf.org; Fri, 29 Feb 2008 08:20:33 -0500 Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <295A6668-EC61-48EA-9F61-8C9F3F0B03D2@magma.ca> To: HIP Group From: Philip Matthews Date: Fri, 29 Feb 2008 08:20:35 -0500 X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: [Hipsec] Demultiplexing STUN from ESP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: hipsec-bounces@ietf.org Errors-To: hipsec-bounces@ietf.org Folks: A few of us on the NAT Traversal for HIP design team have been discussing how to demux a STUN connectivity check packet from an ESP packet containing application data. Due to the way NATs work, the STUN connectivity check packets have to be sent using the same addresses and ports as the ESP packets. Thus a way to distinguish these two kinds of packets at the receiver is needed. The current mechanism is described in section 5.2 of draft-ietf-hip- nat-traversal-03 and draft-ietf-behave-rfc3489bis. Under the current proposal, an incoming packet is a STUN packet if it has _all three_ of the properties listed in the STUN specification: 1) Bits 0, 1, 30, and 31 of the first 32-bit longword are zero; 2) The second 32-bit longword contains the so-called "magic cookie" value of 0x2112A442; AND 3) The STUN message contains a Fingerprint TLV with the correct value. The first two tests are clearly quick and easy to do, but the third test requires more work because the packet must be parsed to locate the Fingerprint TLV and then the value of the TLV must be checked. The design team has been discussing whether we might move to a simpler test. In this simpler test, HIP endpoints would be required to select SPI values in the range 0x80000000 to 0xFFFFFFFF. This would ensure that the first bit of the ESP header is a 1. Since a STUN packet must have a 0 in this position, a simple test would be sufficient to demultiplex the two packet types. The only drawback that we can see from this simpler test is that the effective range of an SPI is cut in half. It is not clear to us whether this range reduction is important from a security standpoint or not. We would like to get the WG's feedback on this proposed simpler test. Is this the reduction in the SPI range acceptable? Comments? - Philip PS. An alternative, slightly more complex test is to ensure that the SPI chosen sets at least one of bits 0,1,30,31 to one, since a STUN packet sets all four of these bits to zero. This alternative test allows the new SPI range to be 94% of the current range, at the cost of a more complex algorithm for choosing an SPI (to keep it random). _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec