http://permalink.gmane.org/gmane.ietf.nat.behave hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.nat.behave/10477 <pre> Yes, we could not stop the use of DPI, but we should consider this scene. I think that is the purpose of F37. Besides, websocket is friendly to http proxy too. I agree that draft-hutton-rtcweb-nat-firewall-considerations-00 should be a baseline to solve the traverse problem of nat and fireward. But I think the turn over websocket solution should also be considered as a option to solve some corner use case and requirement. Best Regards, Xin </pre> Chenxin (Xin 2013-05-16T11:52:17 http://permalink.gmane.org/gmane.ietf.nat.behave/10476 <pre>Reply inline Best Regards, Xin From: Bernard Aboba [mailto:bernard_aboba&lt; at &gt;hotmail.com] Sent: Thursday, May 16, 2013 1:20 AM To: Hutton, Andrew; Chenxin (Xin); behave&lt; at &gt;ietf.org; rtcweb&lt; at &gt;ietf.org Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Andrew Hutton said: [BA] In my experience, institutions with very restrictive security policies (e.g. those that don't allow UDP in or out) also tend to deploy other measures such as deep packet inspection. So just because some traffic is allowed in or out on port 80 does not mean that TURN/TCP will be allowed on that port - a DPI box may examine the traffic and complain if it doesn't see HTTP being used. On the other hand, unless the DPI box is upgraded, it will also complain about websockets. So I think draft-chenxin only helps in a situation where TURN over Websockets would be allowed when TURN/TCP would not be. That scenario is rare, at least at the moment. [Xin] With the development of websocket, there</pre> Chenxin (Xin 2013-05-16T11:42:21 http://permalink.gmane.org/gmane.ietf.nat.behave/10475 <pre>I agree with Bernard's comments regarding the impact of DPI but of course such DPI devices do what they do and we can't and even don't want to stop them from doing it. However for the case when policy is such that the firewall will only allow traffic to traverse that comes from the HTTP Proxy or a network specific TURN server and there is no deliberate policy to block WebRTC media we need a solution and this is what draft-hutton-rtcweb-nat-firewall-considerations-00 addresses. So far I don't see the benefit that TURN over websockets would have in this scenario and it needs additional implementation in the browser and the TURN server. Regards Andy </pre> Hutton, Andrew 2013-05-16T08:28:03 http://permalink.gmane.org/gmane.ietf.nat.behave/10474 <pre>Please see inline [TR] From: rtcweb-bounces&lt; at &gt;ietf.org [mailto:rtcweb-bounces&lt; at &gt;ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, May 15, 2013 10:50 PM To: Hutton, Andrew; Chenxin (Xin); behave&lt; at &gt;ietf.org; rtcweb&lt; at &gt;ietf.org Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Andrew Hutton said: [BA] In my experience, institutions with very restrictive security policies (e.g. those that don't allow UDP in or out) also tend to deploy other measures such as deep packet inspection. So just because some traffic is allowed in or out on port 80 does not mean that TURN/TCP will be allowed on that port - a DPI box may examine the traffic and complain if it doesn't see HTTP being used. On the other hand, unless the DPI box is upgraded, it will also complain about websockets. So I think draft-chenxin only helps in a situation where TURN over Websockets would be allowed when TURN/TCP would not be. That scenario is rare, at least at the moment. The argument for TURN ove</pre> Tirumaleswar Reddy (tireddy 2013-05-16T04:55:54 http://permalink.gmane.org/gmane.ietf.nat.behave/10473 <pre>This draft defines a websocket extension to TURN to make TURN data have the ability to transport over the websocket connection. This method could be a option to solve the Http-fallback requirement in RTCWEB. F37 The browser MUST be able to send streams and data to a peer in the presence of FWs that only allows http(s) traffic. Besides, Turn server with websokcet extension could be a general relay server for some over websocket protocol, such as BFCP over websocket or MSRP over websocket. This could satisfy some Peer to Peer scene when using these protocol in the web environment , without a specific center server. Comments and suggestions are welcome. Best Regards, Xin -----Original Message----- From: internet-drafts&lt; at &gt;ietf.org [mailto:internet-drafts&lt; at &gt;ietf.org] Sent: Tuesday, May 14, 2013 9:15 AM To: Chenxin (Xin); Chenxin (Xin) Subject: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt A new version of I-D, draft-chenxi</pre> Chenxin (Xin 2013-05-15T01:40:05 http://permalink.gmane.org/gmane.ietf.nat.behave/10472 <pre>Andrew Hutton said: [BA] In my experience, institutions with very restrictive security policies (e.g. those that don't allow UDP in or out) also tend to deploy other measures such as deep packet inspection. So just because some traffic is allowed in or out on port 80 does not mean that TURN/TCP will be allowed on that port - a DPI box may examine the traffic and complain if it doesn't see HTTP being used. On the other hand, unless the DPI box is upgraded, it will also complain about websockets. So I think draft-chenxin only helps in a situation where TURN over Websockets would be allowed when TURN/TCP would not be. That scenario is rare, at least at the moment. The argument for TURN over Websocket/TLS is even more difficult to make. While DPI boxes may examine traffic destined to port 443 carefully to make sure that TLS is really being used, assuming that the DPI box does not see anything it considers fishy, the TLS exchange will complete and the DPI box will lose visibility. After TLS is running</pre> Bernard Aboba 2013-05-15T17:19:53 http://permalink.gmane.org/gmane.ietf.nat.behave/10471 <pre>This is an interesting addition to the debate about how best to achieve connectivity for RTCWeb when the client is behind a restrictive firewall. When we wrote the draft http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-00 we did not include this option because we did not see the benefit of additional transport options for TURN given that the existing options (E.g. TURN/TCP and TURN/TLS) seem to be meet our needs. So what would be the benefits that justify this addition transport option for TURN? Regarding F37 then this does need some rewording as I think the WG previously discussed as it needs to talk about the need for traffic to originate from the HTTP Proxy rather than allowing http traffic. That is probably worth a separate thread. Regards Andy </pre> Hutton, Andrew 2013-05-15T16:14:50 http://permalink.gmane.org/gmane.ietf.nat.behave/10470 <pre>the achievable address sharing ratio for dynamic is 10x that of static. I find this to be quite higher than what I would consider generically speaking. Perhaps, we need to differentiate between mobile and wireline deployments. Irrespective of that, I wonder the usefulness of static vs dynamic ratio, and how it could help in any CGN deployment. The question many deployments often ask is about the CGN pool size(s). We should qualify and quantify the answer to that question in this draft. Cheers, Rajiv Sent from my Phone On May 15, 2013, at 12:20 AM, "kaname nishizuka" &lt;kaname&lt; at &gt;nttv6.jp&lt;mailto:kaname&lt; at &gt;nttv6.jp&gt;&gt; wrote: Yes. Based on the port consumption trend, we figured out that the sharing ratio of dynamic assignment is 10 times of that of static assignment. However, I'm not intended to conclude that which is preferable in the draft. That depends on the provider's choice. I would carefully remove confusing representations. regards, kaname (2013/05/13 20:46), Simon Perreault wrote: Le 2013-05-09 14:19,</pre> Rajiv Asati (rajiva 2013-05-15T10:48:23 http://permalink.gmane.org/gmane.ietf.nat.behave/10469 <pre>Dear all, I support the adoption of draft-penno-behave-rfc4787-5382-5508-bis as a behave WG document. Cheers, Christian. _______________________________________________ Behave mailing list Behave&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/behave _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied w</pre> christian.jacquenet< at >orange.com 2013-05-15T07:26:31 http://permalink.gmane.org/gmane.ietf.nat.behave/10468 <pre> Yes. Based on the port consumption trend, we figured out that the sharing ratio of dynamic assignment is 10 times of that of static assignment. However, I'm not intended to conclude that which is preferable in the draft. That depends on the provider's choice. I would carefully remove confusing representations. regards, kaname (2013/05/13 20:46), Simon Perreault wrote: </pre> kaname nishizuka 2013-05-15T04:20:48 http://permalink.gmane.org/gmane.ietf.nat.behave/10467 <pre>+1 I support this draft as wg draft. (2013/05/15 11:29), Arifumi Matsumoto wrote: _______________________________________________ Behave mailing list Behave&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/behave </pre> Shishio Tsuchiya 2013-05-15T02:52:27 http://permalink.gmane.org/gmane.ietf.nat.behave/10466 <pre>Hi, I support this draft. In that, It contains practical and significant improvements over these existing RFCs, such as those mechanisms for address resource limited environment. 2013/5/13 Reinaldo Penno (repenno) &lt;repenno&lt; at &gt;cisco.com&gt; </pre> Arifumi Matsumoto 2013-05-15T02:29:35 http://permalink.gmane.org/gmane.ietf.nat.behave/10465 <pre>As a co-author, I also support this effort. (2013/05/13 23:42), Reinaldo Penno (repenno) wrote: </pre> Kengo Naito 2013-05-15T02:18:10 http://permalink.gmane.org/gmane.ietf.nat.behave/10464 <pre>As a co-author I certainly support this effort, but also as a NAT developer where it has helped clarify many issues. On 5/13/13 11:20 AM, "mohamed.boucadair&lt; at &gt;orange.com" &lt;mohamed.boucadair&lt; at &gt;orange.com&gt; wrote: </pre> Reinaldo Penno (repenno 2013-05-13T14:42:46 http://permalink.gmane.org/gmane.ietf.nat.behave/10463 <pre>I support this effort. </pre> mohamed.boucadair< at >orange.com 2013-05-13T14:20:42 http://permalink.gmane.org/gmane.ietf.nat.behave/10462 <pre>Le 2013-05-09 14:19, Rajiv Asati (rajiva) a écrit : The draft says that the achievable address sharing ratio for dynamic is 10x that of static. So if you have 1:32 for static (a made up figure), it follows you would have 1:320 for dynamic. Simon </pre> Simon Perreault 2013-05-13T11:46:35 http://permalink.gmane.org/gmane.ietf.nat.behave/10461 <pre>Hi Simon, 1:32 (dynamic assignment) on top of 1:10 (static assignment)? Did you intend to nest? Could you please clarify? Cheers, Rajiv -----Original Message----- From: Simon Perreault &lt;simon.perreault&lt; at &gt;viagenie.ca&gt; Date: Thursday, April 4, 2013 5:49 AM To: Behave WG &lt;behave&lt; at &gt;ietf.org&gt; Subject: Re: [BEHAVE] Fwd: New Version Notification fordraft-nishizuka-cgn-deployment-considerations-00.txt </pre> Rajiv Asati (rajiva 2013-05-09T12:19:01 http://permalink.gmane.org/gmane.ietf.nat.behave/10460 <pre>Done at last. The updated document has two new sections: 2. Deployment Considerations - discusses the logging implications of the various Softwires transition methods, as well some considerations arising out of the architectural role of the NAT. 3. NAT-Related Events and Parameters - is a description at a generally coding-independent level of the events to be logged at NATs and their associated parameters. In principle the contents are the same as in the IPFIX document, but some reconciliation may be required. These sections are followed by SYSLOG-specific stuff: applicability statement, parameter and event encoding (with lots examples of complete logs), and an extensive IANA section. Then the usual remaining sections. Comments are welcome. Fire away. Tom Taylor On 08/05/2013 11:44 AM, internet-drafts&lt; at &gt;ietf.org wrote: ... </pre> Tom Taylor 2013-05-08T15:55:43 http://permalink.gmane.org/gmane.ietf.nat.behave/10458 <pre>This draft is a revision to the earlier version by incorporating the comments given by Simon Perreault. comments and suggestions are welcome. Best Regards, Authors. </pre> Ram Mohan R (rmohanr 2013-05-05T17:41:20 http://permalink.gmane.org/gmane.ietf.nat.behave/10457 <pre>The authors of draft-penno-behave-rfc4787-5382-5508-bis have asked that it become a working group document. Please send review nits, spelling corrections, and suchlike to the authors. Please send feedback about this becoming a working group document to the chairs, authors, or list, as you feel appropriate; clear indications of 'support' or 'do not support' are appreciated. http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-04 -d </pre> Dan Wing 2013-05-03T22:43:23 http://permalink.gmane.org/gmane.ietf.nat.behave/10456 <pre>I've asked the other MIB Doctors their opinion. I'm pretty sure Benoit will see the discussion and can provide guidance. David Harrington ietfdbh&lt; at &gt;comcast.net +1-603-828-1401 -----Original Message----- From: Simon Perreault [mailto:simon.perreault&lt; at &gt;viagenie.ca] Sent: Friday, May 03, 2013 3:52 AM To: ietfdbh Cc: behave&lt; at &gt;ietf.org; behave-ads&lt; at &gt;tools.ietf.org Subject: Re: nat-mib-06: separate MIB modules David, What you're proposing is exactly what we had been doing initially. It was then suggested to us that we should change to what we have currently, which we did. We authors are not MIB doctors, and I don't think any one of us really cares which technical form this has. We just need the functionality. Going from one form to another is quite a bit of work, so you'll understand we want to be certain that this time we won't be told to go back again in the later stages of publication. I'm thinking about IESG review here. So if we could get some early feedback from an AD about which way we are expected to go, th</pre> ietfdbh 2013-05-03T19:05:31 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.nat.behave