From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Oct 29 16:42:06 2004 Subject: [Hipsec-rg] hiprg meeting Nov. 12 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04522838@xch-nw-27.nw.nos.boeing.com> We received confirmation today on our requested Nov. 12=20 slot for the HIP RG meeting: FRIDAY, November 12, 2004 1300-1530 Afternoon Session IRTF hiprg Host Identity Protocol RG We are presently finalizing the agenda and will post it ASAP. Tom From: jari.arkko@piuha.net (Jari Arkko) Date: Fri Oct 29 02:31:00 2004 Subject: [Hipsec-rg] Ask for comment about handoff analysis In-Reply-To: <32514.1099029713@www31.gmx.net> References: <32514.1099029713@www31.gmx.net> Message-ID: <4181F3A3.2080701@piuha.net> I believe you need to take into account a number of factors. Packet lengths and crypto time are (IMHO) not the most important things. Probably latency issues are priority 1 for most people, but you mileage may vary. And there components in the latency and other characteristics of handoffs that are common to HIP and other approaches. See http://www.ietf.org/internet-drafts/draft-arkko-mip6-ro-enhancements-00.txt for a discussion of handoff related performance goals, as well as some breakdown of issues affecting this and solution components for improvements, from the Mobile IPv6 point of view. Joseph So wrote: > Dear All, > I'm trying to do the analysis of HIP with other protocol and prove that > HIP can do better handoff. If by analysis and compare with other protocols, > what is the packet length I should choose, with or without HIP_Signature and > HIMAC? (Without: 40 , with 40+20+40). I found some paper just choose part of > the packet to compare (like SIP, they will use only 140bytes (SDP message) > to compare with other protocol to prove they are better) > Can anyone give me some suggestion? Because HIMAC and HIP_Signature will > be the analysis completely different. > Thanks a lot > Yours, > Joseph > From: joseph-so@gmx.net (Joseph So) Date: Fri Oct 29 00:52:00 2004 Subject: [Hipsec-rg] Ask for comment about handoff analysis Message-ID: <32514.1099029713@www31.gmx.net> Dear All, I'm trying to do the analysis of HIP with other protocol and prove that HIP can do better handoff. If by analysis and compare with other protocols, what is the packet length I should choose, with or without HIP_Signature and HIMAC? (Without: 40 , with 40+20+40). I found some paper just choose part of the packet to compare (like SIP, they will use only 140bytes (SDP message) to compare with other protocol to prove they are better) Can anyone give me some suggestion? Because HIMAC and HIP_Signature will be the analysis completely different. Thanks a lot Yours, Joseph -- NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis! From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Oct 26 04:05:00 2004 Subject: [Hipsec-rg] About the Update REA package In-Reply-To: <22655.1098770064@www18.gmx.net> References: <22655.1098770064@www18.gmx.net> Message-ID: On Tue, 26 Oct 2004, Joseph So wrote: -> Dear All, -> I'm trying to analysis about handoff in HIP. I'm calcualte the package -> length. In the draft-ietf-hip-mm-00,it mentioned that "Any UPDATE packet -> that includes a REA parameter SHOULD include both an HMAC and a -> HIP_SIGNATURE. What is a typical lenght of HIP_SIGNATURE, in the -> draft-ietf-hip-base-00, it said that it is variable. At least in the packets I see my packet captures, the length of the HIP_SIGNATURE parameter seems to be 48 bytes using DSA. -> Futhermore, can anyone give the comment on this? -> REA Update package length (Figure 3 in draft-ietf-hip-mm-00, readdress -> without rekeying, but with address check)= REA parameter + HMAC + -> HIP_SIGNATURE = 32 + 20 + HIP_SIGNATURE Add SEQ, 8 bytes. -> min REA parameter = TYPE + Length + SPI + Address Lifetim + Reservered + -> Address = 2 + 2 + 4 + 4 + 4 + 16 = 32. Is my understanding about the packet -> of HIP update packet correct? I am trying to compare with other protocols. Looks like it is right. From: joseph-so@gmx.net (Joseph So) Date: Tue Oct 26 00:45:01 2004 Subject: [Hipsec-rg] About the Update REA package Message-ID: <22655.1098770064@www18.gmx.net> Dear All, I'm trying to analysis about handoff in HIP. I'm calcualte the package length. In the draft-ietf-hip-mm-00,it mentioned that "Any UPDATE packet that includes a REA parameter SHOULD include both an HMAC and a HIP_SIGNATURE. What is a typical lenght of HIP_SIGNATURE, in the draft-ietf-hip-base-00, it said that it is variable. Futhermore, can anyone give the comment on this? REA Update package length (Figure 3 in draft-ietf-hip-mm-00, readdress without rekeying, but with address check)= REA parameter + HMAC + HIP_SIGNATURE = 32 + 20 + HIP_SIGNATURE min REA parameter = TYPE + Length + SPI + Address Lifetim + Reservered + Address = 2 + 2 + 4 + 4 + 4 + 16 = 32. Is my understanding about the packet of HIP update packet correct? I am trying to compare with other protocols. Thanks a lot. Yours, Joseph -- Geschenkt: 3 Monate GMX ProMail + 3 Ausgaben der TV Movie mit DVD ++++ Jetzt anmelden und testen http://www.gmx.net/de/go/mail ++++ From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Oct 25 09:43:01 2004 Subject: [Hipsec-rg] About the performace of HIP Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C045227CE@xch-nw-27.nw.nos.boeing.com> Joseph, One comparison can be found here: Henderson, TR, " Host Mobility for IP Networks: A Comparison" IEEE = Network Magazine, Vol. 17, No. 6, pp. 18-26, November, 2003. Tom > -----Original Message----- > From: Joseph So [mailto:joseph-so@gmx.net]=20 > Sent: Monday, October 25, 2004 12:04 AM > To: hipsec-rg@honor.trusecure.com > Subject: [Hipsec-rg] About the performace of HIP >=20 >=20 > Dear All, > I'm trying to understand the performance of HIP. I found=20 > serval papers > mentioned that "HIP is believed to provide a better=20 > performance than Mobile > IP". Is there any paper or material compared these two=20 > protocols? In the > mobility view, which one can handle the handoff better? I=20 > know that if HIP > will provide a better performance in routing a package than=20 > Mobile IPv4 as > no triangle routing problem, but how about Mobile IPv6 and HIP? > Thanks a lot. > Joseph >=20 > --=20 > +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ > Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl >=20 > _______________________________________________ > Hipsec-rg mailing list > Hipsec-rg@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec-rg >=20 From: joseph-so@gmx.net (Joseph So) Date: Mon Oct 25 01:54:00 2004 Subject: [Hipsec-rg] About the performace of HIP Message-ID: <9479.1098687833@www42.gmx.net> Dear All, I'm trying to understand the performance of HIP. I found serval papers mentioned that "HIP is believed to provide a better performance than Mobile IP". Is there any paper or material compared these two protocols? In the mobility view, which one can handle the handoff better? I know that if HIP will provide a better performance in routing a package than Mobile IPv4 as no triangle routing problem, but how about Mobile IPv6 and HIP? Thanks a lot. Joseph -- +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Thu Oct 21 02:30:01 2004 Subject: [Hipsec-rg] [Fwd: I-D ACTION:draft-eggert-hiprg-rr-prob-desc-00.txt] Message-ID: <417767BC.5090201@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms000709030406040300060203 Content-Type: multipart/mixed; boundary="------------010006020209020302000407" This is a multi-part message in MIME format. --------------010006020209020302000407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Julien and me have a new problem description draft for HIP resolution and rendezvous that is loosely based on our workshop abstract. The idea is that this draft motivates the general problem and describes specific issues. Other documents would then describe specific resolution/rendezvous proposals and discuss if and how they address the issues. (I had chatted with a few people at the last IETF and they seemed to agree that splitting the rendezvous work in this manner may be useful.) We'd be happy to receive feedback; specifically, whether the currently identified issues are valid and whether we're missing some? Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------010006020209020302000407 Content-Type: message/rfc822; name="I-D ACTION:draft-eggert-hiprg-rr-prob-desc-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-eggert-hiprg-rr-prob-desc-00.txt" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from atlas.office (atlas.office [10.1.1.15]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0D92718C084 for ; Wed, 20 Oct 2004 23:07:20 +0200 (CEST) Received: by atlas.office (Postfix) id 7BEBB203A0; Wed, 20 Oct 2004 23:12:06 +0200 (CEST) Delivered-To: quittek@atlas.office Received: by atlas.office (Postfix, from userid 502) id 790792021B; Wed, 20 Oct 2004 23:12:06 +0200 (CEST) Received: from tokyo.netlab.nec.de (pluto.office [10.1.1.84]) by atlas.office (Postfix) with ESMTP id 1F3162032E for ; Wed, 20 Oct 2004 23:12:04 +0200 (CEST) Received: by tokyo.netlab.nec.de (Postfix) id 4A4012C90D; Wed, 20 Oct 2004 23:07:18 +0200 (CEST) Delivered-To: quittek@netlab.nec.de Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 135302C90C; Wed, 20 Oct 2004 23:07:17 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIGE-0003Re-80; Wed, 20 Oct 2004 11:20:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHYQ-0008NT-2M for i-d-announce@megatron.ietf.org; Wed, 20 Oct 2004 10:35:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09871 for ; Wed, 20 Oct 2004 10:35:03 -0400 (EDT) Message-Id: <200410201435.KAA09871@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 20 Oct 2004 10:35:02 -0400 Subject: I-D ACTION:draft-eggert-hiprg-rr-prob-desc-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on atlas.office X-Spam-Status: No, hits=-103.2 required=5.0 tests=BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Level: X-Sanitizer: This message has been sanitized! --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : HIP Resolution and Rendezvous Problem Description Author(s) : L. Eggert, J. Laganier Filename : draft-eggert-hiprg-rr-prob-desc-00.txt Pages : 12 Date : 2004-10-19 This document investigates the design space for resolution and rendezvous mechanisms for the Host Identity Protocol (HIP.) It identifies and describes specific issues that HIP resolution and rendezvous mechanisms should address. These issues include dependencies on the DNS, lack of support for direct communication based on host identities, lack of a reverse lookup mechanism for host identities, and DNS and node rendezvous. This document does not propose specific resolution and rendezvous mechanisms. Different alternative solutions will be described and discussed in companion documents. These documents should analyze if and to what degree the specific proposals they present address the issues identified here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eggert-hiprg-rr-prob-desc-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-eggert-hiprg-rr-prob-desc-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-eggert-hiprg-rr-prob-desc-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: <2004-10-20104945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-eggert-hiprg-rr-prob-desc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-eggert-hiprg-rr-prob-desc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104945.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------010006020209020302000407-- --------------ms000709030406040300060203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDEwMjEwNzM5NDBaMCMGCSqGSIb3DQEJBDEWBBRgmNsyuJtK+eQHguPqb9MYaKLXmDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQC8AlOyT4S7AGJPxsL6jsIYkcHJOaez6FLDDpIzt3Y7vOUN XAtSkdb0RHeEkaI7vPsCiIHD6g/1OTP3hxVnSsByzcu52UeD3TNrMbwhv1d+AhOyEuI5Oeut fN3NX8c++Vb9iSig9rtYi1i7LMLFdPxWsLHeoivc7sVQqJuIofZOVmd1A0gQbQTewacuFbNo ccRhBKl2qEngmdVRbslmM54iyWZPnHe8qOKoCkJsbwFbXgYfOCs8UrHXaai5XDn8RwHGaOF4 cBcf/yw4biuZTiL72AA5Q1q/vFc7wjwRxZ/nSO8MBg1IE9i9hbI8YRHFSwP36KVEy2m3TY9V OGssaH94AAAAAAAA --------------ms000709030406040300060203-- From: miika@iki.fi (Miika Komu) Date: Wed Oct 20 02:27:02 2004 Subject: [Hipsec-rg] Basic Question about HIP Session In-Reply-To: <19722.1098256690@www19.gmx.net> References: <3D05F7E8-225D-11D9-8E4E-000D9331AFB0@nomadiclab.com> <19722.1098256690@www19.gmx.net> Message-ID: On Wed, 20 Oct 2004, Joseph So wrote: > Thanks for your answering, so that if there is a communication between a > HTTP server with HIP support and HTTP client with HIP support, is this > procedure correct? > 1. 4-way handshake which initalized by the HTTP client. > 2. HTTP client sends the HTTP request to server > 3. HTTP server reply Yes, this is correct. Naturally, there is also a TCP handshake between 1 and 2. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From: joseph-so@gmx.net (Joseph So) Date: Wed Oct 20 02:09:01 2004 Subject: [Hipsec-rg] Basic Question about HIP Session References: <3D05F7E8-225D-11D9-8E4E-000D9331AFB0@nomadiclab.com> Message-ID: <19722.1098256690@www19.gmx.net> Dear Pekka, Thanks for your answering, so that if there is a communication between a HTTP server with HIP support and HTTP client with HIP support, is this procedure correct? 1. 4-way handshake which initalized by the HTTP client. 2. HTTP client sends the HTTP request to server 3. HTTP server reply or 2, 1 ,3? (If the HTTP header is using the HIT/LSI instead of IP addresses) Thanks a lot. Yours, Joseph > > Is that all connections no matter in which layer above HIP (Such as > > HTTp, > > FTP, UDP, TCP) established after four-way handshake of HIP? So that no > > communication between nodes can be made before the four-way handshake > > if > > that is base on HI address? > > If I understand your question correctly, the short answer is "yes". > However, the base exchange is usually triggered by some app sending > a first packet to an LSI/HIT. > > --Pekka > > _______________________________________________ > Hipsec-rg mailing list > Hipsec-rg@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec-rg > -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 20 00:50:01 2004 Subject: [Hipsec-rg] Basic Question about HIP Session In-Reply-To: <19187.1098238142@www44.gmx.net> References: <19187.1098238142@www44.gmx.net> Message-ID: <3D05F7E8-225D-11D9-8E4E-000D9331AFB0@nomadiclab.com> > Is that all connections no matter in which layer above HIP (Such as > HTTp, > FTP, UDP, TCP) established after four-way handshake of HIP? So that no > communication between nodes can be made before the four-way handshake > if > that is base on HI address? If I understand your question correctly, the short answer is "yes". However, the base exchange is usually triggered by some app sending a first packet to an LSI/HIT. --Pekka From: joseph-so@gmx.net (Joseph So) Date: Tue Oct 19 21:00:00 2004 Subject: [Hipsec-rg] Basic Question about HIP Session Message-ID: <19187.1098238142@www44.gmx.net> Dear All, Is that all connections no matter in which layer above HIP (Such as HTTp, FTP, UDP, TCP) established after four-way handshake of HIP? So that no communication between nodes can be made before the four-way handshake if that is base on HI address? Yours, Joseph -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Oct 13 09:54:01 2004 Subject: [Hipsec-rg] agenda requests for HIP RG meeting Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608AB@xch-nw-27.nw.nos.boeing.com> We have put in a request for a HIP-RG meeting on Friday, November 12 in the afternoon (1-3:30 slot). So far, that request has not shown up in the IETF agenda, possibly because IRTF slots are handled with lower scheduling priority. If our request is not accepted, we'll let you know ASAP. Please send any requests for agenda topics to Pekka or me by the end of next week. Thanks, Tom