From hipsec-bounces@lists.ietf.org Wed Nov 01 04:43:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfCci-0007EA-DU; Wed, 01 Nov 2006 04:43:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfCcb-00074w-Ph; Wed, 01 Nov 2006 04:42:57 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfCcZ-0000s4-Ti; Wed, 01 Nov 2006 04:42:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kA19gpbq010031; Wed, 1 Nov 2006 11:42:51 +0200 Date: Wed, 1 Nov 2006 11:42:51 +0200 (EET) From: Pekka Savola To: Jari Arkko Subject: Re: [Hipsec] Re: Last Call: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC (draft-laganier-ipv6-khi) In-Reply-To: <45452D5A.6000007@piuha.net> Message-ID: References: <45452D5A.6000007@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.5/2135/Tue Oct 31 23:57:40 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_50, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: HIP , Internet Area , iesg@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Tailing down the Cc: a bit.. On Mon, 30 Oct 2006, Jari Arkko wrote: > We are last calling this document for the second time, for > two reasons. The first reason is to make sure that the > last call has been circulated widely enough in the > community. I believe a document such as this is needed, though the allocation could be made from some other block; I don't have strong opinions on that. At least Geoff asked whether these need to be drawn from the IPv6 unicast block. I'd like to better understand what would be the alternatives. Presumably this might refer to a different prefix such as ::/16. That might be better because that way it would be clearer that the prefixes are not meant to be routable as they would be more easily distinguished as special. I'd suspect that at some point implementations or operators filter out most of ::/16 which might ease the leakage issues. Others already commented about undefined 'temporary' allocation part. A few comments, In section 1.1: In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer. ==> 'making it trivial' sounds too easy to be true. How exactly do you prevent their usage at the IP layer -- by filtering source/destination addresses of the prefix coming in/going out of the wire? But that was exactly what you prohibited from doing (by default). What you seem to be saying that it might be trivial to prevent IP layer usage _at the consenting hosts_, but the current statement is broader than that and causes potential problems as Ted Hardie and maybe others pointed out. In section 2, Encode_n( ): An extraction function which output is obtained by extracting the middle 100-bits long bitstring from the argument bitstring. ==> I don't understand what you mean by "the middle 100-bits long bitstring". The sentence doesn't seem to parse very well. I also don't understand what "middle" might mean here -- it'd probably require a more specific definition if it stays. 7. IANA Considerations ==> draft-huston-ipv6-iana-specials includes a list of things IANA needs to know (updated slightly by RFC-editor note in the announcement) in Section 3. I believe this is something that every requestor should fill in the document itself rather than leave it to be done during the IANA stage. If that process is used here, it might be useful to include a filled template in this section. We propose sharing the name space introduced for CGA Type Tags. Hence, defining new values would follow the rules of Section 8 of [RFC3972], i.e., on a First Come First Served basis. The policy will require updating the policy for assignment in the CGA Message Type name space. ==> I'm not sure if I understand the last sentence. First of all, you refer first to 'CGA Type Tags' and then 'CGA Message Type name space'. Do you refer to the same thing or not? I assume yes (please reword): if so, it's not clear why the assignment policy requires updating as it's already FCFS. Further, even if it did, you use passive voice -- it isn't clear if this document is meant to update the policy (but doesn't adequately specify that), or whether that is done later. editorial --------- As of today, SHA1 [RFC3174] is considered as satisfying the second- preimage resistance requirement Hash output of 100 bits is considered to have a low enough probability of collisions. ==> period missing before 'Hash'. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. ==> RFC4291 is a later version of this. [Hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity Indirection Infrastructure (Hi3)", November 2004. [NodeID] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A Node Identity Internetworking Architecture (NodeID)", April 2006. ==> it wouldn't hurt if the reference was a bit more specific. I guess these are scientific publications. The journal/conference should at least be mentioned. URL is optional. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Nov 07 15:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXUd-0007gK-9J; Tue, 07 Nov 2006 15:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXUc-0007dg-0W for hipsec@ietf.org; Tue, 07 Nov 2006 15:24:22 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXUX-0007oc-DD for hipsec@ietf.org; Tue, 07 Nov 2006 15:24:21 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 92A6D31B3; Tue, 7 Nov 2006 22:24:14 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-niksula20060712 (2006-10-05) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.7-niksula20060712 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9F37630E0; Tue, 7 Nov 2006 22:24:13 +0200 (EET) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3/Submit) with ESMTP id kA7KOAhi019464; Tue, 7 Nov 2006 22:24:12 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Tue, 7 Nov 2006 22:24:09 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: HIP Subject: Re: [Hipsec] Base draft issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: "Gray, Eric" , "Joseph Salowey \(jsalowey\)" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 19 Oct 2006, Petri Jokela wrote: (apologies for the rather long delay, but I believe there was no comment on the two last open issues) > List of issues that I do not necessarily require immediate actions or > that I haven't modified: > > > 16. Risk with using the same D-H value and random puzzle > > "The security consideration section indicates there is a risk in using > the same D-H value and random puzzle, but it does not describe what the > risk is. This makes it difficult to balance with the tradeoff > described. " > > - I haven't made any modifications related to this. Any input for this? With fixed puzzles, an initiating attacker does not have to calculate cookies after the first R1. Combined with reused D-H key, the initiating attacker can use prebuilt I2 messages and thus avoid also signature calculation. This way, the attacker exchanges I1 and R1, and then infinitely send I2 messages, forcing the responder to verify the I2 signatures and calculate new R2 messages. The responder has state at this point (R2-SENT) and can implement caching of sent R2 messages. However, the caching is only valid until the prebuilt R1 message pool is refreshed and the received I2 remains the same. Also, the responder can go to ESTABLISHED after timeouting in R2-SENT, but it still has to accept the I2 packets in this state. As an alternative implementation strategy, the responder may also implement "fair" rate control for incoming R1 packets that guarantees valid initiators to be served eventually. > 17. Sigma > > "The draft claims to be based on the SIGMA exchange. While it is similar > there are some differences. In particular the signature on the > responder's exponential is not required to be validated. > I think it looks OK since the last MAC is signed by the responder, but it > would probably be good to have another set of eyes look at it. " The R1 signature covers the responder's exponential. The MAC in R2 is derived using the exponential and the signature covers the MAC, so I don't see a problem. The original discussion is here: http://www1.ietf.org/mail-archive/web/hipsec/current/msg00922.html I could stop here, but I analyzed the SIGMA compliancy slightly further. I would actually claim that the base exchange is a hybrid of "basic ISO KE" and "basic SIGMA" of the SIGMA paper, which are both secure according to the SIGMA paper. Both the basic ISO and basic SIGMA have three messages, but HIP has four. The difference is the extra I1 "trigger" packet in the beginning of base exchange that allows responder to be stateless. The trigger packet can be added also to the beginning of the ISO and SIGMA protocols, which just "reverts" the roles of the peers. Below, I am assuming that both ISO and SIGMA are modified to have the extra trigger packet in the beginning, just to match the base exchange packet numbers. >From ISO, base exchange inherits the "intended recipient property" which means that the public keys are exposed earlier than in SIGMA (i.e. in the first messages). This, and the derivation of HITs from public keys especially for the otherwise unprotected trigger packet, protects the initiator from attacks where middleman is able to modify the packet. With the use of opportunistic HIP, the "intented recipient property" (which "degrades" base exchange to level of SIGMA), but this is not in primary scope of the base draft anymore. Optional public key protection against active attacks is provided as described in "identity protection variant of the ISO protocol" in the SIGMA paper. In short, the initiator encrypts the public key and makes use of hashes (HITs). I believe this might be subject to crypto analysis and may not provide as strong identity protection as SIGMA-I and SIGMA-R, because those encrypt also the signatures and MACs. >From SIGMA, the base exchange borrows the use of MACs. The main use of MACs in SIGMA is to "decouple the authentication of the DH exponentials from the binding of key and identities". However, since public keys are sent in plaintext (with the exception that initiator *can* encrypt it), the decoupling possibility introduced by MACs is not really used in HIP. IMHO, the MAC of I2 acts mainly as light-weight signature that provides some guarantee for the responder that the time-consuming DSA/RSA signature is worth of verifying. This increases the DoS protection for the responder. Despite the current limited use of the MAC, it allows extending the base exchange v2 towards SIGMA-I and SIGMA-R in my view. HIP differs from SIGMA and ISO in the way the signatures and exponentials are used. In SIGMA and ISO, a signature covers both initiator and responder exponentials within the same signature. In both ISO and SIGMA, a signature covers explicitly both two exponentials. In HIP, a signature covers only a single exponential explicitly. However, we must remember that (1) the HITs affect the MAC key derivation and (2) HITs are covered by the signatures. Putting (1) and (2) together assures an "implicit" binding between the exponentials. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Nov 18 06:00:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlNv7-0007tR-Lk; Sat, 18 Nov 2006 05:59:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlNv6-0007r7-3B for hipsec@ietf.org; Sat, 18 Nov 2006 05:59:36 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlNuw-0007NG-Kd for hipsec@ietf.org; Sat, 18 Nov 2006 05:59:36 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BE5041AD; Sat, 18 Nov 2006 11:59:17 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 11:59:17 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 11:59:17 +0100 Received: from [131.160.126.15] (rvi2-126-15.lmf.ericsson.se [131.160.126.15]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4307C2356; Sat, 18 Nov 2006 12:59:17 +0200 (EET) Message-ID: <455EE785.4000703@ericsson.com> Date: Sat, 18 Nov 2006 12:59:17 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: HIP Subject: Re: [Hipsec] WG items for our new milestones References: <4541F4C5.8000703@ericsson.com> In-Reply-To: <4541F4C5.8000703@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2006 10:59:17.0426 (UTC) FILETIME=[97933120:01C70B00] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Authors of the drafts below, Gonzalo Camarillo wrote: > Folks, > > our new charter has been approved and will be posted soon. The new > charter has three new milestones: > > 1) Legacy NAT Traversal > 2) Legacy Application Interworking > 3) Native API > > We intend to use the following drafts as starting points for their > respective milestones: > > 1) draft-schmitt-hip-nat-traversal-02.txt > 2) draft-henderson-hip-applications-03.txt > 3) draft-komu-shim-native-api-00.txt > > If somebody disagrees with making these drafts WG items, please let us > know. > > Thanks, > > Gonzalo > HIP co-chair > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Nov 18 06:04:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlNzm-0000C3-6W; Sat, 18 Nov 2006 06:04:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlNzl-0000Bx-HK for hipsec@ietf.org; Sat, 18 Nov 2006 06:04:25 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlNzf-0007va-1f for hipsec@ietf.org; Sat, 18 Nov 2006 06:04:25 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 53B045AF; Sat, 18 Nov 2006 12:04:18 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 12:04:18 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 12:04:17 +0100 Received: from [131.160.126.15] (rvi2-126-15.lmf.ericsson.se [131.160.126.15]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 90E8C2356; Sat, 18 Nov 2006 13:04:17 +0200 (EET) Message-ID: <455EE8B1.3020305@ericsson.com> Date: Sat, 18 Nov 2006 13:04:17 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: HIP Subject: Re: [Hipsec] WG items for our new milestones References: <4541F4C5.8000703@ericsson.com> In-Reply-To: <4541F4C5.8000703@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2006 11:04:17.0953 (UTC) FILETIME=[4AB3F910:01C70B01] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: schmitt@netlab.nec.de, lars.eggert@netlab.nec.de X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Authors of the drafts below, draft-schmitt-hip-nat-traversal-02.txt draft-henderson-hip-applications-03.txt draft-komu-shim-native-api-00.txt given that nobody has objected, could you please submit a new revision of these drafts as HIP WG items? Please, copy the chairs in your submission so that we can approve them. We would also like to encourage mailing list discussions on these new WG items, which relate to the three new milestones in our charter. http://www.ietf.org/html.charters/hip-charter.html Thanks, Gonzalo HIP co-chair Gonzalo Camarillo wrote: > Folks, > > our new charter has been approved and will be posted soon. The new > charter has three new milestones: > > 1) Legacy NAT Traversal > 2) Legacy Application Interworking > 3) Native API > > We intend to use the following drafts as starting points for their > respective milestones: > > 1) draft-schmitt-hip-nat-traversal-02.txt > 2) draft-henderson-hip-applications-03.txt > 3) draft-komu-shim-native-api-00.txt > > If somebody disagrees with making these drafts WG items, please let us > know. > > Thanks, > > Gonzalo > HIP co-chair > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Nov 22 15:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmz2q-00065b-SR; Wed, 22 Nov 2006 15:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmz2g-00061o-M2; Wed, 22 Nov 2006 15:50:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmz2g-0005WJ-CH; Wed, 22 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id EF32F26E66; Wed, 22 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gmz2f-0006kd-Oo; Wed, 22 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-nat-traversal-00.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : HIP Extensions for the Traversal of Network Address Translators Author(s) : V. Schmitt, et al. Filename : draft-ietf-hip-nat-traversal-00.txt Pages : 33 Date : 2006-11-22 This document specifies extensions to Host Identity Protocol (HIP) to support traversal of Network Address Translator (NAT) middleboxes. The traversal mechanism tunnels HIP control and data traffic over UDP and enables HIP initiators which MAY be behind NATs to contact HIP responders which MAY be behind another NAT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-00.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-00.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-00.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: <2006-11-22115351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-nat-traversal-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-nat-traversal-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-22115351.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Wed Nov 22 15:50:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmz3D-0007AZ-3N; Wed, 22 Nov 2006 15:50:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmz3A-00079X-FI; Wed, 22 Nov 2006 15:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gmz3A-0004Sc-5X; Wed, 22 Nov 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 11BD72AC79; Wed, 22 Nov 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gmz2f-0006kg-PW; Wed, 22 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-native-api-00.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Native Application Programming Interfaces for SHIM Layer Prococols Author(s) : M. Komu Filename : draft-ietf-hip-native-api-00.txt Pages : 21 Date : 2006-11-22 This document proposes extensions to the current networking APIs for protocols based on identifier/locator split. Currently, the document focuses on HIP, but the extensions can be used also by other protocols similar "shim" layer protocols. Using the API extensions, new SHIM aware applications can gain a better control of the SHIM layer and endpoint identifiers. For example, the applications can query and set SHIM related attributes, or specify their own endpoint identifiers for a host. In addition, a new indirection element called endpoint descriptor is defined for SHIM aware applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-00.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-00.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-00.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: <2006-11-22115856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-native-api-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-native-api-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-22115856.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Sun Nov 26 15:50:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoQwv-0008So-S9; Sun, 26 Nov 2006 15:50:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoQws-0008Ry-3B; Sun, 26 Nov 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoQwr-0001c5-Q0; Sun, 26 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BE3323288B; Sun, 26 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GoQwr-0004DT-L3; Sun, 26 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 26 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-applications-00.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Using HIP with Legacy Applications Author(s) : T. Henderson, P. Nikander Filename : draft-ietf-hip-applications-00.txt Pages : 12 Date : 2006-11-26 The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family (e.g., AF_HOST), but it may be a long time until such HIP- aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is HIP-aware but the applications are not. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-00.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-applications-00.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-applications-00.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: <2006-11-26140525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-applications-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-applications-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-26140525.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart--