From hipsec-bounces@lists.ietf.org Thu Aug 09 13:48:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJC7A-00071m-MC; Thu, 09 Aug 2007 13:48:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJC78-00071g-Tz for hipsec@ietf.org; Thu, 09 Aug 2007 13:48:02 -0400 Received: from mta-2.ms.rz.rwth-aachen.de ([134.130.7.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJC76-0007rj-Tg for hipsec@ietf.org; Thu, 09 Aug 2007 13:48:02 -0400 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JMI00CH8PFZIM20@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 09 Aug 2007 19:47:59 +0200 (CEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 09 Aug 2007 19:47:59 +0200 Received: from [192.168.2.100] (p4FD2720B.dip.t-dialin.net [79.210.114.11]) by relay.rwth-aachen.de (8.13.7/8.13.3/1) with ESMTP id l79HlwdT005650 for ; Thu, 09 Aug 2007 19:47:58 +0200 (MEST) Date: Thu, 09 Aug 2007 19:47:39 +0200 From: Tobias Heer To: HIP WG Message-id: <358D6D87-48E4-4CCF-8F7E-84BFBA5FF245@cs.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) X-IronPort-AV: E=Sophos;i="4.19,241,1183327200"; d="p7s'?scan'208";a="14913251" X-Spam-Score: -4.0 (----) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Subject: [Hipsec] Security issue for middlebox authentication? 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: , Content-Type: multipart/mixed; boundary="===============1026440340==" Errors-To: hipsec-bounces@lists.ietf.org --===============1026440340== Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10-68545672; protocol="application/pkcs7-signature" --Apple-Mail-10-68545672 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi everyone, I recently stumbled about a seemingly unhandled security issue in the HIP protocol concering the authentication of HIP hosts towards middleboxes. I'm not sure if this issue has been discussed before. If so, please excuse my ignorance. In order to illustrate the issue, let me construct a small example: Assume we have a middlebox that checks HIP HIs in order to restrict traffic passing through the box (something like a HIP firewall, etc.). Assume the legitimate holder of HIT X establishes a HIP association with the legitimate holder of HIT Y at some point in time and an attacker M overhears the base exchange and records it (it is not required that the middlebox is on the communication path at that time). At some later point in time (maybe even just milliseconds later) M collaborates with another attacker N. M and N replay the very same BEX with the middlebox on the communication path. The middlebox has no way to distinguish M from X and N from Y as it can only overhear the BEX passively and does not participate in the authentication process. If M and N have agreed on a shared secret beforehand, they can make ESP traffic traverse the middlebox by using the SPIs that X and Y negotiated in the original BEX. This is problematic in all cases where the middlebox really needs to know who is communicating across it (think of logging, accounting for traffic volume, ....). If I am not completely mistaken (and that may be the case, of course) HIP does not have a built in defense against this kind of attack. Using R1 generation counters and unique puzzles won't help much because the middlebox might not have seen the first (authentic) BEX and cannot identify the replayed one as duplicate. It might be the case that HIP was not intended to be used for such authentication towards middleboxes but I remember seeing quite a few application examples that plan to use HIP in such a way. A solution for fixing this problem could be allowing middleboxes adding nonces (like the ECHO_REQUEST, ECHO_RESPONSE mechanism) to the unsigned part of the R1 and I2 messages. The initiator or responder includes this additional nonce in the signed part of the I2 or R2, respectively. This allows the middlebox to verify the signatures and the presence of its nonces before allowing ESP traffic to pass through. A problem here might be the number of middleboxes that can add nonces to the packet. If too many middleboxes insist to add nonces, this might exceed the maximum packet size for a HIP packet. However, one shouldn't expect too many middleboxes on the path. Best regards, Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany http://ds.cs.rwth-aachen.de/members/heer --Apple-Mail-10-68545672 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQjCCAvsw ggJkoAMCAQICEC1IEZFFsMbqCTfVL3CGGP8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDcwNjA2NDQ0MloXDTA4MDcwNTA2NDQ0 MlowXTENMAsGA1UEBBMESGVlcjEPMA0GA1UEKhMGVG9iaWFzMRQwEgYDVQQDEwtUb2JpYXMgSGVl cjElMCMGCSqGSIb3DQEJARYWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMw9OUSRfF10zWkVrIsXsjCC8hsCRqg7NLKWYPr1M7CfJyk/0B14o8Eu PK1qUfjl1w/E5rlHIuC3rbok9tV2hHsWqPV9+tAAr4g5QJVNrou9BCD7vHPuCMJ/7WTWMcEewmS2 +U0762iVFK/bLSKwPvaaQWQV1ULUy9zJaLPHQQIAVooBQSypQy+wtxJ3PIn6nfQQnE8hc+hhz5gd 8jLoGozYz0Xv75W4YSYRjH+/R+JLS60do+V2Si1BUaOjQPS+PBSI3uNmWQQCJOb/3LBFDiUBNWe5 PoVe+HiHZi+L4s0wimzu9O/y7IUme6U5kWQTcMYdVTqxkHDk/TbcAjniyE0CAwEAAaMzMDEwIQYD VR0RBBowGIEWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BQUAA4GBAD+gsUZ2GBKOG8XHPo8vGSBn85ucmwhiY7CHF+B9EvLKX1QebGCg7TooQLvJOighEUCt d5L59l4kjM6u3PrwcHlUkDeImHW3LP2bOvkXhmpYKTLz1QxlnV3WtyydO0JvNQz9pLSI2DAwuPx1 8E7q/XdJ5IWg6J1acNpiNhMuXOrhMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZI hvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEz MDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Ia dr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1Ro YXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRow GAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9l TzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAtSBGRRbDG6gk31S9whhj/MAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDgwOTE3NDczOVowIwYJKoZIhvcNAQkEMRYEFGLhKeYBqVXt ecFYXSZmoue+xZC5MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY/zCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY /zANBgkqhkiG9w0BAQEFAASCAQA5x+NJZcorjOigQxJApMDbD78dJSb6EYhdZfHWe+i9eiXl1zDB 4K9w0tbTDrwHzBX0+XAjswDGeGmriBRkiKJJdyRg4QXTqNLjsI5maY+W2wJ6UrgJyzSJzvU2/vDc lX4FDFPM2iasw/PadiwdF/3OzdWu/UMDSvHNr5x3lc8ac7HX6POkzu6wOOn25LA6iOJpN92YIkjG AekSN4oHLxctUOsiNTVhD+Naid0I/dn/7aE6NK4etrRxOdO/LUF+xamonpjZeEFn35kY+sU/nH0/ sMI+D1zGu6hE54wotzhTHCJhGvcRyMTjZZDw8IyRLFEaJ4nwEtWMsummaatbo3shAAAAAAAA --Apple-Mail-10-68545672-- --===============1026440340== 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 --===============1026440340==-- From hipsec-bounces@lists.ietf.org Fri Aug 10 02:23:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNtw-0003Np-Ot; Fri, 10 Aug 2007 02:23:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJNtv-0003KV-F5 for hipsec@ietf.org; Fri, 10 Aug 2007 02:23:11 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJNtt-0001x4-SK for hipsec@ietf.org; Fri, 10 Aug 2007 02:23:11 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 90871212E94; Fri, 10 Aug 2007 09:23:08 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 44C13212E8F; Fri, 10 Aug 2007 09:23:08 +0300 (EEST) In-Reply-To: <358D6D87-48E4-4CCF-8F7E-84BFBA5FF245@cs.rwth-aachen.de> References: <358D6D87-48E4-4CCF-8F7E-84BFBA5FF245@cs.rwth-aachen.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B3AB96F-EC25-44A8-9B4E-0FA942B41F69@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [Hipsec] Security issue for middlebox authentication? Date: Fri, 10 Aug 2007 09:23:02 +0300 To: Tobias Heer X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: HIP WG 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 Hi Tobias, > In order to illustrate the issue, let me construct a small example: > Assume we have a middlebox that checks HIP HIs in order to restrict =20= > traffic passing through the box (something like a HIP firewall, =20 > etc.). Assume the legitimate holder of HIT X establishes a HIP =20 > association with the legitimate holder of HIT Y at some point in =20 > time and an attacker M overhears the base exchange and records it =20 > (it is not required that the middlebox is on the communication path =20= > at that time). > > At some later point in time (maybe even just milliseconds later) M =20 > collaborates with another attacker N. M and N replay the very same =20 > BEX with the middlebox on the communication path. The middlebox has =20= > no way to distinguish M from X and N from Y as it can only overhear =20= > the BEX passively and does not participate in the authentication =20 > process. If M and N have agreed on a shared secret beforehand, they =20= > can make ESP traffic traverse the middlebox by using the SPIs that =20 > X and Y negotiated in the original BEX. This is problematic in all =20 > cases where the middlebox really needs to know who is communicating =20= > across it (think of logging, accounting for traffic volume, ....). As far as I can see, that is correct. However, ... > A solution for fixing this problem could be allowing middleboxes =20 > adding nonces (like the ECHO_REQUEST, ECHO_RESPONSE mechanism) to =20 > the unsigned part of the R1 and I2 messages. ... that's allowed already, isn't it? > The initiator or responder includes this additional nonce in the =20 > signed part of the I2 or R2, respectively. So this is what is missing: requiring the recipient of an unsigned =20 ECHO_REQUEST to include a corresponding ECHO_RESPONSE to the *signed* =20= part of the reply message? Well, that has the obvious drawback that =20 the middle box won't be able to delete the ECHO_RESPONSE from the =20 reply, but I cannot see any other bad effects.=0E > This allows the middlebox to verify the signatures and the presence =20= > of its nonces before allowing ESP traffic to pass through. A =20 > problem here might be the number of middleboxes that can add nonces =20= > to the packet. If too many middleboxes insist to add nonces, this =20 > might exceed the maximum packet size for a HIP packet. However, one =20= > shouldn't expect too many middleboxes on the path. I agree. To me what you suggest seems like a fairly simple new extension, =20 probably worthy a new parameter with the CRITICAL bit set. Care to write a draft? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 10 04:25:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJPoF-00059l-SO; Fri, 10 Aug 2007 04:25:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJPoE-00059d-6H for hipsec@ietf.org; Fri, 10 Aug 2007 04:25:26 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJPoD-0002Mq-7s for hipsec@ietf.org; Fri, 10 Aug 2007 04:25:26 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 62DAB2C62; Fri, 10 Aug 2007 11:25:24 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id E40272C5A; Fri, 10 Aug 2007 11:25:22 +0300 (EEST) Date: Fri, 10 Aug 2007 11:25:22 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing Subject: RE: AW: [Hipsec] Rebuilding ICE In-Reply-To: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> Message-ID: References: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: "'Tschofenig, Hannes'" , 'HIP WG' , 'Hannes Tschofenig' , 'Marcus Brunner' 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 Tue, 10 Jul 2007, Dan Wing wrote: Hi, some comments below after a long and refreshing summer holiday... > Yes, it is clear that not all 100 pages of ICE would apply to HIP. > > The first version of ICE (draft-rosenberg-sipping-ice-00.txt, Feb-2003) was > 34 pages. That is only one page longer than > draft-ietf-hip-nat-traversal-00! In four and a half years of design, ICE is > now 110 pages long and is used on the Internet (Google, MSN, and Yahoo use > ICE for their interactive audio and video features). is it already? I thought that the ICE development efforts have been frozen as the specs have been changing too much, but I may be wrong. Regarding to the specification length, I think it is rather common to have long IETF specifications. I think the goal is not to optimize the length the draft, but to design technically the best NAT traversal protocol for *HIP*, what ever it is and in whatever format. Also, I don't see how changing the format of packets substantially delays the standardization completion time as long as the ICE acts as a blueprint to the protocol. > I expect the HIP working group (or IRTF, as you are proposing) could > re-invent ICE in less than 4.5 years -- afterall, ICE can be used as a > design guide. However, what is the value in spending IETF/IRTF time and > energy re-inventing ICE? Any shortcuts may not work well, whereas ICE was > designed (and works) in all NAT scenarios after significant peer review. > Those additional 70 pages in ICE weren't added because the author's fingers > needed the exercise! There are already ICE libraries available with > reasonable licensing terms. There are people willing to help HIP (and MIP, > and RTSP) get ICE specified. We are not re-inventing ICE. We are mostly debating on the on-wire format for ICE. I said "mostly" because there are some things, such as cryptographic end-host identities, mobility and rendezvous functionality in HIP, that are not handled within the current ICE specifications. Such things remain technically unaddressed in hip-ice-00 draft. > My attempt to improve HIP's NAT traversal are clearly undesired by the > working group. If and when HIP desires a functional, robust, and > incrementally-deployable NAT traversal mechanism, that works on the > Internet, hopefully someone will drop me an email and I can engage with HIP > again. It is not clear to me how the approach in hip-ice-00 is more incrementally deployable because you need to first deploy HIP enabled rendezvous servers. As explained later, the rendezvous server as defined in hip-ice-00 should also have a STUN service running. Also, the "relay" service as defined in ietf-hip-nat-traversal-02 could be supported in rendezvous servers. The draft situation is currently annoying and I would like to proceed forward because there are implementation activities starting on the topic in two projects. To speed-up the process, below is my qualitative, technical comparison on hip-ice-00 and ietf-hip-nat-traversal-02 approaches. But first, I am including my view on ietf-hip-nat-traversal-01 draft since there are at least two persons still supporting the approach. For the time being, I am still oriented towards ietf-hip-nat-traversal-02 approach for the reasons I hope the comparison will explain better. Technical, detailed comments would be highly appreciated! ietf-hip-nat-traversal-01: + Smallest RTT of all of the approaches. + Simplest to implement and natural integration to RVS architecture, with the exception of some hole punching hacks. Most of the "NAT intelligence" is contained at the RVS. + Stateless operation for RVS - Responder privacy is neglected; the RVS reveals automatically the R location. The reason for the lack of privacy are the hole punching hacks in the RVS. - Biggest drawback is fallback to TURN relay with p2p-unfriendly NATs. It is not possible to negotiate this as the base exchange packets are dropped in such case, and relaying all packets would result in some thing similar to ietf-hip-nat-traversal-02. Alternatively, this could be overcome using a separate record in DNS (or DHT) for TURN. Once again, the TURN protocol would require a similar box as the full HIP/ESP-relay in the 02-draft. Still, sounds like a hack and the switch to full relay would have really long waiting delay and RTT. - What about interoperability with an ICE-based approach? - Does not endorse end-host multihoming. hip-ice-00: + A benefit of this approach is that we can reuse ICE implementations, at least partially. - However, you need hacks in ICE like inserting HITs in place of ICE usernames. - ICE specs do not address mobility or multihoming. - It would also seem like ICE is actually in control of the mobility and multihoming rather than HIP. I think this conflicts with the mm-draft. - The approach may be more insecure than nat-traversal-02. Particularly, ICE messages are not protected with signatures of HIP public keys? - ICE security issues section is quite long. Can we avoid introducing the security issues to HIP by using HIP protocol along with its HMACs, signatures, puzzles and return routability mechanisms? - I believe the ICE relay mechanism requires state in the RVS for the Initiator if STUN is used as it is. Please correct if I am wrong. * It is unclear to me how the wide use of STUN/ICE in varying protocols would be helpful for HIP. At least it does not seem to help with ICE-aware middleboxes because ICE was primarly designed for legacy NAT traversal without middleboxes. * I think the proper term for the "rendezvous server" in the draft would be "rendezvous AND stun server" as these separate services are really coupled into a single server. HIP has nothing to do with STUN message forwarding. * This approach is claimed to support incremental deployment. Well, you need to deploy RVS boxes first and the RVS boxes (or relays, as in 02 version of the draft) can also support outer-NAT transport address detection. ietf-hip-nat-traversal-02: + + Reuses the HIP TLV format which has smaller space requirements as it is a binary format. + I think this approach has less RTT than ICE draft. Better user experience and less packets congesting the network. - Requires reimplementing ICE in HIP implementations (but reuses most of the existing base exchange / UPDATE extensions). * Does not mandate extra STUN servers. The less dependencies to middleboxes, the less we have extra points for possible failure. * HIP requires to deploy new RVS boxes anyway; why not embed also the NAT relay ability to them? * The claim on the mailing list was that standardizing this would take more time. I partially disagree because the draft follows ICE design. * The major functional difference to ICE is that there is no controller; the end-hosts can end-up with asymmetric paths to each other. However, it is possible to introduce this feature if somebody convinces me in technical detail that this is really necessary for *HIP*. -- 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 Fri Aug 10 12:57:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJXnt-00070U-05; Fri, 10 Aug 2007 12:57:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJXns-00070H-01 for hipsec@ietf.org; Fri, 10 Aug 2007 12:57:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJXnr-0008LM-Ls for hipsec@ietf.org; Fri, 10 Aug 2007 12:57:35 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IJXnq-0004qS-0I; Fri, 10 Aug 2007 12:57:34 -0400 In-Reply-To: References: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <270BF680-7DD1-4388-9B8F-1664B714BD38@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: AW: [Hipsec] Rebuilding ICE Date: Fri, 10 Aug 2007 12:57:32 -0400 To: Miika Komu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: HIP WG , Hannes Tschofenig , Hannes Tschofenig , Marcus Brunner 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 10-Aug-07, at 04:25 , Miika Komu wrote: > * The major functional difference to ICE is that there is no > controller; > the end-hosts can end-up with asymmetric paths to each other. > However, > it is possible to introduce this feature if somebody convinces me in > technical detail that this is really necessary for *HIP*. Another advantage of the Controller concept is that it provides a form a "future-proofing" for ICE. Can you describe how future-proofing working in ietf-hip-nat- traversal-02? On a related topic: A difference between ICE-for-SIP and the use of ICE ideas for HIP is that the former carries traffic of different types in different streams, while the latter carries them in one steam. So if one kind of traffic wants a high- bandwidth stream but is willing to tolerate high delay, but another kind of traffic wants a low delay but is willing to tolerate low-bandwidth, then in ICE-for-SIP, these two different traffic types can take different paths. However, I believe both ICE-for-HIP proposals force all the traffic exchanged over a HIP association to take the same path. Am I correct? Is there some way to solve this problem? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 10 16:17:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaup-0001gR-S5; Fri, 10 Aug 2007 16:16:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJauo-0001gL-PN for hipsec@ietf.org; Fri, 10 Aug 2007 16:16:58 -0400 Received: from mta-2.ms.rz.rwth-aachen.de ([134.130.7.73]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJaun-00052B-LE for hipsec@ietf.org; Fri, 10 Aug 2007 16:16:58 -0400 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JMK00FY3QVP8U00@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Fri, 10 Aug 2007 22:14:13 +0200 (CEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 10 Aug 2007 22:14:12 +0200 Received: from [192.168.2.100] (p4FD253A7.dip.t-dialin.net [79.210.83.167]) by relay.rwth-aachen.de (8.13.7/8.13.3/1) with ESMTP id l7AKECXj003895 for ; Fri, 10 Aug 2007 22:14:12 +0200 (MEST) Date: Fri, 10 Aug 2007 22:13:53 +0200 From: Tobias Heer Subject: Re: [Hipsec] Security issue for middlebox authentication? In-reply-to: <9B3AB96F-EC25-44A8-9B4E-0FA942B41F69@nomadiclab.com> To: HIP WG Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) X-IronPort-AV: E=Sophos;i="4.19,245,1183327200"; d="p7s'?scan'208,217";a="15169622" References: <358D6D87-48E4-4CCF-8F7E-84BFBA5FF245@cs.rwth-aachen.de> <9B3AB96F-EC25-44A8-9B4E-0FA942B41F69@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 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: , Content-Type: multipart/mixed; boundary="===============1519756308==" Errors-To: hipsec-bounces@lists.ietf.org --===============1519756308== Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-163719772; protocol="application/pkcs7-signature" --Apple-Mail-14-163719772 Content-Type: multipart/alternative; boundary=Apple-Mail-13-163719709 --Apple-Mail-13-163719709 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Pekka, I'll write a short draft about it and send it to the list ASAP. Cheers Tobias Am 10.08.2007 um 08:23 schrieb Pekka Nikander: > Hi Tobias, > >> In order to illustrate the issue, let me construct a small example: >> Assume we have a middlebox that checks HIP HIs in order to =20 >> restrict traffic passing through the box (something like a HIP =20 >> firewall, etc.). Assume the legitimate holder of HIT X establishes =20= >> a HIP association with the legitimate holder of HIT Y at some =20 >> point in time and an attacker M overhears the base exchange and =20 >> records it (it is not required that the middlebox is on the =20 >> communication path at that time). >> >> At some later point in time (maybe even just milliseconds later) M =20= >> collaborates with another attacker N. M and N replay the very same =20= >> BEX with the middlebox on the communication path. The middlebox =20 >> has no way to distinguish M from X and N from Y as it can only =20 >> overhear the BEX passively and does not participate in the =20 >> authentication process. If M and N have agreed on a shared secret =20 >> beforehand, they can make ESP traffic traverse the middlebox by =20 >> using the SPIs that X and Y negotiated in the original BEX. This =20 >> is problematic in all cases where the middlebox really needs to =20 >> know who is communicating across it (think of logging, accounting =20 >> for traffic volume, ....). > > As far as I can see, that is correct. However, ... > >> A solution for fixing this problem could be allowing middleboxes =20 >> adding nonces (like the ECHO_REQUEST, ECHO_RESPONSE mechanism) to =20 >> the unsigned part of the R1 and I2 messages. > > ... that's allowed already, isn't it? > >> The initiator or responder includes this additional nonce in the =20 >> signed part of the I2 or R2, respectively. > > So this is what is missing: requiring the recipient of an unsigned =20 > ECHO_REQUEST to include a corresponding ECHO_RESPONSE to the =20 > *signed* part of the reply message? Well, that has the obvious =20 > drawback that the middle box won't be able to delete the =20 > ECHO_RESPONSE from the reply, but I cannot see any other bad effects.=0E= > >> This allows the middlebox to verify the signatures and the =20 >> presence of its nonces before allowing ESP traffic to pass =20 >> through. A problem here might be the number of middleboxes that =20 >> can add nonces to the packet. If too many middleboxes insist to =20 >> add nonces, this might exceed the maximum packet size for a HIP =20 >> packet. However, one shouldn't expect too many middleboxes on the =20 >> path. > > I agree. > > To me what you suggest seems like a fairly simple new extension, =20 > probably worthy a new parameter with the CRITICAL bit set. > Care to write a draft? > > --Pekka -- =20 Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group RWTH Aachen University, Germany http://ds.cs.rwth-aachen.de/members/heer --Apple-Mail-13-163719709 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Pekka,

I'll write a short draft = about it and send it to the list ASAP.

Cheers=A0

Tobias

Am 10.08.2007 um 08:23 schrieb Pekka Nikander:

Hi Tobias,

In order = to illustrate the issue, let me construct a small example:
Assume we have a middlebox that checks HIP HIs in = order to restrict traffic passing through the box (something like a HIP = firewall, etc.). Assume the legitimate holder of HIT X establishes a HIP = association with the legitimate holder of HIT Y at some point in time = and an attacker M overhears the base exchange and records it (it is not = required that the middlebox is on the communication path at that = time).

At some later point in time (maybe even just = milliseconds later) M collaborates with another attacker N. M and N = replay the very same BEX with the middlebox on the communication path. = The middlebox has no way to distinguish M from X and N from Y as it can = only overhear the BEX passively and does not participate in the = authentication process. If M and N have agreed on a shared secret = beforehand, they can make ESP traffic traverse the middlebox by using = the SPIs that X and Y negotiated in the original BEX. This is = problematic in all cases where the middlebox really needs to know who is = communicating across it (think of logging, accounting for traffic = volume, ....).

As far as I can see, that is = correct.=A0 However, = ...

=
A solution for fixing this = problem could be allowing middleboxes adding nonces (like the = ECHO_REQUEST, ECHO_RESPONSE mechanism) to the unsigned part of the R1 = and I2 messages.

... that's allowed already, = isn't it?

=
The initiator or responder = includes this additional nonce in the signed part of the I2 or R2, = respectively.

So this is what is missing: = requiring the recipient of an unsigned ECHO_REQUEST to include a = corresponding ECHO_RESPONSE to the *signed* part of the reply = message?=A0 Well, that has = the obvious drawback that the middle box won't be able to delete the = ECHO_RESPONSE from the reply, but I cannot see any other bad = effects.=0E

=
This allows the middlebox = to verify the signatures and the presence of its nonces before allowing = ESP traffic to pass through. A problem here might be the number of = middleboxes that can add nonces to the packet. If too many middleboxes = insist to add nonces, this might exceed the maximum packet size for a = HIP packet. However, one shouldn't expect too many middleboxes on the = path.
I agree.

To me = what you suggest seems like a fairly simple new extension, probably = worthy a new parameter with the CRITICAL bit set.
Care to write a draft?

--Pekka
=




--=A0=A0
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group=A0
RWTH Aachen University, Germany




 =

= --Apple-Mail-13-163719709-- --Apple-Mail-14-163719772 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQjCCAvsw ggJkoAMCAQICEC1IEZFFsMbqCTfVL3CGGP8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDcwNjA2NDQ0MloXDTA4MDcwNTA2NDQ0 MlowXTENMAsGA1UEBBMESGVlcjEPMA0GA1UEKhMGVG9iaWFzMRQwEgYDVQQDEwtUb2JpYXMgSGVl cjElMCMGCSqGSIb3DQEJARYWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMw9OUSRfF10zWkVrIsXsjCC8hsCRqg7NLKWYPr1M7CfJyk/0B14o8Eu PK1qUfjl1w/E5rlHIuC3rbok9tV2hHsWqPV9+tAAr4g5QJVNrou9BCD7vHPuCMJ/7WTWMcEewmS2 +U0762iVFK/bLSKwPvaaQWQV1ULUy9zJaLPHQQIAVooBQSypQy+wtxJ3PIn6nfQQnE8hc+hhz5gd 8jLoGozYz0Xv75W4YSYRjH+/R+JLS60do+V2Si1BUaOjQPS+PBSI3uNmWQQCJOb/3LBFDiUBNWe5 PoVe+HiHZi+L4s0wimzu9O/y7IUme6U5kWQTcMYdVTqxkHDk/TbcAjniyE0CAwEAAaMzMDEwIQYD VR0RBBowGIEWaGVlckBjcy5yd3RoLWFhY2hlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BQUAA4GBAD+gsUZ2GBKOG8XHPo8vGSBn85ucmwhiY7CHF+B9EvLKX1QebGCg7TooQLvJOighEUCt d5L59l4kjM6u3PrwcHlUkDeImHW3LP2bOvkXhmpYKTLz1QxlnV3WtyydO0JvNQz9pLSI2DAwuPx1 8E7q/XdJ5IWg6J1acNpiNhMuXOrhMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZI hvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEz MDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Ia dr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1Ro YXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRow GAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9l TzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAtSBGRRbDG6gk31S9whhj/MAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDgxMDIwMTM1M1owIwYJKoZIhvcNAQkEMRYEFK+ididVfK+G lmHRy5G5sgccLKd2MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY/zCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQLUgRkUWwxuoJN9UvcIYY /zANBgkqhkiG9w0BAQEFAASCAQBltAdvFNVmT/2aKqDLp6Ewuy2v9BMALQxrMJc3UVgHGa1gVFJ/ 4gOcehEjyXegQOp8JhgkzfDoW6XSrv0dVomzlNPqmF72+Q99o+4VCSbYTsYnw78D+bXai5uZDwgY bPs0D2rrhjwPnI+qjM0ewgvYuRhaz5r90g1fexUx94TjVy4vap42tdekLUV0Ca8J1zkkOkqPAAKq MLipdSEnoWX/iuxyIgbu7Rlhl5Oba+r9advjAPKFDKgxF8vHu9rBn1yPieEQgar9MLPFTz6pFcoH sexB/MIc/pTbcjrHQm0R5OJzW+cj24G3So6aTbuXKp0etFkrRqsoJDnirB84rx8CAAAAAAAA --Apple-Mail-14-163719772-- --===============1519756308== 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 --===============1519756308==-- From hipsec-bounces@lists.ietf.org Mon Aug 13 06:50:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKXUx-0003Hx-IM; Mon, 13 Aug 2007 06:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKXUw-0003Hs-Oa for hipsec@ietf.org; Mon, 13 Aug 2007 06:50:10 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKXUv-0001MF-4m for hipsec@ietf.org; Mon, 13 Aug 2007 06:50:10 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 61F0E2D98; Mon, 13 Aug 2007 13:50:08 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070504 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 2A3762DA7; Mon, 13 Aug 2007 13:50:06 +0300 (EEST) Date: Mon, 13 Aug 2007 13:50:05 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Philip Matthews Subject: Re: AW: [Hipsec] Rebuilding ICE In-Reply-To: <270BF680-7DD1-4388-9B8F-1664B714BD38@magma.ca> Message-ID: References: <060a01c7c34c$47d4aec0$c3f0200a@amer.cisco.com> <270BF680-7DD1-4388-9B8F-1664B714BD38@magma.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: HIP WG , Hannes Tschofenig , Hannes Tschofenig , Marcus Brunner 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 Fri, 10 Aug 2007, Philip Matthews wrote: > > On 10-Aug-07, at 04:25 , Miika Komu wrote: > >> * The major functional difference to ICE is that there is no controller; >> the end-hosts can end-up with asymmetric paths to each other. However, >> it is possible to introduce this feature if somebody convinces me in >> technical detail that this is really necessary for *HIP*. > > Another advantage of the Controller concept is that it provides a form a > "future-proofing" for ICE. > Can you describe how future-proofing working in ietf-hip-nat-traversal-02? Based on section 14 of the ICE draft, I think the main purpose of the controller remains the same even for future proofing, that is, to enforce same address pair at the "controlling" host. If a host is running ICEv2 (capable of selecting more optimal address pair than ICEv1) and its peer is running ICEv1, and when the ICEv2 host happens to be the controller, it can enforce a better address pair without the pressure to upgrade all hosts to ICEv2. However, it seems like that it will be based on luck that the ICEv2 host will be the controller in the communications. According to section 5.2 of the ICE draft, the ICE version number plays no role in selection of the controller role. Please correct me if I am wrong. Thus, it seems to me that main component for future-proofing for ICE are the triggered checks. They are also included in ietf-hip-nat-traversal-02. > On a related topic: A difference between ICE-for-SIP and the use of ICE > ideas for HIP is that the former carries traffic of different types in > different streams, while the latter carries them in one steam. So if one > kind of traffic wants a high-bandwidth stream but is willing to tolerate > high delay, but another kind of traffic wants a low delay but is willing > to tolerate low-bandwidth, then in ICE-for-SIP, these two different > traffic types can take different paths. However, I believe both > ICE-for-HIP proposals force all the traffic exchanged over a HIP > association to take the same path. Am I correct? Is there some way to > solve this problem? draft-tschofenig-hip-ice does not really talk about this, but I guess it is assumed that a single, bi-directional UDP tunnel is set-up as a result of ICE connectivity tests. The purpose for the tunnel is the same also for ietf-hip-nat-traversal-02. However, the difference is that you may end-up with two uni-directional tunnels due to lack of the controller role. As a result, you end up with one or two streams. I consider the primary goal of UDP tunnels is to get HIP and ESP traffic through. A secondary goal is to set-up multiple tunnels with different QoS characteristics. The secondary goal requires HIP-aware applications as described in: http://www2.tools.ietf.org/html/draft-pierrel-hip-sima-00 (or maybe it could described here as well: http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt ) I think draft-tschofenig-hip-ice can accomplish multiple UDP tunnels using the "foundation" mechanism. This foundation concept is currently excluded from ietf-hip-nat-traversal-02 because the focus is not on QoS and I think it can be done using the mobility extensions described in section 3.7 of the draft. I would personally concentrate on the QoS issues in a different draft. -- 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 Wed Aug 22 07:33:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INoT2-0003y8-JR; Wed, 22 Aug 2007 07:33:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INoT1-0003y3-HP for hipsec@ietf.org; Wed, 22 Aug 2007 07:33:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INoT1-0006ur-4W for hipsec@ietf.org; Wed, 22 Aug 2007 07:33:43 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 363F9211A0; Wed, 22 Aug 2007 13:33:42 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-db-46cc1f151e7f Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EDA7D2115E; Wed, 22 Aug 2007 13:33:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 13:33:41 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 13:33:41 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1FD9D249B; Wed, 22 Aug 2007 14:33:41 +0300 (EEST) Message-ID: <46CC1F15.6050109@ericsson.com> Date: Wed, 22 Aug 2007 14:33:41 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2007 11:33:41.0553 (UTC) FILETIME=[4A50BA10:01C7E4B0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Hipsec] API draft 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 Folks, a few months ago, we had some discussions about the API draft. Miika contacted the APPS area folks and got some feedback from them. With that feedback, he has generated a new revision of the draft: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt The discussions with the APPS area folks are documented at: http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html http://www1.ietf.org/mail-archive/web/discuss/current/msg00755.html I would like people to have a look at this draft and send comments to the list. Note that our plan was, and still is, to have this draft ready for publication request by the end of the year. There were also discussions on producing a more long-term API at some point... but that may fall under the scope of the RG instead. Cheers, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 24 12:48:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOcKk-0004pg-20; Fri, 24 Aug 2007 12:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOcKj-0004pb-6I for hipsec@ietf.org; Fri, 24 Aug 2007 12:48:29 -0400 Received: from smtp-3.hut.fi ([130.233.228.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOcKh-0006dQ-3E for hipsec@ietf.org; Fri, 24 Aug 2007 12:48:29 -0400 Received: from localhost (putosiko.hut.fi [130.233.228.114]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id l7OGmQXD013617 for ; Fri, 24 Aug 2007 19:48:26 +0300 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new, port 10024) with LMTP id 15337-50-3 for ; Fri, 24 Aug 2007 19:48:25 +0300 (EEST) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id l7OGlj2j013473 for ; Fri, 24 Aug 2007 19:47:46 +0300 Date: Fri, 24 Aug 2007 19:47:45 +0300 (EEST) From: Lauri Silvennoinen To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Subject: [Hipsec] HIP-ICE 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 Hi all, I'm trying to wake up the HIP-ICE discussion again. I have studied both the draft-ietf-hip-nat-traversal-01 and draft-tschofenig-hip-ice-00, and tried to figure out how HIP NAT traversal works according to the drafts. Based on these drafts, discussion with Miika and the figure and comments Dan Wing previously posted on this list, I sketched the following diagrams: http://users.tkk.fi/~ljsilven/hip/comparison.html We have the whole HIP life span illustrated in the figures. Host R is mobile. The data flow in the Komu, Schuetz, Stiemerling figure is pretty straightforward and is approved by Miika. However, the Tschofenig, Wing figure is just the best I came up with. Could somebody clarify how the packets should flow according to draft-tschofenig-hip-ice-00 or is the diagram ok as such. In the figures, both of the hosts reside behind NATs and thus have their own Rendezvous Servers. We have the following basic phases in both of the figures: 1) registration to HIP relay / RVS / TURN 2) DNS query 3) base exchange 4) ICE connectivity tests 5) ESP data flow 6) Handover, R moves 7) Closing of the HIP association Also, because it was unclear to me what kind of middlebox is the RVS you're talking about in draft-tschofenig-hip-ice-00, I sketched both a STUN/TURN server and an RVS+HIP relay in the figure. Observe that this approach still needs a new registration type in the RVS, since the basic RVS is only capable of relaying the I1 packet. Or alternatively we can combine the RVS and STUN/TURN functionalities into a single middlebox, as suggested in draft-tschofenig-hip-ice-00: "In Figure 1 the STUN server is co-located with the HIP rendezvous servers for editorial reasons. From a solution point of view this is, however, not necessary." Comments? Lauri > Date: Tue, 05 Jun 2007 10:13:16 -0700 > From: Dan Wing > > Offer NAT STUN server rendezvous server Answerer > | | | | | > 1 |---------------->| | | > 2 |<----------------| | | > 3 |-------------------------------->| | > 4 | | | |------------------->| > 5 | X<=============================================| > 6 | | | |<-------------------| > 7 |<--------------------------------| | > 8 |=====================================================>| > 9 |<=====================================================| > 10 |<=====================================================| > 11 |=====================================================>| > > 1. gather candidates (send STUN binding request) > 2. receive STUN binding response > 3. send candidates to intended peer, via rendezvous server > 4. message continues from rendezvous server to intended peer > 5. intended peer does a connectivity check, which is dropped by > the NAT (let's pretend the NAT does some filtering, otherwise > this message flow wouldn't be very interesting). > 6. intended peer isn't behind a NAT, so doesn't bother with > the candidate gathering; if it was behind a NAT, it would do > its own candidate gathering. This isn't shown in this message > flow to keep it a little simplier. Message 6 shows the > intended peer replying with its candidate address (which is > its own IP address and UDP port). > 7. Answer is relayed, via the rendezvous server, to the offerer. > The offerer now has the answerer's candidate IP addresses > and candidate UDP ports. > 8. Offerer sends a STUN Binding Request packet directly to the > answerer's candidate IP address. This is received by the > answerer (the intended peer) > 9. Answerer sends STUN Binding Response. when offerer receives > this message, the offerer knows -- without any doubt -- that > it is communicating to the correct host (because that correct > host proved it because it created a valid SHA1 HMAC of the > message). It can now communicate with it -- in HIP's case, > initiate your HIP exchange with the peer and initiate IPsec > ESP. > 10. A so-called "triggered check" occurs, (due to receiving > message 8), which causes the answerer to immediately send > a STUN Binding Request to check its connectivity with the > intended peer (the offerer). This is really an accelerated > re-transmit of message 5 (which was dropped by the offerer's > NAT, due to his NAT's filtering rules). > 11. STUN response is sent, and received by the answerer. It > now knows it has bi-directional communication with the > offerer. > Date: Sat, 23 Jun 2007 10:31:39 -0700 [direct link] > From: Dan Wing > > The important difference with draft-tschofenig-hip-ice isn't the > encoding on-the-wire. > > Rather, the important difference is performing ICE. Those steps > are: > > Initiator: > * gather candidate addresses > * send candidate addresses to remote peer (terminator) > via a rendezvous protocol (HIP, in this case; SIP in > the traditional case of ICE) > > Terminator: > * gather its own candidate addresses > * perform connectivity checks with the remote peer > (initiator) to find a functional path to the initiator > * send candidate addresses to remote peer (initiator) via > a rendezvous protocol (HIP) > > Initiator: > * perform connectivity checks with the remote peer > (terminator) > * prioritize successful checks and determine which path > is preferred (for example: avoid UDP encapsulation, > take a path over only HIP-aware NATs if that's desirable, > avoid NATs and take direct path, etc.). This choice is > communicated to the remote peer (terminator), so it can > make the same choice so bi-directional traffic can be > assured (which is necessary to keep all the NATs open). _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Aug 25 09:43:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOvvE-00005E-HI; Sat, 25 Aug 2007 09:43:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOvvD-000058-8X for hipsec@ietf.org; Sat, 25 Aug 2007 09:43:27 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOvvB-0005Te-1g for hipsec@ietf.org; Sat, 25 Aug 2007 09:43:27 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 4709F30AC; Sat, 25 Aug 2007 16:43:24 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 4D1FC30AF; Sat, 25 Aug 2007 16:43:14 +0300 (EEST) Date: Sat, 25 Aug 2007 16:43:14 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Lauri Silvennoinen Subject: Re: [Hipsec] HIP-ICE In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: hipsec@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 On Fri, 24 Aug 2007, Lauri Silvennoinen wrote: > Comments? Some thoughts below based on your analysis. Please correct if I am wrong: * STUN/TURN/ICE does not define a forwarding mechanism that exchanges transport addresses for hosts (reliably). Therefore, ICE relies on external mechanisms to exchange the initial transport addresses. * As a consequence of previous point, draft-tschofenig-hip-ice-00 relies on a HIP base exchange to communicate the initial transport addresses. (Also, the I1 packet is NOT the nicest place to insert transport addresses) * The currently defined RVS forwards only I1 packets. This means that we need new relaying mechanism. * There is no specified format for transport addresses in base, mm or rvs drafts for transport. A new format is needed. It seems to me that the coarse-grained approach in draft-tschofenig-hip-ice-00 converges towards something like draft-ietf-hip-nat-traversal-02 when you think about the details of how to use ICE with HIP. I came up with one additional point on "next generation" NAT middleboxes. If we want to make a NAT box HIP aware, does it make sense that the box is required to parse both STUN and HIP messages? -- 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 Mon Aug 27 08:40:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPdt3-0001vk-IM; Mon, 27 Aug 2007 08:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPdt2-0001ve-CW for hipsec@ietf.org; Mon, 27 Aug 2007 08:40:08 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPdt0-0007e9-82 for hipsec@ietf.org; Mon, 27 Aug 2007 08:40:08 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7RCdKBr025340 for ; Mon, 27 Aug 2007 15:40:04 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 15:39:52 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 15:39:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Aug 2007 15:39:52 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HIP: A question related to Base Exchange draft Thread-Index: AcfmV7u8/0tVkVVsQsCCz/4wHTEZMgCSyF0g From: To: X-OriginalArrivalTime: 27 Aug 2007 12:39:52.0470 (UTC) FILETIME=[5D3B5360:01C7E8A7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Subject: [Hipsec] HIP: A question related to Base Exchange draft 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: , Content-Type: multipart/mixed; boundary="===============1826014232==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1826014232== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E8A7.5D37BCB6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E8A7.5D37BCB6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My name is Juha Korhonen and I am working at Nokia Research Center with HIP implementation issues for Symbian. I have been reading the draft document (http://tools.ietf.org/html/draft-ietf-hip-base-08) and the following details are unclear for me: Here are them: > 1. The state diagram at page 29 states that=20 >=20 > - When a peer is CLOSED or CLOSING and it has a datagram to send it > acts as a Iniator of the HIP connection and sends I1 packet. After > this it moves to state I1-SENT. >=20 > 2. On the contrary the description of the states' behaviour (first > trigger in CLOSED/CLOSING on page 26 and 27) says: >=20 > - When there is data to send and a another incarnation of hip > association is needed a peer sends I1 packet and stays in state > CLOSING or CLOSED. This is not exactly the same what the State diagram > shows: "a peer moves to state I1-SENT". >=20 >=20 > In my understanding alternative 1 could be the wanted behaviour > according to the processing of packets: peer moves to I1-SENT or peer > stays at CLOSING/CLOSED. Also maybe the thing that, the incarnation of > Security Associations refers to rekeying and rekeying needs new Base > Exchange supports option 1.=20 >=20 There is perhaps something I do not understand, but this is how I see it. Can someone clarify how it works? > Brgds, >=20 > Juha ------_=_NextPart_001_01C7E8A7.5D37BCB6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HIP: A question related to Base Exchange draft

Hi,

My name is Juha = Korhonen and I am working at Nokia Research Center with HIP = implementation issues for Symbian. I have been reading the draft = document (http://tools.ietf.org/html/draft-ietf-hip-base-08) and the = following details are unclear for me:


    Here are them:

    1. The state diagram = at page 29 states that

    - When a peer is = CLOSED or CLOSING and it has a datagram to send it acts as a Iniator of = the HIP connection and sends I1 packet. After this it moves to state = I1-SENT.

    2. On the contrary = the description of the states' behaviour (first trigger in = CLOSED/CLOSING on page 26 and 27) says:

    - When there is data = to send and a another incarnation of hip association is needed a peer = sends I1 packet and stays in state CLOSING or CLOSED. This is not = exactly the same what the State diagram shows: "a peer moves to = state I1-SENT".


    In my understanding = alternative 1 could be the wanted behaviour according to the processing = of packets: peer moves to I1-SENT or peer stays at CLOSING/CLOSED. Also = maybe = the thing that, the = incarnation of Security Associations refers to rekeying and rekeying = needs new Base Exchange supports option 1.

    There is perhaps = something I do not understand, but this is how I see it. Can someone = clarify how it works?


    Brgds,

    Juha

------_=_NextPart_001_01C7E8A7.5D37BCB6-- --===============1826014232== 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 --===============1826014232==-- From hipsec-bounces@lists.ietf.org Mon Aug 27 09:29:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeey-00056i-OO; Mon, 27 Aug 2007 09:29:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeew-00056C-NC for hipsec@ietf.org; Mon, 27 Aug 2007 09:29:38 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPeew-0003gB-22 for hipsec@ietf.org; Mon, 27 Aug 2007 09:29:38 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1042920750; Mon, 27 Aug 2007 15:29:37 +0200 (CEST) X-AuditID: c1b4fb3c-b0e80bb0000007e1-70-46d2d1c000d4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ECAD120742; Mon, 27 Aug 2007 15:29:36 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 15:29:36 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 15:29:36 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 54C0F2336; Mon, 27 Aug 2007 16:29:36 +0300 (EEST) Message-ID: <46D2D1BF.5000709@ericsson.com> Date: Mon, 27 Aug 2007 16:29:35 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 13:29:36.0456 (UTC) FILETIME=[4FD37480:01C7E8AE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Hipsec] NAT Traversal in HIP 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 Folks, NAT traversal in HIP in one of our chartered items and, so, we need to make some progress. At this point, we have three different proposals: http://www.watersprings.org/pub/id/draft-ietf-hip-nat-traversal-01.txt http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt The first one uses a simple algorithm that does not probably work in some network topologies. The second one uses the ICE methodology so that it can work in most network topologies. Instead of using STUN to perform connectivity checks and keep alives, it uses HIP messages. The third one also uses the ICE methodology. Additionally, it uses STUN to perform connectivity checks and keep alives. We have to make a few decisions: 1) Shall we use the ICE methodology or not? Simplifying the ICE methodology would result in a simpler protocol that does not work in certain network topologies. The fact that the NAT traversal mechanism we come up with works in most situations seems to be an important property. Therefore, it seems that using the ICE methodology would be the way to go. In any case, feel free to discuss this point on this list? The following draft is an example on how to apply ICE to a protocol: http://www.ietf.org/internet-drafts/draft-jennings-p2psip-asp-00.txt 2) Shall we use STUN to gather addresses, and perform connectivity checks and keep alives or shall we use HIP messages for that? Using STUN has the advantage that HIP could use all the installed base of STUN servers, which may have been deployed for other purposes (e.g., VoIP). However, we would need to analyze the security implications of using STUN in the HIP architecture, which has been designed with security in mind from the start. Some folks claimed that, architecturally, it made more sense to use HIP than STUN. We need to have further discussions on these issues. Comments are welcome. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Aug 27 13:43:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPicJ-0001zv-N3; Mon, 27 Aug 2007 13:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPicI-0001zq-7o for hipsec@ietf.org; Mon, 27 Aug 2007 13:43:10 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPicH-0007u9-0E for hipsec@ietf.org; Mon, 27 Aug 2007 13:43:10 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IPic3-0000ir-1D; Mon, 27 Aug 2007 13:42:55 -0400 In-Reply-To: <46D2D1BF.5000709@ericsson.com> References: <46D2D1BF.5000709@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0071D4A4-1311-4C61-823C-AABE15FF72DD@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] NAT Traversal in HIP Date: Mon, 27 Aug 2007 13:43:06 -0400 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: HIP 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 27-Aug-07, at 09:29 , Gonzalo Camarillo wrote: > 1) Shall we use the ICE methodology or not? Simplifying the ICE > methodology would result in a simpler protocol that does not work > in certain network topologies. The fact that the NAT traversal > mechanism we come up with works in most situations seems to be an > important property. Therefore, it seems that using the ICE > methodology would be the way to go. In any case, feel free to > discuss this point on this list? I strongly think that the ICE methodology is the right way to go for HIP. I understand that some people are interested in a short-term solution so that they can do experiments, and I don't have any problems with that. However,I think that, if HIP is to be successful, it must have a solid NAT Traversal solution, so I strongly think that the long- term solution should be based on ICE. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Aug 28 03:47:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvnO-0008Q3-Ax; Tue, 28 Aug 2007 03:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvnM-0008HX-7F for hipsec@ietf.org; Tue, 28 Aug 2007 03:47:28 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPvnK-0003Jl-J6 for hipsec@ietf.org; Tue, 28 Aug 2007 03:47:28 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7S7l7rE031564; Tue, 28 Aug 2007 10:47:23 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:47:07 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:47:04 +0300 Received: from [203.178.159.212] (essapo-nirac253221.europe.nokia.com [10.162.253.221]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7S7l197032696; Tue, 28 Aug 2007 10:47:02 +0300 In-Reply-To: <46D2D1BF.5000709@ericsson.com> References: <46D2D1BF.5000709@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <397F4F9D-62A5-419C-8854-8450C12851CD@nokia.com> From: Lars Eggert Subject: Re: [Hipsec] NAT Traversal in HIP Date: Tue, 28 Aug 2007 16:46:41 +0900 To: ext Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 28 Aug 2007 07:47:04.0824 (UTC) FILETIME=[A0830780:01C7E947] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: HIP 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: , Content-Type: multipart/mixed; boundary="===============1631424852==" Errors-To: hipsec-bounces@lists.ietf.org --===============1631424852== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-54--473395506; protocol="application/pkcs7-signature" --Apple-Mail-54--473395506 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-8-27, at 22:29, ext Gonzalo Camarillo wrote: > 1) Shall we use the ICE methodology or not? Simplifying the ICE > methodology would result in a simpler protocol that does not work > in certain network topologies. The fact that the NAT traversal > mechanism we come up with works in most situations seems to be an > important property. Therefore, it seems that using the ICE > methodology would be the way to go. In any case, feel free to > discuss this point on this list? ICE is currently with the IESG. One issue that came up is the pacing of its connectivity checks, because they can introduce quite a bit of traffic and indiscriminately spraying UDP packets around is obviously problematic. Basically, ICE needs to pace and congestion control its connectivity checks for two reasons. (1) In order to avoid trampling over concurrent traffic, and (2) because there is the potential for self-interference: If ICE connectivity probes are sent too aggressively and end up being dropped, ICE will erroneously eliminate candidates, because it thinks that the loss is due to a middlebox rather than congestion. The flipside is that sending connectivity checks at a lower rate will take longer, which is undesirable. In any event, the latest ICE draft tries to sidestep this issue by shaping the connectivity probes to a rate that tries to be identical to the RTP traffic that will follow the ICE exchange. So ICE may still not be too friendly to concurrent traffic, but at least it won't be more unfriendly than the RTP that follows. By now you're probably guessing what I'm getting at: If ICE is used for HIP, that rate shaping can't take place, because ICE has no idea what traffic will be carried inside HIP. (Even HIP has no clue about that at the time of the base exchange.) So a critical mechanism will need to be defined. Note: I'm _not_ arguing against using ICE with HIP. All I'm saying is that there is a bit of work that needs to be done before it safely can. Lars --Apple-Mail-54--473395506 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA4MjgwNzQ2NDJaMCMGCSqGSIb3DQEJBDEWBBRSR73t1pz2DC/g zBw2zIR6aJAt7zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAUNhvboVRWSmucg4lhOpau838up/4vH7kghAP3eRCjIcWcwuMF1Yo N/ouiezXhOrVSEhl9iZOBOtwCef6/wSfVM1wk/bVRzk6sHLEV1ph0NJhBJAmW5QpU/UyenmWVzkz rCNVlpHqqiXiKJDoieQ4uwC/Izp8FwiKWgluDdVVu/QzROXOrwu1EEILZcCYGftgEW28XLlP2GtF YjIiY4mscB0GzMpRleTNcHGi6ABzwbnheaBgAYYeSgfTc3DtJyfDxSfJJh7JlMn41A1OaQ2XiJYi pW9FIdnuoy/NIfknZgp3Qvo3pJohocjSNNGEhqgNK/1qzy1C7OHeBTm1jqlWlgAAAAAAAA== --Apple-Mail-54--473395506-- --===============1631424852== 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 --===============1631424852==-- From hipsec-bounces@lists.ietf.org Tue Aug 28 03:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvsU-0003Kt-Es; Tue, 28 Aug 2007 03:52:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvsT-0003Ko-CX for hipsec@ietf.org; Tue, 28 Aug 2007 03:52:45 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvsS-0000KR-RD for hipsec@ietf.org; Tue, 28 Aug 2007 03:52:45 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C9FC1212D29; Tue, 28 Aug 2007 10:52:42 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9289D212C7F; Tue, 28 Aug 2007 10:52:42 +0300 (EEST) In-Reply-To: <46D2D1BF.5000709@ericsson.com> References: <46D2D1BF.5000709@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0840FACD-521A-4DFF-AF6E-05D99A255BDD@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] NAT Traversal in HIP Date: Tue, 28 Aug 2007 10:52:32 +0300 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: HIP 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 Gonzalo, all, > 1) Shall we use the ICE methodology or not? In the long run, I think we should use ICE *methodology*. On the other hand, I think it would be *good* for people to experiment with lesser functionality very soon, i.e., now. But the latter can be done by the experimenters agreeing on some interim draft and working from that. The WG doesn't need to be directly involved. > 2) Shall we use STUN to gather addresses, and perform connectivity > checks and keep alives or shall we use HIP messages for that? From an architectural point of view, my *personal* opinion is that we should work very hard to make sure that HIP *can* work (even through NATs) without any non-HIP infrastructure. HIP is designed to be a layer 3.5 protocol. It should work without any reliance on protocols above, just like IP and ICMP work without any protocols above. Consequently, my current, perhaps flawed understanding of the offered design options is that we should primarily use HIP messages and not STUN. Optimisations and optional features are a different case. If it makes HIP to work more optimally in some environments, I cannot see any reason why specific HIP implementations couldn't utilise STUN servers whenever they have access to one, as an optional feature. My EUR 0.02 --Pekka Nikander _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 29 00:51:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQFWY-0006rs-L3; Wed, 29 Aug 2007 00:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQFWX-0006rB-Gg for hipsec@ietf.org; Wed, 29 Aug 2007 00:51:25 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQFWV-000433-Tq for hipsec@ietf.org; Wed, 29 Aug 2007 00:51:25 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 191DF31AB; Wed, 29 Aug 2007 07:51:23 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7302F2E0C; Wed, 29 Aug 2007 07:51:16 +0300 (EEST) Date: Wed, 29 Aug 2007 07:51:16 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] NAT Traversal in HIP In-Reply-To: <0840FACD-521A-4DFF-AF6E-05D99A255BDD@nomadiclab.com> Message-ID: References: <46D2D1BF.5000709@ericsson.com> <0840FACD-521A-4DFF-AF6E-05D99A255BDD@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: HIP 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 Tue, 28 Aug 2007, Pekka Nikander wrote: > Gonzalo, all, > >> 1) Shall we use the ICE methodology or not? > > In the long run, I think we should use ICE *methodology*. On the other > hand, I think it would be *good* for people to experiment with lesser > functionality very soon, i.e., now. But the latter can be done by the > experimenters agreeing on some interim draft and working from that. > The WG doesn't need to be directly involved. ICE is the state of the art for legacy NAT traversal. On lesser functionality, the draft already addresses this question in section 3.10: http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt 3.10. Communication with HIP Hosts without NAT Traversal Support The UDP encapsulation of HIP and ESP control packets has not been defined in any other IETF document and legacy hosts drop all UDP encapsulated HIP and ESP traffic. Processing of unknown locator types terminates the base exchange or UPDATE. As such, the extensions defined in this document are not completely backwards compatible and require a minimal support in implementations. A minimal implementation MUST provide UDP encapsulation of HIP and ESP packets. In such a case, the minimal NAT traversal implementation MUST silently discard the processing of type 3 locators to allow communication with implementations supporting NAT traversal defined in this document. The minimal implementation MUST support UDP keepalives to refresh state of the NAT(s). Hosts that conform to [I-D.ietf-hip-mm] respond to UPDATE messages containing an ECHO_REQUEST with an UPDATE message containing an ECHO_RESPONSE. This completes the connectivity tests for the host supporting the extensions defined in this document. As long as the implementation supports UDP encapsulation of HIP control packets, this requires no changes. The Relay extensions defined in this document do not work with minimalistic implementations. When there is a Relay between the hosts, both the Initiator and Responder MUST support the extensions defined in this document. The presence of RELAY_TO and RELAY_FROM parameters denotes the precence of a relay. Looking forward for more feedback on this topic. >> 2) Shall we use STUN to gather addresses, and perform connectivity checks >> and keep alives or shall we use HIP messages for that? > > From an architectural point of view, my *personal* opinion is that we > should work very hard to make sure that HIP *can* work (even through > NATs) without any non-HIP infrastructure. HIP is designed to be a layer > 3.5 protocol. It should work without any reliance on protocols above, > just like IP and ICMP work without any protocols above. Consequently, > my current, perhaps flawed understanding of the offered design options > is that we should primarily use HIP messages and not STUN. > > Optimisations and optional features are a different case. If it makes > HIP to work more optimally in some environments, I cannot see any reason > why specific HIP implementations couldn't utilise STUN servers whenever > they have access to one, as an optional feature. Agree. Nothing in the current draft-ietf-hip-nat-traversal-02.txt prevents the use STUN for HIP: * End-host may use STUN to discover the outernmost NAT address and port even though is not redundant. The relay server registration also tells this to end-host. * Both end-hosts AND relays can use STUN servers to allocate ports for ESP relaying. End-host can communicate this address in a LOCATOR parameter to peer and a relay can send this address during registration. -- 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 Wed Aug 29 01:13:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQFrw-0001Nk-8O; Wed, 29 Aug 2007 01:13:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQFrv-0001Lx-0P for hipsec@ietf.org; Wed, 29 Aug 2007 01:13:31 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQFru-00047q-Fm for hipsec@ietf.org; Wed, 29 Aug 2007 01:13:30 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5A9C0324F; Wed, 29 Aug 2007 08:13:29 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id C86DA324D; Wed, 29 Aug 2007 08:13:20 +0300 (EEST) Date: Wed, 29 Aug 2007 08:13:20 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Lars Eggert Subject: Re: [Hipsec] NAT Traversal in HIP In-Reply-To: <397F4F9D-62A5-419C-8854-8450C12851CD@nokia.com> Message-ID: References: <46D2D1BF.5000709@ericsson.com> <397F4F9D-62A5-419C-8854-8450C12851CD@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: HIP 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 Tue, 28 Aug 2007, Lars Eggert wrote: Hi Lars, > Hi, > > On 2007-8-27, at 22:29, ext Gonzalo Camarillo wrote: >> 1) Shall we use the ICE methodology or not? Simplifying the ICE methodology >> would result in a simpler protocol that does not work in certain network >> topologies. The fact that the NAT traversal mechanism we come up with works >> in most situations seems to be an important property. Therefore, it seems >> that using the ICE methodology would be the way to go. In any case, feel >> free to discuss this point on this list? > > ICE is currently with the IESG. One issue that came up is the pacing of its > connectivity checks, because they can introduce quite a bit of traffic and > indiscriminately spraying UDP packets around is obviously problematic. > Basically, ICE needs to pace and congestion control its connectivity checks > for two reasons. (1) In order to avoid trampling over concurrent traffic, and > (2) because there is the potential for self-interference: If ICE connectivity > probes are sent too aggressively and end up being dropped, ICE will > erroneously eliminate candidates, because it thinks that the loss is due to a > middlebox rather than congestion. The flipside is that sending connectivity > checks at a lower rate will take longer, which is undesirable. > > In any event, the latest ICE draft tries to sidestep this issue by shaping > the connectivity probes to a rate that tries to be identical to the RTP > traffic that will follow the ICE exchange. So ICE may still not be too > friendly to concurrent traffic, but at least it won't be more unfriendly than > the RTP that follows. > > By now you're probably guessing what I'm getting at: If ICE is used for HIP, > that rate shaping can't take place, because ICE has no idea what traffic will > be carried inside HIP. (Even HIP has no clue about that at the time of the > base exchange.) So a critical mechanism will need to be defined. > > Note: I'm _not_ arguing against using ICE with HIP. All I'm saying is that > there is a bit of work that needs to be done before it safely can. This issue seems to apply for both of the drafts. Philip told me earlier that this thing was prone to change in ICE which is the reason why draft-ietf-hip-nat-traversal-02 is merely referencing ICE draft on pacing issues. Can you tell or reference more on (1) ? -- 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 Wed Aug 29 01:57:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGYj-0006um-60; Wed, 29 Aug 2007 01:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGYg-0006lT-UM for hipsec@ietf.org; Wed, 29 Aug 2007 01:57:43 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQGYf-0005co-1j for hipsec@ietf.org; Wed, 29 Aug 2007 01:57:42 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7T5v5xW019188; Wed, 29 Aug 2007 08:57:38 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:57:12 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:57:13 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:57:11 +0300 Received: from [203.178.159.212] (essapo-nirac253242.europe.nokia.com [10.162.253.242]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7T5v7q2016249; Wed, 29 Aug 2007 08:57:09 +0300 In-Reply-To: References: <46D2D1BF.5000709@ericsson.com> <397F4F9D-62A5-419C-8854-8450C12851CD@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <6255EA33-8F56-4EB2-BF3B-34C941D3B6A6@nokia.com> From: Lars Eggert Subject: Re: [Hipsec] NAT Traversal in HIP Date: Wed, 29 Aug 2007 14:56:47 +0900 To: ext Miika Komu X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Aug 2007 05:57:11.0898 (UTC) FILETIME=[713C1BA0:01C7EA01] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: HIP 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: , Content-Type: multipart/mixed; boundary="===============0588216361==" Errors-To: hipsec-bounces@lists.ietf.org --===============0588216361== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-72--393589767; protocol="application/pkcs7-signature" --Apple-Mail-72--393589767 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-8-29, at 14:13, ext Miika Komu wrote: > On Tue, 28 Aug 2007, Lars Eggert wrote: >> ICE is currently with the IESG. One issue that came up is the >> pacing of its connectivity checks, because they can introduce >> quite a bit of traffic and indiscriminately spraying UDP packets >> around is obviously problematic. Basically, ICE needs to pace and >> congestion control its connectivity checks for two reasons. (1) In >> order to avoid trampling over concurrent traffic, and (2) because >> there is the potential for self-interference: If ICE connectivity >> probes are sent too aggressively and end up being dropped, ICE >> will erroneously eliminate candidates, because it thinks that the >> loss is due to a middlebox rather than congestion. The flipside is >> that sending connectivity checks at a lower rate will take longer, >> which is undesirable. >> >> In any event, the latest ICE draft tries to sidestep this issue by >> shaping the connectivity probes to a rate that tries to be >> identical to the RTP traffic that will follow the ICE exchange. So >> ICE may still not be too friendly to concurrent traffic, but at >> least it won't be more unfriendly than the RTP that follows. >> >> By now you're probably guessing what I'm getting at: If ICE is >> used for HIP, that rate shaping can't take place, because ICE has >> no idea what traffic will be carried inside HIP. (Even HIP has no >> clue about that at the time of the base exchange.) So a critical >> mechanism will need to be defined. >> >> Note: I'm _not_ arguing against using ICE with HIP. All I'm saying >> is that there is a bit of work that needs to be done before it >> safely can. > > This issue seems to apply for both of the drafts. Yes. > Philip told me earlier that this thing was prone to change in ICE > which is the reason why draft-ietf-hip-nat-traversal-02 is merely > referencing ICE draft on pacing issues. My point was that what the ICE draft currently says on this only works if you use ICE with RTP. (Or, more generally, when ICE knows something about the data traffic it is trying to set up a path for.) > Can you tell or reference more on (1) ? By "(1)" you mean "avoid trampling over concurrent traffic?" That's what RFC2914 (BCP on congestion control principles) is all about. Basically, congestion control in the Internet serves two purposes: avoiding congestion collapse (i.e., having some way to reduce load in the presence of congestion losses) and being somewhat fair to concurrent traffic. You can argue that because ICE is only sending for a short period of time, it cannot and doesn't really need to do much about the former, and I'd probably buy that. I'm on purpose leaving the second part (fairness) pretty undefined, because there is some wiggle room there for what mechanisms would be OK. But the idea is that, for example, bursting traffic such that it causes excessive losses to established flows is probably bad. What sort of sending scheme is OK and which isn't? Depends on the scenario, which makes this the hard part. Lars --Apple-Mail-72--393589767 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA4MjkwNTU2NDhaMCMGCSqGSIb3DQEJBDEWBBQkIMMj18ySOROC QKUusDC1Ze9H3zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAIssp1RaZNuzkAu8h+jlQ8B1bHHwrXLak8KBZboVJd3cagmLyw8dT Tfq6Tdch8HEk2a5bzKtD83237Pis9jfGf6+L5taD4pl2VqYE+T6GYiY+NwlKPCHZJFiERNoS1/Wp zRlSsDRXxrqROHCPPYZd3epj/8mM0g0yqhPgS02Zu7sge/E17soqWW1BY8f1ZonAzgy7ECFHwQjG Sb1ZrqYWuUAg599vmFgRJg9wsyeoJx2iJ8mTMppy9pd1Wi2gPJ7v+De9o3wS+riviGm8at/jfh0s AIigSRIrttTDsiXt952EFoEoNqzud/a4RhBFS+gFVvGzYLkiFhRyx9pBG4GRcgAAAAAAAA== --Apple-Mail-72--393589767-- --===============0588216361== 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 --===============0588216361==-- From hipsec-bounces@lists.ietf.org Wed Aug 29 03:01:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQHYN-0002Dd-Sw; Wed, 29 Aug 2007 03:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQHYM-0002Cq-FO for hipsec@ietf.org; Wed, 29 Aug 2007 03:01:26 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQHYL-00074b-6m for hipsec@ietf.org; Wed, 29 Aug 2007 03:01:26 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l7T71IpQ003799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2007 00:01:18 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l7T71Ikr001352; Wed, 29 Aug 2007 00:01:18 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l7T71IUs001349; Wed, 29 Aug 2007 00:01:18 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 00:01:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] NAT Traversal in HIP Date: Wed, 29 Aug 2007 00:01:17 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049727@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <0840FACD-521A-4DFF-AF6E-05D99A255BDD@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] NAT Traversal in HIP Thread-Index: AcfpSG9eIMOfSWblQyyjWOf1kOndOQANn2vw From: "Henderson, Thomas R" To: "Pekka Nikander" , "Gonzalo Camarillo" X-OriginalArrivalTime: 29 Aug 2007 07:01:18.0372 (UTC) FILETIME=[65E97640:01C7EA0A] X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: HIP 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 =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, August 28, 2007 12:53 AM > To: Gonzalo Camarillo > Cc: HIP > Subject: Re: [Hipsec] NAT Traversal in HIP >=20 > Gonzalo, all, >=20 > > 1) Shall we use the ICE methodology or not? >=20 > In the long run, I think we should use ICE *methodology*. On the =20 > other hand, I think it would be *good* for people to experiment with =20 > lesser functionality very soon, i.e., now. But the latter can be =20 > done by the experimenters agreeing on some interim draft and working =20 > from that. The WG doesn't need to be directly involved. I agree that there should be some experimental work done before we can reach a definitive conclusion. From my perspective, I am inclined to try to take an existing ICE library and modify it as little as possible to make it work with our HIP implementation.=20 Some areas where I have questions are: - does HIP need to go further to provide connectivity in asymmetric path environments? As Marcelo has pointed out, in a multihoming situation, sometimes your routing will give you asymmetric paths and you need to deal with it. ICE assumes symmetric paths, from what I understand. - what is going to happen when HIP is running ICE and some application is running ICE on top of that in an uncoordinated fashion? These questions suggest to me that it would be nice to define a few deployment/implementation scenarios that we are trying to support and prioritize. =20 >=20 > > 2) Shall we use STUN to gather addresses, and perform connectivity =20 > > checks and keep alives or shall we use HIP messages for that? >=20 > From an architectural point of view, my *personal* opinion is that =20 > we should work very hard to make sure that HIP *can* work (even =20 > through NATs) without any non-HIP infrastructure. HIP is=20 > designed to =20 > be a layer 3.5 protocol. It should work without any reliance on =20 > protocols above, just like IP and ICMP work without any protocols =20 > above. Consequently, my current, perhaps flawed understanding of =20 > the offered design options is that we should primarily use HIP =20 > messages and not STUN. It seems to me that these goals are in opposition at least for IPv4 and likely also for IPv6, since working through legacy NATs seems to require running over transport.=20 It seems that there are two main issues that perhaps can be decoupled: - how to learn (and maintains with keepalives where applicable) locator candidates somehow (some of which may be UDP locators), and how to prioritize among them - given (possibly UDP or IP) locators, HIP implements mechanisms to handle operation over them where the first issue may be solved by ICE, STUN, RVS, out-of-band techniques, etc.=20 Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 29 06:37:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQKvA-0003y9-FJ; Wed, 29 Aug 2007 06:37:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQKv9-0003y4-DP for hipsec@ietf.org; Wed, 29 Aug 2007 06:37:11 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQKv7-0003EZ-ND for hipsec@ietf.org; Wed, 29 Aug 2007 06:37:10 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IQKv7-0001nT-1a; Wed, 29 Aug 2007 06:37:09 -0400 In-Reply-To: <397F4F9D-62A5-419C-8854-8450C12851CD@nokia.com> References: <46D2D1BF.5000709@ericsson.com> <397F4F9D-62A5-419C-8854-8450C12851CD@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <859996D8-6CCD-4560-A162-681CB143D90C@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] NAT Traversal in HIP Date: Wed, 29 Aug 2007 06:37:08 -0400 To: Lars Eggert X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: HIP 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 28-Aug-07, at 03:46 , Lars Eggert wrote: > > By now you're probably guessing what I'm getting at: If ICE is used > for HIP, that rate shaping can't take place, because ICE has no > idea what traffic will be carried inside HIP. (Even HIP has no clue > about that at the time of the base exchange.) So a critical > mechanism will need to be defined. I agree with this analysis. My current opinion is that we should select some fixed but acceptable sending rate and use that. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Aug 29 08:10:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQMNY-0007Wm-KR; Wed, 29 Aug 2007 08:10:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQMNW-0007MF-8s for hipsec@ietf.org; Wed, 29 Aug 2007 08:10:34 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQMNV-0006Rh-NF for hipsec@ietf.org; Wed, 29 Aug 2007 08:10:34 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id AAF99212D35; Wed, 29 Aug 2007 15:10:31 +0300 (EEST) Received: from [127.0.0.1] (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 6E642212D34; Wed, 29 Aug 2007 15:10:31 +0300 (EEST) Message-ID: <46D56238.4050802@nomadiclab.com> Date: Wed, 29 Aug 2007 15:10:32 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: juha.sa.korhonen@nokia.com Subject: Re: [Hipsec] HIP: A question related to Base Exchange draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: hipsec@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 Hi, juha.sa.korhonen@nokia.com wrote: > 1. The state diagram at page 29 states that > > - When a peer is CLOSED or CLOSING and it has a datagram to send > it acts as a Iniator of the HIP connection and sends I1 packet. > After this it moves to state I1-SENT. > > 2. On the contrary the description of the states' behaviour (first > trigger in CLOSED/CLOSING on page 26 and 27) says: > > - When there is data to send and a another incarnation of hip > association is needed a peer sends I1 packet and stays in state > CLOSING or CLOSED. This is not exactly the same what the State > diagram shows: "a peer moves to state I1-SENT". > > > In my understanding alternative 1 could be the wanted behaviour > according to the processing of packets: peer moves to I1-SENT or > peer stays at CLOSING/CLOSED. Also maybe the thing that, the > incarnation of Security Associations refers to rekeying and > rekeying needs new Base Exchange supports option 1. > You are right. The state diagram is wrong, the state should remain in CLOSED/CLOSING. The new negotiation doesn't affect this instance but it is handled separately. Thanks for pointing this out! /petri -- Petri Jokela Phone: +358 44 299 2413 Research Scientist Fax: +358 9 299 3535 Ericsson Research, NomadicLab E-mail: petri.jokela@nomadiclab.com Finland _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 30 06:19:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQh7b-0005Oi-Qc; Thu, 30 Aug 2007 06:19:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQh7V-00055R-GM for hipsec@ietf.org; Thu, 30 Aug 2007 06:19:25 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQh7V-0002VW-2y for hipsec@ietf.org; Thu, 30 Aug 2007 06:19:25 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 21ED0205C6 for ; Thu, 30 Aug 2007 12:19:24 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-4b-46d699ac0501 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1B51620523 for ; Thu, 30 Aug 2007 12:19:24 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 12:19:24 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 12:19:23 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8E928246A for ; Thu, 30 Aug 2007 13:19:23 +0300 (EEST) Message-ID: <46D699AB.3050905@ericsson.com> Date: Thu, 30 Aug 2007 13:19:23 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: HIP Subject: Re: [Hipsec] NAT Traversal in HIP References: <77F357662F8BFA4CA7074B0410171B6D04049727@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049727@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2007 10:19:23.0986 (UTC) FILETIME=[3CB3FB20:01C7EAEF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Hi, I would like the WG to agree on a general direction for this work. Then, I would like to put together a small design team to work on this. Therefore, I would like to encourage folks to try and reach some conclusions so that the design team can start working. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Aug 30 11:08:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQldX-0002yC-Rn; Thu, 30 Aug 2007 11:08:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQldV-0002tA-Oj for hipsec@ietf.org; Thu, 30 Aug 2007 11:08:45 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQldV-0003by-8r for hipsec@ietf.org; Thu, 30 Aug 2007 11:08:45 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IQldT-0003ll-31 for hipsec@ietf.org; Thu, 30 Aug 2007 11:08:44 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <4E7600AA-80D7-4BDA-A28F-1A5D2EF81356@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: HIP WG From: Philip Matthews Date: Thu, 30 Aug 2007 11:08:42 -0400 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Hipsec] Comment on draft-ietf-hip-base-08 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 Section 5.1.1 of this document seems to be the normative description of the checksum field in the HIP packet. However, to me this section seems a bit sketchy on how the value of this field is actually computed. Am I missing something, or is there some implied knowledge of how the checksum is computed that is not stated? - Philip 5.1.1. Checksum Since the checksum covers the source and destination addresses in the IP header, it must be recomputed on HIP-aware NAT devices. If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460] contains the source and destination IPv6 addresses, HIP packet length in the pseudo-header length field, a zero field, and the HIP protocol number (see Section 4) in the Next Header field. The length field is in bytes and can be calculated from the HIP header length field: (HIP Header Length + 1) * 8. In case of using IPv4, the IPv4 UDP pseudo header format [RFC0768] is used. In the pseudo header, the source and destination addresses are those used in the IP header, the zero field is obviously zero, the protocol is the HIP protocol number (see Section 4), and the length is calculated as in the IPv6 case. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Aug 31 02:14:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQzm4-000108-Cr; Fri, 31 Aug 2007 02:14:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQzm3-0000sC-2c for hipsec@ietf.org; Fri, 31 Aug 2007 02:14:31 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQzm1-00029Y-E3 for hipsec@ietf.org; Fri, 31 Aug 2007 02:14:31 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id B43802D9B; Fri, 31 Aug 2007 09:14:28 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 05DDD2D9D; Fri, 31 Aug 2007 09:14:25 +0300 (EEST) Date: Fri, 31 Aug 2007 09:14:25 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] NAT Traversal in HIP In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049727@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D04049727@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: HIP 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 Wed, 29 Aug 2007, Henderson, Thomas R wrote: Hi Tom, >> Gonzalo, all, >> >>> 1) Shall we use the ICE methodology or not? >> >> In the long run, I think we should use ICE *methodology*. On the >> other hand, I think it would be *good* for people to experiment with >> lesser functionality very soon, i.e., now. But the latter can be >> done by the experimenters agreeing on some interim draft and working >> from that. The WG doesn't need to be directly involved. > > I agree that there should be some experimental work done before we can > reach a definitive conclusion. From my perspective, I am inclined to > try to take an existing ICE library and modify it as little as possible > to make it work with our HIP implementation. Yes, it seems tempting implementation wise, but I have expressed several concerns on this list which should be addressed first. The major problems seem to be: * HIP Relay server: this is needed for guaranteed NAT traversal. The relay has to forward HIP control packets which contain the transport address candidates. So we can't use STUN servers for this. * HIP mobility and multihoming: this will get messy with ICE? This may also reduce code reusability from ICE significantly. I have also expressed other concerns, such as security related, in my earlier emails and won't repeat them here. I hope that people address the issues that have been presented on this list on a technical level. In the end, we should select single approach to support interoperability. > Some areas where I have questions are: > > - does HIP need to go further to provide connectivity in asymmetric path > environments? As Marcelo has pointed out, in a multihoming situation, > sometimes your routing will give you asymmetric paths and you need to > deal with it. ICE assumes symmetric paths, from what I understand. I guess it is still possible to have asymmetric paths with the network even though ICE enforces both end-hosts to select the same address pairs. We have remember that the nat draft uses ICE prioritization algorithm to make the hosts to converge towards same locator pairs. This is not enforced like in ICE because I felt it was artificial for HIP. However, we can change this if really needed. There is a RFC related to this topic: ftp://ftp.rfc-editor.org/in-notes/bcp/bcp69.txt I could take an action point of this to see how this applies with UDP+IPsec encapsulation in practice. > - what is going to happen when HIP is running ICE and some application > is running ICE on top of that in an uncoordinated fashion? > > These questions suggest to me that it would be nice to define a few > deployment/implementation scenarios that we are trying to support and > prioritize. Good questions! First, can we assume that ICE stuff is unnecessary when the application is running native HIP/IKE/IPsec APIs? Or should it first detect the underlying capabilities of the underlying implementation? This could be considered in either of the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-02.txt http://www.ietf.org/internet-drafts/draft-ietf-btns-c-api-01.txt Second, an application running ICE may still be enforced to use IPsec according to local policies. Initially, this seemed to suffer from three UDP encapsulations but I think it may work out nicely albeit the initial connectivity might be set-up slower: * ICE triggers the connectivity checks * Some of the checks may be subject IPsec processing and trigger HIP. This further triggers HIP NAT traversal. Here, HIP NAT traversal actually "overrides" upper layer ICE NAT traversal. * As a result, some of the ICE checks create tunnels of UDP(IPsec(UDP(application data))) which does not really suffer from redundant encapsulation with legacy NATs. However, a potential concern might be that ICE selects a locator which is not subject to local IPsec security policies because HIP introduces additional RTT to the connectivity checks. In such a case, plain ICE will be just used. Anyway, I don't know how valid this concern is because the prioritization algorithm is the primary selection method and RTT information is secondary. Mobility and multihoming is problematic, but only when plain ICE is used without HIP. This is not a really concern for this WG, I believe. For HIP-enabled multihoming, should there be "events" to userspace about NAT status? I am referring to this draft: http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt > It seems that there are two main issues that perhaps can be decoupled: > - how to learn (and maintains with keepalives where applicable) locator > candidates somehow (some of which may be UDP locators), and how to > prioritize among them > - given (possibly UDP or IP) locators, HIP implements mechanisms to > handle operation over them > > where the first issue may be solved by ICE, STUN, RVS, out-of-band > techniques, etc. (I think out-of-band techniques should be possible, but avoided for automatization on behalf of the users.) -- 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 Fri Aug 31 02:42:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR0DJ-0003SI-7H; Fri, 31 Aug 2007 02:42:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR0DI-0003SD-3Q for hipsec@ietf.org; Fri, 31 Aug 2007 02:42:40 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR0DH-0001m5-HG for hipsec@ietf.org; Fri, 31 Aug 2007 02:42:40 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5AB17212D39; Fri, 31 Aug 2007 09:42:37 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E3A10212D30; Fri, 31 Aug 2007 09:42:36 +0300 (EEST) In-Reply-To: <4E7600AA-80D7-4BDA-A28F-1A5D2EF81356@magma.ca> References: <4E7600AA-80D7-4BDA-A28F-1A5D2EF81356@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Comment on draft-ietf-hip-base-08 Date: Fri, 31 Aug 2007 09:42:26 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: HIP WG 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 What seems to be missing is explicit notion that for HIP packets carried over IPv6, the RFC 2460 Section 8.1 Upper-Layer checksum algorithm will be used, and for HIP packets carried over IPv4, the RFC 768 UDP checksum algorithm will be used. Would adding that clarify the situation enough, or are you missing something else? Both RFC 2460 and RFC 768 are pretty specific how to do that, and there exists a number of implementations for both. --Pekka On 30 Aug 2007, at 18:08, Philip Matthews wrote: > Section 5.1.1 of this document seems to be the normative > description of the checksum field in the HIP packet. However, to me > this section seems a bit sketchy on how the value of this field is > actually computed. Am I missing something, or is there some > implied knowledge of how the checksum is computed that is not stated? > > - Philip > > 5.1.1. Checksum > > Since the checksum covers the source and destination addresses > in the > IP header, it must be recomputed on HIP-aware NAT devices. > > If IPv6 is used to carry the HIP packet, the pseudo-header > [RFC2460] > contains the source and destination IPv6 addresses, HIP packet > length > in the pseudo-header length field, a zero field, and the HIP > protocol > number (see Section 4) in the Next Header field. The length > field is > in bytes and can be calculated from the HIP header length field: > (HIP > Header Length + 1) * 8. > > In case of using IPv4, the IPv4 UDP pseudo header format > [RFC0768] is > used. In the pseudo header, the source and destination > addresses are > those used in the IP header, the zero field is obviously zero, the > protocol is the HIP protocol number (see Section 4), and the length > is calculated as in the IPv6 case. > > _______________________________________________ > 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 Fri Aug 31 07:13:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR4RR-0002yU-GC; Fri, 31 Aug 2007 07:13:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR4RQ-0002tF-5J for hipsec@ietf.org; Fri, 31 Aug 2007 07:13:32 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR4RO-0000mj-P9 for hipsec@ietf.org; Fri, 31 Aug 2007 07:13:32 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IR4RO-0007ys-0w; Fri, 31 Aug 2007 07:13:30 -0400 In-Reply-To: References: <4E7600AA-80D7-4BDA-A28F-1A5D2EF81356@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Comment on draft-ietf-hip-base-08 Date: Fri, 31 Aug 2007 07:13:29 -0400 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: HIP WG 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 Given your comment, I am also guessing that the pseudo-header is logically prepended to the HIP header and the checksum is computed starting at the first byte of the pseudo-header and going through the last byte of the HIP header (including any TLVs). Is there anything else included? For IPv4, I am guessing that the actual formula is the one described in the UDP specification: Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. For HIP, I am guessing that there is no need to pad with zero octets. Does the following paragraph from the UDP specification also apply to HIP? If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care). What about IPv6? RFC 2460 does not actually describe a checksum formula. Is the same formula used? And since, in IPv6, HIP is logically an extension header what exactly is covered by the checksum? The base spec also describes the possibility that HIP packets might in the future be used to carry upper-level data (i.e., the NextHeader field might be something other that NoNextHeader). In this case, does the checksum cover that upper-level data, or only the HIP header? Or is this something that is left "for future specification"? - Philip On 31-Aug-07, at 02:42 , Pekka Nikander wrote: > What seems to be missing is explicit notion that for HIP packets > carried over IPv6, the RFC 2460 Section 8.1 Upper-Layer checksum > algorithm will be used, and for HIP packets carried over IPv4, the > RFC 768 UDP checksum algorithm will be used. > > Would adding that clarify the situation enough, or are you missing > something else? Both RFC 2460 and RFC 768 are pretty specific how > to do that, and there exists a number of implementations for both. > > --Pekka > > On 30 Aug 2007, at 18:08, Philip Matthews wrote: > >> Section 5.1.1 of this document seems to be the normative >> description of the checksum field in the HIP packet. However, to >> me this section seems a bit sketchy on how the value of this field >> is actually computed. Am I missing something, or is there some >> implied knowledge of how the checksum is computed that is not stated? >> >> - Philip >> >> 5.1.1. Checksum >> >> Since the checksum covers the source and destination addresses >> in the >> IP header, it must be recomputed on HIP-aware NAT devices. >> >> If IPv6 is used to carry the HIP packet, the pseudo-header >> [RFC2460] >> contains the source and destination IPv6 addresses, HIP packet >> length >> in the pseudo-header length field, a zero field, and the HIP >> protocol >> number (see Section 4) in the Next Header field. The length >> field is >> in bytes and can be calculated from the HIP header length >> field: (HIP >> Header Length + 1) * 8. >> >> In case of using IPv4, the IPv4 UDP pseudo header format >> [RFC0768] is >> used. In the pseudo header, the source and destination >> addresses are >> those used in the IP header, the zero field is obviously zero, the >> protocol is the HIP protocol number (see Section 4), and the >> length >> is calculated as in the IPv6 case. >> >> _______________________________________________ >> 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 Fri Aug 31 08:29:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR5cZ-0008If-Tp; Fri, 31 Aug 2007 08:29:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR5cY-0008Cg-WF for hipsec@ietf.org; Fri, 31 Aug 2007 08:29:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR5cY-0002uT-0e for hipsec@ietf.org; Fri, 31 Aug 2007 08:29:06 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C3ED4212D45; Fri, 31 Aug 2007 15:29:03 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8DDD1212C63; Fri, 31 Aug 2007 15:29:03 +0300 (EEST) In-Reply-To: References: <4E7600AA-80D7-4BDA-A28F-1A5D2EF81356@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <058F505E-282B-4023-9B77-ACD153F6759E@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Comment on draft-ietf-hip-base-08 Date: Fri, 31 Aug 2007 15:28:53 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: HIP WG 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 Well, my perhaps faulty understanding is that for both IPv4 and IPv6, the currently existing UDP checksum implementations include everything from the pseudo header to the end of the payload. If so, the logical implication is that if there are further headers beyond HIP (such as UDP and/or SIP, for example), they will be included in the checksum. The intention in HIP has been to be compatible with UDP, thereby allowing existing hardware accelerators for updating UDP checksums in NATs to be trivially reused. However, I am not aware of any vendor having done an analysis if that is really feasible with the current design. The interpretation of this Section has been a problem in the past in the interops. Therefore, and based on your comments, I think it would be very good to clarify it. However, I haven't implemented it myself. The implementers should speak up. Perhaps someone who has done this could write a clarifying paragraph or two. --Pekka On 31 Aug 2007, at 14:13, Philip Matthews wrote: > > Given your comment, I am also guessing that the pseudo-header is > logically prepended to the HIP header and the checksum is computed > starting at the first byte of the pseudo-header and going through > the last byte of the HIP header (including any TLVs). Is there > anything else included? For IPv4, I am guessing that the actual > formula is the one described in the UDP specification: > Checksum is the 16-bit one's complement of the one's complement > sum of a > pseudo header of information from the IP header, the UDP header, > and the > data, padded with zero octets at the end (if necessary) to > make a > multiple of two octets. > For HIP, I am guessing that there is no need to pad with zero > octets. Does the following paragraph from the UDP specification > also apply to HIP? > If the computed checksum is zero, it is transmitted as all > ones (the > equivalent in one's complement arithmetic). An all zero > transmitted > checksum value means that the transmitter generated no > checksum (for > debugging or for higher level protocols that don't care). > > What about IPv6? RFC 2460 does not actually describe a checksum > formula. Is the same formula used? And since, in IPv6, HIP is > logically an extension header what exactly is covered by the checksum? > > The base spec also describes the possibility that HIP packets might > in the future be used to carry upper-level data (i.e., the > NextHeader field might be something other that NoNextHeader). In > this case, does the checksum cover that upper-level data, or only > the HIP header? Or is this something that is left "for future > specification"? > > - Philip > > On 31-Aug-07, at 02:42 , Pekka Nikander wrote: > >> What seems to be missing is explicit notion that for HIP packets >> carried over IPv6, the RFC 2460 Section 8.1 Upper-Layer checksum >> algorithm will be used, and for HIP packets carried over IPv4, the >> RFC 768 UDP checksum algorithm will be used. >> >> Would adding that clarify the situation enough, or are you missing >> something else? Both RFC 2460 and RFC 768 are pretty specific how >> to do that, and there exists a number of implementations for both. >> >> --Pekka >> >> On 30 Aug 2007, at 18:08, Philip Matthews wrote: >> >>> Section 5.1.1 of this document seems to be the normative >>> description of the checksum field in the HIP packet. However, to >>> me this section seems a bit sketchy on how the value of this >>> field is actually computed. Am I missing something, or is there >>> some implied knowledge of how the checksum is computed that is >>> not stated? >>> >>> - Philip >>> >>> 5.1.1. Checksum >>> >>> Since the checksum covers the source and destination addresses >>> in the >>> IP header, it must be recomputed on HIP-aware NAT devices. >>> >>> If IPv6 is used to carry the HIP packet, the pseudo-header >>> [RFC2460] >>> contains the source and destination IPv6 addresses, HIP packet >>> length >>> in the pseudo-header length field, a zero field, and the HIP >>> protocol >>> number (see Section 4) in the Next Header field. The length >>> field is >>> in bytes and can be calculated from the HIP header length >>> field: (HIP >>> Header Length + 1) * 8. >>> >>> In case of using IPv4, the IPv4 UDP pseudo header format >>> [RFC0768] is >>> used. In the pseudo header, the source and destination >>> addresses are >>> those used in the IP header, the zero field is obviously zero, >>> the >>> protocol is the HIP protocol number (see Section 4), and the >>> length >>> is calculated as in the IPv6 case. >>> >>> _______________________________________________ >>> 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 Fri Aug 31 09:46:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR6p7-0000Xk-9F; Fri, 31 Aug 2007 09:46:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR6p5-0000Nd-LC for hipsec@ietf.org; Fri, 31 Aug 2007 09:46:07 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR6p4-0006BI-65 for hipsec@ietf.org; Fri, 31 Aug 2007 09:46:07 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IR6on-0003HE-1g; Fri, 31 Aug 2007 09:45:49 -0400 In-Reply-To: <058F505E-282B-4023-9B77-ACD153F6759E@nomadiclab.com> References: <4E7600AA-80D7-4BDA-A28F-1A5D2EF81356@magma.ca> <058F505E-282B-4023-9B77-ACD153F6759E@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Comment on draft-ietf-hip-base-08 Date: Fri, 31 Aug 2007 09:46:03 -0400 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: HIP WG 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 Great! And thanks for your replies. I should have probably said that all this came up from some discussions that a few of us where having around the HIP checksum in the context of our HIP-HOP proposal. We don't actually need the answers to all these questions, but I just thought it would be useful to point out that the definition in section 5.1.1 seems a bit underspecified. - Philip On 31-Aug-07, at 08:28 , Pekka Nikander wrote: > Well, my perhaps faulty understanding is that for both IPv4 and > IPv6, the currently existing UDP checksum implementations include > everything from the pseudo header to the end of the payload. If > so, the logical implication is that if there are further headers > beyond HIP (such as UDP and/or SIP, for example), they will be > included in the checksum. > > The intention in HIP has been to be compatible with UDP, thereby > allowing existing hardware accelerators for updating UDP checksums > in NATs to be trivially reused. However, I am not aware of any > vendor having done an analysis if that is really feasible with the > current design. > > The interpretation of this Section has been a problem in the past > in the interops. Therefore, and based on your comments, I think it > would be very good to clarify it. However, I haven't implemented > it myself. The implementers should speak up. Perhaps someone who > has done this could write a clarifying paragraph or two. > > --Pekka > > On 31 Aug 2007, at 14:13, Philip Matthews wrote: > >> >> Given your comment, I am also guessing that the pseudo-header is >> logically prepended to the HIP header and the checksum is computed >> starting at the first byte of the pseudo-header and going through >> the last byte of the HIP header (including any TLVs). Is there >> anything else included? For IPv4, I am guessing that the actual >> formula is the one described in the UDP specification: >> Checksum is the 16-bit one's complement of the one's complement >> sum of a >> pseudo header of information from the IP header, the UDP >> header, and the >> data, padded with zero octets at the end (if necessary) >> to make a >> multiple of two octets. >> For HIP, I am guessing that there is no need to pad with zero >> octets. Does the following paragraph from the UDP specification >> also apply to HIP? >> If the computed checksum is zero, it is transmitted as all >> ones (the >> equivalent in one's complement arithmetic). An all zero >> transmitted >> checksum value means that the transmitter generated no >> checksum (for >> debugging or for higher level protocols that don't care). >> >> What about IPv6? RFC 2460 does not actually describe a checksum >> formula. Is the same formula used? And since, in IPv6, HIP is >> logically an extension header what exactly is covered by the >> checksum? >> >> The base spec also describes the possibility that HIP packets >> might in the future be used to carry upper-level data (i.e., the >> NextHeader field might be something other that NoNextHeader). In >> this case, does the checksum cover that upper-level data, or only >> the HIP header? Or is this something that is left "for future >> specification"? >> >> - Philip >> >> On 31-Aug-07, at 02:42 , Pekka Nikander wrote: >> >>> What seems to be missing is explicit notion that for HIP packets >>> carried over IPv6, the RFC 2460 Section 8.1 Upper-Layer checksum >>> algorithm will be used, and for HIP packets carried over IPv4, >>> the RFC 768 UDP checksum algorithm will be used. >>> >>> Would adding that clarify the situation enough, or are you >>> missing something else? Both RFC 2460 and RFC 768 are pretty >>> specific how to do that, and there exists a number of >>> implementations for both. >>> >>> --Pekka >>> >>> On 30 Aug 2007, at 18:08, Philip Matthews wrote: >>> >>>> Section 5.1.1 of this document seems to be the normative >>>> description of the checksum field in the HIP packet. However, to >>>> me this section seems a bit sketchy on how the value of this >>>> field is actually computed. Am I missing something, or is there >>>> some implied knowledge of how the checksum is computed that is >>>> not stated? >>>> >>>> - Philip >>>> >>>> 5.1.1. Checksum >>>> >>>> Since the checksum covers the source and destination >>>> addresses in the >>>> IP header, it must be recomputed on HIP-aware NAT devices. >>>> >>>> If IPv6 is used to carry the HIP packet, the pseudo-header >>>> [RFC2460] >>>> contains the source and destination IPv6 addresses, HIP >>>> packet length >>>> in the pseudo-header length field, a zero field, and the HIP >>>> protocol >>>> number (see Section 4) in the Next Header field. The length >>>> field is >>>> in bytes and can be calculated from the HIP header length >>>> field: (HIP >>>> Header Length + 1) * 8. >>>> >>>> In case of using IPv4, the IPv4 UDP pseudo header format >>>> [RFC0768] is >>>> used. In the pseudo header, the source and destination >>>> addresses are >>>> those used in the IP header, the zero field is obviously >>>> zero, the >>>> protocol is the HIP protocol number (see Section 4), and the >>>> length >>>> is calculated as in the IPv6 case. >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec