From ticsa-info-admin@honor.trusecure.com Fri Apr 1 11:01:21 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08052 for ; Fri, 1 Apr 2005 11:01:20 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 453AC7362 for ; Fri, 1 Apr 2005 11:00:48 -0500 (EST) Date: Fri, 01 Apr 2005 11:00:48 -0500 Message-ID: <20050401160048.10510.47176.Mailman@honor> Subject: honor.trusecure.com mailing list memberships reminder From: mailman-owner@honor.icsalabs.com To: hip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: ticsa-info-admin@honor.trusecure.com Errors-To: ticsa-info-admin@honor.trusecure.com X-BeenThere: ticsa-info@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk This is a reminder, sent out once a month, about your honor.trusecure.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, hipsec-request@honor.trusecure.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@honor. Thanks! Passwords for hip-archive@lists.ietf.org: List Password // URL ---- -------- hipsec@honor.trusecure.com fewefo http://honor.trusecure.com/mailman/options/hipsec/hip-archive%40lists.ietf.org From hipsec-admin@honor.trusecure.com Sat Apr 2 04:55:43 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09531 for ; Sat, 2 Apr 2005 04:55:42 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9D8187314; Sat, 2 Apr 2005 04:55:03 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id E19697303; Sat, 2 Apr 2005 04:54:10 -0500 (EST) Received: from localhost (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id CDD83212F96; Sat, 2 Apr 2005 12:54:07 +0300 (EEST) From: Jan Mikael Melen To: hipsec@honor.trusecure.com, hipsec-rg@honor.trusecure.com User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504021254.06354.Jan.Melen@nomadiclab.com> Subject: [Hipsec] HIP4BSD source code Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sat, 2 Apr 2005 12:54:05 +0300 Date: Sat, 2 Apr 2005 12:54:05 +0300 Content-Transfer-Encoding: 7bit Hi, There is now available new version of the HIP4BSD source code at http://www.hip4inter.net/ We have also a HIP test server running at our lab. The HIT of that server can be resolved from the AAAA record of either woodstock4.hip4inter.net or woodstock6.hip4inter.net. Naturally the woodstock4 resolves also as an IPv4 A record and woodstock6 resolves as an IPv6 AAAA record. On error during the base exchange an NOTIFY message will be sent and approriate error code is set. Both the code at hip4inter.net and the test server are implementing the draft-ietf-base-01 draft. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Apr 4 05:42:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11348 for ; Mon, 4 Apr 2005 05:42:37 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A50537310; Mon, 4 Apr 2005 05:42:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by honor.icsalabs.com (Postfix) with ESMTP id BC3D4730F for ; Mon, 4 Apr 2005 05:41:33 -0400 (EDT) Received: from [192.168.1.50] (194.2.144.31) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 41E44AA30340A1B3; Mon, 4 Apr 2005 11:41:36 +0200 From: Julien Laganier To: "Henderson, Thomas R" Subject: Re: [Hipsec] Rendezvous and tunneling User-Agent: KMail/1.7 Cc: hipsec@honor.trusecure.com References: <6938661A6EDA8A4EA8D1419BCE46F24C066490B2@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C066490B2@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504041141.43963.julien.IETF@laposte.net> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 4 Apr 2005 11:41:43 +0200 Date: Mon, 4 Apr 2005 11:41:43 +0200 Content-Transfer-Encoding: 7bit On Wednesday 30 March 2005 21:08, Henderson, Thomas R wrote: > -----Original Message----- > > So I have now three questions before I begin another pass of > > edition: > > > > 1) Should we get rid of I1_TUNNELING mode? > > > > 2) Should we get rid of BIDIRECTIONAL mode? If not, what is > > the usage scenario you have in mind? > > > > 3) Should we specify that the RVS relays I1 _and_ UPDATES? This > > is required to support double-movement in mobility scenarios. > > I am fine with 1 and 2. As for 3, note that the current mobility > draft does not address the double-jump problem from the client > side. Therefore, if UPDATE inclusion gets hairy (i.e., has DoS > issues), then I would not delay the RVS draft on account of that. > On the other hand, if it is a simple extension, then it will > probably be used by future mobility drafts. Ok, then I will proceed with (1) and (2). Regarding (3), I don't think there's is additional DoS issues we should be concerned about. Potentials attacks involving UPDATE relaying are likely to be less severe than those involving I1: The I1 relaying introduces reflexion and amplification (because R1 is larger than I1) attacks. The RVS draft defends against these attacks by HMACing packets relayed by the RVS, hence defending against malicious nodes, but not against malicious RVS. With UPDATEs relaying, the only attacks introduced are reflexion attacks: An UPDATE will trigger another UPDATE, which is about the same size. So I would say that we can specify UPDATE relaying, and that it is somewhat "easier" to secure than I1 relaying. I might be wrong though, and will appreciate if someone can confirm/infirm the above analysis. Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Apr 4 08:36:33 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26143 for ; Mon, 4 Apr 2005 08:36:33 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7E97D7307; Mon, 4 Apr 2005 08:36:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id C370872E6 for ; Mon, 4 Apr 2005 08:35:51 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id B8DAE212FAB; Mon, 4 Apr 2005 15:35:39 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060ACA@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060ACA@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Tim Shepard" , From: Pekka Nikander Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619.2) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 4 Apr 2005 15:35:46 +0300 Date: Mon, 4 Apr 2005 15:35:46 +0300 Content-Transfer-Encoding: 7bit Tom, >>> That describes the essential bit of what I was trying to get at by >>> proposing we just have a byte with one or two assigned code points. >>> So if we say this: >>> >>> If the prefix is 01000, >>> then the next 3 bits are the HA. >>> >>> If the prefix is something other than 01000, then the syntax and >>> semantics of the following bits (however many there may be) >>> are to be defined by future documents. >>> >>> that makes me happy. >> >> I'm happy with that, too. > > Can we make it 010, with five bits HA? Why that way? Why not five bit prefix and three HA? IMHO three bits for the hash algorithm should be enough at this point of time. What is your rational for this different allocation of the bits? I feel that I am lacking information here. From my point of view, 3 bits is more than enough for the hash algorithm (IMHO 2 bits would do), so I don't see any reason for making it longer. Secondly, making the prefix longer is good from a potential IANA allocation point of view. Sure, we could do a still longer prefix, e.g. /13, but that would then make the hash field considerably shorter and thereby less secure. In other words, IMHO we should either go with no prefix at all, and just use 3 bits for the hash algorithm, or then go to some reasonable long prefix, where 5 bits seems like a good choice considering various implementation issues and how hard it is likely to get an IANA allocation. We can certainly wait with the IANA allocation, but IMHO we should work towards one. That is the only way that I see for having "full" backwards compatibility at the IPv6 API, with channel bindings. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Apr 4 09:42:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07072 for ; Mon, 4 Apr 2005 09:42:33 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 36790730F; Mon, 4 Apr 2005 09:42:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 5376A730A for ; Mon, 4 Apr 2005 09:41:15 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA10007; Mon, 4 Apr 2005 08:41:06 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j34Df5712745; Mon, 4 Apr 2005 08:41:05 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 06:41:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060AE0@xch-nw-27.nw.nos.boeing.com> Thread-Topic: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Thread-Index: AcU5EtG6nknbPRkTRUClyHAXEuY3cAAB54KQ From: "Henderson, Thomas R" To: "Pekka Nikander" Cc: "Tim Shepard" , X-OriginalArrivalTime: 04 Apr 2005 13:41:00.0415 (UTC) FILETIME=[F00C10F0:01C5391B] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 4 Apr 2005 06:40:59 -0700 Date: Mon, 4 Apr 2005 06:40:59 -0700 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Monday, April 04, 2005 5:36 AM > To: Henderson, Thomas R > Cc: Tim Shepard; hipsec@honor.trusecure.com > Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec]=20 > SHA1 broken? )=20 >=20 > Tom, >=20 > >>> That describes the essential bit of what I was trying to=20 > get at by=20 > >>> proposing we just have a byte with one or two assigned=20 > code points. > >>> So if we say this: > >>> > >>> If the prefix is 01000, > >>> then the next 3 bits are the HA. > >>> > >>> If the prefix is something other than 01000, then the=20 > syntax and > >>> semantics of the following bits (however many there may be) > >>> are to be defined by future documents. > >>> > >>> that makes me happy. > >> > >> I'm happy with that, too. > > > > Can we make it 010, with five bits HA? >=20 > Why that way? Why not five bit prefix and three HA? IMHO=20 > three bits for the hash algorithm should be enough at this=20 > point of time. What is your rational for this different=20 > allocation of the bits? =20 The rationale is simply to be able to more simply enumerate those prefixes that would collide with IPv6 address space. With five bits, it makes it longer to enumerate all of the possible collisions with that space-- unless one allows wildcards. For example, if I want to specify a different HIT space that covers all of the global unicast IPv6 addresses, with five bit prefix, I must enumerate a lot of possible prefixes. Maybe this is a non-issue, if wild card bits are supported in future prefix definitions. I was not thinking of 3 vs. 5 from an IANA allocation issue, nor do I think that 5 bits is needed for the hash algorithm.=20 Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Apr 4 10:02:33 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09448 for ; Mon, 4 Apr 2005 10:02:33 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8BE38730F; Mon, 4 Apr 2005 10:02:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 4A23E730A for ; Mon, 4 Apr 2005 10:01:37 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 32EC4212FAB; Mon, 4 Apr 2005 17:01:38 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander To: hipsec@honor.trusecure.com X-Mailer: Apple Mail (2.619.2) Subject: [Hipsec] Problems with the current mailing list situation Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 4 Apr 2005 17:01:45 +0300 Date: Mon, 4 Apr 2005 17:01:45 +0300 Content-Transfer-Encoding: 7bit Folks, I am primarily sending this to the people that read the archives and may be sending mail to the list without subscribing to it. In theory that should work, but in practise it does not work right now. All posts by people not on the list need to be approved by a moderator, and I happen to be that moderator. For a number of reasons I failed to handle the posts for a few weeks, with the result that there is currently about 350 mails queued in the moderator queue. Most, if not all, of that is spam. The only spam filter that we have had was me. Now, unfortunately, Safari fails to process the mailman admin web page any more, because it is so big. Or it does, but it gets so painfully slow that it is unusable in practise, taking several minutes to render the page, and then over a minute every time I click on some widget. Hence, right now I can't do anything to process the moderator queue, and it therefore just accumulates. As a result, if someone sends a legitimate message without being on the list, it will never get processed. I am sorry about the situation, but I don't have the cycles to do anything right now. We are in the process of moving the list to another host, but that hasn't happened yet. However, that doesn't help with the current queue, which most probably will remain unprocessed forever. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Apr 6 01:55:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28165 for ; Wed, 6 Apr 2005 01:55:37 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8B93F7309; Wed, 6 Apr 2005 01:55:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 12EAE72E2 for ; Wed, 6 Apr 2005 01:54:07 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id A077F212C2D; Wed, 6 Apr 2005 08:54:01 +0300 (EEST) In-Reply-To: <05aa01c53a1d$9877fc70$ef01a996@gmp> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648DDC@xch-nw-27.nw.nos.boein g.com> <03ae01c508b2$fcab8ff0$ef01a996@gmp> <3f8d4c130634edf9fd6c9e1e4f2c6c9a@nomadiclab.com> <045b01c50aee$28290bc0$ef01a996@gmp> <29b42c8fdcdd4feb74f9efff5f2f5f05@nomadiclab.com> <05aa01c53a1d$9877fc70$ef01a996@gmp> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7f880a546bb4532477491b9d250c6736@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com, Christian Vogt , "Ahrenholz, Jeffrey M" , Jari Arkko , Jan Mikael Melen , Thomas R Henderson From: Pekka Nikander To: "Greg Perkins" X-Mailer: Apple Mail (2.619.2) Subject: [Hipsec] Re: some questions regarding the update packet protocol Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 6 Apr 2005 08:54:09 +0300 Date: Wed, 6 Apr 2005 08:54:09 +0300 Content-Transfer-Encoding: 7bit Greg, [CC:n to the list as I think this belongs to the WG and raises important topics.] >> UPDATEs MAY be retransmitting without incrementing SEQ. ... > > How to process equal sequence numbers due (normally) to > retransmissions is > outlined in section 8.10.1. But what is the difference between > retransmission and a replay attack? Nothing as far as I can tell? IIRC, the intention is to say that as packets may get duplicated in the IP network anyway, also the sending host may send duplicate packets. For example, if the sender does not receive a corresponding ACK, it may resend an old, already signed packet instead of constructing a new packet and signing that. From the receiver's perspective, it is no different from receiving a recent packet multiple times. The receiver does not know if the packet has been duplicated in the net, is a replay attack attempt, or has been resent by the sender. Maybe the text needs to be clarified? > >> If the same >> subset of parameters is included in multiple UPDATEs with different >> SEQs, the host MUST ensure that receiver processing of the >> parameters >> multiple times will not result in a protocol error. > > I also don't understand that. Is that saying you have received the > same HIP > update packet with only the SEQ changed? So I can resend the same > update > packet with an incremented SEQ, yes? IIRC, the intention is just to clarify the semantics. For example, let say that we have a hypothetical payload "Increment a counter by one". Now, if you send two identical UPDATEs with the *same* SEQ, both containing the "increment a counter by one", the counter will be incremented once. However, if you send two UPDATEs with *different* SEQs but otherwise identical, the counter will be incremented twice. This is probably too obvious, and hence some text clarification might be needed. Suggestions? Or maybe we should write more text about the perhaps-obvious semantics issue that the sender must not assume anything about the receiver's state beyond acked UPDATEs. That is, if the sender has several pending updates out, the protocol must work correctly independent on which of the pending updates actually reach the receiver and in which order. > From the way update packets are processed and tracked, it seems that > clients > could easily bombard a service with HIP update packets that the client > only > created once but can resend many times. Of course, this can be done > already > in toiday's Internet but with HIP, if the signature is being checked, > this > will cause greater problems. One way to counter that is to remember some past received UPDATEs and any responses to them, and simply re-send the already existing response in the case of receiving a resent UPDATE. > I think their needs to be an update counter > that gets incremented with each update and decremented over time. > Once you > reach some threshold MAX_UPDATE_COUNT the receiver starts to send > challenges, maybe pre-made encrypted nonces for the update initiator to > decrypt, where the nonce must be sent back before any further update > packets > are processed. This is just an extension of the puzzle challenge idea > in > the base exchange onto the update packet protocol (make the initiator > do > some work). I think something like this would help since the HIP > exchange > is good against most attacks while the update packet protocol seems > vulnerable. In principle, sounds like a good idea under certain circumstances, especially when an non-trusted (perhaps anonymous) peer sends updates in a rapid rate, and especially if any of the signatures fails. However, before proceeding with writing any text, I think we need to better understand the pros and cons. Simply allowing either of the peers to pose a challenge to the other saying "If you want to continue please solve this puzzle" may not be a good idea, as that also may be used as a DoS tool. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Apr 6 19:34:33 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20491 for ; Wed, 6 Apr 2005 19:34:32 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 53EBF7316; Wed, 6 Apr 2005 19:34:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id 5B0717315 for ; Wed, 6 Apr 2005 19:33:27 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA09656; Wed, 6 Apr 2005 16:33:06 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j36NX6L02450; Wed, 6 Apr 2005 16:33:06 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 16:33:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Null IPsec Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060AEF@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Null IPsec Thread-Index: AcUlAIiXTzmn4ZH8Tc2RbfH2HjCdcQV/NC8A From: "Henderson, Thomas R" To: "Gonzalo Camarillo" , "HIP" Cc: "David Ward" X-OriginalArrivalTime: 06 Apr 2005 23:33:06.0132 (UTC) FILETIME=[FBD9C940:01C53B00] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 6 Apr 2005 16:33:05 -0700 Date: Wed, 6 Apr 2005 16:33:05 -0700 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Wednesday, March 09, 2005 3:20 PM > To: HIP > Cc: David Ward > Subject: [Hipsec] Null IPsec >=20 > Folks, >=20 > during today's meeting, the chairs got an action point to=20 > talk to the security ADs about the possibility of having a=20 > MUST implement IPsec with null encryption and/or null=20 > integrity protection. >=20 > I talked to Russ, and his gut reaction was that null=20 > encryption with integrity may be fine, but he would need to=20 > see the use case people have in mind before accepting null=20 > encryption and null integrity. >=20 We should probably try to close out this issue. At the WG meeting, I asked whether having ESP as a MUST implement portion of HIP would constrain future implementations that might not need to run ESP. Specifically, I had in mind Secure RTP (RFC 3711). HIP plus SRTP could be implemented for a VoIP node, without ESP. IIRC, Pekka pointed out that there is usually required a minimal level of interoperability specified, and by putting out HIP as a stand-alone spec with no mandatory transport format, we would violate that tenet. I then floated the idea of requiring, at a minimum, compliance with ESP packet formats (with SPIs merely serving as per-packet shim context) even if the crypto transforms were null. However, I don't sense any support for that idea, and I am not sure it is a good idea anyway. It violates RFC2406, for instance. =20 Presently, we have the following situation: i) HIP draft requires implementation of ESP: "All HIP implementations MUST implement, at minimum, the ESP transport format for HIP [23]." ii) ESP draft requires implementation of ESP-AES-CBC with HMAC-SHA1, and ESP-NULL with HMAC-SHA1. iii) ESP-NULL is deprecated: "In addition to AES, all implementations MUST implement the ESP NULL encryption and authentication algorithms. These algorithms are provided mainly for debugging purposes, and SHOULD NOT be used in production environments. The default configuration in implementations MUST be to reject NULL encryption or authentication." Is there sentiment for changing any of these? At the very least, I think that iii) is too constraining-- we should not block the possible use of null encryption with integrity check. If no one else thinks i) is a big deal, then I will drop it. I suppose that a future RFC could override that statement if needed. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Apr 7 04:21:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26575 for ; Thu, 7 Apr 2005 04:21:36 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C43D77318; Thu, 7 Apr 2005 04:21:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by honor.icsalabs.com (Postfix) with ESMTP id C8FAD7317 for ; Thu, 7 Apr 2005 04:20:01 -0400 (EDT) Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j378Hdm6020302; Thu, 7 Apr 2005 10:19:47 +0200 (MEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 10:19:19 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 10:19:18 +0200 Received: from [131.160.37.196] (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4FFA618A90; Thu, 7 Apr 2005 11:19:18 +0300 (EEST) Message-ID: <4254ED06.6050302@ericsson.com> From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Cc: David Ward Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2005 08:19:18.0750 (UTC) FILETIME=[7E98F7E0:01C53B4A] Subject: [Hipsec] Minutes of HIP meeting in IETF 62 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 07 Apr 2005 11:19:18 +0300 Date: Thu, 07 Apr 2005 11:19:18 +0300 Content-Transfer-Encoding: 7bit Folks, here you have the draft minutes of our last meeting. Let us know if you have any comments. http://hip.piuha.net/meetings/ietf62/notes/minutes-ietf62-hip.txt Thanks, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Apr 7 14:41:38 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25208 for ; Thu, 7 Apr 2005 14:41:37 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B9449731B; Thu, 7 Apr 2005 14:41:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by honor.icsalabs.com (Postfix) with ESMTP id 8A89E731A for ; Thu, 7 Apr 2005 14:40:48 -0400 (EDT) Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j37IeklB027723 for ; Thu, 7 Apr 2005 14:40:46 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 119E21E81AB for ; Thu, 7 Apr 2005 14:33:42 -0400 (EDT) Received: from gmp (dhcp239.Research.Panasonic.COM [150.169.1.239])by redwood.research.panasonic.com (Postfix) with SMTP id 071AC1E8176for ; Thu, 7 Apr 2005 14:33:42 -0400 (EDT) Message-ID: <001b01c53ba2$3e400190$ef01a996@gmp> From: "Greg Perkins" To: References: <6938661A6EDA8A4EA8D1419BCE46F24C06648DDC@xch-nw-27.nw.nos.boein g.com> <03ae01c508b2$fcab8ff0$ef01a996@gmp> <3f8d4c130634edf9fd6c9e1e4f2c6c9a@nomadiclab.com> <045b01c50aee$28290bc0$ef01a996@gmp> <29b42c8fdcdd4feb74f9efff5f2f5f05@nomadiclab.com> <05aa01c53a1d$9877fc70$ef01a996@gmp> <7f880a546bb4532477491b9d250c6736@nomadiclab.com> Subject: Re: [Hipsec] Re: some questions regarding the update packet protocol MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Apr 2005 14:47:26 -0400 Date: Thu, 7 Apr 2005 14:47:26 -0400 Content-Transfer-Encoding: 7bit Thanks for your responses Pekka, making update packets less useful to attackers is going to be a little more complex than I thought. > IIRC, the intention is to say that as packets may get duplicated in > the IP network anyway, also the sending host may send duplicate packets. > For example, if the sender does not receive a corresponding ACK, it > may resend an old, already signed packet instead of constructing a new > packet and signing that. Ok, fair enough. > IIRC, the intention is just to clarify the semantics. For example, > let say that we have a hypothetical payload "Increment a counter by > one". > Now, if you send two identical UPDATEs with the *same* SEQ, both > containing > the "increment a counter by one", the counter will be incremented once. > However, if you send two UPDATEs with *different* SEQs but otherwise > identical, the counter will be incremented twice. > > This is probably too obvious, and hence some text clarification might > be needed. Suggestions? > > Or maybe we should write more text about the perhaps-obvious semantics > issue that the sender must not assume anything about the receiver's > state beyond acked UPDATEs. That is, if the sender has several pending > updates out, the protocol must work correctly independent on which of > the > pending updates actually reach the receiver and in which order. Ok, I think I get this now. I think the protocol should not send another, different update packet until a current outstanding update packet is acked by the receiver (or the protocol drops it, like if a mobile node sends a update packet but then gets a new ip address before receiving an ACK it can reset state and send a new update packet). This would simplify analysis of the interactions of the two HIP host's state machines. Would that cause any problems (I have trouble think of cases where I would want to send multiple update packets since I can bundle multiple requests into a single update packet)? Now If the receiving host is processing an update packet and receives a new one it too would need to reset state and then process the new update packet. A problem can occur if the receiver processes an update packet, ACKs it and changes state yet the sender has reset state and sent a new update packet before receiving the ACK. A way to fix that is that update packets have their own counters. Even after processing and sending an ACK the receiver will still reset state if it receives a new update packet with the same update packet counter (sequence number basically). An update packet sequence number only gets incremented after an ACK has been received. I think this would help keep the HIP protocol running smoothly. > One way to counter that is to remember some past received UPDATEs and > any responses to them, and simply re-send the already existing response > in the case of receiving a resent UPDATE. I thought about that previously and decided that an attacker would simply create more instances of update packets than an implementation would save, then cycle through them. There is just no way to stop this without implementing an intrusion detection system at the IP layer (that seems unlikely ;) ) or limiting the number of requests in order to limit the damage that an attacker can do. Some limit based on RTT might help here but could cause problems with fast moving mobile hosts (or host's on connection boundaries). So probably allow REA update packets at anytime but if the same update packet or a different update packet is received before RTT then drop it or even flag it as an attack and drop the connection. That would at least help. > In principle, sounds like a good idea under certain circumstances, > especially when an non-trusted (perhaps anonymous) peer sends updates > in a rapid rate, and especially if any of the signatures fails. > However, before proceeding with writing any text, I think we need > to better understand the pros and cons. Simply allowing either of > the peers to pose a challenge to the other saying "If you want to > continue please solve this puzzle" may not be a good idea, as that > also may be used as a DoS tool. Good point. I made an assumption that I never stated which is that an initiator of a HIP session can never send a challenge. If the receiver of a HIP I1 ever receives a challenge they can elect to drop the session. This is good, I think something simple yet helpful can be done here with only a little bit of extra state being saved. Attacks will be possible but I think they can be limited. Greg ----- Original Message ----- From: "Pekka Nikander" To: "Greg Perkins" Cc: ; "Christian Vogt" ; "Ahrenholz, Jeffrey M" ; "Jari Arkko" ; "Jan Mikael Melen" ; "Thomas R Henderson" Sent: Wednesday, April 06, 2005 1:54 AM Subject: [Hipsec] Re: some questions regarding the update packet protocol > Greg, > > [CC:n to the list as I think this belongs to the WG and > raises important topics.] > > >> UPDATEs MAY be retransmitting without incrementing SEQ. ... > > > > How to process equal sequence numbers due (normally) to > > retransmissions is > > outlined in section 8.10.1. But what is the difference between > > retransmission and a replay attack? Nothing as far as I can tell? > > IIRC, the intention is to say that as packets may get duplicated in > the IP network anyway, also the sending host may send duplicate packets. > For example, if the sender does not receive a corresponding ACK, it > may resend an old, already signed packet instead of constructing a new > packet and signing that. > > From the receiver's perspective, it is no different from receiving > a recent packet multiple times. The receiver does not know if the > packet has been duplicated in the net, is a replay attack attempt, > or has been resent by the sender. > > Maybe the text needs to be clarified? > > > > >> If the same > >> subset of parameters is included in multiple UPDATEs with different > >> SEQs, the host MUST ensure that receiver processing of the > >> parameters > >> multiple times will not result in a protocol error. > > > > I also don't understand that. Is that saying you have received the > > same HIP > > update packet with only the SEQ changed? So I can resend the same > > update > > packet with an incremented SEQ, yes? > > IIRC, the intention is just to clarify the semantics. For example, > let say that we have a hypothetical payload "Increment a counter by > one". > Now, if you send two identical UPDATEs with the *same* SEQ, both > containing > the "increment a counter by one", the counter will be incremented once. > However, if you send two UPDATEs with *different* SEQs but otherwise > identical, the counter will be incremented twice. > > This is probably too obvious, and hence some text clarification might > be needed. Suggestions? > > Or maybe we should write more text about the perhaps-obvious semantics > issue that the sender must not assume anything about the receiver's > state beyond acked UPDATEs. That is, if the sender has several pending > updates out, the protocol must work correctly independent on which of > the > pending updates actually reach the receiver and in which order. > > > From the way update packets are processed and tracked, it seems that > > clients > > could easily bombard a service with HIP update packets that the client > > only > > created once but can resend many times. Of course, this can be done > > already > > in toiday's Internet but with HIP, if the signature is being checked, > > this > > will cause greater problems. > > One way to counter that is to remember some past received UPDATEs and > any responses to them, and simply re-send the already existing response > in the case of receiving a resent UPDATE. > > > I think their needs to be an update counter > > that gets incremented with each update and decremented over time. > > Once you > > reach some threshold MAX_UPDATE_COUNT the receiver starts to send > > challenges, maybe pre-made encrypted nonces for the update initiator to > > decrypt, where the nonce must be sent back before any further update > > packets > > are processed. This is just an extension of the puzzle challenge idea > > in > > the base exchange onto the update packet protocol (make the initiator > > do > > some work). I think something like this would help since the HIP > > exchange > > is good against most attacks while the update packet protocol seems > > vulnerable. > > In principle, sounds like a good idea under certain circumstances, > especially when an non-trusted (perhaps anonymous) peer sends updates > in a rapid rate, and especially if any of the signatures fails. > However, before proceeding with writing any text, I think we need > to better understand the pros and cons. Simply allowing either of > the peers to pose a challenge to the other saying "If you want to > continue please solve this puzzle" may not be a good idea, as that > also may be used as a DoS tool. > > --Pekka > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Apr 7 16:11:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03620 for ; Thu, 7 Apr 2005 16:11:36 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D912C731F; Thu, 7 Apr 2005 16:11:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id DD629731A for ; Thu, 7 Apr 2005 16:10:54 -0400 (EDT) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 199D02DE8; Thu, 7 Apr 2005 23:10:55 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5130D2DAA for ; Thu, 7 Apr 2005 23:10:53 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j37KAqG05842; Thu, 7 Apr 2005 23:10:52 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@honor.trusecure.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.2-niksula20040914 (2004-11-16) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2-niksula20040914 Subject: [Hipsec] clarifications to the base draft Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Apr 2005 23:10:52 +0300 (EEST) Date: Thu, 7 Apr 2005 23:10:52 +0300 (EEST) Thomas asked for Jeff and me to make some (interop related) clarifications to the text about ENCRYPTED and HMAC calculation. Here's what we came up: 6.2.16 ENCRYPTED The ENCRYPTED parameter encapsulates another TLV, the encrypted data, which is also in TLV format. Consequently, the first fields in the encapsulated parameter(s) are Type and Length, allowing the contents to be easily parsed after decryption. Both the ENCRYPTED parameter and the encapsulated TLV(s) MUST be padded. The padding needed for the ENCRYPTED parameter is referred as the "outer" padding. Correspondingly, the padding for the parameter(s) encapsulated within the ENCRYPTED parameter is referred as the "inner" padding. The inner padding follows exactly the rules of Section 6.2.1. The outer padding also follows the same rules but with an exception. Namely, some algorithms require that the data to be encrypted must be a multiple of the cipher algorithm block size. In this case, the outer padding MUST include extra padding, as specified by the encryption algorithm. The size of the extra padding is selected so that the the length of the ENCRYPTED is the minimum value that is both multiple of eight and the cipher block size. The encryption algorithm may specify padding bytes other than zero; for example, AES [AES] uses the PKCS5 padding scheme [PKCS5] (see section 6.1.1) where the remaining n bytes to fill the block each have the value n. Note that the length of the cipher suite output may be smaller or larger than the length of the data to be encrypted, since the encryption process may compress the data or add additional padding to the data. 6.2.17 NOTIFY .. 8.3.1 HMAC calculation The following process applies both to the HMAC and HMAC_2 TLVs. When processing HMAC_2, the difference is that the HMAC calculation includes a pseudo HOST_ID field containing the Responder's information as sent in the R1 packet earlier. Both the initiator and the responder should take some care when verifying or calculating the HMAC_2. Specifically, the responder should preserve other parameters than the HOST_ID when sending the R2. Also, the Initiator has to preserve the HOST_ID exactly as it was received in the R1 packet. The HMAC TLV is defined in Section 6.2.10 and HMAC_2 TLV in Section 6.2.11. HMAC calculation and verification process: .. References: [PKCS5] ftp://ftp.rfc-editor.org/in-notes/rfc2898.txt [AES] National Institute of Standards and Technology, U.S. Department of Commerce, "Advanced Encryption Standard", Federal Information Processing Standards Publication 197, Washington, DC, November 2001. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Apr 8 16:53:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11959 for ; Fri, 8 Apr 2005 16:53:35 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D1DCF7305; Fri, 8 Apr 2005 16:53:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 2C78A72F4 for ; Fri, 8 Apr 2005 16:52:49 -0400 (EDT) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1343E2D8D; Fri, 8 Apr 2005 23:52:52 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 07FA82D89; Fri, 8 Apr 2005 23:52:47 +0300 (EEST) In-Reply-To: <42076FE3.3070304@mitre.org> References: <42027267.5090503@mitre.org> <32ff0289f98cec5dfdbfd350e021043e@nomadiclab.com> <4202904C.8070909@mitre.org> <42038367.5030507@mitre.org> <60e0b916d90f3c2325617c2eb919bd5d@nomadiclab.com> <42076FE3.3070304@mitre.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <31bb3e0d13017568115ed3699ad6515d@iki.fi> Content-Transfer-Encoding: 7bit Cc: Andrew McGregor , Pekka Nikander , hipsec@honor.trusecure.com From: Teemu Koponen Subject: Re: [Hipsec] Rendezvous Server Concerns To: Kevin Grace X-Mailer: Apple Mail (2.619.2) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.2-niksula20040914 (2004-11-16) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2-niksula20040914 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 8 Apr 2005 23:52:53 +0300 Date: Fri, 8 Apr 2005 23:52:53 +0300 Content-Transfer-Encoding: 7bit On Feb 7, 2005, at 15:40, Kevin Grace wrote: Kevin, >>> Today, using readily available DNS implementations and without >>> Rendezvous Servers, one can create an A record in an authoritative >>> name server for a mobile host and assign it a time-to-live of 1 >>> second. The longest the record could possibly be cached by >>> non-authoritative name servers then is 1 second.When the node moves >>> and changes IP addresses, it can successfully update its A record >>> within the authoritative name server in less than a second. The >>> total latency between when a node's address changes and when DNS is >>> properly updated need not exceed a couple seconds and could well be >>> closer to one second. >> >> >> This is very good news indeed. Would you care to share us with a >> reference? > > Sure. From the London Communications Symposium in 2002: > http://www.ee.ucl.ac.uk/lcs/papers2002/LCS072.pdf > > The authors in the referenced paper demonstrate empirically how fast > DNS can perform zone transfers and the maximum update rate it can > support for a given configuration. Note, they are using what today > would be considered slow platforms (650 MHz PIII) and even better > performance results can be obtained today. My own organization has > conducted similar tests using faster hardware and have been able to > support over 300 individual dynamic updates/sec where each mobile node > has a unique TSIG key; each individual update completes in well under > a second. I just recalled this thread while reading a more recent paper about DNS TTL violations: Pang et al., On the responsiveness of DNS-based network control, http://www-2.cs.cmu.edu/~aditya/papers/imc04-resp.pdf My interpretation of their DNS measurements is that pure DNS based mobility is simply not possible due to the current TTL violations in Internet even though DNS itself could handle the slight increase in load, which is by the way argued in more detail in the following paper: Jung et al., DNS performance and the effectiveness of caching, http://nms.lcs.mit.edu/papers/dns-ton2002.pdf Teemu -- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec