From behave-bounces@ietf.org Thu Nov 01 06:54:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InXgG-0001ew-RM; Thu, 01 Nov 2007 06:53:44 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1InXgG-0001dW-6o for behave-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 06:53:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InXgF-0001dN-Nw for behave@ietf.org; Thu, 01 Nov 2007 06:53:43 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InXgE-0003XO-BJ for behave@ietf.org; Thu, 01 Nov 2007 06:53:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA1ArboJ010206; Thu, 1 Nov 2007 12:53:37 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 12:53:36 +0200 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); Thu, 1 Nov 2007 12:53:35 +0200 Received: from [172.21.34.231] (esdhcp034231.research.nokia.com [172.21.34.231]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA1ArX7s003111; Thu, 1 Nov 2007 12:53:33 +0200 In-Reply-To: <5966.52888.qm@web33302.mail.mud.yahoo.com> References: <5966.52888.qm@web33302.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] Date: Thu, 1 Nov 2007 12:53:32 +0200 To: ext Pyda Srisuresh X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Nov 2007 10:53:35.0435 (UTC) FILETIME=[737C81B0:01C81C75] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0087276019==" Errors-To: behave-bounces@ietf.org --===============0087276019== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-85-858847671; protocol="application/pkcs7-signature" --Apple-Mail-85-858847671 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-31, at 16:29, ext Pyda Srisuresh wrote: > --- Lars Eggert wrote: >> On 2007-10-30, at 19:29, ext Carlos Pignataro wrote: >>> On 10/30/2007 12:34 PM, Lars Eggert said the following: > [suresh] We all agree that IP packets with BAD IP header checksum > are silently > dropped by end-hosts and routers. ICMP errors are not generated by > end-hosts or > routers in response to IP packets with bad IP header checksums. Correct. > In that case, how could the embedded IP header checksum have been > corrupted? > You say, one possibility is corruption during transmission. > Corruption of which > specific bits in the IP header? It could have been transmission > corruption on > any part of the IP header - Src/Dest IP addresses, TTL, Length, > Checksum etc. > We cannot assume that every other part of the IP header may be OK, > but checksum > alone may have gotten corrupted. In other words, if the IP header > checksum is > corrupted, the entire IP header is suspect. That is the gist of > recommendation > for REQ-3a. Please be precise in your terms. We're talking about ICMP packets here that have their own header checksum (like IP), an ICMP message checksum and an embedded payload that contains the first part of an IP packet, which also has a header checksum and may have a transport checksum. We need to clearly differentiate between these for the purposes of this discussion. Let me restate my concerns in those terms. Obviously, a NAT needs to verify if the header checksum in the outermost IP header is correct before doing anything, as in RFC1812. We have no argument about this. Next, ICMP messages include a checksum that covers the entire ICMP message. I actually couldn't find anything in 792, 1122 and 1812 that defines where this checksum is to be validated, but since ICMP is carried end-to-end inside IP, I'd assume the idea is that the end system validates it, as for our other transport protocols. You can argue that a NAT acts as an end system here, because it needs to rewrite the contents of the ICMP message. In that case, you can argue that it should validate the ICMP message checksum and drop the packet if it is invalid. (The draft currently doesn't talk about this, however, and probably should.) Next, the ICMP payload contains the beginnings of the IP packet that caused the ICMP message to be generated. Here is where our disagreement starts. It's highly unlikely that the ICMP message checksum will be valid and the IP checksum of the embedded packet will be invalid, because, as you correctly point out, ICMP messages aren't supposed to be generated in response to corrupt IP packets. So while the NAT could validate the IP header checksum of the embedded packet, it's not clear how useful that will be. If you want to recommend this, I can live with it. My main concern is with validating the transport checksums as a security measure, and the rest of this email will discuss this concern. > In order for a NAT > to make the mods, NAT needs to start with a good base. Modifying an > IP packet, > fully knowing that it's header is suspect, could result in > bombarding the wrong > end-host with the ICMP error message. First, "bombarding" isn't the term I'd use when we're talking about forwarding one packet. Second, if you're concerned here that an attacker may abuse this to blast traffic at a host and want to prevent this, you're entering the realm of defining security mechanisms, which BEHAVE isn't chartered to do. > It woudl be derelict to not drop suspect IP packets for a device > that examines > the payload and detects checksum failure. I do believe, the current > recommendation of SHOULD as Best Current Practice is the right > thing to do. Routers don't check transport checksums to identify "suspect" packets, either. And again, your choice of wording makes it clear that you do want to design a security mechanism here. > [suresh] Lars - This is not one of designing a security mechanism > within BCP. > This is a NAT functionality requirement. NAT needs to examine the > IP and > transport headers in order to make decisions concerning translation > and > forwarding. When the IP and transport checksums are BAD, the > corresponding IP > and transport headers are suspect. When the IP and trasport headers > are > suspect, NAT does not have a good base to start from. I hope, you > agree, it is > not advisible to do lookups or translations knowing fully well the > base headers > are suspect. Hence, the recommendations REQ-3a, 3d. Thanks. As I said above, I can live with NATs validating the IP header checksums of embedded packet, even though I don't think it will matter. Validating the transport checksums, in a way that goes beyond what the IETF is currently recommending for end systems, is the issue. Lars --Apple-Mail-85-858847671 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 MBwGCSqGSIb3DQEJBTEPFw0wNzExMDExMDUzMzJaMCMGCSqGSIb3DQEJBDEWBBTtlzeE5gDMnLJ8 yFgKEpGF5gx+sDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAJ/45FN8m5YEMs9dBR6YjYSjS93La6NZEnBq7P/QUgqZg3KN1bGJ5 BRu1NC10JPOQtpjfFyjfDiHxulk/nbPIwF0Uhwtaa/798wtVeRhtyHmY9sc1boFF7YnaYpaux4Jd LP2L1U/sfbXJp4KvRBRj+T4iA89U/o8HrTDWbC1WLyUa4fz6kodSlJZ+Xk+Ilybsup2WAwQ7vF1x oXMGITb3F6d2CRODInCV6FSLPh1Jk3St4c+qTNZafUPrCy5DM7wcmbDEa975tpxVO5DBkKAvexm8 +LC9A+xGEOlldb8Sa7dKKnnWZy/ijf7Tody2o6FfgdDGcoVOoC8D58WwCy7IFwAAAAAAAA== --Apple-Mail-85-858847671-- --===============0087276019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0087276019==-- From behave-bounces@ietf.org Thu Nov 01 07:58:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InYfF-0004Kv-Pe; Thu, 01 Nov 2007 07:56:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1InYfE-0004Jq-IF for behave-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 07:56:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InYfD-00047I-D8 for behave@ietf.org; Thu, 01 Nov 2007 07:56:43 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InYf8-0005uo-0r for behave@ietf.org; Thu, 01 Nov 2007 07:56:38 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1InYf7-0001wP-0h; Thu, 01 Nov 2007 07:56:37 -0400 In-Reply-To: References: <5966.52888.qm@web33302.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95A4D976-3B90-4BA7-B21B-E12D2B76EB7C@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] Date: Thu, 1 Nov 2007 07:57:20 -0400 To: Lars Eggert 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: d6b246023072368de71562c0ab503126 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org If I understand things correctly, the question concerns an incoming ICMP error response. Specifically the question is: Should the NAT verify the checksum of the embedded IP and transport header before updating the IP addresses and ports in those headers? Let's look at how the NAT handled the original (outgoing) UDP or TCP packet. Neither BEHAVE-UDP (RFC 4787) or BEHAVE-TCP say anything about the NAT having to check the IP or transport header checksum before updating the IP addresses and ports in those headers. Since we are not mandating that the NAT verify the checksums in the original outgoing packet, it seems wrong to mandate that the NAT verify the checksums in the ICMP error response. Thus I think we should remove this requirement from the ICMP document. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 07 09:13:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iplf6-0005TD-TR; Wed, 07 Nov 2007 09:13:44 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iplf4-0005N7-3H for behave-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 09:13:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iplf3-0005LI-Hn for behave@ietf.org; Wed, 07 Nov 2007 09:13:41 -0500 Received: from web33313.mail.mud.yahoo.com ([68.142.206.128]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iplf2-000145-IW for behave@ietf.org; Wed, 07 Nov 2007 09:13:41 -0500 Received: (qmail 41252 invoked by uid 60001); 7 Nov 2007 14:13:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=0mERWug0+SU1bgOix6JKyr2TiJ+qwK4Lc1tZiNELB0JOaBh4Laqqk3h/mYHoj+A914DqR61IF9b82ISmY5ltXDIp2GscInKXmkocivRoz3+EJZZvy2apfagZZDDTVTg7VRiOKn5vShx/x03T9sZDPTcw37/GY5WVUMWfZ2ADOfA=; X-YMail-OSG: rHeWjSgVM1kkIK9onLaGvUQB6CJKKIMm8cToMnnj2BkprhalMU6HT6d4PRCFazdpI1YeL76RaQ-- Received: from [69.236.112.124] by web33313.mail.mud.yahoo.com via HTTP; Wed, 07 Nov 2007 06:13:38 PST Date: Wed, 7 Nov 2007 06:13:38 -0800 (PST) From: Pyda Srisuresh Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] To: Lars Eggert In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <437661.40391.qm@web33313.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Behave WG , iesg@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Lars, Please see my comments inline. regards, suresh --- Lars Eggert wrote: > On 2007-10-31, at 16:29, ext Pyda Srisuresh wrote: > > --- Lars Eggert wrote: > >> On 2007-10-30, at 19:29, ext Carlos Pignataro wrote: > >>> On 10/30/2007 12:34 PM, Lars Eggert said the following: > > [suresh] We all agree that IP packets with BAD IP header checksum > > are silently > > dropped by end-hosts and routers. ICMP errors are not generated by > > end-hosts or > > routers in response to IP packets with bad IP header checksums. > > Correct. > > > In that case, how could the embedded IP header checksum have been > > corrupted? > > You say, one possibility is corruption during transmission. > > Corruption of which > > specific bits in the IP header? It could have been transmission > > corruption on > > any part of the IP header - Src/Dest IP addresses, TTL, Length, > > Checksum etc. > > We cannot assume that every other part of the IP header may be OK, > > but checksum > > alone may have gotten corrupted. In other words, if the IP header > > checksum is > > corrupted, the entire IP header is suspect. That is the gist of > > recommendation > > for REQ-3a. > > Please be precise in your terms. We're talking about ICMP packets > here that have their own header checksum (like IP), an ICMP message > checksum and an embedded payload that contains the first part of an > IP packet, which also has a header checksum and may have a transport > checksum. We need to clearly differentiate between these for the > purposes of this discussion. > > Let me restate my concerns in those terms. > > Obviously, a NAT needs to verify if the header checksum in the > outermost IP header is correct before doing anything, as in RFC1812. > We have no argument about this. > > Next, ICMP messages include a checksum that covers the entire ICMP > message. I actually couldn't find anything in 792, 1122 and 1812 that > defines where this checksum is to be validated, but since ICMP is > carried end-to-end inside IP, I'd assume the idea is that the end > system validates it, as for our other transport protocols. > > You can argue that a NAT acts as an end system here, because it needs > to rewrite the contents of the ICMP message. In that case, you can > argue that it should validate the ICMP message checksum and drop the > packet if it is invalid. (The draft currently doesn't talk about > this, however, and probably should.) > [suresh] As you said, RFCs 791, 1122 and 1812 are mum about ICMP checksum validation. So, we did not mention anything about ICMP checksum validation in the draft. However, I agree with you that the draft should add a requirement to validate the ICMP checksum. I will go ahead and add this. > Next, the ICMP payload contains the beginnings of the IP packet that > caused the ICMP message to be generated. Here is where our > disagreement starts. > > It's highly unlikely that the ICMP message checksum will be valid and > the IP checksum of the embedded packet will be invalid, because, as > you correctly point out, ICMP messages aren't supposed to be > generated in response to corrupt IP packets. So while the NAT could > validate the IP header checksum of the embedded packet, it's not > clear how useful that will be. If you want to recommend this, I can > live with it. > [suresh] OK. Couple of comments. First, I do agree with you that the usefulness of validating embedded IP header checksum is limited if the ICMP message checksum is not validated. Second, NAT is able to definitively validate the embedded IP checksum, as all the bits necessary to validate the embedded IP header checksum are guaranteed to be within the ICMP error message. This is unlike the transport checksum, where the transport segment is not guaranteed to be fully embedded within the ICMP error message. SO, I will go ahead and keep the recommendation to validate the embedded IP header checksum. Thanks. > My main concern is with validating the transport checksums as a > security measure, and the rest of this email will discuss this concern. > > > In order for a NAT > > to make the mods, NAT needs to start with a good base. Modifying an > > IP packet, > > fully knowing that it's header is suspect, could result in > > bombarding the wrong > > end-host with the ICMP error message. > > First, "bombarding" isn't the term I'd use when we're talking about > forwarding one packet. > > Second, if you're concerned here that an attacker may abuse this to > blast traffic at a host and want to prevent this, you're entering the > realm of defining security mechanisms, which BEHAVE isn't chartered > to do. > > > It woudl be derelict to not drop suspect IP packets for a device > > that examines > > the payload and detects checksum failure. I do believe, the current > > recommendation of SHOULD as Best Current Practice is the right > > thing to do. > > Routers don't check transport checksums to identify "suspect" > packets, either. > > And again, your choice of wording makes it clear that you do want to > design a security mechanism here. > [suresh] Lars - Your inference that I was wanting to desing a security mechanism in incorrect. I used the word "suspect" to refer to the bits corrupted along transmission. If you have a different choice term, please suggest one. I will be happy to use that. Thanks. > > [suresh] Lars - This is not one of designing a security mechanism > > within BCP. > > This is a NAT functionality requirement. NAT needs to examine the > > IP and > > transport headers in order to make decisions concerning translation > > and > > forwarding. When the IP and transport checksums are BAD, the > > corresponding IP > > and transport headers are suspect. When the IP and trasport headers > > are > > suspect, NAT does not have a good base to start from. I hope, you > > agree, it is > > not advisible to do lookups or translations knowing fully well the > > base headers > > are suspect. Hence, the recommendations REQ-3a, 3d. Thanks. > > As I said above, I can live with NATs validating the IP header > checksums of embedded packet, even though I don't think it will matter. > > Validating the transport checksums, in a way that goes beyond what > the IETF is currently recommending for end systems, is the issue. > [suresh] Couple of comments on validating the transport checksum. a) The usefulness of validating the embedded transport checksum is limited if the ICMP message checksum is not validated; b) It would be useful if NAT could guarentee the validity of all tuple fields of the embedded IP packet (ex: Src IP, Dest Ip, Src port, Dest Port for a TCP/UDP packet) used for looking up a matching session. However, it is not guaranteed that ICMP payloads contain the entire transport segment. So, NAT is not guaranteed that it can validate the transport tuples always. So, the usefulness of Req-3d is really limited to the cases where the embedded packet contains the entire transport segment. Considering that you say that this requirement to validate embedded transport checksum goes beyond what the IETF is currently recommending for end systems, I am OK to drop the Req-3d. Thank you for your time. regards, suresh > Lars _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 07 09:31: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 1IplwH-0006UD-TL; Wed, 07 Nov 2007 09:31:29 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IplwH-0006Qa-0g for behave-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 09:31:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IplwG-0006QP-6t for behave@ietf.org; Wed, 07 Nov 2007 09:31:28 -0500 Received: from web33302.mail.mud.yahoo.com ([68.142.206.117]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IplwB-0002ow-KG for behave@ietf.org; Wed, 07 Nov 2007 09:31:28 -0500 Received: (qmail 36843 invoked by uid 60001); 7 Nov 2007 14:31:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=sEv3l+8aY9DZQgNsaytJ5D7cGXiRe54NI7pKqL1dsqzuqVl7PgjD8krnnWWUEwNZUwVT0RxAvhVvLsDxdLexAQFSDqXXjMXJkED/96LtyoGpJI8fdIaMoOP4HCXHUc8yERjWV+Q9EzZEX7lv7qSEy9m/lMsSik66OGJYv0sUsZY=; X-YMail-OSG: hhup5H0VM1nNkImxThs.hqhilkjfaUCUBQMtqAXlebdL09ifTeWbirQ7pDtm0dEzk60NInjL9A-- Received: from [69.236.112.124] by web33302.mail.mud.yahoo.com via HTTP; Wed, 07 Nov 2007 06:31:23 PST Date: Wed, 7 Nov 2007 06:31:23 -0800 (PST) From: Pyda Srisuresh Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] To: Philip Matthews , Lars Eggert In-Reply-To: <95A4D976-3B90-4BA7-B21B-E12D2B76EB7C@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <50784.35879.qm@web33302.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --- Philip Matthews wrote: > If I understand things correctly, the question concerns an incoming > ICMP error response. Specifically the question is: Should the NAT > verify the checksum of the embedded IP and transport header before > updating the IP addresses and ports in those headers? > > Let's look at how the NAT handled the original (outgoing) UDP or TCP > packet. Neither BEHAVE-UDP (RFC 4787) or BEHAVE-TCP say anything > about the NAT having to check the IP or transport header checksum > before updating the IP addresses and ports in those headers. > [suresh] As Carlos pointed out earlier, per RFC 1122 and RFC 1812, an endhost or a router MUST drop an IP packet with invalid IP header checksum. SO, there is no need to restate this requirement in BEH-UDP or BEH-TCP. As for transport checksums - RFC 1122 explictily says (in section 4.1.3.4 and 4.2.2.7) that endhosts MUST validate the transport checksum. So, once again, no need to restate this requirement in BEH-UDP or BEH-TCP. > Since we are not mandating that the NAT verify the checksums in the > original outgoing packet, it seems wrong to mandate that the NAT > verify the checksums in the ICMP error response. [suresh] Please see my comment above. regards, suresh > > Thus I think we should remove this requirement from the ICMP document. > > - Philip > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 08 04:39:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3qy-0003av-BU; Thu, 08 Nov 2007 04:39:12 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iq3qx-0003a2-W1 for behave-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 04:39:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3qs-0003Tl-9T for behave@ietf.org; Thu, 08 Nov 2007 04:39:06 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq3qp-0007FZ-Na for behave@ietf.org; Thu, 08 Nov 2007 04:39:06 -0500 Received: by ug-out-1314.google.com with SMTP id u2so1007480uge for ; Thu, 08 Nov 2007 01:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=s3bfnHomOl9abWTJp5yGrYY1hG/fEgBZlNRZYc+Nsz4=; b=lRcstCyItaB6og3nFvrkdmIOjJ9n96kz1NMROXtZV/g1icP18yVTPHJzLFauAL1GxPE+XtaUCBBnN/YKkuAsX5w5mcEvI1nrj5ZIG7ztlLfeVdzrHYqJJbej3MozciKBaOxMK1GDp0VXYGfJSjkVeVo6Qf6LT8LW1OCQGp3cHXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p3D0FNSvydqX52MKkGHwSF1WNqlgljKscNaGKaAXa7fw+k709fqB6lGY/11Z4EwxAv/J7Oik2BfODw+zRBMUlth19MDKCM9f7eHf9OEIZqQo07U9NVsIalgYXdYwW2jvyp9seU6g/+7jQ4pvpuD4l1ciq4C8XY8Eh8jiQZOt6dA= Received: by 10.67.88.10 with SMTP id q10mr384474ugl.1194514742772; Thu, 08 Nov 2007 01:39:02 -0800 (PST) Received: by 10.67.106.15 with HTTP; Thu, 8 Nov 2007 01:39:02 -0800 (PST) Message-ID: Date: Thu, 8 Nov 2007 15:09:02 +0530 From: "Mayank Dev Sondhi" To: "Jonathan Rosenberg" Subject: Re: [BEHAVE] TURN - some proposed changes for improvement and simplification In-Reply-To: <46E81AFE.6040705@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E81AFE.6040705@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > Now, that said, TCP has some additional complexities that UDP does not. > First and foremost is that you need to be very careful with how you > handle buffering. We want to avoid the case where data arrives quickly > on the connection from the client to the TURN server, but the TCP > connection from the TURN server to the remote peer is slow, and so data > is lost at the TURN server when buffers overflow. To handle this, we > will specify a buffering requirement and a possiblemechanism. There > would be a maximum buffer size per connection set in the kernel (for > example). The TURN server application code reads off of this buffer and > writes to the other TCP connection. If it cannot write because the > window is full, it doesn't read data from the incoming > connection. This will eventually cause the buffers in the kernel to > fill, and then packets are dropped (and not ACKed), causing backpressure > on the TCP connections. This effectively bridges the congestion control > between the connections, and ensures that, TURN server failures aside, > no packets get dropped in the TURN server. We believe that this kind of > mechanism is used in other similar boxes like HTTP proxies. The point on HTTP proxies presents an interesting scenario. The recommended buffer size is a difficult number to come up with just because some ISA proxies for example, set the maximum window size(buffer) for their proxied connection whereas the client actually connecting via the proxy may have advertised a "lesser" buffer size. So Client A connecting via Proxy A may advertise a 20KB Window Size and the proxied connection would however advertise a 64KB Window Size to the TURN server. If the TCP connection to the remote peer is slow, the backpressure from the TURN server will take more time to affect the buffer on the sending client and this could potentially create a problem.(degraded user experience and increased latency in signal for example) Is there a recommended way to advertise the least window size over the connection, or potentially have a "sweet spot" number that would be the IETF recommendation? I confess that this may not even be an issue, but just wanted to call it out. Thanks Mayank On Sep 12, 2007 10:29 PM, Jonathan Rosenberg wrote: > > As Dan mentioned at the last IETF meeting, we've formed a small team to > actively work on TURN over the next month, in order to accelerate its > completion and produce a version ready for WGLC by the end of September. > > As part of this, we took a step back and looked a bit at some of the > more troubling aspects of TURN. Three in particular seemed important: > > * There are several different methods of framing and encapsulation of > messages with a number of exceptions based on transport protocol, > contents of the data, and the active destination. The overall effect is > confusing and rather complex. > > * The active destination concept is inelegant, confusing, complex, and > during forking results in undesirable overhead and at least one > timing-related race condition. > > * the use of multiple TCP connections from the TURN server towards > peers, when there is one TCP connection from the TURN server to the > client, has been a concern on the list recently. > > We have a proposal on some non-trivial changes to TURN on these topics. > > Firstly, we can eliminate the entire need for active destinations (and > the Send and Data primitives as well) by introducing the concept of a > 'channel'. Each channel is a stream of application data sent to and from > a remote IP and port. In the case of UDP, we'd add a SINGLE BYTE to the > front of every packet to and from the TURN server, which is used to > signal the channel number. Channel 0 is reserved for TURN signaling to > and from the client and TURN server. The remaining 255 channels are for > remote destinations and carry pure data after the 1-byte channel number. > So when a client does a Send or a Connect, the server allocates a > remaining channel number and passes this channel number back to the > client. From that point on, when the TURN server receives data from the > peer, it sends it to the client and adds only the byte up front > containing the channel number. Similarly, when the client wants to send > data, it just adds this byte up front indicating the channel number, and > the TURN server sends the data to the corresponding remote peer. There > is no encapsulation of data as a TURN message ever. Thus, the Data > indication is removed. TURN currently requires the server to check for > the magic cookie in packets received from remote peers, and when it sees > it, encapsulate the resulting data in a Data indication. That > requirement would also be eliminated. > > Consider a forking use case where A calls a URI and this forks to B and > C. Both send a 200 OK. A will end up running ICE simultaneously with > both B and C. All of the STUN checks and any resulting RTP would just be > sent over different channels, all with identical overhead (1 byte). > There would be no need to re-invite, as there would typically be in the > current TURN mechanism. > > This also fixes the complexity that was raised on the list for > packetcable; the current mechanism complicates their QOS mechanisms > because the bandwidth for the stream is not deterministic. Here, it is > deterministic. Every packet always has an extra 1 byte per packet overhead. > > The main reason we've avoided any kind of framing for UDP up until now > has been overhead. So what kind of overhead does this introduce? Well if > we assume something really nasty like g729 with 20ms framing, thats 20 > bytes of payload plus 40 for RTP/UDP/IP gives us 60, which now goes to > 61. Thats a 1.6 percent penalty which is pretty good, considering > especially the huge overhead you are already paying for RTP/UDP. Anyway > a more realistic number is g711 with 30ms framing, and there is .35% > overhead. This cost seems reasonable given the simplifications it brings. > > Another possible concern with the 1-byte overhead is path MTU. If a UDP > packet was sent from a remote peer and it was exactly equal to the path > MTU from the remote peer to the TURN server, this will now fragment on > the TURN server to client link. Its not clear that this is a real > problem. But if you are aware of UDP applications that send data exactly > at the MTU for some reason, please speak up. > > For TCP, the channel mechanism would work the same. The current framing > already has a 'type' field which we'd just turn into a channel number. > Thus both UDP and TCP would have framing, the difference is only that > TCP includes a length whereas UDP does not. Protocol operation is > otherwise more or less the same, and this would forge closer alignment > between UDP and TCP. As with UDP, this allows multiple TCP connections > from the TURN server to remote peers, each of which would have its own > channel number, allocated to the client when permissions are created for > a remote IP address, or when a connect request is sent. Connection > status indications would all come over the control channel, and each > such indication would contain, as an attribute, the channel number that > the status indication is associated with. > > Now, that said, TCP has some additional complexities that UDP does not. > First and foremost is that you need to be very careful with how you > handle buffering. We want to avoid the case where data arrives quickly > on the connection from the client to the TURN server, but the TCP > connection from the TURN server to the remote peer is slow, and so data > is lost at the TURN server when buffers overflow. To handle this, we > will specify a buffering requirement and a possiblemechanism. There > would be a maximum buffer size per connection set in the kernel (for > example). The TURN server application code reads off of this buffer and > writes to the other TCP connection. If it cannot write because the > window is full, it doesn't read data from the incoming > connection. This will eventually cause the buffers in the kernel to > fill, and then packets are dropped (and not ACKed), causing backpressure > on the TCP connections. This effectively bridges the congestion control > between the connections, and ensures that, TURN server failures aside, > no packets get dropped in the TURN server. We believe that this kind of > mechanism is used in other similar boxes like HTTP proxies. > > Now, lets consider the case of multiple TCP connections to a > multiplicity of remote peers. There have been suggestions on the list to > just disallow this. We cannot. It happens as an artifact of forking. > Consider client A that sends an offer. Amongst its candidates is a > passive TCP candidate learned from the TURN server. THis INVITE forks to > B and C, each of which return a single active candidate. Now, A will > need to open permissions on the TURN server for B and C's IP addresses > listed in the SDP answer, and both B and C will open a TCP connection > towards the TURN server in order for ICE checks to proceed. Note well, > that since ICE processing happens ideally prior to call answering, this > case happens NOT JUST when both B and C answer at the same time, but > whenever there is forking at all with ICE-tcp. So this is actually a > common case and not a corner case. > > In this case of multiple TCP connections to remote peers, the congestion > control bridging described above gets complicated, and head-of-line > blocking gets introduced. Congestion on the connection from the TURN > server to one peer can slow down the connection to the client, and thus > limit the throughput to the other peer. This is only a problem when we > are transferring real data, not so much for things like STUN messages or > TLS handshakes. So the recommendation is going to be that, if a client > ends up in a case with multiple TCP connections that survive past the > connectivity checks, in that case the spec will recommend the client > allocate a new TCP candidate from the TURN server and restart ICE with > one of the peers, in order to eliminate the HOL blocking. > > We're looking for feedback on this proposal (and questions and > clarifications of course) ASAP - within the next week. If this seems > like a good direction, we can work these changes in and address the > other comments and still deliver a revision on schedule. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 08 08:04:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq73H-0004lH-Ob; Thu, 08 Nov 2007 08:04:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iq73G-0004kc-9q for behave-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 08:04:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq73F-0004kU-RZ for behave@ietf.org; Thu, 08 Nov 2007 08:04:05 -0500 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 1Iq73C-0004EY-Go for behave@ietf.org; Thu, 08 Nov 2007 08:04:05 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Iq73B-0007pj-0M; Thu, 08 Nov 2007 08:04:01 -0500 In-Reply-To: References: <46E81AFE.6040705@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32C89837-329E-44BA-8F27-D666E9CF5ADE@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Thu, 8 Nov 2007 08:04:59 -0500 To: Behave WG 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: Rohan Mahy , Dan Wing Subject: [BEHAVE] TURN - some proposed changes for improvement and simplification X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The TURN design team has decided to split TURN into two drafts. The base TURN draft will handle just "UDP allocations" while a new TURN- TCP draft will talk about "TCP allocations". We have already talked with the ADs and they are happy with this decision. The base draft will handle the case where the connection to the remote destination is over UDP, however it will allow the connection between the TURN client and the TURN server to be TCP or TLS over TCP. This decision allows us to rapidly advance the UDP case, which people seem to be most interested in right now, while giving us a chance to get the TCP stuff right. We ARE hoping to get both drafts out for this IETF, and are madly working away. The TURN-TCP draft (due on Monday!) might be, well, a bit drafty, but should give some meat for us to discuss in Vancouver. The base TURN draft we are hoping will be solid and suitable for rapid advancement. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 08 08:16: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 1Iq7FN-0003UM-AG; Thu, 08 Nov 2007 08:16:37 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iq7FM-0003To-8L for behave-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 08:16:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq7FL-0003TH-U6 for behave@ietf.org; Thu, 08 Nov 2007 08:16:35 -0500 Received: from submit01.sysedata.no ([195.159.29.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq7FG-0004Vq-Sv for behave@ietf.org; Thu, 08 Nov 2007 08:16:35 -0500 Received: from [82.196.214.14] (helo=[192.168.1.66]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1Iq7FF-00067N-6P; Thu, 08 Nov 2007 14:16:29 +0100 Message-ID: <47330C31.3050004@db.org> Date: Thu, 08 Nov 2007 14:16:33 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN - some proposed changes for improvement and simplification References: <46E81AFE.6040705@cisco.com> <32C89837-329E-44BA-8F27-D666E9CF5ADE@magma.ca> In-Reply-To: <32C89837-329E-44BA-8F27-D666E9CF5ADE@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Rohan Mahy , Behave WG , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > The TURN design team has decided to split TURN into two drafts. The base > TURN draft will handle just "UDP allocations" while a new TURN-TCP draft > will talk about "TCP allocations". We have already talked with the ADs > and they are happy with this decision. > > The base draft will handle the case where the connection to the remote > destination is over UDP, however it will allow the connection between > the TURN client and the TURN server to be TCP or TLS over TCP. > this makes sense. can I ask that we move the "turn-ipv6" spec into the base turn spec? /alfred > This decision allows us to rapidly advance the UDP case, which people > seem to be most interested in right now, while giving us a chance to get > the TCP stuff right. > > We ARE hoping to get both drafts out for this IETF, and are madly > working away. The TURN-TCP draft (due on Monday!) might be, well, a bit > drafty, but should give some meat for us to discuss in Vancouver. The > base TURN draft we are hoping will be solid and suitable for rapid > advancement. > > - Philip > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 08 12:04:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAnX-0008IV-HW; Thu, 08 Nov 2007 12:04:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IqAnW-0008FB-1D for behave-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:04:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAnV-0008F2-Du for behave@ietf.org; Thu, 08 Nov 2007 12:04:05 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqAnU-0005YV-UU for behave@ietf.org; Thu, 08 Nov 2007 12:04:05 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6C6A12108B for ; Thu, 8 Nov 2007 18:04:04 +0100 (CET) X-AuditID: c1b4fb3e-af032bb0000007e1-c1-47334184e483 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6302320169 for ; Thu, 8 Nov 2007 18:04:04 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 18:04:04 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 18:04:04 +0100 Message-ID: <47334183.4020605@ericsson.com> Date: Thu, 08 Nov 2007 18:04:03 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behave WG X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 17:04:04.0256 (UTC) FILETIME=[5DC9AA00:01C82229] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [BEHAVE] draft-ietf-behave-multicast-11: Discuss changes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, We this document received a few discusses during when it was with the IESG. All issues except one was resolved by version 11. However, there was a major change in adding another requirement. REQ-7: The NAT MUST NOT forward Local Network Control Block (224.0.0/24) [RFC3171] (also known as "link-local multicast") traffic from its 'inside' interface(s) to its 'outside' interface. I want to check that no one in the WG has grief with this change. Please provide feedback at the latest the 19th of Nov. There are some more changes that can easily be reviewed in the diff: http://tools.ietf.org/wg/behave/draft-ietf-behave-multicast/draft-ietf-behave-multicast-11-from-10.diff.html There is still one issue remaining to be sorted out. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 08 19:52: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 1IqI6M-0004xV-SS; Thu, 08 Nov 2007 19:52:02 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IqI6L-0004uw-Gk for behave-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 19:52:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqI6L-0004uj-2y for behave@ietf.org; Thu, 08 Nov 2007 19:52:01 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqI6H-0002Zf-QR for behave@ietf.org; Thu, 08 Nov 2007 19:52:00 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id C17A8328A1; Fri, 9 Nov 2007 00:51:27 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IqI5n-0002cI-Mn; Thu, 08 Nov 2007 19:51:27 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: dwing@cisco.com From: IETF I-D Submission Tool Message-Id: Date: Thu, 08 Nov 2007 19:51:27 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: eckert@cisco.com, behave@ietf.org Subject: [BEHAVE] New Version Notification for draft-ietf-behave-multicast-12 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org A new version of I-D, draft-ietf-behave-multicast-12.txt has been successfuly submitted by Dan Wing and posted to the IETF repository. Filename: draft-ietf-behave-multicast Revision: 12 Title: IP Multicast Requirements for a Network Address (and port) Translator (NAT) Creation_date: 2007-11-08 WG ID: behave Number_of_pages: 17 Abstract: This document specifies requirements for a Network Address (and port) Translator (NAT) that supports Any Source IP Multicast or Source- Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. The IETF Secretariat. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 08 20:00: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 1IqIEg-0001Ou-BS; Thu, 08 Nov 2007 20:00:38 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IqIEd-0001Lj-KD for behave-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 20:00:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqIEd-0001LU-AE; Thu, 08 Nov 2007 20:00:35 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqIEa-00032E-0H; Thu, 08 Nov 2007 20:00:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id EFD2E328A1; Fri, 9 Nov 2007 01:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqIE5-0004w0-Rc; Thu, 08 Nov 2007 20:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Nov 2007 20:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-multicast-12.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IP Multicast Requirements for a Network Address (and port) Translator (NAT) Author(s) : D. Wing, T. Eckert Filename : draft-ietf-behave-multicast-12.txt Pages : 17 Date : 2007-11-08 This document specifies requirements for a Network Address (and port) Translator (NAT) that supports Any Source IP Multicast or Source- Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-multicast-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-multicast-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-08195124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-multicast-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-multicast-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-08195124.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Fri Nov 09 01:58:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqNpP-0001qe-Nq; Fri, 09 Nov 2007 01:58:55 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IqNpO-0001pE-TV for behave-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 01:58:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqNpN-0001p5-H7 for behave@ietf.org; Fri, 09 Nov 2007 01:58:54 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqNpM-00079z-Uy for behave@ietf.org; Fri, 09 Nov 2007 01:58:53 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA96wkU8001652; Fri, 9 Nov 2007 08:58:48 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 08:58:46 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 08:58:45 +0200 Received: from esdhcp04065.research.nokia.com ([172.21.40.65]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 08:58:46 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-multicast-11: Discuss changes Date: Fri, 9 Nov 2007 08:59:00 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47334183.4020605@ericsson.com> In-Reply-To: <47334183.4020605@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711090859.00548.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 09 Nov 2007 06:58:46.0121 (UTC) FILETIME=[F8E7CD90:01C8229D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Thursday 08 November 2007 19:04:03 ext Magnus Westerlund, vous avez =C3= =A9crit=C2=A0: > We this document received a few discusses during when it was with the > IESG. All issues except one was resolved by version 11. However, there > was a major change in adding another requirement. > > REQ-7: The NAT MUST NOT forward Local Network Control Block > (224.0.0/24) [RFC3171] (also known as "link-local > multicast") traffic from its 'inside' interface(s) to its > 'outside' interface. > > I want to check that no one in the WG has grief with this change. Please > provide feedback at the latest the 19th of Nov. I would rather have grief if we did not have that requirement. Many applications are using that range for "easy" link-local discovery=20 already, and we surely don't want these to leak to the outside. Especially = as=20 typically they very much are not secured, beyond the link-local assumption. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 09 03:32:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqPIM-0003zu-Hn; Fri, 09 Nov 2007 03:32:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IqPIL-0003zm-0Y for behave-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 03:32:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqPIF-0003vt-D6 for behave@ietf.org; Fri, 09 Nov 2007 03:32:47 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqPIB-0005zZ-Nl for behave@ietf.org; Fri, 09 Nov 2007 03:32:47 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2BEE320A49 for ; Fri, 9 Nov 2007 09:32:43 +0100 (CET) X-AuditID: c1b4fb3c-b067fbb0000007e1-85-47341b2bb247 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1CED7207E9 for ; Fri, 9 Nov 2007 09:32:43 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 09:32:42 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 09:32:42 +0100 Message-ID: <47341B2A.1000800@ericsson.com> Date: Fri, 09 Nov 2007 09:32:42 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [BEHAVE] draft-ietf-behave-multicast-11: Discuss changes References: <47334183.4020605@ericsson.com> In-Reply-To: <47334183.4020605@ericsson.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2007 08:32:42.0406 (UTC) FILETIME=[1864A460:01C822AB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org As you may have seen version 12 has appeared. It resolves the last remaining issue by updating the following requirement addition (a): REQ-5: A NAT MUST forward IP multicast UDP datagrams from its 'inside' interface(s) to its 'outside' interface. a: NATs which support the above requirement MUST also provide a configuration option to disable this feature. Otherwise, a multihomed network would cause duplicate instances of the multicast data traffic on the public network. To see all changes compared to 11 there is a diff: http://tools.ietf.org/wg/behave/draft-ietf-behave-multicast/draft-ietf-behave-multicast-12-from-11.diff.html Cheers Magnus Magnus Westerlund skrev: > Hi, > > We this document received a few discusses during when it was with the > IESG. All issues except one was resolved by version 11. However, there > was a major change in adding another requirement. > > REQ-7: The NAT MUST NOT forward Local Network Control Block > (224.0.0/24) [RFC3171] (also known as "link-local > multicast") traffic from its 'inside' interface(s) to its > 'outside' interface. > > I want to check that no one in the WG has grief with this change. Please > provide feedback at the latest the 19th of Nov. > > There are some more changes that can easily be reviewed in the diff: > http://tools.ietf.org/wg/behave/draft-ietf-behave-multicast/draft-ietf-behave-multicast-11-from-10.diff.html > > There is still one issue remaining to be sorted out. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 13 15:15: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 1Is2A7-0007bR-5L; Tue, 13 Nov 2007 15:15:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Is2A3-0007Uj-P4 for behave-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 15:15:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2A2-0007T8-TS; Tue, 13 Nov 2007 15:15:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is2A2-00068H-Gb; Tue, 13 Nov 2007 15:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 20231175DC; Tue, 13 Nov 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Is2A1-0000Za-LN; Tue, 13 Nov 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 13 Nov 2007 15:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-tcp-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations Author(s) : J. Rosenberg, R. Mahy Filename : draft-ietf-behave-turn-tcp-00.txt Pages : 9 Date : 2007-11-13 This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept and manage TCP connection with the client's peers. TURN and this extension both purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-tcp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-turn-tcp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-turn-tcp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-13140702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-tcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-tcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-13140702.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Tue Nov 13 22:58:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9OD-0005FJ-V0; Tue, 13 Nov 2007 22:58:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Is9OD-0005FD-6p for behave-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 22:58:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9OC-0005EY-Sa for behave@ietf.org; Tue, 13 Nov 2007 22:58:08 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is9OC-0000mF-KO for behave@ietf.org; Tue, 13 Nov 2007 22:58:08 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 323C9175DC; Wed, 14 Nov 2007 03:57:38 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Is9Nh-00007F-NL; Tue, 13 Nov 2007 22:57:37 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: jdrosen@cisco.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 13 Nov 2007 22:57:37 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rohan@ekabal.com, behave@ietf.org, philip_matthews@magma.ca, dwing@cisco.com Subject: [BEHAVE] New Version Notification for draft-ietf-behave-rfc3489bis-12 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org A new version of I-D, draft-ietf-behave-rfc3489bis-12.txt has been successfuly submitted by Jonathan Rosenberg and posted to the IETF repository. Filename: draft-ietf-behave-rfc3489bis Revision: 12 Title: Session Traversal Utilities for (NAT) (STUN) Creation_date: 2007-11-13 WG ID: behave Number_of_pages: 48 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. The IETF Secretariat. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 13 23:00:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9Q7-000753-Hm; Tue, 13 Nov 2007 23:00:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Is9Q5-00071o-8b for behave-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 23:00:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9Q4-00071g-TJ; Tue, 13 Nov 2007 23:00:04 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is9Q4-0000xo-GG; Tue, 13 Nov 2007 23:00:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2105E175DC; Wed, 14 Nov 2007 04:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Is9Q1-0006dY-Ee; Tue, 13 Nov 2007 23:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 13 Nov 2007 23:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-12.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Session Traversal Utilities for (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-12.txt Pages : 48 Date : 2007-11-13 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-13225734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-13225734.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Tue Nov 13 23:00: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 1Is9QA-0007Bv-Ml; Tue, 13 Nov 2007 23:00:10 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Is9Q9-00079r-9v for behave-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 23:00:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9Q8-00077c-Cy for behave@ietf.org; Tue, 13 Nov 2007 23:00:08 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is9Q8-0000xs-0P for behave@ietf.org; Tue, 13 Nov 2007 23:00:08 -0500 X-IronPort-AV: E=Sophos;i="4.21,413,1188802800"; d="scan'208";a="2453" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Nov 2007 20:00:07 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAE4072B012622 for ; Tue, 13 Nov 2007 20:00:07 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lAE3xvYw005772 for ; Wed, 14 Nov 2007 04:00:07 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 19:59:14 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 19:59:14 -0800 Message-ID: <473A72B2.1090405@cisco.com> Date: Tue, 13 Nov 2007 22:59:46 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 03:59:14.0846 (UTC) FILETIME=[B8CA6BE0:01C82672] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1514; t=1195012807; x=1195876807; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20updated=20rfc3489bis |Sender:=20; bh=DhI1QDcnjhQOrM1fTpdPHRugaqu8EcxJGxooptFtCFA=; b=ixp0mbbN/vjDPH/4L4dZyZRn8O9it0PPowjtvWF4vJdIyooQtin+uBvn0vM2FLwVPBoydyL2 ePB951JZingoVzrPFuf+GoL1fYwIMDNBJeFFa87Rt5gqbJlmKsQPIxpW; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [BEHAVE] updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I've just submitted an updated rfc3489bis: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-12.txt this incorporates comments from Magnus's review, gen-art and DNS directorate reviews. Changes are: * provided definition of RTO * added bitfield numbers in Figure 1 * clarified that STUN is not designed to work in cases where a request is under the MTU but the response will be larger. * mentioned that CHANGED-ADDRESS has also been removed from this spec (it was omitted from the list) * clarified that, xor-mapped-address for v6 is computed by xoring mapped address with the CONCATENATION of the cookie and transaction ID (previously, it did not state that concatenation was happening) * added reference to RFC3629 for UTF-8 * added reference to MD5 spec (RFC 1321) * clarified that SRV domain names should not be hard coded * aligned client and server terminology with common industry practice. Based on this, either clients or servers can send indications. * changed SRV usage for tls to be _stuns._tcp.example.com * requested IANA to change the STUN port name from "nat-stun-port" to "stun" Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 14 12:35:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsM8x-0000Hj-Uh; Wed, 14 Nov 2007 12:35:15 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IsM8x-0000Gj-1I for behave-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 12:35:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsM8w-0000G6-MK for behave@ietf.org; Wed, 14 Nov 2007 12:35:14 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsM8w-0004qz-Bf for behave@ietf.org; Wed, 14 Nov 2007 12:35:14 -0500 X-IronPort-AV: E=Sophos;i="4.21,417,1188802800"; d="scan'208";a="15571887" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 14 Nov 2007 09:35:13 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAEHZDae014085; Wed, 14 Nov 2007 09:35:13 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAEHZCIx022234; Wed, 14 Nov 2007 17:35:12 GMT In-Reply-To: <200711090859.00548.remi.denis-courmont@nokia.com> References: <47334183.4020605@ericsson.com> <200711090859.00548.remi.denis-courmont@nokia.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [BEHAVE] draft-ietf-behave-multicast-11: Discuss changes Date: Wed, 14 Nov 2007 09:34:43 -0800 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1117; t=1195061713; x=1195925713; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20draft-ietf-behave-multicast-11=3A=20Discus s=20changes |Sender:=20; bh=ny6R4KoiBsvBQBWnfmF0UDPUIGStnosBWIzrHZS6nK8=; b=bsjFCsP+3r9HJvGUiQ6ODqfSusn7ThnXc9DPvWiOxIjM6nlHxSIqaFwg9yhgqnqs0j5lk03W NLzmgoHGEzeveyuhmrCTbkCJ0n3yRZnspPYvPsOdjYlOcMYWTHeIBu06; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Nov 8, 2007, at 10:59 PM, R=E9mi Denis-Courmont wrote: > Le Thursday 08 November 2007 19:04:03 ext Magnus Westerlund, vous =20 > avez =E9crit : >> We this document received a few discusses during when it was with the >> IESG. All issues except one was resolved by version 11. However, =20 >> there >> was a major change in adding another requirement. >> >> REQ-7: The NAT MUST NOT forward Local Network Control Block >> (224.0.0/24) [RFC3171] (also known as "link-local >> multicast") traffic from its 'inside' interface(s) to its >> 'outside' interface. >> >> I want to check that no one in the WG has grief with this change. =20 >> Please >> provide feedback at the latest the 19th of Nov. > > I would rather have grief if we did not have that requirement. > Many applications are using that range for "easy" link-local discovery > already, and we surely don't want these to leak to the outside. =20 > Especially as > typically they very much are not secured, beyond the link-local =20 > assumption. I agree. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 14 12:37: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 1IsMAp-0003RI-RT; Wed, 14 Nov 2007 12:37:11 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IsMAp-0003Qz-42 for behave-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 12:37:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMAo-0003PT-OG for behave@ietf.org; Wed, 14 Nov 2007 12:37:10 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsMAo-00055k-7i for behave@ietf.org; Wed, 14 Nov 2007 12:37:10 -0500 X-IronPort-AV: E=Sophos;i="4.21,417,1188802800"; d="scan'208";a="144452" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 14 Nov 2007 09:37:10 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAEHb9AW029423; Wed, 14 Nov 2007 09:37:09 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAEHb7Ix024894; Wed, 14 Nov 2007 17:37:08 GMT In-Reply-To: <47341B2A.1000800@ericsson.com> References: <47334183.4020605@ericsson.com> <47341B2A.1000800@ericsson.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E6CDE93-730E-4F23-A2C7-DDDBB8D7CB7B@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] draft-ietf-behave-multicast-11: Discuss changes Date: Wed, 14 Nov 2007 09:36:38 -0800 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3335; t=1195061829; x=1195925829; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20draft-ietf-behave-multicast-11=3A=20Discus s=20changes |Sender:=20; bh=4uIKUdL7I9o7nYZGRPvQQI34uWXwuknumKSmJ5bWd1w=; b=RACLpKLZAqVIgF03Zal9tKwargZMiRmzucf5yk+vEqItJ9Cvv1myGXlBu/+ixYpBlV8jIOaU 0UIjyGu3nzr+Ngspou77y3AbP05ysgD8L9bKqZ4YBKikPRk2WcmxYjZ4; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I think this is a good resolution to a very tricky problem. What this lacks in good it makes up in being simple. Cullen (with my individual contributor hat on) On Nov 9, 2007, at 12:32 AM, Magnus Westerlund wrote: > As you may have seen version 12 has appeared. It resolves the last > remaining issue by updating the following requirement addition (a): > > REQ-5: A NAT MUST forward IP multicast UDP datagrams from its > 'inside' interface(s) to its 'outside' interface. > > a: NATs which support the above requirement MUST also > provide a configuration option to disable this > feature. > Otherwise, a multihomed network would cause duplicate > instances of the multicast data traffic on the public > network. > > To see all changes compared to 11 there is a diff: > > http://tools.ietf.org/wg/behave/draft-ietf-behave-multicast/draft- > ietf-behave-multicast-12-from-11.diff.html > > Cheers > > Magnus > > > Magnus Westerlund skrev: >> Hi, >> >> We this document received a few discusses during when it was with the >> IESG. All issues except one was resolved by version 11. However, >> there >> was a major change in adding another requirement. >> >> REQ-7: The NAT MUST NOT forward Local Network Control Block >> (224.0.0/24) [RFC3171] (also known as "link-local >> multicast") traffic from its 'inside' interface(s) to its >> 'outside' interface. >> >> I want to check that no one in the WG has grief with this change. >> Please >> provide feedback at the latest the 19th of Nov. >> >> There are some more changes that can easily be reviewed in the diff: >> http://tools.ietf.org/wg/behave/draft-ietf-behave-multicast/draft- >> ietf-behave-multicast-11-from-10.diff.html >> >> There is still one issue remaining to be sorted out. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> --------------------------------------------------------------------- >> - >> Multimedia Technologies, Ericsson Research EAB/TVM/M >> --------------------------------------------------------------------- >> - >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> --------------------------------------------------------------------- >> - >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > > -- > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 15 12:07:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiBi-0000hQ-EE; Thu, 15 Nov 2007 12:07:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IsiBh-0000e4-Ad for behave-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 12:07:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiBh-0000dw-0m for behave@ietf.org; Thu, 15 Nov 2007 12:07:33 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsiBd-00067R-Ot for behave@ietf.org; Thu, 15 Nov 2007 12:07:33 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 26601D9D4038; Thu, 15 Nov 2007 09:07:29 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id DDD8B7F001C for ; Thu, 15 Nov 2007 09:07:26 -0800 (PST) Message-ID: <473C7CCE.6040902@acm.org> Date: Thu, 15 Nov 2007 09:07:26 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: behave@ietf.org Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-tcp-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org In section 9.1, the value for the Connect transaction is 0x007 but in turn-04 Connect is defined as 0x005 and the Data indication as 0x007. Also Connect Status is now 0x009 but was 0x008 in turn-04 (Listen Permission is now 0x008). It would be simpler to keep the same values, i.e.: 0x005: Connect 0x006: Send 0x007: Data 0x008: Connect Status 0x009: Listen Permission Thanks. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations > Author(s) : J. Rosenberg, R. Mahy > Filename : draft-ietf-behave-turn-tcp-00.txt > Pages : 9 > Date : 2007-11-13 > > This specification defines an extension of Traversal Using Relays > around NAT (TURN), a relay protocol for NAT traversal, to allows a > TURN client to request TCP allocations, and defines new requests and > indications for the TURN server to open and accept and manage TCP > connection with the client's peers. TURN and this extension both > purposefully restricts the ways in which the relayed address can be > used. In particular, it prevents users from running general purpose > servers from ports obtained from the STUN server. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 15 12:55:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isiw0-0007qW-At; Thu, 15 Nov 2007 12:55:24 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Isivz-0007ot-AC for behave-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 12:55:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isivy-0007mE-TL for behave@ietf.org; Thu, 15 Nov 2007 12:55:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isivy-0000pQ-Gp for behave@ietf.org; Thu, 15 Nov 2007 12:55:22 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 15 Nov 2007 09:55:22 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAFHtLvf019031; Thu, 15 Nov 2007 09:55:21 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAFHtKCX009859; Thu, 15 Nov 2007 17:55:21 GMT From: "Dan Wing" To: "'Hesham Soliman'" , "'IPv6 Operations'" References: Date: Thu, 15 Nov 2007 09:55:21 -0800 Message-ID: <0a8401c827b0$b173e8f0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgmdNhMdi3uu494QJ20lQZaYVwEXgBOA0pQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1627; t=1195149321; x=1196013321; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20Firewall=20control |Sender:=20; bh=V6ceaP79O8JF7JJtNZxB/g1r5BSDW/xwbFzia5Fe8WU=; b=n6K+bSED3bZ9cCWNMWkMwkgOQammDni3TLzefexUwsB0S66FGAV1HiSZpXr/9yex+VnRQfQQ B5R6U95kv1FKiUZCm0KpMsE43DgT6WFFh4931/YPqk6WxwaGotDVW/ug; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: behave@ietf.org Subject: [BEHAVE] RE: Firewall control X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (CC'ing BEHAVE) On v6ops, Hesham Soliman wrote: > We've submitted the draft below. I requested a slot from Fred > to discuss this in Vancouver. I look forward to your input on > this. We've received some comments from Dan Wing already about > some aspects of the draft which are underspecified or can be > improved. I have read both draft-soliman-firewall-control-00.txt and (previously) James Woodyatt's ALD, draft-woodyatt-ald-01.txt. At the BEHAVE working group meeting at IETF69 in Chicago, James presented both v6ops-cpe-simple-security and ALD. Looking at the v6ops minutes, it appears James did not present ALD to v6ops in Chicago but he did present v6ops-cpe-simple-security. There is a lot of similarity between soliman-firewall-control and woodyatt-ald. As there are two proposals that provide a similar function, it seems there is some community interest in creating a v6 protocol to allow hosts to talk to v6 firewalls. It would be to everyone's advantage to have one solution, unless we 'want to see the desert bloom' with 3-4 non-interoperable standards like happened with v4 NATs. The BEHAVE WG is only chartered for v4 NATs/NAPTs, but I have invited Hesham to present soliman-firewall-control because BEHAVE working group members are well-versed in the difficulties of simple CPE firewalling (a side-effect of v4 NAPTs), and I expect can provide constructive comments on the document. I expect there may be sufficient interest in this topic to request a BoF in Philadelphia, and have an informal meeting with interested parties in Vancouver. Thoughts? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 15 13:09:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isj9t-0001eg-Hv; Thu, 15 Nov 2007 13:09:45 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Isj9s-0001e3-HN for behave-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 13:09:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isj9s-0001dt-7g for behave@ietf.org; Thu, 15 Nov 2007 13:09:44 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Isj9p-0000dE-FH for behave@ietf.org; Thu, 15 Nov 2007 13:09:44 -0500 Received: (qmail 12642 invoked by uid 0); 15 Nov 2007 18:09:40 -0000 Received: from 88.117.95.35 by www169.gmx.net with HTTP; Thu, 15 Nov 2007 19:09:39 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Nov 2007 19:09:40 +0100 From: "Hannes Tschofenig" In-Reply-To: <0a8401c827b0$b173e8f0$c4f0200a@cisco.com> Message-ID: <20071115180940.9730@gmx.net> MIME-Version: 1.0 References: <0a8401c827b0$b173e8f0$c4f0200a@cisco.com> Subject: Re: [BEHAVE] RE: Firewall control To: "Dan Wing" , v6ops@ops.ietf.org, Hesham@elevatemobile.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+GwhgN3miGCjfQzjtA5eILZ/yz7eUUwarla7l8dX JcRHeE+CfNU5uh94iieZ/6/zYZgnhWpZfrWg== Content-Transfer-Encoding: 7bit X-GMX-UID: C/5VdIBNeWUkUoEFq25n4I0jL0tsZk2U X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The big question is "Why do you need yet another protocol?" Another one would be: "Why do the IPv4 solutions don't work given that they are designed with extensibility in mind?" -------- Original-Nachricht -------- > Datum: Thu, 15 Nov 2007 09:55:21 -0800 > Von: "Dan Wing" > An: "\'Hesham Soliman\'" , "\'IPv6 Operations\'" > CC: behave@ietf.org > Betreff: [BEHAVE] RE: Firewall control > (CC'ing BEHAVE) > > On v6ops, Hesham Soliman wrote: > > > We've submitted the draft below. I requested a slot from Fred > > to discuss this in Vancouver. I look forward to your input on > > this. We've received some comments from Dan Wing already about > > some aspects of the draft which are underspecified or can be > > improved. > > I have read both draft-soliman-firewall-control-00.txt and (previously) > James > Woodyatt's ALD, draft-woodyatt-ald-01.txt. At the BEHAVE working group > meeting at IETF69 in Chicago, James presented both > v6ops-cpe-simple-security > and ALD. Looking at the v6ops minutes, it appears James did not present > ALD > to v6ops in Chicago but he did present v6ops-cpe-simple-security. > > There is a lot of similarity between soliman-firewall-control and > woodyatt-ald. As there are two proposals that provide a similar function, > it > seems there is some community interest in creating a v6 protocol to allow > hosts to talk to v6 firewalls. It would be to everyone's advantage to > have > one solution, unless we 'want to see the desert bloom' with 3-4 > non-interoperable standards like happened with v4 NATs. > > > The BEHAVE WG is only chartered for v4 NATs/NAPTs, but I have invited > Hesham > to present soliman-firewall-control because BEHAVE working group members > are > well-versed in the difficulties of simple CPE firewalling (a side-effect > of v4 > NAPTs), and I expect can provide constructive comments on the document. > > > I expect there may be sufficient interest in this topic to request a BoF > in > Philadelphia, and have an informal meeting with interested parties in > Vancouver. Thoughts? > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 15 13:45: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 1IsjiW-0002mv-0t; Thu, 15 Nov 2007 13:45:32 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IsjiU-0002lF-LT for behave-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 13:45:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsjiU-0002l7-Bl for behave@ietf.org; Thu, 15 Nov 2007 13:45:30 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsjiP-00023m-He for behave@ietf.org; Thu, 15 Nov 2007 13:45:30 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Nov 2007 13:45:25 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAFIjPO6026380; Thu, 15 Nov 2007 13:45:25 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAFIjLNj024500; Thu, 15 Nov 2007 18:45:22 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 13:45:21 -0500 Received: from 10.86.115.68 ([10.86.115.68]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Nov 2007 18:45:20 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 15 Nov 2007 13:45:21 -0400 Subject: Re: [BEHAVE] RE: Firewall control From: Melinda Shore To: Hannes Tschofenig , Dan Wing , , Message-ID: Thread-Topic: [BEHAVE] RE: Firewall control Thread-Index: Acgnt6yz60lo+pOqEdy9sQAKleNSdA== In-Reply-To: <20071115180940.9730@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Nov 2007 18:45:21.0347 (UTC) FILETIME=[ACE86930:01C827B7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15546.002 X-TM-AS-Result: No--7.404700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1087; t=1195152325; x=1196016325; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20RE=3A=20Firewall=20control |Sender:=20 |To:=20Hannes=20Tschofenig=20, =20Dan=20Wing=20 , =0A=20=20=20=20=20=20=20=20, =20; bh=HM+zl1Wdk1uQC6agrgE7MxaezvHN35jLzr/icw7+a04=; b=KuIJ64jGqGKaZVrVYwZarsz9DOlfjpDpRBVxSw7Q6vgJ2FQavTB6p0G34SWn8g7jDZIW1Far 5hvCr0LUEetBHWqyp3e5Ycz4iaSURev7zAO12c1mPLkl84Rj93/zzpY2; Authentication-Results: rtp-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 11/15/07 2:09 PM, "Hannes Tschofenig" wrote: > Another one would be: "Why do the IPv4 solutions don't work given that they > are designed with extensibility in mind?" The only work I saw the Soliman draft reference was NSIS, which uses a different signaling model. There's been a lot more work done closer to the client-server model, which is what they're proposing also, and I gather that they're not familiar with it. I think that you're closer to right about what the real question is. Nearly any solution to any problem introduces new problems, and I think in general the new problems introduced by both path- coupled and path-decoupled middlebox signaling are sufficiently intractible that we either end up resisting doing them at all or choose instead to go with a bunch of hacked-up messy stuff that's very situational. I realize that the IETF doesn't do architecture but it seems to me that somehow this bigger question needs to be handled before putting effort into a different version of the same old thing. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 15 19:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isp1P-0006VA-3R; Thu, 15 Nov 2007 19:25:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Isp1N-0006UM-5m for behave-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 19:25:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isp1M-0006T8-K1 for behave@ietf.org; Thu, 15 Nov 2007 19:25:20 -0500 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isp1J-0000nZ-5o for behave@ietf.org; Thu, 15 Nov 2007 19:25:20 -0500 Received: from oaamta07ps.mx.bigpond.com ([124.190.106.219]) by omta01ps.mx.bigpond.com with ESMTP id <20071116002512.YFBM16290.omta01ps.mx.bigpond.com@oaamta07ps.mx.bigpond.com> for ; Fri, 16 Nov 2007 00:25:12 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta07ps.mx.bigpond.com with ESMTP id <20071116002512.WSCM7441.oaamta07ps.mx.bigpond.com@PC20005>; Fri, 16 Nov 2007 00:25:12 +0000 From: "Hesham Soliman" To: "'Melinda Shore'" , "'Hannes Tschofenig'" , "'Dan Wing'" , Subject: RE: [BEHAVE] RE: Firewall control Date: Fri, 16 Nov 2007 11:24:58 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acgnt6yz60lo+pOqEdy9sQAKleNSdAANuYhA X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > wrote: > > Another one would be: "Why do the IPv4 solutions don't > work given that they > > are designed with extensibility in mind?" > > The only work I saw the Soliman draft reference was NSIS, which > uses a different signaling model. There's been a lot more work > done closer to the client-server model, which is what they're > proposing also, and I gather that they're not familiar with it. => I would appreciate a link to something that I can read about similar proposals in this area. I'm aware of James' work and probably should have added it to the references but unintentionally didn't. > > I think that you're closer to right about what the real question > is. Nearly any solution to any problem introduces new problems, > and I think in general the new problems introduced by both path- > coupled and path-decoupled middlebox signaling are sufficiently > intractible that we either end up resisting doing them at all or > choose instead to go with a bunch of hacked-up messy stuff that's > very situational. => I find it difficult to discuss a wide range of problems in different deployments on such generic level. Of course every solution introduces new problems but that is never a reason to dismiss a solution IMHO. There is also a wide range of firewall deployment scenarios as you know and while I can think of some that don't need this approach, others definitely do. So I agree with one aspect of Hannes question, which is: what was the problem with other proposals. Lets discuss that. The first part of the question is not really useful because it doesn't tell us what those solutions are that we're supposed to compare with. Hesham > > I realize that the IETF doesn't do architecture but it seems to > me that somehow this bigger question needs to be handled before > putting effort into a different version of the same old thing. > > Melinda > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 15 20:02:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IspbN-0005Q0-H0; Thu, 15 Nov 2007 20:02:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IspbM-0005Mp-8C for behave-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 20:02:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IspbL-0005La-T9 for behave@ietf.org; Thu, 15 Nov 2007 20:02:31 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IspbL-0007ef-CU for behave@ietf.org; Thu, 15 Nov 2007 20:02:31 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Nov 2007 17:02:30 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAG12Utj012492; Thu, 15 Nov 2007 17:02:30 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAG12SEA024743; Fri, 16 Nov 2007 01:02:28 GMT From: "Dan Wing" To: "'Hesham Soliman'" , "'Melinda Shore'" , "'Hannes Tschofenig'" , References: Subject: RE: [BEHAVE] RE: Firewall control Date: Thu, 15 Nov 2007 17:02:28 -0800 Message-ID: <042a01c827ec$5cf3dd30$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acgnt6yz60lo+pOqEdy9sQAKleNSdAANuYhAAADHB3A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2842; t=1195174950; x=1196038950; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20RE=3A=20Firewall=20control |Sender:=20; bh=d5Y+RLnMLLaOFh1X+zNU3/SXrQS+X9VbKuDpOwhRpJE=; b=JVFpWEFfRovJIRa0JjWJPSVdqYy8BNLlOmba/EDKqrs7cUe81ylg67pOYtuqkCN6gfwqmdsk FN8iWV/i5Zhkw82cZZllLCDpTiFRO/idfAhLe9txwtHLTF5IItdBr99LI3YgSZIQFZBYEr5umN m9v5izzSYsj1Y4WHNMuHx9Fec=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > wrote: > > > Another one would be: "Why do the IPv4 solutions don't > > work given that they > > > are designed with extensibility in mind?" > > > > The only work I saw the Soliman draft reference was NSIS, which > > uses a different signaling model. There's been a lot more work > > done closer to the client-server model, which is what they're > > proposing also, and I gather that they're not familiar with it. > > => I would appreciate a link to something that I can read > about similar proposals in this area. I'm aware of James' work > and probably should have added it to the references but > unintentionally didn't. draft-eggert-middlebox-control-survey-01.txt surveys most of the efforts around NAT (and firewall) control including NAT-PMP, NSIS NATFW NSLP, UPnP IGD, and James Woodyatt's ALD. There are placeholders for MIDCOM, RSIP, STUN Control, NLS, AFWC, and RSIP. > > I think that you're closer to right about what the real question > > is. Nearly any solution to any problem introduces new problems, > > and I think in general the new problems introduced by both path- > > coupled and path-decoupled middlebox signaling are sufficiently > > intractible that we either end up resisting doing them at all or > > choose instead to go with a bunch of hacked-up messy stuff that's > > very situational. > > => I find it difficult to discuss a wide range of problems in > different deployments on such generic level. Of course every > solution introduces new problems but that is never a reason to > dismiss a solution IMHO. There is also a wide range of > firewall deployment scenarios as you know and while I > can think of some that don't need this approach, others > definitely do. > > So I agree with one aspect of Hannes question, which is: what was the > problem with other proposals. Lets discuss that. draft-eggert-middlebox-control-survey-01.txt describes them, but doesn't get into what's wrong with them. The original SAFE BoF request hits on a few things that are wrong (an updated description of the SAFE BoF will be available shortly, but here was the earlier version): http://www.employees.org/safe/bof-request.html Some of those might be applicable to v6 incarnations of those protocols, too; I haven't thought about that aspect enough to comment intelligently. -d > The first part of the > question is not really useful because it doesn't tell us what those > solutions are that we're supposed to compare with. > > Hesham > > > > > I realize that the IETF doesn't do architecture but it seems to > > me that somehow this bigger question needs to be handled before > > putting effort into a different version of the same old thing. > > > > Melinda > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 15 21: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 1IsqdU-0007jO-2G; Thu, 15 Nov 2007 21:08:48 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IsqdS-0007ff-9C for behave-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 21:08:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsqdR-0007et-U3 for behave@ietf.org; Thu, 15 Nov 2007 21:08:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsqdR-0006Qn-Eq for behave@ietf.org; Thu, 15 Nov 2007 21:08:45 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2007 18:08:45 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAG28ivK030816; Thu, 15 Nov 2007 18:08:44 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAG28d80018390; Fri, 16 Nov 2007 02:08:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 18:08:39 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 18:08:39 -0800 Message-ID: <473CFBC6.6080103@cisco.com> Date: Thu, 15 Nov 2007 21:09:10 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-tcp-00.txt References: <473C7CCE.6040902@acm.org> In-Reply-To: <473C7CCE.6040902@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2007 02:08:39.0223 (UTC) FILETIME=[9A7A3470:01C827F5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1949; t=1195178924; x=1196042924; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20I-D=20ACTION=3Adraft-ietf-behave-turn-tcp- 00.txt |Sender:=20; bh=1Ua8z89yS78OEU2M7I9NWMw/UIfszoCokEFQBqfCduk=; b=RGI3J5xH+sqciNBZhopyR4apogDOdYdHvVh3OtTSJXUZMLd4zmtkZJ5QBFK3HUjOum18QgpD yzBfuMpM904wrJcLwtPnfy0gqHSDp4LfcdGmAudyXFiWlszFWQySHnV2; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org OK, I will reflect this in TURN. Note that it will be inconsistent with turn-tcp (which will need to be fixed) until the blackout period lifts. Thanks, Jonathan R. Marc Petit-Huguenin wrote: > In section 9.1, the value for the Connect transaction is 0x007 but in > turn-04 Connect is defined as 0x005 and the Data indication as 0x007. > Also Connect Status is now 0x009 but was 0x008 in turn-04 (Listen > Permission is now 0x008). > > It would be simpler to keep the same values, i.e.: > > 0x005: Connect > 0x006: Send > 0x007: Data > 0x008: Connect Status > 0x009: Listen Permission > > Thanks. > > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. >> >> Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations >> Author(s) : J. Rosenberg, R. Mahy >> Filename : draft-ietf-behave-turn-tcp-00.txt >> Pages : 9 >> Date : 2007-11-13 >> >> This specification defines an extension of Traversal Using Relays >> around NAT (TURN), a relay protocol for NAT traversal, to allows a >> TURN client to request TCP allocations, and defines new requests and >> indications for the TURN server to open and accept and manage TCP >> connection with the client's peers. TURN and this extension both >> purposefully restricts the ways in which the relayed address can be >> used. In particular, it prevents users from running general purpose >> servers from ports obtained from the STUN server. > > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 16 03:14: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 1IswKy-0006sH-HB; Fri, 16 Nov 2007 03:14:04 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IswKw-0006q3-P2 for behave-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 03:14:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IswKr-0006az-Cv for behave@ietf.org; Fri, 16 Nov 2007 03:13:57 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IswKq-0005Nw-KZ for behave@ietf.org; Fri, 16 Nov 2007 03:13:57 -0500 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 lAG8DHPs008983; Fri, 16 Nov 2007 10:13:49 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:13:40 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:13:39 +0200 Received: from essapo-nirac252141.europe.nokia.com ([10.162.252.141]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:13:39 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, v6ops@ops.ietf.org Subject: Re: [BEHAVE] RE: Firewall control Date: Fri, 16 Nov 2007 10:05:14 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <0a8401c827b0$b173e8f0$c4f0200a@cisco.com> <20071115180940.9730@gmx.net> In-Reply-To: <20071115180940.9730@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711161005.14996.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 16 Nov 2007 08:13:39.0888 (UTC) FILETIME=[984A7B00:01C82828] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Thursday 15 November 2007 20:09:40 ext Hannes Tschofenig, vous avez =E9c= rit=A0: > The big question is "Why do you need yet another protocol?" We probably don't. Obviously, we not only don't need multiple protocols, bu= t=20 we don't want multiple protocols to do the same thing. > Another one would be: "Why do the IPv4 solutions don't work given that th= ey > are designed with extensibility in mind?" Actually, they don't really work all that well (UPnP IGD, NAT-PMP, STUN=20 control). These "pragmatic" solutions to IPv4 firewall control are heavily= =20 biased toward NAT traversal. They use UDP as carrier. They use the middlebox "external" IP address towar= d=20 the outside, rather than the IP address of the end node. Also, NAT-PMP and= =20 IGD are limited to first-hop because they use link-local multicast discover= y. And of course, these protocol would only deal with UDP and TCP 'cause that'= s=20 the only protocols that pass through NATs. With IPv6, I do not-so-humbly think it makes a lot of sense to use ICMPv6 a= s=20 carrier (and follow IPv6/ICMPv6 formatting convention, including 64-bits=20 alignment). It also makes sense to deliver the firewall control address=20 through IPv6 means such as ICMPV6 RA or DHCPv6. In fact, both James and=20 Hesham proposals do that. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 16 04:05:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isx99-0003I4-B0; Fri, 16 Nov 2007 04:05:55 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Isx98-0003DX-0i for behave-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 04:05:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isx97-0003Ca-Dj for behave@ietf.org; Fri, 16 Nov 2007 04:05:53 -0500 Received: from submit01.sysedata.no ([195.159.29.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isx96-00009w-St for behave@ietf.org; Fri, 16 Nov 2007 04:05:53 -0500 Received: from [82.196.214.14] (helo=[192.168.1.66]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1Isx90-0000bL-L0; Fri, 16 Nov 2007 10:05:46 +0100 Message-ID: <473D5D90.7070504@db.org> Date: Fri, 16 Nov 2007 10:06:24 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: jdrosen@cisco.com Subject: Re: [BEHAVE] New Version Notification for draft-ietf-behave-rfc3489bis-12 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: rohan@ekabal.com, behave@ietf.org, philip_matthews@magma.ca, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi here are some minor comments on this new version of rfc3489bis: Comments on draft-ietf-behave-rfc3489bis-12 by Alfred E. Heggestad 16. Nov 2007 NITS: > Section 3. Overview of Operation, 5th paragraph > > > Response back to the the STUN client. As this packet passes back ^^^^^^^ -> should be "the" > Section 6. 4th paragraph > > a response message), and indication transactions (which consists a > single indication message). Response classes are split into error -> add "of" between "consists" and "a" -> "...(which consists of a single..." > Section 7.1. Forming a Request or an Indication > > When formulating a request or indication message, the agehtn MUST ^^^^^^ -> typo, should be "agent" ? > Section 7.2.1 > > the 3s recommended in RFC 2988). In fixed- line access links, a ^^^^^^^^^^^ -> could be "fixed-line" > Section 10. Authentication and Message-Integrity Mechanisms > > additional processing occurs in three different places: when forming > a message; when receiving a message immediately after the the basic ^^^^^^^ -> should be "the" > Section 12 Backwards Compatibility with RFC 3489 > > o There were three comprehension-required attributes, RESPONSE- > ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESSthat have been removed ^^^^^^^^^^^^^^^^^^^ -> could add a space separator here IETF I-D Submission Tool wrote: > A new version of I-D, draft-ietf-behave-rfc3489bis-12.txt has been successfuly submitted by Jonathan Rosenberg and posted to the IETF repository. > > Filename: draft-ietf-behave-rfc3489bis > Revision: 12 > Title: Session Traversal Utilities for (NAT) (STUN) > Creation_date: 2007-11-13 > WG ID: behave > Number_of_pages: 48 > > Abstract: > Session Traversal Utilities for NAT (STUN) is a protocol that serves > as a tool for other protocols in dealing with NAT traversal. It can > be used by an endpoint to determine the IP address and port allocated > to it by a NAT. It can also be used to check connectivity between > two endpoints, and as a keep-alive protocol to maintain NAT bindings. > STUN works with many existing NATs, and does not require any special > behavior from them. > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > to be used in the context of a NAT traversal solution. This is an > important change from the previous version of this specification (RFC > 3489), which presented STUN as a complete solution. > > This document obsoletes RFC 3489. > > > > The IETF Secretariat. > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 16 06:07:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz2f-0002Um-A2; Fri, 16 Nov 2007 06:07:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Isz2c-0002QX-NS for behave-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 06:07:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz2c-0002PO-9r for behave@ietf.org; Fri, 16 Nov 2007 06:07:18 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isz2b-000850-Ms for behave@ietf.org; Fri, 16 Nov 2007 06:07:18 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAGB6nj7029533; Fri, 16 Nov 2007 13:07:05 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 13:06:55 +0200 Received: from esdhcp04081.research.nokia.com ([172.21.40.81]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 13:06:54 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, "ext Jonathan Rosenberg" , rohan@ekabal.com Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-tcp-00.txt Date: Fri, 16 Nov 2007 13:07:23 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711161307.23289.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 16 Nov 2007 11:06:54.0898 (UTC) FILETIME=[CC332120:01C82840] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Tuesday 13 November 2007 22:15:01 ext behave-bounces@ietf.org, vous avez= =20 =C3=A9crit=C2=A0: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. Some minor comments: * I feel 445 should get a more generic "name" - something like "Transport=20 protocol mismatch". After all, someone may define TURN for other transports= =20 that UDP and TCP (SCTP and DCCP being the obvious candidates there). * It would probably not hurt to write down explicitly whether or not the po= rt=20 number in the REMOTE-ADDRESS attribute is taken into account for incoming=20 connections. I suppose it's only taken into account for active connection, = so=20 that we can use TURN to chat with peers behind symmetric NATs. * On the CONNECT-STAT, we need to clarify whether half-closed connections a= re=20 ESTABLISHED or CLOSED, either ways. For instance, I think it's valid to=20 half-close a FTP DATA connection in the unused direction. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 16 08:35: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 1It1Lw-0002Bh-Im; Fri, 16 Nov 2007 08:35:24 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1It1Lt-00027o-PS for behave-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 08:35:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1Lt-00027M-FQ for behave@ietf.org; Fri, 16 Nov 2007 08:35:21 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It1Lq-0002nZ-9N for behave@ietf.org; Fri, 16 Nov 2007 08:35:21 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Nov 2007 08:35:19 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAGDZIDx017308; Fri, 16 Nov 2007 08:35:18 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAGDZ3Ei003536; Fri, 16 Nov 2007 13:35:17 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 08:35:17 -0500 Received: from 10.86.115.68 ([10.86.115.68]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Nov 2007 13:35:16 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 16 Nov 2007 08:35:16 -0500 Subject: Re: [BEHAVE] RE: Firewall control From: Melinda Shore To: Dan Wing , "'Hesham Soliman'" , "'Hannes Tschofenig'" , Message-ID: Thread-Topic: [BEHAVE] RE: Firewall control Thread-Index: Acgnt6yz60lo+pOqEdy9sQAKleNSdAANuYhAAADHB3AAGPWvVA== In-Reply-To: <042a01c827ec$5cf3dd30$c4f0200a@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Nov 2007 13:35:17.0006 (UTC) FILETIME=[864502E0:01C82855] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15548.002 X-TM-AS-Result: No--7.202200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1087; t=1195220118; x=1196084118; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20RE=3A=20Firewall=20control |Sender:=20 |To:=20Dan=20Wing=20, =20=22'Hesham=20Soliman'=22=20, =0A=20=20=20=20=20=20=20=20=22'Hannes=20Tschofenig'= 22=20, =0A=20=20=20=20=20=20=20=20; bh=22nfFpQimjARBbiOqNR8LUHyrIsc5NIHlYFl5COgorg=; b=yVwfE2xcQ+D1iFVqA6c1s8M2ghedNawkS553K/4Ayhn6DUM4+J+tHhDy7UmRb8HFC8DQUU5e 0oxJBrkXS8ieCBi9/2BbnudJSG5CsaV9gDRAbXM22NNijeDqcOxm0Fcc; Authentication-Results: rtp-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 11/15/07 8:02 PM, "Dan Wing" wrote: > draft-eggert-middlebox-control-survey-01.txt surveys most of > the efforts around NAT (and firewall) control including NAT-PMP, > NSIS NATFW NSLP, UPnP IGD, and James Woodyatt's ALD. There are > placeholders for MIDCOM, RSIP, STUN Control, NLS, AFWC, and > RSIP. There is also SIMCO, which has been implemented as part of Asterisk. > Some of those might be applicable to v6 incarnations of those > protocols, too; I haven't thought about that aspect enough to > comment intelligently. I think the basic problem is one that's really impossible to address in the IETF, which is that IP and talking to middleboxes are pretty much incompatible. You don't just need to know network topology, you need to know routing state, as well. The path-coupled stuff comes closer to being able to handle this but NAT is a big fat problem for reachability. In spite of this I tend to think that path-decoupled approaches will tend to be more deployable but I'm pretty sure we don't need yet another one. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 16 09:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2dt-0002G0-3b; Fri, 16 Nov 2007 09:58:01 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1It2ds-0002FN-3F for behave-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:58:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2dr-0002FE-Pj for behave@ietf.org; Fri, 16 Nov 2007 09:57:59 -0500 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2dn-0000Lv-Qa for behave@ietf.org; Fri, 16 Nov 2007 09:57:59 -0500 Received: from oaamta03ps.mx.bigpond.com ([124.190.106.219]) by omta04ps.mx.bigpond.com with ESMTP id <20071116145752.JBII22884.omta04ps.mx.bigpond.com@oaamta03ps.mx.bigpond.com> for ; Fri, 16 Nov 2007 14:57:52 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta03ps.mx.bigpond.com with ESMTP id <20071116145752.EVIT12832.oaamta03ps.mx.bigpond.com@PC20005>; Fri, 16 Nov 2007 14:57:52 +0000 From: "Hesham Soliman" To: =?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?= , , Subject: RE: [BEHAVE] RE: Firewall control Date: Sat, 17 Nov 2007 01:57:40 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <200711161005.14996.remi.denis-courmont@nokia.com> Thread-Index: AcgoKK8BFBeKevH4RDSrrVRcRWbepQAQJBSQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'Dan Wing' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > Another one would be: "Why do the IPv4 solutions don't=20 > work given that they > > are designed with extensibility in mind?" >=20 > Actually, they don't really work all that well (UPnP IGD,=20 > NAT-PMP, STUN=20 > control). These "pragmatic" solutions to IPv4 firewall=20 > control are heavily=20 > biased toward NAT traversal. =3D> That's exactly right. A lot of this is inherited from the FW =3D=3D = NAT world.=20 Hesham >=20 > --=20 > R=E9mi Denis-Courmont >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 16 10:05: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 1It2lO-0002ko-TB; Fri, 16 Nov 2007 10:05:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1It2lN-0002jI-J1 for behave-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:05:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2lN-0002iU-7T for behave@ietf.org; Fri, 16 Nov 2007 10:05:45 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2lJ-0001EP-UF for behave@ietf.org; Fri, 16 Nov 2007 10:05:45 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Nov 2007 10:05:32 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAGF5VEj023078; Fri, 16 Nov 2007 10:05:31 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAGF3rEe004638; Fri, 16 Nov 2007 15:05:31 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:05:23 -0500 Received: from 10.86.115.68 ([10.86.115.68]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Nov 2007 15:05:22 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 16 Nov 2007 10:05:23 -0500 Subject: Re: [BEHAVE] RE: Firewall control From: Melinda Shore To: Hesham Soliman , "'R=?ISO-8859-1?B?6Q==?=mi Denis-Courmont'" , , Message-ID: Thread-Topic: [BEHAVE] RE: Firewall control Thread-Index: AcgoKK8BFBeKevH4RDSrrVRcRWbepQAQJBSQAAHItIc= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Nov 2007 15:05:23.0384 (UTC) FILETIME=[1CB8D380:01C82862] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15548.002 X-TM-AS-Result: No--12.477900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=744; t=1195225531; x=1196089531; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20RE=3A=20Firewall=20control |Sender:=20 |To:=20Hesham=20Soliman=20, =0A=20=20=20=20=20=2 0=20=20=22'R=3D?ISO-8859-1?B?6Q=3D=3D?=3Dmi=20Denis-Courmont'=22=20, =0A=20=20=20=20=20=20=20=20, =20< v6ops@ops.ietf.org>; bh=78dr2tIXytwyMhVUHDE9bS8Ry54eO3wyO1d7F69buYY=; b=AMa7j3vnh+p/bpfSlCiSW7V+M6mAOjDlwKr08jJOEghcPqhyq0ZvAD9HxvyhouIBOpLWiLIN Bipg2Pj+xOjIBufyJVglzIE7pGf3syoEPbbULuXEQU562S/fd/BRwiHD; Authentication-Results: rtp-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 11/16/07 10:57 AM, "Hesham Soliman" wrote: > => That's exactly right. A lot of this is inherited from the FW == NAT > world. Some are, some aren't. UPnP IGD is not so much, nor are midcom or SIMCO or a bunch of the others that haven't worked out. Part of the issue in the IETF has been that real-world problems around NAT traversal have tended to dominate the problem space, and that's reasonable. We've got a draft on differences between firewall and NAT traversal that we'll be sending in when the submissions open up again. One issue to consider is that firewalls instantiate policy, and that the firewall traversal work so far hasn't focused that much on policy interactions. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 16 10:27:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It36W-0001SQ-Dt; Fri, 16 Nov 2007 10:27:36 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1It36V-0001Ps-FL for behave-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:27:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It36V-0001Od-2R for behave@ietf.org; Fri, 16 Nov 2007 10:27:35 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It36U-00013F-K8 for behave@ietf.org; Fri, 16 Nov 2007 10:27:34 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAGFQ0ul017196; Fri, 16 Nov 2007 09:27:21 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 17:26:33 +0200 Received: from esdhcp04081.research.nokia.com ([172.21.40.81]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 17:26:33 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Melinda Shore" Subject: Re: [BEHAVE] RE: Firewall control Date: Fri, 16 Nov 2007 17:27:02 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711161727.02496.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 16 Nov 2007 15:26:33.0524 (UTC) FILETIME=[11C8CF40:01C82865] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: v6ops@ops.ietf.org, behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Friday 16 November 2007 17:05:23 ext Melinda Shore, vous avez =E9crit=A0: > On 11/16/07 10:57 AM, "Hesham Soliman" wrote: > > =3D> That's exactly right. A lot of this is inherited from the FW =3D= =3D NAT > > world. > > Some are, some aren't. UPnP IGD is not so much, Uh? UPnP is about mapping external ports to internal ones, and getting the= =20 external address of the middlebox. Now, if that's not NAT centric... > We've got a draft on differences between firewall and NAT traversal that > we'll be sending in when the submissions open up again. One issue to > consider is that firewalls instantiate policy, and that the firewall > traversal work so far hasn't focused that much on policy interactions. A firewall that has an "advanced" policy such as what you'll find in a typi= cal=20 corporate network most certainly does not want to be controlled anyway. But then, there are "stateful" firewalls, whose policy it is to=20 let "solicited" traffic in. As far as we had a nice client-server model, th= at=20 worked very well. Nowadays we have "peer-to-peer" stuff such as end-to-end= =20 SIP media, or p2p file transfers. I have got to believe the main use cases= =20 for *IPv6* firewall control, is to tell a (loose) stateful firewall=20 what "solicited" traffic is, whenever the on-the-wire packets are not=20 sufficient. A host would know what its solicited traffic is, pretty much by= =20 definition. Typical use cases are: =2D your typical home LAN/WLAN access behind a stateful firewall CPE (what ALD is clearly designed for, and IMHO quite succesfully) =2D cellular networks accesses where pay-per-bit, DoS concerns, battery=20 lifetime, etc. pretty much require the use of stateful firewall (Hesham draft seems to address this) IMHO, better merge these two documents (or kill either of them), than creat= e a=20 third one at this point. And they probably have sufficient features, that I= 'd=20 rather not make the whole thing yet more complicated. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 16 10:34: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 1It3DM-0004PW-OX; Fri, 16 Nov 2007 10:34:40 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1It3DM-0004Ov-3L for behave-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:34:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3DL-0004OD-OO for behave@ietf.org; Fri, 16 Nov 2007 10:34:39 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3DL-0001i6-BG for behave@ietf.org; Fri, 16 Nov 2007 10:34:39 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2007 07:34:38 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAGFYcJF008051; Fri, 16 Nov 2007 07:34:38 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAGFYUEQ021031; Fri, 16 Nov 2007 15:34:38 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:34:36 -0500 Received: from 10.86.115.68 ([10.86.115.68]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Nov 2007 15:34:35 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 16 Nov 2007 10:34:36 -0500 Subject: Re: [BEHAVE] RE: Firewall control From: Melinda Shore To: R=?ISO-8859-1?B?6Q==?=mi Denis-Courmont Message-ID: Thread-Topic: [BEHAVE] RE: Firewall control Thread-Index: AcgoZjFcb6V8UpRZEdyySgAKleNSdA== In-Reply-To: <200711161727.02496.remi.denis-courmont@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Nov 2007 15:34:36.0137 (UTC) FILETIME=[3171B590:01C82866] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15548.002 X-TM-AS-Result: No--13.025000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1194; t=1195227278; x=1196091278; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20RE=3A=20Firewall=20control |Sender:=20; bh=wDazyYp8VYa0Q+iFpQ0PawnzRKSevntfrgrCH0dMiTM=; b=NEbiRZoe6kaX98fQOFWNZk899d5bkwu1W8JbJ2jI0gh8vcZ2lD6GlVmafDBHlxMXha4mhOQn 2lMZvEyhMT62zDOShMcCo4RMwcOP4gusycbD5PA41iki36xLN4X8DXPw; Authentication-Results: sj-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -2.2 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: v6ops@ops.ietf.org, behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 11/16/07 10:27 AM, "R=E9mi Denis-Courmont" wrote: > Uh? UPnP is about mapping external ports to internal ones, and getting th= e > external address of the middlebox. Now, if that's not NAT centric... The last time I looked at it it also included firewall pinholing. > A firewall that has an "advanced" policy such as what you'll find in a ty= pical > corporate network most certainly does not want to be controlled anyway. Back when we were trying to figure out what to call this work there was a strong "suggestion" from Scott Bradner to call it "middlebox communication" because we didn't want to imply that the endpoint or its proxy was actually going to be controlling anything. The problem here isn't to allow applications to open pinholes on firewalls, but rather for applications to request these network resources, give the network/firewall sufficient information to say "yes" or "no," and give the network a mechanism to communicate its decision back to the endpoint. What you describe as a "stateful" firewall actually behaves rather like a NAT, and as you imply is missing a more granular policy component. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 16 19:19:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItBPc-00078Z-Jt; Fri, 16 Nov 2007 19:19:52 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ItBPX-0006uJ-N3 for behave-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 19:19:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItBPW-0006rw-TA for behave@ietf.org; Fri, 16 Nov 2007 19:19:46 -0500 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItBPR-00086Q-H5 for behave@ietf.org; Fri, 16 Nov 2007 19:19:46 -0500 Received: from oaamta08ps.mx.bigpond.com ([124.190.106.219]) by omta04ps.mx.bigpond.com with ESMTP id <20071117001937.OMSU22884.omta04ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com> for ; Sat, 17 Nov 2007 00:19:37 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta08ps.mx.bigpond.com with ESMTP id <20071117001936.HQAR2178.oaamta08ps.mx.bigpond.com@PC20005>; Sat, 17 Nov 2007 00:19:36 +0000 From: "Hesham Soliman" To: "'Melinda Shore'" , =?iso-8859-1?Q?'R_=E9_mi_Denis-Courmont'?= Subject: RE: [BEHAVE] RE: Firewall control Date: Sat, 17 Nov 2007 11:19:23 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcgoZjFcb6V8UpRZEdyySgAKleNSdAAUO3MQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: v6ops@ops.ietf.org, behave@ietf.org, 'Dan Wing' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > A firewall that has an "advanced" policy such as what > you'll find in a typical > > corporate network most certainly does not want to be > controlled anyway. > > Back when we were trying to figure out what to call this work there > was a strong "suggestion" from Scott Bradner to call it "middlebox > communication" because we didn't want to imply that the endpoint or > its proxy was actually going to be controlling anything. The problem > here isn't to allow applications to open pinholes on firewalls, but > rather for applications to request these network resources, give the > network/firewall sufficient information to say "yes" or "no," and > give the network a mechanism to communicate its decision back to the > endpoint. > > What you describe as a "stateful" firewall actually behaves rather > like a NAT, and as you imply is missing a more granular policy > component. => I agree with this analysis but I don't think there is an issue with missing policies. By decoupling the policy entity from the firewall you let that decision be made in the PDP and simply gets "told" to the FW. There are many architectures, especially in cellular networks, where this model makes a lot of sense, especially when you consider that all the knowledge needed to authorise the pinhhole is known at the PDP. I think the trickiest part with something like this is building the right APIs for applications to make such requests. I guess that's what you are saying above and I agree with that. But of course this is not the only scenario where such API is needed, QoS signaling is another example where this is needed. Hesham > > Melinda > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Nov 17 12:30: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 1ItRUa-00033l-7T; Sat, 17 Nov 2007 12:30:04 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ItRUY-00033b-Ok for behave-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 12:30:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItRUY-00033T-Dq; Sat, 17 Nov 2007 12:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItRUY-0005sh-0g; Sat, 17 Nov 2007 12:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DABF0327BF; Sat, 17 Nov 2007 17:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItRUX-0004LU-P5; Sat, 17 Nov 2007 12:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 17 Nov 2007 12:30:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-05.txt Pages : 39 Date : 2007-11-17 This specification defines an extension of the Session Traversal Utilities for NAT (STUN) Protocol for asking the STUN server to relay packets towards a client. This extension, called Traversal Using Relays around NAT (TURN), is useful for hosts behind address dependent NATs. The extension purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers on ports obtained from the TURN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-turn-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-turn-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-17122109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-17122109.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Sat Nov 17 12:38:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItRcm-0005Uh-KJ; Sat, 17 Nov 2007 12:38:32 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ItRck-0005P5-LX for behave-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 12:38:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItRck-0005Ox-Al for behave@ietf.org; Sat, 17 Nov 2007 12:38:30 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItRcj-0000PJ-Pd for behave@ietf.org; Sat, 17 Nov 2007 12:38:30 -0500 Received: from [207.61.233.78] (helo=[192.168.0.142]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1ItRci-0005YG-1d; Sat, 17 Nov 2007 12:38:28 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <162D57F8-5097-4DF9-8844-33063D443966@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sat, 17 Nov 2007 12:39:44 -0500 To: Behave WG X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([192.168.0.142]) [207.61.233.78] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Rohan Mahy , Dan Wing Subject: [BEHAVE] draft-ietf-behave-turn-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I have just posted draft-ietf-behave-turn-05. A formal announcement notice should appear shortly. As you may be aware, Rohan Mahy, Jonathan Rosenberg, Dan Wing, and I have been working hard on a revision of TURN since early September. We have made quite a few changes to the spec in order to address the comments received from the working group and others on the -04 version. Originally, we were hoping to have a final version ready for working group last call by this time, but that has proven impossible. So we are publishing this draft aware that there are still some editorial changes to make, and perhaps one or two minor technical details to tweak. However, we would like to get feedback on all the changes we have made, with the hopes that we can rapidly make any fixes required and get a final version out for WGLC some time early next year. I have copied section 15 from the draft below which lists the changes made since turn-04. - Philip 15. Changes since version -04 This section lists the major changes between this document and draft-ietf-behave-turn-04: o Removed the ability to allocate addresses for TCP relaying. This is now covered in a separate document. However, communication between the client and the server can still run over TCP or TLS/ TCP. This resulted in the removal of the Connect method and the TIMER-VAL and CONNECT-STAT attributes. o Added the concept of channels. All communication between the client and the server flows on a channel. Channels are numbered 0..65535. Channel 0 is used for TURN messages, while the remaining channels are used for sending unencapsulated data to/ from a remote peer. This concept adds a new Channel Confirmation method and a new CHANNEL-NUMBER attribute. The new attribute is also used in the Send and Data methods. o The framing mechanism formally used just for stream-oriented transports is now also used for UDP, and the former Type and Reserved fields in the header have been replaced by a Channel Number field. The length field is zero when running over UDP. o TURN now runs on its own port, rather than using the STUN port. The use of channels requires this. o Removed the SetActiveDestination concept. This has been replaced by the concept of channels. o Changed the allocation refresh mechanism. The new mechanism uses a new Refresh method, rather than repeating the Allocation transaction. o Changed the syntax of SRV requests for secure transport. The new syntax is "_turns._tcp" rather than the old "_turn._tls". This change mirrors the corresponding change in STUN SRV syntax. o Renamed the old REMOTE-ADDRESS attribute to PEER-ADDRESS, and changed it to use the XOR-MAPPED-ADDRESS format. o Changed the RELAY-ADDRESS attribute to use the XOR-MAPPED-ADDRESS format (instead of the MAPPED-ADDRESS format)). o Renamed the 437 error code from "No Binding" to "Allocation Mismatch". o Added a discussion of what happens if a client's public binding on its outermost NAT changes. o The document now consistently uses the term "peer" as the name of a remote endpoint with which the client wishes to communicate. o Rewrote much of the document to describe the new concepts. At the same time, tried to make the presentation clearer and less repetitive. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Nov 17 15:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTqE-0008M6-Qr; Sat, 17 Nov 2007 15:00:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ItTqD-0008JY-90 for behave-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 15:00:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTqC-0008JM-Tt; Sat, 17 Nov 2007 15:00:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItTqC-0004ah-Ge; Sat, 17 Nov 2007 15:00:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2A8C0175E4; Sat, 17 Nov 2007 20:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItTph-00037N-MP; Sat, 17 Nov 2007 15:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 17 Nov 2007 15:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-13.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Session Traversal Utilities for (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-13.txt Pages : 48 Date : 2007-11-17 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-17145855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-17145855.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Sat Nov 17 15:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTqD-0008KB-HV; Sat, 17 Nov 2007 15:00:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ItTqC-0008Iq-Eq for behave-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 15:00:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTqC-0008IL-54 for behave@ietf.org; Sat, 17 Nov 2007 15:00:32 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItTq9-0001kK-BH for behave@ietf.org; Sat, 17 Nov 2007 15:00:32 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Nov 2007 12:00:18 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAHK0IKm022277; Sat, 17 Nov 2007 12:00:18 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAHK0540015729; Sat, 17 Nov 2007 20:00:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 15:00:04 -0500 Received: from [10.82.233.250] ([10.82.233.250]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 15:00:04 -0500 Message-ID: <473F4864.7020402@cisco.com> Date: Sat, 17 Nov 2007 15:00:36 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Alfred E. Heggestad" Subject: Re: [BEHAVE] New Version Notification for draft-ietf-behave-rfc3489bis-12 References: <473D5D90.7070504@db.org> In-Reply-To: <473D5D90.7070504@db.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2007 20:00:04.0226 (UTC) FILETIME=[71BCF620:01C82954] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15550.002 X-TM-AS-Result: No--16.090900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3793; t=1195329618; x=1196193618; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20New=20Version=20Notification=20for=09draft -ietf-behave-rfc3489bis-12 |Sender:=20; bh=fWkBx/cDMazOS/M2v32qNSoMoB8Mbvp3ymFDsfPo+6Y=; b=EFddYWkPnA4sPAJRmOZdnm8c3Y0HGwF8nxGwqrxkQAwabl2fRjFGCzJCyCJF7/kkNBD9XVkn bK0XHaRCa0ELSwu9nJZk1SymSReHXSpnviUzeX83xAwzkfpL1VdsJQnT; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: rohan@ekabal.com, behave@ietf.org, philip_matthews@magma.ca, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Thanks. I fixed and submitted -13 with these changes (that was the only difference from -12). -Jonathan R. Alfred E. Heggestad wrote: > Hi > > here are some minor comments on this new version of rfc3489bis: > > > > Comments on draft-ietf-behave-rfc3489bis-12 > > by Alfred E. Heggestad > 16. Nov 2007 > > > > > NITS: > > > > Section 3. Overview of Operation, 5th paragraph > > > > > > Response back to the the STUN client. As this packet passes back > ^^^^^^^ > > -> should be "the" > > > > > > Section 6. 4th paragraph > > > > a response message), and indication transactions (which consists a > > single indication message). Response classes are split into error > > -> add "of" between "consists" and "a" -> "...(which consists of a > single..." > > > > > > Section 7.1. Forming a Request or an Indication > > > > When formulating a request or indication message, the agehtn MUST > ^^^^^^ > > -> typo, should be "agent" ? > > > > > > Section 7.2.1 > > > > the 3s recommended in RFC 2988). In fixed- line access links, a > ^^^^^^^^^^^ > > -> could be "fixed-line" > > > > > > Section 10. Authentication and Message-Integrity Mechanisms > > > > additional processing occurs in three different places: when forming > > a message; when receiving a message immediately after the the basic > ^^^^^^^ > > -> should be "the" > > > > > > Section 12 Backwards Compatibility with RFC 3489 > > > > o There were three comprehension-required attributes, RESPONSE- > > ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESSthat have been removed > ^^^^^^^^^^^^^^^^^^^ > > -> could add a space separator here > > > > > > > IETF I-D Submission Tool wrote: >> A new version of I-D, draft-ietf-behave-rfc3489bis-12.txt has been >> successfuly submitted by Jonathan Rosenberg and posted to the IETF >> repository. >> >> Filename: draft-ietf-behave-rfc3489bis >> Revision: 12 >> Title: Session Traversal Utilities for (NAT) (STUN) >> Creation_date: 2007-11-13 >> WG ID: behave >> Number_of_pages: 48 >> >> Abstract: >> Session Traversal Utilities for NAT (STUN) is a protocol that serves >> as a tool for other protocols in dealing with NAT traversal. It can >> be used by an endpoint to determine the IP address and port allocated >> to it by a NAT. It can also be used to check connectivity between >> two endpoints, and as a keep-alive protocol to maintain NAT bindings. >> STUN works with many existing NATs, and does not require any special >> behavior from them. >> >> STUN is not a NAT traversal solution by itself. Rather, it is a tool >> to be used in the context of a NAT traversal solution. This is an >> important change from the previous version of this specification (RFC >> 3489), which presented STUN as a complete solution. >> >> This document obsoletes RFC 3489. >> >> >> >> The IETF Secretariat. >> >> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Nov 17 15:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTqE-0008M6-Qr; Sat, 17 Nov 2007 15:00:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ItTqD-0008JY-90 for behave-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 15:00:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTqC-0008JM-Tt; Sat, 17 Nov 2007 15:00:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItTqC-0004ah-Ge; Sat, 17 Nov 2007 15:00:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2A8C0175E4; Sat, 17 Nov 2007 20:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItTph-00037N-MP; Sat, 17 Nov 2007 15:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 17 Nov 2007 15:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-13.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Session Traversal Utilities for (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-13.txt Pages : 48 Date : 2007-11-17 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-rfc3489bis-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-rfc3489bis-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-17145855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-17145855.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Sat Nov 17 15:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTqD-0008KB-HV; Sat, 17 Nov 2007 15:00:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ItTqC-0008Iq-Eq for behave-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 15:00:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItTqC-0008IL-54 for behave@ietf.org; Sat, 17 Nov 2007 15:00:32 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItTq9-0001kK-BH for behave@ietf.org; Sat, 17 Nov 2007 15:00:32 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Nov 2007 12:00:18 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAHK0IKm022277; Sat, 17 Nov 2007 12:00:18 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAHK0540015729; Sat, 17 Nov 2007 20:00:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 15:00:04 -0500 Received: from [10.82.233.250] ([10.82.233.250]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 15:00:04 -0500 Message-ID: <473F4864.7020402@cisco.com> Date: Sat, 17 Nov 2007 15:00:36 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Alfred E. Heggestad" Subject: Re: [BEHAVE] New Version Notification for draft-ietf-behave-rfc3489bis-12 References: <473D5D90.7070504@db.org> In-Reply-To: <473D5D90.7070504@db.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2007 20:00:04.0226 (UTC) FILETIME=[71BCF620:01C82954] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15550.002 X-TM-AS-Result: No--16.090900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3793; t=1195329618; x=1196193618; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20New=20Version=20Notification=20for=09draft -ietf-behave-rfc3489bis-12 |Sender:=20; bh=fWkBx/cDMazOS/M2v32qNSoMoB8Mbvp3ymFDsfPo+6Y=; b=EFddYWkPnA4sPAJRmOZdnm8c3Y0HGwF8nxGwqrxkQAwabl2fRjFGCzJCyCJF7/kkNBD9XVkn bK0XHaRCa0ELSwu9nJZk1SymSReHXSpnviUzeX83xAwzkfpL1VdsJQnT; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: rohan@ekabal.com, behave@ietf.org, philip_matthews@magma.ca, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Thanks. I fixed and submitted -13 with these changes (that was the only difference from -12). -Jonathan R. Alfred E. Heggestad wrote: > Hi > > here are some minor comments on this new version of rfc3489bis: > > > > Comments on draft-ietf-behave-rfc3489bis-12 > > by Alfred E. Heggestad > 16. Nov 2007 > > > > > NITS: > > > > Section 3. Overview of Operation, 5th paragraph > > > > > > Response back to the the STUN client. As this packet passes back > ^^^^^^^ > > -> should be "the" > > > > > > Section 6. 4th paragraph > > > > a response message), and indication transactions (which consists a > > single indication message). Response classes are split into error > > -> add "of" between "consists" and "a" -> "...(which consists of a > single..." > > > > > > Section 7.1. Forming a Request or an Indication > > > > When formulating a request or indication message, the agehtn MUST > ^^^^^^ > > -> typo, should be "agent" ? > > > > > > Section 7.2.1 > > > > the 3s recommended in RFC 2988). In fixed- line access links, a > ^^^^^^^^^^^ > > -> could be "fixed-line" > > > > > > Section 10. Authentication and Message-Integrity Mechanisms > > > > additional processing occurs in three different places: when forming > > a message; when receiving a message immediately after the the basic > ^^^^^^^ > > -> should be "the" > > > > > > Section 12 Backwards Compatibility with RFC 3489 > > > > o There were three comprehension-required attributes, RESPONSE- > > ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESSthat have been removed > ^^^^^^^^^^^^^^^^^^^ > > -> could add a space separator here > > > > > > > IETF I-D Submission Tool wrote: >> A new version of I-D, draft-ietf-behave-rfc3489bis-12.txt has been >> successfuly submitted by Jonathan Rosenberg and posted to the IETF >> repository. >> >> Filename: draft-ietf-behave-rfc3489bis >> Revision: 12 >> Title: Session Traversal Utilities for (NAT) (STUN) >> Creation_date: 2007-11-13 >> WG ID: behave >> Number_of_pages: 48 >> >> Abstract: >> Session Traversal Utilities for NAT (STUN) is a protocol that serves >> as a tool for other protocols in dealing with NAT traversal. It can >> be used by an endpoint to determine the IP address and port allocated >> to it by a NAT. It can also be used to check connectivity between >> two endpoints, and as a keep-alive protocol to maintain NAT bindings. >> STUN works with many existing NATs, and does not require any special >> behavior from them. >> >> STUN is not a NAT traversal solution by itself. Rather, it is a tool >> to be used in the context of a NAT traversal solution. This is an >> important change from the previous version of this specification (RFC >> 3489), which presented STUN as a complete solution. >> >> This document obsoletes RFC 3489. >> >> >> >> The IETF Secretariat. >> >> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Nov 17 23:21:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itbef-0006Ax-4E; Sat, 17 Nov 2007 23:21:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Itbed-00068R-EW for behave-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 23:21:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itbed-00067y-2p for behave@ietf.org; Sat, 17 Nov 2007 23:21:07 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itbea-0007ai-MP for behave@ietf.org; Sat, 17 Nov 2007 23:21:07 -0500 Received: by rv-out-0910.google.com with SMTP id l15so985548rvb for ; Sat, 17 Nov 2007 20:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=ayoy92w00yr6KDBYx9doOXR3nbik0w8Gnjgu3QZ1Oow=; b=r5Hfma6lLQdbx/wwnUtd99AD23TgMucbT0+lp5W+JPzPSTLzB4ICv6fEL4e3QlNK5QQlwnFOT2V9AfijUC7lLHREWWd76bLeLQGNwKQHrVm3o+ybKPzcnFCH1xD5y9aLTMCub09bjAUN0Nst2/v0o6LIlZfDfHn96yJB+tlx7UM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=QZUWAJ0t3t3o2nK9qarKFeqeEwJWjH3ws+UBxcnz1WRPyM4XHNZyKWvwPNR0gSngyRedl0Qdj9xhptKBTY1Fcr4Eamsctje1MI2XuX6kFsjsz7azCioTGuu1ANFOx1fF6/dyCegCKDbcQp3Zhq3zZVd9HToQK1Sr6ptiKOhrUg8= Received: by 10.142.203.13 with SMTP id a13mr496260wfg.1195359663901; Sat, 17 Nov 2007 20:21:03 -0800 (PST) Received: by 10.142.132.18 with HTTP; Sat, 17 Nov 2007 20:21:03 -0800 (PST) Message-ID: <20d2bdfb0711172021i3d2ba99yd539612397a31738@mail.gmail.com> Date: Sat, 17 Nov 2007 23:21:03 -0500 From: "Bruce Lowekamp" To: "Behave WG" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 269c87aaab54e339 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-02 submitted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I've submitted a new version of NAT Behavior Discovery. Unfortunately the automatic submission tool is still having problems with my name, but in the meantime, Derek and I have made the following changes: o Changed proposed status to experimental o Made significant changes to the introduction and applicability statements to reflect the experimental status o Fixed the New Attributes and IANA considerations not listing the same attribute numbers. o Removed mandatory shared secret credentials in favor of the option of rate limiting or credentials. Specified that credentials must be obtained from the user or parent application. o Made OTHER-ADDRESS and SOURCE-ADDRESS optional to address compatibility with 3489bis clients. Renamed SOURCE-ADDRESS as RESPONSE-ORIGIN to avoid conflicts with 3489. o Renamed XOR-RESPONSE-ADDRESS to XOR-RESPONSE-TARGET o Added discussion of FINGERPRINT and ALTERNATE-SERVER for compliance with 3489bis stun usage definition requirements. Filename: draft-ietf-behave-nat-behavior-discovery Version: 02 Staging URL: http://www3.ietf.org/proceedings/staging/draft-ietf-behave-nat-behavior-discovery-02.txt Title: NAT Behavior Discovery Using STUN Creation_date: 2007-11-17 WG ID: behave Number_of_pages: 28 Abstract: This specification defines an experimental usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server.Requirements Language Author(s): Derek MacDonald, derek@counterpath.com Bruce Lowekamp, lowekamp@sipeerior.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 19 07:50: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 1Iu65E-0004iB-J1; Mon, 19 Nov 2007 07:50:36 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iu65B-0004e7-Qw for behave-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 07:50:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65B-0004dz-GB; Mon, 19 Nov 2007 07:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu65B-0004fP-3F; Mon, 19 Nov 2007 07:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B2E7C175C1; Mon, 19 Nov 2007 12:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu64g-0001ok-8Y; Mon, 19 Nov 2007 07:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 07:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-p2p-state-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-p2p-state-06.txt Pages : 32 Date : 2007-11-19 This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-p2p-state-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-p2p-state-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19074427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-p2p-state-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-p2p-state-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19074427.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Mon Nov 19 14:15:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuC5a-0007Ab-4d; Mon, 19 Nov 2007 14:15:22 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IuC5J-0006PP-53 for behave-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 14:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuC5I-0006NY-Fd; Mon, 19 Nov 2007 14:15:04 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuC5H-0005xq-Fe; Mon, 19 Nov 2007 14:15:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E9AD426E54; Mon, 19 Nov 2007 19:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuC5F-0000A4-Pa; Mon, 19 Nov 2007 14:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 14:15:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-nat-behavior-discovery-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavior Discovery Using STUN Author(s) : D. MacDonald, B. Lowekamp Filename : draft-ietf-behave-nat-behavior-discovery-02.txt Pages : 28 Date : 2007-11-19 This specification defines an experimental usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-nat-behavior-discovery-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-nat-behavior-discovery-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19133156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-nat-behavior-discovery-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-nat-behavior-discovery-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19133156.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Mon Nov 19 18:20: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 1IuFv3-0001Ut-4m; Mon, 19 Nov 2007 18:20:45 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IuFv2-0001Un-76 for behave-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 18:20:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFv1-0001Ua-Gf for behave@ietf.org; Mon, 19 Nov 2007 18:20:43 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuFux-0007w9-Sh for behave@ietf.org; Mon, 19 Nov 2007 18:20:43 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 19105D9D403C; Mon, 19 Nov 2007 15:20:39 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 7DF07D9D4038; Mon, 19 Nov 2007 15:20:36 -0800 (PST) Message-ID: <47421A43.8000400@acm.org> Date: Mon, 19 Nov 2007 15:20:35 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Behave WG Subject: Re: [BEHAVE] draft-ietf-behave-turn-05 References: <162D57F8-5097-4DF9-8844-33063D443966@magma.ca> In-Reply-To: <162D57F8-5097-4DF9-8844-33063D443966@magma.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Rohan Mahy , Philip Matthews , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Some comments and questions: 1. Section 3, 1st paragraph: "...is connected to a private network and through one or more NATs to the public Internet. On the public Internet..." There is no such thing as a non-public Internet. 2. Section 5: I think it would be better to integrate this whole section in the Client/Server behavior, as one have to continuously read back and forth between the client/server behavior sections and this section. 3. Section 6.1.2: Refresh Requests: I see that the possibility of moving an allocation to a different tuple was completely removed in this draft (see paragraph 7 of section 6.1.2.1 of turn-04). Why? 4. Section 6.1.2, 1st paragraph. "Before 3/4 of the lifetime..." I never understood this 3/4 thing (I do not either understand a similar rule for SIP registration). Wouldn't it be more efficient to have the rule saying "16 times the RTO if using UDP or 7900ms if using TCP before the expiration of the lifetime timer..." 5. Section 6.2.1.1, 3rd paragraph: "... the server allocates a port..." It cannot do this yet, as it has to first check the REQUESTED-IP and REQUESTED-PORT-PROPS attributes. More generally, I found turn-05 more difficult to read (from a developer point of view) than turn-04, because the text does not follow the flow of the code. 6. Section 6.2.1.4 paragraph 6: "Note that the LIFETIME attribute an Allocate request..." There is something missing in this sentence. 7. Section 6.2.1.4 paragraph 6: There is no error code defined to reject a LIFETIME attribute too short. 8. Section 7.1.1 paragraph 5 and 6: "...receives a ChannelConfirmation Indication..." Should be "Channel Confirmation indication" 9. Section 7.2.1: "When the server receives a Data indication..." should be "...a Send indication" 10. Section 8.1: Is there a good reason to have two reserved bytes and a length of 4 instead of no reserved bytes and a length of 2? 11. Sections 8.4, 8.6 and 8.9: What is the reason to xor-encode the IP address? 12. Section 10: 2nd paragraph: '...instead of just "stun".' should be '...instead of "stun".' Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 20 01:04: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 1IuMDu-0007oy-Br; Tue, 20 Nov 2007 01:04:38 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IuMDt-0007oj-8G for behave-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 01:04:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuMDs-0007oa-TG for behave@ietf.org; Tue, 20 Nov 2007 01:04:36 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuMDs-0007i4-9c for behave@ietf.org; Tue, 20 Nov 2007 01:04:36 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lAK64RU17638; Mon, 19 Nov 2007 22:04:27 -0800 In-Reply-To: <47421A43.8000400@acm.org> References: <162D57F8-5097-4DF9-8844-33063D443966@magma.ca> <47421A43.8000400@acm.org> 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: Rohan Mahy Subject: Re: [BEHAVE] draft-ietf-behave-turn-05 Date: Mon, 19 Nov 2007 22:04:20 -0800 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Rohan Mahy , Behave WG , Philip Matthews , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Nov 19, 2007, at 3:20 PM, Marc Petit-Huguenin wrote: > Some comments and questions: > 3. Section 6.1.2: Refresh Requests: I see that the possibility of > moving an allocation to a different tuple was completely removed in > this > draft (see paragraph 7 of section 6.1.2.1 of turn-04). Why? The design team was concerned that if we include a partial mobility feature, that other mobility requirements would creep in. Mobility was not an original feature of the protocol. It is certainly something that could be added later if it proves useful and we have consensus on those requirements. > 4. Section 6.1.2, 1st paragraph. "Before 3/4 of the lifetime..." I > never understood this 3/4 thing (I do not either understand a similar > rule for SIP registration). Wouldn't it be more efficient to have the > rule saying "16 times the RTO if using UDP or 7900ms if using TCP > before > the expiration of the lifetime timer..." The LIFETIME is related to the lifetime of the allocation, which has a recommended default of 10 minutes. After 3/4 of this time (7.5 *minutes*) the client is expected to refresh its allocation. This is completely orthogonal and unrelated to the amount of time a client waits after sending a keepalive before determining that a flow is dead (16x RTO for UDP); and it is also different from the amount of time before a permission times out (typically about 30 seconds for UDP allocations). > 5. Section 6.2.1.1, 3rd paragraph: "... the server allocates a > port..." > > It cannot do this yet, as it has to first check the REQUESTED-IP and > REQUESTED-PORT-PROPS attributes. More generally, I found turn-05 more > difficult to read (from a developer point of view) than turn-04, > because > the text does not follow the flow of the code. good catch. if you could point out other places where the order is different please let me know. > 10. Section 8.1: Is there a good reason to have two reserved bytes > and a > length of 4 instead of no reserved bytes and a length of 2? To make the framing the same for all transports, and to insure we are always aligned on a double word boundary. > 11. Sections 8.4, 8.6 and 8.9: What is the reason to xor-encode > the IP > address? To prevent it from being rewritten by a NAT with a "generic ALG". thanks, -rohan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 20 01:58:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuN3s-0001tT-QA; Tue, 20 Nov 2007 01:58:20 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IuN3r-0001sY-S3 for behave-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 01:58:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuN3r-0001sK-1w for behave@ietf.org; Tue, 20 Nov 2007 01:58:19 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuN3o-0000nk-AG for behave@ietf.org; Tue, 20 Nov 2007 01:58:19 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 596EDD9D403A; Mon, 19 Nov 2007 22:58:15 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id C8378D9D4038; Mon, 19 Nov 2007 22:58:10 -0800 (PST) Message-ID: <47428582.7080105@acm.org> Date: Mon, 19 Nov 2007 22:58:10 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [BEHAVE] draft-ietf-behave-turn-05 References: <162D57F8-5097-4DF9-8844-33063D443966@magma.ca> <47421A43.8000400@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Behave WG , Philip Matthews , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Rohan, Thanks for your answers. More comments below. Rohan Mahy wrote: > > On Nov 19, 2007, at 3:20 PM, Marc Petit-Huguenin wrote: > >> Some comments and questions: >> 3. Section 6.1.2: Refresh Requests: I see that the possibility of >> moving an allocation to a different tuple was completely removed in this >> draft (see paragraph 7 of section 6.1.2.1 of turn-04). Why? > > The design team was concerned that if we include a partial mobility > feature, that other mobility requirements would creep in. Mobility was > not an original feature of the protocol. It is certainly something that > could be added later if it proves useful and we have consensus on those > requirements. Fair enough. > >> 4. Section 6.1.2, 1st paragraph. "Before 3/4 of the lifetime..." I >> never understood this 3/4 thing (I do not either understand a similar >> rule for SIP registration). Wouldn't it be more efficient to have the >> rule saying "16 times the RTO if using UDP or 7900ms if using TCP before >> the expiration of the lifetime timer..." > > The LIFETIME is related to the lifetime of the allocation, which has a > recommended default of 10 minutes. After 3/4 of this time (7.5 > *minutes*) the client is expected to refresh its allocation. > > This is completely orthogonal and unrelated to the amount of time a > client waits after sending a keepalive before determining that a flow is > dead (16x RTO for UDP); and it is also different from the amount of time > before a permission times out (typically about 30 seconds for UDP > allocations). I understand this. What I do not understand is the choice for the value 3/4. In the worst case (all UDP packets lost excepted for the last one), a Refresh request will be received by the server 63 * RTO milliseconds after the beginning of the transaction. If the last retransmission is not received, the allocation will expire and it does not matter if the transaction began (1/4 * lifetime) or (lifetime - 64 * RTO) before the expiration. So why do not use (lifetime - 64 * RTO) instead? > >> 5. Section 6.2.1.1, 3rd paragraph: "... the server allocates a port..." >> >> It cannot do this yet, as it has to first check the REQUESTED-IP and >> REQUESTED-PORT-PROPS attributes. More generally, I found turn-05 more >> difficult to read (from a developer point of view) than turn-04, because >> the text does not follow the flow of the code. > > good catch. if you could point out other places where the order is > different please let me know. OK, I finished my server implementation and I am currently working on the client side, so I'll send a more complete review after this. > >> 10. Section 8.1: Is there a good reason to have two reserved bytes and a >> length of 4 instead of no reserved bytes and a length of 2? > > To make the framing the same for all transports, and to insure we are > always aligned on a double word boundary. OK, but with length=2, the padding algorithm still align on a double word boundary. Not that it really matters, I am just curious about how the choice is made between reserved bits and padding. > >> 11. Sections 8.4, 8.6 and 8.9: What is the reason to xor-encode the IP >> address? > > To prevent it from being rewritten by a NAT with a "generic ALG". > How a generic ALG can rewrite an IP address assigned to the TURN server? And if a NAT can do this, then why do not also xor-encode ALTERNATE-SERVER in rfc3489bis? Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 20 03:52:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuOqj-0008AF-AX; Tue, 20 Nov 2007 03:52:53 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IuOqi-0008A9-Hg for behave-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 03:52:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuOqd-00089z-HF for behave@ietf.org; Tue, 20 Nov 2007 03:52:47 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuOqY-0003I8-Q2 for behave@ietf.org; Tue, 20 Nov 2007 03:52:47 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 306C4206A0 for ; Tue, 20 Nov 2007 09:52:42 +0100 (CET) X-AuditID: c1b4fb3c-b0e1cbb000002c9b-1d-4742a05a9702 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 159A72079E for ; Tue, 20 Nov 2007 09:52:42 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 09:52:41 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 09:52:41 +0100 Message-ID: <4742A059.2060900@ericsson.com> Date: Tue, 20 Nov 2007 09:52:41 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [BEHAVE] draft-ietf-behave-multicast-11: Discuss changes References: <47334183.4020605@ericsson.com> <47341B2A.1000800@ericsson.com> In-Reply-To: <47341B2A.1000800@ericsson.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2007 08:52:41.0582 (UTC) FILETIME=[B5B3A0E0:01C82B52] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org As there has been only positive feedback for the discuss clearing changes I will now approve this document. Magnus Magnus Westerlund skrev: > As you may have seen version 12 has appeared. It resolves the last > remaining issue by updating the following requirement addition (a): > > REQ-5: A NAT MUST forward IP multicast UDP datagrams from its > 'inside' interface(s) to its 'outside' interface. > > a: NATs which support the above requirement MUST also > provide a configuration option to disable this feature. > Otherwise, a multihomed network would cause duplicate > instances of the multicast data traffic on the public > network. > > To see all changes compared to 11 there is a diff: > > http://tools.ietf.org/wg/behave/draft-ietf-behave-multicast/draft-ietf-behave-multicast-12-from-11.diff.html > > Cheers > > Magnus > > > Magnus Westerlund skrev: >> Hi, >> >> We this document received a few discusses during when it was with the >> IESG. All issues except one was resolved by version 11. However, there >> was a major change in adding another requirement. >> >> REQ-7: The NAT MUST NOT forward Local Network Control Block >> (224.0.0/24) [RFC3171] (also known as "link-local >> multicast") traffic from its 'inside' interface(s) to its >> 'outside' interface. >> >> I want to check that no one in the WG has grief with this change. Please >> provide feedback at the latest the 19th of Nov. >> >> There are some more changes that can easily be reviewed in the diff: >> http://tools.ietf.org/wg/behave/draft-ietf-behave-multicast/draft-ietf-behave-multicast-11-from-10.diff.html >> >> There is still one issue remaining to be sorted out. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM/M >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 20 10:28:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuV10-0007Jq-2I; Tue, 20 Nov 2007 10:27:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IuV0x-0007HY-4h for behave-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:27:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuV0w-0007HM-QY; Tue, 20 Nov 2007 10:27:50 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuV0w-000611-GT; Tue, 20 Nov 2007 10:27:50 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 21AA1175AC; Tue, 20 Nov 2007 15:27:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuV0R-0007Wj-Lk; Tue, 20 Nov 2007 10:27:19 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 20 Nov 2007 10:27:19 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'IP Multicast Requirements for a Network Address (and port) Translator (NAT)' to BCP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The IESG has approved the following document: - 'IP Multicast Requirements for a Network Address (and port) Translator (NAT) ' as a BCP This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-12.txt Technical Summary In order for IP multicast applications to function well over NATs, multicast UDP must work as seamlessly as unicast UDP. However, NATs have little consistency in IP multicast operation which results in inconsistent user experiences and failed IP multicast operation. This document targets requirements intended to enable correct operations of Any Source Multicast and Source-Specific Multicast in devices running IGMP proxy routing and NAT and without applying NAT to IP multicast group addresses. This profile of functionality is the expected best practice for residential access routers small branch routers or similar deployments. Working Group Summary There was a consensus in the WG to publish this document. Document Quality This document was reviewed by both BEHAVE WG participants as well as participants from the MAGMA WG. This has resulted in a well reviewed document that addresses both the multicast and NAT aspects very well. Personnel This document was shepherd by the responsible AD Magnus Westerlund due to the author being WG chair. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 20 16:50: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 1Iuayx-0005wi-8P; Tue, 20 Nov 2007 16:50:11 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iuayv-0005wJ-GF for behave-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 16:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuayu-0005w9-Ls for behave@ietf.org; Tue, 20 Nov 2007 16:50:08 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuayp-00040b-0Z for behave@ietf.org; Tue, 20 Nov 2007 16:50:08 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 20 Nov 2007 13:50:02 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAKLo2ln031694 for ; Tue, 20 Nov 2007 13:50:02 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAKLnvUV001472 for ; Tue, 20 Nov 2007 21:50:02 GMT From: "Dan Wing" To: Date: Tue, 20 Nov 2007 13:49:56 -0800 Message-ID: <0d6001c82bbf$4dd45c90$91da46ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acgrv0p6YbQ8F25iSZ2/sX5R5USPHQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1217; t=1195595402; x=1196459402; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20draft=20agenda=20posted |Sender:=20; bh=PDpxlOuq0M0s2J/R16wvbiSzDbtmhwhprLG6RgHtWBs=; b=OwIBCzgGhFX9/+RLTqjLe8otLhBKU6ZNigS26jdn/kck25etM5ISwZqvJcG9VDicrwfGeuwQ +3QinLN7qzXJ5Ss26SOTOgYDJmmBLo96X98TzHNdieyRFDzyGJVpalSmRccHZI8eAdNvpWUUiX qyOKsLQRXYYQbw1CjpdRt62Sg=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [BEHAVE] draft agenda posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The tentative agenda for BEHAVE is now available at: http://www3.ietf.org/proceedings/07dec/agenda/behave.html -d ----- BEHAVE Agenda -- IETF 70, Vancouver TUESDAY, December 4, 15:20-17:20 *** DRAFT AGENDA *** Chair: Dan Wing, dwing@cisco.com 15:20 Agenda, milestones, and document status (Chair, 10) 15:30 TURN (Jonathan Rosenberg, 45) draft-ietf-behave-turn-05 16:15 TURN-TCP (Rohan Mahy, 15) draft-ietf-behave-turn-tcp-00 16:30 NAT Behavior Discovery (Bruce Lowekamp, 10) draft-ietf-behave-nat-behavior-discovery-02 16:40 SCTP (Michael Tuexen and Randall Stewart, 15) draft-stewart-behave-sctpnat-03 draft-xie-behave-sctp-nat-cons-03 16:55 Firewall Control for Public Access Networks (Hesham Soliman, 15) draft-soliman-firewall-control-00 17:10 Extending TURN to allow TCP servers without SIP (Mikael Latvala, 10) no draft 17:20 end *** DRAFT AGENDA *** (agenda version: 0.2) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 20 17:18: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 1IubQH-0005BR-Q2; Tue, 20 Nov 2007 17:18:26 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IubQF-00057Z-BU for behave-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 17:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IubQE-00054N-8X for behave@ietf.org; Tue, 20 Nov 2007 17:18:22 -0500 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IubQA-00054L-3z for behave@ietf.org; Tue, 20 Nov 2007 17:18:21 -0500 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 7CD4619C6009; Tue, 20 Nov 2007 14:18:17 -0800 (PST) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 5C8712809D; Tue, 20 Nov 2007 14:18:17 -0800 (PST) X-AuditID: 11807130-a93afbb000006ed1-22-47435d2925ba Received: from [17.151.111.218] (unknown [17.151.111.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id B05BB2809A; Tue, 20 Nov 2007 14:18:16 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: james woodyatt Subject: Re: [BEHAVE] RE: Firewall control Date: Tue, 20 Nov 2007 14:18:05 -0800 To: IPv6 Operations , Behave WG X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Nov 16, 2007, at 07:34, Melinda Shore wrote: > On 11/16/07 10:27 AM, "R=E9mi Denis-Courmont" courmont@nokia.com> wrote: >> Uh? UPnP is about mapping external ports to internal ones, and =20 >> getting the >> external address of the middlebox. Now, if that's not NAT centric... > > The last time I looked at it it also included firewall pinholing. There are hints that UPnP IGD 2.0 may support firewall pinholing in =20 IPv6 whenever it's eventually published. I have seen no public =20 documents yet, but I would be very surprised if this feature is =20 inserted into the specification by any method beyond the =20 straightforward method of extended the XML schemas to allow IPv6 =20 addresses and, possibly, to note that no NAT is necessary. >> A firewall that has an "advanced" policy such as what you'll find =20 >> in a typical >> corporate network most certainly does not want to be controlled =20 >> anyway. > > Back when we were trying to figure out what to call this work there > was a strong "suggestion" from Scott Bradner to call it "middlebox > communication" because we didn't want to imply that the endpoint or > its proxy was actually going to be controlling anything. The problem > here isn't to allow applications to open pinholes on firewalls, but > rather for applications to request these network resources, give the > network/firewall sufficient information to say "yes" or "no," and > give the network a mechanism to communicate its decision back to the > endpoint. I'd like to point out that my ALD proposal is very deliberately =20 presented with an inverted perspective on this. The problem I tried =20 to address is to give the stateful firewall a chance to discover =20 application endpoint addresses that policy requires it to exempt from =20= the general prohibition on blocking incoming packets not conforming =20 to any existing state created by tracking the flow of outbound packets. ALD is absolutely *NOT* a mechanism for applications to "control" =20 firewalls, or even to "request" firewalls to open pinholes for them. =20= It is a mechanism for firewalls to discover application listeners, so =20= that incoming flows for those applications can be delivered to them =20 properly, even when applications don't know in advance where those =20 flows will originate. Notice that ALD notifications go from nodes to =20= firewalls, and acknowledgements are sent by firewalls solely for the =20 purpose of telling nodes to stop sending notification retries. No =20 information is provided by firewalls to applications beyond that. =20 This is quite intentional. I think firewalls should be as transparent as possible, except when =20 policy requires them to intervene. In my humble opinion, ALD's primary virtue is that it correctly =20 places the burden on the firewall not to destroy network transparency =20= unnecessarily. To that end, it aims to define a way for IPv6 node =20 implementations to provide firewalls with enough information to =20 behave transparently in the face of passive listening applications. =20 It does not try to inform applications of the state of firewalls in =20 the network. We all still think applications shouldn't have to care, right? I also think it's worth noting that any proposal for nodes/=20 applications to communicate with firewalls to solve these sorts of =20 problems will inevitably involve disclosing the addresses of =20 application passive listener endpoints when their users may not be =20 expecting it. I don't know how to prevent that from happening and =20 still comply with the recommendations described in RFC 4864 and =20 expanded in draft-ietf-v6ops-cpe-simple-security, but I don't think =20 many participants here think this is a sensible security =20 consideration. Furthermore, I suspect many network operators will be =20= very interested in mining the information stream produced by =20 protocols of this class. This is another virtue of ALD. It gives operators the potential for =20 some snooping goodness they can't get with current IPv6 =20 implementations, and it does so *without* larding their firewalls =20 down with a lot of extra work trying to inform applications of things =20= they shouldn't need to know. -- james woodyatt member of technical staff, communications engineering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 21 07:37:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuopq-0002Cu-FY; Wed, 21 Nov 2007 07:37:42 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iuopo-0002Ch-6G for behave-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 07:37:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuopn-0002CT-IL for behave@ietf.org; Wed, 21 Nov 2007 07:37:39 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuopj-0003RB-7V for behave@ietf.org; Wed, 21 Nov 2007 07:37:39 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Nov 2007 07:37:33 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALCbWEo010621; Wed, 21 Nov 2007 07:37:32 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALCbSKH010853; Wed, 21 Nov 2007 12:37:28 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 07:37:28 -0500 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Nov 2007 12:37:28 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 21 Nov 2007 07:37:26 -0500 Subject: Re: [BEHAVE] RE: Firewall control From: Melinda Shore To: james woodyatt , IPv6 Operations , Behave WG Message-ID: Thread-Topic: [BEHAVE] RE: Firewall control Thread-Index: AcgsO0V0hDuw9JguEdyySgAKleNSdA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 12:37:28.0595 (UTC) FILETIME=[47003E30:01C82C3B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1082; t=1195648653; x=1196512653; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20RE=3A=20Firewall=20control |Sender:=20 |To:=20james=20woodyatt=20, =20IPv6=20Operations=20,=0A=20=20=20=20=20=20=20=20Behave=20WG=20; bh=WaqwRAL53m7rcmg4yqpUBTnWXnKrhZX6Is+uCtAruig=; b=XVhIy838drb9+gjwfMN7KXN2J/FpLZMF1aFyO8M9y/uMMKA/NDqnPmFMv964EJ3Cczk+CHAp BnqU6NehlXiagz5O1aZWfF6sgHm5eTQV3l79yfNv7q6HsfYmTRN3a9eM; Authentication-Results: rtp-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 11/20/07 5:18 PM, "james woodyatt" wrote: > In my humble opinion, ALD's primary virtue is that it correctly > places the burden on the firewall not to destroy network transparency > unnecessarily. Sure - that was a goal of midcom, too (restore some measure of endy-to-endiness). However, the problems that go along with that include necessarily include things that make the network even more visible still, like topology awareness (where is the firewall, and how do you choose the right one?). Those ancillary problems remain unsolved and largely unaddressed, and it's difficult to understand why there's an interest in another protocol to do the same thing a bunch of others do (existing "off-path" firewall protocols include [but are not limited to] midcom, SIMCO, and UPnP IGD) while the all the problems they generate have not been resolved. Because there's no NAT involved v6 firewalling might be one place where a path-coupled approach might actually be deployable, assuming the authorization problems could be addressed. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 21 07:42: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 1Iuou8-000882-KO; Wed, 21 Nov 2007 07:42:08 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iuou6-00083l-Kv for behave-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 07:42:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuou6-00081R-2t; Wed, 21 Nov 2007 07:42:06 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iuou5-0007Q9-2g; Wed, 21 Nov 2007 07:42:05 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6f4744a6cb; Wed, 21 Nov 2007 20:55:02 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm136473f449a; Sun, 18 Nov 2007 02:53:58 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sun, 18 Nov 2007 02:53:58 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItRUb-00033q-Mo; Sat, 17 Nov 2007 12:30:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItRUY-00033T-Dq; Sat, 17 Nov 2007 12:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItRUY-0005sh-0g; Sat, 17 Nov 2007 12:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DABF0327BF; Sat, 17 Nov 2007 17:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItRUX-0004LU-P5; Sat, 17 Nov 2007 12:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 17 Nov 2007 12:30:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-05.txt X-BeenThere: behave@ietf.org Reply-To: internet-drafts@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-05.txt Pages : 39 Date : 2007-11-17 This specification defines an extension of the Session Traversal Utilities for NAT (STUN) Protocol for asking the STUN server to relay packets towards a client. This extension, called Traversal Using Relays around NAT (TURN), is useful for hosts behind address dependent NATs. The extension purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers on ports obtained from the TURN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-turn-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-turn-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-17122109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-17122109.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Wed Nov 21 09:05:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqCH-0006tf-DV; Wed, 21 Nov 2007 09:04:57 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IuqCF-0006oP-6r for behave-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:04:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqCE-0006oH-NO for behave@ietf.org; Wed, 21 Nov 2007 09:04:54 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqCE-0001qd-Bc for behave@ietf.org; Wed, 21 Nov 2007 09:04:54 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IuqCD-0007dr-2P; Wed, 21 Nov 2007 09:04:53 -0500 In-Reply-To: <47428582.7080105@acm.org> References: <162D57F8-5097-4DF9-8844-33063D443966@magma.ca> <47421A43.8000400@acm.org> <47428582.7080105@acm.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8728F3B5-D96C-41AE-B952-5A47EA8A4E4F@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] draft-ietf-behave-turn-05 Date: Wed, 21 Nov 2007 09:06:19 -0500 To: Marc Petit-Huguenin 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: 21c69d3cfc2dd19218717dbe1d974352 Cc: Rohan Mahy , Behave WG , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 20-Nov-07, at 01:58 , Marc Petit-Huguenin wrote: > Hi Rohan, > > Thanks for your answers. More comments below. > > Rohan Mahy wrote: >> >> On Nov 19, 2007, at 3:20 PM, Marc Petit-Huguenin wrote: >> >>> Some comments and questions: >>> 3. Section 6.1.2: Refresh Requests: I see that the possibility of >>> moving an allocation to a different tuple was completely removed >>> in this >>> draft (see paragraph 7 of section 6.1.2.1 of turn-04). Why? >> >> The design team was concerned that if we include a partial mobility >> feature, that other mobility requirements would creep in. Mobility >> was >> not an original feature of the protocol. It is certainly >> something that >> could be added later if it proves useful and we have consensus on >> those >> requirements. > > Fair enough. The design team is very interested in trying to get the portion of TURN that people want today done ASAP. For that reason, we split UDP and TCP allocations (because we felt that the demand today is for UDP allocations, not TCP allocations) and that is also the reason we pulled the mobility feature (we didn't see anyone wanting to use it today). We debated both of these actions, and the decision on both was taken late in the game, but we feel we have made the right decision. Basically, we don't want the base TURN spec held up over anything that people don't want right now. If we are wrong in our assessment of what is really important now, please let us know. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 21 13:44:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuYE-0004Ar-KG; Wed, 21 Nov 2007 13:43:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IuuYC-0004Al-Rz for behave-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 13:43:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuYC-0004Ad-IM for behave@ietf.org; Wed, 21 Nov 2007 13:43:52 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuuYA-0007E0-7x for behave@ietf.org; Wed, 21 Nov 2007 13:43:52 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2007 10:43:49 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lALIhnTq016899; Wed, 21 Nov 2007 10:43:49 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lALIhm0W028082; Wed, 21 Nov 2007 18:43:48 GMT From: "Dan Wing" To: Date: Wed, 21 Nov 2007 10:43:48 -0800 Message-ID: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcgsbnPriamrYHeSSG60AIshISHnZw== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=630; t=1195670629; x=1196534629; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20adopt=20STUN=20test=20vectors? |Sender:=20; bh=FFXb+GvGRDFKuFE2h8ixRIjbPBmBceMCZ4cEsfv0pPw=; b=dkfR/lwEdYjg9bVgnJiG7OqC7QubcsDyR1IeZU5ilSK4iu/nNCxPCzAQzCh0WL5VlwB13jab EzFB+0Nf2Q3U826JPJhOU9xv6yMQ+Q9XhiV4vu/plM4/UBqMkZgw9on7; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [BEHAVE] adopt STUN test vectors? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org We don't have a milestone for STUN test vectors and it probably falls a bit outside of the as-written charter, but before we try to change those: is there interest in adopting Remi's "Test vectors for RFC3489bis", draft-denis-behave-rfc3489bis-test-vectors-02 as a working group item for BEHAVE? It's 6 pages, please skim it: http://www.ietf.org/internet-drafts/draft-denis-behave-rfc3489bis-test-vectors -02.txt Before adopting it, I will need to get approval from our ADs to add another milestone and adjust the charter accordingly. But I wanted to poll first to see if we should try doing that. Thanks, -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 21 14:57:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuvh0-0001EE-Ef; Wed, 21 Nov 2007 14:57:02 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iuvgy-0001Dr-VG for behave-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 14:57:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuvgy-0001Dj-En for behave@ietf.org; Wed, 21 Nov 2007 14:57:00 -0500 Received: from smtp5.freeserve.com ([193.252.22.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuvgr-0001OE-3l for behave@ietf.org; Wed, 21 Nov 2007 14:57:00 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3427.me.freeserve.com (SMTP Server) with ESMTP id 2FAED1C00086; Wed, 21 Nov 2007 20:56:52 +0100 (CET) Received: from Codalogic (user-514dddcd.l4.c2.dsl.pol.co.uk [81.77.221.205]) by mwinf3427.me.freeserve.com (SMTP Server) with ESMTP id 38DF51C0008E; Wed, 21 Nov 2007 20:56:51 +0100 (CET) X-ME-UUID: 20071121195651233.38DF51C0008E@mwinf3427.me.freeserve.com Message-ID: <001601c82c78$a6e2fad0$a100a8c0@Codalogic> From: "Pete Cordell" To: "Dan Wing" References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> Subject: Re: [BEHAVE] adopt STUN test vectors? Date: Wed, 21 Nov 2007 19:56:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Has it been discussed whether the tests vectors could just be added as an appendix to rfc3489bis? It would only amount to about 3 pages of extra text, and other specs, such as UTF-8 and base64 include such test vectors. BTW - Wikipedia and I think FINGERPRINT should refer Cyclic Redundancy Check, as opposed to Circular Redundancy Check. Cheers, Pete. -- ============================================= Pete Cordell Codalogic http://www.codalogic.com/ ============================================= ----- Original Message ----- From: "Dan Wing" To: Sent: Wednesday, November 21, 2007 6:43 PM Subject: [BEHAVE] adopt STUN test vectors? > We don't have a milestone for STUN test vectors and it probably falls a > bit > outside of the as-written charter, but before we try to change those: is > there interest in adopting Remi's "Test vectors for RFC3489bis", > draft-denis-behave-rfc3489bis-test-vectors-02 as a working group item for > BEHAVE? It's 6 pages, please skim it: > > http://www.ietf.org/internet-drafts/draft-denis-behave-rfc3489bis-test-vectors > -02.txt > > Before adopting it, I will need to get approval from our ADs to add > another > milestone and adjust the charter accordingly. But I wanted to poll first > to > see if we should try doing that. > > Thanks, > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 22 04:29: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 1Iv8NT-0003OE-LG; Thu, 22 Nov 2007 04:29:43 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iv8NS-0003Nj-JB for behave-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 04:29:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv8NR-0003LA-Qy for behave@ietf.org; Thu, 22 Nov 2007 04:29:41 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv8NO-0000az-68 for behave@ietf.org; Thu, 22 Nov 2007 04:29:41 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6BF4020A87; Thu, 22 Nov 2007 10:28:37 +0100 (CET) X-AuditID: c1b4fb3c-ae794bb0000030cf-50-47454bc59296 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5BCEA209A9; Thu, 22 Nov 2007 10:28:37 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 10:28:37 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 10:28:36 +0100 Message-ID: <47454BC4.6090909@ericsson.com> Date: Thu, 22 Nov 2007 10:28:36 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] adopt STUN test vectors? References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> In-Reply-To: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2007 09:28:36.0999 (UTC) FILETIME=[0F41A970:01C82CEA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I have discussed this with my Co-AD Lars and I think we can squeeze this in without any charter changes. So lets discuss the main question. Is it a useful enough document that the WG should be responsible to produce it. Regarding putting that into a STUN appendix that it a bit late as STUNbis is on the IESG telechat agenda for next week. Cheers Magnus Dan Wing skrev: > We don't have a milestone for STUN test vectors and it probably falls a bit > outside of the as-written charter, but before we try to change those: is > there interest in adopting Remi's "Test vectors for RFC3489bis", > draft-denis-behave-rfc3489bis-test-vectors-02 as a working group item for > BEHAVE? It's 6 pages, please skim it: > > http://www.ietf.org/internet-drafts/draft-denis-behave-rfc3489bis-test-vectors > -02.txt > > Before adopting it, I will need to get approval from our ADs to add another > milestone and adjust the charter accordingly. But I wanted to poll first to > see if we should try doing that. > > Thanks, > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 22 05:01: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 1Iv8rw-00047d-Uq; Thu, 22 Nov 2007 05:01:12 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iv8rv-00047T-P4 for behave-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 05:01:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv8rv-00047L-AY for behave@ietf.org; Thu, 22 Nov 2007 05:01:11 -0500 Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv8ru-0007AV-Ua for behave@ietf.org; Thu, 22 Nov 2007 05:01:11 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3201.me.freeserve.com (SMTP Server) with ESMTP id 661ED7000084; Thu, 22 Nov 2007 11:01:10 +0100 (CET) Received: from Codalogic (user-514dddcd.l4.c2.dsl.pol.co.uk [81.77.221.205]) by mwinf3201.me.freeserve.com (SMTP Server) with ESMTP id C173D700008B; Thu, 22 Nov 2007 11:01:07 +0100 (CET) X-ME-UUID: 20071122100107792.C173D700008B@mwinf3201.me.freeserve.com Message-ID: <002101c82cee$98ea0010$a100a8c0@Codalogic> From: "Pete Cordell" To: "Magnus Westerlund" , "Dan Wing" References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> <47454BC4.6090909@ericsson.com> Subject: Re: [BEHAVE] adopt STUN test vectors? Date: Thu, 22 Nov 2007 10:00:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org ----- Original Message From: "Magnus Westerlund" > Regarding putting that into a STUN appendix that it a bit late as > STUNbis is on the IESG telechat agenda for next week. The IESG could always make the review comment that the test vectors should be added to STUNbis! That shouldn't delay STUNbis at all. My concern is that if the test vectors are published as a separate document nobody outside of the IETF inner core will ever know about them. If the document is stand-alone, then I think it should be more comprehensive, including error responses, and possibly even mal-formed requests etc. etc. my 2 cents, Pete Cordell -- Codalogic Visit http://www.codalogic.com/ for XSD to C++ data binding _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Nov 24 06:35:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtHq-0006yY-4V; Sat, 24 Nov 2007 06:35:02 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IvtHo-0006yE-Cg for behave-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:35:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtHj-0006xy-8a; Sat, 24 Nov 2007 06:34:55 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvtHf-0006v9-3R; Sat, 24 Nov 2007 06:34:55 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2e47483318; Sat, 24 Nov 2007 19:47:48 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2ad47419c5a; Mon, 19 Nov 2007 21:12:40 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 21:12:40 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65H-0004jS-QN; Mon, 19 Nov 2007 07:50:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65B-0004dz-GB; Mon, 19 Nov 2007 07:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu65B-0004fP-3F; Mon, 19 Nov 2007 07:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B2E7C175C1; Mon, 19 Nov 2007 12:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu64g-0001ok-8Y; Mon, 19 Nov 2007 07:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 07:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-p2p-state-06.txt X-BeenThere: behave@ietf.org Reply-To: internet-drafts@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-p2p-state-06.txt Pages : 32 Date : 2007-11-19 This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-p2p-state-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-p2p-state-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19074427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-p2p-state-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-p2p-state-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19074427.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Sat Nov 24 16:02: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 1Iw28R-0007FD-IE; Sat, 24 Nov 2007 16:01:55 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iw28Q-0007F6-Dg for behave-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 16:01:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw28Q-0007Ey-4E for behave@ietf.org; Sat, 24 Nov 2007 16:01:54 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw28N-0001wa-HO for behave@ietf.org; Sat, 24 Nov 2007 16:01:54 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id DC3A4D9D4038; Sat, 24 Nov 2007 13:01:50 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 3D6B87F001C for ; Sat, 24 Nov 2007 13:01:48 -0800 (PST) Message-ID: <4748913B.8090806@acm.org> Date: Sat, 24 Nov 2007 13:01:47 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [BEHAVE] Transport of ICMP errors in TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org draft-ietf-mmusic-ice-17 section 7.1.2.1 says that "[a]gents MAY support receipt of ICMP errors for connectivity check." Unfortunately there is no way to receive a ICMP error when the connectivity check is carried over TURN. Here's an example: +------ Client -----+ ICE Turn client Turn Server Peer | Binding Req | | | |------------>| 0 Send(123, peer, Binding Req) | | | |--------------------------------->| Binding Req | | | 0 Channel Confirmation Ind(123) |-------------->| | |<---------------------------------| ICMP 3 | | | |<--------------| | Binding Req | | | |------------>| 123 Binding Req | | | |--------------------------------->| Binding Req | | | |-------------->| | | | ICMP 3 | | | |<--------------| : : : : I suggest to add a new indication that will carry the ICMP content to the TURN client so the Binding transaction can fail earlier: +------ Client -----+ ICE Turn client Turn Server Peer | Binding Req | | | |------------>| 0 Send(123, peer, Binding Req) | | | |--------------------------------->| Binding Req | | | 0 Channel Confirmation Ind(123) |-------------->| | |<---------------------------------| ICMP 3 | | | 0 Icmp Ind(source, data) |<--------------| | ICMP 3 |<---------------------------------| | |<------------| | | The new indication contains a PEER-ADDRESS attribute that contain the source IP address/port of the ICMP packet, some other attributes to carry the ICMP values (type, code and next-hop MTU) and a DATA attribute that contain the data copied from the original UDP packet. The ICMP spec mandates to copy only the IP header and 8 additional bytes, i.e. the UDP header, which should be enough to match the Binding transaction if there is only one pending. Some IP implementations returns even more data, so the STUN transaction Id could be available to find the transaction. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 26 12:16: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 1IwhZe-0007sB-3b; Mon, 26 Nov 2007 12:16:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IwhZb-0007in-3T for behave-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:16:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhZa-0007h8-Ce; Mon, 26 Nov 2007 12:16:42 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhZV-0004TA-4O; Mon, 26 Nov 2007 12:16:42 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 087AD327BD; Mon, 26 Nov 2007 17:16:37 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IwhZU-0007sp-UN; Mon, 26 Nov 2007 12:16:36 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 26 Nov 2007 12:16:36 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Document Action: 'State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs)' to Informational RFC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The IESG has approved the following document: - 'State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) ' as an Informational RFC This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-06.txt Technical Summary This memo documents the various methods known to be in use by applications to establish direct UDP or TCP communication in the presence of Network Address Translators (NATs). Working Group Summary Agreeing on RFC3489 terminology (which is well known) versus RFC4787 terminology (which is more accurate but longer) involved some controversy. Consensus was to use RFC4787 terminology. Document Quality This document have had descent review in the WG. The techniques in this document are implemented in various software that traverses NATs. Personnel Document shepherd: Dan Wing, dwing@cisco.com Responsible AD: Magnus Westerlund, magnus.westerlund@ericsson.com Note to RFC Editor Please update the reference to RFC 3041 to RFC 4941. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 26 14:33:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjiP-0001b4-Qw; Mon, 26 Nov 2007 14:33:57 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IwjiO-0001ay-Kl for behave-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:33:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjiO-0001aq-Ac for behave@ietf.org; Mon, 26 Nov 2007 14:33:56 -0500 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwjiL-0001C8-Q2 for behave@ietf.org; Mon, 26 Nov 2007 14:33:56 -0500 Received: by nz-out-0506.google.com with SMTP id n1so442873nzf for ; Mon, 26 Nov 2007 11:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=f8hpkduZJfFFYhj6YprS50xRonwl0ocITGWd7Q0Wn04=; b=vK1DK15tZUYkOgpMXaRaXe8B2zHpIQOooAoORKRVWBY/JQX5+lzWaKui85Iz2I0b9ip24cHpt2NCIySuVW7Pstkjoc2KrZ0eb3c04FB6gjex31bs09QwNtizQMZERH3brHsJHPf6u9NqwN+YmR3hy0zwHdLEgRSwfVoVl94GYqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DHWp9ZPdSzHdXOg2xrKXySQkwBk7M+iY1FvkTN2YAPkcKKI0VJFMhUTUXZusllxh4oCr7FC1IeFGkZEPT/NXkRFpoUSDo6GSNzA/1klznNz64hKQ4z2emSkfMfsfK5P9Maiu2toCqJORY9jWDLg8ySkBMC5RFPzv9t+87liCnw8= Received: by 10.142.154.20 with SMTP id b20mr599748wfe.1196105632428; Mon, 26 Nov 2007 11:33:52 -0800 (PST) Received: by 10.142.214.15 with HTTP; Mon, 26 Nov 2007 11:33:52 -0800 (PST) Message-ID: <953beacc0711261133h5c5f219eyb9ec772b1cc44510@mail.gmail.com> Date: Mon, 26 Nov 2007 11:33:52 -0800 From: "Rohan Mahy" To: "Dan Wing" Subject: Re: [BEHAVE] draft agenda posted In-Reply-To: <0d6001c82bbf$4dd45c90$91da46ab@cisco.com> MIME-Version: 1.0 References: <0d6001c82bbf$4dd45c90$91da46ab@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0197057390==" Errors-To: behave-bounces@ietf.org --===============0197057390== Content-Type: multipart/alternative; boundary="----=_Part_6257_3050156.1196105632418" ------=_Part_6257_3050156.1196105632418 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Dan, Can you provide a pointer to the discussion related to the last agenda item? After searching through my archives of the BEHAVE mailing list, I am not finding anything that looks like this. If it hasn't been discussed on the list and there is no draft, I think we should skip it. thanks, -rohan On Nov 20, 2007 1:49 PM, Dan Wing wrote: > The tentative agenda for BEHAVE is now available at: > > http://www3.ietf.org/proceedings/07dec/agenda/behave.html > > -d > > ----- > > BEHAVE Agenda -- IETF 70, Vancouver > TUESDAY, December 4, 15:20-17:20 > > > *** DRAFT AGENDA *** > > Chair: Dan Wing, dwing@cisco.com > > 15:20 Agenda, milestones, and document status (Chair, > 10) > > 15:30 TURN (Jonathan Rosenberg, > 45) > draft-ietf-behave-turn-05 > > 16:15 TURN-TCP (Rohan Mahy, > 15) > draft-ietf-behave-turn-tcp-00 > > 16:30 NAT Behavior Discovery (Bruce Lowekamp, > 10) > draft-ietf-behave-nat-behavior-discovery-02 > > 16:40 SCTP (Michael Tuexen and Randall Stewart, > 15) > draft-stewart-behave-sctpnat-03 > draft-xie-behave-sctp-nat-cons-03 > > 16:55 Firewall Control for Public Access Networks (Hesham Soliman, > 15) > draft-soliman-firewall-control-00 > > 17:10 Extending TURN to allow TCP servers without SIP (Mikael Latvala, > 10) > no draft > > 17:20 end > > *** DRAFT AGENDA *** > > (agenda version: 0.2) > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_6257_3050156.1196105632418 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Dan,

Can you provide a pointer to the discussion related to the last agenda item?  After searching through my archives of the BEHAVE mailing list, I am not finding anything that looks like this.

If it hasn't been discussed on the list and there is no draft, I think we should skip it.

thanks,
-rohan

On Nov 20, 2007 1:49 PM, Dan Wing <dwing@cisco.com> wrote:
The tentative agenda for BEHAVE is now available at:

http://www3.ietf.org/proceedings/07dec/agenda/behave.html

-d

-----

                       BEHAVE Agenda -- IETF 70, Vancouver
                         TUESDAY, December 4, 15:20-17:20


*** DRAFT AGENDA ***

Chair: Dan Wing, dwing@cisco.com

15:20  Agenda, milestones, and document status                   (Chair, 10)

15:30  TURN                                         (Jonathan Rosenberg, 45)
        draft-ietf-behave-turn-05

16:15  TURN-TCP                                             (Rohan Mahy, 15)
        draft-ietf-behave-turn-tcp-00

16:30  NAT Behavior Discovery                           (Bruce Lowekamp, 10)
        draft-ietf-behave-nat-behavior-discovery-02

16:40  SCTP                         (Michael Tuexen and Randall Stewart, 15)
        draft-stewart-behave-sctpnat-03
        draft-xie-behave-sctp-nat-cons-03

16:55  Firewall Control for Public Access Networks      (Hesham Soliman, 15)
        draft-soliman-firewall-control-00

17:10  Extending TURN to allow TCP servers without SIP  (Mikael Latvala, 10)
        no draft

17:20  end

*** DRAFT AGENDA ***

(agenda version: 0.2)



_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave

------=_Part_6257_3050156.1196105632418-- --===============0197057390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0197057390==-- From behave-bounces@ietf.org Mon Nov 26 14:46:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjv0-0007UC-R2; Mon, 26 Nov 2007 14:46:58 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iwjv0-0007U6-0R for behave-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:46:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjuz-0007Tw-La for behave@ietf.org; Mon, 26 Nov 2007 14:46:57 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwjuz-0003Mr-7B for behave@ietf.org; Mon, 26 Nov 2007 14:46:57 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Nov 2007 11:46:56 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAQJkutm002309; Mon, 26 Nov 2007 11:46:56 -0800 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQJkuus005592; Mon, 26 Nov 2007 19:46:56 GMT From: "Dan Wing" To: "'Rohan Mahy'" References: <0d6001c82bbf$4dd45c90$91da46ab@cisco.com> <953beacc0711261133h5c5f219eyb9ec772b1cc44510@mail.gmail.com> Subject: RE: [BEHAVE] draft agenda posted Date: Mon, 26 Nov 2007 11:46:55 -0800 Message-ID: <0c6701c83065$19cd3c50$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <953beacc0711261133h5c5f219eyb9ec772b1cc44510@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgwY0zk9YTdmVNMR6+qfhpe3A+mXwAASd5w DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2528; t=1196106416; x=1196970416; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20draft=20agenda=20posted |Sender:=20; bh=Loyxdsr/w9MPAgKFiOCRvZ+juT/cZHfB6/yAZ8ENTg4=; b=WCeGkd20FvYn+dKRUD6jeE9H7icMcrHLQCzsstLto93cg13KREq8yNdwMMGql7D2g3a3adm3 va+FZ00uZ0B5nkX7aVaCuWWsTC9bDKhHH84V19Yo0IH90J6K6+ZAEqSaVd/UqciyAXkclJJUjI EVGcOdYkpACLeDHfmcuuKZQLQ=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Mikael.Latvala@nokia.com, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (For reference, Rohan is referencing the topic "Extending TURN to allow TCP servers without SIP", to be presented by Mikael Latvala.) Mikael sent me a summary of this topic and I asked him to start a discussion on the list. I have CC'd him as a reminder. -d > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > Sent: Monday, November 26, 2007 11:34 AM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] draft agenda posted > > Hi Dan, > > Can you provide a pointer to the discussion related to the > last agenda item? After searching through my archives of the > BEHAVE mailing list, I am not finding anything that looks like this. > > If it hasn't been discussed on the list and there is no > draft, I think we should skip it. > > thanks, > -rohan > > > On Nov 20, 2007 1:49 PM, Dan Wing wrote: > > > The tentative agenda for BEHAVE is now available at: > > http://www3.ietf.org/proceedings/07dec/agenda/behave.html > > -d > > ----- > > BEHAVE Agenda -- IETF 70, Vancouver > TUESDAY, December 4, 15:20-17:20 > > > *** DRAFT AGENDA *** > > Chair: Dan Wing, dwing@cisco.com > > 15:20 Agenda, milestones, and document status > (Chair, 10) > > 15:30 TURN > (Jonathan Rosenberg, 45) > draft-ietf-behave-turn-05 > > 16:15 TURN-TCP > (Rohan Mahy, 15) > draft-ietf-behave-turn-tcp-00 > > 16:30 NAT Behavior Discovery > (Bruce Lowekamp, 10) > draft-ietf-behave-nat-behavior-discovery-02 > > 16:40 SCTP (Michael Tuexen and > Randall Stewart, 15) > draft-stewart-behave-sctpnat-03 > draft-xie-behave-sctp-nat-cons-03 > > 16:55 Firewall Control for Public Access Networks > (Hesham Soliman, 15) > draft-soliman-firewall-control-00 > > 17:10 Extending TURN to allow TCP servers without SIP > (Mikael Latvala, 10) > no draft > > 17:20 end > > *** DRAFT AGENDA *** > > (agenda version: 0.2) > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 27 12:14: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 1Ix40X-0002qJ-Vy; Tue, 27 Nov 2007 12:14:01 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ix40W-0002q5-N0 for behave-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 12:14:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix40W-0002pt-9n for behave@ietf.org; Tue, 27 Nov 2007 12:14:00 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix40V-0005e0-MW for behave@ietf.org; Tue, 27 Nov 2007 12:14:00 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lARHDeut023935 for ; Tue, 27 Nov 2007 19:13:57 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:28:10 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:28:09 +0200 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 Date: Tue, 27 Nov 2007 17:28:09 +0200 Message-ID: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TURN solution for home networks Thread-Index: AcgxCh1+9URymT+cSTWhQT5klyzoAQ== From: To: X-OriginalArrivalTime: 27 Nov 2007 15:28:09.0973 (UTC) FILETIME=[1DD10250:01C8310A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [BEHAVE] TURN solution for home networks X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The current TURN specs says: "Though originally invented for Voice over IP applications, TURN is designed to be a general-purpose relay mechanism for NAT traversal." Unfortunately this is not that obvious when one reads the current TURN spec. This spec has the following limitations which make it unsuitable for scenarios where the home owner wants to access services in the home network from a remote location; 1. "[Client] needs to request each permission explicitly and one at a time."=20 There are two problems with this restriction. A. Home owner cannot know beforehand from which IP address (external IP address) s/he is going to access the home network. B. Even if home owner did magically know all the external IP addresses, all home automation and many AV based device would not be able to request such permissions, because there are no mechanisms how home owner could the devices what these external IP addresses are. 2. "A TURN server can then relay traffic between a reliable transport used between the client and server (TCP or TLS over TCP), and UDP used from server to peer." Limiting the transport protocol to UDP between server and peer means for example that peers behind corporate firewalls would not be able to access the TURN server. 3. Last but not least, it has been pointed out to me that IESG won't accept wordings such as=20 "This insures that a client can't use a TURN server to run a traditional server, and partially protects the client from DoS attacks." as these restrictions are outside the scope of this spec. There are three alternatives how we can correct the current situation and make TURN-type solution applicable also for home networks: 1. Modify the existing draft-ietf-behave-turn-XX.txt (considering how long the TURN work has been going on I see this very unlikely alternative) 2. Create a new BEHAVE sponsored draft which addresses the home network needs (Nokia preferred alternative) 3. Wait that some company creates an informational draft My plan is to discuss about these three different alternatives in Vancouver and hopefully get some kind of a rough consensus on how to go forward.=20 /Mikael _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 27 12:31:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4Hm-0003Lr-9C; Tue, 27 Nov 2007 12:31:50 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ix4Hl-0003LY-9W for behave-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 12:31:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4Hk-0003LE-VF for behave@ietf.org; Tue, 27 Nov 2007 12:31:48 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix4Hk-0000sQ-KL for behave@ietf.org; Tue, 27 Nov 2007 12:31:48 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id D5297D9D4040; Tue, 27 Nov 2007 09:31:47 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 85C3AD9D4040; Tue, 27 Nov 2007 09:31:45 -0800 (PST) Message-ID: <474C5480.4060303@acm.org> Date: Tue, 27 Nov 2007 09:31:44 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Mikael.Latvala@nokia.com Subject: Re: [BEHAVE] TURN solution for home networks References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> In-Reply-To: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Mikael.Latvala@nokia.com wrote: > The current TURN specs says: > [snip] > > 2. "A TURN server can then relay traffic between a reliable transport > used between the client and server (TCP or TLS over TCP), and UDP used > from server to peer." > > Limiting the transport protocol to UDP between server and peer means for > example that peers behind corporate firewalls would not be able to > access the TURN server. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-behave-turn-tcp-00.txt -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 27 14:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5jJ-0003oF-7t; Tue, 27 Nov 2007 14:04:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ix5jH-0003jD-Mq for behave-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:04:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5jH-0003j5-BR for behave@ietf.org; Tue, 27 Nov 2007 14:04:19 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix5jG-0008PO-Iq for behave@ietf.org; Tue, 27 Nov 2007 14:04:19 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id E1124D9D403A; Tue, 27 Nov 2007 11:04:17 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 589BED9D4038; Tue, 27 Nov 2007 11:04:15 -0800 (PST) Message-ID: <474C6A2E.6060600@acm.org> Date: Tue, 27 Nov 2007 11:04:14 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Behave WG Subject: Re: [BEHAVE] draft-ietf-behave-turn-05 References: <162D57F8-5097-4DF9-8844-33063D443966@magma.ca> <47421A43.8000400@acm.org> In-Reply-To: <47421A43.8000400@acm.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Rohan Mahy , Philip Matthews , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Continued... 13. Section 6.1.1 paragraph 5: "The client MUST include a REQUESTED-TRANSPORT attribute." This is inconsistent with section 6.2.1.1 paragraph 3 that says that "[i]f the request did not contain a REQUESTED-TRANSPORT attribute..." 14. Section 6.1.1 paragraph 6: "As an example, the Real Time Transport Protocol (RTP) [rfc3550]..." should be "...the Real-time Transport Protocol..." 15. Section 6.1.1 paragraph 6: "...the Real Time Transport Protocol (RTP) [RFC3550] requires that RTP and RTCP ports be an adjacent pair..." should be "...(RTP) [RFC3550] recommends that RTP and RTCP ports..." 16. Section 6.2.1.1 paragraph 3: "If the request did not contain a REQUESTED-TRANSPORT attribute, the server MUST use the same transport protocol as the request arrived on." Without the turn-tcp extension, if the request arrived on a TCP or TLS transport protocol without a REQUESTED-TRANSPORT, the server must reject the request with a 442. 17. Section 6.2.1.3 paragraph 3. This paragraph does not explain how to allocate the port that was reserved by a previous allocation. This is explained in section 8.7 but the text should add that the allocation of the reserved port must be done with the same tuple and same username/realm/password that was used to reserve it. 18. Section 6.2.1.4 paragraph 6: "Note that the LIFETIME attribute an Allocate request can be zero, though this is effectively a no-op." Why authorizing this, if it effectively does nothing? See also my comment #7 below. 19. Section 6.2.2 paragraph 2: "First, the request MUST be authenticated using the same shared secret as the one associated with the allocation." What happen if the user password is changed during an allocation? 20. Section 6.2.2 There is no explanation on what can be done after an allocation expires. Is it possible to create a new one? With the same username/realm/password? 21. Section 7.2.3 paragraph 2. I suggest to move this paragraph just after the first paragraph of section 7.2.2 22. Section 8.9 1st paragraph: "...so as to be able to allocate more than 64k transport addresses." should be "...more than 63k transport addresses." 23. Section 10. I suggest to add NAPTR (ala RFC 3263) processing to choose the preferred transport for a domain if it does not matter for the client. 24. Section 15 paragraph 12: I cannot find this discussion in the document. Thanks. Marc Petit-Huguenin wrote: > Some comments and questions: > > 1. Section 3, 1st paragraph: "...is connected to a private network and > through one or more NATs to the public Internet. On the public Internet..." > > There is no such thing as a non-public Internet. > > 2. Section 5: I think it would be better to integrate this whole > section in the Client/Server behavior, as one have to continuously read > back and forth between the client/server behavior sections and this section. > > 3. Section 6.1.2: Refresh Requests: I see that the possibility of > moving an allocation to a different tuple was completely removed in this > draft (see paragraph 7 of section 6.1.2.1 of turn-04). Why? > > 4. Section 6.1.2, 1st paragraph. "Before 3/4 of the lifetime..." I > never understood this 3/4 thing (I do not either understand a similar > rule for SIP registration). Wouldn't it be more efficient to have the > rule saying "16 times the RTO if using UDP or 7900ms if using TCP before > the expiration of the lifetime timer..." > > 5. Section 6.2.1.1, 3rd paragraph: "... the server allocates a port..." > > It cannot do this yet, as it has to first check the REQUESTED-IP and > REQUESTED-PORT-PROPS attributes. More generally, I found turn-05 more > difficult to read (from a developer point of view) than turn-04, because > the text does not follow the flow of the code. > > 6. Section 6.2.1.4 paragraph 6: "Note that the LIFETIME attribute an > Allocate request..." There is something missing in this sentence. > > 7. Section 6.2.1.4 paragraph 6: There is no error code defined to > reject a LIFETIME attribute too short. > > 8. Section 7.1.1 paragraph 5 and 6: "...receives a ChannelConfirmation > Indication..." Should be "Channel Confirmation indication" > > 9. Section 7.2.1: "When the server receives a Data indication..." should > be "...a Send indication" > > 10. Section 8.1: Is there a good reason to have two reserved bytes and a > length of 4 instead of no reserved bytes and a length of 2? > > 11. Sections 8.4, 8.6 and 8.9: What is the reason to xor-encode the IP > address? > > 12. Section 10: 2nd paragraph: '...instead of just "stun".' should be > '...instead of "stun".' > > > Thanks. > -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 27 20:38:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxBt9-0006Ev-Sl; Tue, 27 Nov 2007 20:38:55 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IxBt8-0006Ek-5N for behave-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 20:38:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxBt7-0006EZ-Qe for behave@ietf.org; Tue, 27 Nov 2007 20:38:53 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxBt7-00051z-ED for behave@ietf.org; Tue, 27 Nov 2007 20:38:53 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 Nov 2007 17:38:40 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAS1cc3J017124; Tue, 27 Nov 2007 17:38:38 -0800 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAS1cb75024477; Wed, 28 Nov 2007 01:38:38 GMT From: "Dan Wing" To: , References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> Subject: RE: [BEHAVE] TURN solution for home networks Date: Tue, 27 Nov 2007 17:38:32 -0800 Message-ID: <22cc01c8315f$63f45430$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgxCh1+9URymT+cSTWhQT5klyzoAQAU693w DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1877; t=1196213918; x=1197077918; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TURN=20solution=20for=20home=20networks |Sender:=20; bh=SwTxRDDTKq0KqpPFzixwSnWvZ2OfDKnxBKvRo6wIhEk=; b=sdKj5/u7oG/IUZsLlmuD9hNMbXhdBSnb3KWHipNdwIK1y3gnNG0QGuK7vYQUcUXN1GWzzdic KGeYOb/plJlqc2ebOCjWSmo5VcU5ZsUjLRO0P5y90QI3jcEN/uI8rcxlHqJ8XsW8VdX/RA/Y7z CbLsZlXQnTjxhzcuhM9UygyCY=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > 2. "A TURN server can then relay traffic between a reliable transport > used between the client and server (TCP or TLS over TCP), and UDP used > from server to peer." > > Limiting the transport protocol to UDP between server and > peer means for example that peers behind corporate firewalls > would not be able to access the TURN server. TURN does support the following scenario: Endpoint-A Endpoint-B TURN client---------TURN server---------peer ^ ^ | | TCP UDP This allows Endpoint-A to be behind a firewall that only allows outgoing TCP connections. If Endpoint-B is also behind a firewall that only allows TCP, Endpoint-B would also need to get a UDP address from its TURN server, resulting in a flow like this: Endpoint-A Endpoint-A's Endpoint-B's Endpoint-B TURN client-------TURN server-------TURN server-------peer ^ ^ ^ | | | TCP UDP TCP If you want TCP on the 'public' (peer) side of the TURN server, you need TURN-TCP as Marc mentioned. With TURN-TCP, you can do this: Endpoint-A Endpoint-A's Endpoint-B TURN client-------TURN server-------peer ^ ^ | | TCP TCP I would like folks to comment on your other points; the design decisions were made on purpose but if others are finding TURN won't meet their needs, we may need to have two 'profiles' of TURN; one that has the restriction described in TURN and another that does not require configuring permissions in the TURN server. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 27 22:21: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 1IxDUe-0003C1-B7; Tue, 27 Nov 2007 22:21:44 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IxDUd-0003Bo-FK for behave-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 22:21:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxDUc-0003Be-Kb for behave@ietf.org; Tue, 27 Nov 2007 22:21:42 -0500 Received: from [67.15.124.176] (helo=rakhan.thetiger.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxDUb-0000An-0Q for behave@ietf.org; Tue, 27 Nov 2007 22:21:42 -0500 Received: from [10.0.1.100] (c220-239-137-68.smelb1.vic.optusnet.com.au [220.239.137.68]) by rakhan.thetiger.com (Postfix) with ESMTP id B227F8A8651; Tue, 27 Nov 2007 20:34:32 -0600 (CST) Message-Id: <31582A4D-9948-447B-8C06-F5EE641B0B7E@thetiger.com> From: David Miles To: In-Reply-To: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN solution for home networks Date: Wed, 28 Nov 2007 14:21:28 +1100 References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: -0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Mikael, You mentioned work is needed to address the home network needs - would we be able to spend some time discussing these? I'm interested to know the drivers for TURN vs STUN as I would have thought TURN would have been an undesirable solution. Best Regards, -David On 28/11/2007, at 2:28 AM, wrote: > The current TURN specs says: > > "Though originally invented for Voice over IP applications, TURN is > designed to be a general-purpose relay mechanism for NAT traversal." > > Unfortunately this is not that obvious when one reads the current TURN > spec. This spec has the following limitations which make it unsuitable > for scenarios where the home owner wants to access services in the > home > network from a remote location; > > 1. "[Client] needs to request each permission explicitly and one at a > time." > > There are two problems with this restriction. > > A. Home owner cannot know beforehand from which IP address (external > IP > address) s/he is going to access the home network. > > B. Even if home owner did magically know all the external IP > addresses, > all home automation and many AV based device would not be able to > request such permissions, because there are no mechanisms how home > owner > could the devices what these external IP addresses are. > > 2. "A TURN server can then relay traffic between a reliable transport > used between the client and server (TCP or TLS over TCP), and UDP used > from server to peer." > > Limiting the transport protocol to UDP between server and peer means > for > example that peers behind corporate firewalls would not be able to > access the TURN server. > > 3. Last but not least, it has been pointed out to me that IESG won't > accept wordings such as > > "This insures that a client can't use a TURN server to run a > traditional > server, and partially protects the client from DoS attacks." > > as these restrictions are outside the scope of this spec. > > > There are three alternatives how we can correct the current situation > and make TURN-type solution applicable also for home networks: > > 1. Modify the existing draft-ietf-behave-turn-XX.txt (considering how > long the TURN work has been going on I see this very unlikely > alternative) > 2. Create a new BEHAVE sponsored draft which addresses the home > network > needs (Nokia preferred alternative) > 3. Wait that some company creates an informational draft > > My plan is to discuss about these three different alternatives in > Vancouver and hopefully get some kind of a rough consensus on how to > go > forward. > > /Mikael > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 28 13:00: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 1IxRCj-0000TC-NR; Wed, 28 Nov 2007 13:00:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IxRCi-0000Pw-P6 for behave-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 13:00:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRCi-0000Pn-EH for behave@ietf.org; Wed, 28 Nov 2007 13:00:08 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxRCh-0008Bz-W2 for behave@ietf.org; Wed, 28 Nov 2007 13:00:08 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Nov 2007 10:00:07 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lASI07W0009944; Wed, 28 Nov 2007 10:00:07 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lASHxwqr007702; Wed, 28 Nov 2007 18:00:07 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 10:00:04 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 10:00:04 -0800 Message-ID: <474DACC6.1040601@cisco.com> Date: Wed, 28 Nov 2007 13:00:38 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mikael.Latvala@nokia.com Subject: Re: [BEHAVE] TURN solution for home networks References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> In-Reply-To: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 18:00:04.0241 (UTC) FILETIME=[80C1B010:01C831E8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2134; t=1196272807; x=1197136807; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20solution=20for=20home=20networks |Sender:=20; bh=ZuxkgdDCOzYRwSC7c74BRy7fA8qthuj9M05clhU75VU=; b=DyfMdjG0VjRk9YXUdOo6vxuW5Stzw9gg/1Vmr7ewx5fl768Ziv9u+/t6cVzsdPRlrieDK2R2 ImnRUD4adWAj5R1yli/yo2kuvs6G6ROTP9N5sdlG4E4OV7jeiij1jrrQ; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org inline: Mikael.Latvala@nokia.com wrote: > The current TURN specs says: > > "Though originally invented for Voice over IP applications, TURN is > designed to be a general-purpose relay mechanism for NAT traversal." > > Unfortunately this is not that obvious when one reads the current TURN > spec. This spec has the following limitations which make it unsuitable > for scenarios where the home owner wants to access services in the home > network from a remote location; Can you clarify what you have in mind here? It sounds like, there is a TURN server running in the home network, presumably accessible at some public IP address. The user takes their PC somewhere else, and wants to connect to their TURN server, obtain an IP address which is actually within their home network (presumably net-10 or 192.168 for example) and then be able to access things like their home PC or NAS box as if they were on the home network? Sort of like a VPN, right? If so, I think its fair to say that TURN by itself is not going to address this problem, and I don't think it should. There has been some other work on using SIP to establish IPSec VPN for remote access to home resources: http://www.ietf.org/internet-drafts/draft-saito-mmusic-sdp-ike-01.txt But perhaps you have a different use case in mind. > > 1. "[Client] needs to request each permission explicitly and one at a > time." > > There are two problems with this restriction. > > A. Home owner cannot know beforehand from which IP address (external IP > address) s/he is going to access the home network. Hmm, based on this question you definitely have a different picture in mind. In the scenario I outline above, the permissions would be opened for communicating with devices in the home, not for the remote client. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 28 19:07:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWwW-0000YZ-FG; Wed, 28 Nov 2007 19:07:48 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IxWwU-0000YT-Mp for behave-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 19:07:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWwU-0000W1-Am for behave@ietf.org; Wed, 28 Nov 2007 19:07:46 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxWwT-00072e-Gh for behave@ietf.org; Wed, 28 Nov 2007 19:07:46 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAT07cSx010484; Thu, 29 Nov 2007 02:07:38 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 02:07:11 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 02:07:11 +0200 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: [BEHAVE] TURN solution for home networks Date: Thu, 29 Nov 2007 02:07:10 +0200 Message-ID: <326A98184EC61140A2569345DB3614C106881972@esebe105.NOE.Nokia.com> In-Reply-To: <31582A4D-9948-447B-8C06-F5EE641B0B7E@thetiger.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN solution for home networks Thread-Index: AcgxbdNveUcK9fkkTbymNMb4uNVvcQAqdVYg References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> <31582A4D-9948-447B-8C06-F5EE641B0B7E@thetiger.com> From: To: X-OriginalArrivalTime: 29 Nov 2007 00:07:11.0271 (UTC) FILETIME=[C9E3BB70:01C8321B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org David, TURN is as undesirable solution for home networks as it is for SIP traffic which is the concern of the current TURN spec. I would be more that happy to use only STUN. Unfortunately STUN is just not enough, AFAIK this is especially true in the States.=20 My personal opinion is that the only reason we need to create TURN like specs is to show operators and ISPs that=20 - IETF community is capable of creating a set necessary protocols which allow the Internet community to circumvent the obstacles that restrictive NATs introduce - the sooner the ISP and operators adopt the correct network neutrality attitude, the faster the Internet ecosystem can benefit from the fast last mile connections (xDSL, DOCSIS, fiber, WiMAX, etc.) which shall also give a boost to operators' and ISPs' business When saying operators and ISPs I am not claiming that every operator or ISP places restrictions on the use of the Internet as in some parts of the world the TURN specs have no validity.=20 /Mikael >-----Original Message----- >From: ext David Miles [mailto:davidm@thetiger.com]=20 >Sent: 28.11.2007 05:21 >To: Latvala Mikael (Nokia-NRC/Helsinki) >Cc: behave@ietf.org >Subject: Re: [BEHAVE] TURN solution for home networks > >Mikael, > >You mentioned work is needed to address the home network needs=20 >- would we be able to spend some time discussing these? I'm=20 >interested to know the drivers for TURN vs STUN as I would=20 >have thought TURN would have been an undesirable solution. > >Best Regards, > >-David > >On 28/11/2007, at 2:28 AM, wrote: > >> The current TURN specs says: >> >> "Though originally invented for Voice over IP applications, TURN is=20 >> designed to be a general-purpose relay mechanism for NAT traversal." >> >> Unfortunately this is not that obvious when one reads the=20 >current TURN=20 >> spec. This spec has the following limitations which make it=20 >unsuitable=20 >> for scenarios where the home owner wants to access services in the=20 >> home network from a remote location; >> >> 1. "[Client] needs to request each permission explicitly and=20 >one at a=20 >> time." >> >> There are two problems with this restriction. >> >> A. Home owner cannot know beforehand from which IP address (external=20 >> IP >> address) s/he is going to access the home network. >> >> B. Even if home owner did magically know all the external IP=20 >> addresses, all home automation and many AV based device would not be=20 >> able to request such permissions, because there are no=20 >mechanisms how=20 >> home owner could the devices what these external IP addresses are. >> >> 2. "A TURN server can then relay traffic between a reliable=20 >transport=20 >> used between the client and server (TCP or TLS over TCP),=20 >and UDP used=20 >> from server to peer." >> >> Limiting the transport protocol to UDP between server and peer means=20 >> for example that peers behind corporate firewalls would not=20 >be able to=20 >> access the TURN server. >> >> 3. Last but not least, it has been pointed out to me that IESG won't=20 >> accept wordings such as >> >> "This insures that a client can't use a TURN server to run a=20 >> traditional server, and partially protects the client from DoS=20 >> attacks." >> >> as these restrictions are outside the scope of this spec. >> >> >> There are three alternatives how we can correct the current=20 >situation=20 >> and make TURN-type solution applicable also for home networks: >> >> 1. Modify the existing draft-ietf-behave-turn-XX.txt=20 >(considering how=20 >> long the TURN work has been going on I see this very unlikely >> alternative) >> 2. Create a new BEHAVE sponsored draft which addresses the home=20 >> network needs (Nokia preferred alternative) 3. Wait that=20 >some company=20 >> creates an informational draft >> >> My plan is to discuss about these three different alternatives in=20 >> Vancouver and hopefully get some kind of a rough consensus on how to=20 >> go forward. >> >> /Mikael >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 28 20:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXoV-0002J8-GM; Wed, 28 Nov 2007 20:03:35 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IxXoU-0002J3-Go for behave-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 20:03:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXoU-0002Iv-5q for behave@ietf.org; Wed, 28 Nov 2007 20:03:34 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxXoT-0000qA-Do for behave@ietf.org; Wed, 28 Nov 2007 20:03:34 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAT13SRw021536; Thu, 29 Nov 2007 03:03:29 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 03:03:25 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 03:03:26 +0200 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: [BEHAVE] TURN solution for home networks Date: Thu, 29 Nov 2007 03:03:25 +0200 Message-ID: <326A98184EC61140A2569345DB3614C106881974@esebe105.NOE.Nokia.com> In-Reply-To: <474DACC6.1040601@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN solution for home networks Thread-Index: Acgx6IWEi2ZzvW0nRQmcmu4ODkyq9QAM6KGQ References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> <474DACC6.1040601@cisco.com> From: To: X-OriginalArrivalTime: 29 Nov 2007 01:03:26.0039 (UTC) FILETIME=[A5687670:01C83223] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jonothan, Axiom: There is a network called the home network in a house. The home network contains one Home Gateway (HG), which is typically a DOCSIS or xDSL model, and one or more nodes (computers, servers or devices such as refigerators, A/C controllers, security cameras, thermostats, heatpumps, etc.) Whether all these devices have an IP address is irrelevant as long as other nodes in the home network can communicate with such non-IP based devices. HG forwards packets between the home network and the Internet. Use case: Home owner visits some location outside his house and needs to access a computer, server and/or device in the home network from this remote location. Now, as far as I have understood the TURN draft correctly, the current TURN spec does not offer a solution for this use case. Furthermore, TURN server cannot be run in the home network because nodes in the home network are usually assinged with a private IP address. What comes to the http://www.ietf.org/internet-drafts/draft-saito-mmusic-sdp-ike-01.txt the proposal has only two shortcomings:=20 A. It uses SIP as a control protocol B. It uses IPsec as a tunnel protocol SIP is bad because legacy applications and most of the applications created still today use domain names and DNS. Moving to SIP would mean changes to every application. IPSec is bad, because it has to be UDP encapsulated to sustain NAT enforced header changes but at the same time large portion of firewalls, especially corporate ones, block any outgoing UDP traffic. =20 /Mikael >-----Original Message----- >From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 >Sent: 28.11.2007 20:01 >To: Latvala Mikael (Nokia-NRC/Helsinki) >Cc: behave@ietf.org >Subject: Re: [BEHAVE] TURN solution for home networks > >inline: > >Mikael.Latvala@nokia.com wrote: >> The current TURN specs says: >>=20 >> "Though originally invented for Voice over IP applications, TURN is=20 >> designed to be a general-purpose relay mechanism for NAT traversal." >>=20 >> Unfortunately this is not that obvious when one reads the=20 >current TURN=20 >> spec. This spec has the following limitations which make it=20 >unsuitable=20 >> for scenarios where the home owner wants to access services in the=20 >> home network from a remote location; > >Can you clarify what you have in mind here? > >It sounds like, there is a TURN server running in the home=20 >network, presumably accessible at some public IP address. The=20 >user takes their PC somewhere else, and wants to connect to=20 >their TURN server, obtain an IP address which is actually=20 >within their home network (presumably net-10 or 192.168 for=20 >example) and then be able to access things like their home PC=20 >or NAS box as if they were on the home network? Sort of like a=20 >VPN, right? > >If so, I think its fair to say that TURN by itself is not=20 >going to address this problem, and I don't think it should.=20 >There has been some other work on using SIP to establish IPSec=20 >VPN for remote access to home >resources: > >http://www.ietf.org/internet-drafts/draft-saito-mmusic-sdp-ike-01.txt > >But perhaps you have a different use case in mind. > >>=20 >> 1. "[Client] needs to request each permission explicitly and=20 >one at a=20 >> time." >>=20 >> There are two problems with this restriction. >>=20 >> A. Home owner cannot know beforehand from which IP address (external=20 >> IP >> address) s/he is going to access the home network. > >Hmm, based on this question you definitely have a different=20 >picture in mind. In the scenario I outline above, the=20 >permissions would be opened for communicating with devices in=20 >the home, not for the remote client. > >-Jonathan R. > > >--=20 >Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >Cisco Fellow Edison, NJ 08837 >Cisco, Voice Technology Group >jdrosen@cisco.com >http://www.jdrosen.net PHONE: (408) 902-3084 >http://www.cisco.com > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 28 20:33: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 1IxYHT-0002cu-Sj; Wed, 28 Nov 2007 20:33:31 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IxYHS-0002ci-2d for behave-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 20:33:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxYHR-0002ca-Nh for behave@ietf.org; Wed, 28 Nov 2007 20:33:29 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxYHR-0001lw-1c for behave@ietf.org; Wed, 28 Nov 2007 20:33:29 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 0C36BD9D403A; Wed, 28 Nov 2007 17:33:28 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id D1D8CD9D4038; Wed, 28 Nov 2007 17:33:24 -0800 (PST) Message-ID: <474E16E4.5050201@acm.org> Date: Wed, 28 Nov 2007 17:33:24 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Mikael.Latvala@nokia.com Subject: Re: [BEHAVE] TURN solution for home networks References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> <474DACC6.1040601@cisco.com> <326A98184EC61140A2569345DB3614C106881974@esebe105.NOE.Nokia.com> In-Reply-To: <326A98184EC61140A2569345DB3614C106881974@esebe105.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Mikael.Latvala@nokia.com wrote: > Jonothan, > > Axiom: > > There is a network called the home network in a house. The home network > contains one Home Gateway (HG), which is typically a DOCSIS or xDSL > model, and one or more nodes (computers, servers or devices such as > refigerators, A/C controllers, security cameras, thermostats, heatpumps, > etc.) Whether all these devices have an IP address is irrelevant as long > as other nodes in the home network can communicate with such non-IP > based devices. HG forwards packets between the home network and the > Internet. > > Use case: > > Home owner visits some location outside his house and needs to access a > computer, server and/or device in the home network from this remote > location. Here's an idea: You assign an IPv6 address to each of your computer, server and/or device, and then you can access all of them from anywhere on the Internet. A WRT45GL with OpenWRT with a free IPv6 tunnel from HE or SixXS for your home, another free IPv6 tunnel from Freenet6 for your laptop and you are all set. > > Now, as far as I have understood the TURN draft correctly, the current > TURN spec does not offer a solution for this use case. Furthermore, TURN > server cannot be run in the home network because nodes in the home > network are usually assinged with a private IP address. > > What comes to the > http://www.ietf.org/internet-drafts/draft-saito-mmusic-sdp-ike-01.txt > the proposal has only two shortcomings: > A. It uses SIP as a control protocol > B. It uses IPsec as a tunnel protocol > > SIP is bad because legacy applications and most of the applications > created still today use domain names and DNS. Moving to SIP would mean > changes to every application. IPSec is bad, because it has to be UDP > encapsulated to sustain NAT enforced header changes but at the same time > large portion of firewalls, especially corporate ones, block any > outgoing UDP traffic. > > /Mikael > > >> -----Original Message----- >> From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 28.11.2007 20:01 >> To: Latvala Mikael (Nokia-NRC/Helsinki) >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] TURN solution for home networks >> >> inline: >> >> Mikael.Latvala@nokia.com wrote: >>> The current TURN specs says: >>> >>> "Though originally invented for Voice over IP applications, TURN is >>> designed to be a general-purpose relay mechanism for NAT traversal." >>> >>> Unfortunately this is not that obvious when one reads the >> current TURN >>> spec. This spec has the following limitations which make it >> unsuitable >>> for scenarios where the home owner wants to access services in the >>> home network from a remote location; >> Can you clarify what you have in mind here? >> >> It sounds like, there is a TURN server running in the home >> network, presumably accessible at some public IP address. The >> user takes their PC somewhere else, and wants to connect to >> their TURN server, obtain an IP address which is actually >> within their home network (presumably net-10 or 192.168 for >> example) and then be able to access things like their home PC >> or NAS box as if they were on the home network? Sort of like a >> VPN, right? >> >> If so, I think its fair to say that TURN by itself is not >> going to address this problem, and I don't think it should. >> There has been some other work on using SIP to establish IPSec >> VPN for remote access to home >> resources: >> >> http://www.ietf.org/internet-drafts/draft-saito-mmusic-sdp-ike-01.txt >> >> But perhaps you have a different use case in mind. >> >>> 1. "[Client] needs to request each permission explicitly and >> one at a >>> time." >>> >>> There are two problems with this restriction. >>> >>> A. Home owner cannot know beforehand from which IP address (external >>> IP >>> address) s/he is going to access the home network. >> Hmm, based on this question you definitely have a different >> picture in mind. In the scenario I outline above, the >> permissions would be opened for communicating with devices in >> the home, not for the remote client. >> >> -Jonathan R. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 28 21:55:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZYc-0007y3-7y; Wed, 28 Nov 2007 21:55:18 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IxZYa-0007wB-Nl for behave-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 21:55:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZYa-0007vh-DT for behave@ietf.org; Wed, 28 Nov 2007 21:55:16 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxZYa-0004G7-1j for behave@ietf.org; Wed, 28 Nov 2007 21:55:16 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 2C0D9D9D403A; Wed, 28 Nov 2007 18:55:15 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id AB16DD9D4038 for ; Wed, 28 Nov 2007 18:55:13 -0800 (PST) Message-ID: <474E2A10.6010003@acm.org> Date: Wed, 28 Nov 2007 18:55:12 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [BEHAVE] Port allocation in TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Between turn-05 and turn-ipv6-03, there is 3 different attributes used to allocate a port: REQUESTED-PORT-PROPS, REQUESTED-IP and REQUESTED-ADDRESS-TYPE. My proposal is to simplify by merging the 3 attributes into one: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0| A | Family | Specific Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address (32 bits or 128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The six first bits are reserved and must be set to zero. The two bits labeled A have the same meaning than the A bits in REQUESTED-PORT-PROPS. The Family field has the same meaning than the field of same name in REQUESTED-ADDRESS-TYPE. The Specific Port Number field has the same meaning than the field of same name in REQUESTED-PORT-PROPS. The Address field has the same meaning than the field of same name in REQUESTED-IP, excepted that a value of all zero means that the server is free to choose the IP address -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 29 01:51:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdFb-00056V-9i; Thu, 29 Nov 2007 01:51:55 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IxdFa-00054u-LX for behave-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 01:51:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdFa-00054k-8x for behave@ietf.org; Thu, 29 Nov 2007 01:51:54 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxdFZ-000639-Pv for behave@ietf.org; Thu, 29 Nov 2007 01:51:54 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAT6pa0G032122; Thu, 29 Nov 2007 08:51:46 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 08:51:22 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 08:51:21 +0200 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: [BEHAVE] TURN solution for home networks Date: Thu, 29 Nov 2007 08:51:22 +0200 Message-ID: <326A98184EC61140A2569345DB3614C1068819CB@esebe105.NOE.Nokia.com> In-Reply-To: <474E16E4.5050201@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN solution for home networks Thread-Index: AcgyJ+LWW/LVUMRTTj+svFKBGGl8nQAK8Vtw References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> <474DACC6.1040601@cisco.com> <326A98184EC61140A2569345DB3614C106881974@esebe105.NOE.Nokia.com> <474E16E4.5050201@acm.org> From: To: X-OriginalArrivalTime: 29 Nov 2007 06:51:21.0462 (UTC) FILETIME=[40213960:01C83254] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org :) > >Here's an idea: You assign an IPv6 address to each of your=20 >computer, server and/or device, and then you can access all of=20 >them from anywhere on the Internet. A WRT45GL with OpenWRT=20 >with a free IPv6 tunnel from HE or SixXS for your home,=20 >another free IPv6 tunnel from Freenet6 for your laptop and you=20 >are all set. > >>=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 29 22:35:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxweY-0004dN-Al; Thu, 29 Nov 2007 22:34:58 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IxweW-0004cR-Gf for behave-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 22:34:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxweW-0004c0-6B for behave@ietf.org; Thu, 29 Nov 2007 22:34:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxweV-00062F-O3 for behave@ietf.org; Thu, 29 Nov 2007 22:34:56 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 29 Nov 2007 19:34:54 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3YtCN012402; Thu, 29 Nov 2007 19:34:55 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id lAU3Yrqa016727; Fri, 30 Nov 2007 03:34:53 GMT In-Reply-To: <47454BC4.6090909@ericsson.com> References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> <47454BC4.6090909@ericsson.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34C9E434-D73E-41E1-B9F9-45F06C0956AB@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] adopt STUN test vectors? Date: Thu, 29 Nov 2007 19:34:14 -0800 To: Behave WG X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2413; t=1196393695; x=1197257695; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20adopt=20STUN=20test=20vectors? |Sender:=20; bh=5iTVwDmWzxq1U01sXlpmQzqEkZUAPilwsEHz8u9hFpA=; b=IwN6YdHBgUCndDdgiHSKay2aynqE/iBRCXs6WxyKbO0BEgEYCqaReSWAa27C73A5N6ZB/QoO jFgaLfdup0byD6BO0alLSJcmIkFWg9ebvK+nWO/GfvcYEHV1hA3l2JiiCUtUuBNrv7RHa7sbfL kRDOG+b/F/RrAPFgOrytA7hhI=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The SIP Call Flows came out long after the protocol specification and turned out to be very helpful for implementors - and people did mange to find them. I think it some minimal examples that implementors can use to check things are working are almost always a good thing and would be in favor of this. Cullen On Nov 22, 2007, at 1:28 AM, Magnus Westerlund wrote: > Hi, > > I have discussed this with my Co-AD Lars and I think we can squeeze > this > in without any charter changes. So lets discuss the main question. > Is it > a useful enough document that the WG should be responsible to > produce it. > > Regarding putting that into a STUN appendix that it a bit late as > STUNbis is on the IESG telechat agenda for next week. > > Cheers > > Magnus > > Dan Wing skrev: >> We don't have a milestone for STUN test vectors and it probably >> falls a bit >> outside of the as-written charter, but before we try to change >> those: is >> there interest in adopting Remi's "Test vectors for RFC3489bis", >> draft-denis-behave-rfc3489bis-test-vectors-02 as a working group >> item for >> BEHAVE? It's 6 pages, please skim it: >> >> http://www.ietf.org/internet-drafts/draft-denis-behave-rfc3489bis- >> test-vectors >> -02.txt >> >> Before adopting it, I will need to get approval from our ADs to >> add another >> milestone and adjust the charter accordingly. But I wanted to >> poll first to >> see if we should try doing that. >> >> Thanks, >> -d >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > > -- > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 30 01:13:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixz7n-0000Il-G3; Fri, 30 Nov 2007 01:13:19 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ixz7k-0000IV-O2 for behave-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 01:13:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixz7k-0000IA-2z for behave@ietf.org; Fri, 30 Nov 2007 01:13:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixz7j-0007yd-Q1 for behave@ietf.org; Fri, 30 Nov 2007 01:13:15 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 22:13:15 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAU6DF0O024904 for ; Thu, 29 Nov 2007 22:13:15 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id lAU6DEqa024668 for ; Fri, 30 Nov 2007 06:13:15 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Behave WG From: Cullen Jennings Date: Thu, 29 Nov 2007 22:13:09 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=150; t=1196403195; x=1197267195; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20behave-nat-behavior-discovery |Sender:=20; bh=Z54jVAUkYAQe1J7/S5w9U/WN3xU4zTEMdRkFSddY9Yw=; b=HYp1H/fdBmk6nMgdn39ODe49//dHxu96EPoZNgQsvRCPFCQ8otv5/cXtguQQggXgE9jzIkEH PaaUtOIwvg68b2LgNguCKgBzG3Txf3Bcp+SJQU35bljYqr9hcG+ocgKf; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 2.7 (++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [BEHAVE] behave-nat-behavior-discovery X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I like the way you scope what this can and can not be used for. It removed a lot of my concerns about it. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 30 06:19:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3uN-0007o6-JT; Fri, 30 Nov 2007 06:19:47 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iy3uM-0007fP-8u for behave-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 06:19:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3uL-0007ct-To; Fri, 30 Nov 2007 06:19:45 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iy3uJ-0003Vo-0z; Fri, 30 Nov 2007 06:19:45 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3f47503861; Fri, 30 Nov 2007 19:32:34 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm200474b1ab6; Tue, 27 Nov 2007 01:31:40 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 27 Nov 2007 01:31:40 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhZh-0007x6-2h; Mon, 26 Nov 2007 12:16:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhZa-0007h8-Ce; Mon, 26 Nov 2007 12:16:42 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhZV-0004TA-4O; Mon, 26 Nov 2007 12:16:42 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 087AD327BD; Mon, 26 Nov 2007 17:16:37 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IwhZU-0007sp-UN; Mon, 26 Nov 2007 12:16:36 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 26 Nov 2007 12:16:36 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 4.9 (++++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Document Action: 'State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs)' to Informational RFC X-BeenThere: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The IESG has approved the following document: - 'State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) ' as an Informational RFC This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-06.txt Technical Summary This memo documents the various methods known to be in use by applications to establish direct UDP or TCP communication in the presence of Network Address Translators (NATs). Working Group Summary Agreeing on RFC3489 terminology (which is well known) versus RFC4787 terminology (which is more accurate but longer) involved some controversy. Consensus was to use RFC4787 terminology. Document Quality This document have had descent review in the WG. The techniques in this document are implemented in various software that traverses NATs. Personnel Document shepherd: Dan Wing, dwing@cisco.com Responsible AD: Magnus Westerlund, magnus.westerlund@ericsson.com Note to RFC Editor Please update the reference to RFC 3041 to RFC 4941. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave