From internet-drafts@ietf.org Wed May 1 01:28:07 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4ED21F8E48; Wed, 1 May 2013 01:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ipz-13eEiqWK; Wed, 1 May 2013 01:28:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B47D21F8C23; Wed, 1 May 2013 01:28:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130501082807.854.32553.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 01:28:07 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 08:28:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Additional Managed Objects for Network Address Translato= rs (NAT) Author(s) : Simon Perreault Tina Tsou Senthil Sivakumar Filename : draft-ietf-behave-nat-mib-06.txt Pages : 82 Date : 2013-05-01 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat-mib-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Wed May 1 01:31:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A3121F8E7C for ; Wed, 1 May 2013 01:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ5xGVGdHw-E for ; Wed, 1 May 2013 01:30:59 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D99F21F8E79 for ; Wed, 1 May 2013 01:30:59 -0700 (PDT) Received: from porto.nomis80.org (87-231-137-212.rev.numericable.fr [87.231.137.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5EDC74135B for ; Wed, 1 May 2013 04:30:58 -0400 (EDT) Message-ID: <5180D2C1.60105@viagenie.ca> Date: Wed, 01 May 2013 10:30:57 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: behave@ietf.org References: <20130501082807.854.32553.idtracker@ietfa.amsl.com> In-Reply-To: <20130501082807.854.32553.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 08:31:00 -0000 Group, This version fixes MIB syntax issues and updates the security considerations section according to the recommended boilerplate. As far as we know this is ready for WGLC. Simon Le 2013-05-01 10:28, internet-drafts@ietf.org a écrit : > > 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 : Additional Managed Objects for Network Address Translators (NAT) > Author(s) : Simon Perreault > Tina Tsou > Senthil Sivakumar > Filename : draft-ietf-behave-nat-mib-06.txt > Pages : 82 > Date : 2013-05-01 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for devices implementing Network Address Translator (NAT) function. > This MIB module may be used for monitoring of a device capable of NAT > function. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-behave-nat-mib-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat-mib-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ietfdbh@comcast.net Thu May 2 16:14:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B50E21F854E for ; Thu, 2 May 2013 16:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3HmFjN1deaS for ; Thu, 2 May 2013 16:14:47 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id A20CE21F8425 for ; Thu, 2 May 2013 16:14:47 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta05.westchester.pa.mail.comcast.net with comcast id WzK61l0050SCNGk55BEnbc; Thu, 02 May 2013 23:14:47 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta09.westchester.pa.mail.comcast.net with comcast id XBEm1l00d2yZEBF3VBEm3u; Thu, 02 May 2013 23:14:47 +0000 From: "ietfdbh" To: "'Simon Perreault'" , Date: Thu, 2 May 2013 19:14:47 -0400 Message-ID: <03e901ce478a$d75cdf90$86169eb0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5Hitaycf8hxox0T8uzH2NciK+nNQ== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367536487; bh=ah5pNR9/jbydmsNwxFyyP3Svg1AXLXbJ4lUSBYtSja4=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=nCB3/NT2b9LNbnNiDBRyTE2o2OxYl9uCBgyFPvd4qMjEmisaBR6bXZtETQIr6VGn4 Ch4dMZfKGeWhTA9Wi3WH7xDddn0KFPpt9A/cNY0E6Na3hffIT+Z7NzObYYCGTMC9rA 57jUMArusClhE92Jx2EY46uvNuVMOb+DnL5xRsoj7mZWS2YpYaPZhNeFBpsd8aMtBZ nDOwgQqKvnVRr3jlSNZSmsof9eS5IIXlmUqO7IVC63pToSKSRwMco0Y04Ny5vV575c SFol6WyPHHU2WC/eBOc4EnGBf84RuqYuPbHwAbyKw+7odzAy+WrW7/UF+r5uhufIkf BGJJeVMK+vbCg== Cc: behave-ads@tools.ietf.org Subject: [BEHAVE] nat-mib-06: separate MIB modules X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 23:14:52 -0000 Hi, I would like to suggest a change. If I understand correctly, this document deprecates the entire RFC4008 NAT-MIB, and proposes a completely new MIB under the same name. I think this is sub-optimal. In NMS applications that support multiple devices, some of which support RFC4008 and some of which support this new MIB module, it will be potentially confusing to call them by the same name. You really have two completely different MIB modules that you are trying = to sell under the same name. I think that is not a good idea. I recommend writing an RFC4008bis document to deprecate the RFC4008 = NAT-MIB. Then put your proposed new MIB objects into a separate MIB module, using = a different name for the newly designed MIB for managing NATs (maybe NEW-NAT-MIB, but I'd hope for something that more accurately describes the modified purpose of the MIB, maybe NAT-MONITORING-MIB) Put this in a separate RFC. I think that would be a much cleaner solution, and much more obvious = what you are doing here. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of Simon Perreault Sent: Wednesday, May 01, 2013 4:31 AM To: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-06.txt Group, This version fixes MIB syntax issues and updates the security = considerations section according to the recommended boilerplate. As far as we know this is ready for WGLC. Simon Le 2013-05-01 10:28, internet-drafts@ietf.org a =E9crit : > > 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 : Additional Managed Objects for Network Address Translators (NAT) > Author(s) : Simon Perreault > Tina Tsou > Senthil Sivakumar > Filename : draft-ietf-behave-nat-mib-06.txt > Pages : 82 > Date : 2013-05-01 > > Abstract: > This memo defines a portion of the Management Information Base = (MIB) > for devices implementing Network Address Translator (NAT) = function. > This MIB module may be used for monitoring of a device capable of = NAT > function. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-behave-nat-mib-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat-mib-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Thu May 2 18:07:07 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452E121F8EC2 for ; Thu, 2 May 2013 18:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNPXx3Z7aLf2 for ; Thu, 2 May 2013 18:07:06 -0700 (PDT) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id C195621F8EAF for ; Thu, 2 May 2013 18:07:06 -0700 (PDT) Received: by mail-ia0-f182.google.com with SMTP id x30so959238iaa.27 for ; Thu, 02 May 2013 18:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=uNDzQzrGIEIZkv6mkwMx2oHZJdgEKVvmNxJnaHSCO9c=; b=oPz77ZRlgMHPzqVfhcfV1I4QSJny4JjuBhhJjEdDKPopy5LRltQszX/L7Mh1MrmnUy 86dHodIC7wRsXWcpiaxb6+2LxlHrpm/Sj7wDcaAORy5XgZ8FZeJI9KTiVs+DibIihk65 vmO+3tDrp3p82xQwnMDzIjLmJCzCSaGrUWC/UaOv1eYpXxNaQ1j08bwRXOYKTvzVYp7Z bgsn36/bpQL2PRXlhuwjsE2Nf/MJbQ0eXWM9/I38W906/bTStGWFBfdFuJ4uSOvk8dah iwHEd5WWoxualJxQ8cMTkbSrL5ahF2b8SRf69N4bsDRwe68qwRCh7NtnJ3oIY43lmsew Vidg== X-Received: by 10.50.152.105 with SMTP id ux9mr4712957igb.53.1367543226412; Thu, 02 May 2013 18:07:06 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-104-209.tor.primus.ca. [173.206.104.209]) by mx.google.com with ESMTPSA id w8sm18677954igl.9.2013.05.02.18.07.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 May 2013 18:07:05 -0700 (PDT) Message-ID: <51830DB7.4050201@gmail.com> Date: Thu, 02 May 2013 21:07:03 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "behave@ietf.org" , David Harrington Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 01:07:07 -0000 In organizing the encoding for the SYSLOG approach, I need to decide how to define the structured data elements. Each such element is identified by an SD-ID and contains a specified set of parameters. I have eight events in all (including "invalid port detected"), and twenty different parameters. The accounting is a little different from IPFIX because some IPFIX parameters end up in the SYSLOG headers instead. One parameter is common to all of the events, a few are common to at least four of them, and the rest are more scattered. There may be some reconciliation required when I submit the SYSLOG update. The question is how to define the structured data elements. Here are the possibilities: (a) define only one structured data element, within which all parameters are optional from the point of view of SYSLOG, but individual parameters may be mandatory from the application point of view depending on the event type. Every event would use the same structured data element. (b) define one structured data element per event, with mandatory and optional parameters as required. The same parameter would then be registered formally with IANA once for each event using it. (c) variation on (a): partition the parameters amongst multiple structured data elements, more than one of which may be needed to make up a complete event report. One possible use is to group parameters relating to a given NAT type. The disadvantage is a bit longer log lengths because of the additional structured data headers. Are there any opinions on all this? SYSLOG is defined in RFC 5424. Tom Taylor From ssenthil@cisco.com Thu May 2 18:42:22 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C98921F8FF5 for ; Thu, 2 May 2013 18:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF0kT5fmUb8r for ; Thu, 2 May 2013 18:42:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 69CAF21F9017 for ; Thu, 2 May 2013 18:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1996; q=dns/txt; s=iport; t=1367545337; x=1368754937; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=DDNdr39cLbzh/2niLQddaaoYQ3BtUXc5yKL2jFRrgiE=; b=RWNcNmhSPNel3DArFnzgqQzfFK00dynt4WebMLtyYVhBbKTbXPFYAxXM CYsD4T4suOiZqbVlIp47S1t5vfMz76WhZN0RVFqvWqEztsdb8CIC92H23 RaUgNBhh95XqJG7aGSVzzsyLwc3/xIO9zct0MfsbPT4GTuBizbbyDguHC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAAIVg1GtJV2d/2dsb2JhbABSgwc3vyiBABZ0giEBBAEBATc0HQEIIhQxBgslAgQBEgiHcgMPDLh/DYgDBIxPgiY4gnJhA5VHjXWFIYMNgic X-IronPort-AV: E=Sophos;i="4.87,600,1363132800"; d="scan'208";a="202914324" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 03 May 2013 01:42:17 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r431gHtc001564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 01:42:17 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.104]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 2 May 2013 20:42:16 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "behave@ietf.org" , David Harrington Thread-Topic: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters Thread-Index: AQHOR5qLu6NZrqbL+UaY0n/vMbXrT5jywGyA Date: Fri, 3 May 2013 01:42:15 +0000 Message-ID: In-Reply-To: <51830DB7.4050201@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.117.198.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <69C9B120017EA4409BA31FF6A4168C92@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 01:42:22 -0000 Option b would be my preference, as it seems the most straight forward approach,=20 easy to understand and implement. Senthil On 5/2/13 9:07 PM, "Tom Taylor" wrote: >In organizing the encoding for the SYSLOG approach, I need to decide how >to define the structured data elements. Each such element is identified >by an SD-ID and contains a specified set of parameters. > >I have eight events in all (including "invalid port detected"), and >twenty different parameters. The accounting is a little different from >IPFIX because some IPFIX parameters end up in the SYSLOG headers >instead. One parameter is common to all of the events, a few are common >to at least four of them, and the rest are more scattered. There may be >some reconciliation required when I submit the SYSLOG update. > >The question is how to define the structured data elements. Here are the >possibilities: > >(a) define only one structured data element, within which all parameters >are optional from the point of view of SYSLOG, but individual parameters >may be mandatory from the application point of view depending on the >event type. Every event would use the same structured data element. > >(b) define one structured data element per event, with mandatory and >optional parameters as required. The same parameter would then be >registered formally with IANA once for each event using it. > >(c) variation on (a): partition the parameters amongst multiple >structured data elements, more than one of which may be needed to make >up a complete event report. One possible use is to group parameters >relating to a given NAT type. The disadvantage is a bit longer log >lengths because of the additional structured data headers. > >Are there any opinions on all this? SYSLOG is defined in RFC 5424. > >Tom Taylor >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From repenno@cisco.com Thu May 2 18:58:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9230921F90D2 for ; Thu, 2 May 2013 18:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNatGQb3IWks for ; Thu, 2 May 2013 18:57:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0921F9058 for ; Thu, 2 May 2013 18:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2294; q=dns/txt; s=iport; t=1367546275; x=1368755875; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=0gnJ7UVOF/SFLXluVkdU0q/BAu4kyY1sDpaz6TjNReM=; b=WA5awv5NAxRpKJ8HyDtyLrA6LFcMwaGQNy5nckyAXQGzeukkIl4fs3tX ++jd67huZwFu2afHDa1Gb5yPGNbU9LdlqgpznHhDekrQpfQkvnoEiqkH/ jlSeP4d7nETH5U2vve0i/LyTxp57T/MI/+Pewf3XCBzVB8FhEHcaQ3Xgr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAI0Yg1GtJXHB/2dsb2JhbABSgwc3vyiBABZ0gh8BAQEEAQEBNzQdAQgYChQxBgslAgQBEgiHcgMPDLh9DYgDBIxPgiY4gnJhA5VHjXWFIYMNgic X-IronPort-AV: E=Sophos;i="4.87,600,1363132800"; d="scan'208";a="205886680" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 03 May 2013 01:57:55 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r431vssI004892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 01:57:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.96]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 2 May 2013 20:57:54 -0500 From: "Reinaldo Penno (repenno)" To: "Senthil Sivakumar (ssenthil)" , Tom Taylor , "behave@ietf.org" , "David Harrington" Thread-Topic: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters Thread-Index: AQHOR5qLxG8kIZ+LcU+tQGjun+gyWJjzA32A///SEYA= Date: Fri, 3 May 2013 01:57:54 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409062ADD@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.84.65] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 01:58:00 -0000 I agree Senthil's proposal. On 5/2/13 10:42 PM, "Senthil Sivakumar (ssenthil)" wrote: >Option b would be my preference, as it seems the most straight forward >approach,=20 >easy to understand and implement. > >Senthil > >On 5/2/13 9:07 PM, "Tom Taylor" wrote: > >>In organizing the encoding for the SYSLOG approach, I need to decide how >>to define the structured data elements. Each such element is identified >>by an SD-ID and contains a specified set of parameters. >> >>I have eight events in all (including "invalid port detected"), and >>twenty different parameters. The accounting is a little different from >>IPFIX because some IPFIX parameters end up in the SYSLOG headers >>instead. One parameter is common to all of the events, a few are common >>to at least four of them, and the rest are more scattered. There may be >>some reconciliation required when I submit the SYSLOG update. >> >>The question is how to define the structured data elements. Here are the >>possibilities: >> >>(a) define only one structured data element, within which all parameters >>are optional from the point of view of SYSLOG, but individual parameters >>may be mandatory from the application point of view depending on the >>event type. Every event would use the same structured data element. >> >>(b) define one structured data element per event, with mandatory and >>optional parameters as required. The same parameter would then be >>registered formally with IANA once for each event using it. >> >>(c) variation on (a): partition the parameters amongst multiple >>structured data elements, more than one of which may be needed to make >>up a complete event report. One possible use is to group parameters >>relating to a given NAT type. The disadvantage is a bit longer log >>lengths because of the additional structured data headers. >> >>Are there any opinions on all this? SYSLOG is defined in RFC 5424. >> >>Tom Taylor >>_______________________________________________ >>Behave mailing list >>Behave@ietf.org >>https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Fri May 3 00:51:54 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA6621F94D0 for ; Fri, 3 May 2013 00:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWQloWYzmKuU for ; Fri, 3 May 2013 00:51:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 19DF921F94FF for ; Fri, 3 May 2013 00:51:47 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DE6F14034D; Fri, 3 May 2013 03:51:41 -0400 (EDT) Message-ID: <51836C8E.6070905@viagenie.ca> Date: Fri, 03 May 2013 09:51:42 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ietfdbh References: <03e901ce478a$d75cdf90$86169eb0$@comcast.net> In-Reply-To: <03e901ce478a$d75cdf90$86169eb0$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave-ads@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] nat-mib-06: separate MIB modules X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 07:51:55 -0000 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, that would be great. Thanks, Simon Le 2013-05-03 01:14, ietfdbh a écrit : > I would like to suggest a change. > If I understand correctly, this document deprecates the entire RFC4008 > NAT-MIB, and proposes a completely new MIB under the same name. > I think this is sub-optimal. > In NMS applications that support multiple devices, some of which support > RFC4008 and some of which support this new MIB module, it will be > potentially confusing to call them by the same name. > You really have two completely different MIB modules that you are trying to > sell under the same name. > I think that is not a good idea. > > I recommend writing an RFC4008bis document to deprecate the RFC4008 NAT-MIB. > Then put your proposed new MIB objects into a separate MIB module, using a > different name for the newly designed MIB for managing NATs > (maybe NEW-NAT-MIB, but I'd hope for something that more accurately > describes the modified purpose of the MIB, maybe NAT-MONITORING-MIB) > Put this in a separate RFC. > > I think that would be a much cleaner solution, and much more obvious what > you are doing here. From clonvick@cisco.com Fri May 3 09:28:02 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7C321F9730 for ; Fri, 3 May 2013 09:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq5DFI-B0xHm for ; Fri, 3 May 2013 09:27:56 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA4C21F9802 for ; Fri, 3 May 2013 08:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3050; q=dns/txt; s=iport; t=1367595500; x=1368805100; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=P463ZBHPPWIjtqp19qy090OH92GYQZ5BoBKg0BuH6s4=; b=SAFXEs5ghW9BRfmDtrTbB1WOgpLDvTnGwOyUbz3TWHJybhfMbn6KyFb9 2xb9Op1q2zOjoJCTIR/bTnMT1waCe2i2FJqlM0GwNA0MGroFYkDYR7lIr LZ81iIPotDRKuTBPyXFCELu3Vw401SUEAfhh7Vi0XP3Vpp3eqjbfThzrF A=; X-IronPort-AV: E=Sophos;i="4.87,605,1363132800"; d="scan'208";a="77160329" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 03 May 2013 15:38:19 +0000 Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r43FcIto024266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 May 2013 15:38:18 GMT Date: Fri, 3 May 2013 08:38:17 -0700 (PDT) From: Chris Lonvick To: Tom Taylor , "Reinaldo Penno (repenno)" In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F060409062ADD@xmb-rcd-x04.cisco.com> Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F060409062ADD@xmb-rcd-x04.cisco.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: David Harrington , "behave@ietf.org" Subject: Re: [BEHAVE] SYSLOG strategy for organizing NAT logging event parameters X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 16:28:02 -0000 Hi, The thought that went into structured data in RFC5424 was to keep it simple for the sender to put together, and easy for the receiver to parse. The latter is especially critical if the receiver is going to immediately parse the message upon receipt. If anyone is interested, John Kelsey wrote some things about that in Section 7 of RFC 5848, "Signed Syslog Messages". I'd also agree that B gives the most flexibility. Thanks, Chris On Thu, 2 May 2013, Reinaldo Penno (repenno) wrote: > I agree Senthil's proposal. > > On 5/2/13 10:42 PM, "Senthil Sivakumar (ssenthil)" > wrote: > >> Option b would be my preference, as it seems the most straight forward >> approach, >> easy to understand and implement. >> >> Senthil >> >> On 5/2/13 9:07 PM, "Tom Taylor" wrote: >> >>> In organizing the encoding for the SYSLOG approach, I need to decide how >>> to define the structured data elements. Each such element is identified >>> by an SD-ID and contains a specified set of parameters. >>> >>> I have eight events in all (including "invalid port detected"), and >>> twenty different parameters. The accounting is a little different from >>> IPFIX because some IPFIX parameters end up in the SYSLOG headers >>> instead. One parameter is common to all of the events, a few are common >>> to at least four of them, and the rest are more scattered. There may be >>> some reconciliation required when I submit the SYSLOG update. >>> >>> The question is how to define the structured data elements. Here are the >>> possibilities: >>> >>> (a) define only one structured data element, within which all parameters >>> are optional from the point of view of SYSLOG, but individual parameters >>> may be mandatory from the application point of view depending on the >>> event type. Every event would use the same structured data element. >>> >>> (b) define one structured data element per event, with mandatory and >>> optional parameters as required. The same parameter would then be >>> registered formally with IANA once for each event using it. >>> >>> (c) variation on (a): partition the parameters amongst multiple >>> structured data elements, more than one of which may be needed to make >>> up a complete event report. One possible use is to group parameters >>> relating to a given NAT type. The disadvantage is a bit longer log >>> lengths because of the additional structured data headers. >>> >>> Are there any opinions on all this? SYSLOG is defined in RFC 5424. >>> >>> Tom Taylor >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From ietfdbh@comcast.net Fri May 3 12:05:53 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E6D21F870F for ; Fri, 3 May 2013 12:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5oEnnrrp4Fs for ; Fri, 3 May 2013 12:05:48 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id D386E21F8F5C for ; Fri, 3 May 2013 12:05:30 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta01.westchester.pa.mail.comcast.net with comcast id XPQ81l0021YDfWL51X5Wqu; Fri, 03 May 2013 19:05:30 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta20.westchester.pa.mail.comcast.net with comcast id XX5V1l0132yZEBF3gX5Wvn; Fri, 03 May 2013 19:05:30 +0000 From: "ietfdbh" To: "'Simon Perreault'" References: <03e901ce478a$d75cdf90$86169eb0$@comcast.net> <51836C8E.6070905@viagenie.ca> In-Reply-To: <51836C8E.6070905@viagenie.ca> Date: Fri, 3 May 2013 15:05:31 -0400 Message-ID: <044301ce4831$2f17cf50$8d476df0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJWQqeLYnFoBbWdkdsg9ovZyZNpiAEZ4iEul9sNtDA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367607930; bh=iTEbfVv8nc1HoFpsdToo6izE6/42vZ42CUbm41F2+mc=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=lo2IiX4FLmyEUOGz9lrM2MEQcGZCjkyDSZD3W7PftTXDPnq2evcF3KD1LOlXFp1Sy YnI6Pz4v+62R0+uOK3XuITnCvrSJzwO6rl3EDFP2jYU05pjqN1SD721ucS58IGYTg/ edbUv3s3D75TIrV4mH8cPUhGLFGSbV8T2iAw+Dvjs39u2f6zJNOd6INtfCbB/lHUUu 5NIz2AJHck8IchkJiYBvIUSt2htrwnFUWpWH2EPfe0E0TvYSpsl1TVtczOQpHcIpFh eNCxyxe6UXas04nKsh7/V47Kbx/AOgzaq9gvAFzKw0eoMFa2IvQQA4ErooHZQE+WRu 4cFOWpaVjip8g== Cc: behave-ads@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] nat-mib-06: separate MIB modules X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:05:54 -0000 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@comcast.net +1-603-828-1401 -----Original Message----- From: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Sent: Friday, May 03, 2013 3:52 AM To: ietfdbh Cc: behave@ietf.org; behave-ads@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, that would be great. Thanks, Simon Le 2013-05-03 01:14, ietfdbh a =E9crit : > I would like to suggest a change. > If I understand correctly, this document deprecates the entire RFC4008 = > NAT-MIB, and proposes a completely new MIB under the same name. > I think this is sub-optimal. > In NMS applications that support multiple devices, some of which=20 > support > RFC4008 and some of which support this new MIB module, it will be=20 > potentially confusing to call them by the same name. > You really have two completely different MIB modules that you are=20 > trying to sell under the same name. > I think that is not a good idea. > > I recommend writing an RFC4008bis document to deprecate the RFC4008 NAT-MIB. > Then put your proposed new MIB objects into a separate MIB module,=20 > using a different name for the newly designed MIB for managing NATs=20 > (maybe NEW-NAT-MIB, but I'd hope for something that more accurately=20 > describes the modified purpose of the MIB, maybe NAT-MONITORING-MIB)=20 > Put this in a separate RFC. > > I think that would be a much cleaner solution, and much more obvious=20 > what you are doing here. From dwing@cisco.com Fri May 3 15:43:32 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C120521F8F26 for ; Fri, 3 May 2013 15:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA0uK0Qcp4Um for ; Fri, 3 May 2013 15:43:28 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AE2D321F8F6E for ; Fri, 3 May 2013 15:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=480; q=dns/txt; s=iport; t=1367621005; x=1368830605; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=7m47NM6/Xtou5+Lig2/5zwPnQn2Ii3ASb1lKZb5L58Q=; b=am+g9apM3AKKQiYuOTX3BNnhiK30Ou7oFxQyeBASLTLq2CCGR1pqrTMV uOxJXCatlFKQhClkYA/7LxB/fyohrQ7qUmdlMPbgKz8gGgROfkuViOlAf vsKUUIbTit5mKE+K1p6dGFWIJ2D2MOQW9wLfKyFdud8gaUXIhqhtRcnkl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4GAFw8hFGrRDoJ/2dsb2JhbABQgwc3gnWvXYxjehZtB4JDHT+BPogeDcFXjzGCeWEDiRqOEoEmhG+LHYMtHA X-IronPort-AV: E=Sophos;i="4.87,607,1363132800"; d="scan'208";a="80275629" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 03 May 2013 22:43:24 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r43MhNMB023128; Fri, 3 May 2013 22:43:23 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 3 May 2013 15:43:23 -0700 Message-Id: To: "behave@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org" , "Behave Chairs \(behave-chairs@tools.ietf.org\)" Subject: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 22:43:32 -0000 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. =20 http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-04 -d From rmohanr@cisco.com Sun May 5 10:41:26 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB8121F9709 for ; Sun, 5 May 2013 10:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb8GMsgjangP for ; Sun, 5 May 2013 10:41:21 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3904321F970B for ; Sun, 5 May 2013 10:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1165; q=dns/txt; s=iport; t=1367775681; x=1368985281; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Fwoj+ed12eqtp2tk8l45CLE0wLUVgU3JQsgm9hnFKcs=; b=DEsFtev5qPbsSZMAonrBTYgeNuRNBhAv8VI5XT6/y9w/biTbKPrkc99C WhEo7wualc7hYOxMQwg6u8nkFi0pz4LzOWkTqiF0XqVYbWaWleEN1wTRZ +c8RpmTNoIt5BEbJzZQrifwvwMcqkh1w5kURgGlBXFyLsFu8nMqsUTE1b s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIFAN2YhlGtJXG8/2dsb2JhbABQgwc3RL8BfxZtB4IfAQEBAwE6PQcNAQgiFEIbAQYDAgQTCAGHfQYHBaBXnl+PADiCcmEDmFSQDoMNgic X-IronPort-AV: E=Sophos;i="4.87,616,1363132800"; d="scan'208";a="206440333" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 05 May 2013 17:41:20 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r45HfKau029417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 5 May 2013 17:41:20 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.52]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Sun, 5 May 2013 12:41:20 -0500 From: "Ram Mohan R (rmohanr)" To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-reddy-behave-turn-auth-01.txt Thread-Index: AQHOSbdHzt4rGhlLtkyhidzGVsT9lZj3jOwA Date: Sun, 5 May 2013 17:41:20 +0000 Message-ID: In-Reply-To: <20130505173753.27896.70611.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.65.46.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <09CB157C6DB3D2498947A5C5751E4AB8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 17:41:26 -0000 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. > On 05/05/13 11:07 PM, "internet-drafts@ietf.org" > wrote: > >A new version of I-D, draft-reddy-behave-turn-auth-01.txt >has been successfully submitted by Tirumaleswar Reddy and posted to the >IETF repository. > >Filename: draft-reddy-behave-turn-auth >Revision: 01 >Title: Problems with STUN Authentication for TURN >Creation date: 2013-05-05 >Group: Individual Submission >Number of pages: 7 >URL: =20 >http://www.ietf.org/internet-drafts/draft-reddy-behave-turn-auth-01.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-reddy-behave-turn-auth >Htmlized: =20 >http://tools.ietf.org/html/draft-reddy-behave-turn-auth-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-behave-turn-auth-01 > >Abstract: > This document discusses some of the issues with STUN authentication > for TURN messages. > > =20 > =20 > > >The IETF Secretariat > > From internet-drafts@ietf.org Wed May 8 08:44:48 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3867D21F93C8; Wed, 8 May 2013 08:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT+3fkrcix0e; Wed, 8 May 2013 08:44:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE4C21F8FE9; Wed, 8 May 2013 08:44:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130508154447.24024.36769.idtracker@ietfa.amsl.com> Date: Wed, 08 May 2013 08:44:47 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:44:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Syslog Format for NAT Logging Author(s) : Zhonghua Chen Cathy Zhou Tina Tsou T. Taylor Filename : draft-ietf-behave-syslog-nat-logging-01.txt Pages : 31 Date : 2013-05-08 Abstract: With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of NAT-related events has become very important for legal purposes. The logs may be required to identify a host that was used to launch malicious attacks or engage in illegal behaviour, and/or may be required for accounting purposes. This document identifies the events that need to be logged and the parameters that are required in the logs depending on the context in which the NAT is being used. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 5101). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-syslog-nat-logging-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tom.taylor.stds@gmail.com Wed May 8 08:56:07 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9711921F94A6 for ; Wed, 8 May 2013 08:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THxIvM8fjRGQ for ; Wed, 8 May 2013 08:56:07 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8021F8E74 for ; Wed, 8 May 2013 08:55:46 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k5so3535276iea.4 for ; Wed, 08 May 2013 08:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZB/eKB1oj2wDjoproageqQ5KzmYumbszmCwX7ZkgalY=; b=UuTujeZlYwl51W0OQjDsP22Q8qC4p5esxbkoJUBGc6pQLloWR7qCI22lasD1h+nSEb nNBwsrf+CLBeMxXh9Wg0wRwQg/oxghPMV7lm3Jx/ritepJxme5l1U5zDzSWLuoOMfPm4 PGDKEOLDe+XO8MYS5pUpCXpjuf6rSiz3Lmp/z67qXZMW8/4JXVFGWBua3zxTEKK+Wv5k SWYPYEHmXm/m4OlTRghSExAkG9GMj461Pu8aqQP0JL1r9gIqVSFlMAO980vDBsZYc1SV enr6ZLgdIo3gnLSWat0aHWLCMYkWe3HRU/xtmRAGMFVLd/IopVDIcioeb89VmnEj2ABd JQyw== X-Received: by 10.50.212.3 with SMTP id ng3mr2761477igc.43.1368028546304; Wed, 08 May 2013 08:55:46 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-68-118.tor.primus.ca. [173.206.68.118]) by mx.google.com with ESMTPSA id ve9sm3337476igb.3.2013.05.08.08.55.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 08:55:45 -0700 (PDT) Message-ID: <518A757F.5000701@gmail.com> Date: Wed, 08 May 2013 11:55:43 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: behave@ietf.org References: <20130508154447.24024.36769.idtracker@ietfa.amsl.com> In-Reply-To: <20130508154447.24024.36769.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:56:07 -0000 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@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 : Syslog Format for NAT Logging > Author(s) : Zhonghua Chen > Cathy Zhou > Tina Tsou > T. Taylor > Filename : draft-ietf-behave-syslog-nat-logging-01.txt > Pages : 31 > Date : 2013-05-08 > > Abstract: > With the wide deployment of Carrier Grade NAT (CGN) devices, the > logging of NAT-related events has become very important for legal > purposes. The logs may be required to identify a host that was used > to launch malicious attacks or engage in illegal behaviour, and/or > may be required for accounting purposes. This document identifies > the events that need to be logged and the parameters that are > required in the logs depending on the context in which the NAT is > being used. It goes on to standardize formats for reporting these > events and parameters using SYSLOG (RFC 5424). A companion document > specifies formats for reporting the same events and parameters using > IPFIX (RFC 5101). Applicability statements are provided in this > document and its companion to guide operators and implementors in > their choice of which technology to use for logging. > ... From rajiva@cisco.com Thu May 9 05:19:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB4721F8BC0 for ; Thu, 9 May 2013 05:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJnKCiE6hl+i for ; Thu, 9 May 2013 05:19:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 761B521F8D6A for ; Thu, 9 May 2013 05:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2926; q=dns/txt; s=iport; t=1368101943; x=1369311543; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=TW1++ZXvOYxG9kzGAni3XJF+5q/ZlT9U9itjLq3R3gg=; b=ACgnPrnOfeCBsGTQK4cpYbu+X/JnBzLLuWY3U9clritIzaKFRYjvOciO RTmVtxD4PSBtPLeK+VoZ2E1Lgl2bToHnbHgQwbe3LoTjQ3baMaWxSlLJc LjjM8uZGU7AAtAvWTGs0zk2DTVVhrjN7utH3oC/e7YOOkUtPxZvPkvfe/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJKTi1GtJV2d/2dsb2JhbABSgwc3wAd8FnSCHwEBAQMBAQEBJEcJBwcGAQgRAwECCxkyCx0IAgQBEgiHfgYMwSGOdzgGgm5hA4hij3CQD4FXgTiCJw X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="205335445" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 09 May 2013 12:19:02 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r49CJ2Bv008842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 12:19:02 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.174]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 9 May 2013 07:19:02 -0500 From: "Rajiv Asati (rajiva)" To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt Thread-Index: AQHOTK9jaOM7bqd790Smts+64Be8ww== Date: Thu, 9 May 2013 12:19:01 +0000 Message-ID: In-Reply-To: <515D4C91.4020504@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.65.67.42] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <290B08958753F242865908C244E1DFE4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 12:19:08 -0000 Hi Simon, > An ISP is running out of addresses. It considers two options: static CGN > vs dynamic CGN. Static allows, let's say, 32 users per public IPv4 > address. Given the 1:10 figure from the draft, it follows that dynamic > allows 320 users per public IPv4 address. 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 Date: Thursday, April 4, 2013 5:49 AM To: Behave WG Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt >Le 2013-04-03 20:57, Senthil Sivakumar (ssenthil) a =E9crit : >> If it is not the address, what is the limiting factor? The reason ISP >> is deploying CGN is the shortage of addresses and cant provide a >> single address to each of his subscribers. Maybe you meant to say the >> address is not the only limiting factor. I never said the text was >> saying static isnt good enough :-), I deduced from the study that the >> usage of ports is far more compellingly efficient with dynamic port >> allocation and the cost of logging infra can be justified. > >I'll try to illustrate my point with an example with numbers. > >An ISP is running out of addresses. It considers two options: static CGN >vs dynamic CGN. Static allows, let's say, 32 users per public IPv4 >address. Given the 1:10 figure from the draft, it follows that dynamic >allows 320 users per public IPv4 address. > >If 32 is "enough", why suffer the trouble of logging (among others) just >to get to 320? If 32 and 320 are both "enough", then considerations >other than efficient use of public IPv4 addresses must take priority. > >"Enough" could mean something like "enough to support projected growth >for X years". > >> Most of the studies in the past projected how bad the logging problem >> is but didn=B9t have any data on the other side of the equation on how >> inefficient the static port allocation is. I wouldn=B9t want this draft >> to say one is better than the other, but let the operators choose, if >> 10:1 static to dynamic port allocation is justified for their >> deployment. > >The 10:1 figure is useful. However, the conclusion "therefore dynamic is >better" is premature. There are tons of other criteria to consider. Even >worse, it is very possible that the 10:1 figure does not even matter: if >static is "good enough", you may not care that dynamic is 10 times better. > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Mon May 13 04:46:31 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9103721F9425 for ; Mon, 13 May 2013 04:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjTfzNEX0nM9 for ; Mon, 13 May 2013 04:46:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0B721F93E1 for ; Mon, 13 May 2013 04:46:31 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:3dce:24d5:a561:3385]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5F4B14044E; Mon, 13 May 2013 07:46:29 -0400 (EDT) Message-ID: <5190D29B.9070805@viagenie.ca> Date: Mon, 13 May 2013 13:46:35 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 11:46:31 -0000 Le 2013-05-09 14:19, Rajiv Asati (rajiva) a écrit : >> An ISP is running out of addresses. It considers two options: static CGN >> vs dynamic CGN. Static allows, let's say, 32 users per public IPv4 >> address. Given the 1:10 figure from the draft, it follows that dynamic >> allows 320 users per public IPv4 address. > > 1:32 (dynamic assignment) on top of 1:10 (static assignment)? Did you > intend to nest? > > Could you please clarify? 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 From mohamed.boucadair@orange.com Mon May 13 07:20:51 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F8221F9601 for ; Mon, 13 May 2013 07:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4miNfdnY8m7S for ; Mon, 13 May 2013 07:20:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id CA89621F9425 for ; Mon, 13 May 2013 07:20:45 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id DEB3F2DCB40; Mon, 13 May 2013 16:20:43 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B7F6B35C045; Mon, 13 May 2013 16:20:43 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 13 May 2013 16:20:43 +0200 From: To: Dan Wing , "behave@ietf.org" Date: Mon, 13 May 2013 16:20:42 +0200 Thread-Topic: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis Thread-Index: Ac5IT6bCnWkUk+C2QeGKR2FViXGfRQHlTDqg Message-ID: <94C682931C08B048B7A8645303FDC9F36ECEBCEA27@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.13.134220 Cc: "draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org" , "Behave Chairs \(behave-chairs@tools.ietf.org\)" Subject: Re: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 14:20:51 -0000 I support this effort.=20 >-----Message d'origine----- >De=A0: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part= de >Dan Wing >Envoy=E9=A0: samedi 4 mai 2013 00:43 >=C0=A0: behave@ietf.org >Cc=A0: draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org; Behave Cha= irs >(behave-chairs@tools.ietf.org) >Objet=A0: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508= - >bis > >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 > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From repenno@cisco.com Mon May 13 07:42:54 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84EA21F8F6E for ; Mon, 13 May 2013 07:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9psImXEbuE0 for ; Mon, 13 May 2013 07:42:50 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E521F8F4F for ; Mon, 13 May 2013 07:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1414; q=dns/txt; s=iport; t=1368456170; x=1369665770; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=X/gQ4UkTZ6jBJjvGjHrpmV7BpxG1vzHQMl+6s3/b1Ak=; b=jvgm9CYPC8DW8SK9re/Imzb66rvOEd1Ce4O4x1ww4dUPszZkBkxU4AYk HflbX+v9kIWH8WacTJ28ayyYNbVF+Cx8pt+I9m9CqCQh+iUPSnc/DB3LP IWhcasfYQV+a11tDbB2Qyn0tJBG8ldTB8Zf3RxuWFWaeO51SCpc4mKd03 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAGP7kFGtJV2Z/2dsb2JhbABagwc3wCqBAxZ0giEBBAEBARpRCxIBCCIdLgsUEQIEAQ0FCIgEDLtFjncxB4J0YQOIYo9wkA+DD4In X-IronPort-AV: E=Sophos;i="4.87,662,1363132800"; d="scan'208";a="209782225" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 13 May 2013 14:42:48 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4DEgluc002406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 May 2013 14:42:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 13 May 2013 09:42:47 -0500 From: "Reinaldo Penno (repenno)" To: "mohamed.boucadair@orange.com" , "Dan Wing (dwing)" , "behave@ietf.org" Thread-Topic: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis Thread-Index: AQHOSE+oeu1CoLmSrUmFSosWVWflp5kDjUsA///T4AA= Date: Mon, 13 May 2013 14:42:46 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908272B@xmb-rcd-x04.cisco.com> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ECEBCEA27@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.82.84] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7068BA210C56BD48B8061D7FEF692CDD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org" , "Behave Chairs \(behave-chairs@tools.ietf.org\)" Subject: Re: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 14:42:55 -0000 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@orange.com" wrote: >I support this effort. > > >>-----Message d'origine----- >>De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part >>de >>Dan Wing >>Envoy=E9 : samedi 4 mai 2013 00:43 >>=C0 : behave@ietf.org >>Cc : draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org; Behave >>Chairs >>(behave-chairs@tools.ietf.org) >>Objet : [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508- >>bis >> >>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 >> >>_______________________________________________ >>Behave mailing list >>Behave@ietf.org >>https://www.ietf.org/mailman/listinfo/behave >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From naito.kengo@lab.ntt.co.jp Tue May 14 19:18:26 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84A421F8AE2 for ; Tue, 14 May 2013 19:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ua2doqvAlkV for ; Tue, 14 May 2013 19:18:21 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 452A321F8A7B for ; Tue, 14 May 2013 19:18:21 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id r4F2IBxw012265; Wed, 15 May 2013 11:18:11 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 83D81E0272; Wed, 15 May 2013 11:18:11 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 7809DE026C; Wed, 15 May 2013 11:18:11 +0900 (JST) Received: from [127.0.0.1] ([129.60.7.245]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id r4F2IAMk018666; Wed, 15 May 2013 11:18:11 +0900 Message-ID: <5192F062.7060101@lab.ntt.co.jp> Date: Wed, 15 May 2013 11:18:10 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dan Wing (dwing)" References: <45A697A8FFD7CF48BCF2BE7E106F06040908272B@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908272B@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , "draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org" , "Behave Chairs \(behave-chairs@tools.ietf.org\)" Subject: Re: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 02:18:26 -0000 As a co-author, I also support this effort. (2013/05/13 23:42), Reinaldo Penno (repenno) wrote: > 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@orange.com" > wrote: > >> I support this effort. >> >> >>> -----Message d'origine----- >>> De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part >>> de >>> Dan Wing >>> Envoyé : samedi 4 mai 2013 00:43 >>> À : behave@ietf.org >>> Cc : draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org; Behave >>> Chairs >>> (behave-chairs@tools.ietf.org) >>> Objet : [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508- >>> bis >>> >>> 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 >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From n@arifumi.net Tue May 14 19:29:41 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0321F8A6B for ; Tue, 14 May 2013 19:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23m+EHrELvi4 for ; Tue, 14 May 2013 19:29:36 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9864A21F8AD8 for ; Tue, 14 May 2013 19:29:36 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id x10so931327pdj.7 for ; Tue, 14 May 2013 19:29:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=QdZB6yIsAqUYCgGwgE7BcsjHm20iClQNRa0ai7AuupI=; b=E1kWJXcb/MOWxiyADIHtBdrhKkB4uPhjQ+ZINunPzcm5Y117/TEvpBQFkWvjZb9kpQ eY3nm2knVdo2/NG3LNNJ++SvP9UKEF681GZOc6ryaoALg8WnkY1XjwNb1agFrxlhBWQp oC0B6SdHo58Rti/88dg9A88DnrQJBLdaJVAPURKgSPhgsyQk3FNU5vtEgLV5XnhELexu XrIXNf6sFx9SC15XUaJOFS2z91BYyU151njxE5kijBMYgIZ2CiHFgeE5legKk6nVHFBn Hn7NPLXXdPOlbWWG6I7aVWMUh8o/eMFFTKzpSmXe/ZusV0ssFErDUUP2mScqVT6b7F4F BOww== MIME-Version: 1.0 X-Received: by 10.68.163.165 with SMTP id yj5mr36344670pbb.207.1368584975980; Tue, 14 May 2013 19:29:35 -0700 (PDT) Sender: n@arifumi.net Received: by 10.68.54.69 with HTTP; Tue, 14 May 2013 19:29:35 -0700 (PDT) X-Originating-IP: [192.68.248.65] In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908272B@xmb-rcd-x04.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36ECEBCEA27@PUEXCB1B.nanterre.francetelecom.fr> <45A697A8FFD7CF48BCF2BE7E106F06040908272B@xmb-rcd-x04.cisco.com> Date: Wed, 15 May 2013 11:29:35 +0900 X-Google-Sender-Auth: 9Sa7eAuEVScG3fXhlo3JYBLCRlI Message-ID: From: Arifumi Matsumoto To: "Reinaldo Penno (repenno)" Content-Type: multipart/alternative; boundary=047d7b86d55656ac0704dcb885d8 X-Gm-Message-State: ALoCoQlalj+JIL6mOjz3jELmPXO4Qo2qmxzbyBfJmysxEEuMG3FJGGI8+N4cheRqTdr2o9vb9TnG Cc: "behave@ietf.org" , "mohamed.boucadair@orange.com" , "draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org" , "Dan Wing \(dwing\)" , "Behave Chairs \(behave-chairs@tools.ietf.org\)" Subject: Re: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 02:29:41 -0000 --047d7b86d55656ac0704dcb885d8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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) > 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@orange.com" > wrote: > > >I support this effort. > > > > > >>-----Message d'origine----- > >>De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la par= t > >>de > >>Dan Wing > >>Envoy=E9 : samedi 4 mai 2013 00:43 > >>=C0 : behave@ietf.org > >>Cc : draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org; Behave > >>Chairs > >>(behave-chairs@tools.ietf.org) > >>Objet : [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-550= 8- > >>bis > >> > >>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 y= ou > >>feel appropriate; clear indications of 'support' or 'do not support' ar= e > >>appreciated. > >> > >> http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-0= 4 > >> > >>-d > >> > >>_______________________________________________ > >>Behave mailing list > >>Behave@ietf.org > >>https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --047d7b86d55656ac0704dcb885d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I support this draft.
In that, It contains p= ractical and significant improvements over these existing RFCs,
such as those mechanisms for address resource limit= ed environment.

2013/5/13 R= einaldo Penno (repenno) <repenno@cisco.com>
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@orange.com"
<mohamed.boucadair@orange.com> wrote:

>I support this effort.
>
>
>>-----Message d'origine-----
>>De : behave-bounces@ietf= .org [mailto:behave-bounces@= ietf.org] De la part
>>de
>>Dan Wing
>>Envoy=E9 : samedi 4 mai 2013 00:43
>>=C0 : behave@ietf.org
>>Cc : draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org; B= ehave
>>Chairs
>>(behave-chairs@tool= s.ietf.org)
>>Objet : [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382= -5508-
>>bis
>>
>>The authors of draft-penno-behave-rfc4787-5382-5508-bis have asked = that
>>it
>>become a working group document. =A0Please send review nits, spelli= ng
>>corrections, and suchlike to the authors. =A0Please send feedback a= bout
>>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.
>>
>> =A0http://tools.ietf.org/html/draft-penn= o-behave-rfc4787-5382-5508-bis-04
>>
>>-d
>>
>>_______________________________________________
>>Behave mailing list
>>Behave@ietf.org
>>https://www.ietf.org/mailman/listinfo/behave
>_______________________________________________
>Behave mailing list
>Behave@ietf.org
>https://www.ietf.org/mailman/listinfo/behave

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

--047d7b86d55656ac0704dcb885d8-- From shtsuchi@cisco.com Tue May 14 19:52:40 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C249221F8AE2 for ; Tue, 14 May 2013 19:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfXwCVHa5Zd0 for ; Tue, 14 May 2013 19:52:36 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id C25A321F8ADF for ; Tue, 14 May 2013 19:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2737; q=dns/txt; s=iport; t=1368586355; x=1369795955; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DYJZMuyuK45ELvR9GUx39EZdTVzbdk3fZiv/7uKzzOo=; b=dNtcJ1oUzklYdjLab9g9/OmRPRoej+dn3KhA54bdedYsGt0T+l3Vdu0S kfMZyMmiFi7zl7qD4r+uK6Yo4EgWKCRCwdlvboMUtA9arxFEtvUdHbyqM RLP5Ko5FbfhH8euwW0nciRofA6U0buwRfaWttF/BeoBDQdgxo8jzt+AbS E=; X-IronPort-AV: E=Sophos;i="4.87,674,1363132800"; d="scan'208";a="31152839" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 15 May 2013 02:52:33 +0000 Received: from dhcp-10-141-56-48.cisco.com (dhcp-10-141-56-48.cisco.com [10.141.56.48]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4F2qSRE014856; Wed, 15 May 2013 02:52:28 GMT Message-ID: <5192F86B.3010101@cisco.com> Date: Wed, 15 May 2013 11:52:27 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: arifumi@nttv6.net References: <94C682931C08B048B7A8645303FDC9F36ECEBCEA27@PUEXCB1B.nanterre.francetelecom.fr> <45A697A8FFD7CF48BCF2BE7E106F06040908272B@xmb-rcd-x04.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, repenno@cisco.com, behave-chairs@tools.ietf.org, dwing@cisco.com, mohamed.boucadair@orange.com, draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org, shtsuchi@cisco.com Subject: Re: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 02:52:40 -0000 +1 I support this draft as wg draft. (2013/05/15 11:29), Arifumi Matsumoto wrote: > 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) > > > 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@orange.com " > > wrote: > > >I support this effort. > > > > > >>-----Message d'origine----- > >>De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org ] De la part > >>de > >>Dan Wing > >>Envoyé : samedi 4 mai 2013 00:43 > >>À : behave@ietf.org > >>Cc : draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org ; Behave > >>Chairs > >>(behave-chairs@tools.ietf.org ) > >>Objet : [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508- > >>bis > >> > >>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 > >> > >>_______________________________________________ > >>Behave mailing list > >>Behave@ietf.org > >>https://www.ietf.org/mailman/listinfo/behave > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From kaname@nttv6.jp Tue May 14 21:21:02 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E919621F8B33 for ; Tue, 14 May 2013 21:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7vFylVY7nub for ; Tue, 14 May 2013 21:20:54 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by ietfa.amsl.com (Postfix) with ESMTP id 519B421F8B18 for ; Tue, 14 May 2013 21:20:54 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [115.69.228.212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 1F308BDC21; Wed, 15 May 2013 13:20:53 +0900 (JST) Received: from [IPv6:2402:c800:ff06:0:14a9:c723:77c7:2791] (unknown [IPv6:2402:c800:ff06:0:14a9:c723:77c7:2791]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 233A1E0D9C; Wed, 15 May 2013 13:20:53 +0900 (JST) Message-ID: <51930D20.2050809@nttv6.jp> Date: Wed, 15 May 2013 13:20:48 +0900 From: kaname nishizuka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Simon Perreault References: <5190D29B.9070805@viagenie.ca> In-Reply-To: <5190D29B.9070805@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , "Rajiv Asati \(rajiva\)" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 04:21:03 -0000 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, Rajiv Asati (rajiva) a écrit : >>> An ISP is running out of addresses. It considers two options: static >>> CGN >>> vs dynamic CGN. Static allows, let's say, 32 users per public IPv4 >>> address. Given the 1:10 figure from the draft, it follows that dynamic >>> allows 320 users per public IPv4 address. >> >> 1:32 (dynamic assignment) on top of 1:10 (static assignment)? Did you >> intend to nest? >> >> Could you please clarify? > > 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 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 From christian.jacquenet@orange.com Wed May 15 00:27:14 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905ED21F8D7A for ; Wed, 15 May 2013 00:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdaWLoOtr-IE for ; Wed, 15 May 2013 00:27:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E2F8A21F8E99 for ; Wed, 15 May 2013 00:26:39 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 37A393B4A6C; Wed, 15 May 2013 09:26:33 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0E2C927C067; Wed, 15 May 2013 09:26:33 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 15 May 2013 09:26:32 +0200 From: To: "behave@ietf.org" Date: Wed, 15 May 2013 09:26:31 +0200 Thread-Topic: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis Thread-Index: Ac5RF0d/WmpPRJLUQW6PUfu26axY5wAJghKw Message-ID: <3336_1368602793_519338A9_3336_713_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A84E61AAE@PUEXCB1C.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36ECEBCEA27@PUEXCB1B.nanterre.francetelecom.fr> <45A697A8FFD7CF48BCF2BE7E106F06040908272B@xmb-rcd-x04.cisco.com> <5192F86B.3010101@cisco.com> In-Reply-To: <5192F86B.3010101@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.2.64815 Cc: BOUCADAIR Mohamed OLNC/OLN , "repenno@cisco.com" , "behave-chairs@tools.ietf.org" , "dwing@cisco.com" , "draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org" Subject: Re: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 07:27:14 -0000 RGVhciBhbGwsDQogDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LXBlbm5vLWJlaGF2 ZS1yZmM0Nzg3LTUzODItNTUwOC1iaXMgYXMgYSBiZWhhdmUgV0cgZG9jdW1lbnQuDQoNCkNoZWVy cywNCg0KQ2hyaXN0aWFuLg0KPiAgICAgID4+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ICAgICAgPj5EZSA6IGJlaGF2ZS1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86YmVoYXZlLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86YmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpiZWhh dmUtYm91bmNlc0BpZXRmLm9yZz5dIERlIGxhIHBhcnQNCj4gICAgICA+PmRlDQo+ICAgICAgPj5E YW4gV2luZw0KPiAgICAgID4+RW52b3nDqSA6IHNhbWVkaSA0IG1haSAyMDEzIDAwOjQzDQo+ICAg ICAgPj7DgCA6IGJlaGF2ZUBpZXRmLm9yZyA8bWFpbHRvOmJlaGF2ZUBpZXRmLm9yZz4NCj4gICAg ICA+PkNjIDogZHJhZnQtcGVubm8tYmVoYXZlLXJmYzQ3ODctNTM4Mi01NTA4LWJpc0B0b29scy5p ZXRmLm9yZyA8bWFpbHRvOmRyYWZ0LXBlbm5vLWJlaGF2ZS1yZmM0Nzg3LTUzODItNTUwOC1iaXNA dG9vbHMuaWV0Zi5vcmc+OyBCZWhhdmUNCj4gICAgICA+PkNoYWlycw0KPiAgICAgID4+KGJlaGF2 ZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgPG1haWx0bzpiZWhhdmUtY2hhaXJzQHRvb2xzLmlldGYu b3JnPikNCj4gICAgICA+Pk9iamV0IDogW0JFSEFWRV0gY2FsbCBmb3IgYWRvcHRpb24sIGRyYWZ0 LXBlbm5vLWJlaGF2ZS1yZmM0Nzg3LTUzODItNTUwOC0NCj4gICAgICA+PmJpcw0KPiAgICAgID4+ DQo+ICAgICAgPj5UaGUgYXV0aG9ycyBvZiBkcmFmdC1wZW5uby1iZWhhdmUtcmZjNDc4Ny01Mzgy LTU1MDgtYmlzIGhhdmUgYXNrZWQgdGhhdA0KPiAgICAgID4+aXQNCj4gICAgICA+PmJlY29tZSBh IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuICBQbGVhc2Ugc2VuZCByZXZpZXcgbml0cywgc3BlbGxp bmcNCj4gICAgICA+PmNvcnJlY3Rpb25zLCBhbmQgc3VjaGxpa2UgdG8gdGhlIGF1dGhvcnMuICBQ bGVhc2Ugc2VuZCBmZWVkYmFjayBhYm91dA0KPiAgICAgID4+dGhpcw0KPiAgICAgID4+YmVjb21p bmcgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IHRvIHRoZSBjaGFpcnMsIGF1dGhvcnMsIG9yIGxp c3QsIGFzIHlvdQ0KPiAgICAgID4+ZmVlbCBhcHByb3ByaWF0ZTsgY2xlYXIgaW5kaWNhdGlvbnMg b2YgJ3N1cHBvcnQnIG9yICdkbyBub3Qgc3VwcG9ydCcgYXJlDQo+ICAgICAgPj5hcHByZWNpYXRl ZC4NCj4gICAgICA+Pg0KPiAgICAgID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXBlbm5vLWJlaGF2ZS1yZmM0Nzg3LTUzODItNTUwOC1iaXMtMDQNCj4gICAgICA+Pg0KPiAgICAg ID4+LWQNCj4gICAgICA+Pg0KPiAgICAgID4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gICAgICA+PkJlaGF2ZSBtYWlsaW5nIGxpc3QNCj4gICAgICA+ PkJlaGF2ZUBpZXRmLm9yZyA8bWFpbHRvOkJlaGF2ZUBpZXRmLm9yZz4NCj4gICAgICA+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQo+ICAgICAgPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgPkJlaGF2ZSBt YWlsaW5nIGxpc3QNCj4gICAgICA+QmVoYXZlQGlldGYub3JnIDxtYWlsdG86QmVoYXZlQGlldGYu b3JnPg0KPiAgICAgID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2 ZQ0KPiANCj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ICAgICBCZWhhdmUgbWFpbGluZyBsaXN0DQo+ICAgICBCZWhhdmVAaWV0Zi5vcmcgPG1h aWx0bzpCZWhhdmVAaWV0Zi5vcmc+DQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2JlaGF2ZQ0KPiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQmVoYXZlIG1haWxpbmcgbGlzdA0KPiBCZWhh dmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhh dmUNCj4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkJlaGF2ZSBtYWlsaW5nIGxpc3QNCkJlaGF2ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK RnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From rajiva@cisco.com Wed May 15 03:48:29 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5EE21F8F61 for ; Wed, 15 May 2013 03:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6rzMoT6Tkwc for ; Wed, 15 May 2013 03:48:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E7D3A21F8F53 for ; Wed, 15 May 2013 03:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7308; q=dns/txt; s=iport; t=1368614905; x=1369824505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=flNRlGOMa0yvAJPONPoDqROgW45uzcc28XyHZRj0S08=; b=fX85AQLQhuSnpzfXJLUZsNvI4IESit7PGQoEZERI9hV32KgWPbTHa+dH yypC14O/8JqrbdOBIC9QgVaL4lDv5GSe+xJ2CKSleVTYtPOnJ5WLK60bS xv9OzBjXslvV5UxvdEBmJ98hqoD19ICusb/PDeythzCCSfOXaCICot1Rn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFACtnk1GtJXG+/2dsb2JhbABagwc3wFF5FnSCIAEBBAEBAWsJAhACAQgSKQQHJwsUAw4CBA4FiAwMvHkEjxoEB4J0YQOIZ45NkT2BV4E4 X-IronPort-AV: E=Sophos;i="4.87,677,1363132800"; d="scan'208,217";a="210711164" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 15 May 2013 10:48:24 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4FAmOhC027981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 10:48:24 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 15 May 2013 05:48:24 -0500 From: "Rajiv Asati (rajiva)" To: kaname nishizuka Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt Thread-Index: AQHOTK9jaOM7bqd790Smts+64Be8w5kDWX2AgAKoHACAABh6pw== Date: Wed, 15 May 2013 10:48:23 +0000 Message-ID: <1D535049-BEFF-4805-A0AD-8C0D55DA8199@cisco.com> References: <5190D29B.9070805@viagenie.ca>,<51930D20.2050809@nttv6.jp> In-Reply-To: <51930D20.2050809@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1D535049BEFF4805A0AD8C0D55DA8199ciscocom_" MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 10:48:30 -0000 --_000_1D535049BEFF4805A0AD8C0D55DA8199ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 speak= ing. Perhaps, we need to differentiate between mobile and wireline deployments. Irrespective of that, I wonder the usefulness of static vs dynamic ratio, a= nd how it could help in any CGN deployment. The question many deployments o= ften 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" > wrote: Yes. Based on the port consumption trend, we figured out that the sharing r= atio 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, Rajiv Asati (rajiva) a =E9crit : An ISP is running out of addresses. It considers two options: static CGN vs dynamic CGN. Static allows, let's say, 32 users per public IPv4 address. Given the 1:10 figure from the draft, it follows that dynamic allows 320 users per public IPv4 address. 1:32 (dynamic assignment) on top of 1:10 (static assignment)? Did you intend to nest? Could you please clarify? 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 foll= ows you would have 1:320 for dynamic. Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 --_000_1D535049BEFF4805A0AD8C0D55DA8199ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
the achiev= able address sharing ratio for dynamic is 10x that of static.=

I find this to be quite hig= her than what I would consider generically speaking. 

Perhaps, we need to differe= ntiate between mobile and wireline deployments. 

Irrespective of that, I won= der 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" <kaname@nttv6.jp> wrote:


Yes. Based on the port consumption trend, we figured out that the sha= ring ratio of dynamic assignment is 10 times of that of static assignment.<= /span>
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, Rajiv Asati (rajiva) a= =E9crit :
An ISP is running out of addresses. It cons= iders two options: static CGN
vs dynamic CGN. Static allows, let's say, 3= 2 users per public IPv4
address. Given the 1:10 figure from the dra= ft, it follows that dynamic
allows 320 users per public IPv4 address.

1:32 (dynamic assignment) on top of 1:10 (s= tatic assignment)? Did you
intend to nest?

Could you please clarify?

The draft says that the achievable address = sharing ratio for dynamic is 10x that of static. So if you have 1:32 for st= atic (a made up figure), it follows you would have 1:320 for dynamic.

Simon
___________________________________________= ____
Behave mailing list
Behave@i= etf.org
https://www.ietf.org/mailman/listinfo/behave


--
----
Kaname Nishizuka
Innovative Architecture Center
NTT Communications Corporation
+81-50-3812-4704

--_000_1D535049BEFF4805A0AD8C0D55DA8199ciscocom_-- From andrew.hutton@siemens-enterprise.com Wed May 15 09:14:57 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCD421F8C69; Wed, 15 May 2013 09:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me5UEFsQd3TR; Wed, 15 May 2013 09:14:53 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A7D5A21F8EFC; Wed, 15 May 2013 09:14:52 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 86FF91EB8473; Wed, 15 May 2013 18:14:51 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Wed, 15 May 2013 18:14:51 +0200 From: "Hutton, Andrew" To: "Chenxin (Xin)" , "behave@ietf.org" , "rtcweb@ietf.org" , "dispatch-bounces@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUEBzwmg1PRmVTkGgLh5/jvIzeJkFdPzAgAD0rVA= Date: Wed, 15 May 2013 16:14:50 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 16:14:57 -0000 This is an interesting addition to the debate about how best to achieve con= nectivity 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 no= t see the benefit of additional transport options for TURN given that the e= xisting 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 f= or TURN? Regarding F37 then this does need some rewording as I think the WG previous= ly discussed as it needs to talk about the need for traffic to originate fr= om the HTTP Proxy rather than allowing http traffic. That is probably worth= a separate thread. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Chenxin (Xin) > Sent: 15 May 2013 02:40 > To: behave@ietf.org; rtcweb@ietf.org; dispatch-bounces@ietf.org > Subject: [rtcweb] FW: New Version Notification for draft-chenxin- > behave-turn-websocket-00.txt >=20 > This draft defines a websocket extension to TURN to make TURN data have > the ability to transport over the websocket connection. >=20 > This method could be a option to solve the Http-fallback requirement in > RTCWEB. >=20 > 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. >=20 > 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. >=20 > Comments and suggestions are welcome. >=20 > Best Regards, > Xin >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@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 >=20 >=20 > A new version of I-D, draft-chenxin-behave-turn-websocket-00.txt > has been successfully submitted by Xin Chen and posted to the > IETF repository. >=20 > Filename: draft-chenxin-behave-turn-websocket > Revision: 00 > Title: Traversal Using Relays around NAT (TURN) Extensions > for Websocket Allocations > Creation date: 2013-05-13 > Group: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-chenxin- > behave-turn-websocket-00.txt > Status: http://datatracker.ietf.org/doc/draft-chenxin-behave- > turn-websocket > Htmlized: http://tools.ietf.org/html/draft-chenxin-behave-turn- > websocket-00 >=20 >=20 > Abstract: > This document defines an extension to TURN that allows it to run > over > a Websocket [RFC6455] channel. This will allow a client in a > restrictive network to exchange and relay media or data over the > websocket. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Wed May 15 10:20:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAC921F8F4A; Wed, 15 May 2013 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3uaWNqn3+36; Wed, 15 May 2013 10:19:57 -0700 (PDT) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57121F8F2E; Wed, 15 May 2013 10:19:55 -0700 (PDT) Received: from BLU169-W49 ([65.55.111.71]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 May 2013 10:19:54 -0700 X-TMN: [YCpH8KRc73zNzffRzLHPKaHWbCqsrwAWsTybyylk99g=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_48f1096f-9729-41d6-be29-9042e4ea1ac7_" From: Bernard Aboba To: "Hutton, Andrew" , "Chenxin (Xin)" , "behave@ietf.org" , "rtcweb@ietf.org" Date: Wed, 15 May 2013 10:19:53 -0700 Importance: Normal In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> MIME-Version: 1.0 X-OriginalArrivalTime: 15 May 2013 17:19:54.0554 (UTC) FILETIME=[6A93E1A0:01CE5190] Subject: Re: [BEHAVE] [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 17:20:09 -0000 --_48f1096f-9729-41d6-be29-9042e4ea1ac7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew Hutton said:=20 > When we wrote the draft http://tools.ietf.org/html/draft-hutton-rtcweb-na= t-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. >=20 > So what would be the benefits that justify this addition transport option= for TURN? [BA] In my experience=2C institutions with very restrictive security polic= ies (e.g. those that don't allow UDP in or out) also tend to deploy other m= easures such as deep packet inspection. So just because some traffic is a= llowed 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 se= e HTTP being used. On the other hand=2C unless the DPI box is upgraded=2C = it will also complain about websockets. So I think draft-chenxin only help= s in a situation where TURN over Websockets would be allowed when TURN/TCP = would not be. That scenario is rare=2C at least at the moment.=20 The argument for TURN over Websocket/TLS is even more difficult to make. Wh= ile DPI boxes may examine traffic destined to port 443 carefully to make su= re that TLS is really being used=2C assuming that the DPI box does not see= anything it considers fishy=2C the TLS exchange will complete and the DPI = box will lose visibility. After TLS is running=2C the DPI box does not hav= e much information available to distinguish TURN/TLS from HTTP over TLS=2C = with or without websockets -- and those things it does have (such as packet= size) are as likely to result in an objection to websocket transport as TU= RN/TLS. So I'm not sure that draft-chenxin will help in that situation eit= her. = --_48f1096f-9729-41d6-be29-9042e4ea1ac7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Andrew Hutton said: =3B
<= br>
>=3B When we wrote the draft http://tools.ietf.org/html/draft-hut= ton-rtcweb-nat-firewall-considerations-00 we did not include this option be= cause we did not see the benefit of additional transport options for TURN g= iven that the existing options (E.g. TURN/TCP and TURN/TLS) seem to be meet= our needs.
>=3B
>=3B So what would be the benefits that justify= this addition transport option for TURN?

[BA] In my experience=2C &= nbsp=3Binstitutions with very restrictive security policies (e.g. those tha= t don't allow UDP in or out) also tend to deploy other measures such as dee= p packet inspection.  =3B 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.  =3BOn the other hand=2C unless the DPI box is upgraded=2C it wi= ll also complain about websockets.  =3BSo I think draft-chenxin only he= lps in a situation where TURN over Websockets would be allowed when TURN/TC= P would not be.  =3BThat scenario is rare=2C at least at the moment.&nb= sp=3B

The argument for TURN over Websocket/TLS is = even more difficult to make. While DPI boxes may examine traffic destined t= o port 443 carefully to make sure that TLS is really being used=2C  =3B= assuming that the DPI box does not see anything it considers fishy=2C the T= LS exchange will complete and the DPI box will lose visibility.  =3BAfter TLS is running=2C the DPI box does no= t have much information available to distinguish TURN/TLS from HTTP over TL= S=2C with or without websockets -- and those things it does have (such as p= acket size) are as likely to result in an objection to websocket transport = as TURN/TLS.  =3BSo I'm not s= ure that draft-chenxin will help in that situation either. =3B
= --_48f1096f-9729-41d6-be29-9042e4ea1ac7_-- From hangzhou.chenxin@huawei.com Tue May 14 18:40:23 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A5121F8AE2; Tue, 14 May 2013 18:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iJSI1SoRwCo; Tue, 14 May 2013 18:40:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CBCBE21F84D4; Tue, 14 May 2013 18:40:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASU55151; Wed, 15 May 2013 01:40:17 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 02:39:51 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 02:40:14 +0100 Received: from SZXEML538-MBS.china.huawei.com ([169.254.3.34]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Wed, 15 May 2013 09:40:06 +0800 From: "Chenxin (Xin)" To: "behave@ietf.org" , "rtcweb@ietf.org" , "dispatch-bounces@ietf.org" Thread-Topic: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUEBzwmg1PRmVTkGgLh5/jvIzeJkFdPzA Date: Wed, 15 May 2013 01:40:05 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 15 May 2013 10:52:29 -0700 Subject: [BEHAVE] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 01:40:23 -0000 VGhpcyBkcmFmdCBkZWZpbmVzIGEgd2Vic29ja2V0IGV4dGVuc2lvbiB0byBUVVJOIHRvIG1ha2Ug VFVSTiBkYXRhIGhhdmUgdGhlIGFiaWxpdHkgdG8gdHJhbnNwb3J0IG92ZXIgdGhlIHdlYnNvY2tl dCBjb25uZWN0aW9uLg0KDQpUaGlzIG1ldGhvZCBjb3VsZCBiZSBhIG9wdGlvbiB0byBzb2x2ZSB0 aGUgSHR0cC1mYWxsYmFjayByZXF1aXJlbWVudCBpbiBSVENXRUIuIA0KDQogICAgRjM3ICAgICAg ICAgICAgVGhlIGJyb3dzZXIgTVVTVCBiZSBhYmxlIHRvIHNlbmQgc3RyZWFtcyBhbmQNCiAgICAg ICAgICAgICAgICAgICBkYXRhIHRvIGEgcGVlciBpbiB0aGUgcHJlc2VuY2Ugb2YgRldzIHRoYXQg b25seQ0KICAgICAgICAgICAgICAgICAgIGFsbG93cyBodHRwKHMpIHRyYWZmaWMuDQoNCkJlc2lk ZXMsIFR1cm4gc2VydmVyIHdpdGggd2Vic29rY2V0IGV4dGVuc2lvbiBjb3VsZCBiZSBhIGdlbmVy YWwgcmVsYXkgc2VydmVyIGZvciBzb21lIG92ZXIgd2Vic29ja2V0IHByb3RvY29sLCBzdWNoIGFz IEJGQ1Agb3ZlciB3ZWJzb2NrZXQgb3IgTVNSUCBvdmVyIHdlYnNvY2tldC4gVGhpcyBjb3VsZCBz YXRpc2Z5IHNvbWUgUGVlciB0byBQZWVyIHNjZW5lIHdoZW4gdXNpbmcgdGhlc2UgcHJvdG9jb2wg aW4gdGhlIHdlYiBlbnZpcm9ubWVudCAsIHdpdGhvdXQgYSBzcGVjaWZpYyBjZW50ZXIgc2VydmVy Lg0KDQpDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgUmVnYXJk cywNCiAgICAgWGluIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogVHVlc2RheSwgTWF5IDE0LCAyMDEzIDk6MTUgQU0NClRvOiBDaGVueGluIChYaW4pOyBD aGVueGluIChYaW4pDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWNoZW54aW4tYmVoYXZlLXR1cm4td2Vic29ja2V0LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldC0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGluIENoZW4gYW5kIHBvc3RlZCB0byB0aGUN CklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJu LXdlYnNvY2tldA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgVHJhdmVyc2FsIFVzaW5nIFJlbGF5 cyBhcm91bmQgTkFUIChUVVJOKSBFeHRlbnNpb25zIGZvciBXZWJzb2NrZXQgQWxsb2NhdGlvbnMN CkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA1LTEzDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCk51bWJlciBvZiBwYWdlczogNw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldC0w MC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldA0KSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tl dC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGV4dGVuc2lv biB0byBUVVJOIHRoYXQgYWxsb3dzIGl0IHRvIHJ1biBvdmVyDQogICBhIFdlYnNvY2tldCBbUkZD NjQ1NV0gY2hhbm5lbC4gIFRoaXMgd2lsbCBhbGxvdyBhIGNsaWVudCBpbiBhDQogICByZXN0cmlj dGl2ZSBuZXR3b3JrIHRvIGV4Y2hhbmdlIGFuZCByZWxheSBtZWRpYSBvciBkYXRhIG92ZXIgdGhl DQogICB3ZWJzb2NrZXQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From tireddy@cisco.com Wed May 15 21:56:01 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACD321F8F4D; Wed, 15 May 2013 21:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5fSawCtmv0q; Wed, 15 May 2013 21:55:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 75D7021F8EED; Wed, 15 May 2013 21:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9001; q=dns/txt; s=iport; t=1368680156; x=1369889756; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=LljL0BCgc/S9OlnTFzucJdIefHsjX6E/UAyJHLdOQgQ=; b=PIexw9Qf5AmI9ND4K6nE9XGte8JPHzzaIVxWsMeT8Je5e+P+Wj2pCFIt rI65Jm1fvzKXgxLJ0qP6o2AwnE1iALNpnfx8UNFMaaPovHc2ZGSDi8DLt DHWrGSHxb+IbVqgRCB07/g/hXGEginpVv6nPPaBkIp4tDENzgspCnp9z2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFlmlFGtJV2b/2dsb2JhbABbgkNEN8B9gQEWdIIfAQEBAwEtSgcLAgEIEQQBAQsdBzIUCAEIAgQBEgiHfgYMvHiNeXQ3AYJ0YQOYXJAWgViBOIFqPA X-IronPort-AV: E=Sophos;i="4.87,681,1363132800"; d="scan'208,217";a="211108161" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 16 May 2013 04:55:55 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4G4tt2i000540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 04:55:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 15 May 2013 23:55:55 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Bernard Aboba , "Hutton, Andrew" , "Chenxin (Xin)" , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUYdcX1lIz7P+wE24JCIYCsgyvJkG0ZaAgABst3A= Date: Thu, 16 May 2013 04:55:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B6DB83@xmb-rcd-x10.cisco.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.46.83] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B6DB83xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [BEHAVE] [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 04:56:01 -0000 --_000_913383AAA69FF945B8F946018B75898A14B6DB83xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline [TR] From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: Wednesday, May 15, 2013 10:50 PM To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave= -turn-websocket-00.txt Andrew Hutton said: > When we wrote the draft http://tools.ietf.org/html/draft-hutton-rtcweb-na= t-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? [BA] In my experience, institutions with very restrictive security policie= s (e.g. those that don't allow UDP in or out) also tend to deploy other mea= sures such as deep packet inspection. So just because some traffic is all= owed in or out on port 80 does not mean that TURN/TCP will be allowed on th= at 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 wil= l 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. Wh= ile DPI boxes may examine traffic destined to port 443 carefully to make su= re that TLS is really being used, assuming that the DPI box does not see a= nything it considers fishy, the TLS exchange will complete and the DPI box = will lose visibility. After TLS is running, the DPI box does not have much= information available to distinguish TURN/TLS from HTTP over TLS, with or = without websockets -- and those things it does have (such as packet size) a= re as likely to result in an objection to websocket transport as TURN/TLS. = So I'm not sure that draft-chenxin will help in that situation either. [TR] Firewalls with restrictive policies in addition to DPI use various oth= er mechanisms like reputation, heuristics, HTTPS proxy etc to classify the = traffic and block it. --Tiru. --_000_913383AAA69FF945B8F946018B75898A14B6DB83xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see inline [TR]

 

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Wednesday, May 15, 2013 10:50 PM
To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org<= br> Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin= -behave-turn-websocket-00.txt

 

Andrew Hutton said: =

> 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/T= LS) seem to be meet our needs.
>
> So what would be the benefits that justify this addition transport opt= ion for TURN?

[BA] In my experience,  institutions with very restrictive security po= licies (e.g. those that don't allow UDP in or out) also tend to deploy othe= r measures such as deep packet inspection.   So just because some traf= fic 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 th= e traffic and complain if it doesn't see HTTP being used.  On the othe= r hand, unless the DPI box is upgraded, it will also complain about websock= ets.  So I think draft-chenxin only helps in a situation where TURN over Websockets would be allowed when TURN/TCP w= ould not be.  That scenario is rare, at least at the moment. 

 

The argument for TURN over Websocket/TLS is even more di= fficult to make. While DPI boxes may examine traffic destined to port 443 c= arefully to make sure that TLS is really being used,  assuming that the DPI box does not see anything it considers fishy, the TLS exchang= e will complete and the DPI box will lose visibility.  After TLS is ru= nning, the DPI box does not have much information available to distinguish = TURN/TLS from HTTP over TLS, with or without websockets -- and those things it does have (such as packet size) = are as likely to result in an objection to websocket transport as TURN/TLS.=  So I'm not sure that draft-chenxin will help in that situation eithe= r. 

 

[TR] Firewalls with restrictive policies in addition to DPI = use various other mechanisms like reputation, heuristics, HTTPS proxy etc t= o classify the traffic and block it.

 

--Tiru.

--_000_913383AAA69FF945B8F946018B75898A14B6DB83xmbrcdx10ciscoc_-- From andrew.hutton@siemens-enterprise.com Thu May 16 01:28:10 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC6121F854D; Thu, 16 May 2013 01:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnNNxCzXl5wa; Thu, 16 May 2013 01:28:06 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 68F7921F8E84; Thu, 16 May 2013 01:28:06 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 67B5023F0481; Thu, 16 May 2013 10:28:04 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Thu, 16 May 2013 10:28:04 +0200 From: "Hutton, Andrew" To: Bernard Aboba , "Chenxin (Xin)" , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUEBzwmg1PRmVTkGgLh5/jvIzeJkFdPzAgAD0rVD///UigIABF7SQ Date: Thu, 16 May 2013 08:28:03 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 08:28:11 -0000 I agree with Bernard's comments regarding the impact of DPI but of course s= uch DPI devices do what they do and we can't and even don't want to stop th= em from doing it. However for the case when policy is such that the firewal= l will only allow traffic to traverse that comes from the HTTP Proxy or a n= etwork specific TURN server and there is no deliberate policy to block WebR= TC media we need a solution and this is what draft-hutton-rtcweb-nat-firewa= ll-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 TUR= N server. Regards Andy > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: 15 May 2013 18:20 > To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org > Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- > behave-turn-websocket-00.txt >=20 > Andrew Hutton said: > > 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? >=20 > [BA] In my experience, =A0institutions 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. =A0 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. =A0On the other > hand, unless the DPI box is upgraded, it will also complain about > websockets. =A0So I think draft-chenxin only helps in a situation where > TURN over Websockets would be allowed when TURN/TCP would not be. =A0That > 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, =A0assuming that > the DPI box does not see anything it considers fishy, the TLS exchange > will complete and the DPI box will lose visibility. =A0After TLS is > running, the DPI box does not have much information available to > distinguish TURN/TLS from HTTP over TLS, with or without websockets -- > and those things it does have (such as packet size) are as likely to > result in an objection to websocket transport as TURN/TLS. =A0So I'm not > sure that draft-chenxin will help in that situation either. From hangzhou.chenxin@huawei.com Thu May 16 04:42:50 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0BB21F8FED; Thu, 16 May 2013 04:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfU6KDte31Br; Thu, 16 May 2013 04:42:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 42F9021F905F; Thu, 16 May 2013 04:42:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASV95737; Thu, 16 May 2013 11:42:43 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 12:41:55 +0100 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 12:42:28 +0100 Received: from SZXEML538-MBS.china.huawei.com ([169.254.3.34]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.007; Thu, 16 May 2013 19:42:22 +0800 From: "Chenxin (Xin)" To: Bernard Aboba , "Hutton, Andrew" , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUYdZvexTilrlAE6hVSVk7wP2WJkF96iAgAGyz4A= Date: Thu, 16 May 2013 11:42:21 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03974C6DDA82@szxeml538-mbs.china.huawei.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.129] Content-Type: multipart/alternative; boundary="_000_9E34D50A21D1D1489134B4D770CE03974C6DDA82szxeml538mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [BEHAVE] [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 11:42:50 -0000 --_000_9E34D50A21D1D1489134B4D770CE03974C6DDA82szxeml538mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reply inline Best Regards, Xin From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Thursday, May 16, 2013 1:20 AM To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin-behave= -turn-websocket-00.txt Andrew Hutton said: > When we wrote the draft http://tools.ietf.org/html/draft-hutton-rtcweb-na= t-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? [BA] In my experience, institutions with very restrictive security policie= s (e.g. those that don't allow UDP in or out) also tend to deploy other mea= sures such as deep packet inspection. So just because some traffic is all= owed in or out on port 80 does not mean that TURN/TCP will be allowed on th= at 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 wil= l 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 will be more and more web = servers which support websocket. That means websocket will be treated the s= ame as HTTP in the policy of FW or proxy server. Comparing with transportin= g the TCP packet directly on the Http port, Upgrade the HTTP to websocket a= nd transport the data over it is more friendly to FW and proxy server. The = possibility of the block of the websocket data by the DPI is less than the= TCP data. So I think the benefit of turn over websocket is that it will i= ncrease the success rate when the rtcweb is used in the restrictive network= , such as in airport or some hotel. The argument for TURN over Websocket/TLS is even more difficult to make. Wh= ile DPI boxes may examine traffic destined to port 443 carefully to make su= re that TLS is really being used, assuming that the DPI box does not see a= nything it considers fishy, the TLS exchange will complete and the DPI box = will lose visibility. After TLS is running, the DPI box does not have much= information available to distinguish TURN/TLS from HTTP over TLS, with or = without websockets -- and those things it does have (such as packet size) a= re as likely to result in an objection to websocket transport as TURN/TLS. = So I'm not sure that draft-chenxin will help in that situation either. [Xin] If DPI can't inspect the content of TLS data, there is no difference= . But considering DPI-SSL, which could inspect the TLS session, the turn ov= er websocket will be has the benefit which has been said before. --_000_9E34D50A21D1D1489134B4D770CE03974C6DDA82szxeml538mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reply inli= ne

 = ;

Best Regards,

     Xi= n

 = ;

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Thursday, May 16, 2013 1:20 AM
To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org<= br> Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin= -behave-turn-websocket-00.txt

 

Andrew Hut= ton said: 

> When we wrote the draft http://tools= .ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-00 we did no= t 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 opt= ion for TURN?

[BA] In my experience,  institutions with very restrictive security po= licies (e.g. those that don't allow UDP in or out) also tend to deploy othe= r measures such as deep packet inspection.   So just because some traf= fic 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 th= e traffic and complain if it doesn't see HTTP being used.  On the othe= r hand, unless the DPI box is upgraded, it will also complain about websock= ets.  So I think draft-chenxin only helps in a situation where TURN over Websockets would be allowed when TURN/TCP w= ould not be.  That scenario is rare, at least at the moment. 

 

[Xin] = ;  With the development of websocket, there will be more and more web = servers which support websocket. That means websocket will be treated the same as HTTP in the policy of FW or proxy server. Comparing with trans= porting the TCP packet directly on the Http port, Upgrade the HTTP to webso= cket and transport the data over it is more friendly to FW and proxy server= . The possibility of the block of  the websocket data by the DPI is less than the TCP data.  So I = think the benefit of turn over websocket is that it will increase the succe= ss rate when the rtcweb is used in the restrictive network, such as in airp= ort or some hotel.

 = ;

The argument for TURN over Websocket/TLS = is even more difficult to make. While DPI boxes may examine traffic destine= d to port 443 carefully to make sure that TLS is really being used,  assuming that the DPI box does not see anything it considers f= ishy, the TLS exchange will complete and the DPI box will lose visibility. =  After TLS is running, the DPI box does not have much information avai= lable to distinguish TURN/TLS from HTTP over TLS, with or without websockets -- and those things it does have (such as = packet size) are as likely to result in an objection to websocket transport= as TURN/TLS.  So I'm not sure that draft-chenxin will help in that si= tuation either. 

[Xin] = ; If DPI can’t inspect the content of TLS data, there is no differenc= e. But considering DPI-SSL, which could inspect the TLS session, the turn over websocket will be has the benefit which has been said before.

 = ;

--_000_9E34D50A21D1D1489134B4D770CE03974C6DDA82szxeml538mbschi_-- From hangzhou.chenxin@huawei.com Thu May 16 04:52:26 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF13B21F907E; Thu, 16 May 2013 04:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlyTRzUIQw7f; Thu, 16 May 2013 04:52:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED44D21F8E96; Thu, 16 May 2013 04:52:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASV96520; Thu, 16 May 2013 11:52:21 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 12:51:46 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 19:52:20 +0800 Received: from SZXEML538-MBS.china.huawei.com ([169.254.3.34]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Thu, 16 May 2013 19:52:18 +0800 From: "Chenxin (Xin)" To: "Hutton, Andrew" , Bernard Aboba , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUYdZvexTilrlAE6hVSVk7wP2WJkF96iAgAD9vYCAAL7ywA== Date: Thu, 16 May 2013 11:52:17 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03974C6DDA95@szxeml538-mbs.china.huawei.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.129] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [BEHAVE] [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 11:52:26 -0000 >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Thursday, May 16, 2013 4:28 PM >To: Bernard Aboba; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org >Subject: RE: [rtcweb] FW: New Version Notification for >draft-chenxin-behave-turn-websocket-00.txt > >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 spec= ific >TURN server and there is no deliberate policy to block WebRTC media we nee= d a >solution and this is what draft-hutton-rtcweb-nat-firewall-considerations-= 00 >addresses. > 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 p= roxy too. I agree that draft-hutton-rtcweb-nat-firewall-considerations-00 s= hould 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 opt= ion to solve some corner use case and requirement. Best Regards, Xin=20 >So far I don't see the benefit that TURN over websockets would have in thi= s >scenario and it needs additional implementation in the browser and the TUR= N >server. > >Regards >Andy > > >> -----Original Message----- >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >> Sent: 15 May 2013 18:20 >> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org >> Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- >> behave-turn-websocket-00.txt >> >> Andrew Hutton said: >> > 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? >> >> [BA] In my experience, =A0institutions 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. =A0 So just becaus= e >> 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. =A0On the other >> hand, unless the DPI box is upgraded, it will also complain about >> websockets. =A0So I think draft-chenxin only helps in a situation where >> TURN over Websockets would be allowed when TURN/TCP would not >be. =A0That >> 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, =A0assuming that >> the DPI box does not see anything it considers fishy, the TLS exchange >> will complete and the DPI box will lose visibility. =A0After TLS is >> running, the DPI box does not have much information available to >> distinguish TURN/TLS from HTTP over TLS, with or without websockets -- >> and those things it does have (such as packet size) are as likely to >> result in an objection to websocket transport as TURN/TLS. =A0So I'm not >> sure that draft-chenxin will help in that situation either. > > > From andrew.hutton@siemens-enterprise.com Mon May 20 04:06:48 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA6421F912C; Mon, 20 May 2013 04:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Io7+nY8zucjz; Mon, 20 May 2013 04:06:38 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id F313221F8A14; Mon, 20 May 2013 04:06:37 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id BC18C1EB84EE; Mon, 20 May 2013 13:06:36 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Mon, 20 May 2013 13:06:36 +0200 From: "Hutton, Andrew" To: Lorenzo Miniero , =?utf-8?B?R3VzdGF2byBHYXJjw61h?= Thread-Topic: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVTqUu83hGBO03EOmioPLICQbqpkN5f0A Date: Mon, 20 May 2013 11:06:35 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> In-Reply-To: <20130520111522.1b7e2eb1@meetecho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 11:06:48 -0000 UmVnYXJkaW5nIHRoZSBIVFRQIGZhbGxiYWNrIGFuZCB3aGV0aGVyIHRoaXMgY291bGQgYmUgYWRh cHRlZCB0byBiZSBhIFRVUk4gb3ZlciBIVFRQIGJhc2VkIHNvbHV0aW9uIHRoZW4gSSB0aGluayB0 aGUgc2FtZSBjb21tZW50cyB0aGF0IHdlcmUgbWFkZSBvbiB0aGUgVFVSTiBvdmVyIHdlYnNvY2tl dHMgYXBwbHkuIFdoYXQgYXJlIHRoZSBiZW5lZml0cyBvZiBjcmVhdGluZyBhIG5ldyB0cmFuc3Bv cnQgZm9yIFRVUk4gb3ZlciB3aGF0IHdlIGNhbiBkbyB1c2luZyBIVFRQIENvbm5lY3QgYXMgZGVz Y3JpYmVkIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi1ydGN3ZWIt bmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25zLTAwLg0KDQpIYXZpbmcgc2FpZCB0aGF0IEkgYW0g cmVhbGx5IGhhcHB5IHdlIGFyZSBoYXZpbmcgdGhpcyBkZWJhdGUgYXMgd2UgcmVhbGx5IG5lZWQg dG8gZmluZCBhIHNvbHV0aW9uIGhlcmUgdGhhdCB0aGUgYnJvd3NlciB2ZW5kb3JzIHdpbGwgaW1w bGVtZW50IHNvIEkgd291bGQgcmVhbGx5IGxpa2UgdG8ga25vdyB3aGljaCBvcHRpb25zIHRoZXkg cHJlZmVyLg0KDQpJIHJlYWxseSBob3BlIHdlIGNhbiBnZXQgZHJhZnQtaHV0dG9uLXJ0Y3dlYi1u YXQtZmlyZXdhbGwtY29uc2lkZXJhdGlvbnMgYWRvcHRlZCBhbmQgdXNlIGl0IHRvIGRvY3VtZW50 IHdoYXRldmVyIHRoZSB3b3JraW5nIGdyb3VwIGFncmVlcyBvbiBiZWluZyB0aGUgcmlnaHQgc29s dXRpb24uDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IExvcmVuem8gTWluaWVybyBbbWFpbHRvOmxvcmVuem9AbWVldGVjaG8uY29tXQ0K PiBTZW50OiAyMCBNYXkgMjAxMyAxMDoxNQ0KPiBUbzogR3VzdGF2byBHYXJjw61hDQo+IENjOiBI dXR0b24sIEFuZHJldzsgcnRjd2ViQGlldGYub3JnOyBiZWhhdmVAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtydGN3ZWJdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2hlbnhp bi0NCj4gYmVoYXZlLXR1cm4td2Vic29ja2V0LTAwLnR4dA0KPiANCj4gSWwgZ2lvcm5vIFN1biwg MTkgTWF5IDIwMTMgMjM6MjA6NDEgLTA3MDANCj4gR3VzdGF2byBHYXJjw61hIDxnZ2JAdG9rYm94 LmNvbT4gaGEgc2NyaXR0bzoNCj4gDQo+ID4gSSBhZ3JlZSB0aGF0IFRVUk4gb3ZlciB3ZWJzb2Nr ZXRzIGRvZXNuJ3Qgc29sdmUgbXVjaCBtb3JlIHNjZW5hcmlvcw0KPiA+IHRoYW4gVFVSTi9UTFMu ICAgSWYgdHJ5aW5nIHRvIGZpeCBIVFRQIFByb3h5IHRyYXZlcnNhbCB3aHkgbm90IGRvaW5nDQo+ ID4gaXQgb3ZlciBIVFRQIHRoYXQgYXNpZGUgb2YgcGhpbG9zb3BoaWNhbCBkaXNjdXNzaW9ucyB3 b3VsZCBiZSB0aGUNCj4gPiBzb2x1dGlvbiB3aXRoIGJldHRlciBzdWNjZXNzIHJhdGU/ICBPdGhl cndpc2Ugd2Ugd2lsbCBoYXZlIHRvDQo+ID4gY29udGludWUgYW5zd2VyaW5nIGZvciBhbm90aGVy IDEwIHllYXJzICJ3aHkgaXMgdGhpcyBhcHAgbm90IHdvcmtpbmcNCj4gPiBpZiBza3lwZSBkb2Vz Ii4NCj4gPg0KPiA+IFNvbWV0aGluZyBsaWtlIHRoaXMgZHJhZnQgc2VudCBzb21lIG1vbnRocyBh Z28gYnV0IHBlcmhhcHMgZm9yIFRVUk4NCj4gPiBpbnN0ZWFkIG9mIGRpcmVjdCBjb25uZWN0aW9u czoNCj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtbWluaWVyby1ydGN3ZWItaHR0 cC1mYWxsYmFjay0wMC50eHQNCj4gPg0KPiANCj4gDQo+IFdoZW4gSSBzdWJtaXR0ZWQgdGhhdCBk cmFmdCB0aGlzIHN1bW1lciwgSSBoYWQgdGhhdCBleGFjdCBwdXJwb3NlIGluDQo+IG1pbmQsIHRo YXQgaXMgdGFraW5nIGNhcmUgb2YgY29ybmVyIGVkZ2UgY2FzZXMgbGlrZSByZXN0cmljdGl2ZSBw cm94aWVzDQo+IGFuZCB0aGUgbGlrZS4gT2YgY291cnNlIGl0IHdhcyBub3QgbWVhbnQgdG8gYmUg YSBzb2x1dGlvbiwganVzdCBhIHdheQ0KPiB0byBmb3N0ZXIgZGlzY3Vzc2lvbiBpbiB0aGF0IGRp cmVjdGlvbi4gSW4gdGhhdCBkaXNjdXNzaW9uIEkgYWxzbw0KPiBtZW50aW9uZWQgc29tZSB3b3Jr IHdlIGRpZCBhYm91dCB0aGlzIGluIHRoZSBwYXN0LCB3aGljaCBpbiBwYXJ0DQo+IGFwcGFyZW50 bHkgZW5kZWQgdXAgaW4gZHJhZnQtaHV0dG9uLXJ0Y3dlYi1uYXQtZmlyZXdhbGwtY29uc2lkZXJh dGlvbnM6DQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2Vi L2N1cnJlbnQvbXNnMDUwNDEuaHRtbA0KPiANCj4gQXQgdGhlIHRpbWUgbW9zdCBwZW9wbGUgaW4g dGhlIE1MIHRob3VnaHQgaXQgd2FzIGVpdGhlciB0b28gdXNlbGVzcywNCj4gdG9vIGNvbXBsZXgg b3IgZXZlbiBoYXJtZnVsLCBjb25zaWRlcmluZyBpdCBjb3VsZCBiZSBjb25zaWRlcmVkIGFzIGEN Cj4gInNuZWFreSIgd2F5IHRvIGNpcmN1bXZlbnQgcnVsZXMgYWRkZWQgYnkgYSBuZXR3b3JrIGFk bWluaXN0cmF0b3IsIGFuZA0KPiBzbyB1bmFjY2VwdGFibGUuIEFueXdheSwgYXMgSSBzYWlkIGJh Y2sgdGhlbiwgYSBzb2x1dGlvbiBsaWtlIHRoaXMNCj4gZG9lc24ndCBoYXZlIHRvIGJlIHNuZWFr eSwgYW5kIGl0IGNvdWxkIHZlcnkgd2VsbCBiZSBjb25jZWl2ZWQgaW4gb3JkZXINCj4gdG8gYmUg YWRtaW4tZnJpZW5kbHkgcmF0aGVyIHRoYW4gaGF2ZSBhIHBhcnJvdCBhbmQgYSB3b29kZW4gbGVn Lg0KPiANCj4gV2hldGhlciB3ZSBhY3R1YWxseSBuZWVkIHNvbWV0aGluZyBsaWtlIHRoaXMgb3Ig VFVSTi1vdmVyLTQ0MyBpcyBlbm91Z2gNCj4gSSBkb24ndCBrbm93OiBJIHN0aWxsIHRoaW5rIGl0 IG1heSBiZSB1c2VmdWwgdG8gdGFja2xlIHNjZW5hcmlvcyB3aGVyZQ0KPiBldmVyeXRoaW5nIGVs c2UgZmFpbHMgKHRoZSAic2t5cGUgd29ya3MgaGVyZSIgZWZmZWN0KSwgc28gSSdkIGJlIGdsYWQN Cj4gdG8gYmUgb2YgaGVscCBpbiB0aGF0IGRpcmVjdGlvbiBpZiBuZWVkZWQuDQo+IA0KPiBMb3Jl bnpvDQo+IA0KPiANCj4gDQo+ID4gT24gMTYvMDUvMjAxMywgYXQgMDE6MjgsIEh1dHRvbiwgQW5k cmV3IHdyb3RlOg0KPiA+DQo+ID4gPiBJIGFncmVlIHdpdGggQmVybmFyZCdzIGNvbW1lbnRzIHJl Z2FyZGluZyB0aGUgaW1wYWN0IG9mIERQSSBidXQgb2YNCj4gPiA+IGNvdXJzZSBzdWNoIERQSSBk ZXZpY2VzIGRvIHdoYXQgdGhleSBkbyBhbmQgd2UgY2FuJ3QgYW5kIGV2ZW4gZG9uJ3QNCj4gPiA+ IHdhbnQgdG8gc3RvcCB0aGVtIGZyb20gZG9pbmcgaXQuIEhvd2V2ZXIgZm9yIHRoZSBjYXNlIHdo ZW4gcG9saWN5DQo+ID4gPiBpcyBzdWNoIHRoYXQgdGhlIGZpcmV3YWxsIHdpbGwgb25seSBhbGxv dyB0cmFmZmljIHRvIHRyYXZlcnNlIHRoYXQNCj4gPiA+IGNvbWVzIGZyb20gdGhlIEhUVFAgUHJv eHkgb3IgYSBuZXR3b3JrIHNwZWNpZmljIFRVUk4gc2VydmVyIGFuZA0KPiA+ID4gdGhlcmUgaXMg bm8gZGVsaWJlcmF0ZSBwb2xpY3kgdG8gYmxvY2sgV2ViUlRDIG1lZGlhIHdlIG5lZWQgYQ0KPiA+ ID4gc29sdXRpb24gYW5kIHRoaXMgaXMgd2hhdA0KPiA+ID4gZHJhZnQtaHV0dG9uLXJ0Y3dlYi1u YXQtZmlyZXdhbGwtY29uc2lkZXJhdGlvbnMtMDAgYWRkcmVzc2VzLg0KPiA+ID4NCj4gPiA+IFNv IGZhciBJIGRvbid0IHNlZSB0aGUgYmVuZWZpdCB0aGF0IFRVUk4gb3ZlciB3ZWJzb2NrZXRzIHdv dWxkIGhhdmUNCj4gPiA+IGluIHRoaXMgc2NlbmFyaW8gYW5kIGl0IG5lZWRzIGFkZGl0aW9uYWwg aW1wbGVtZW50YXRpb24gaW4gdGhlDQo+ID4gPiBicm93c2VyIGFuZCB0aGUgVFVSTiBzZXJ2ZXIu DQo+ID4gPg0KPiA+ID4gUmVnYXJkcw0KPiA+ID4gQW5keQ0KPiA+ID4NCj4gPiA+DQo+ID4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiBGcm9tOiBCZXJuYXJkIEFib2JhIFtt YWlsdG86YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbV0NCj4gPiA+PiBTZW50OiAxNSBNYXkgMjAx MyAxODoyMA0KPiA+ID4+IFRvOiBIdXR0b24sIEFuZHJldzsgQ2hlbnhpbiAoWGluKTsgYmVoYXZl QGlldGYub3JnOw0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gPiA+PiBTdWJqZWN0OiBSRTogW3J0Y3dl Yl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiA+PiBkcmFmdC1jaGVueGlu LSBiZWhhdmUtdHVybi13ZWJzb2NrZXQtMDAudHh0DQo+ID4gPj4NCj4gPiA+PiBBbmRyZXcgSHV0 dG9uIHNhaWQ6DQo+ID4gPj4+IFdoZW4gd2Ugd3JvdGUgdGhlIGRyYWZ0IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi0NCj4gPiA+PiBydGN3ZWItbmF0LWZpcmV3YWxsLWNv bnNpZGVyYXRpb25zLTAwIHdlIGRpZCBub3QgaW5jbHVkZSB0aGlzDQo+ID4gPj4gb3B0aW9uIGJl Y2F1c2Ugd2UgZGlkIG5vdCBzZWUgdGhlIGJlbmVmaXQgb2YgYWRkaXRpb25hbCB0cmFuc3BvcnQN Cj4gPiA+PiBvcHRpb25zIGZvciBUVVJOIGdpdmVuIHRoYXQgdGhlIGV4aXN0aW5nIG9wdGlvbnMg KEUuZy4gVFVSTi9UQ1ANCj4gPiA+PiBhbmQgVFVSTi9UTFMpIHNlZW0gdG8gYmUgbWVldCBvdXIg bmVlZHMuDQo+ID4gPj4+DQo+ID4gPj4+IFNvIHdoYXQgd291bGQgYmUgdGhlIGJlbmVmaXRzIHRo YXQganVzdGlmeSB0aGlzIGFkZGl0aW9uDQo+IHRyYW5zcG9ydA0KPiA+ID4+IG9wdGlvbiBmb3Ig VFVSTj8NCj4gPiA+Pg0KPiA+ID4+IFtCQV0gSW4gbXkgZXhwZXJpZW5jZSwgIGluc3RpdHV0aW9u cyB3aXRoIHZlcnkgcmVzdHJpY3RpdmUNCj4gc2VjdXJpdHkNCj4gPiA+PiBwb2xpY2llcyAoZS5n LiB0aG9zZSB0aGF0IGRvbid0IGFsbG93IFVEUCBpbiBvciBvdXQpIGFsc28gdGVuZCB0bw0KPiA+ ID4+IGRlcGxveSBvdGhlciBtZWFzdXJlcyBzdWNoIGFzIGRlZXAgcGFja2V0IGluc3BlY3Rpb24u ICAgU28ganVzdA0KPiA+ID4+IGJlY2F1c2Ugc29tZSB0cmFmZmljIGlzIGFsbG93ZWQgaW4gb3Ig b3V0IG9uIHBvcnQgODAgZG9lcyBub3QgbWVhbg0KPiA+ID4+IHRoYXQgVFVSTi9UQ1Agd2lsbCBi ZSBhbGxvd2VkIG9uIHRoYXQgcG9ydCAtIGEgRFBJIGJveCBtYXkgZXhhbWluZQ0KPiA+ID4+IHRo ZSB0cmFmZmljIGFuZCBjb21wbGFpbiBpZiBpdCBkb2Vzbid0IHNlZSBIVFRQIGJlaW5nIHVzZWQu ICBPbg0KPiA+ID4+IHRoZSBvdGhlciBoYW5kLCB1bmxlc3MgdGhlIERQSSBib3ggaXMgdXBncmFk ZWQsIGl0IHdpbGwgYWxzbw0KPiA+ID4+IGNvbXBsYWluIGFib3V0IHdlYnNvY2tldHMuICBTbyBJ IHRoaW5rIGRyYWZ0LWNoZW54aW4gb25seSBoZWxwcyBpbg0KPiA+ID4+IGEgc2l0dWF0aW9uIHdo ZXJlIFRVUk4gb3ZlciBXZWJzb2NrZXRzIHdvdWxkIGJlIGFsbG93ZWQgd2hlbg0KPiA+ID4+IFRV Uk4vVENQIHdvdWxkIG5vdCBiZS4gIFRoYXQgc2NlbmFyaW8gaXMgcmFyZSwgYXQgbGVhc3QgYXQg dGhlDQo+ID4gPj4gbW9tZW50Lg0KPiA+ID4+DQo+ID4gPj4gVGhlIGFyZ3VtZW50IGZvciBUVVJO IG92ZXIgV2Vic29ja2V0L1RMUyBpcyBldmVuIG1vcmUgZGlmZmljdWx0IHRvDQo+ID4gPj4gbWFr ZS4gV2hpbGUgRFBJIGJveGVzIG1heSBleGFtaW5lIHRyYWZmaWMgZGVzdGluZWQgdG8gcG9ydCA0 NDMNCj4gPiA+PiBjYXJlZnVsbHkgdG8gbWFrZSBzdXJlIHRoYXQgVExTIGlzIHJlYWxseSBiZWlu ZyB1c2VkLCAgYXNzdW1pbmcNCj4gPiA+PiB0aGF0IHRoZSBEUEkgYm94IGRvZXMgbm90IHNlZSBh bnl0aGluZyBpdCBjb25zaWRlcnMgZmlzaHksIHRoZSBUTFMNCj4gPiA+PiBleGNoYW5nZSB3aWxs IGNvbXBsZXRlIGFuZCB0aGUgRFBJIGJveCB3aWxsIGxvc2UgdmlzaWJpbGl0eS4NCj4gPiA+PiBB ZnRlciBUTFMgaXMgcnVubmluZywgdGhlIERQSSBib3ggZG9lcyBub3QgaGF2ZSBtdWNoIGluZm9y bWF0aW9uDQo+ID4gPj4gYXZhaWxhYmxlIHRvIGRpc3Rpbmd1aXNoIFRVUk4vVExTIGZyb20gSFRU UCBvdmVyIFRMUywgd2l0aCBvcg0KPiA+ID4+IHdpdGhvdXQgd2Vic29ja2V0cyAtLSBhbmQgdGhv c2UgdGhpbmdzIGl0IGRvZXMgaGF2ZSAoc3VjaCBhcw0KPiA+ID4+IHBhY2tldCBzaXplKSBhcmUg YXMgbGlrZWx5IHRvIHJlc3VsdCBpbiBhbiBvYmplY3Rpb24gdG8gd2Vic29ja2V0DQo+ID4gPj4g dHJhbnNwb3J0IGFzIFRVUk4vVExTLiAgU28gSSdtIG5vdCBzdXJlIHRoYXQgZHJhZnQtY2hlbnhp biB3aWxsDQo+ID4gPj4gaGVscCBpbiB0aGF0IHNpdHVhdGlvbiBlaXRoZXIuDQo+ID4gPg0KPiA+ ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gPiA+IHJ0Y3dlYkBp ZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3 ZWINCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiA+IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== From ggb@tokbox.com Sun May 19 23:20:55 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313C821F8FFA for ; Sun, 19 May 2013 23:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zajJjEWR0aTu for ; Sun, 19 May 2013 23:20:49 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 83F7B21F8FDF for ; Sun, 19 May 2013 23:20:49 -0700 (PDT) Received: from mail-pb0-f46.google.com ([209.85.160.46]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUZnAv+/bemdl/XlGHSuuKBkQ3vdeKctT@postini.com; Sun, 19 May 2013 23:20:49 PDT Received: by mail-pb0-f46.google.com with SMTP id rq2so853043pbb.5 for ; Sun, 19 May 2013 23:20:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=MEEnF9UQJaddOPR545NYv3a4ivMh/sm93NYqgTI5ADI=; b=Vjei2rI137/Kjd0Iazyducq0NWYZXwtyKJGOLKYAq9qLyVqLWS/EykZFA5vz+KLDcg Wux7Roe2c6+SsXA/1xCw2hvhD/LHc4d+AScHfcoHEfVmSJzoljOUq9KWdifsMtF7W558 kcd7FXOOiWDQ3GNH4LfRbZiFBprw1rGTH/ls1SNcRllqZ5uWYCdiEbHw0qDVtZTaUPfv bEwy42jtfr/lHuKrf2NkT9TOn9eZBKQEGXfzFciluRsVrw1uz0Vw7bYBL9GQiDjFvlrv PVb8sklLzpLDTZmCgqUot4gO8nUoH2ohHD6TTefM4ZO37KiFhol9T3UBFWo+jfg2Jfqx clWA== X-Received: by 10.68.204.35 with SMTP id kv3mr59429626pbc.87.1369030847027; Sun, 19 May 2013 23:20:47 -0700 (PDT) X-Received: by 10.68.204.35 with SMTP id kv3mr59429616pbc.87.1369030846920; Sun, 19 May 2013 23:20:46 -0700 (PDT) Received: from [192.168.10.222] (ginger.tokbox.com. [216.38.134.117]) by mx.google.com with ESMTPSA id wi6sm22724942pbc.22.2013.05.19.23.20.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 May 2013 23:20:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> Date: Sun, 19 May 2013 23:20:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlTwOqNMt0KuOOQEvX+sQevL65WCFWNvzEbQ2Vs5NFtqQLOh0BZyN8LUPGwYiS0i8cIbI//qjdLxrVH3EYDa0GPleA78m/9XLfOqzdrJf03GEOi8+Ok9dlwaEXAmND4fMrqsW0J8V3WLfYvmuEmDE+/DN7zBQ== X-Mailman-Approved-At: Mon, 20 May 2013 08:58:02 -0700 Cc: Bernard Aboba , "rtcweb@ietf.org" , "behave@ietf.org" , "Chenxin \(Xin\)" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 06:20:55 -0000 I agree that TURN over websockets doesn't solve much more scenarios than = TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it over = HTTP that aside of philosophical discussions would be the solution with = better success rate? Otherwise we will have to continue answering for = another 10 years "why is this app not working if skype does". Something like this draft sent some months ago but perhaps for TURN = instead of direct connections: http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt On 16/05/2013, at 01:28, Hutton, Andrew wrote: > 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. >=20 > 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. >=20 > Regards > Andy >=20 >=20 >> -----Original Message----- >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >> Sent: 15 May 2013 18:20 >> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org >> Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- >> behave-turn-websocket-00.txt >>=20 >> Andrew Hutton said: >>> 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. >>>=20 >>> So what would be the benefits that justify this addition transport >> option for TURN? >>=20 >> [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. >>=20 >> 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, the DPI box does not have much information available to >> distinguish TURN/TLS from HTTP over TLS, with or without websockets = -- >> and those things it does have (such as packet size) are as likely to >> result in an objection to websocket transport as TURN/TLS. So I'm = not >> sure that draft-chenxin will help in that situation either. >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From lorenzo@meetecho.com Mon May 20 02:15:56 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2CF21F8529 for ; Mon, 20 May 2013 02:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXdOxxAwRIPU for ; Mon, 20 May 2013 02:15:51 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg5.aruba.it [62.149.158.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2D99D21F856D for ; Mon, 20 May 2013 02:15:31 -0700 (PDT) Received: from localhost.localdomain ([143.225.229.163]) by smtpcmd05.ad.aruba.it with bizsmtp id e9FV1l00E3YAKuv019FVsx; Mon, 20 May 2013 11:15:29 +0200 Date: Mon, 20 May 2013 11:15:22 +0200 From: Lorenzo Miniero To: Gustavo =?UTF-8?B?R2FyY8OtYQ==?= Message-ID: <20130520111522.1b7e2eb1@meetecho.com> In-Reply-To: <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 20 May 2013 08:58:02 -0700 Cc: "rtcweb@ietf.org" , "Hutton, Andrew" , "behave@ietf.org" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 09:15:57 -0000 Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=C3=ADa ha scritto: > I agree that TURN over websockets doesn't solve much more scenarios > than TURN/TLS. If trying to fix HTTP Proxy traversal why not doing > it over HTTP that aside of philosophical discussions would be the > solution with better success rate? Otherwise we will have to > continue answering for another 10 years "why is this app not working > if skype does". >=20 > Something like this draft sent some months ago but perhaps for TURN > instead of direct connections: > http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt >=20 When I submitted that draft this summer, I had that exact purpose in mind, that is taking care of corner edge cases like restrictive proxies and the like. Of course it was not meant to be a solution, just a way to foster discussion in that direction. In that discussion I also mentioned some work we did about this in the past, which in part apparently ended up in draft-hutton-rtcweb-nat-firewall-considerations: http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html At the time most people in the ML thought it was either too useless, too complex or even harmful, considering it could be considered as a "sneaky" way to circumvent rules added by a network administrator, and so unacceptable. Anyway, as I said back then, a solution like this doesn't have to be sneaky, and it could very well be conceived in order to be admin-friendly rather than have a parrot and a wooden leg. Whether we actually need something like this or TURN-over-443 is enough I don't know: I still think it may be useful to tackle scenarios where everything else fails (the "skype works here" effect), so I'd be glad to be of help in that direction if needed. Lorenzo > On 16/05/2013, at 01:28, Hutton, Andrew wrote: >=20 > > 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. > >=20 > > 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. > >=20 > > Regards > > Andy > >=20 > >=20 > >> -----Original Message----- > >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > >> Sent: 15 May 2013 18:20 > >> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org > >> Subject: RE: [rtcweb] FW: New Version Notification for > >> draft-chenxin- behave-turn-websocket-00.txt > >>=20 > >> Andrew Hutton said: > >>> 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. > >>>=20 > >>> So what would be the benefits that justify this addition transport > >> option for TURN? > >>=20 > >> [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. > >>=20 > >> 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, the DPI box does not have much information > >> available to distinguish TURN/TLS from HTTP over TLS, with or > >> without websockets -- and those things it does have (such as > >> packet size) are as likely to result in an objection to websocket > >> transport as TURN/TLS. So I'm not sure that draft-chenxin will > >> help in that situation either. > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From iesg-secretary@ietf.org Mon May 20 18:44:47 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6A121F90B1; Mon, 20 May 2013 18:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46Xq6x-skSfG; Mon, 20 May 2013 18:44:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE59821F92FB; Mon, 20 May 2013 18:44:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130521014443.24697.41662.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 18:44:43 -0700 Cc: behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis' to Proposed Standard (draft-ietf-behave-nat64-discovery-heuristic-17.txt) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 01:44:47 -0000 The IESG has approved the following document: - 'Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis' (draft-ietf-behave-nat64-discovery-heuristic-17.txt) as Proposed Standard This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic/ Technical Summary This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. Working Group Summary The document specifies a heuristic that is not perfect and so some points were rough, but the constraint for this document was to operate without changes to code (only configuration) in existing networks. Given that constraint, there was strong consensus. Relaxing the constraint would allow one to do better, and that is the focus of a draft recently submitted to the PCP WG. Document Quality Jouni Korhonen did a prototype implementation that was presented in the WG but not included in commercial product. Additionally, Cameron Byrne (T-Mobile USA) has a 464XLAT implementation that also implements this draft, as noted at https://sites.google.com/site/tmoipv6/464xlat#TOC-Android-CLAT-on-a-UMTS-IPv6-only-network-with-DNS64-NAT64 Personnel Document Shepherd: Dave Thaler (dthaler@microsoft.com) Responsible Area Director: Martin Stiemerling From dwing@cisco.com Mon May 20 18:56:57 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10121F974D for ; Mon, 20 May 2013 18:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcFgv99H1WLO for ; Mon, 20 May 2013 18:56:52 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8761F21F976E for ; Mon, 20 May 2013 18:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12005; q=dns/txt; s=iport; t=1369101411; x=1370311011; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vwX1hgGIKKp0ess2zpx6mvjy0E5EiDEBuDifRnJ4vuU=; b=SK3lyEmwy0KljXO4w4buC8RFSuJaSAJ+Vh4afnWapkVtAb14nR2Ay05N TmyZcVmLLShdnHh72zDYNtrUIGUnpblCDuX926t4mSC1YnfCQrmm7UrSN h/OXDUORNkoPfOag8jsT0oNODd6rBv61AA8U71aukqEux3KjvM7o/XnGe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAL7TmlFIo8UY/2dsb2JhbABPCoM4wU+BHHSCHwEBAQMBAQEBJBMtBwsFCwsYLiEGMAYTh3sDCQYMs3QNiFUEjEqBEwgFB30zB4JzYQOJH4wzgWaGHoV/hSODLxyBLAEf X-IronPort-AV: E=Sophos;i="4.87,711,1363132800"; d="scan'208";a="31433643" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 21 May 2013 01:56:49 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4L1ugO4015873; Tue, 21 May 2013 01:56:43 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <518A757F.5000701@gmail.com> Date: Mon, 20 May 2013 18:56:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6ACBECAC-F476-4947-8F02-FC267403219C@cisco.com> References: <20130508154447.24024.36769.idtracker@ietfa.amsl.com> <518A757F.5000701@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1503) Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 01:56:57 -0000 Thanks for writing this document. My personal review, not as chair, Section 2.1 seems to be trying to distinguish between mechanisms that = are dynamic and those that are static. Static are DS-Lite with = [I-D.tsou-behave-natx4-log-reduction] and [I-D.pcp-port-set], MAP-E, and = lightweight 4over6. Dynamic is dynamic. Then there is the combination, = which is popularly described in draft-donley-behave-deterministic-cgn. = I would suggest separate sections explaining these three things, and = more concisely. Also, Section 2.1 is titled "NAT Logging Requirements = For Different Transition Methods" and has 3 paragraphs describing MAP-E, = which does not do network address translation in the ISP's network; a = different title for the section that discusses MAP-E seems useful. = Afterall, with MAP-E the NAT function occurs in the customer premise = NAT, which is not going to generate logging messages. It seems Section = 2 might be something we would want common between the SYSLOG and IPFIX = documents, perhaps? I noticed the non-normative "Note:" regarding Gateway-Initiated DS-Lite = underneath Figure 1. Can that be moved to somewhere else so it is more = normative? (It looks like a centered ). Perhaps it should = be explained in Section 2.1, rather than here. In Figure 1, can the user identifier be generalized a bit? There are = lots of NATs which use interface identifiers (e.g., en0, en1, en2), VLAN = IDs, VRFs, to separate the inside addresses -- rather than using the = fields shown here in Figure 1. This seems to have happened in Section = 3.1 (which shows VLAN ID and VRFs) but the table does not appear to = allow that sort of flexibility. Section 3.1, "NAT session creation and deletion events are recorded when a binding to a specific destination address and port is recorded in or deleted from the session database. See the discussion in Section 3 of [RFC6146]." That does not align with the endpoint-independent mapping described in = Section 3 of RFC6146. That is, a 'creation' event does not occur with = every new destination address. I found Section 3.1 really difficult to understand what is generated for = a TCP/UDP mapping, versus what is supposed to be generated for an ICMP = mapping. =20 " o Destination IPv4 (for NAT44) or IPv6 (for NAT64) address (OPTIONAL);" A NAT64 would have an IPv4 destination address. Note this is for = *destination logging*, which needs its own discussion beyond just = "(OPTIONAL)" and beyond the citation that RFC6888 recommends against = destination logging. There are implementation issues with destination = logging (state creation in the logging device to avoid generating a log = event with every packet), and it deserves mentioning in a logging = document that destination logging more than destroys the log reduction = benefit of bulk port assignment. " o Post-NAT destination IPv4 address (OPTIONAL);" Seems redundant with the preceding item. "The pre-NAT value of destination address will differ from the post-NAT value only in a double-NAT situation. Hence in most cases even with destination logging the pre-NAT value will not be recorded." I don't understand what that means. Please make it clearer in the = document. This is the first and only time the term "double-NAT" appears = in the document, which might be part of my confusion. Section 3.4 says: "The same allocation applies to each protocol = supported by the NAT." -> but you really only mean UDP and TCP, even = though the NAT supports ICMP (which doesn't use ports) or even if it = were to support SCTP (which does not expect NAPT devices to rewrite port = numbers). So, please say "The same ports are allocated for TCP and = UDP." Section 3.4, why are the starting and ending port numbers optional, can = this work? =20 Section 3.4, the Port Range Size and Range Step are too complicated. = Are=20 Section 3.4 needs to explain if the same single logging event will be = generated when ports are deleted, or if they are consolidated. For = example, let's say ports 100-200 are allocated to a subscriber and a = logging event generated, then ports 200-250 are (later) allocated to the = same subscriber and a logging event generated. Will that second logging = event indicate ports 100-250? (I could see someone reasonably = implementing that). Would two separate deletion log events be = generated, one deletion for 100-200, and another deletion for 201-250? = Or would only one log deletion event be generated? All of these corner = cases need discussion with some rules for how this is expected to work. = This could perhaps be left to implementation decision, but if that is = the decision it should clearly say. General comment for all of sections 3.5, 3.6, and 3.7: Can a SYSLOG = message be generated *before* we hit a limit? It seems there is no = highwater mark for any of those. I expect operators would prefer = knowing before hitting a limit and also when hitting a limit (because = users will notice the hard failure when a limit is hit). Thoughts? "3.5. NAT Address Exhaustion Event", is there expected to be anything = to prevent this event from being continually generated? Because, if the = NAT is running near its limit and hits it, it will likely have a port = released, then one allocated (hitting the limit again), over and over = again. Same question for Section 3.4 (port exhaustion). And, are both = events generated when the final port is allocated (seems like both would = be generated). =20 Section 3.7, Quota exhausted -- for the (per-user) quota a citation to = REQ-11 of RFC6888 would be helpful. I found the paragraph describing = which fields are mandatory for which sort of quota difficult to = understand. I played around with a table (which did not help clarity) = and some alternative wording. But I couldn't improve the text much, = because I don't really know what fields are best to send for the = different sort of events. This feels very free-form and a cause of = interoperability problems with the various ways a NAT or the SYSLOG = parsing code would interpret the presence of certain fields. For = example, does the lack of a subscriber-identifying address mean that a = non-subscriber-specific administrative limit was hit? It seems that is = the case, which is okay, but more explicit explanation could be helpful. = Or creating separate events like was done with 3.5 and 3.6 =09 Section 5.2.1, "NTyp: NAT Type" where it mentions NAT44 it should cite = the canonical NAPT44 definition in RFC3022. For NAT64, probably want to = reference both stateful NAT64 (RFC6146) and stateless (RFC6145). =20 5.2.5. PreS4: Pre-NAT IPv4 Source Address PARAM-VALUE: part or all of an IPv4 address, represented in dotted decimal form. Why provide only part of the IPv4 address? For on-the-wire efficiency? = If some of the address is omitted, is it the first NNN bits that are = omitted, or the last NNN bits that are omitted. I would omit the first = NNN bits if all the internal addresses shared those same NNN bits (e.g., = all were 100.64/10, I could omit the first 10 bits). I would omit the = last NNN bits if assigning a /24 to a subscriber and I don't care which = of their devices caused the NAT event. =20 5.2.6. PreS6: Pre-NAT IPv6 Source Address: "PARAM-VALUE: Part or all = of an IPv6 address, represented in the form specified by [ RFC5952]." Same question -- the first part or the last part of the address? Most = subscribers are assigned a /64, so reporting the full 128 bit address is = awkward, I agree. But, similarly, most of an ISP's network will use the = same IPv6 prefix so reporting the first 8 or 24 bits is redundant. The = document needs to clarify. =20 And as this is string-encoded, what rules should be followed for "::", = as that has changed in the last couple of years and would be good to = cite. In IANA considerations a new IANA registry is created. This needs to = additionally provide guidance for how that new registry can be extended = in teh future, and a few other things. RFC5226 has details. Security considerations: " When logs are being recorded for regulatory reasons, preservation of their integrity and authentication of their origin is essential." The accuracy and unambiguity of the information is important, as well. = To that point, the address compression has me concerned and address = compression needs more text in the document, and may deserve calling out = explicitly in the security considerations section. Also worth pointing = out is the address ranges and "step range" (whatever that is) might be = changed while the NAT is operating -- which impacts almost everything = reported to the SYSLOG server. Seems useful to add NAT Configuration = Changed events when such things occur? In security considerations, missing messages are not mentioned. They = should be. Would it be worthwhile to include a sequence number (which = does not appear to be part of the SYSLOG header, nor of the messages = defined in this spec.) -d =20 On May 8, 2013, at 8:55 AM, Tom Taylor = wrote: > Done at last. The updated document has two new sections: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Comments are welcome. Fire away. >=20 > Tom Taylor >=20 > On 08/05/2013 11:44 AM, internet-drafts@ietf.org wrote: >>=20 >> 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. >>=20 >> Title : Syslog Format for NAT Logging >> Author(s) : Zhonghua Chen >> Cathy Zhou >> Tina Tsou >> T. Taylor >> Filename : draft-ietf-behave-syslog-nat-logging-01.txt >> Pages : 31 >> Date : 2013-05-08 >>=20 >> Abstract: >> With the wide deployment of Carrier Grade NAT (CGN) devices, the >> logging of NAT-related events has become very important for legal >> purposes. The logs may be required to identify a host that was = used >> to launch malicious attacks or engage in illegal behaviour, and/or >> may be required for accounting purposes. This document identifies >> the events that need to be logged and the parameters that are >> required in the logs depending on the context in which the NAT is >> being used. It goes on to standardize formats for reporting these >> events and parameters using SYSLOG (RFC 5424). A companion = document >> specifies formats for reporting the same events and parameters = using >> IPFIX (RFC 5101). Applicability statements are provided in this >> document and its companion to guide operators and implementors in >> their choice of which technology to use for logging. >>=20 > ... > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon May 20 19:11:59 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B870721F977C for ; Mon, 20 May 2013 19:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBdeqJmqMr6I for ; Mon, 20 May 2013 19:11:54 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9633A21F9774 for ; Mon, 20 May 2013 19:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2007; q=dns/txt; s=iport; t=1369102314; x=1370311914; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=m1Zp5g6Yqa2GvzFK3yNhqWt3lHWJUTktmCw7dFL1Z8k=; b=Tl+oz/UKzDdHF/LPibX15Z1PwMOSwo39eQVofVhskmMiD5IxhMau/lbe C2SB8eO4WJg4pKoRUlneSdeyizdzuboxcKwewa1GBB4ao5BAO42rtVnWp WQdW/rzD58pC3U5v4CiQOMaJT6gWy0ZUi2/tGog0kDaYe9BJs33scGanZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFADHXmlGrRDoG/2dsb2JhbABZgwgxwU6BBhZ0gmA/gT6IH7xfjyGCemEDiR+OGYYeiyKDLxw X-IronPort-AV: E=Sophos;i="4.87,711,1363132800"; d="scan'208";a="78617369" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 21 May 2013 02:11:54 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4L2BrAX023928; Tue, 21 May 2013 02:11:53 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 20 May 2013 19:11:53 -0700 Message-Id: <4ACE4A37-091D-433A-8112-98E201605046@cisco.com> To: draft-ietf-behave-ipfix-nat-logging Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "" Subject: [BEHAVE] short review of draft-ietf-behave-ipfix-nat-logging-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 02:11:59 -0000 This is a short review of draft-ietf-behave-ipfix-nat-logging-00. I = noticed several things in this document which are similar to my review = of the SYSLOG document. Please be sure to see that review and I'm sure = you will notice some similarities. I noticed draft-ietf-behave-ipfix-nat-logging-00 also seems to not = explain the nuances of logging the destination. This not only could = increase log file size, but also impacts the memory of the NAT device = and forces state on otherwise-stateless devices (such as stateless = NAT64, MAP-E, or MAP-T, and others). Not to mention creates a log of = user activity which reduces subscriber privacy. I see draft-ietf-behave-ipfix-nat-logging-00 also has a 'range step = size', but I am not aware of where 'step size' is explained or discussed = elsewhere. A citation within the document to wherever 'step size' is = explained would be useful. =20 It reads strangely that the Address Binding event described in Section = 5.4.8 shows "Mandatory: No" for both IPv4 and IPv6 source addresses -- = surely one or the other needs to be present for this event to make = sense, the text says: This event will be generated when a NAT device binds a local address with a global address. This binding event happens when the first packet of the first flow from a host in the private realm. but I can't tell if, when a brand-new TCP SYN is sent by a client, if = that causes both an Address Binding event and _also_ a "NAT44 BIB = create" event, because the document does not describe a "BIB" or a "Bind = entry" -- if those are well-understood terms, can a citation be added, = or in-place definition be added? Also would benefit from clarity around = why there is a Address Binding event in Section 5.4.8 versus the "BIB = create" events described earlier. Similar observation as with SYSLOG on security considerations, need for = clarity of the logs, and suchlike (see my SYSLOG review posted to = BEHAVE). -d From andrew.hutton@siemens-enterprise.com Tue May 21 06:34:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC3121F96BC; Tue, 21 May 2013 06:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhvj8cANgMSj; Tue, 21 May 2013 06:34:12 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id AD4EF21F974B; Tue, 21 May 2013 06:34:11 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 477811EB851A; Tue, 21 May 2013 15:34:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Tue, 21 May 2013 15:34:10 +0200 From: "Hutton, Andrew" To: Simon Pietro Romano Thread-Topic: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVTqUu83hGBO03EOmioPLICQbqpkN5f0AgABIK4CAAXZogA== Date: Tue, 21 May 2013 13:34:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> In-Reply-To: <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1159E317MCHP04MSXglobal_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , Lorenzo Miniero , "behave@ietf.org" , =?iso-8859-1?Q?Gustavo_Garc=EDa?= Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:34:17 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1159E317MCHP04MSXglobal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Simon I believe all possible solutions deserve attention however my feeling is th= at the HTTP Connect based mechanism for connecting to the TURN server via T= URN/TCP/TLS has a good chance of being implemented by browsers. What I would really like to happen is for draft-hutton-rtcweb-nat-firewall-= considerations to be adopted and progressed by the WG to describe the prefe= rred solution whatever it might be. In the next update we could add some text describing the alternatives to th= e HTTP CONNECT based mechanism to promote further discussion at least we se= em to have some agreement that a solution is needed. Regards Andy From: Simon Pietro Romano [mailto:spromano@unina.it] Sent: 20 May 2013 18:12 To: Hutton, Andrew Cc: Lorenzo Miniero; Gustavo Garc=EDa; behave@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-tur= n-websocket-00.txt I keep on thinking that the solution depicted in http://tools.ietf.org/id/d= raft-miniero-rtcweb-http-fallback-00.txt deserves attention. Simon Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto: Regarding the HTTP fallback and whether this could be adapted to be a TURN = over HTTP based solution then I think the same comments that were made on t= he TURN over websockets apply. What are the benefits of creating a new tran= sport for TURN over what we can do using HTTP Connect as described in http:= //tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-00. Having said that I am really happy we are having this debate as we really n= eed to find a solution here that the browser vendors will implement so I wo= uld really like to know which options they prefer. I really hope we can get draft-hutton-rtcweb-nat-firewall-considerations ad= opted and use it to document whatever the working group agrees on being the= right solution. Regards Andy -----Original Message----- From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] Sent: 20 May 2013 10:15 To: Gustavo Garc=EDa Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.or= g Subject: Re: [rtcweb] New Version Notification for draft-chenxin- behave-turn-websocket-00.txt Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=EDa > ha scritto: I agree that TURN over websockets doesn't solve much more scenarios than TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it over HTTP that aside of philosophical discussions would be the solution with better success rate? Otherwise we will have to continue answering for another 10 years "why is this app not working if skype does". Something like this draft sent some months ago but perhaps for TURN instead of direct connections: http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt When I submitted that draft this summer, I had that exact purpose in mind, that is taking care of corner edge cases like restrictive proxies and the like. Of course it was not meant to be a solution, just a way to foster discussion in that direction. In that discussion I also mentioned some work we did about this in the past, which in part apparently ended up in draft-hutton-rtcweb-nat-firewall-considerations: http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html At the time most people in the ML thought it was either too useless, too complex or even harmful, considering it could be considered as a "sneaky" way to circumvent rules added by a network administrator, and so unacceptable. Anyway, as I said back then, a solution like this doesn't have to be sneaky, and it could very well be conceived in order to be admin-friendly rather than have a parrot and a wooden leg. Whether we actually need something like this or TURN-over-443 is enough I don't know: I still think it may be useful to tackle scenarios where everything else fails (the "skype works here" effect), so I'd be glad to be of help in that direction if needed. Lorenzo On 16/05/2013, at 01:28, Hutton, Andrew wrote: 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 -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: 15 May 2013 18:20 To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- behave-turn-websocket-00.txt Andrew Hutton said: 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? [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, the DPI box does not have much information available to distinguish TURN/TLS from HTTP over TLS, with or without websockets -- and those things it does have (such as packet size) are as likely to result in an objection to websocket transport as TURN/TLS. So I'm not sure that draft-chenxin will help in that situation either. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _\= \|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Feder= ico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. Mag= ritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) )= / (_/ --_000_9F33F40F6F2CD847824537F3C4E37DDF1159E317MCHP04MSXglobal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Simon

 <= /p>

I believe all possible so= lutions deserve attention however my feeling is that the HTTP Connect based= mechanism for connecting to the TURN server via TURN/TCP/TLS has a good chance of being implemented by browsers.

 <= /p>

What I would really like = to happen is for draft-hutton-rtcweb-nat-firewall-considerations to be adop= ted and progressed by the WG to describe the preferred solution whatever it might be.

 <= /p>

In the next update we cou= ld add some text describing the alternatives to the HTTP CONNECT based mech= anism to promote further discussion at least we seem to have some agreement that a solution is needed.

 <= /p>

Regards=

Andy

 <= /p>

 <= /p>

From: Simon Pi= etro Romano [mailto:spromano@unina.it]
Sent: 20 May 2013 18:12
To: Hutton, Andrew
Cc: Lorenzo Miniero; Gustavo Garc=EDa; behave@ietf.org; rtcweb@ietf.= org
Subject: Re: [rtcweb] New Version Notification for draft-chenxin-beh= ave-turn-websocket-00.txt

 

I keep on thinking that the solution depicted in&nbs= p;http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt deserves attention.

 

Simon

 

Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andre= w ha scritto:



Regarding the HTTP fallback and whether this could b= e adapted to be a TURN over HTTP based solution then I think the same comme= nts that were made on the TURN over websockets apply. What are the benefits= of creating a new transport for TURN over what we can do using HTTP Connect as described in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-= 00.

Having said that I am really happy we are having this debate as we really n= eed to find a solution here that the browser vendors will implement so I wo= uld really like to know which options they prefer.

I really hope we can get draft-hutton-rtcweb-nat-firewall-considerations ad= opted and use it to document whatever the working group agrees on being the= right solution.

Regards
Andy



-----Original Message-----

From: Lorenzo Miniero [mailto:lorenzo@meetecho.com]

Sent: 20 May 2013 10:15

To: Gustavo Garc=EDa

Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org

Subject: Re: [rtcweb] New Version Notification for d= raft-chenxin-

behave-turn-websocket-00.txt

 

Il giorno Sun, 19 May 2013 23:20:41 -0700=

Gustavo Garc=EDa <ggb@tokbox.com> ha scritto:

 

I agree that TURN over websockets doesn't solve much= more scenarios

than TURN/TLS.   If trying to fix HTTP Pro= xy traversal why not doing

it over HTTP that aside of philosophical discussions= would be the

solution with better success rate?  Otherwise w= e will have to

continue answering for another 10 years "why is= this app not working

if skype does".

 

Something like this draft sent some months ago but p= erhaps for TURN

instead of direct connections:

http://tools.ietf.org/id/draft-miniero-rtcweb-ht= tp-fallback-00.txt

 

 

 

When I submitted that draft this summer, I had that = exact purpose in

mind, that is taking care of corner edge cases like = restrictive proxies

and the like. Of course it was not meant to be a sol= ution, just a way

to foster discussion in that direction. In that disc= ussion I also

mentioned some work we did about this in the past, w= hich in part

apparently ended up in draft-hutton-rtcweb-nat-firew= all-considerations:

 

http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg05041.html

 

At the time most people in the ML thought it was eit= her too useless,

too complex or even harmful, considering it could be= considered as a

"sneaky" way to circumvent rules added by = a network administrator, and

so unacceptable. Anyway, as I said back then, a solu= tion like this

doesn't have to be sneaky, and it could very well be= conceived in order

to be admin-friendly rather than have a parrot and a= wooden leg.

 

Whether we actually need something like this or TURN= -over-443 is enough

I don't know: I still think it may be useful to tack= le scenarios where

everything else fails (the "skype works here&qu= ot; effect), so I'd be glad

to be of help in that direction if needed.

 

Lorenzo

 

 

 

On 16/05/2013, at 01:28, Hutton, Andrew wrote:<= /o:p>

 

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 cas= e 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 a= ddresses.

 

So far I don't see the benefit that TURN over websoc= kets would have

in this scenario and it needs additional implementat= ion in the

browser and the TURN server.

 

Regards

Andy

 

 

-----Original Message-----

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]

Sent: 15 May 2013 18:20

To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org;

rtcweb@ietf.org

Subject: RE: [rtcweb] FW: New Version Notification f= or

draft-chenxin- behave-turn-websocket-00.txt

 

Andrew Hutton said:

When we wrote the draft http://tools.ietf.org/html/draft-hutton-

rtcweb-nat-firewall-considerations-00 we did not inc= lude this

option because we did not see the benefit of additio= nal transport

options for TURN given that the existing options (E.= g. TURN/TCP

and TURN/TLS) seem to be meet our needs.<= /p>

 

So what would be the benefits that justify this addi= tion

transport

option for TURN?

 

[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 b= ox may examine

the traffic and complain if it doesn't see HTTP bein= g used.  On

the other hand, unless the DPI box is upgraded, it w= ill also

complain about websockets.  So I think draft-ch= enxin only helps in

a situation where TURN over Websockets would be allo= wed when

TURN/TCP would not be.  That scenario is rare, = at least at the

moment.

 

The argument for TURN over Websocket/TLS is even mor= e difficult to

make. While DPI boxes may examine traffic destined t= o 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 vis= ibility.

After TLS is running, the DPI box does not have much= information

available to distinguish TURN/TLS from HTTP over TLS= , with or

without websockets -- and those things it does have = (such as

packet size) are as likely to result in an objection= to websocket

transport as TURN/TLS.  So I'm not sure that dr= aft-chenxin will

help in that situation either.

 

 

 

 

_______________________________________________=

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb

 

_______________________________________________=

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb

 

      &nbs= p;                         &n= bsp;            = ;            &n= bsp;             &nb= sp; _\\|//_

      &nbs= p;                            = ;            &n= bsp;              ( O-O )

   ~~~~~~~~~~~~= ~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

      &nbs= p;                 =             &nb= sp;            =        Simon Pietro Romano

      &nbs= p;         &nb= sp;            =             &nb= sp;      Universita' di Na= poli Federico II

      &nbs= p;          &n= bsp;              Computer Engineering Department =

                 =     Phone: +39 081 7683823 -- Fax: +39 081 7683816

      &nbs= p;                     &n= bsp;              e-mail: spromano@unina.it

 <= /p>

           &nb= sp;          <<Molti mi dic= ono che lo scoraggiamento =CB l'alibi degli 

           &nb= sp;          idioti. Ci rifl= etto un istante; e mi scoraggio>>. Magritte.

      &nbs= p;              &nb= sp;            =                       = ;  oooO

  ~~~~~~~~~~~~~~~~~~= ~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

           &nb= sp;            =             &nb= sp;                   =        \ (            ( =   )

           &nb= sp;            =             =                     &nbs= p;   \_)          ) /

      &nbs= p;                     &n= bsp;                     =                      = ;(_/

 <= /p>

 

 

 

--_000_9F33F40F6F2CD847824537F3C4E37DDF1159E317MCHP04MSXglobal_-- From tom.taylor.stds@gmail.com Tue May 21 07:21:50 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5001421F978F for ; Tue, 21 May 2013 07:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyTFbT9UWh01 for ; Tue, 21 May 2013 07:21:44 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id D373721F977A for ; Tue, 21 May 2013 07:21:30 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id l20so858304oag.37 for ; Tue, 21 May 2013 07:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KTJv7j6ZeaJkV0ja3b0yIKydXuW6ux5y7uTZ9VlPTcA=; b=gQ5Lc1pW4s05F3Y6IOeyfRx9m8FGUnhzSt9epQtp/6Uzv3kosEqLXsg08HbugshdIF mdJdHgZniZv6rc7NDkIPUfRiE/7FgLXXLGyudC/k1Suke3HKdG3uxB3DBEo+7cBKEIQW LBaCFNRrssUnkkSyKs3p9e0X8C2Ihur1z6oVcSByWVjWIcElm/3RdRwUFw7STt8e7eNC opAqzY+Qe8M8vfJvDOs4ctvxURlOPr8NPcragGWpZ0Z29qvAK5RbjztDqVIeaz+SvY1X FYkDiyCCxbK2eX0QS5vwNTi94Z9UJ8PW/MvzuQmndY862R05WJtFGheYeky+CzD8aFOd tkQg== X-Received: by 10.60.179.42 with SMTP id dd10mr1536989oec.124.1369146090413; Tue, 21 May 2013 07:21:30 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-36.tor.primus.ca. [173.206.2.36]) by mx.google.com with ESMTPSA id c20sm2627403oez.4.2013.05.21.07.21.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 07:21:29 -0700 (PDT) Message-ID: <519B82E9.7020609@gmail.com> Date: Tue, 21 May 2013 10:21:29 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dan Wing References: <20130508154447.24024.36769.idtracker@ietfa.amsl.com> <518A757F.5000701@gmail.com> <6ACBECAC-F476-4947-8F02-FC267403219C@cisco.com> In-Reply-To: <6ACBECAC-F476-4947-8F02-FC267403219C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:21:50 -0000 Thank you very much for the time you've spent on this. We'll study your comments carefully and report back on our suggested responses. Tom Taylor On 20/05/2013 9:56 PM, Dan Wing wrote: > Thanks for writing this document. > > My personal review, not as chair, > ... From spromano@unina.it Mon May 20 10:11:42 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF2921F96CA; Mon, 20 May 2013 10:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHKq8d3CV6TI; Mon, 20 May 2013 10:11:37 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id CC28821F96B9; Mon, 20 May 2013 10:11:34 -0700 (PDT) Received: from [143.225.162.130] ([143.225.162.130]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r4KHBWVP023559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 19:11:32 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_57A43A19-E216-43EE-9809-02D4AC87A6B4" From: Simon Pietro Romano In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> Date: Mon, 20 May 2013 19:11:31 +0200 Message-Id: <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Tue, 21 May 2013 09:10:43 -0700 Cc: "rtcweb@ietf.org" , Lorenzo Miniero , "behave@ietf.org" , =?iso-8859-1?Q?Gustavo_Garc=EDa?= Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:11:42 -0000 --Apple-Mail=_57A43A19-E216-43EE-9809-02D4AC87A6B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I keep on thinking that the solution depicted in = http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt = deserves attention. Simon Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto: > Regarding the HTTP fallback and whether this could be adapted to be a = TURN over HTTP based solution then I think the same comments that were = made on the TURN over websockets apply. What are the benefits of = creating a new transport for TURN over what we can do using HTTP Connect = as described in = http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations= -00. >=20 > Having said that I am really happy we are having this debate as we = really need to find a solution here that the browser vendors will = implement so I would really like to know which options they prefer. >=20 > I really hope we can get = draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to = document whatever the working group agrees on being the right solution. >=20 > Regards > Andy >=20 >=20 >> -----Original Message----- >> From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] >> Sent: 20 May 2013 10:15 >> To: Gustavo Garc=EDa >> Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org >> Subject: Re: [rtcweb] New Version Notification for draft-chenxin- >> behave-turn-websocket-00.txt >>=20 >> Il giorno Sun, 19 May 2013 23:20:41 -0700 >> Gustavo Garc=EDa ha scritto: >>=20 >>> I agree that TURN over websockets doesn't solve much more scenarios >>> than TURN/TLS. If trying to fix HTTP Proxy traversal why not doing >>> it over HTTP that aside of philosophical discussions would be the >>> solution with better success rate? Otherwise we will have to >>> continue answering for another 10 years "why is this app not working >>> if skype does". >>>=20 >>> Something like this draft sent some months ago but perhaps for TURN >>> instead of direct connections: >>> http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt >>>=20 >>=20 >>=20 >> When I submitted that draft this summer, I had that exact purpose in >> mind, that is taking care of corner edge cases like restrictive = proxies >> and the like. Of course it was not meant to be a solution, just a way >> to foster discussion in that direction. In that discussion I also >> mentioned some work we did about this in the past, which in part >> apparently ended up in = draft-hutton-rtcweb-nat-firewall-considerations: >>=20 >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html >>=20 >> At the time most people in the ML thought it was either too useless, >> too complex or even harmful, considering it could be considered as a >> "sneaky" way to circumvent rules added by a network administrator, = and >> so unacceptable. Anyway, as I said back then, a solution like this >> doesn't have to be sneaky, and it could very well be conceived in = order >> to be admin-friendly rather than have a parrot and a wooden leg. >>=20 >> Whether we actually need something like this or TURN-over-443 is = enough >> I don't know: I still think it may be useful to tackle scenarios = where >> everything else fails (the "skype works here" effect), so I'd be glad >> to be of help in that direction if needed. >>=20 >> Lorenzo >>=20 >>=20 >>=20 >>> On 16/05/2013, at 01:28, Hutton, Andrew wrote: >>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Regards >>>> Andy >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >>>>> Sent: 15 May 2013 18:20 >>>>> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; >> rtcweb@ietf.org >>>>> Subject: RE: [rtcweb] FW: New Version Notification for >>>>> draft-chenxin- behave-turn-websocket-00.txt >>>>>=20 >>>>> Andrew Hutton said: >>>>>> 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. >>>>>>=20 >>>>>> So what would be the benefits that justify this addition >> transport >>>>> option for TURN? >>>>>=20 >>>>> [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. >>>>>=20 >>>>> 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, the DPI box does not have much information >>>>> available to distinguish TURN/TLS from HTTP over TLS, with or >>>>> without websockets -- and those things it does have (such as >>>>> packet size) are as likely to result in an objection to websocket >>>>> transport as TURN/TLS. So I'm not sure that draft-chenxin will >>>>> help in that situation either. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_57A43A19-E216-43EE-9809-02D4AC87A6B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = keep on thinking that the solution depicted in http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt&n= bsp;deserves = attention.

Simon

Il giorno = 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto:

Regarding the HTTP fallback and whether this could be = adapted to be a TURN over HTTP based solution then I think the same = comments that were made on the TURN over websockets apply. What are the = benefits of creating a new transport for TURN over what we can do using = HTTP Connect as described in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-c= onsiderations-00.

Having said that I am really happy we are = having this debate as we really need to find a solution here that the = browser vendors will implement so I would really like to know which = options they prefer.

I really hope we can get = draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to = document whatever the working group agrees on being the right = solution.

Regards
Andy


-----Original Message-----
From: Lorenzo Miniero = [mailto:lorenzo@meetecho.com]
Sent: 20 May 2013 10:15
To: Gustavo Garc=EDa
Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org
Subject: Re: [rtcweb] New Version Notification for = draft-chenxin-
behave-turn-websocket-00.txt

Il giorno Sun, = 19 May 2013 23:20:41 -0700
Gustavo Garc=EDa <ggb@tokbox.com> ha = scritto:

I agree that TURN over websockets doesn't solve much more = scenarios
than TURN/TLS.   If = trying to fix HTTP Proxy traversal why not = doing
it over HTTP that aside of philosophical discussions would = be the
solution with better success rate?  Otherwise we will = have to
continue answering for another 10 years "why is this app = not working
if skype = does".

Something like this draft sent = some months ago but perhaps for = TURN
instead of direct = connections:
http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt



When I = submitted that draft this summer, I had that exact purpose = in
mind, that is taking care = of corner edge cases like restrictive = proxies
and the like. Of = course it was not meant to be a solution, just a = way
to foster discussion in = that direction. In that discussion I also
mentioned some work we did about this in the past, which = in part
apparently ended up in = draft-hutton-rtcweb-nat-firewall-considerations:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html
=

At the time most people in the ML thought it was either = too useless,
too complex or = even harmful, considering it could be considered as = a
"sneaky" way to circumvent = rules added by a network administrator, and
so unacceptable. Anyway, as I said back then, a solution = like this
doesn't have to be = sneaky, and it could very well be conceived in = order
to be admin-friendly = rather than have a parrot and a wooden leg.

Whether we = actually need something like this or TURN-over-443 is = enough
I don't know: I still = think it may be useful to tackle scenarios = where
everything else fails = (the "skype works here" effect), so I'd be = glad
to be of help in that = direction if needed.

Lorenzo



On 16/05/2013, at 01:28, Hutton, Andrew = wrote:

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


-----Original = Message-----
From: Bernard Aboba = [mailto:bernard_aboba@hotmail.com]
Sent: = 15 May 2013 = 18:20
To: Hutton, Andrew; Chenxin = (Xin); behave@ietf.org;
rtcweb@ietf.org
Subject: RE: [rtcweb] FW: New = Version Notification = for
draft-chenxin- = behave-turn-websocket-00.txt

Andrew Hutton = said:
When = we wrote the draft http://tools.ietf.org/ht= ml/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?

[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, the DPI = box does not have much = information
available to distinguish = TURN/TLS from HTTP over TLS, with = or
without websockets -- and those = things it does have (such = as
packet size) are as likely to = result in an objection to = websocket
transport as TURN/TLS.  So = I'm not sure that draft-chenxin = will
help in that situation = either.




_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.org= /mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.org= /mailman/listinfo/rtcweb

____________= ___________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_57A43A19-E216-43EE-9809-02D4AC87A6B4-- From karl.stahl@intertex.se Tue May 21 16:03:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCA411E80E8; Tue, 21 May 2013 16:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.241 X-Spam-Level: X-Spam-Status: No, score=0.241 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WuA9d85G2iU; Tue, 21 May 2013 16:03:01 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 039D121F929F; Tue, 21 May 2013 16:02:57 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305220102421239; Wed, 22 May 2013 01:02:42 +0200 From: "Karl Stahl" To: , References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> Date: Wed, 22 May 2013 01:02:40 +0200 Message-ID: <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CE5688.0ECFE650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOVTqUu83hGBO03EOmioPLICQbqpkN5f0AgABIK4CAAXZogIAAbTOA Content-Language: sv X-Mailman-Approved-At: Tue, 21 May 2013 18:02:41 -0700 Subject: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 23:03:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CE5688.0ECFE650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, =20 Isn=92t such a low quality fallback channel for penetrating restrictive NAT/Firewalls NEGATIVE for RTCweb? =20 QUALITY: Any tunneling of RTP through the =93always open=94 HTTP 80 or = HTTPS 443 ports is RTP over an error correcting TCP channel. Thus, lost packets = will be retransmitted, resulting in second long packet delays. Jitter buffers don=92t handle that and if they did, we will not be happy with second = long delays in RTC, i.e. two-way real-time communications. That is why we run = RTP over UDP. =20 (When discussing QoS, some will stand up and tell that sound quality = really was good =96 it is all about bandwidth, etc. Yes, quality in an IP = network is good when you don=92t fill the pipe =96 even this TCP-pipe is. But in = today=92s data crowded networks, where you are not alone, the pipe is filled at = every email or click on a webpage. Then packets are lost, and with the = fallback discussed you don=92t even have the benefit of UDP over TCP transport.) =20 SKYPE: Yes, I know Skype has a similar fallback =96 same low quality - = and I have heard the argument =93Otherwise we will have to continue answering = for another 10 years "why is this app not working if skype does". But why = should that be the ambition of the RTCweb standards? =20 DECIDING NETWORK USAGE: Doesn=92t the network administrator that = configured the firewall have a legitimate right to decide what traffic should be on = his network? If he only wants internal traffic and surfing, shouldn=92t it = be his choice to be able to configure just that? And if a service provider (SP) blocks all but surfing on his access, the user can get another = subscription if he wants to benefit from using RTCweb (and that SP will go out of business=85or can just offer his access at a very low cost for surfing = only usage). =20 Not getting RTCweb through a restrictive firewall, may rather encourage = the network administer to resolve the problem properly, than if we provide a fallback with lousy quality. Then the user may not be interested in the = =93bad RTCweb=94 and won=92t ask his network administrator to =93enable it=94. =20 BETTER THAN BEST EFFORT: Actually, it we =93enable networks for = RTCweb=94, we could quality wise get a BETTER pipes for RTCweb media than for surfing! = The STUN/TURN server address provided actually allows ICE/TURN/STUN media to = be routed another path than data traffic =96 a better path, maybe even with = level 3 QoS (diffserve or RSVP if we are lucky). =20 Remember, that we finally are stepping up from 100 years old 3,5 kHz = voice only to potentially telepresence HiFi HD 3.5 Mbps quality. We should encourage that the networks support this potential, rather than = providing a low quality fallback, that will bring a bad user experience to RTCweb. =20 NEW VIEW ON ICE: I think it is time to view the ICE/TURN/STUN protocol = suit in an alternative way. Instead of being a way to fool or trick media = through a NAT/Firewall that is unaware of what is happening, regard = ICE/TURN/STUN as a protocol to Request Access for RTC through the firewall. Firewalls =96 = if combined with the STUN/TURN server =96 could then respond not just by = opening a path for RTC, but could also prioritize and shape the traffic in the firewall for much better quality. (A firewall is often the point where congestion can be controlled.) And the firewall could request quality = over the transport network for the RTC media (heard cable operators were interested to do that with their reservation type of QoS they use for = voice) =96 others could use diffserve. =20 TURN and STUN servers also include authentication =96 Maybe they were = intended for =93Request pass trough=94 rather than =93Fool media through=94, were = they? =20 /Karl =20 =20 Fr=E5n: rtcweb-bounces@ietf.org [ mailto:rtcweb-bounces@ietf.org] F=F6r = Hutton, Andrew Skickat: den 21 maj 2013 15:34 Till: Simon Pietro Romano Kopia: rtcweb@ietf.org; = behave@ietf.org =C4mne: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt =20 Hi Simon =20 I believe all possible solutions deserve attention however my feeling is that the HTTP Connect based mechanism for connecting to the TURN server = via TURN/TCP/TLS has a good chance of being implemented by browsers. =20 What I would really like to happen is for draft-hutton-rtcweb-nat-firewall-considerations to be adopted and = progressed by the WG to describe the preferred solution whatever it might be. =20 In the next update we could add some text describing the alternatives to = the HTTP CONNECT based mechanism to promote further discussion at least we = seem to have some agreement that a solution is needed. =20 Regards Andy =20 =20 From: Simon Pietro Romano [mailto:spromano@unina.it]=20 Sent: 20 May 2013 18:12 To: Hutton, Andrew Cc: Lorenzo Miniero; Gustavo Garc=EDa; behave@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt =20 I keep on thinking that the solution depicted in http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt = deserves attention. =20 Simon =20 Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto: Regarding the HTTP fallback and whether this could be adapted to be a = TURN over HTTP based solution then I think the same comments that were made = on the TURN over websockets apply. What are the benefits of creating a new transport for TURN over what we can do using HTTP Connect as described = in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideration= s-0 0. Having said that I am really happy we are having this debate as we = really need to find a solution here that the browser vendors will implement so = I would really like to know which options they prefer. I really hope we can get draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to document whatever the working group agrees on = being the right solution. Regards Andy -----Original Message----- From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] Sent: 20 May 2013 10:15 To: Gustavo Garc=EDa Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-chenxin- behave-turn-websocket-00.txt =20 Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=EDa ha scritto: =20 I agree that TURN over websockets doesn't solve much more scenarios than TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it over HTTP that aside of philosophical discussions would be the solution with better success rate? Otherwise we will have to continue answering for another 10 years "why is this app not working if skype does". =20 Something like this draft sent some months ago but perhaps for TURN instead of direct connections: http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt =20 =20 =20 When I submitted that draft this summer, I had that exact purpose in mind, that is taking care of corner edge cases like restrictive proxies and the like. Of course it was not meant to be a solution, just a way to foster discussion in that direction. In that discussion I also mentioned some work we did about this in the past, which in part apparently ended up in draft-hutton-rtcweb-nat-firewall-considerations: =20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html =20 At the time most people in the ML thought it was either too useless, too complex or even harmful, considering it could be considered as a "sneaky" way to circumvent rules added by a network administrator, and so unacceptable. Anyway, as I said back then, a solution like this doesn't have to be sneaky, and it could very well be conceived in order to be admin-friendly rather than have a parrot and a wooden leg. =20 Whether we actually need something like this or TURN-over-443 is enough I don't know: I still think it may be useful to tackle scenarios where everything else fails (the "skype works here" effect), so I'd be glad to be of help in that direction if needed. =20 Lorenzo =20 =20 =20 On 16/05/2013, at 01:28, Hutton, Andrew wrote: =20 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. =20 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. =20 Regards Andy =20 =20 -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: 15 May 2013 18:20 To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin- behave-turn-websocket-00.txt =20 Andrew Hutton said: 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. =20 So what would be the benefits that justify this addition transport option for TURN? =20 [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. =20 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, the DPI box does not have much information available to distinguish TURN/TLS from HTTP over TLS, with or without websockets -- and those things it does have (such as packet size) are as likely to result in an objection to websocket transport as TURN/TLS. So I'm not sure that draft-chenxin will help in that situation either. =20 =20 =20 =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro = Romano Universita' di Napoli Federico II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it =20 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) = ) / = (_/ =20 =20 =20 =20 ------=_NextPart_000_0001_01CE5688.0ECFE650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Al= l,

 

Is= n’t such a low quality fallback channel for penetrating = restrictive NAT/Firewalls NEGATIVE for RTCweb?

 

QU= ALITY: Any tunneling of RTP through the “always open” HTTP = 80 or HTTPS 443 ports is RTP over an error correcting TCP channel. Thus, = lost packets will be retransmitted, resulting in second long packet = delays. Jitter buffers don’t handle that and if they did, we will = not be happy with second long delays in RTC, i.e. two-way real-time = communications. That is why we run RTP over UDP.

 

(W= hen discussing QoS, some will stand up and tell that sound quality = really was good – it is all about bandwidth, etc. Yes, quality in = an IP network is good when you don’t fill the pipe – even = this TCP-pipe is. But in today’s data crowded networks, where you = are not alone, the pipe is filled at every email or click on a webpage. = Then packets are lost, and with the fallback discussed you don’t = even have the benefit of UDP over TCP = transport.)

 

SK= YPE: Yes, I know Skype has a similar fallback – same low quality - = and I have heard the argument “Otherwise = we will have to continue answering for another 10 years "why is = this app not working if skype does". Bu= t why should that be the ambition of the RTCweb = standards?

 

DE= CIDING NETWORK USAGE: Doesn’t the network administrator that = configured the firewall have a legitimate right to decide what traffic = should be on his network? If he only wants internal traffic and surfing, = shouldn’t it be his choice to be able to configure just that? And = if a service provider (SP) blocks all but surfing on his access, the = user can get another subscription if he wants to benefit from using = =A0RTCweb (and that SP will go out of business…or can just offer = his access at a very low cost for surfing only = usage).

 

No= t getting RTCweb through a restrictive firewall, may rather encourage = the network administer to resolve the problem properly, than if we = provide a fallback with lousy quality. Then the user may not be = interested in the “bad RTCweb” and won’t ask his = network administrator to “enable = it”.

 

BE= TTER THAN BEST EFFORT: Actually, it we “enable networks for = RTCweb”, we could quality wise get a BETTER pipes for RTCweb media = than for surfing! The STUN/TURN server address provided actually allows = ICE/TURN/STUN media to be routed another path than data traffic – = a better path, maybe even with level 3 QoS (diffserve or RSVP if we are = lucky).

 

Re= member, that we finally are stepping up from 100 years old 3,5 kHz voice = only to potentially telepresence HiFi HD 3.5 Mbps quality. We should = encourage that the networks support this potential, rather than = providing a low quality fallback, that will bring a bad user experience = to RTCweb.

 

NE= W VIEW ON ICE: I think it is time to view the ICE/TURN/STUN protocol = suit in an alternative way. Instead of being a way to fool or trick = media through a NAT/Firewall that is unaware of what is happening, = regard ICE/TURN/STUN as a protocol to Request Access for RTC through the = firewall. Firewalls – if combined with the STUN/TURN server = – could then respond not just by opening a path for RTC, but could = also prioritize and shape the traffic in the firewall for much better = quality. (A firewall is often the point where congestion can be = controlled.) And the firewall could request quality over the transport = network for the RTC media (heard cable operators were interested to do = that with their reservation type of QoS they use for voice) – = others could use diffserve.

 

TU= RN and STUN servers also include authentication – Maybe they were = intended for “Request pass trough” rather than “Fool = media through”, were they?

 

/K= arl

 

 

Fr=E5n: = rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] F=F6r = Hutton, Andrew
Skickat: den 21 maj 2013 = 15:34
Till: Simon Pietro Romano
Kopia: rtcweb@ietf.org; = behave@ietf.org
=C4mn= e: Re: [rtcweb] New Version Notification for = draft-chenxin-behave-turn-websocket-00.txt

 

Hi Simon

 

I believe all possible solutions deserve attention however my feeling = is that the HTTP Connect based mechanism for connecting to the TURN = server via TURN/TCP/TLS has a good chance of being implemented by = browsers.

 

What I would really like to happen is for = draft-hutton-rtcweb-nat-firewall-considerations to be adopted and = progressed by the WG to describe the preferred solution whatever it = might be.

 

In the next update we could add some text describing the alternatives = to the HTTP CONNECT based mechanism to promote further discussion at = least we seem to have some agreement that a solution is = needed.

 

Regards

Andy

 

 

From:= Simon = Pietro Romano [mailto:spromano@unina.it] =
Sent: 20 May 2013 18:12
To: Hutton, = Andrew
Cc: Lorenzo Miniero; Gustavo Garc=EDa; behave@ietf.org; rtcweb@ietf.org
Subject: = Re: [rtcweb] New Version Notification for = draft-chenxin-behave-turn-websocket-00.txt

 

I keep on thinking that the = solution depicted in http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt=  deserves attention.

 

Simon

 

Il giorno 20/mag/2013, alle ore = 13:06, Hutton, Andrew ha scritto:




Regarding the HTTP fallback and = whether this could be adapted to be a TURN over HTTP based solution then = I think the same comments that were made on the TURN over websockets = apply. What are the benefits of creating a new transport for TURN over = what we can do using HTTP Connect as described in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall= -considerations-00.

Having said that I am really happy we are = having this debate as we really need to find a solution here that the = browser vendors will implement so I would really like to know which = options they prefer.

I really hope we can get = draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to = document whatever the working group agrees on being the right = solution.

Regards
Andy




-----Original = Message-----

From: Lorenzo Miniero [mailto:lorenzo@meetecho.com]

Sent: 20 May 2013 = 10:15

To: Gustavo = Garc=EDa

Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org

=

Subject: Re: [rtcweb] New Version = Notification for = draft-chenxin-

behave-turn-websocket-00.txt

 

Il giorno Sun, 19 May 2013 23:20:41 = -0700

Gustavo Garc=EDa <ggb@tokbox.com> ha = scritto:

 

I agree that TURN over websockets = doesn't solve much more = scenarios

than TURN/TLS.   If = trying to fix HTTP Proxy traversal why not = doing

it over HTTP that aside of = philosophical discussions would be = the

solution with better success rate? =  Otherwise we will have = to

continue answering for another 10 = years "why is this app not = working

if skype = does".

 

Something like this draft sent some = months ago but perhaps for = TURN

instead of direct = connections:

http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt=

 

 

 

When I submitted that draft this = summer, I had that exact purpose = in

mind, that is taking care of corner = edge cases like restrictive = proxies

and the like. Of course it was not = meant to be a solution, just a = way

to foster discussion in that = direction. In that discussion I = also

mentioned some work we did about = this in the past, which in = part

apparently ended up in = draft-hutton-rtcweb-nat-firewall-considerations:

 

http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html

 

At the time most people in the ML = thought it was either too = useless,

too complex or even harmful, = considering it could be considered as = a

"sneaky" way to = circumvent rules added by a network administrator, = and

so unacceptable. Anyway, as I said = back then, a solution like = this

doesn't have to be sneaky, and it = could very well be conceived in = order

to be admin-friendly rather than = have a parrot and a wooden = leg.

 

Whether we actually need something = like this or TURN-over-443 is = enough

I don't know: I still think it may = be useful to tackle scenarios = where

everything else fails (the = "skype works here" effect), so I'd be = glad

to be of help in that direction if = needed.

 

Lorenzo

 

 

 

On 16/05/2013, at 01:28, Hutton, = Andrew wrote:

 

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

 

 

-----Original = Message-----

=

From: Bernard Aboba [mailto:bernard_aboba@hotmail.co= m]

Sent: 15 May 2013 = 18:20

To: Hutton, Andrew; Chenxin (Xin); = behave@ietf.org;

rtcweb@ietf.org

=

Subject: RE: [rtcweb] FW: New = Version Notification = for

draft-chenxin- = behave-turn-websocket-00.txt

 

Andrew Hutton = said:

When we wrote the draft http://tools.ietf.org/h= tml/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?

 

[BA] In my experience, =  institutions with very = restrictive

<= /blockquote>

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.

<= /blockquote>

After TLS is running, the DPI box = does not have much = information

<= /blockquote>

available to distinguish TURN/TLS = from HTTP over TLS, with = or

without websockets -- and those = things it does have (such = as

packet size) are as likely to = result in an objection to = websocket

transport as TURN/TLS.  So I'm = not sure that draft-chenxin = will

help in that situation = either.

 

 

 

 

_______________________________________________

rtcweb mailing = list

rtcweb@ietf.org

=

https://www.ietf.or= g/mailman/listinfo/rtcweb

 

_______________________________________________

rtcweb mailing = list

rtcweb@ietf.org

=

https://www.ietf.or= g/mailman/listinfo/rtcweb


_______________________________________________
rtcwe= b mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

 

                    =          &n= bsp;           &nb= sp;           &nbs= p;            =      =   _\\|//_

                    =                &n= bsp;           &nb= sp;            =   ( O-O )

  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~<= span lang=3DEN-US>

                  =           &n= bsp;           &nb= sp;           &nbs= p;   Simon Pietro Romano

                     &n= bsp;           &nb= sp;           &nbs= p;  Universita' = di Napoli Federico II

                        &n= bsp;       Computer Engineering = Department 

                     Phone: +39 081 = 7683823 -- Fax: +39 081 7683816

                    =                     =    e-mail: spromano@unina.it

 

           &nbs= p;          <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 

           &nbs= p;          idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.

                       &n= bsp;           &nb= sp;                 =      oooO

  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

           &nbs= p;            = ;            =            =                  \ ( =            (   )

           &nbs= p;            = ;                       =               \_)     =      ) /

                    =                     =                     =            (_/

 

 

 

 

------=_NextPart_000_0001_01CE5688.0ECFE650-- From simon.perreault@viagenie.ca Wed May 22 01:00:12 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E479921F92FB; Wed, 22 May 2013 01:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, NO_RELAYS=-0.001, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc4+dS2r9iUH; Wed, 22 May 2013 01:00:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8598C21F92F5; Wed, 22 May 2013 01:00:11 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B531240409; Wed, 22 May 2013 04:00:10 -0400 (EDT) Message-ID: <519C7B17.8070405@viagenie.ca> Date: Wed, 22 May 2013 10:00:23 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: behave@ietf.org, rtcweb@ietf.org References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> In-Reply-To: <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 08:00:12 -0000 Le 2013-05-22 01:02, Karl Stahl a écrit : > Doesn’t the network administrator that configured the firewall have > a legitimate right to decide what traffic should be on his network? IMHO this is the strongest argument. STUN/TURN/ICE have always been about NAT traversal. Firewall traversal is a completely different beast. It implies a kind of battle between the client and the firewall, where the client implementer is trying to be smarter than the firewall administrator. This is a battle the IETF should not engage in. Let the vendors play that game. Simon From simon.perreault@viagenie.ca Wed May 22 02:30:43 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA5421F9640; Wed, 22 May 2013 02:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, NO_RELAYS=-0.001, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbBkohnjdwa0; Wed, 22 May 2013 02:30:43 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CDA0A21F963C; Wed, 22 May 2013 02:30:42 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 529C747143; Wed, 22 May 2013 05:30:41 -0400 (EDT) Message-ID: <519C904B.2040305@viagenie.ca> Date: Wed, 22 May 2013 11:30:51 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Karl Stahl References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> In-Reply-To: <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 09:30:44 -0000 Le 2013-05-22 11:04, Karl Stahl a écrit : >> Firewall traversal is a completely different beast. > > Not really. There are always firewall functions included in "a NAT" (e.g. > open for traffic from inside to outside and you can then get traffic back > the same path - with some timeout), even if the RFCs only call the box "a > NAT". I prefer to say NAT/Firewall. You're focusing on the technical aspect. The difference I'm considering is not technical. NAT traversal is performed with the agreement of everyone involved, whereas firewall traversal is a battle between the client implementer and the firewall administrator. There's also a potential arms race: firewalls will evolve with the ability to block whatever we standardize, so we will need a newer traversal method, which firewalls will end up blocking as well, etc. etc. etc. We don't want to play that game. NAT traversal: ok Firewall traversal: not for the IETF Simon From karl.stahl@intertex.se Wed May 22 02:05:45 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EF421F8FDB; Wed, 22 May 2013 02:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.985 X-Spam-Level: X-Spam-Status: No, score=0.985 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNJ7jOfUbfpq; Wed, 22 May 2013 02:05:40 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id A0F2621F8E8E; Wed, 22 May 2013 02:05:36 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305221104535380; Wed, 22 May 2013 11:04:53 +0200 From: "Karl Stahl" To: "'Simon Perreault'" , , References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> In-Reply-To: <519C7B17.8070405@viagenie.ca> Date: Wed, 22 May 2013 11:04:34 +0200 Message-ID: <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5Wwm4Iz5ivH6XVS8ew4EYtZaoshgABmkjA Content-Language: sv X-Mailman-Approved-At: Wed, 22 May 2013 09:27:19 -0700 Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 09:05:45 -0000 > Firewall traversal is a completely different beast. Not really. There are always firewall functions included in "a NAT" = (e.g. open for traffic from inside to outside and you can then get traffic = back the same path - with some timeout), even if the RFCs only call the box = "a NAT". I prefer to say NAT/Firewall. ICE/TURN/STUN handles both the NAT and firewall issues to a limit. And the drafts behave-turn-websocket and other about tunneling through http(s) ports are an attempt to extend the limit where the firewall = function (not NAT) is blocking RTCweb (in this case). Actually I think ICE/TURN/STUN even works with a firewall that does not = have NAT enabled at all (as long as UDP ports from inside to outside are open = to use).=20 Having said that, I of course agree that IETF should not extend TURN = with tunneling to pass through a restrictive firewall. /Karl =20 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Simon Perreault Skickat: den 22 maj 2013 10:00 Till: behave@ietf.org; rtcweb@ietf.org =C4mne: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Le 2013-05-22 01:02, Karl Stahl a =E9crit : > Doesn=92t the network administrator that configured the firewall have = a=20 > legitimate right to decide what traffic should be on his network? IMHO this is the strongest argument. STUN/TURN/ICE have always been about NAT traversal. Firewall traversal = is a completely different beast. It implies a kind of battle between the = client and the firewall, where the client implementer is trying to be smarter = than the firewall administrator. This is a battle the IETF should not engage = in. Let the vendors play that game. Simon _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Thu May 23 06:09:01 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2298421F93B1; Thu, 23 May 2013 06:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuWam1ftClVd; Thu, 23 May 2013 06:08:57 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 421F121F93BC; Thu, 23 May 2013 06:08:55 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 481C41EB8648; Thu, 23 May 2013 15:08:54 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Thu, 23 May 2013 15:08:54 +0200 From: "Hutton, Andrew" To: Simon Perreault , Karl Stahl Thread-Topic: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVs8PvK/QKOM3AUmVgv4HMJ4KjZkSvTfQ Date: Thu, 23 May 2013 13:08:53 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115A0F16@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> In-Reply-To: <519C904B.2040305@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 13:09:01 -0000 At least with regard to draft-hutton-rtcweb-nat-firewall-considerations we = are not attempting to enter or add to any existing arms race between client= s and firewalls. We are only describing how to use existing IETF protocols which already ext= ensively discuss firewall traversal (E.g. TURN / RFC 5766) to meet the RTCW= EB requirements in this area which have existed in http://tools.ietf.org/ht= ml/draft-ietf-rtcweb-use-cases-and-requirements-10 for almost two years now= . Of course if a network administer wants to block RTCWEB media they should b= e able to so and nobody is I believe suggesting that we try to prevent this= . Regards Andy > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: 22 May 2013 10:31 > To: Karl Stahl > Cc: rtcweb@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification > for draft-chenxin-behave-turn-websocket-00.txt >=20 > Le 2013-05-22 11:04, Karl Stahl a =E9crit : > >> Firewall traversal is a completely different beast. > > > > Not really. There are always firewall functions included in "a NAT" > (e.g. > > open for traffic from inside to outside and you can then get traffic > back > > the same path - with some timeout), even if the RFCs only call the > box "a > > NAT". I prefer to say NAT/Firewall. >=20 > You're focusing on the technical aspect. The difference I'm considering > is not technical. >=20 > NAT traversal is performed with the agreement of everyone involved, > whereas firewall traversal is a battle between the client implementer > and the firewall administrator. There's also a potential arms race: > firewalls will evolve with the ability to block whatever we > standardize, > so we will need a newer traversal method, which firewalls will end up > blocking as well, etc. etc. etc. We don't want to play that game. >=20 > NAT traversal: ok > Firewall traversal: not for the IETF >=20 > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From hangzhou.chenxin@huawei.com Thu May 23 19:26:38 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EB721F93E9; Thu, 23 May 2013 19:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.027 X-Spam-Level: X-Spam-Status: No, score=-5.027 tagged_above=-999 required=5 tests=[AWL=-1.571, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv45bbbPSdx2; Thu, 23 May 2013 19:26:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B36A321F93ED; Thu, 23 May 2013 19:26:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATC27475; Fri, 24 May 2013 02:26:30 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 03:26:12 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 03:26:25 +0100 Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.68]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.007; Fri, 24 May 2013 10:26:22 +0800 From: "Chenxin (Xin)" To: Simon Perreault , Karl Stahl Thread-Topic: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVs8m6PhKpPzBWESvuGMiUrIKUZkTliFQ Date: Fri, 24 May 2013 02:26:22 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> In-Reply-To: <519C904B.2040305@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.129] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 02:26:38 -0000 ICAgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBub3QgdHJ5IHRvIGJhdHRsZSB3aXRoIG5ldHdvcmsg YWRtaW5pc3RyYXRvciwgYW5kIHdlIGFyZSBub3QgZG9pbmcgdGhhdC4gV2UganVzdCBzdXBwbHkg c29tZSB0ZWNobmljYWwgdG9vbHMgdG8gcnRjd2ViIGltcGxlbWVudGVyLCB0byBtYWtlIHRoZSB1 c2VycyBjb3VsZCBnZXQgYmVuZWZpdCBhbmQgY29udmVuaWVuY2Ugd2hlbiB1c2luZyBydGN3ZWIu IEZhbGxiYWNrIG1ldGhvZHMgYW5kIHByb3Bvc2FscyBhcmUgZm9yIHRoaXMgcHVycG9zZS4gIFdl IGNvdWxkIG5vdCBkZWNpZGUgdGhhdCBob3cgd2lsbCBhIGtpbmQgb2YgdGVjaG5pcXVlIGJlIHVz ZWQuIEV2ZXJ5IHRlY2huaXF1ZSBjb3VsZCBiZSB1c2VkIGluIGEgZ29vZCB3YXkgYW5kIGEgYmFk IHdheS4gIEkgYmVsaWV2ZSB0aGF0IHJ0Y3dlYiBpcyBhIGdvb2QgYW5kIHRydXN0d29ydGh5IHRl Y2huaXF1ZSB3aGljaCBpcyBkaWZmZXJlbnQgd2l0aCB0aGUgc29tZSBoYXJtZnVsIHRoaW5ncyB3 aGljaCBzaG91bGQgYmUgYmxvY2tlZCBieSB0aGUgYWRtaW5pc3RlcnMuIFNvIGxldCB1cyBiYWNr IHRvIHRoZSB0ZWNobmljYWwgYXNwZWN0OiBzaG91bGQgd2UgbmVlZCB0byBzdXBwb3J0IGEgZmFs bGJhY2sgbWV0aG9kIGluIHJ0Y3dlYiBub3c/IFdoaWNoIG9uZSBzaG91bGQgd2Ugc3VwcG9ydCB0 byBNVEk/IFdoaWNoIG9uZSBzaG91bGQgd2Ugc3VwcG9ydCB0byBiZSBhIG9wdGlvbj8gSSB0aGlu ayBub3cgdGhlcmUgaXMgdGhyZWUgbWV0aG9kIHRvIHNvbHZlIHRoZSBmYWxsYmFjayByZXF1aXJl bWVudKO6VFVSTi9UTFMsIEhUVFAgY2hhbm5lbCAsIFRVUk4vV1Mgb3IgSFRUUC4gSSBhbSB3aWxs aW5nIHRvIHdyaXRlIGEgbWFpbCB0aGVzZSBkYXlzIHRvIG1ha2UgYSBzaW1wbGUgY29uY2x1c2lv biBhbmQgY29tcGFyaXNvbiBiZXR3ZWVuIHRoZXNlIG1ldGhvZHMsIHdoaWNoIHdpbGwgcHJvdmlk ZSBhIG1hdGVyaWFsIHRvIFdHIGZvciBmdXR1cmUgZGlzY3Vzc2lvbiBhbmQgZGVjaXNpb24uDQoN CkJlc3QgUmVnYXJkcywNCiAgICAgWGluIA0KDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPlNpbW9uIFBlcnJlYXVsdA0KPlNlbnQ6IFdlZG5lc2Rh eSwgTWF5IDIyLCAyMDEzIDU6MzEgUE0NCj5UbzogS2FybCBTdGFobA0KPkNjOiBydGN3ZWJAaWV0 Zi5vcmc7IGJlaGF2ZUBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcnRjd2ViXSBbQkVIQVZFXSBX aHk/IFF1YWxpdHkhIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC1jaGVueGlu LWJlaGF2ZS10dXJuLXdlYnNvY2tldC0wMC50eHQNCj4NCj5MZSAyMDEzLTA1LTIyIDExOjA0LCBL YXJsIFN0YWhsIGEgqKZjcml0IDoNCj4+PiBGaXJld2FsbCB0cmF2ZXJzYWwgaXMgYSBjb21wbGV0 ZWx5IGRpZmZlcmVudCBiZWFzdC4NCj4+DQo+PiBOb3QgcmVhbGx5LiBUaGVyZSBhcmUgYWx3YXlz IGZpcmV3YWxsIGZ1bmN0aW9ucyBpbmNsdWRlZCBpbiAiYSBOQVQiIChlLmcuDQo+PiBvcGVuIGZv ciB0cmFmZmljIGZyb20gaW5zaWRlIHRvIG91dHNpZGUgYW5kIHlvdSBjYW4gdGhlbiBnZXQgdHJh ZmZpYyBiYWNrDQo+PiB0aGUgc2FtZSBwYXRoIC0gd2l0aCBzb21lIHRpbWVvdXQpLCBldmVuIGlm IHRoZSBSRkNzIG9ubHkgY2FsbCB0aGUgYm94ICJhDQo+PiBOQVQiLiBJIHByZWZlciB0byBzYXkg TkFUL0ZpcmV3YWxsLg0KPg0KPllvdSdyZSBmb2N1c2luZyBvbiB0aGUgdGVjaG5pY2FsIGFzcGVj dC4gVGhlIGRpZmZlcmVuY2UgSSdtIGNvbnNpZGVyaW5nDQo+aXMgbm90IHRlY2huaWNhbC4NCj4N Cj5OQVQgdHJhdmVyc2FsIGlzIHBlcmZvcm1lZCB3aXRoIHRoZSBhZ3JlZW1lbnQgb2YgZXZlcnlv bmUgaW52b2x2ZWQsDQo+d2hlcmVhcyBmaXJld2FsbCB0cmF2ZXJzYWwgaXMgYSBiYXR0bGUgYmV0 d2VlbiB0aGUgY2xpZW50IGltcGxlbWVudGVyDQo+YW5kIHRoZSBmaXJld2FsbCBhZG1pbmlzdHJh dG9yLiBUaGVyZSdzIGFsc28gYSBwb3RlbnRpYWwgYXJtcyByYWNlOg0KPmZpcmV3YWxscyB3aWxs IGV2b2x2ZSB3aXRoIHRoZSBhYmlsaXR5IHRvIGJsb2NrIHdoYXRldmVyIHdlIHN0YW5kYXJkaXpl LA0KPnNvIHdlIHdpbGwgbmVlZCBhIG5ld2VyIHRyYXZlcnNhbCBtZXRob2QsIHdoaWNoIGZpcmV3 YWxscyB3aWxsIGVuZCB1cA0KPmJsb2NraW5nIGFzIHdlbGwsIGV0Yy4gZXRjLiBldGMuIFdlIGRv bid0IHdhbnQgdG8gcGxheSB0aGF0IGdhbWUuDQo+DQo+TkFUIHRyYXZlcnNhbDogb2sNCj5GaXJl d2FsbCB0cmF2ZXJzYWw6IG5vdCBmb3IgdGhlIElFVEYNCj4NCj5TaW1vbg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+cnRjd2ViIG1haWxpbmcgbGlz dA0KPnJ0Y3dlYkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViDQo= From bernard_aboba@hotmail.com Thu May 23 23:36:49 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9621F8F83; Thu, 23 May 2013 23:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.743 X-Spam-Level: X-Spam-Status: No, score=-101.743 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, PLING_QUERY=1.39, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-BXT7VBNv11; Thu, 23 May 2013 23:36:44 -0700 (PDT) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by ietfa.amsl.com (Postfix) with ESMTP id 489B621F8C23; Thu, 23 May 2013 23:36:44 -0700 (PDT) Received: from BLU405-EAS59 ([65.55.111.73]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 May 2013 23:36:43 -0700 X-EIP: [OhkgpYU1LN0YWREBbomot1FY+n/nOFNd] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> Date: Fri, 24 May 2013 07:36:41 +0100 To: X-OriginalArrivalTime: 24 May 2013 06:36:43.0099 (UTC) FILETIME=[0DFEEAB0:01CE5849] Cc: "behave@ietf.org" , Karl Stahl Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 06:36:49 -0000 SSBkb24ndCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBsdW1wIFRVUk4gZnVuY3Rpb25hbGl0eSAo ZS5nLiBUVVJOIG92ZXIgVENQLCBUTFMgb3IgV1MpIGluIHRoZSBzYW1lIGJ1Y2tldCBhcyB0cmFu c3BvcnQgb3ZlciBIVFRQL0hUVFBTIG9yIFdTLCBzaW5jZSB0aGUgZm9ybWVyIGludm9sdmVzIHRo ZSBQZWVyQ29ubmVjdGlvbiBBUEkgYnV0IHRoZSBsYXR0ZXIgbmVlZCBub3QuIA0KDQpJZiBJQ0Ug ZmFpbHMsIGFuIGFwcGxpY2F0aW9uIGNhbiB0cnkgYWx0ZXJuYXRpdmVzLiBBcyBsb25nIGFzIHRo b3NlIGFsdGVybmF0aXZlcyBkb24ndCBpbnZvbHZlIHBlZXIgdG8gcGVlciB0cmFuc3BvcnQgb2Yg bWVkaWEgb3ZlciBodHRwL2h0dHBzIG9yIFdTLCBpdCBpc24ndCBjbGVhciB0byBtZSB0aGF0IHdl IG5lZWQgYSBzdGFuZGFyZCBlbmNhcHN1bGF0aW9uLiBBbmQgaWYgd2UgYXJlIHRhbGtpbmcgYWJv dXQgcGVlci10by1wZWVyIHRoZW4gdGhpcyBpbXBsaWVzIGFuIGh0dHAvaHR0cHMgb3IgV1Mgc2Vy dmVyIGluIHRoZSBicm93c2VyLCB3aGljaCBzZWVtcyBsaWtlIGl0IGlzIG91dCBvZiBzY29wZSwg YXQgbGVhc3QgaW4gdGhpcyBkaXNjdXNzaW9uLg0KDQpPbiBNYXkgMjQsIDIwMTMsIGF0IDM6MjYs ICJDaGVueGluIChYaW4pIiA8aGFuZ3pob3UuY2hlbnhpbkBodWF3ZWkuY29tPiB3cm90ZToNCg0K PiAgIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgbm90IHRyeSB0byBiYXR0bGUgd2l0aCBuZXR3b3Jr IGFkbWluaXN0cmF0b3IsIGFuZCB3ZSBhcmUgbm90IGRvaW5nIHRoYXQuIFdlIGp1c3Qgc3VwcGx5 IHNvbWUgdGVjaG5pY2FsIHRvb2xzIHRvIHJ0Y3dlYiBpbXBsZW1lbnRlciwgdG8gbWFrZSB0aGUg dXNlcnMgY291bGQgZ2V0IGJlbmVmaXQgYW5kIGNvbnZlbmllbmNlIHdoZW4gdXNpbmcgcnRjd2Vi LiBGYWxsYmFjayBtZXRob2RzIGFuZCBwcm9wb3NhbHMgYXJlIGZvciB0aGlzIHB1cnBvc2UuICBX ZSBjb3VsZCBub3QgZGVjaWRlIHRoYXQgaG93IHdpbGwgYSBraW5kIG9mIHRlY2huaXF1ZSBiZSB1 c2VkLiBFdmVyeSB0ZWNobmlxdWUgY291bGQgYmUgdXNlZCBpbiBhIGdvb2Qgd2F5IGFuZCBhIGJh ZCB3YXkuICBJIGJlbGlldmUgdGhhdCBydGN3ZWIgaXMgYSBnb29kIGFuZCB0cnVzdHdvcnRoeSB0 ZWNobmlxdWUgd2hpY2ggaXMgZGlmZmVyZW50IHdpdGggdGhlIHNvbWUgaGFybWZ1bCB0aGluZ3Mg d2hpY2ggc2hvdWxkIGJlIGJsb2NrZWQgYnkgdGhlIGFkbWluaXN0ZXJzLiBTbyBsZXQgdXMgYmFj ayB0byB0aGUgdGVjaG5pY2FsIGFzcGVjdDogc2hvdWxkIHdlIG5lZWQgdG8gc3VwcG9ydCBhIGZh bGxiYWNrIG1ldGhvZCBpbiBydGN3ZWIgbm93PyBXaGljaCBvbmUgc2hvdWxkIHdlIHN1cHBvcnQg dG8gTVRJPyBXaGljaCBvbmUgc2hvdWxkIHdlIHN1cHBvcnQgdG8gYmUgYSBvcHRpb24/IEkgdGhp bmsgbm93IHRoZXJlIGlzIHRocmVlIG1ldGhvZCB0byBzb2x2ZSB0aGUgZmFsbGJhY2sgcmVxdWly ZW1lbnTvvJpUVVJOL1RMUywgSFRUUCBjaGFubmVsICwgVFVSTi9XUyBvciBIVFRQLiBJIGFtIHdp bGxpbmcgdG8gd3JpdGUgYSBtYWlsIHRoZXNlIGRheXMgdG8gbWFrZSBhIHNpbXBsZSBjb25jbHVz aW9uIGFuZCBjb21wYXJpc29uIGJldHdlZW4gdGhlc2UgbWV0aG9kcywgd2hpY2ggd2lsbCBwcm92 aWRlIGEgbWF0ZXJpYWwgdG8gV0cgZm9yIGZ1dHVyZSBkaXNjdXNzaW9uIGFuZCBkZWNpc2lvbi4N Cj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gICAgIFhpbiANCj4gDQo+IA0KPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gU2ltb24gUGVycmVhdWx0 DQo+PiBTZW50OiBXZWRuZXNkYXksIE1heSAyMiwgMjAxMyA1OjMxIFBNDQo+PiBUbzogS2FybCBT dGFobA0KPj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnDQo+PiBTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gW0JFSEFWRV0gV2h5PyBRdWFsaXR5ISBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDQo+PiBkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldC0wMC50eHQN Cj4+IA0KPj4gTGUgMjAxMy0wNS0yMiAxMTowNCwgS2FybCBTdGFobCBhIMOpY3JpdCA6DQo+Pj4+ IEZpcmV3YWxsIHRyYXZlcnNhbCBpcyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGJlYXN0Lg0KPj4+ IA0KPj4+IE5vdCByZWFsbHkuIFRoZXJlIGFyZSBhbHdheXMgZmlyZXdhbGwgZnVuY3Rpb25zIGlu Y2x1ZGVkIGluICJhIE5BVCIgKGUuZy4NCj4+PiBvcGVuIGZvciB0cmFmZmljIGZyb20gaW5zaWRl IHRvIG91dHNpZGUgYW5kIHlvdSBjYW4gdGhlbiBnZXQgdHJhZmZpYyBiYWNrDQo+Pj4gdGhlIHNh bWUgcGF0aCAtIHdpdGggc29tZSB0aW1lb3V0KSwgZXZlbiBpZiB0aGUgUkZDcyBvbmx5IGNhbGwg dGhlIGJveCAiYQ0KPj4+IE5BVCIuIEkgcHJlZmVyIHRvIHNheSBOQVQvRmlyZXdhbGwuDQo+PiAN Cj4+IFlvdSdyZSBmb2N1c2luZyBvbiB0aGUgdGVjaG5pY2FsIGFzcGVjdC4gVGhlIGRpZmZlcmVu Y2UgSSdtIGNvbnNpZGVyaW5nDQo+PiBpcyBub3QgdGVjaG5pY2FsLg0KPj4gDQo+PiBOQVQgdHJh dmVyc2FsIGlzIHBlcmZvcm1lZCB3aXRoIHRoZSBhZ3JlZW1lbnQgb2YgZXZlcnlvbmUgaW52b2x2 ZWQsDQo+PiB3aGVyZWFzIGZpcmV3YWxsIHRyYXZlcnNhbCBpcyBhIGJhdHRsZSBiZXR3ZWVuIHRo ZSBjbGllbnQgaW1wbGVtZW50ZXINCj4+IGFuZCB0aGUgZmlyZXdhbGwgYWRtaW5pc3RyYXRvci4g VGhlcmUncyBhbHNvIGEgcG90ZW50aWFsIGFybXMgcmFjZToNCj4+IGZpcmV3YWxscyB3aWxsIGV2 b2x2ZSB3aXRoIHRoZSBhYmlsaXR5IHRvIGJsb2NrIHdoYXRldmVyIHdlIHN0YW5kYXJkaXplLA0K Pj4gc28gd2Ugd2lsbCBuZWVkIGEgbmV3ZXIgdHJhdmVyc2FsIG1ldGhvZCwgd2hpY2ggZmlyZXdh bGxzIHdpbGwgZW5kIHVwDQo+PiBibG9ja2luZyBhcyB3ZWxsLCBldGMuIGV0Yy4gZXRjLiBXZSBk b24ndCB3YW50IHRvIHBsYXkgdGhhdCBnYW1lLg0KPj4gDQo+PiBOQVQgdHJhdmVyc2FsOiBvaw0K Pj4gRmlyZXdhbGwgdHJhdmVyc2FsOiBub3QgZm9yIHRoZSBJRVRGDQo+PiANCj4+IFNpbW9uDQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcnRj d2ViIG1haWxpbmcgbGlzdA0KPj4gcnRjd2ViQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From simon.perreault@viagenie.ca Fri May 24 04:19:48 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDFF21F8717; Fri, 24 May 2013 04:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, NO_RELAYS=-0.001, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n4ugHl09mBS; Fri, 24 May 2013 04:19:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1091D21F86DD; Fri, 24 May 2013 04:19:48 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2C5B8403D9; Fri, 24 May 2013 07:19:47 -0400 (EDT) Message-ID: <519F4CDF.3090005@viagenie.ca> Date: Fri, 24 May 2013 13:19:59 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Matthew Kaufman (SKYPE)" References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se>, <519C7B17.8070405@viagenie.ca> <2A495B69-DEFE-4B6B-A80D-9C2263F9106D@skype.net> In-Reply-To: <2A495B69-DEFE-4B6B-A80D-9C2263F9106D@skype.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 11:19:48 -0000 Le 2013-05-24 12:19, Matthew Kaufman (SKYPE) a écrit : > (Channeling Randy Bush for a moment)... I strongly encourage my competitors to not engage in this battle. It's not about engaging or not, it's about standardizing. In an arms race, there no point to standardizing your weapons du jour. As a framework, ICE still allows whatever form of firewall traversal that vendors may think of. Simon > On May 22, 2013, at 9:00 AM, "Simon Perreault" wrote: > >> Le 2013-05-22 01:02, Karl Stahl a écrit : >>> Doesn’t the network administrator that configured the firewall have >>> a legitimate right to decide what traffic should be on his network? >> >> IMHO this is the strongest argument. >> >> STUN/TURN/ICE have always been about NAT traversal. Firewall traversal >> is a completely different beast. It implies a kind of battle between the >> client and the firewall, where the client implementer is trying to be >> smarter than the firewall administrator. This is a battle the IETF >> should not engage in. Let the vendors play that game. >> >> Simon >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From oej@edvina.net Fri May 24 01:05:10 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9955921F87D1; Fri, 24 May 2013 01:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUEG0PPw7WmK; Fri, 24 May 2013 01:05:09 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 02B1921F89EB; Fri, 24 May 2013 01:05:06 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4EBD593C2A1; Fri, 24 May 2013 08:05:03 +0000 (UTC) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> Date: Fri, 24 May 2013 10:05:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <152D6DF0-A795-4D83-B35B-9CC2DD2EFEDF@edvina.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> To: "Chenxin (Xin)" X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Fri, 24 May 2013 08:36:13 -0700 Cc: "rtcweb@ietf.org" , "Olle E. Johansson" , "behave@ietf.org" , Karl Stahl Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 08:05:10 -0000 I do agree with SImon here. Firewall traversal in the sense "let's = bypass the firewall admin policys" is not something for the IETF, Why not focus on discussing best behaviour for firewalls, so we don't = end up in the mess we have in SIP with most firewalls breaking communication. We also have huge problems with = firewall/CPE/routers that are starting to implement broken SIP application layer gateways. Maybe "run a TURN server on the firewall" is a good recommendation to = start with. /O 24 maj 2013 kl. 04:26 skrev "Chenxin (Xin)" = : > I agree that we should not try to battle with network administrator, = and we are not doing that. We just supply some technical tools to rtcweb = implementer, to make the users could get benefit and convenience when = using rtcweb. Fallback methods and proposals are for this purpose. We = could not decide that how will a kind of technique be used. Every = technique could be used in a good way and a bad way. I believe that = rtcweb is a good and trustworthy technique which is different with the = some harmful things which should be blocked by the administers. So let = us back to the technical aspect: should we need to support a fallback = method in rtcweb now? Which one should we support to MTI? Which one = should we support to be a option? I think now there is three method to = solve the fallback requirement=A3=BATURN/TLS, HTTP channel , TURN/WS or = HTTP. I am willing to write a mail these days to make a simple = conclusion and comparison between these methods, which will provide a = material to WG for future discussion and decision. >=20 > Best Regards, > Xin=20 >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of >> Simon Perreault >> Sent: Wednesday, May 22, 2013 5:31 PM >> To: Karl Stahl >> Cc: rtcweb@ietf.org; behave@ietf.org >> Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification = for >> draft-chenxin-behave-turn-websocket-00.txt >>=20 >> Le 2013-05-22 11:04, Karl Stahl a =A8=A6crit : >>>> Firewall traversal is a completely different beast. >>>=20 >>> Not really. There are always firewall functions included in "a NAT" = (e.g. >>> open for traffic from inside to outside and you can then get traffic = back >>> the same path - with some timeout), even if the RFCs only call the = box "a >>> NAT". I prefer to say NAT/Firewall. >>=20 >> You're focusing on the technical aspect. The difference I'm = considering >> is not technical. >>=20 >> NAT traversal is performed with the agreement of everyone involved, >> whereas firewall traversal is a battle between the client implementer >> and the firewall administrator. There's also a potential arms race: >> firewalls will evolve with the ability to block whatever we = standardize, >> so we will need a newer traversal method, which firewalls will end up >> blocking as well, etc. etc. etc. We don't want to play that game. >>=20 >> NAT traversal: ok >> Firewall traversal: not for the IETF >>=20 >> Simon >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From karl.stahl@intertex.se Fri May 24 01:51:34 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97F221F91B8; Fri, 24 May 2013 01:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.613 X-Spam-Level: X-Spam-Status: No, score=0.613 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXOroNTqMu4u; Fri, 24 May 2013 01:51:30 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 57D4321F93DA; Fri, 24 May 2013 01:51:24 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305241051070962; Fri, 24 May 2013 10:51:07 +0200 From: "Karl Stahl" To: "'Hutton, Andrew'" , "'Simon Perreault'" References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9F33F40F6F2CD847824537F3C4E37DDF115A0F16@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF115A0F16@MCHP04MSX.global-ad.net> Date: Fri, 24 May 2013 10:51:05 +0200 Message-ID: <02ca01ce585b$d3eff630$7bcfe290$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOVs8PvK/QKOM3AUmVgv4HMJ4KjZkSvTfQgAEufLA= Content-Language: sv X-Mailman-Approved-At: Fri, 24 May 2013 08:36:13 -0700 Cc: behave@ietf.org, rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 08:51:35 -0000 I read the two drafts referenced. http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 0=20 looks OK both regarding not fighting firewall restrictions, and not introducing quality degradation. The enterprise use case with a restrictive firewall not allowing UDP to = the Internet is described under 4.2.5.1 and suggests the use of a local TURN server on the LAN that "enabling cases where peers are both on the = internal side to connect without the traffic leaving the internal network." I don't = see that it pin points how rtcweb outside LAN - to the Internet - would = happen, but an additional firewall/router could be added between the LAN TURN = server and the Internet to handle that.=20 That would result in a separate pipe for rtcweb media - that the network administer himself arranges! And he has even the possibility to arrange better quality (prioritizing etc.) on that pipe than via the ordinary firewall where rtcweb remains blocked. Both http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideration= s-0 0 and=20 http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-00.txt=20 describe ways of tunneling RTP traffic trough HTTP(S) TCP ports 80(443) = that are open in the firewall for surfing usage.=20 Whether that tunneling has an extra framing from TURN/TCP, TURN/TLS or = WS, does not affect the discussion about trying to get rtcweb media through = a firewall that is configured to only allow surfing. All of these fallbacks also results in RTP over TCP (instead of UDP as usual) and therefore degrades quality due to the error correcting retransmission. There is no way around that. (I believe the TURN/TLS is = only TCP half of the way - between the client and TURN server, but the = firewall being penetrated is often also the congestion point - so not much improvement quality wise.)=20 So, even if pushing RTC through the surf ports would not be considered fighting the firewall restriction (How could it?), do we really want a quality degraded fallback channel for rtcweb anyway? I'd say we should encourage better quality networks to really step up from POTS quality = voice now that we have chance. /Karl -----Ursprungligt meddelande----- Fr=E5n: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Skickat: den 23 maj 2013 15:09 Till: Simon Perreault; Karl Stahl Kopia: rtcweb@ietf.org; behave@ietf.org =C4mne: RE: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt At least with regard to draft-hutton-rtcweb-nat-firewall-considerations = we are not attempting to enter or add to any existing arms race between = clients and firewalls. We are only describing how to use existing IETF protocols which already extensively discuss firewall traversal (E.g. TURN / RFC 5766) to meet = the RTCWEB requirements in this area which have existed in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 0 for almost two years now. Of course if a network administer wants to block RTCWEB media they = should be able to so and nobody is I believe suggesting that we try to prevent = this. Regards Andy > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On=20 > Behalf Of Simon Perreault > Sent: 22 May 2013 10:31 > To: Karl Stahl > Cc: rtcweb@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification=20 > for draft-chenxin-behave-turn-websocket-00.txt >=20 > Le 2013-05-22 11:04, Karl Stahl a =E9crit : > >> Firewall traversal is a completely different beast. > > > > Not really. There are always firewall functions included in "a NAT" > (e.g. > > open for traffic from inside to outside and you can then get traffic > back > > the same path - with some timeout), even if the RFCs only call the > box "a > > NAT". I prefer to say NAT/Firewall. >=20 > You're focusing on the technical aspect. The difference I'm=20 > considering is not technical. >=20 > NAT traversal is performed with the agreement of everyone involved,=20 > whereas firewall traversal is a battle between the client implementer=20 > and the firewall administrator. There's also a potential arms race: > firewalls will evolve with the ability to block whatever we=20 > standardize, so we will need a newer traversal method, which firewalls = > will end up blocking as well, etc. etc. etc. We don't want to play=20 > that game. >=20 > NAT traversal: ok > Firewall traversal: not for the IETF >=20 > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From karl.stahl@intertex.se Fri May 24 01:58:45 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0F21F967F; Fri, 24 May 2013 01:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntDo-g0iolCJ; Fri, 24 May 2013 01:58:40 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0E24E21F9676; Fri, 24 May 2013 01:58:39 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305241058222555; Fri, 24 May 2013 10:58:22 +0200 From: "Karl Stahl" To: "'Chenxin \(Xin\)'" , "'Simon Perreault'" References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> Date: Fri, 24 May 2013 10:58:20 +0200 Message-ID: <02cb01ce585c$d70aae40$85200ac0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOVs8m6PhKpPzBWESvuGMiUrIKUZkTliFQgABzLfA= Content-Language: sv X-Mailman-Approved-At: Fri, 24 May 2013 08:36:13 -0700 Cc: behave@ietf.org, rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 08:58:45 -0000 Leaving my quality concern of a such fallback channel for a moment... How do you mean that tunneling rtcweb media through a firewall that is = configured to only allow surfing is not to "battle with network = administrator"? Isn't it exactly just that, whatever technique we chose to it with? /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]=20 Skickat: den 24 maj 2013 04:26 Till: Simon Perreault; Karl Stahl Kopia: rtcweb@ietf.org; behave@ietf.org =C3=84mne: RE: [rtcweb] [BEHAVE] Why? Quality! New Version Notification = for draft-chenxin-behave-turn-websocket-00.txt I agree that we should not try to battle with network administrator, = and we are not doing that. We just supply some technical tools to rtcweb = implementer, to make the users could get benefit and convenience when = using rtcweb. Fallback methods and proposals are for this purpose. We = could not decide that how will a kind of technique be used. Every = technique could be used in a good way and a bad way. I believe that = rtcweb is a good and trustworthy technique which is different with the = some harmful things which should be blocked by the administers. So let = us back to the technical aspect: should we need to support a fallback = method in rtcweb now? Which one should we support to MTI? Which one = should we support to be a option? I think now there is three method to = solve the fallback requirement=EF=BC=9ATURN/TLS, HTTP channel , TURN/WS = or HTTP. I am willing to write a mail these days to make a simple = conclusion and comparison between these methods, which will provide a = material to WG for future discussion and decision. Best Regards, Xin=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >Behalf Of Simon Perreault >Sent: Wednesday, May 22, 2013 5:31 PM >To: Karl Stahl >Cc: rtcweb@ietf.org; behave@ietf.org >Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification=20 >for draft-chenxin-behave-turn-websocket-00.txt > >Le 2013-05-22 11:04, Karl Stahl a =C3=A9crit : >>> Firewall traversal is a completely different beast. >> >> Not really. There are always firewall functions included in "a NAT" = (e.g. >> open for traffic from inside to outside and you can then get traffic=20 >> back the same path - with some timeout), even if the RFCs only call=20 >> the box "a NAT". I prefer to say NAT/Firewall. > >You're focusing on the technical aspect. The difference I'm considering = >is not technical. > >NAT traversal is performed with the agreement of everyone involved,=20 >whereas firewall traversal is a battle between the client implementer=20 >and the firewall administrator. There's also a potential arms race: >firewalls will evolve with the ability to block whatever we=20 >standardize, so we will need a newer traversal method, which firewalls=20 >will end up blocking as well, etc. etc. etc. We don't want to play that = game. > >NAT traversal: ok >Firewall traversal: not for the IETF > >Simon >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From karl.stahl@intertex.se Fri May 24 02:07:18 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB5421F95E9; Fri, 24 May 2013 02:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.426 X-Spam-Level: X-Spam-Status: No, score=0.426 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igHE1BYhAZ4y; Fri, 24 May 2013 02:07:13 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id 280EF21F95A0; Fri, 24 May 2013 02:07:12 -0700 (PDT) Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305241106574163; Fri, 24 May 2013 11:06:57 +0200 From: "Karl Stahl" To: "'Olle E. Johansson'" , "'Chenxin \(Xin\)'" References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca> <9E34D50A21D1D1489134B4D770CE039753363F1F@szxeml538-mbx.china.huawei.com> <152D6DF0-A795-4D83-B35B-9CC2DD2EFEDF@edvina.net> In-Reply-To: <152D6DF0-A795-4D83-B35B-9CC2DD2EFEDF@edvina.net> Date: Fri, 24 May 2013 11:06:56 +0200 Message-ID: <02cc01ce585e$0a778c20$1f66a460$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5YVWbFzUJU+Oo+T5OV79XHpFvSegAB3NOA Content-Language: sv X-Mailman-Approved-At: Fri, 24 May 2013 08:36:13 -0700 Cc: behave@ietf.org, rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:07:18 -0000 > Maybe "run a TURN server on the firewall" is a good recommendation to = start with. That would include be the combination of the LAN TURN server and the = additional firewall/router I just mentioned in another response: "http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-= 10 looks OK both regarding not fighting firewall restrictions, and not = introducing quality degradation. The enterprise use case with a restrictive firewall not allowing UDP to = the Internet is described under 4.2.5.1 and suggests the use of a local = TURN server on the LAN that "enabling cases where peers are both on the = internal side to connect without the traffic leaving the internal = network." I don't see that it pin points how rtcweb outside LAN - to the = Internet - would happen, but an additional firewall/router could be = added between the LAN TURN server and the Internet to handle that." And it has the potential to add quality rather than degenerate it. /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: Olle E. Johansson [mailto:oej@edvina.net]=20 Skickat: den 24 maj 2013 10:05 Till: Chenxin (Xin) Kopia: Olle E. Johansson; Simon Perreault; Karl Stahl; behave@ietf.org; = rtcweb@ietf.org =C3=84mne: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification = for draft-chenxin-behave-turn-websocket-00.txt I do agree with SImon here. Firewall traversal in the sense "let's = bypass the firewall admin policys" is not something for the IETF, Why not focus on discussing best behaviour for firewalls, so we don't = end up in the mess we have in SIP with most firewalls breaking = communication. We also have huge problems with firewall/CPE/routers that = are starting to implement broken SIP application layer gateways. Maybe "run a TURN server on the firewall" is a good recommendation to = start with. /O 24 maj 2013 kl. 04:26 skrev "Chenxin (Xin)" = : > I agree that we should not try to battle with network administrator, = and we are not doing that. We just supply some technical tools to rtcweb = implementer, to make the users could get benefit and convenience when = using rtcweb. Fallback methods and proposals are for this purpose. We = could not decide that how will a kind of technique be used. Every = technique could be used in a good way and a bad way. I believe that = rtcweb is a good and trustworthy technique which is different with the = some harmful things which should be blocked by the administers. So let = us back to the technical aspect: should we need to support a fallback = method in rtcweb now? Which one should we support to MTI? Which one = should we support to be a option? I think now there is three method to = solve the fallback requirement=EF=BC=9ATURN/TLS, HTTP channel , TURN/WS = or HTTP. I am willing to write a mail these days to make a simple = conclusion and comparison between these methods, which will provide a = material to WG for future discussion and decision. >=20 > Best Regards, > Xin >=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Simon Perreault >> Sent: Wednesday, May 22, 2013 5:31 PM >> To: Karl Stahl >> Cc: rtcweb@ietf.org; behave@ietf.org >> Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification = >> for draft-chenxin-behave-turn-websocket-00.txt >>=20 >> Le 2013-05-22 11:04, Karl Stahl a =C3=A9crit : >>>> Firewall traversal is a completely different beast. >>>=20 >>> Not really. There are always firewall functions included in "a NAT" = (e.g. >>> open for traffic from inside to outside and you can then get traffic = >>> back the same path - with some timeout), even if the RFCs only call=20 >>> the box "a NAT". I prefer to say NAT/Firewall. >>=20 >> You're focusing on the technical aspect. The difference I'm=20 >> considering is not technical. >>=20 >> NAT traversal is performed with the agreement of everyone involved,=20 >> whereas firewall traversal is a battle between the client implementer = >> and the firewall administrator. There's also a potential arms race: >> firewalls will evolve with the ability to block whatever we=20 >> standardize, so we will need a newer traversal method, which=20 >> firewalls will end up blocking as well, etc. etc. etc. We don't want = to play that game. >>=20 >> NAT traversal: ok >> Firewall traversal: not for the IETF >>=20 >> Simon >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From matthew.kaufman@skype.net Fri May 24 03:20:36 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFECD21F962A; Fri, 24 May 2013 03:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, PLING_QUERY=1.39] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr6qEHsq0q0X; Fri, 24 May 2013 03:20:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1D33C21F9397; Fri, 24 May 2013 03:20:25 -0700 (PDT) Received: from BL2FFO11FD021.protection.gbl (10.173.161.201) by BL2FFO11HUB020.protection.gbl (10.173.160.112) with Microsoft SMTP Server (TLS) id 15.0.698.0; Fri, 24 May 2013 10:20:24 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Fri, 24 May 2013 10:20:23 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.85]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0136.001; Fri, 24 May 2013 10:19:59 +0000 From: "Matthew Kaufman (SKYPE)" To: Simon Perreault Thread-Topic: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOVsJqpl4QZ5A+d0aC0ygnMUkR1pkUIvf7 Date: Fri, 24 May 2013 10:19:58 +0000 Message-ID: <2A495B69-DEFE-4B6B-A80D-9C2263F9106D@skype.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se>, <519C7B17.8070405@viagenie.ca> In-Reply-To: <519C7B17.8070405@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377454002)(51704005)(24454002)(377424003)(77982001)(81542001)(47446002)(47976001)(47736001)(56816002)(81342001)(69226001)(49866001)(50466002)(23746002)(33656001)(74706001)(4396001)(16406001)(54356001)(6806003)(54316002)(46102001)(20776003)(47776003)(74502001)(79102001)(36756003)(63696002)(74366001)(59766001)(31966008)(74876001)(80022001)(76482001)(74662001)(44976003)(50986001)(53806001)(65816001)(51856001)(56776001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB020; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 085634EFF4 X-Mailman-Approved-At: Fri, 24 May 2013 08:36:13 -0700 Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 10:20:36 -0000 (Channeling Randy Bush for a moment)... I strongly encourage my competitors= to not engage in this battle. Matthew Kaufman (Sent from my iPhone) On May 22, 2013, at 9:00 AM, "Simon Perreault" wrote: > Le 2013-05-22 01:02, Karl Stahl a =E9crit : >> Doesn=92t the network administrator that configured the firewall have >> a legitimate right to decide what traffic should be on his network? >=20 > IMHO this is the strongest argument. >=20 > STUN/TURN/ICE have always been about NAT traversal. Firewall traversal > is a completely different beast. It implies a kind of battle between the > client and the firewall, where the client implementer is trying to be > smarter than the firewall administrator. This is a battle the IETF > should not engage in. Let the vendors play that game. >=20 > Simon > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From petithug@acm.org Fri May 24 09:02:34 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A8C21F969D; Fri, 24 May 2013 09:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNynIe1j-gFV; Fri, 24 May 2013 09:02:33 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 824AB21F9615; Fri, 24 May 2013 09:02:32 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:2d:d9af:d9c7:dae0:e111] (unknown [IPv6:2601:9:4bc0:2d:d9af:d9c7:dae0:e111]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id C4FC4204BA; Fri, 24 May 2013 18:02:29 +0200 (CEST) Message-ID: <519F8F13.8020204@acm.org> Date: Fri, 24 May 2013 09:02:27 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Lorenzo Miniero References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> In-Reply-To: <20130520111522.1b7e2eb1@meetecho.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , "rtcweb@ietf.org" , =?UTF-8?B?R3VzdGF2byBHYXJjw61h?= Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 16:02:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/20/2013 02:15 AM, Lorenzo Miniero wrote: > Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo García > ha scritto: > >> I agree that TURN over websockets doesn't solve much more scenarios than >> TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it over >> HTTP that aside of philosophical discussions would be the solution with >> better success rate? Otherwise we will have to continue answering for >> another 10 years "why is this app not working if skype does". >> >> Something like this draft sent some months ago but perhaps for TURN >> instead of direct connections: >> http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt >> > > > When I submitted that draft this summer, I had that exact purpose in mind, > that is taking care of corner edge cases like restrictive proxies and the > like. Of course it was not meant to be a solution, just a way to foster > discussion in that direction. In that discussion I also mentioned some work > we did about this in the past, which in part apparently ended up in > draft-hutton-rtcweb-nat-firewall-considerations: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html > > At the time most people in the ML thought it was either too useless, too > complex or even harmful, considering it could be considered as a "sneaky" > way to circumvent rules added by a network administrator, and so > unacceptable. Anyway, as I said back then, a solution like this doesn't > have to be sneaky, and it could very well be conceived in order to be > admin-friendly rather than have a parrot and a wooden leg. About circumventing rules added by a network administrator, I do think that using TURN over Websocket or HTTP is doing in fact the opposite: It is the only way to obey the wish of the network administrator, as long as you classify Webrtc is a *web* technology and not as a VoIP technology. Think about it this way: An administrator restricting UDP but authorizing HTTP is basically saying: All web applications are fine, and Webrtc being a Web application, it should just work fine, and should not be a collateral damage of restricting UDP. So TURN over Websocket/HTTP should be a mandatory part of Webrtc. Now the administrator should also have access to tools to restrict some classes of web applications, and Webrtc should be one of these classes. But that should not be done as a side-effect of closing the UDP ports. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRn48NAAoJECnERZXWan7Eve4P/3Y1SL2IuHZw6Iqats3ZwXG9 dRxG5JSWEqKbVBgiPNUvXocMu7MbclAB1PC8K++roBDjayqlL9bh2EGmolyLDMLr oloAFLRUmo4Yccj+IkECODbgVowtE9rNl9BudUk4hDk151Z6HLgu8wjAR05aLaM2 9PHnAmp4JZt6BlrOytkUj9yHLsSSCPNqZpYSFFbrCEkURQLZTXlPw0BOtRVoBb8a zBwDVSaW7IdgOuIwq5kbxaITXXrrezCspMesMucVFfp9f0k1AtR3ARjhPj6wAogv WJvtBnJYUDw8fpZplyPmKK8af7jEpfbr5IrkzE5JPrmeCdLElzqb6BSpe+GP6EqH 0QSDZe73HqwMso90VAFPitGnTK91qLk7R3c//W3J0GQ6sSwUYrArjx5sO5uS7N9n 78YIZXoEYgPMfetkGIMJddSRkJxNjQAyi9kmcWyss8CgvqEnWCZbFlnz8I0Eeh+8 tOI4nhyJGVsSKAn1uORGvnrOXID8oTOhXfwh2r4yDQRpu8outqZuSeksSEtOgoYe Jli9boycKkXCilBDHkf+YhY5bqETvDunFyb+O1NQnpIogQOrxucX8Jr9YyAbRxbw xb0qNyMPLpp75jXfgFQ4Cxc+f8Nm7xYG8GKrSKHxiqazo6aOKZ1rxWdv5945iB53 HJsMG1MkVKRwRBgLsM9S =HTew -----END PGP SIGNATURE----- From ssenthil@cisco.com Fri May 24 09:50:06 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114CB21F8C4C for ; Fri, 24 May 2013 09:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+eVsYueites for ; Fri, 24 May 2013 09:50:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3732021F8624 for ; Fri, 24 May 2013 09:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3170; q=dns/txt; s=iport; t=1369414201; x=1370623801; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6w5jFJMttehVWWchouP4DB7z8BMmHz90Hx5xqkMNKZg=; b=TguMwoSwIt5jwor1LY5ArmgHa3QEa+48RLk4ftcVxdRPA9wEU/6SvLfj 54WUIDWgHCH0U0cyTwBBDLVTu4lcyOwzXy99bTs9qtYCXtYoLj94YxwMR DD/uHIfYrcgqseqORzu/1+JtdZtTrvZ5i59jGUtoosgzCIK/ORrvph27x 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgGAEWZn1GtJXG+/2dsb2JhbABagwgwwiqBBhZ0giMBAQEDAQEBAWsLBQ0BCCJLCyUCBA4FCId/Bgy5ewSObDEHgnNhA4hnoBSDD4Im X-IronPort-AV: E=Sophos;i="4.87,736,1363132800"; d="scan'208";a="214680038" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 24 May 2013 16:50:00 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4OGo0gu011309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 16:50:00 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 24 May 2013 11:50:00 -0500 From: "Senthil Sivakumar (ssenthil)" To: "Dan Wing (dwing)" , draft-ietf-behave-ipfix-nat-logging Thread-Topic: [BEHAVE] short review of draft-ietf-behave-ipfix-nat-logging-00 Thread-Index: AQHOVciY51mhPGSAdUOHm3rR5Afi35kUoqUA Date: Fri, 24 May 2013 16:49:59 +0000 Message-ID: In-Reply-To: <4ACE4A37-091D-433A-8112-98E201605046@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.117.198.134] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4B5823A09CCE0544BC236F2357FC9C3A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [BEHAVE] short review of draft-ietf-behave-ipfix-nat-logging-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 16:50:06 -0000 On 5/20/13 10:11 PM, "Dan Wing (dwing)" wrote: >This is a short review of draft-ietf-behave-ipfix-nat-logging-00. I >noticed several things in this document which are similar to my review of >the SYSLOG document. Please be sure to see that review and I'm sure you >will notice some similarities. Ok. Will respond back to the relevant ones in that thread. > >I noticed draft-ietf-behave-ipfix-nat-logging-00 also seems to not >explain the nuances of logging the destination. This not only could >increase log file size, but also impacts the memory of the NAT device and >forces state on otherwise-stateless devices (such as stateless NAT64, >MAP-E, or MAP-T, and others). Not to mention creates a log of user >activity which reduces subscriber privacy. Would add a paragraph explaining the disadvantages satisfy your concerns? I agree with your points on above except forcing state on the stateless device, which I don=B9t understand how logging forces state on a stateless device. Also, note that the destination logging is not mandatory, and we can add text to make destination logging must be turned off by default. > >I see draft-ietf-behave-ipfix-nat-logging-00 also has a 'range step >size', but I am not aware of where 'step size' is explained or discussed >elsewhere. A citation within the document to wherever 'step size' is >explained would be useful. Ok. > >It reads strangely that the Address Binding event described in Section >5.4.8 shows "Mandatory: No" for both IPv4 and IPv6 source addresses -- >surely one or the other needs to be present for this event to make sense, >the text says: That should be read as either one of them is mandatory, but individually neither is. I don=B9t know how to capture that in the table. I can add some text to indicate that either IPv4 or IPv6 source must be present. > This event will be generated when a NAT device binds a local address > with a global address. This binding event happens when the first > packet of the first flow from a host in the private realm. >but I can't tell if, when a brand-new TCP SYN is sent by a client, if >that causes both an Address Binding event and _also_ a "NAT44 BIB create" >event, because the document does not describe a "BIB" or a "Bind entry" >-- if those are well-understood terms, can a citation be added, or >in-place definition be added? Also would benefit from clarity around why >there is a Address Binding event in Section 5.4.8 versus the "BIB create" >events described earlier. For the first syn, an address binding event will happen AND either an NAT44/NAT64 BIB event or NAT44/NAT64 session event will happen. The subsequent SYNs and other packets from the same internal host will not create an address binding event. > >Similar observation as with SYSLOG on security considerations, > need for clarity of the logs, and suchlike (see my SYSLOG review posted >to BEHAVE). Ok, Thanks for the review. Senthil > >-d > > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Fri May 24 10:11:40 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E4321F9631 for ; Fri, 24 May 2013 10:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7SWvN4D9sgs for ; Fri, 24 May 2013 10:11:36 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 956E621F9615 for ; Fri, 24 May 2013 10:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4340; q=dns/txt; s=iport; t=1369415494; x=1370625094; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zno41OMap+WqwLO8k9czSPz7PCuiWWses0YaXDqgtGU=; b=EOThjXQa3pjdlOWTzQe74rG+ldOx6GdpNg57ArYcKlaI+np8ALbB4tHs k1T2OLumF2efUzJd8T3+dvU1y+VQSUrpfGhN0LW6ec8zoa2F4T+pMGlA8 sI6HFTL7CFf/lmWEUq0hgZeZ5U2HrC25QXHaelZPXE2qF96qC3sZ4K2S6 Y=; X-IronPort-AV: E=Sophos;i="4.87,736,1363132800"; d="scan'208";a="79501297" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 24 May 2013 17:11:34 +0000 Received: from [10.32.240.195] ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4OHBXen019170; Fri, 24 May 2013 17:11:33 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Fri, 24 May 2013 10:11:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <004F5A69-001E-4138-A13C-AC37CFD8AA74@cisco.com> References: To: Senthil Sivakumar (ssenthil) X-Mailer: Apple Mail (2.1503) Cc: "" , draft-ietf-behave-ipfix-nat-logging Subject: Re: [BEHAVE] short review of draft-ietf-behave-ipfix-nat-logging-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 17:11:40 -0000 On May 24, 2013, at 9:49 AM, Senthil Sivakumar (ssenthil) = wrote: >=20 >=20 > On 5/20/13 10:11 PM, "Dan Wing (dwing)" wrote: >=20 >> This is a short review of draft-ietf-behave-ipfix-nat-logging-00. I >> noticed several things in this document which are similar to my = review of >> the SYSLOG document. Please be sure to see that review and I'm sure = you >> will notice some similarities. > Ok. Will respond back to the relevant ones in that thread. >>=20 >> I noticed draft-ietf-behave-ipfix-nat-logging-00 also seems to not >> explain the nuances of logging the destination. This not only could >> increase log file size, but also impacts the memory of the NAT device = and >> forces state on otherwise-stateless devices (such as stateless NAT64, >> MAP-E, or MAP-T, and others). Not to mention creates a log of user >> activity which reduces subscriber privacy. >=20 > Would add a paragraph explaining the disadvantages satisfy your = concerns? > I agree with your points on above except forcing state on the = stateless > device, which I don=B9t understand how logging forces state on a = stateless > device. A good example of the problem is a bittorrent client, which makes = connections and transfers data from the same source port to hundreds of = destinations. With TCP, each different destination is clearly indicated = with the SYN bit, which can trigger destination logging. However if the = client is using UDP, there is nothing handy like a SYN indicating "this = is a new connection", so logging will necessarily be every packet, = unless the device maintains state of which destinations it has already = logged. This is not limited to bittorrent; other applications such as = Skype, webrtc, and many games also use UDP in a similar fashion. > Also, note that the destination logging is not mandatory, and we > can add text to make destination logging must be turned off by = default. Yes, understood. >=20 >>=20 >> I see draft-ietf-behave-ipfix-nat-logging-00 also has a 'range step >> size', but I am not aware of where 'step size' is explained or = discussed >> elsewhere. A citation within the document to wherever 'step size' is >> explained would be useful. >=20 > Ok. >>=20 >> It reads strangely that the Address Binding event described in = Section >> 5.4.8 shows "Mandatory: No" for both IPv4 and IPv6 source addresses = -- >> surely one or the other needs to be present for this event to make = sense, >> the text says: >=20 > That should be read as either one of them is mandatory, but = individually > neither is. I don=B9t know how to capture that in the table. I can add = some > text to indicate that either IPv4 or IPv6 source must be present. If it fits, the IPv4 could say "Mandatory for IPv4 binding" and the IPv6 = one could be similar, or use Notes in the table or something. -d >=20 >> This event will be generated when a NAT device binds a local address >> with a global address. This binding event happens when the first >> packet of the first flow from a host in the private realm. >> but I can't tell if, when a brand-new TCP SYN is sent by a client, if >> that causes both an Address Binding event and _also_ a "NAT44 BIB = create" >> event, because the document does not describe a "BIB" or a "Bind = entry" >> -- if those are well-understood terms, can a citation be added, or >> in-place definition be added? Also would benefit from clarity around = why >> there is a Address Binding event in Section 5.4.8 versus the "BIB = create" >> events described earlier. >=20 > For the first syn, an address binding event will happen AND either an > NAT44/NAT64 BIB event or NAT44/NAT64 session event will happen. The > subsequent SYNs and other packets from the same internal host will not > create an address binding event. >=20 >>=20 >> Similar observation as with SYSLOG on security considerations, >> need for clarity of the logs, and suchlike (see my SYSLOG review = posted >> to BEHAVE). >=20 > Ok, Thanks for the review. >=20 > Senthil >>=20 >> -d >>=20 >>=20 >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 From andrew.hutton@siemens-enterprise.com Tue May 28 08:04:01 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A5721F9817; Tue, 28 May 2013 08:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwSjNsIi7EKU; Tue, 28 May 2013 08:03:57 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id ACC2C21F9814; Tue, 28 May 2013 08:03:56 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C2AE91EB8529; Tue, 28 May 2013 17:03:55 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.174]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Tue, 28 May 2013 17:03:55 +0200 From: "Hutton, Andrew" To: Marc Petit-Huguenin , Lorenzo Miniero Thread-Topic: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOWJgguR8PhNxiQUuYi4Iujc603Jkaseag Date: Tue, 28 May 2013 15:03:54 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115B2146@MCHP04MSX.global-ad.net> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <519F8F13.8020204@acm.org> In-Reply-To: <519F8F13.8020204@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "behave@ietf.org" , =?utf-8?B?R3VzdGF2byBHYXJjw61h?= Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 15:04:01 -0000 T246IDI0IE1heSAyMDEzIDE3OjAyIE1hcmMgUGV0aXQtSHVndWVuaW4gV3JvdGU6DQo+IA0KPiBB Ym91dCBjaXJjdW12ZW50aW5nIHJ1bGVzIGFkZGVkIGJ5IGEgbmV0d29yayBhZG1pbmlzdHJhdG9y LCBJIGRvIHRoaW5rDQo+IHRoYXQNCj4gdXNpbmcgVFVSTiBvdmVyIFdlYnNvY2tldCBvciBIVFRQ IGlzIGRvaW5nIGluIGZhY3QgdGhlIG9wcG9zaXRlOiAgSXQgaXMNCj4gdGhlDQo+IG9ubHkgd2F5 IHRvIG9iZXkgdGhlIHdpc2ggb2YgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvciwgYXMgbG9uZyBh cyB5b3UNCj4gY2xhc3NpZnkgV2VicnRjIGlzIGEgKndlYiogdGVjaG5vbG9neSBhbmQgbm90IGFz IGEgVm9JUCB0ZWNobm9sb2d5Lg0KPiANCg0KSSBjZXJ0YWlubHkgYWdyZWUgd2l0aCB0aGlzLiBX RUJSdGMgaXMgYSBuZXcgdGVjaG5vbG9neSBlbWJlZGRlZCBpbiB0aGUgYnJvd3NlciBmb3Igd2Vi IGFwcGxpY2F0aW9ucyB0byB1c2Ugc28gd2UgbmVlZCB0byBkZWZpbmUgdGhlIG1lY2hhbmlzbSB1 c2VkIGJ5IHRoZSBicm93c2VyIHRvIGhhbmRsZSBmaXJld2FsbCBzY2VuYXJpb3MgYW5kIGdpdmUg dGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgdGhlIHRvb2xzIHRvIGRvIHdoYXQgdGhleSB3YW50 Lg0KDQpUaGlzIGlzIG5vdCBhYm91dCBjaXJjdW12ZW50aW5nIHJ1bGVzIGJ1dCBhYm91dCBwdXR0 aW5nIHRvb2xzIGluIHBsYWNlIHNvIHJ1bGVzIGNhbiBiZSBkZWZpbmVkIGZvciB0aGlzIG5ldyB3 ZWIgdGVjaG5vbG9neSBhbmQgd2UgbmVlZCB0byBtb3ZlIG9uIHRoaXMgb3RoZXJ3aXNlIHdlYnJ0 YyB3aWxsIGJlIHVubmVjZXNzYXJpbHkgcmVzdHJpY3RlZCBpbiB3aGVyZS9ob3cgaXQgY2FuIGJl IHVzZWQuDQoNClNvIGZhciBJIHN0aWxsIHRoaW5rIHRoZSBIVFRQIENvbm5lY3QgbWVjaGFuaXNt IGRlc2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odXR0b24tcnRj d2ViLW5hdC1maXJld2FsbC1jb25zaWRlcmF0aW9ucyBpcyB0aGUgYmVzdCBvcHRpb24gYXMgaXQg cmVxdWlyZXMgb25seSBicm93c2VyIGltcGxlbWVudGF0aW9uIGFuZCBleGlzdGluZyBpbmZyYXN0 cnVjdHVyZSB0byB3b3JrLiANCg0KSG93ZXZlciBsZXQncyBkZWJhdGUgdGhlIG1lcml0cyBvZiBh bGwgc29sdXRpb25zIGFuZCBtb3ZlIHRoaXMgZm9yd2FyZC4NCg0KQW5keS4NCg0KDQo= From rlb@ipv.sx Fri May 24 10:52:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589F321F9651 for ; Fri, 24 May 2013 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FSNBdw0AJGC for ; Fri, 24 May 2013 10:52:52 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0B85721F95EC for ; Fri, 24 May 2013 10:52:47 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id h1so6593056oag.11 for ; Fri, 24 May 2013 10:52:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4/8ezoRymLgYaW5UV+BFWCV3lwZDPqbB+H8Fp3KiTyo=; b=LacuPAsluAeSYqvYh33VSAW1xHPVF+flmRq6iREeTBrQFQqGX21KrjqswL1VH8w7lo dsKD+gaEyxdxeWkfqvm6CYlCLfbQv8KAhB4OFCqCKcHQd6/drRhZ2ePwyXrBafiLOXfX uCcYV/9UycyHI0UgeIu8Fv/PvPMuHiD8kYlm7nArIh+77qch6+rrlymijzKptW0yR94K VVQ7l6a3ciJ5ZiDZ7FS1oxr6auMndeJKU5k3JMLcMQWN9rw4eLiJaaWHzuNsMm/RpcHX 5tPcapnpw+btjSKntqnx2A7B1x1qttCylldPdzCD8BLnQ4e8u6TC8HwsJ7PTJ56Hkynl y2+Q== MIME-Version: 1.0 X-Received: by 10.60.42.104 with SMTP id n8mr12735649oel.94.1369417967588; Fri, 24 May 2013 10:52:47 -0700 (PDT) Received: by 10.60.102.146 with HTTP; Fri, 24 May 2013 10:52:47 -0700 (PDT) X-Originating-IP: [128.89.254.202] In-Reply-To: <519F8F13.8020204@acm.org> References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <519F8F13.8020204@acm.org> Date: Fri, 24 May 2013 13:52:47 -0400 Message-ID: From: Richard Barnes To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=089e0149ca5c81ec2204dd7a7752 X-Gm-Message-State: ALoCoQkIXUIkFkH5B3X7QpGpN7Hy5NSyGpKQVGTTL1kbAVVaEZgz3fHsl45jnsE6OsOUOAgPhm6L X-Mailman-Approved-At: Tue, 28 May 2013 08:38:47 -0700 Cc: "rtcweb@ietf.org" , Lorenzo Miniero , "behave@ietf.org" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 17:52:52 -0000 --089e0149ca5c81ec2204dd7a7752 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is probably about the appropriate point in the thread to drop in a reference to Firewall Enhancement Protocol, RFC 3093: FEP has the benefit that you don't even negotiate the connection, since it tunnels the entire IP datagram, not just the UDP part. On Fri, May 24, 2013 at 12:02 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 05/20/2013 02:15 AM, Lorenzo Miniero wrote: > > Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=EDa > > > ha scritto: > > > >> I agree that TURN over websockets doesn't solve much more scenarios th= an > >> TURN/TLS. If trying to fix HTTP Proxy traversal why not doing it ove= r > >> HTTP that aside of philosophical discussions would be the solution wit= h > >> better success rate? Otherwise we will have to continue answering for > >> another 10 years "why is this app not working if skype does". > >> > >> Something like this draft sent some months ago but perhaps for TURN > >> instead of direct connections: > >> http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt > >> > > > > > > When I submitted that draft this summer, I had that exact purpose in > mind, > > that is taking care of corner edge cases like restrictive proxies and t= he > > like. Of course it was not meant to be a solution, just a way to foster > > discussion in that direction. In that discussion I also mentioned some > work > > we did about this in the past, which in part apparently ended up in > > draft-hutton-rtcweb-nat-firewall-considerations: > > > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html > > > > At the time most people in the ML thought it was either too useless, to= o > > complex or even harmful, considering it could be considered as a "sneak= y" > > way to circumvent rules added by a network administrator, and so > > unacceptable. Anyway, as I said back then, a solution like this doesn't > > have to be sneaky, and it could very well be conceived in order to be > > admin-friendly rather than have a parrot and a wooden leg. > > About circumventing rules added by a network administrator, I do think th= at > using TURN over Websocket or HTTP is doing in fact the opposite: It is t= he > only way to obey the wish of the network administrator, as long as you > classify Webrtc is a *web* technology and not as a VoIP technology. > > Think about it this way: An administrator restricting UDP but authorizin= g > HTTP is basically saying: All web applications are fine, and Webrtc being= a > Web application, it should just work fine, and should not be a collateral > damage of restricting UDP. So TURN over Websocket/HTTP should be a > mandatory > part of Webrtc. > > Now the administrator should also have access to tools to restrict some > classes of web applications, and Webrtc should be one of these classes. > But > that should not be done as a side-effect of closing the UDP ports. > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJRn48NAAoJECnERZXWan7Eve4P/3Y1SL2IuHZw6Iqats3ZwXG9 > dRxG5JSWEqKbVBgiPNUvXocMu7MbclAB1PC8K++roBDjayqlL9bh2EGmolyLDMLr > oloAFLRUmo4Yccj+IkECODbgVowtE9rNl9BudUk4hDk151Z6HLgu8wjAR05aLaM2 > 9PHnAmp4JZt6BlrOytkUj9yHLsSSCPNqZpYSFFbrCEkURQLZTXlPw0BOtRVoBb8a > zBwDVSaW7IdgOuIwq5kbxaITXXrrezCspMesMucVFfp9f0k1AtR3ARjhPj6wAogv > WJvtBnJYUDw8fpZplyPmKK8af7jEpfbr5IrkzE5JPrmeCdLElzqb6BSpe+GP6EqH > 0QSDZe73HqwMso90VAFPitGnTK91qLk7R3c//W3J0GQ6sSwUYrArjx5sO5uS7N9n > 78YIZXoEYgPMfetkGIMJddSRkJxNjQAyi9kmcWyss8CgvqEnWCZbFlnz8I0Eeh+8 > tOI4nhyJGVsSKAn1uORGvnrOXID8oTOhXfwh2r4yDQRpu8outqZuSeksSEtOgoYe > Jli9boycKkXCilBDHkf+YhY5bqETvDunFyb+O1NQnpIogQOrxucX8Jr9YyAbRxbw > xb0qNyMPLpp75jXfgFQ4Cxc+f8Nm7xYG8GKrSKHxiqazo6aOKZ1rxWdv5945iB53 > HJsMG1MkVKRwRBgLsM9S > =3DHTew > -----END PGP SIGNATURE----- > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e0149ca5c81ec2204dd7a7752 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is probably about the appropriate point in the thread= to drop in a reference to Firewall Enhancement Protocol, RFC 3093:
FEP has the benefit that you don't even negotiate the connection, = since it tunnels the entire IP datagram, not just the UDP part.
&= lt;/sarcasm>




On Fri, May 24, 2013 at 12:02 PM, Marc P= etit-Huguenin <petithug@acm.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/20/2013 02:15 AM, Lorenzo Miniero wrote:
> Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo Garc=EDa <ggb@tokbox.com>
> ha scritto:
>
>> I agree that TURN over websockets doesn't solve much more scen= arios than
>> TURN/TLS. =A0 If trying to fix HTTP Proxy traversal why not doing = it over
>> HTTP that aside of philosophical discussions would be the solution= with
>> better success rate? =A0Otherwise we will have to continue answeri= ng for
>> another 10 years "why is this app not working if skype does&q= uot;.
>>
>> Something like this draft sent some months ago but perhaps for TUR= N
>> instead of direct connections:
>> http://tools.ietf.org/id/draft-miniero-rtcwe= b-http-fallback-00.txt
>>
>
>
> When I submitted that draft this summer, I had that exact purpose in m= ind,
> that is taking care of corner edge cases like restrictive proxies and = the
> like. Of course it was not meant to be a solution, just a way to foste= r
> discussion in that direction. In that discussion I also mentioned some= work
> we did about this in the past, which in part apparently ended up in > draft-hutton-rtcweb-nat-firewall-considerations:
>
> http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg05041.html
>
> At the time most people in the ML thought it was either too useless, t= oo
> complex or even harmful, considering it could be considered as a "= ;sneaky"
> way to circumvent rules added by a network administrator, and so
> unacceptable. Anyway, as I said back then, a solution like this doesn&= #39;t
> have to be sneaky, and it could very well be conceived in order to be<= br> > admin-friendly rather than have a parrot and a wooden leg.

About circumventing rules added by a network administrator, I do thin= k that
using TURN over Websocket or HTTP is doing in fact the opposite: =A0It is t= he
only way to obey the wish of the network administrator, as long as you
classify Webrtc is a *web* technology and not as a VoIP technology.

Think about it this way: =A0An administrator restricting UDP but authorizin= g
HTTP is basically saying: All web applications are fine, and Webrtc being a=
Web application, it should just work fine, and should not be a collateral damage of restricting UDP. =A0So TURN over Websocket/HTTP should be a manda= tory
part of Webrtc.

Now the administrator should also have access to tools to restrict some
classes of web applications, and Webrtc should be one of these classes. =A0= But
that should not be done as a side-effect of closing the UDP ports.

- --
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRn48NAAoJECnERZXWan7Eve4P/3Y1SL2IuHZw6Iqats3ZwXG9
dRxG5JSWEqKbVBgiPNUvXocMu7MbclAB1PC8K++roBDjayqlL9bh2EGmolyLDMLr
oloAFLRUmo4Yccj+IkECODbgVowtE9rNl9BudUk4hDk151Z6HLgu8wjAR05aLaM2
9PHnAmp4JZt6BlrOytkUj9yHLsSSCPNqZpYSFFbrCEkURQLZTXlPw0BOtRVoBb8a
zBwDVSaW7IdgOuIwq5kbxaITXXrrezCspMesMucVFfp9f0k1AtR3ARjhPj6wAogv
WJvtBnJYUDw8fpZplyPmKK8af7jEpfbr5IrkzE5JPrmeCdLElzqb6BSpe+GP6EqH
0QSDZe73HqwMso90VAFPitGnTK91qLk7R3c//W3J0GQ6sSwUYrArjx5sO5uS7N9n
78YIZXoEYgPMfetkGIMJddSRkJxNjQAyi9kmcWyss8CgvqEnWCZbFlnz8I0Eeh+8
tOI4nhyJGVsSKAn1uORGvnrOXID8oTOhXfwh2r4yDQRpu8outqZuSeksSEtOgoYe
Jli9boycKkXCilBDHkf+YhY5bqETvDunFyb+O1NQnpIogQOrxucX8Jr9YyAbRxbw
xb0qNyMPLpp75jXfgFQ4Cxc+f8Nm7xYG8GKrSKHxiqazo6aOKZ1rxWdv5945iB53
HJsMG1MkVKRwRBgLsM9S
=3DHTew
-----END PGP SIGNATURE-----
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e0149ca5c81ec2204dd7a7752-- From dwing@cisco.com Tue May 28 17:29:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115AE11E80D2 for ; Tue, 28 May 2013 17:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaS1xGA-v3wD for ; Tue, 28 May 2013 17:29:03 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8745811E80BA for ; Tue, 28 May 2013 17:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=610; q=dns/txt; s=iport; t=1369787343; x=1370996943; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=azSEeRBfeN+VGjmXMZfP9/G5cvj4XwRS5mSGh6fPy98=; b=ZwlXx5Fc9ARppm2f+19PEKscpzcSbH+8HN5lnUAuCiyat9jbJmEg4gGa jf3qYgR4A0JFm4LgjB1Zq3RjFIcq2A9vM6BNcueIj0E7caUzxQCfSl+ce T6DEQiyYbWxLAhD7QegLsgn2WoVt8kCcqn2k22XzPL9m+zLF4owoIJmaU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8IAAxLpVGrRDoI/2dsb2JhbABZgwkwAYJzslmMY4EHFm0HgiMBAQEDAR0dPwULC0ZXBhOIBwUNu1yOajMHgnNhA4kfjhyBKYR1iyKDLxw X-IronPort-AV: E=Sophos;i="4.87,761,1363132800"; d="scan'208";a="79770894" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 29 May 2013 00:29:03 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4T0T2bN002031; Wed, 29 May 2013 00:29:02 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Tue, 28 May 2013 17:29:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65164E06-7BC2-4A34-94B3-85198119C617@cisco.com> References: To: "behave@ietf.org" X-Mailer: Apple Mail (2.1503) Cc: "draft-penno-behave-rfc4787-5382-5508-bis@tools.ietf.org" , "Behave Chairs \(behave-chairs@tools.ietf.org\)" Subject: Re: [BEHAVE] call for adoption, draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 00:29:08 -0000 On May 3, 2013, at 3:43 PM, Dan Wing wrote: > 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. =20 >=20 > = http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-04 This will be adopted as a working group document. -d From dthaler@microsoft.com Wed May 29 14:17:50 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E6C21F9701 for ; Wed, 29 May 2013 14:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.467 X-Spam-Level: X-Spam-Status: No, score=-98.467 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ7VjtawDS8T for ; Wed, 29 May 2013 14:17:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9B221F96EC for ; Wed, 29 May 2013 14:17:43 -0700 (PDT) Received: from BY2FFO11FD026.protection.gbl (10.1.15.203) by BY2FFO11HUB036.protection.gbl (10.1.14.179) with Microsoft SMTP Server (TLS) id 15.0.698.0; Wed, 29 May 2013 21:17:42 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD026.mail.protection.outlook.com (10.1.15.215) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 29 May 2013 21:17:42 +0000 Received: from DB8EHSOBE018.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 29 May 2013 21:17:34 +0000 Received: from mail33-db8-R.bigfish.com (10.174.8.254) by DB8EHSOBE018.bigfish.com (10.174.4.81) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 May 2013 21:16:18 +0000 Received: from mail33-db8 (localhost [127.0.0.1]) by mail33-db8-R.bigfish.com (Postfix) with ESMTP id 3651ABC00C2 for ; Wed, 29 May 2013 21:16:18 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -14 X-BigFish: PS-14(zzzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dh17598djz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh17ej9a9j1155h) Received-SPF: softfail (mail33-db8: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; LANG:en; Received: from mail33-db8 (localhost.localdomain [127.0.0.1]) by mail33-db8 (MessageSwitch) id 1369862176298884_11542; Wed, 29 May 2013 21:16:16 +0000 (UTC) Received: from DB8EHSMHS016.bigfish.com (unknown [10.174.8.226]) by mail33-db8.bigfish.com (Postfix) with ESMTP id 469E14C0055 for ; Wed, 29 May 2013 21:16:16 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS016.bigfish.com (10.174.4.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 May 2013 21:16:15 +0000 Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.311.1; Wed, 29 May 2013 21:16:11 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.698.13; Wed, 29 May 2013 21:16:09 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.183]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.183]) with mapi id 15.00.0698.010; Wed, 29 May 2013 21:16:08 +0000 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: WGLC on draft-ietf-behave-nat-mib Thread-Index: Ac5csUf0maP8QPpzSZGehDhIcO1Hfw== Date: Wed, 29 May 2013 21:16:08 +0000 Message-ID: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:1a:3:24d6:67ae:ed1b:a4be] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(20776003)(49866001)(15202345002)(46102001)(44976003)(16676001)(56816002)(47776003)(46406003)(74662001)(54316002)(4396001)(76576001)(77982001)(74316001)(33646001)(59766001)(76176001)(56776001)(81342001)(79102001)(54356001)(6806003)(81542001)(50986001)(69226001)(50466002)(47976001)(76482001)(47736001)(23726002)(65816001)(51856001)(74502001)(74876001)(74366001)(80022001)(74706001)(47446002)(31966008)(76786001)(53806001)(76796001)(63696002)(24736002)(3826001)(15302535009); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB036; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08617F610C Subject: [BEHAVE] WGLC on draft-ietf-behave-nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 21:17:50 -0000 We are starting a two-week working group last call for "Additional Managed = Objects for Network Address Translators (NAT)", draft-ietf-behave-nat-mib-0= 6, http://tools.ietf.org/html/draft-ietf-behave-nat-mib-06=20 Please send substantial comments to the list, and simple editorial nits to = the authors. WGLC for this document will end on Wednesday, June 12. -Dave From dthaler@microsoft.com Wed May 29 14:43:42 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7053B21F9763 for ; Wed, 29 May 2013 14:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.8 X-Spam-Level: X-Spam-Status: No, score=-97.8 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gsGi86t4T-Q for ; Wed, 29 May 2013 14:43:37 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 0269621F9766 for ; Wed, 29 May 2013 14:43:36 -0700 (PDT) Received: from BY2FFO11FD010.protection.gbl (10.1.15.203) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.0.698.0; Wed, 29 May 2013 21:43:28 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Wed, 29 May 2013 21:43:28 +0000 Received: from CO9EHSOBE021.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 29 May 2013 21:43:17 +0000 Received: from mail103-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 May 2013 21:43:00 +0000 Received: from mail103-co9 (localhost [127.0.0.1]) by mail103-co9-R.bigfish.com (Postfix) with ESMTP id 6DDEA1C00AE for ; Wed, 29 May 2013 21:43:00 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -19 X-BigFish: PS-19(zz9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh17ej9a9j1155h) Received-SPF: softfail (mail103-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; LANG:en; Received: from mail103-co9 (localhost.localdomain [127.0.0.1]) by mail103-co9 (MessageSwitch) id 1369863779297663_19039; Wed, 29 May 2013 21:42:59 +0000 (UTC) Received: from CO9EHSMHS028.bigfish.com (unknown [10.236.132.246]) by mail103-co9.bigfish.com (Postfix) with ESMTP id 453CC48005C; Wed, 29 May 2013 21:42:59 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS028.bigfish.com (10.236.130.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 May 2013 21:42:57 +0000 Received: from BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.311.1; Wed, 29 May 2013 21:42:56 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.698.13; Wed, 29 May 2013 21:42:54 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.183]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.183]) with mapi id 15.00.0698.010; Wed, 29 May 2013 21:42:54 +0000 From: Dave Thaler To: "draft-ietf-behave-nat-mib@tools.ietf.org" Thread-Topic: WGLC on draft-ietf-behave-nat-mib Thread-Index: Ac5csUf0maP8QPpzSZGehDhIcO1HfwAAQW1Q Date: Wed, 29 May 2013 21:42:54 +0000 Message-ID: References: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:1a:3:24d6:67ae:ed1b:a4be] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB271.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(377454002)(199002)(13464003)(189002)(47776003)(79102001)(74706001)(76576001)(50466002)(6806003)(80022001)(23726002)(65816001)(47446002)(54316002)(74502001)(54356001)(4396001)(47736001)(74876001)(49866001)(46102001)(77982001)(31966008)(56816002)(63696002)(53806001)(50986001)(33646001)(51856001)(20776003)(15202345002)(81342001)(46406003)(74366001)(47976001)(74316001)(81542001)(16676001)(69226001)(76482001)(76786001)(44976003)(59766001)(56776001)(76796001)(74662001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB040; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08617F610C Cc: "behave@ietf.org" Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 21:43:42 -0000 Some initial items noticed by document shepherd (me): 1) Section 5 of the current draft has " Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP." Per http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security=20 that's supposed to be followed with " These are the tables and objects and their sensitivity/vulnerability: " Also the document has 2 paragraphs of text=20 "There are a number of managed objects in this MIB that may contain ... versions of SNMP provide features for such a secure environment." which do not appear in the current MIB boilerplate at the link above. Should those 2 paragraphs be removed? 2) Section 5 contains MUST, SHOULD, etc. But the document is missing the boilerplate reference to RFC 2119. 3) Section 6 does not say whether any additional actions for IANA are needed. Suggest adding "No IANA actions are required by this document.= " 4) The MIB compiler I used complained about this: > natMappingPool OBJECT-TYPE > SYNTAX NatPoolId (0|1..4294967295) Because of > NatPoolId ::=3D TEXTUAL-CONVENTION > SYNTAX Unsigned32 (1..4294967295) That is, NatPoolId does not allow 0, and so natMappingPool cannot add it and still use the NatPoolId syntax. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Dave Thaler > Sent: Wednesday, May 29, 2013 2:16 PM > To: behave@ietf.org > Subject: [BEHAVE] WGLC on draft-ietf-behave-nat-mib >=20 > We are starting a two-week working group last call for "Additional Manage= d > Objects for Network Address Translators (NAT)", draft-ietf-behave-nat-mib= -06, >=20 > http://tools.ietf.org/html/draft-ietf-behave-nat-mib-06 >=20 > Please send substantial comments to the list, and simple editorial nits t= o the > authors. >=20 > WGLC for this document will end on Wednesday, June 12. >=20 > -Dave >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 From simon.perreault@viagenie.ca Thu May 30 02:47:59 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9476921F8FEC for ; Thu, 30 May 2013 02:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=-1.824, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, J_CHICKENPOX_74=0.6, MANGLED_PAIN=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC2PJZQlVwEB for ; Thu, 30 May 2013 02:47:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDD121F8F9E for ; Thu, 30 May 2013 02:47:47 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E208E4689C; Thu, 30 May 2013 05:47:45 -0400 (EDT) Message-ID: <51A72041.6060208@viagenie.ca> Date: Thu, 30 May 2013 11:47:45 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dave Thaler References: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------020306010209090309010503" X-Mailman-Approved-At: Thu, 30 May 2013 10:10:25 -0700 Cc: "behave@ietf.org" , "draft-ietf-behave-nat-mib@tools.ietf.org" Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 09:47:59 -0000 This is a multi-part message in MIME format. --------------020306010209090309010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Le 2013-05-29 23:42, Dave Thaler a écrit : > Some initial items noticed by document shepherd (me): > > 1) Section 5 of the current draft has > " Some of the readable objects in this MIB module (i.e., objects with a > MAX-ACCESS other than not-accessible) may be considered sensitive or > vulnerable in some network environments. It is thus important to > control even GET and/or NOTIFY access to these objects and possibly > to even encrypt the values of these objects when sending them over > the network via SNMP." > > Per http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > that's supposed to be followed with > " These are the tables and objects and their > sensitivity/vulnerability: > > " > > Also the document has 2 paragraphs of text > "There are a number of managed objects in this MIB that may contain > ... > versions of SNMP provide features for such a secure environment." > which do not appear in the current MIB boilerplate at the link above. > Should those 2 paragraphs be removed? How about this as a replacement? Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Objects that reveal host identities: Various objects can reveal the identity of private hosts that are engaged in a session with external end nodes. A curious outsider could monitor these to assess the number of private hosts being supported by the NAT device. Further, a disgruntled former employee of an enterprise could use the information to break into specific private hosts by intercepting the existing sessions or originating new sessions into the host. * natMapIntAddrType * natMapIntAddrInt * natMapIntAddrExt * natMappingIntRealm * natMappingIntAddressType * natMappingIntAddress * natMappingIntPort * natMappingMapBehavior * natMappingFilterBehavior * natMappingAddressPooling * natSubscriberIntPrefixType * natSubscriberIntPrefix * natSubscriberIntPrefixLength Other objects that reveal NAT state: Other managed objects in this MIB may contain information that may be sensitive from a business perspective, in that they may represent NAT state information. * natCntAddressMappings * natCntProtocolMappings * natPoolUsage * natPoolRangeAllocatedPorts * natSubscriberCntMappings There are no objects that are sensitive in their own right, such as passwords or monetary amounts. > 2) Section 5 contains MUST, SHOULD, etc. But the document is missing > the boilerplate reference to RFC 2119. *gasp* Added. > 3) Section 6 does not say whether any additional actions for IANA > are needed. Suggest adding "No IANA actions are required by this document." Added. > 4) The MIB compiler I used complained about this: >> natMappingPool OBJECT-TYPE >> SYNTAX NatPoolId (0|1..4294967295) > Because of >> NatPoolId ::= TEXTUAL-CONVENTION >> SYNTAX Unsigned32 (1..4294967295) > > That is, NatPoolId does not allow 0, and so natMappingPool cannot add it > and still use the NatPoolId syntax. Hmmmm... Would it be OK if I changed natMappingPool to an Unsigned32? natMappingPool OBJECT-TYPE SYNTAX Unsigned32 (0|1..4294967295) Updated draft is attached. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca --------------020306010209090309010503 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-behave-nat-mib-07.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-behave-nat-mib-07.txt" Network Working Group S. Perreault Internet-Draft Viagenie Obsoletes: 4008 (if approved) T. Tsou Intended status: Standards Track Huawei Technologies (USA) Expires: December 01, 2013 S. Sivakumar Cisco Systems May 30, 2013 Additional Managed Objects for Network Address Translators (NAT) draft-ietf-behave-nat-mib-07 Abstract This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 01, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Perreault, et al. Expires December 01, 2013 [Page 1] Internet-Draft NEW NAT MIB May 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Internet-Standard Management Framework . . . . . . . . . 2 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Deprecated Features . . . . . . . . . . . . . . . . . . . 3 3.2. New Features . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Realms . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 81 7.2. Informative References . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 1. Introduction This memo defines a portion of the Management Information Base (MIB) for devices implementing NAT function. This MIB module may be used for monitoring of a device capable of NAT function. Using it for configuration is deprecated. NAT types and their characteristics are defined in [RFC2663]. Traditional NAT function, in particular is defined in [RFC3022]. This MIB does not address the firewall functions and must not be used for configuring or monitoring these. Section 2 provides references to the SNMP management framework, which was used as the basis for the MIB module definition. Section 3 provides an overview of the MIB features. Lastly, Section 4 has the complete NAT MIB definition. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB Perreault, et al. Expires December 01, 2013 [Page 2] Internet-Draft NEW NAT MIB May 2013 module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview 3.1. Deprecated Features All objects defined in [RFC4008] have been marked with "STATUS deprecated" for the following reasons: Writability: Experience with NAT has shown that implementations vary tremendously. The NAT algorithms and data structures have little in common across devices, and this results in wildly incompatible configuration parameters. Therefore, few implementations were ever able to claim full compliance. Lesson learned: the MIB should be read-only as much as possible. Exposing configuration parameters: Even in read-only mode, many configuration parameters were exposed by [RFC4008] (e.g. timeouts). Since implementations vary wildly in their sets of configuration parameters, few implementations could claim even basic compliance. Lesson learned: the NAT MIB's purpose is not to expose configuration parameters. Interfaces: Objects from [RFC4008] tie NAT state with interfaces (e.g. the interface table, the way map entries are grouped by interface). Many NAT implementations either never keep track of the interface or associate a mapping to a set of interfaces. Since interfaces are at the core of [RFC4008], many NAT devices were unable to have a proper implementation. Lesson learned: NAT is a logical function that may be independent of interfaces. Do not tie NAT state with interfaces. NAT service types: [RFC4008] used four categories of NAT service: basicNat, napt, bidirectionalNat, twiceNat. These are ill-defined and many implementations either use different categories or do not use categories at all. Lesson learned: do not try to categorize NAT types. Limited transport protocol set: The set of transport protocols was defined as: other, icmp, udp, tcp. Furthermore, the numeric values corresponding to those labels were arbitrary, without Perreault, et al. Expires December 01, 2013 [Page 3] Internet-Draft NEW NAT MIB May 2013 relation to the actual standard protocol numbers. This meant that NAT implementations were limited to those protocols and were unable to expose information about DCCP, SCTP, etc. Lesson learned: use standard transport protocol numbers. 3.2. New Features New features in this module are as follows: Counters: Many new counters are introduced. Most of them are available in two variants: global and per-transport protocol. Limits: A few limits on the quantity of state data stored by the NAT device. Some of them can trigger notifications. Address+Port Pools: Pools of external addresses and ports are often used in enterprise and ISP settings. Pools are listed in a table, each with its range of addresses and ports. It is possible to inspect each pool's usage, to set limits, and to receive notifications when thresholds are crossed. Address Mappings: NATs that have an "IP address pooling" behavior of "Paired" [RFC4787] maintain a mapping from internal address to external address. This module allows inspection of this mapping table. Mapping table indexed by external 3-tuple: It is often necessary to determine the internal address that is mapped to a given external address and port. This MIB provides this table with an index to accomplish this efficiently, without having to iterate over all mappings. Realms: See Section 3.3. RFC 4787 terminology: Mapping table entries indicate the mapping behavior, the filtering behavior, and the address pooling behavior that were used to create the mapping. Subscriber awareness: With the advent of CGN deployment, a set of subscriber specific counters, limits and parameters are added. 3.3. Realms Current NAT devices commonly allow the internal and external parts of a mapping to come from different realms. The meaning of "realm" is implementation-dependent. On some implementations it can be equivalent to the name of a VPN Routing and Forwarding table (VRF). Perreault, et al. Expires December 01, 2013 [Page 4] Internet-Draft NEW NAT MIB May 2013 On others it is simply the numeric index of a virtual routing table. Note that this usage of "realm" is completely different from the one in [RFC4008]. This MIB allows the realm to be indicated where it makes sense. The format is an SnmpAdminString. On platforms that identify realms with integers, the string representation of the integer is used instead. The empty string has special meaning: it refers to the default realm. Note that many MIBs implicitly support realms in one form or another by using SNMPv3 contexts. See for example the OSPFv2 MIB [RFC4750]. This method cannot be used for the NAT MIB because mapppings can belong to two realms simultaneously: the internal part can be in one realm while the external part is in another. In such cases the NAT function acts like a "wormhole" between two realms. Using contexts would implicitly impose the restriction that all objects would have to belong to the same realm. 4. Definitions This MIB module IMPORTs objects from [RFC2578], [RFC2579], and [RFC4001]. NAT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Gauge32, Counter64, TimeTicks, mib-2, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, StorageType, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, ifCounterDiscontinuityGroup FROM IF-MIB SnmpAdminString Perreault, et al. Expires December 01, 2013 [Page 5] Internet-Draft NEW NAT MIB May 2013 FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress, InetAddressPrefixLength, InetPortNumber FROM INET-ADDRESS-MIB; natMIB MODULE-IDENTITY LAST-UPDATED "201304260000Z" -- RFC Ed.: set to publication date ORGANIZATION "IETF Behavior Engineering for Hindrance Avoidance (BEHAVE) Working Group" CONTACT-INFO "Working Group Email: behave@ietf.org Simon Perreault Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada Phone: +1 418 656 9254 Email: simon.perreault@viagenie.ca URI: http://viagenie.ca Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tina.tsou.zouting@huawei.com Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park, North Carolina 27709 USA Phone: +1 919 392 5158 Email: ssenthil@cisco.com" DESCRIPTION "This MIB module defines the generic managed objects for NAT. Perreault, et al. Expires December 01, 2013 [Page 6] Internet-Draft NEW NAT MIB May 2013 Copyright (C) The Internet Society (2013). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note" REVISION "201304260000Z" -- RFC Ed.: set to publication date DESCRIPTION "Complete rewrite, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & set date" REVISION "200503210000Z" -- 21th March 2005 DESCRIPTION "Initial version, published as RFC 4008." ::= { mib-2 123 } natMIBObjects OBJECT IDENTIFIER ::= { natMIB 1 } NatProtocolType ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "A list of protocols that support the network address translation. Inclusion of the values is not intended to imply that those protocols need to be supported. Any change in this TEXTUAL-CONVENTION should also be reflected in the definition of NatProtocolMap, which is a BITS representation of this." SYNTAX INTEGER { none (1), -- not specified other (2), -- none of the following icmp (3), udp (4), tcp (5) } NatProtocolMap ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "A bitmap of protocol identifiers that support the network address translation. Any change in this TEXTUAL-CONVENTION should also be reflected in the definition of NatProtocolType." SYNTAX BITS { other (0), icmp (1), udp (2), tcp (3) } Perreault, et al. Expires December 01, 2013 [Page 7] Internet-Draft NEW NAT MIB May 2013 NatAddrMapId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS deprecated DESCRIPTION "A unique id that is assigned to each address map by a NAT enabled device." SYNTAX Unsigned32 (1..4294967295) NatBindIdOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS deprecated DESCRIPTION "A unique id that is assigned to each bind by a NAT enabled device. The bind id will be zero in the case of a Symmetric NAT." SYNTAX Unsigned32 (0..4294967295) NatBindId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS deprecated DESCRIPTION "A unique id that is assigned to each bind by a NAT enabled device." SYNTAX Unsigned32 (1..4294967295) NatSessionId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS deprecated DESCRIPTION "A unique id that is assigned to each session by a NAT enabled device." SYNTAX Unsigned32 (1..4294967295) NatBindMode ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "An indication of whether the bind is an address bind or an address port bind." SYNTAX INTEGER { addressBind (1), addressPortBind (2) } NatAssociationType ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "An indication of whether the association is static or dynamic." Perreault, et al. Expires December 01, 2013 [Page 8] Internet-Draft NEW NAT MIB May 2013 SYNTAX INTEGER { static (1), dynamic (2) } NatTranslationEntity ::= TEXTUAL-CONVENTION STATUS deprecated DESCRIPTION "An indication of a) the direction of a session for which an address map entry, address bind or port bind is applicable, and b) the entity (source or destination) within the session that is subject to translation." SYNTAX BITS { inboundSrcEndPoint (0), outboundDstEndPoint(1), inboundDstEndPoint (2), outboundSrcEndPoint(3) } -- -- Default Values for the Bind and NAT Protocol Timers -- natDefTimeouts OBJECT IDENTIFIER ::= { natMIBObjects 1 } natNotifCtrl OBJECT IDENTIFIER ::= { natMIBObjects 2 } -- -- Address Bind and Port Bind related NAT configuration -- natBindDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The default Bind (Address Bind or Port Bind) idle timeout parameter. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 0 } ::= { natDefTimeouts 1 } Perreault, et al. Expires December 01, 2013 [Page 9] Internet-Draft NEW NAT MIB May 2013 -- -- UDP related NAT configuration -- natUdpDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The default UDP idle timeout parameter. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 300 } ::= { natDefTimeouts 2 } -- -- ICMP related NAT configuration -- natIcmpDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The default ICMP idle timeout parameter. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 300 } ::= { natDefTimeouts 3 } -- -- Other protocol parameters -- natOtherDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS deprecated DESCRIPTION Perreault, et al. Expires December 01, 2013 [Page 10] Internet-Draft NEW NAT MIB May 2013 "The default idle timeout parameter for protocols represented by the value other (2) in NatProtocolType. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 60 } ::= { natDefTimeouts 4 } -- -- TCP related NAT Timers -- natTcpDefIdleTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The default time interval that a NAT session for an established TCP connection is allowed to remain valid without any activity on the TCP connection. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 86400 } ::= { natDefTimeouts 5 } natTcpDefNegTimeout OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS deprecated DESCRIPTION "The default time interval that a NAT session for a TCP connection that is not in the established state is allowed to remain valid without any activity on the TCP connection. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system." DEFVAL { 60 } Perreault, et al. Expires December 01, 2013 [Page 11] Internet-Draft NEW NAT MIB May 2013 ::= { natDefTimeouts 6 } natNotifThrottlingInterval OBJECT-TYPE SYNTAX Integer32 (0 | 5..3600) UNITS "seconds" MAX-ACCESS read-write STATUS deprecated DESCRIPTION "This object controls the generation of the natPacketDiscard notification. If this object has a value of zero, then no natPacketDiscard notifications will be transmitted by the agent. If this object has a non-zero value, then the agent must not generate more than one natPacketDiscard 'notification-event' in the indicated period, where a 'notification-event' is the generation of a single notification PDU type to a list of notification destinations. If additional NAT packets are discarded within the throttling period, then notification-events for these changes must be suppressed by the agent until the current throttling period expires. If natNotifThrottlingInterval notification generation is enabled, the suggested default throttling period is 60 seconds, but generation of the natPacketDiscard notification should be disabled by default. If the agent is capable of storing non-volatile configuration, then the value of this object must be restored after a re-initialization of the management system. The actual transmission of notifications is controlled via the MIB modules in RFC 3413." DEFVAL { 0 } ::= { natNotifCtrl 1 } -- -- The NAT Interface Table -- natInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF NatInterfaceEntry MAX-ACCESS not-accessible Perreault, et al. Expires December 01, 2013 [Page 12] Internet-Draft NEW NAT MIB May 2013 STATUS deprecated DESCRIPTION "This table specifies the attributes for interfaces on a device supporting NAT function." ::= { natMIBObjects 3 } natInterfaceEntry OBJECT-TYPE SYNTAX NatInterfaceEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Each entry in the natInterfaceTable holds a set of parameters for an interface, instantiated by ifIndex. Therefore, the interface index must have been assigned, according to the applicable procedures, before it can be meaningfully used. Generally, this means that the interface must exist. When natStorageType is of type nonVolatile, however, this may reflect the configuration for an interface whose ifIndex has been assigned but for which the supporting implementation is not currently present." INDEX { ifIndex } ::= { natInterfaceTable 1 } NatInterfaceEntry ::= SEQUENCE { natInterfaceRealm INTEGER, natInterfaceServiceType BITS, natInterfaceInTranslates Counter64, natInterfaceOutTranslates Counter64, natInterfaceDiscards Counter64, natInterfaceStorageType StorageType, natInterfaceRowStatus RowStatus } natInterfaceRealm OBJECT-TYPE SYNTAX INTEGER { private (1), public (2) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object identifies whether this interface is connected to the private or the public realm." DEFVAL { public } ::= { natInterfaceEntry 1 } Perreault, et al. Expires December 01, 2013 [Page 13] Internet-Draft NEW NAT MIB May 2013 natInterfaceServiceType OBJECT-TYPE SYNTAX BITS { basicNat (0), napt (1), bidirectionalNat (2), twiceNat (3) } MAX-ACCESS read-create STATUS deprecated DESCRIPTION "An indication of the direction in which new sessions are permitted and the extent of translation done within the IP and transport headers." ::= { natInterfaceEntry 2 } natInterfaceInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Number of packets received on this interface that were translated. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natInterfaceEntry 3 } natInterfaceOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Number of translated packets that were sent out this interface. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natInterfaceEntry 4 } natInterfaceDiscards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Number of packets that had to be rejected/dropped due to Perreault, et al. Expires December 01, 2013 [Page 14] Internet-Draft NEW NAT MIB May 2013 a lack of resources for this interface. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natInterfaceEntry 5 } natInterfaceStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." REFERENCE "Textual Conventions for SMIv2, Section 2." DEFVAL { nonVolatile } ::= { natInterfaceEntry 6 } natInterfaceRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the natInterfaceRowStatus column is 'notReady'. In particular, a newly created row cannot be made active until the corresponding instance of natInterfaceServiceType has been set. None of the objects in this row may be modified while the value of this object is active(1)." REFERENCE "Textual Conventions for SMIv2, Section 2." ::= { natInterfaceEntry 7 } -- -- The Address Map Table -- Perreault, et al. Expires December 01, 2013 [Page 15] Internet-Draft NEW NAT MIB May 2013 natAddrMapTable OBJECT-TYPE SYNTAX SEQUENCE OF NatAddrMapEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table lists address map parameters for NAT." ::= { natMIBObjects 4 } natAddrMapEntry OBJECT-TYPE SYNTAX NatAddrMapEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This entry represents an address map to be used for NAT and contributes to the dynamic and/or static address mapping tables of the NAT device." INDEX { ifIndex, natAddrMapIndex } ::= { natAddrMapTable 1 } NatAddrMapEntry ::= SEQUENCE { natAddrMapIndex NatAddrMapId, natAddrMapName SnmpAdminString, natAddrMapEntryType NatAssociationType, natAddrMapTranslationEntity NatTranslationEntity, natAddrMapLocalAddrType InetAddressType, natAddrMapLocalAddrFrom InetAddress, natAddrMapLocalAddrTo InetAddress, natAddrMapLocalPortFrom InetPortNumber, natAddrMapLocalPortTo InetPortNumber, natAddrMapGlobalAddrType InetAddressType, natAddrMapGlobalAddrFrom InetAddress, natAddrMapGlobalAddrTo InetAddress, natAddrMapGlobalPortFrom InetPortNumber, natAddrMapGlobalPortTo InetPortNumber, natAddrMapProtocol NatProtocolMap, natAddrMapInTranslates Counter64, natAddrMapOutTranslates Counter64, natAddrMapDiscards Counter64, natAddrMapAddrUsed Gauge32, natAddrMapStorageType StorageType, natAddrMapRowStatus RowStatus } natAddrMapIndex OBJECT-TYPE SYNTAX NatAddrMapId MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION Perreault, et al. Expires December 01, 2013 [Page 16] Internet-Draft NEW NAT MIB May 2013 "Along with ifIndex, this object uniquely identifies an entry in the natAddrMapTable. Address map entries are applied in the order specified by natAddrMapIndex." ::= { natAddrMapEntry 1 } natAddrMapName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS deprecated DESCRIPTION "Name identifying all map entries in the table associated with the same interface. All map entries with the same ifIndex MUST have the same map name." ::= { natAddrMapEntry 2 } natAddrMapEntryType OBJECT-TYPE SYNTAX NatAssociationType MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This parameter can be used to set up static or dynamic address maps." ::= { natAddrMapEntry 3 } natAddrMapTranslationEntity OBJECT-TYPE SYNTAX NatTranslationEntity MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The end-point entity (source or destination) in inbound or outbound sessions (i.e., first packets) that may be translated by an address map entry. Session direction (inbound or outbound) is derived from the direction of the first packet of a session traversing a NAT interface. NAT address (and Transport-ID) maps may be defined to effect inbound or outbound sessions. Traditionally, address maps for Basic NAT and NAPT are configured on a public interface for outbound sessions, effecting translation of source end-point. The value of this object must be set to outboundSrcEndPoint for those interfaces. Alternately, if address maps for Basic NAT and NAPT were to be configured on a private interface, the desired Perreault, et al. Expires December 01, 2013 [Page 17] Internet-Draft NEW NAT MIB May 2013 value for this object for the map entries would be inboundSrcEndPoint (i.e., effecting translation of source end-point for inbound sessions). If TwiceNAT were to be configured on a private interface, the desired value for this object for the map entries would be a bitmask of inboundSrcEndPoint and inboundDstEndPoint." ::= { natAddrMapEntry 4 } natAddrMapLocalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object specifies the address type used for natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo." ::= { natAddrMapEntry 5 } natAddrMapLocalAddrFrom OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object specifies the first IP address of the range of IP addresses mapped by this translation entry. The value of this object must be less than or equal to the value of the natAddrMapLocalAddrTo object. The type of this address is determined by the value of the natAddrMapLocalAddrType object." ::= { natAddrMapEntry 6 } natAddrMapLocalAddrTo OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object specifies the last IP address of the range of IP addresses mapped by this translation entry. If only a single address is being mapped, the value of this object is equal to the value of natAddrMapLocalAddrFrom. For a static NAT, the number of addresses in the range defined by natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo must be equal to the number of addresses in the range defined by natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo. The value of this object must be greater than or equal Perreault, et al. Expires December 01, 2013 [Page 18] Internet-Draft NEW NAT MIB May 2013 to the value of the natAddrMapLocalAddrFrom object. The type of this address is determined by the value of the natAddrMapLocalAddrType object." ::= { natAddrMapEntry 7 } natAddrMapLocalPortFrom OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS deprecated DESCRIPTION "If this conceptual row describes a Basic NAT address mapping, then the value of this object must be zero. If this conceptual row describes NAPT, then the value of this object specifies the first port number in the range of ports being mapped. The value of this object must be less than or equal to the value of the natAddrMapLocalPortTo object. If the translation specifies a single port, then the value of this object is equal to the value of natAddrMapLocalPortTo." DEFVAL { 0 } ::= { natAddrMapEntry 8 } natAddrMapLocalPortTo OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS deprecated DESCRIPTION "If this conceptual row describes a Basic NAT address mapping, then the value of this object must be zero. If this conceptual row describes NAPT, then the value of this object specifies the last port number in the range of ports being mapped. The value of this object must be greater than or equal to the value of the natAddrMapLocalPortFrom object. If the translation specifies a single port, then the value of this object is equal to the value of natAddrMapLocalPortFrom." DEFVAL { 0 } ::= { natAddrMapEntry 9 } natAddrMapGlobalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS deprecated Perreault, et al. Expires December 01, 2013 [Page 19] Internet-Draft NEW NAT MIB May 2013 DESCRIPTION "This object specifies the address type used for natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo." ::= { natAddrMapEntry 10 } natAddrMapGlobalAddrFrom OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object specifies the first IP address of the range of IP addresses being mapped to. The value of this object must be less than or equal to the value of the natAddrMapGlobalAddrTo object. The type of this address is determined by the value of the natAddrMapGlobalAddrType object." ::= { natAddrMapEntry 11 } natAddrMapGlobalAddrTo OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object specifies the last IP address of the range of IP addresses being mapped to. If only a single address is being mapped to, the value of this object is equal to the value of natAddrMapGlobalAddrFrom. For a static NAT, the number of addresses in the range defined by natAddrMapGlobalAddrFrom and natAddrMapGlobalAddrTo must be equal to the number of addresses in the range defined by natAddrMapLocalAddrFrom and natAddrMapLocalAddrTo. The value of this object must be greater than or equal to the value of the natAddrMapGlobalAddrFrom object. The type of this address is determined by the value of the natAddrMapGlobalAddrType object." ::= { natAddrMapEntry 12 } natAddrMapGlobalPortFrom OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS deprecated DESCRIPTION "If this conceptual row describes a Basic NAT address mapping, then the value of this object must be zero. If this conceptual row describes NAPT, then the value of Perreault, et al. Expires December 01, 2013 [Page 20] Internet-Draft NEW NAT MIB May 2013 this object specifies the first port number in the range of ports being mapped to. The value of this object must be less than or equal to the value of the natAddrMapGlobalPortTo object. If the translation specifies a single port, then the value of this object is equal to the value natAddrMapGlobalPortTo." DEFVAL { 0 } ::= { natAddrMapEntry 13 } natAddrMapGlobalPortTo OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS deprecated DESCRIPTION "If this conceptual row describes a Basic NAT address mapping, then the value of this object must be zero. If this conceptual row describes NAPT, then the value of this object specifies the last port number in the range of ports being mapped to. The value of this object must be greater than or equal to the value of the natAddrMapGlobalPortFrom object. If the translation specifies a single port, then the value of this object is equal to the value of natAddrMapGlobalPortFrom." DEFVAL { 0 } ::= { natAddrMapEntry 14 } natAddrMapProtocol OBJECT-TYPE SYNTAX NatProtocolMap MAX-ACCESS read-create STATUS deprecated DESCRIPTION "This object specifies a bitmap of protocol identifiers." ::= { natAddrMapEntry 15 } natAddrMapInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of inbound packets pertaining to this address map entry that were translated. Discontinuities in the value of this counter can occur Perreault, et al. Expires December 01, 2013 [Page 21] Internet-Draft NEW NAT MIB May 2013 at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrMapEntry 16 } natAddrMapOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of outbound packets pertaining to this address map entry that were translated. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrMapEntry 17 } natAddrMapDiscards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of packets pertaining to this address map entry that were dropped due to lack of addresses in the address pool identified by this address map. The value of this object must always be zero in case of static address map. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrMapEntry 18 } natAddrMapAddrUsed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of addresses pertaining to this address map that are currently being used from the NAT pool. The value of this object must always be zero in the case of a static address map." ::= { natAddrMapEntry 19 } natAddrMapStorageType OBJECT-TYPE Perreault, et al. Expires December 01, 2013 [Page 22] Internet-Draft NEW NAT MIB May 2013 SYNTAX StorageType MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." REFERENCE "Textual Conventions for SMIv2, Section 2." DEFVAL { nonVolatile } ::= { natAddrMapEntry 20 } natAddrMapRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS deprecated DESCRIPTION "The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the natAddrMapRowStatus column is 'notReady'. None of the objects in this row may be modified while the value of this object is active(1)." REFERENCE "Textual Conventions for SMIv2, Section 2." ::= { natAddrMapEntry 21 } -- -- Address Bind section -- natAddrBindNumberOfEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object maintains a count of the number of entries that currently exist in the natAddrBindTable." ::= { natMIBObjects 5 } -- -- The NAT Address BIND Table -- Perreault, et al. Expires December 01, 2013 [Page 23] Internet-Draft NEW NAT MIB May 2013 natAddrBindTable OBJECT-TYPE SYNTAX SEQUENCE OF NatAddrBindEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table holds information about the currently active NAT BINDs." ::= { natMIBObjects 6 } natAddrBindEntry OBJECT-TYPE SYNTAX NatAddrBindEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Each entry in this table holds information about an active address BIND. These entries are lost upon agent restart. This row has indexing which may create variables with more than 128 subidentifiers. Implementers of this table must be careful not to create entries that would result in OIDs which exceed the 128 subidentifier limit. Otherwise, the information cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." INDEX { ifIndex, natAddrBindLocalAddrType, natAddrBindLocalAddr } ::= { natAddrBindTable 1 } NatAddrBindEntry ::= SEQUENCE { natAddrBindLocalAddrType InetAddressType, natAddrBindLocalAddr InetAddress, natAddrBindGlobalAddrType InetAddressType, natAddrBindGlobalAddr InetAddress, natAddrBindId NatBindId, natAddrBindTranslationEntity NatTranslationEntity, natAddrBindType NatAssociationType, natAddrBindMapIndex NatAddrMapId, natAddrBindSessions Gauge32, natAddrBindMaxIdleTime TimeTicks, natAddrBindCurrentIdleTime TimeTicks, natAddrBindInTranslates Counter64, natAddrBindOutTranslates Counter64 } natAddrBindLocalAddrType OBJECT-TYPE SYNTAX InetAddressType Perreault, et al. Expires December 01, 2013 [Page 24] Internet-Draft NEW NAT MIB May 2013 MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This object specifies the address type used for natAddrBindLocalAddr." ::= { natAddrBindEntry 1 } natAddrBindLocalAddr OBJECT-TYPE SYNTAX InetAddress (SIZE (4|16)) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This object represents the private-realm specific network layer address, which maps to the public-realm address represented by natAddrBindGlobalAddr. The type of this address is determined by the value of the natAddrBindLocalAddrType object." ::= { natAddrBindEntry 2 } natAddrBindGlobalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object specifies the address type used for natAddrBindGlobalAddr." ::= { natAddrBindEntry 3 } natAddrBindGlobalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object represents the public-realm network layer address that maps to the private-realm network layer address represented by natAddrBindLocalAddr. The type of this address is determined by the value of the natAddrBindGlobalAddrType object." ::= { natAddrBindEntry 4 } natAddrBindId OBJECT-TYPE SYNTAX NatBindId MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object represents a bind id that is dynamically Perreault, et al. Expires December 01, 2013 [Page 25] Internet-Draft NEW NAT MIB May 2013 assigned to each bind by a NAT enabled device. Each bind is represented by a bind id that is unique across both, the natAddrBindTable and the natAddrPortBindTable." ::= { natAddrBindEntry 5 } natAddrBindTranslationEntity OBJECT-TYPE SYNTAX NatTranslationEntity MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object represents the direction of sessions for which this bind is applicable and the endpoint entity (source or destination) within the sessions that is subject to translation using the BIND. Orientation of the bind can be a superset of translationEntity of the address map entry which forms the basis for this bind. For example, if the translationEntity of an address map entry is outboundSrcEndPoint, the translationEntity of a bind derived from this map entry may either be outboundSrcEndPoint or it may be bidirectional (a bitmask of outboundSrcEndPoint and inboundDstEndPoint)." ::= { natAddrBindEntry 6 } natAddrBindType OBJECT-TYPE SYNTAX NatAssociationType MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object indicates whether the bind is static or dynamic." ::= { natAddrBindEntry 7 } natAddrBindMapIndex OBJECT-TYPE SYNTAX NatAddrMapId MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object is a pointer to the natAddrMapTable entry (and the parameters of that entry) which was used in creating this BIND. This object, in conjunction with the ifIndex (which identifies a unique addrMapName) points to a unique entry in the natAddrMapTable." ::= { natAddrBindEntry 8 } Perreault, et al. Expires December 01, 2013 [Page 26] Internet-Draft NEW NAT MIB May 2013 natAddrBindSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Number of sessions currently using this BIND." ::= { natAddrBindEntry 9 } natAddrBindMaxIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object indicates the maximum time for which this bind can be idle with no sessions attached to it. The value of this object is of relevance only for dynamic NAT." ::= { natAddrBindEntry 10 } natAddrBindCurrentIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "At any given instance, this object indicates the time that this bind has been idle without any sessions attached to it. The value of this object is of relevance only for dynamic NAT." ::= { natAddrBindEntry 11 } natAddrBindInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of inbound packets that were successfully translated by using this bind entry. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrBindEntry 12 } Perreault, et al. Expires December 01, 2013 [Page 27] Internet-Draft NEW NAT MIB May 2013 natAddrBindOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of outbound packets that were successfully translated using this bind entry. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrBindEntry 13 } -- -- Address Port Bind section -- natAddrPortBindNumberOfEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object maintains a count of the number of entries that currently exist in the natAddrPortBindTable." ::= { natMIBObjects 7 } -- -- The NAT Address Port Bind Table -- natAddrPortBindTable OBJECT-TYPE SYNTAX SEQUENCE OF NatAddrPortBindEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table holds information about the currently active NAPT BINDs." ::= { natMIBObjects 8 } natAddrPortBindEntry OBJECT-TYPE SYNTAX NatAddrPortBindEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Each entry in the this table holds information about a NAPT bind that is currently active. These entries are lost upon agent restart. Perreault, et al. Expires December 01, 2013 [Page 28] Internet-Draft NEW NAT MIB May 2013 This row has indexing which may create variables with more than 128 subidentifiers. Implementers of this table must be careful not to create entries which would result in OIDs that exceed the 128 subidentifier limit. Otherwise, the information cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." INDEX { ifIndex, natAddrPortBindLocalAddrType, natAddrPortBindLocalAddr, natAddrPortBindLocalPort, natAddrPortBindProtocol } ::= { natAddrPortBindTable 1 } NatAddrPortBindEntry ::= SEQUENCE { natAddrPortBindLocalAddrType InetAddressType, natAddrPortBindLocalAddr InetAddress, natAddrPortBindLocalPort InetPortNumber, natAddrPortBindProtocol NatProtocolType, natAddrPortBindGlobalAddrType InetAddressType, natAddrPortBindGlobalAddr InetAddress, natAddrPortBindGlobalPort InetPortNumber, natAddrPortBindId NatBindId, natAddrPortBindTranslationEntity NatTranslationEntity, natAddrPortBindType NatAssociationType, natAddrPortBindMapIndex NatAddrMapId, natAddrPortBindSessions Gauge32, natAddrPortBindMaxIdleTime TimeTicks, natAddrPortBindCurrentIdleTime TimeTicks, natAddrPortBindInTranslates Counter64, natAddrPortBindOutTranslates Counter64 } natAddrPortBindLocalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This object specifies the address type used for natAddrPortBindLocalAddr." ::= { natAddrPortBindEntry 1 } natAddrPortBindLocalAddr OBJECT-TYPE SYNTAX InetAddress (SIZE (4|16)) MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This object represents the private-realm specific network layer address which, in conjunction with natAddrPortBindLocalPort, maps to the public-realm network layer address and transport id represented by Perreault, et al. Expires December 01, 2013 [Page 29] Internet-Draft NEW NAT MIB May 2013 natAddrPortBindGlobalAddr and natAddrPortBindGlobalPort respectively. The type of this address is determined by the value of the natAddrPortBindLocalAddrType object." ::= { natAddrPortBindEntry 2 } natAddrPortBindLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "For a protocol value TCP or UDP, this object represents the private-realm specific port number. On the other hand, for ICMP a bind is created only for query/response type ICMP messages such as ICMP echo, Timestamp, and Information request messages, and this object represents the private-realm specific identifier in the ICMP message, as defined in RFC 792 for ICMPv4 and in RFC 2463 for ICMPv6. This object, together with natAddrPortBindProtocol, natAddrPortBindLocalAddrType, and natAddrPortBindLocalAddr, constitutes a session endpoint in the private realm. A bind entry binds a private realm specific endpoint to a public realm specific endpoint, as represented by the tuple of (natAddrPortBindGlobalPort, natAddrPortBindProtocol, natAddrPortBindGlobalAddrType, and natAddrPortBindGlobalAddr)." ::= { natAddrPortBindEntry 3 } natAddrPortBindProtocol OBJECT-TYPE SYNTAX NatProtocolType MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This object specifies a protocol identifier. If the value of this object is none(1), then this bind entry applies to all IP traffic. Any other value of this object specifies the class of IP traffic to which this BIND applies." ::= { natAddrPortBindEntry 4 } natAddrPortBindGlobalAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only Perreault, et al. Expires December 01, 2013 [Page 30] Internet-Draft NEW NAT MIB May 2013 STATUS deprecated DESCRIPTION "This object specifies the address type used for natAddrPortBindGlobalAddr." ::= { natAddrPortBindEntry 5 } natAddrPortBindGlobalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object represents the public-realm specific network layer address that, in conjunction with natAddrPortBindGlobalPort, maps to the private-realm network layer address and transport id represented by natAddrPortBindLocalAddr and natAddrPortBindLocalPort, respectively. The type of this address is determined by the value of the natAddrPortBindGlobalAddrType object." ::= { natAddrPortBindEntry 6 } natAddrPortBindGlobalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS deprecated DESCRIPTION "For a protocol value TCP or UDP, this object represents the public-realm specific port number. On the other hand, for ICMP a bind is created only for query/response type ICMP messages such as ICMP echo, Timestamp, and Information request messages, and this object represents the public-realm specific identifier in the ICMP message, as defined in RFC 792 for ICMPv4 and in RFC 2463 for ICMPv6. This object, together with natAddrPortBindProtocol, natAddrPortBindGlobalAddrType, and natAddrPortBindGlobalAddr, constitutes a session endpoint in the public realm. A bind entry binds a public realm specific endpoint to a private realm specific endpoint, as represented by the tuple of (natAddrPortBindLocalPort, natAddrPortBindProtocol, natAddrPortBindLocalAddrType, and natAddrPortBindLocalAddr)." ::= { natAddrPortBindEntry 7 } Perreault, et al. Expires December 01, 2013 [Page 31] Internet-Draft NEW NAT MIB May 2013 natAddrPortBindId OBJECT-TYPE SYNTAX NatBindId MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object represents a bind id that is dynamically assigned to each bind by a NAT enabled device. Each bind is represented by a unique bind id across both the natAddrBindTable and the natAddrPortBindTable." ::= { natAddrPortBindEntry 8 } natAddrPortBindTranslationEntity OBJECT-TYPE SYNTAX NatTranslationEntity MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object represents the direction of sessions for which this bind is applicable and the entity (source or destination) within the sessions that is subject to translation with the BIND. Orientation of the bind can be a superset of the translationEntity of the address map entry that forms the basis for this bind. For example, if the translationEntity of an address map entry is outboundSrcEndPoint, the translationEntity of a bind derived from this map entry may either be outboundSrcEndPoint or may be bidirectional (a bitmask of outboundSrcEndPoint and inboundDstEndPoint)." ::= { natAddrPortBindEntry 9 } natAddrPortBindType OBJECT-TYPE SYNTAX NatAssociationType MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object indicates whether the bind is static or dynamic." ::= { natAddrPortBindEntry 10 } natAddrPortBindMapIndex OBJECT-TYPE SYNTAX NatAddrMapId MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object is a pointer to the natAddrMapTable entry Perreault, et al. Expires December 01, 2013 [Page 32] Internet-Draft NEW NAT MIB May 2013 (and the parameters of that entry) used in creating this BIND. This object, in conjunction with the ifIndex (which identifies a unique addrMapName), points to a unique entry in the natAddrMapTable." ::= { natAddrPortBindEntry 11 } natAddrPortBindSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "Number of sessions currently using this BIND." ::= { natAddrPortBindEntry 12 } natAddrPortBindMaxIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object indicates the maximum time for which this bind can be idle without any sessions attached to it. The value of this object is of relevance only for dynamic NAT." ::= { natAddrPortBindEntry 13 } natAddrPortBindCurrentIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "At any given instance, this object indicates the time that this bind has been idle without any sessions attached to it. The value of this object is of relevance only for dynamic NAT." ::= { natAddrPortBindEntry 14 } natAddrPortBindInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of inbound packets that were translated as per this bind entry. Perreault, et al. Expires December 01, 2013 [Page 33] Internet-Draft NEW NAT MIB May 2013 Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrPortBindEntry 15 } natAddrPortBindOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of outbound packets that were translated as per this bind entry. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natAddrPortBindEntry 16 } -- -- The Session Table -- natSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF NatSessionEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The (conceptual) table containing one entry for each NAT session currently active on this NAT device." ::= { natMIBObjects 9 } natSessionEntry OBJECT-TYPE SYNTAX NatSessionEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry (conceptual row) containing information about an active NAT session on this NAT device. These entries are lost upon agent restart." INDEX { ifIndex, natSessionIndex } ::= { natSessionTable 1 } NatSessionEntry ::= SEQUENCE { natSessionIndex NatSessionId, natSessionPrivateSrcEPBindId NatBindIdOrZero, natSessionPrivateSrcEPBindMode NatBindMode, Perreault, et al. Expires December 01, 2013 [Page 34] Internet-Draft NEW NAT MIB May 2013 natSessionPrivateDstEPBindId NatBindIdOrZero, natSessionPrivateDstEPBindMode NatBindMode, natSessionDirection INTEGER, natSessionUpTime TimeTicks, natSessionAddrMapIndex NatAddrMapId, natSessionProtocolType NatProtocolType, natSessionPrivateAddrType InetAddressType, natSessionPrivateSrcAddr InetAddress, natSessionPrivateSrcPort InetPortNumber, natSessionPrivateDstAddr InetAddress, natSessionPrivateDstPort InetPortNumber, natSessionPublicAddrType InetAddressType, natSessionPublicSrcAddr InetAddress, natSessionPublicSrcPort InetPortNumber, natSessionPublicDstAddr InetAddress, natSessionPublicDstPort InetPortNumber, natSessionMaxIdleTime TimeTicks, natSessionCurrentIdleTime TimeTicks, natSessionInTranslates Counter64, natSessionOutTranslates Counter64 } natSessionIndex OBJECT-TYPE SYNTAX NatSessionId MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The session ID for this NAT session." ::= { natSessionEntry 1 } natSessionPrivateSrcEPBindId OBJECT-TYPE SYNTAX NatBindIdOrZero MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The bind id associated between private and public source end points. In the case of Symmetric-NAT, this should be set to zero." ::= { natSessionEntry 2 } natSessionPrivateSrcEPBindMode OBJECT-TYPE SYNTAX NatBindMode MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object indicates whether the bind indicated by the object natSessionPrivateSrcEPBindId is an address bind or an address port bind." Perreault, et al. Expires December 01, 2013 [Page 35] Internet-Draft NEW NAT MIB May 2013 ::= { natSessionEntry 3 } natSessionPrivateDstEPBindId OBJECT-TYPE SYNTAX NatBindIdOrZero MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The bind id associated between private and public destination end points." ::= { natSessionEntry 4 } natSessionPrivateDstEPBindMode OBJECT-TYPE SYNTAX NatBindMode MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object indicates whether the bind indicated by the object natSessionPrivateDstEPBindId is an address bind or an address port bind." ::= { natSessionEntry 5 } natSessionDirection OBJECT-TYPE SYNTAX INTEGER { inbound (1), outbound (2) } MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The direction of this session with respect to the local network. 'inbound' indicates that this session was initiated from the public network into the private network. 'outbound' indicates that this session was initiated from the private network into the public network." ::= { natSessionEntry 6 } natSessionUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The up time of this session in one-hundredths of a second." ::= { natSessionEntry 7 } natSessionAddrMapIndex OBJECT-TYPE Perreault, et al. Expires December 01, 2013 [Page 36] Internet-Draft NEW NAT MIB May 2013 SYNTAX NatAddrMapId MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object is a pointer to the natAddrMapTable entry (and the parameters of that entry) used in creating this session. This object, in conjunction with the ifIndex (which identifies a unique addrMapName), points to a unique entry in the natAddrMapTable." ::= { natSessionEntry 8 } natSessionProtocolType OBJECT-TYPE SYNTAX NatProtocolType MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The protocol type of this session." ::= { natSessionEntry 9 } natSessionPrivateAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object specifies the address type used for natSessionPrivateSrcAddr and natSessionPrivateDstAddr." ::= { natSessionEntry 10 } natSessionPrivateSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The source IP address of the session endpoint that lies in the private network. The value of this object must be zero only when the natSessionPrivateSrcEPBindId object has a zero value. When the value of this object is zero, the NAT session lookup will match any IP address to this field. The type of this address is determined by the value of the natSessionPrivateAddrType object." ::= { natSessionEntry 11 } natSessionPrivateSrcPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only Perreault, et al. Expires December 01, 2013 [Page 37] Internet-Draft NEW NAT MIB May 2013 STATUS deprecated DESCRIPTION "When the value of protocol is TCP or UDP, this object represents the source port in the first packet of session while in private-realm. On the other hand, when the protocol is ICMP, a NAT session is created only for query/response type ICMP messages such as ICMP echo, Timestamp, and Information request messages, and this object represents the private-realm specific identifier in the ICMP message, as defined in RFC 792 for ICMPv4 and in RFC 2463 for ICMPv6. The value of this object must be zero when the natSessionPrivateSrcEPBindId object has zero value and value of natSessionPrivateSrcEPBindMode is addressPortBind(2). In such a case, the NAT session lookup will match any port number to this field. The value of this object must be zero when the object is not a representative field (SrcPort, DstPort, or ICMP identifier) of the session tuple in either the public realm or the private realm." ::= { natSessionEntry 12 } natSessionPrivateDstAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The destination IP address of the session endpoint that lies in the private network. The value of this object must be zero when the natSessionPrivateDstEPBindId object has a zero value. In such a scenario, the NAT session lookup will match any IP address to this field. The type of this address is determined by the value of the natSessionPrivateAddrType object." ::= { natSessionEntry 13 } natSessionPrivateDstPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS deprecated DESCRIPTION "When the value of protocol is TCP or UDP, this object represents the destination port in the first packet Perreault, et al. Expires December 01, 2013 [Page 38] Internet-Draft NEW NAT MIB May 2013 of session while in private-realm. On the other hand, when the protocol is ICMP, this object is not relevant and should be set to zero. The value of this object must be zero when the natSessionPrivateDstEPBindId object has a zero value and natSessionPrivateDstEPBindMode is set to addressPortBind(2). In such a case, the NAT session lookup will match any port number to this field. The value of this object must be zero when the object is not a representative field (SrcPort, DstPort, or ICMP identifier) of the session tuple in either the public realm or the private realm." ::= { natSessionEntry 14 } natSessionPublicAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object specifies the address type used for natSessionPublicSrcAddr and natSessionPublicDstAddr." ::= { natSessionEntry 15 } natSessionPublicSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The source IP address of the session endpoint that lies in the public network. The value of this object must be zero when the natSessionPrivateSrcEPBindId object has a zero value. In such a scenario, the NAT session lookup will match any IP address to this field. The type of this address is determined by the value of the natSessionPublicAddrType object." ::= { natSessionEntry 16 } natSessionPublicSrcPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS deprecated DESCRIPTION "When the value of protocol is TCP or UDP, this object Perreault, et al. Expires December 01, 2013 [Page 39] Internet-Draft NEW NAT MIB May 2013 represents the source port in the first packet of session while in public-realm. On the other hand, when protocol is ICMP, a NAT session is created only for query/response type ICMP messages such as ICMP echo, Timestamp, and Information request messages, and this object represents the public-realm specific identifier in the ICMP message, as defined in RFC 792 for ICMPv4 and in RFC 2463 for ICMPv6. The value of this object must be zero when the natSessionPrivateSrcEPBindId object has a zero value and natSessionPrivateSrcEPBindMode is set to addressPortBind(2). In such a scenario, the NAT session lookup will match any port number to this field. The value of this object must be zero when the object is not a representative field (SrcPort, DstPort or ICMP identifier) of the session tuple in either the public realm or the private realm." ::= { natSessionEntry 17 } natSessionPublicDstAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The destination IP address of the session endpoint that lies in the public network. The value of this object must be non-zero when the natSessionPrivateDstEPBindId object has a non-zero value. If the value of this object and the corresponding natSessionPrivateDstEPBindId object value is zero, then the NAT session lookup will match any IP address to this field. The type of this address is determined by the value of the natSessionPublicAddrType object." ::= { natSessionEntry 18 } natSessionPublicDstPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS deprecated DESCRIPTION "When the value of protocol is TCP or UDP, this object represents the destination port in the first packet of Perreault, et al. Expires December 01, 2013 [Page 40] Internet-Draft NEW NAT MIB May 2013 session while in public-realm. On the other hand, when the protocol is ICMP, this object is not relevant for translation and should be zero. The value of this object must be zero when the natSessionPrivateDstEPBindId object has a zero value and natSessionPrivateDstEPBindMode is addressPortBind(2). In such a scenario, the NAT session lookup will match any port number to this field. The value of this object must be zero when the object is not a representative field (SrcPort, DstPort, or ICMP identifier) of the session tuple in either the public realm or the private realm." ::= { natSessionEntry 19 } natSessionMaxIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The max time for which this session can be idle without detecting a packet." ::= { natSessionEntry 20 } natSessionCurrentIdleTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The time since a packet belonging to this session was last detected." ::= { natSessionEntry 21 } natSessionInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of inbound packets that were translated for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natSessionEntry 22 } Perreault, et al. Expires December 01, 2013 [Page 41] Internet-Draft NEW NAT MIB May 2013 natSessionOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of outbound packets that were translated for this session. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natSessionEntry 23 } -- -- The Protocol table -- natProtocolTable OBJECT-TYPE SYNTAX SEQUENCE OF NatProtocolEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "The (conceptual) table containing per protocol NAT statistics." ::= { natMIBObjects 10 } natProtocolEntry OBJECT-TYPE SYNTAX NatProtocolEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An entry (conceptual row) containing NAT statistics pertaining to a particular protocol." INDEX { natProtocol } ::= { natProtocolTable 1 } NatProtocolEntry ::= SEQUENCE { natProtocol NatProtocolType, natProtocolInTranslates Counter64, natProtocolOutTranslates Counter64, natProtocolDiscards Counter64 } natProtocol OBJECT-TYPE SYNTAX NatProtocolType MAX-ACCESS not-accessible STATUS deprecated Perreault, et al. Expires December 01, 2013 [Page 42] Internet-Draft NEW NAT MIB May 2013 DESCRIPTION "This object represents the protocol pertaining to which parameters are reported." ::= { natProtocolEntry 1 } natProtocolInTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of inbound packets pertaining to the protocol identified by natProtocol that underwent NAT. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natProtocolEntry 2 } natProtocolOutTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of outbound packets pertaining to the protocol identified by natProtocol that underwent NAT. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." ::= { natProtocolEntry 3 } natProtocolDiscards OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of packets pertaining to the protocol identified by natProtocol that had to be rejected/dropped due to lack of resources. These rejections could be due to session timeout, resource unavailability, lack of address space, etc. Discontinuities in the value of this counter can occur at reinitialization of the management system and at other times, as indicated by the value of ifCounterDiscontinuityTime on the relevant interface." Perreault, et al. Expires December 01, 2013 [Page 43] Internet-Draft NEW NAT MIB May 2013 ::= { natProtocolEntry 4 } -- -- Notifications section -- natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 } -- -- Notifications -- natPacketDiscard NOTIFICATION-TYPE OBJECTS { ifIndex } STATUS deprecated DESCRIPTION "This notification is generated when IP packets are discarded by the NAT function; e.g., due to lack of mapping space when NAT is out of addresses or ports. Note that the generation of natPacketDiscard notifications is throttled by the agent, as specified by the 'natNotifThrottlingInterval' object." ::= { natMIBNotifications 1 } -- -- Conformance information. -- natMIBConformance OBJECT IDENTIFIER ::= { natMIB 2 } natMIBGroups OBJECT IDENTIFIER ::= { natMIBConformance 1 } natMIBCompliances OBJECT IDENTIFIER ::= { natMIBConformance 2 } -- -- Units of conformance -- natConfigGroup OBJECT-GROUP OBJECTS { natInterfaceRealm, natInterfaceServiceType, natInterfaceStorageType, natInterfaceRowStatus, natAddrMapName, natAddrMapEntryType, natAddrMapTranslationEntity, Perreault, et al. Expires December 01, 2013 [Page 44] Internet-Draft NEW NAT MIB May 2013 natAddrMapLocalAddrType, natAddrMapLocalAddrFrom, natAddrMapLocalAddrTo, natAddrMapLocalPortFrom, natAddrMapLocalPortTo, natAddrMapGlobalAddrType, natAddrMapGlobalAddrFrom, natAddrMapGlobalAddrTo, natAddrMapGlobalPortFrom, natAddrMapGlobalPortTo, natAddrMapProtocol, natAddrMapStorageType, natAddrMapRowStatus, natBindDefIdleTimeout, natUdpDefIdleTimeout, natIcmpDefIdleTimeout, natOtherDefIdleTimeout, natTcpDefIdleTimeout, natTcpDefNegTimeout, natNotifThrottlingInterval } STATUS deprecated DESCRIPTION "A collection of configuration-related information required to support management of devices supporting NAT." ::= { natMIBGroups 1 } natTranslationGroup OBJECT-GROUP OBJECTS { natAddrBindNumberOfEntries, natAddrBindGlobalAddrType, natAddrBindGlobalAddr, natAddrBindId, natAddrBindTranslationEntity, natAddrBindType, natAddrBindMapIndex, natAddrBindSessions, natAddrBindMaxIdleTime, natAddrBindCurrentIdleTime, natAddrBindInTranslates, natAddrBindOutTranslates, natAddrPortBindNumberOfEntries, natAddrPortBindGlobalAddrType, natAddrPortBindGlobalAddr, natAddrPortBindGlobalPort, natAddrPortBindId, natAddrPortBindTranslationEntity, natAddrPortBindType, natAddrPortBindMapIndex, Perreault, et al. Expires December 01, 2013 [Page 45] Internet-Draft NEW NAT MIB May 2013 natAddrPortBindSessions, natAddrPortBindMaxIdleTime, natAddrPortBindCurrentIdleTime, natAddrPortBindInTranslates, natAddrPortBindOutTranslates, natSessionPrivateSrcEPBindId, natSessionPrivateSrcEPBindMode, natSessionPrivateDstEPBindId, natSessionPrivateDstEPBindMode, natSessionDirection, natSessionUpTime, natSessionAddrMapIndex, natSessionProtocolType, natSessionPrivateAddrType, natSessionPrivateSrcAddr, natSessionPrivateSrcPort, natSessionPrivateDstAddr, natSessionPrivateDstPort, natSessionPublicAddrType, natSessionPublicSrcAddr, natSessionPublicSrcPort, natSessionPublicDstAddr, natSessionPublicDstPort, natSessionMaxIdleTime, natSessionCurrentIdleTime, natSessionInTranslates, natSessionOutTranslates } STATUS deprecated DESCRIPTION "A collection of BIND-related objects required to support management of devices supporting NAT." ::= { natMIBGroups 2 } natStatsInterfaceGroup OBJECT-GROUP OBJECTS { natInterfaceInTranslates, natInterfaceOutTranslates, natInterfaceDiscards } STATUS deprecated DESCRIPTION "A collection of NAT statistics associated with the interface on which NAT is configured, to aid troubleshooting/monitoring of the NAT operation." ::= { natMIBGroups 3 } natStatsProtocolGroup OBJECT-GROUP OBJECTS { natProtocolInTranslates, natProtocolOutTranslates, Perreault, et al. Expires December 01, 2013 [Page 46] Internet-Draft NEW NAT MIB May 2013 natProtocolDiscards } STATUS deprecated DESCRIPTION "A collection of protocol specific NAT statistics, to aid troubleshooting/monitoring of NAT operation." ::= { natMIBGroups 4 } natStatsAddrMapGroup OBJECT-GROUP OBJECTS { natAddrMapInTranslates, natAddrMapOutTranslates, natAddrMapDiscards, natAddrMapAddrUsed } STATUS deprecated DESCRIPTION "A collection of address map specific NAT statistics, to aid troubleshooting/monitoring of NAT operation." ::= { natMIBGroups 5 } natMIBNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { natPacketDiscard } STATUS deprecated DESCRIPTION "A collection of notifications generated by devices supporting this MIB." ::= { natMIBGroups 6 } -- -- Compliance statements -- natMIBFullCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "When this MIB is implemented with support for read-create, then such an implementation can claim full compliance. Such devices can then be both monitored and configured with this MIB. The following index objects cannot be added as OBJECT clauses but nevertheless have the compliance requirements: " -- OBJECT natAddrBindLocalAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending Perreault, et al. Expires December 01, 2013 [Page 47] Internet-Draft NEW NAT MIB May 2013 -- on its support for IPv4 and IPv6." -- OBJECT natAddrBindLocalAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrPortBindLocalAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrPortBindLocalAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." MODULE IF-MIB -- The interfaces MIB, RFC2863 MANDATORY-GROUPS { ifCounterDiscontinuityGroup } MODULE -- this module MANDATORY-GROUPS { natConfigGroup, natTranslationGroup, natStatsInterfaceGroup } GROUP natStatsProtocolGroup DESCRIPTION "This group is optional." GROUP natStatsAddrMapGroup DESCRIPTION "This group is optional." GROUP natMIBNotificationGroup DESCRIPTION "This group is optional." OBJECT natAddrMapLocalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." Perreault, et al. Expires December 01, 2013 [Page 48] Internet-Draft NEW NAT MIB May 2013 OBJECT natAddrMapLocalAddrFrom SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapLocalAddrTo SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrFrom SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrTo SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrBindGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrBindGlobalAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." Perreault, et al. Expires December 01, 2013 [Page 49] Internet-Draft NEW NAT MIB May 2013 OBJECT natAddrPortBindGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrPortBindGlobalAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateSrcAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateDstAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicSrcAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support Perreault, et al. Expires December 01, 2013 [Page 50] Internet-Draft NEW NAT MIB May 2013 for IPv4 and IPv6." OBJECT natSessionPublicDstAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." ::= { natMIBCompliances 1 } natMIBReadOnlyCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "When this MIB is implemented without support for read-create (i.e., in read-only mode), then such an implementation can claim read-only compliance. Such a device can then be monitored but cannot be configured with this MIB. The following index objects cannot be added as OBJECT clauses but nevertheless have the compliance requirements: " -- OBJECT natAddrBindLocalAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrBindLocalAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrPortBindLocalAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- DESCRIPTION -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." -- OBJECT natAddrPortBindLocalAddr -- SYNTAX InetAddress (SIZE(4|16)) -- DESCRIPTION Perreault, et al. Expires December 01, 2013 [Page 51] Internet-Draft NEW NAT MIB May 2013 -- "An implementation is required to support -- global IPv4 and/or IPv6 addresses, depending -- on its support for IPv4 and IPv6." MODULE IF-MIB -- The interfaces MIB, RFC2863 MANDATORY-GROUPS { ifCounterDiscontinuityGroup } MODULE -- this module MANDATORY-GROUPS { natConfigGroup, natTranslationGroup, natStatsInterfaceGroup } GROUP natStatsProtocolGroup DESCRIPTION "This group is optional." GROUP natStatsAddrMapGroup DESCRIPTION "This group is optional." GROUP natMIBNotificationGroup DESCRIPTION "This group is optional." OBJECT natInterfaceRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT natAddrMapLocalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapLocalAddrFrom SYNTAX InetAddress (SIZE(4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapLocalAddrTo SYNTAX InetAddress (SIZE(4|16)) MIN-ACCESS read-only Perreault, et al. Expires December 01, 2013 [Page 52] Internet-Draft NEW NAT MIB May 2013 DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrFrom SYNTAX InetAddress (SIZE(4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapGlobalAddrTo SYNTAX InetAddress (SIZE(4|16)) MIN-ACCESS read-only DESCRIPTION "Write access is not required. An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrMapRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT natAddrBindGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrBindGlobalAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for Perreault, et al. Expires December 01, 2013 [Page 53] Internet-Draft NEW NAT MIB May 2013 IPv4 and IPv6." OBJECT natAddrPortBindGlobalAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natAddrPortBindGlobalAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateSrcAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPrivateDstAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicAddrType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicSrcAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 Perreault, et al. Expires December 01, 2013 [Page 54] Internet-Draft NEW NAT MIB May 2013 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." OBJECT natSessionPublicDstAddr SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is required to support global IPv4 and/or IPv6 addresses, depending on its support for IPv4 and IPv6." ::= { natMIBCompliances 2 } --=================================================================== -- END OF DEPRECATED OBJECTS. CURRENT OBJECTS FOLLOW. -- textual conventions ProtocolNumber ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A transport protocol number, from the 'protocol-numbers' IANA registry." SYNTAX Unsigned32 (0..255) NatPoolId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique ID that is assigned to each pool." SYNTAX Unsigned32 (1..4294967295) NatBehaviorType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Behavior type as described in [RFC4787] sections 4.1 and 5." SYNTAX INTEGER { endpointIndependent (0), addressDependent (1), addressAndPortDependent (2) } NatPoolingType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Pooling type as described in [RFC4787] sections 4.1." Perreault, et al. Expires December 01, 2013 [Page 55] Internet-Draft NEW NAT MIB May 2013 SYNTAX INTEGER { arbitrary (0), paired (1) } -- notifications natNotifPoolWatermarkLow NOTIFICATION-TYPE OBJECTS { natPoolIndex } STATUS current DESCRIPTION "This notification is generated when the specified pool's number of free addresses becomes lower than or equal to the specified threshold. The threshold is specified by the natPoolWatermarkLow object" ::= { natMIBNotifications 2 } natNotifPoolWatermarkHigh NOTIFICATION-TYPE OBJECTS { natPoolIndex } STATUS current DESCRIPTION "This notification is generated when the specified pool's number of free addresses becomes greater than or equal to the specified threshold. The threshold is specified by the natPoolWatermarkHigh object" ::= { natMIBNotifications 3 } natNotifMappings NOTIFICATION-TYPE OBJECTS { natCntMappings } STATUS current DESCRIPTION "This notification is generated when natCntMappings exceeds the value of natMappingsNotifyThreshold." ::= { natMIBNotifications 4 } natNotifAddrMappings NOTIFICATION-TYPE OBJECTS { natCntAddressMappings } STATUS current DESCRIPTION "This notification is generated when natCntAddressMappings exceeds the value of natAddrMapNotifyThreshold." ::= { natMIBNotifications 5 } natNotifSubscriberMappings NOTIFICATION-TYPE OBJECTS { natSubscriberCntMappings } STATUS current DESCRIPTION Perreault, et al. Expires December 01, 2013 [Page 56] Internet-Draft NEW NAT MIB May 2013 "This notification is generated when natSubscriberCntMappings exceeds the value of natSubscriberMapNotifyThresh, unless natSubscriberMapNotifyThresh is zero.." ::= { natMIBNotifications 6 } -- counters natCounters OBJECT IDENTIFIER ::= { natMIBObjects 11 } natCntTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT has been applied." ::= { natCounters 1 } natCntOOP OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT could not be applied because no external port was available, excluding quota limitations." ::= { natCounters 2 } natCntResource OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT could not be applied because of resource constraints (excluding out-of-ports condition)." ::= { natCounters 3 } natCntStateMismatch OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT could not be applied because of mapping state mismatch. For example, a TCP packet that matches an existing mapping but is dropped because its flags are incompatible with the current state of the mapping would cause this counter to be incremented." Perreault, et al. Expires December 01, 2013 [Page 57] Internet-Draft NEW NAT MIB May 2013 ::= { natCounters 4 } natCntQuota OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT could not be applied because of quota limitations. Quotas include absolute limits as well as limits on rate of allocation." ::= { natCounters 5 } natCntMappings OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of currently active mappings. Equal to natCntMapRemovals - natCntMapCreations." ::= { natCounters 6 } natCntMapCreations OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of mapping creations. This includes static mappings." ::= { natCounters 7 } natCntMapRemovals OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of mapping removals. This includes static mappings." ::= { natCounters 8 } natCntAddressMappings OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of active address mappings. Equal to natCntAddrMapRemovals - natCntAddrMapCreations." ::= { natCounters 9 } Perreault, et al. Expires December 01, 2013 [Page 58] Internet-Draft NEW NAT MIB May 2013 natCntAddrMapCreations OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of address mapping creations. This includes static mappings." ::= { natCounters 10 } natCntAddrMapRemovals OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of address mapping removals. This includes static mappings." ::= { natCounters 11 } natCntProtocolTable OBJECT-TYPE SYNTAX SEQUENCE OF NatCntProtocolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of protocols with per-protocol counters." ::= { natCounters 128 } natCntProtocolEntry OBJECT-TYPE SYNTAX NatCntProtocolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Per-protocol counters." INDEX { natCntProtocolNumber } ::= { natCntProtocolTable 1 } NatCntProtocolEntry ::= SEQUENCE { natCntProtocolNumber ProtocolNumber, natCntProtocolTranslates Counter64, natCntProtocolOOP Counter64, natCntProtocolResource Counter64, natCntProtocolStateMismatch Counter64, natCntProtocolQuota Counter64, natCntProtocolMappings Gauge32, natCntProtocolMapCreations Counter64, natCntProtocolMapRemovals Counter64 } Perreault, et al. Expires December 01, 2013 [Page 59] Internet-Draft NEW NAT MIB May 2013 natCntProtocolNumber OBJECT-TYPE SYNTAX ProtocolNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "Counters in this conceptual row apply to packets using the transport protocol identified by this object's value." ::= { natCntProtocolEntry 1 } natCntProtocolTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT has been applied." ::= { natCntProtocolEntry 2 } natCntProtocolOOP OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT could not be applied because no external port was available." ::= { natCntProtocolEntry 3 } natCntProtocolResource OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT could not be applied because of resource constraints (excluding out-of-ports condition)." ::= { natCntProtocolEntry 4 } natCntProtocolStateMismatch OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT could not be applied because of state table mismatch. For example, a TCP packet that matches an existing mapping but is dropped because its flags are incompatible with the current state of the mapping would cause this counter to be incremented." ::= { natCntProtocolEntry 5 } Perreault, et al. Expires December 01, 2013 [Page 60] Internet-Draft NEW NAT MIB May 2013 natCntProtocolQuota OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets to which NAT could not be applied because of exceeded quotas. Quotas include absolute limits as well as limits on rate of allocation." ::= { natCntProtocolEntry 6 } natCntProtocolMappings OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of active mappings. Equal to natCntMapRemovals - natCntMapCreations." ::= { natCntProtocolEntry 7 } natCntProtocolMapCreations OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of mapping creations. This includes static mappings." ::= { natCntProtocolEntry 8 } natCntProtocolMapRemovals OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of mapping removals. This includes statis mappings." ::= { natCntProtocolEntry 9 } -- limits natLimits OBJECT IDENTIFIER ::= { natMIBObjects 12 } natLimitMappings OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Global limit on the total number of mappings. Zero means unlimited." Perreault, et al. Expires December 01, 2013 [Page 61] Internet-Draft NEW NAT MIB May 2013 ::= { natLimits 1 } natMappingsNotifyThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "See natNotifMappings." ::= { natLimits 2 } natLimitAddressMappings OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Global limit on the total number of internal-to-external address mappings. Zero means unlimited. This limit is only applicable to NATs that have an 'IP address pooling' behavior of 'Paired' [RFC4787]." ::= { natLimits 3 } natAddrMapNotifyThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "See natNotifAddrMappings." ::= { natLimits 4 } natLimitFragments OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Global limit on the total number of fragments pending reassembly. Zero means unlimited. This limit is only applicable to NATs having 'Receive Fragments Out of Order' behavior [RFC4787]." ::= { natLimits 5 } natLimitSubscribers OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Global limit on the number of subscribers with active Perreault, et al. Expires December 01, 2013 [Page 62] Internet-Draft NEW NAT MIB May 2013 mappings. Zero means unlimited." ::= { natLimits 6 } -- pools natPoolObjects OBJECT IDENTIFIER ::= { natMIBObjects 13 } natPoolTable OBJECT-TYPE SYNTAX SEQUENCE OF NatPoolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of pools." ::= { natPoolObjects 1 } natPoolEntry OBJECT-TYPE SYNTAX NatPoolEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry in the table of pools." INDEX { natPoolIndex } ::= { natPoolTable 1 } NatPoolEntry ::= SEQUENCE { natPoolIndex NatPoolId, natPoolRealm SnmpAdminString, natPoolUsage Integer32, natPoolWatermarkLow Integer32, natPoolWatermarkHigh Integer32, natPoolPortMin InetPortNumber, natPoolPortMax InetPortNumber } natPoolIndex OBJECT-TYPE SYNTAX NatPoolId MAX-ACCESS read-only STATUS current DESCRIPTION "Index of an address pool." ::= { natPoolEntry 1 } natPoolRealm OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only Perreault, et al. Expires December 01, 2013 [Page 63] Internet-Draft NEW NAT MIB May 2013 STATUS current DESCRIPTION "Realm to which this pool's addresses belong." ::= { natPoolEntry 2 } natPoolUsage OBJECT-TYPE SYNTAX Integer32 (0..100) MAX-ACCESS read-only STATUS current DESCRIPTION "Percentage of the pool's total number of external ports currently mapped." ::= { natPoolEntry 3 } natPoolWatermarkLow OBJECT-TYPE SYNTAX Integer32 (-1|0..100) MAX-ACCESS read-create STATUS current DESCRIPTION "Low watermark on a pool's usage, in percentage of the total number of ports available. If set to -1, the watermark is disabled. Otherwise when natPoolUsage becomes lower than or equal to natPoolWatermarkLow, a notification is sent. The NAT may also start behaving in low usage mode (this is implementation-defined)." ::= { natPoolEntry 4 } natPoolWatermarkHigh OBJECT-TYPE SYNTAX Integer32 (-1|0..100) MAX-ACCESS read-create STATUS current DESCRIPTION "High watermark on a pool's usage, in percentage of the total number of ports available. If set to -1, the watermark is disabled. Otherwise, when natPoolUsage becomes higher than or equal to natPoolWatermarkHigh, a notification is sent. The NAT may also start behaving in high usage mode (this is implementation-defined)." ::= { natPoolEntry 5 } natPoolPortMin OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "Minimal port number to be allocated in this pool." ::= { natPoolEntry 6 } Perreault, et al. Expires December 01, 2013 [Page 64] Internet-Draft NEW NAT MIB May 2013 natPoolPortMax OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "Maximal port number to be allocated in this pool." ::= { natPoolEntry 7 } natPoolRangeTable OBJECT-TYPE SYNTAX SEQUENCE OF NatPoolRangeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains address ranges used by pool entries." ::= { natPoolObjects 2 } natPoolRangeEntry OBJECT-TYPE SYNTAX NatPoolRangeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "NAT pool address range." INDEX { natPoolRangeType, natPoolRangeBegin } ::= { natPoolRangeTable 1 } NatPoolRangeEntry ::= SEQUENCE { natPoolRangePoolIndex NatPoolId, natPoolRangeType InetAddressType, natPoolRangeBegin InetAddress, natPoolRangeEnd InetAddress, natPoolRangeAllocatedPorts Gauge32 } natPoolRangePoolIndex OBJECT-TYPE SYNTAX NatPoolId MAX-ACCESS read-only STATUS current DESCRIPTION "Index of the address pool to which this address range belongs. See natPoolIndex." ::= { natPoolRangeEntry 1 } natPoolRangeType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible Perreault, et al. Expires December 01, 2013 [Page 65] Internet-Draft NEW NAT MIB May 2013 STATUS current DESCRIPTION "The address type of natPoolRangeBegin and natPoolRangeEnd." ::= { natPoolRangeEntry 2 } natPoolRangeBegin OBJECT-TYPE SYNTAX InetAddress (SIZE (4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Lowest address included in this range." ::= { natPoolRangeEntry 3 } natPoolRangeEnd OBJECT-TYPE SYNTAX InetAddress (SIZE (4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "Highest address included in this range." ::= { natPoolRangeEntry 4 } natPoolRangeAllocatedPorts OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of ports currently allocated on the addresses in this range." ::= { natPoolRangeEntry 5 } -- indexed mapping tables natMapObjects OBJECT IDENTIFIER ::= { natMIBObjects 14 } natMapIntAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF NatMapIntAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of mappings from internal to external address. This table is only applicable to NATs that have an 'IP address pooling' behavior of 'Paired' [RFC4787]." ::= { natMapObjects 1 } natMapIntAddrEntry OBJECT-TYPE Perreault, et al. Expires December 01, 2013 [Page 66] Internet-Draft NEW NAT MIB May 2013 SYNTAX NatMapIntAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Mapping from internal to external address." INDEX { natMapIntAddrIntRealm, natMapIntAddrType, natMapIntAddrInt } ::= { natMapIntAddrTable 1 } NatMapIntAddrEntry ::= SEQUENCE { natMapIntAddrIntRealm SnmpAdminString, natMapIntAddrExtRealm SnmpAdminString, natMapIntAddrType InetAddressType, natMapIntAddrInt InetAddress, natMapIntAddrExt InetAddress } natMapIntAddrIntRealm OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Realm to which natMapIntAddrInt belongs." ::= { natMapIntAddrEntry 1 } natMapIntAddrExtRealm OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Realm to which natMapIntAddrExt belongs." ::= { natMapIntAddrEntry 2 } natMapIntAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Address type for natMapIntAddrInt and natMapIntAddrExt." ::= { natMapIntAddrEntry 3 } natMapIntAddrInt OBJECT-TYPE SYNTAX InetAddress (SIZE (4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Perreault, et al. Expires December 01, 2013 [Page 67] Internet-Draft NEW NAT MIB May 2013 "Internal address." ::= { natMapIntAddrEntry 4 } natMapIntAddrExt OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "External address." ::= { natMapIntAddrEntry 5 } natMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF NatMappingTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of mappings indexed by external 3-tuple." ::= { natMapObjects 2 } natMappingTableEntry OBJECT-TYPE SYNTAX NatMappingTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single NAT mapping." INDEX { natMappingProto, natMappingExtRealm, natMappingExtAddressType, natMappingExtAddress, natMappingExtPort } ::= { natMappingTable 1 } NatMappingTableEntry ::= SEQUENCE { natMappingProto ProtocolNumber, natMappingExtRealm SnmpAdminString, natMappingExtAddressType InetAddressType, natMappingExtAddress InetAddress, natMappingExtPort InetPortNumber, natMappingIntRealm SnmpAdminString, natMappingIntAddressType InetAddressType, natMappingIntAddress InetAddress, natMappingIntPort InetPortNumber, natMappingPool NatPoolId, natMappingMapBehavior NatBehaviorType, natMappingFilterBehavior NatBehaviorType, natMappingAddressPooling NatPoolingType } Perreault, et al. Expires December 01, 2013 [Page 68] Internet-Draft NEW NAT MIB May 2013 natMappingProto OBJECT-TYPE SYNTAX ProtocolNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mapping's transport protocol number." ::= { natMappingTableEntry 1 } natMappingExtRealm OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The realm to which natMappingExtAddress belongs." ::= { natMappingTableEntry 2 } natMappingExtAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Type of the mapping's external address." ::= { natMappingTableEntry 3 } natMappingExtAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mapping's external address. If this is the undefined address, all external addresses are mapped to the internal address." ::= { natMappingTableEntry 4 } natMappingExtPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mapping's external port number. If this is zero, all external ports are mapped to the internal port." ::= { natMappingTableEntry 5 } natMappingIntRealm OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION Perreault, et al. Expires December 01, 2013 [Page 69] Internet-Draft NEW NAT MIB May 2013 "The realm to which natMappingIntAddress belongs." ::= { natMappingTableEntry 6 } natMappingIntAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Type of the mapping's internal address." ::= { natMappingTableEntry 7 } natMappingIntAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The mapping's internal address. If this is the undefined address, addresses are not translated." ::= { natMappingTableEntry 8 } natMappingIntPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The mapping's internal port number. If this is zero, ports are not translated." ::= { natMappingTableEntry 9 } natMappingPool OBJECT-TYPE SYNTAX Unsigned32 (0|1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "Index of the pool that contains this mapping's external address and port. If zero, no pool is associated with this mapping." ::= { natMappingTableEntry 10 } natMappingMapBehavior OBJECT-TYPE SYNTAX NatBehaviorType MAX-ACCESS read-only STATUS current DESCRIPTION "Mapping behavior as described in [RFC4787] section 4.1." ::= { natMappingTableEntry 11 } natMappingFilterBehavior OBJECT-TYPE Perreault, et al. Expires December 01, 2013 [Page 70] Internet-Draft NEW NAT MIB May 2013 SYNTAX NatBehaviorType MAX-ACCESS read-only STATUS current DESCRIPTION "Filtering behavior as described in [RFC4787] section 5." ::= { natMappingTableEntry 12 } natMappingAddressPooling OBJECT-TYPE SYNTAX NatPoolingType MAX-ACCESS read-only STATUS current DESCRIPTION "Type of address pooling behavior that was used to create this mapping." ::= { natMappingTableEntry 13 } -- subscribers natSubscribers OBJECT IDENTIFIER ::= { natMIBObjects 15 } natSubscribersTable OBJECT-TYPE SYNTAX SEQUENCE OF NatSubscribersTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of CGN subscribers." ::= { natSubscribers 1 } natSubscribersTableEntry OBJECT-TYPE SYNTAX NatSubscribersTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry describes a single CGN subscriber." INDEX { natSubscriberIdentifierType, natSubscriberIdentifier } ::= { natSubscribersTable 1 } NatSubscribersTableEntry ::= SEQUENCE { natSubscriberIdentifierType InetAddressType, natSubscriberIdentifier InetAddress, natSubscriberIntPrefixType InetAddressType, natSubscriberIntPrefix InetAddress, natSubscriberIntPrefixLength InetAddressPrefixLength, natSubscriberPool NatPoolId, natSubscriberCntTranslates Counter64, natSubscriberCntOOP Counter64, Perreault, et al. Expires December 01, 2013 [Page 71] Internet-Draft NEW NAT MIB May 2013 natSubscriberCntResource Counter64, natSubscriberCntStateMismatch Counter64, natSubscriberCntQuota Counter64, natSubscriberCntMappings Gauge32, natSubscriberCntMapCreations Counter64, natSubscriberCntMapRemovals Counter64, natSubscriberLimitMappings Unsigned32, natSubscriberMapNotifyThresh Unsigned32 } natSubscriberIdentifierType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Address type of the subscriber identifier." ::= { natSubscribersTableEntry 1 } natSubscriberIdentifier OBJECT-TYPE SYNTAX InetAddress (SIZE (4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Address used for uniquely identifying the subscriber. In traditional NAT, this is the internal address assigned to the CPE. In case an address range is assigned to a subscriber, the first address in the range is used as identifier. For tunnelled connectivity (e.g., DS-Lite [RFC6333]), the outer address is used as identifier (i.e., the IPv6 address in the case of DS-Lite)." ::= { natSubscribersTableEntry 2 } natSubscriberIntPrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Subscriber's internal prefix type." ::= { natSubscribersTableEntry 3 } natSubscriberIntPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Prefix assigned to a subscriber's CPE." ::= { natSubscribersTableEntry 4 } Perreault, et al. Expires December 01, 2013 [Page 72] Internet-Draft NEW NAT MIB May 2013 natSubscriberIntPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "Length of the prefix assigned to a subscriber's CPE, in bits. In case a single address is assigned, this will be 32 for IPv4 and 128 for IPv6." ::= { natSubscribersTableEntry 5 } natSubscriberPool OBJECT-TYPE SYNTAX NatPoolId MAX-ACCESS read-only STATUS current DESCRIPTION "External address pool to which this subscriber belongs." ::= { natSubscribersTableEntry 6 } natSubscriberCntTranslates OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received from or sent to this subscriber and to which NAT has been applied." ::= { natSubscribersTableEntry 7 } natSubscriberCntOOP OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received from this subscriber to which NAT could not be applied because no external port was available, excluding quota limitations." ::= { natSubscribersTableEntry 8 } natSubscriberCntResource OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received from this subscriber to which NAT could not be applied because of resource constraints (excluding out-of-ports condition)." ::= { natSubscribersTableEntry 9 } natSubscriberCntStateMismatch OBJECT-TYPE Perreault, et al. Expires December 01, 2013 [Page 73] Internet-Draft NEW NAT MIB May 2013 SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received from or destined to this subscriber to which NAT could not be applied because of mapping state mismatch. For example, a TCP packet that matches an existing mapping but is dropped because its flags are incompatible with the current state of the mapping would cause this counter to be incremented." ::= { natSubscribersTableEntry 10 } natSubscriberCntQuota OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received from or destined to this subscriber to which NAT could not be applied because of quota limitations. Quotas include absolute limits as well as limits on the rate of allocation." ::= { natSubscribersTableEntry 11 } natSubscriberCntMappings OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of currently active mappings created by or for this subscriber. Equal to natSubscriberCntMapRemovals - natSubscriberCntMapCreations." ::= { natSubscribersTableEntry 12 } natSubscriberCntMapCreations OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of mappings created by or for this subscriber." ::= { natSubscribersTableEntry 13 } natSubscriberCntMapRemovals OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION Perreault, et al. Expires December 01, 2013 [Page 74] Internet-Draft NEW NAT MIB May 2013 "Number of mappings removed by or for this subscriber." ::= { natSubscribersTableEntry 14 } natSubscriberLimitMappings OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Limit on the number of active mappings created by or for this subscriber. Zero means unlimited." ::= { natSubscribersTableEntry 15 } natSubscriberMapNotifyThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "See natNotifSubscriberMappings." ::= { natSubscribersTableEntry 16 } -- object groups natGroupBasicObjects OBJECT-GROUP OBJECTS { natCntTranslates, natCntOOP, natCntResource, natCntStateMismatch, natCntQuota, natCntMappings, natCntMapCreations, natCntMapRemovals, natCntProtocolTranslates, natCntProtocolOOP, natCntProtocolResource, natCntProtocolStateMismatch, natCntProtocolQuota, natCntProtocolMappings, natCntProtocolMapCreations, natCntProtocolMapRemovals, natLimitMappings, natMappingsNotifyThreshold, natPoolIndex, natPoolRealm, natPoolUsage, natPoolWatermarkLow, natPoolWatermarkHigh, natPoolPortMin, Perreault, et al. Expires December 01, 2013 [Page 75] Internet-Draft NEW NAT MIB May 2013 natPoolPortMax, natPoolRangePoolIndex, natPoolRangeEnd, natPoolRangeAllocatedPorts, natMappingIntRealm, natMappingIntAddressType, natMappingIntAddress, natMappingIntPort, natMappingPool, natMappingMapBehavior, natMappingFilterBehavior, natMappingAddressPooling } STATUS current DESCRIPTION "Basic counters, limits, and thresholds." ::= { natMIBGroups 7 } natGroupAddrMapObjects OBJECT-GROUP OBJECTS { natCntAddressMappings, natCntAddrMapCreations, natCntAddrMapRemovals, natLimitAddressMappings, natAddrMapNotifyThreshold, natMapIntAddrExtRealm, natMapIntAddrExt } STATUS current DESCRIPTION "Objects that require 'Paired IP address pooling' behavior [RFC4787]." ::= { natMIBGroups 8 } natGroupFragmentObjects OBJECT-GROUP OBJECTS { natLimitFragments } STATUS current DESCRIPTION "Objects that require 'Receive Fragments Out of Order' behavior [RFC4787]." ::= { natMIBGroups 9 } natGroupBasicNotifications NOTIFICATION-GROUP NOTIFICATIONS { natNotifPoolWatermarkLow, natNotifPoolWatermarkHigh, natNotifMappings } STATUS current DESCRIPTION "Basic notifications." ::= { natMIBGroups 11 } Perreault, et al. Expires December 01, 2013 [Page 76] Internet-Draft NEW NAT MIB May 2013 natGroupAddrMapNotifications NOTIFICATION-GROUP NOTIFICATIONS { natNotifAddrMappings } STATUS current DESCRIPTION "Notifications about address mappings." ::= { natMIBGroups 12 } natGroupSubscriberObjects OBJECT-GROUP OBJECTS { natSubscriberIntPrefixType, natSubscriberIntPrefix, natSubscriberIntPrefixLength, natSubscriberPool, natSubscriberCntTranslates, natSubscriberCntOOP, natSubscriberCntResource, natSubscriberCntStateMismatch, natSubscriberCntQuota, natSubscriberCntMappings, natSubscriberCntMapCreations, natSubscriberCntMapRemovals, natSubscriberLimitMappings, natLimitSubscribers, natSubscriberMapNotifyThresh } STATUS current DESCRIPTION "Per-subscriber counters, limits, and thresholds." ::= { natMIBGroups 13 } natGroupSubscriberNotifications NOTIFICATION-GROUP NOTIFICATIONS { natNotifSubscriberMappings } STATUS current DESCRIPTION "Subscriber notifications." ::= { natMIBGroups 14 } -- compliance statements natBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Basic compliance with this MIB is attained when the objects contained in the mandatory groups are implemented." MODULE -- this module MANDATORY-GROUPS { natGroupBasicObjects, natGroupBasicNotifications } ::= { natMIBCompliances 3 } Perreault, et al. Expires December 01, 2013 [Page 77] Internet-Draft NEW NAT MIB May 2013 natAddrMapCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "NATs that have 'Paired IP address pooling' behavior [RFC4787] and implement the objects in this group can claim this level of compliance." MODULE -- this module MANDATORY-GROUPS { natGroupBasicObjects, natGroupBasicNotifications, natGroupAddrMapObjects, natGroupAddrMapNotifications } ::= { natMIBCompliances 4 } natFragmentsCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "NATs that have 'Receive Fragments Out of Order' behavior [RFC4787] and implement the objects in this group can claim this level of compliance." MODULE -- this module MANDATORY-GROUPS { natGroupBasicObjects, natGroupBasicNotifications, natGroupFragmentObjects } ::= { natMIBCompliances 5 } natCGNCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "NATs that have 'Paired IP address pooling' and 'Receive Fragments Out of Order' behavior [RFC4787] and implement the objects in this group can claim this level of compliance. This level of compliance is to be expected of a CGN compliant with [I-D.ietf-behave-lsn-requiremnents]." MODULE -- this module MANDATORY-GROUPS { natGroupBasicObjects, natGroupBasicNotifications, natGroupAddrMapObjects, natGroupAddrMapNotifications, natGroupFragmentObjects, natGroupSubscriberObjects, natGroupSubscriberNotifications } ::= { natMIBCompliances 6 } END Perreault, et al. Expires December 01, 2013 [Page 78] Internet-Draft NEW NAT MIB May 2013 5. Security Considerations Note: This section only applies to objects with current status. For deprecated objects, please refer to the Security Considerations section from [RFC4008]. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Limits: An attacker setting a very low or very high limit can easily cause a denial-of-service situation. * natLimitMappings * natLimitAddressMappings * natLimitFragments * natLimitSubscribers * natSubscriberLimitMappings Notification thresholds: An attacker setting an arbitrarily low treshold can cause many useless notifications to be generated. Setting an arbitrarily high threshold can effectively disable notifications, which could be used to hide another attack. * natMappingsNotifyThreshold * natAddrMapNotifyThreshold * natSubscriberMapNotifyThresh Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Objects that reveal host identities: Various objects can reveal the identity of private hosts that are engaged in a session with Perreault, et al. Expires December 01, 2013 [Page 79] Internet-Draft NEW NAT MIB May 2013 external end nodes. A curious outsider could monitor these to assess the number of private hosts being supported by the NAT device. Further, a disgruntled former employee of an enterprise could use the information to break into specific private hosts by intercepting the existing sessions or originating new sessions into the host. * natMapIntAddrType * natMapIntAddrInt * natMapIntAddrExt * natMappingIntRealm * natMappingIntAddressType * natMappingIntAddress * natMappingIntPort * natMappingMapBehavior * natMappingFilterBehavior * natMappingAddressPooling * natSubscriberIntPrefixType * natSubscriberIntPrefix * natSubscriberIntPrefixLength Other objects that reveal NAT state: Other managed objects in this MIB may contain information that may be sensitive from a business perspective, in that they may represent NAT state information. * natCntAddressMappings * natCntProtocolMappings * natPoolUsage * natPoolRangeAllocatedPorts * natSubscriberCntMappings Perreault, et al. Expires December 01, 2013 [Page 80] Internet-Draft NEW NAT MIB May 2013 There are no objects that are sensitive in their own right, such as passwords or monetary amounts. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. IANA Considerations IANA has assigned object identifier 123 to the natMIB module, with prefix iso.org.dod.internet.mgmt.mib-2 in the Network Management Parameters registry [1]. No IANA actions are required by this document. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Perreault, et al. Expires December 01, 2013 [Page 81] Internet-Draft NEW NAT MIB May 2013 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009. [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011. 7.2. Informative References Perreault, et al. Expires December 01, 2013 [Page 82] Internet-Draft NEW NAT MIB May 2013 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005. Authors' Addresses Simon Perreault Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada Phone: +1 418 656 9254 Email: simon.perreault@viagenie.ca URI: http://viagenie.ca Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tina.tsou.zouting@huawei.com Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park, North Carolina 27709 USA Phone: +1 919 392 5158 Email: ssenthil@cisco.com Perreault, et al. Expires December 01, 2013 [Page 83] --------------020306010209090309010503-- From dthaler@microsoft.com Thu May 30 12:44:22 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C9921F907E for ; Thu, 30 May 2013 12:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.217 X-Spam-Level: X-Spam-Status: No, score=-98.217 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNo6tGtXa2YB for ; Thu, 30 May 2013 12:44:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id A964A21F8FA3 for ; Thu, 30 May 2013 12:44:16 -0700 (PDT) Received: from BY2FFO11FD017.protection.gbl (10.1.15.202) by BY2FFO11HUB007.protection.gbl (10.1.14.165) with Microsoft SMTP Server (TLS) id 15.0.707.0; Thu, 30 May 2013 19:40:57 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD017.mail.protection.outlook.com (10.1.14.105) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Thu, 30 May 2013 19:40:57 +0000 Received: from CO9EHSOBE025.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.3.136.1; Thu, 30 May 2013 19:40:48 +0000 Received: from mail186-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE025.bigfish.com (10.236.130.88) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 May 2013 19:39:02 +0000 Received: from mail186-co9 (localhost [127.0.0.1]) by mail186-co9-R.bigfish.com (Postfix) with ESMTP id 979A11000D7 for ; Thu, 30 May 2013 19:39:02 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -27 X-BigFish: PS-27(zz9371Ic89bh936eI119bId772h542I1432I179dNzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz31h2a8h668h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh17ej9a9j1155h) Received-SPF: softfail (mail186-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT004.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR03MB266; H:BN1PR03MB267.namprd03.prod.outlook.com; LANG:en; Received: from mail186-co9 (localhost.localdomain [127.0.0.1]) by mail186-co9 (MessageSwitch) id 1369942741527159_13650; Thu, 30 May 2013 19:39:01 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.239]) by mail186-co9.bigfish.com (Postfix) with ESMTP id 7E40384004D; Thu, 30 May 2013 19:39:01 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 May 2013 19:39:01 +0000 Received: from BN1PR03MB266.namprd03.prod.outlook.com (10.255.200.15) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 30 May 2013 19:38:58 +0000 Received: from BN1PR03MB267.namprd03.prod.outlook.com (10.255.200.17) by BN1PR03MB266.namprd03.prod.outlook.com (10.255.200.15) with Microsoft SMTP Server (TLS) id 15.0.698.13; Thu, 30 May 2013 19:38:58 +0000 Received: from BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.233]) by BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.233]) with mapi id 15.00.0698.010; Thu, 30 May 2013 19:38:57 +0000 From: Dave Thaler To: Simon Perreault Thread-Topic: WGLC on draft-ietf-behave-nat-mib Thread-Index: Ac5csUf0maP8QPpzSZGehDhIcO1HfwAAQW1QABobqYAAFHfJEA== Date: Thu, 30 May 2013 19:38:57 +0000 Message-ID: <2d6b12df967d4faf8fcfd6d6891b2ca2@BN1PR03MB267.namprd03.prod.outlook.com> References: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> <51A72041.6060208@viagenie.ca> In-Reply-To: <51A72041.6060208@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:1a:3:24d6:67ae:ed1b:a4be] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BN1PR03MB266.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VIAGENIE.CA$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(13464003)(377424003)(45074003)(199002)(377454002)(51704005)(60454003)(76576001)(44976003)(56776001)(33646001)(16676001)(20776003)(23756003)(63696002)(6806003)(4396001)(74366001)(47776003)(47976001)(74316001)(76482001)(81542001)(15202345002)(77982001)(54316002)(59766001)(49866001)(79102001)(47736001)(551544002)(81342001)(50986001)(56816002)(76796001)(50466002)(47446002)(74706001)(31966008)(74502001)(74662001)(46102001)(53806001)(69226001)(74876001)(80022001)(54356001)(65816001)(76786001)(51856001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB007; H:TK5EX14HUBC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 08626BE3A5 Cc: "behave@ietf.org" , "draft-ietf-behave-nat-mib@tools.ietf.org" Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:44:22 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Thursday, May 30, 2013 2:48 AM > To: Dave Thaler > Cc: draft-ietf-behave-nat-mib@tools.ietf.org; behave@ietf.org > Subject: Re: WGLC on draft-ietf-behave-nat-mib >=20 > Le 2013-05-29 23:42, Dave Thaler a =E9crit : > > Some initial items noticed by document shepherd (me): > > > > 1) Section 5 of the current draft has > > " Some of the readable objects in this MIB module (i.e., objects with a > > MAX-ACCESS other than not-accessible) may be considered sensitive o= r > > vulnerable in some network environments. It is thus important to > > control even GET and/or NOTIFY access to these objects and possibly > > to even encrypt the values of these objects when sending them over > > the network via SNMP." > > > > Per http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > > that's supposed to be followed with > > " These are the tables and objects and their > > sensitivity/vulnerability: > > > > " > > > > Also the document has 2 paragraphs of text "There are a number of > > managed objects in this MIB that may contain ... > > versions of SNMP provide features for such a secure environment." > > which do not appear in the current MIB boilerplate at the link above. > > Should those 2 paragraphs be removed? >=20 > How about this as a replacement? >=20 > Some of the readable objects in this MIB module (i.e., objects with a > MAX-ACCESS other than not-accessible) may be considered sensitive or > vulnerable in some network environments. It is thus important to > control even GET and/or NOTIFY access to these objects and possibly > to even encrypt the values of these objects when sending them over > the network via SNMP. These are the tables and objects and their > sensitivity/vulnerability: >=20 > Objects that reveal host identities: Various objects can reveal the > identity of private hosts that are engaged in a session with > external end nodes. A curious outsider could monitor these to > assess the number of private hosts being supported by the NAT > device. Further, a disgruntled former employee of an enterprise > could use the information to break into specific private hosts by > intercepting the existing sessions or originating new sessions > into the host. >=20 > * natMapIntAddrType >=20 > * natMapIntAddrInt >=20 > * natMapIntAddrExt >=20 > * natMappingIntRealm >=20 > * natMappingIntAddressType >=20 > * natMappingIntAddress >=20 > * natMappingIntPort >=20 > * natMappingMapBehavior >=20 > * natMappingFilterBehavior >=20 > * natMappingAddressPooling >=20 > * natSubscriberIntPrefixType >=20 > * natSubscriberIntPrefix >=20 > * natSubscriberIntPrefixLength >=20 > Other objects that reveal NAT state: Other managed objects in this > MIB may contain information that may be sensitive from a business > perspective, in that they may represent NAT state information. >=20 > * natCntAddressMappings >=20 > * natCntProtocolMappings >=20 > * natPoolUsage >=20 > * natPoolRangeAllocatedPorts >=20 > * natSubscriberCntMappings >=20 > There are no objects that are sensitive in their own right, such as > passwords or monetary amounts. Fine. > > 2) Section 5 contains MUST, SHOULD, etc. But the document is missing > > the boilerplate reference to RFC 2119. >=20 > *gasp* >=20 > Added. Ok. > > 3) Section 6 does not say whether any additional actions for IANA are > > needed. Suggest adding "No IANA actions are required by this document.= " >=20 > Added. Ok. > > 4) The MIB compiler I used complained about this: > >> natMappingPool OBJECT-TYPE > >> SYNTAX NatPoolId (0|1..4294967295) > > Because of > >> NatPoolId ::=3D TEXTUAL-CONVENTION > >> SYNTAX Unsigned32 (1..4294967295) > > > > That is, NatPoolId does not allow 0, and so natMappingPool cannot add > > it and still use the NatPoolId syntax. >=20 > Hmmmm... Would it be OK if I changed natMappingPool to an Unsigned32? >=20 > natMappingPool OBJECT-TYPE > SYNTAX Unsigned32 (0|1..4294967295) Yes, but you should remove the range restriction since that's the full rang= e. So just SYNTAX Unsigned32 =20 > Updated draft is attached. I see you added in the security considerations section: > Note: This section only applies to objects with current status. > For deprecated objects, please refer to the Security > Considerations section from [RFC4008]. However that doesn't make sense in my opinion unless we make RFC4008 a Normative (not informative) reference. But I would prefer keeping it as an informative reference so it can be obsoleted. So I disagree with the quoted limitation. -Dave=20 From simon.perreault@viagenie.ca Fri May 31 00:50:55 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5975C21F9371 for ; Fri, 31 May 2013 00:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jidh2ZTxBM52 for ; Fri, 31 May 2013 00:50:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CBB8F21F9302 for ; Fri, 31 May 2013 00:50:54 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:840c:a975:6de0:6912]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CB0F0414AC; Fri, 31 May 2013 03:50:53 -0400 (EDT) Message-ID: <51A8565B.5070700@viagenie.ca> Date: Fri, 31 May 2013 09:50:51 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dave Thaler References: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> <51A72041.6060208@viagenie.ca> <2d6b12df967d4faf8fcfd6d6891b2ca2@BN1PR03MB267.namprd03.prod.outlook.com> In-Reply-To: <2d6b12df967d4faf8fcfd6d6891b2ca2@BN1PR03MB267.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , "draft-ietf-behave-nat-mib@tools.ietf.org" Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 07:50:55 -0000 Le 2013-05-30 21:38, Dave Thaler a écrit : >>> 4) The MIB compiler I used complained about this: >>>> natMappingPool OBJECT-TYPE >>>> SYNTAX NatPoolId (0|1..4294967295) >>> Because of >>>> NatPoolId ::= TEXTUAL-CONVENTION >>>> SYNTAX Unsigned32 (1..4294967295) >>> >>> That is, NatPoolId does not allow 0, and so natMappingPool cannot add >>> it and still use the NatPoolId syntax. >> >> Hmmmm... Would it be OK if I changed natMappingPool to an Unsigned32? >> >> natMappingPool OBJECT-TYPE >> SYNTAX Unsigned32 (0|1..4294967295) > > Yes, but you should remove the range restriction since that's the full range. > So just > SYNTAX Unsigned32 Right. Removed. > I see you added in the security considerations section: >> Note: This section only applies to objects with current status. >> For deprecated objects, please refer to the Security >> Considerations section from [RFC4008]. > > However that doesn't make sense in my opinion unless we make RFC4008 a > Normative (not informative) reference. But I would prefer keeping it as > an informative reference so it can be obsoleted. So I disagree with the > quoted limitation. Hmmm... So what should we do instead? Keeping in mind that the security considerations in 4008 aren't up to today's standards. a) Copy the security section verbatim from 4008. Add a preamble saying something like "These considerations apply to the deprecated elements. Others may apply, use at your own risk." b) Create brand new security considerations for deprecated elements. c) ??? Simon From ietfdbh@comcast.net Fri May 31 06:48:05 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7814221F96E1 for ; Fri, 31 May 2013 06:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY1IYIvxx32q for ; Fri, 31 May 2013 06:47:59 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 64CB121F969C for ; Fri, 31 May 2013 06:47:59 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta02.westchester.pa.mail.comcast.net with comcast id iban1l0031wpRvQ51dnyw3; Fri, 31 May 2013 13:47:58 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta18.westchester.pa.mail.comcast.net with comcast id idnx1l00S2yZEBF3ednxej; Fri, 31 May 2013 13:47:58 +0000 From: "ietfdbh" To: "'Simon Perreault'" , "'Dave Thaler'" References: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> <51A72041.6060208@viagenie.ca> <2d6b12df967d4faf8fcfd6d6891b2ca2@BN1PR03MB267.namprd03.prod.outlook.com> <51A8565B.5070700@viagenie.ca> In-Reply-To: <51A8565B.5070700@viagenie.ca> Date: Fri, 31 May 2013 09:47:41 -0400 Message-ID: <004a01ce5e05$6bf10c90$43d325b0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJBxKJNP60xDQ0hdWTuJWe6MT5M0gKTgyxEAo3yDToCQZO96AGHXu79l/EandA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370008078; bh=B2IpskxIYdgMQEAMlybG8dAGz9zhGawck42yokzCoF0=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=bytcFEMmrxDYXTBVCvnyPszhCCq57UekmVJdzkM5vcSQy7aeTKlQUe2XEWJW3gqCZ j9WqUFoECYmTlbsETjpgKILfZ+Dy2mOPek1GTS7bK109C62Aa8owZzXxo0Pud2Rpp7 nPAkVyLN3j8w0+EgT/0gl7x1rtro3/COyb/NSF87nAzl8K5A3GTAP9y3rWZxEuGPWC Y4LuN72sM0xzebNQPTxPeAGhFwGfdVMtBL6L9D1Grc4tWeCUdJyr1TKacbPWjkAxTs sL1xi1he3UXXTyV77S/5WH6eVbjbDbHbUbVpup8JINqaRA1G7Vj+1Hr77gWsCepGek /hQVjlYxuQEkw== Cc: draft-ietf-behave-nat-mib@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 13:48:06 -0000 Hi, Three things. 1) A while back, I suggested that, if you are deprecating all of the = NAT-MIB in rfc4008, that it would be better to do this as a separate document = from the NEW-NAT-MIB (or whatever the new module gets called). Simon asked me = to get consensus from the MIB Doctors. I checked with the MIB Doctor list, and only got one reply - from = Juergen, who apparently recommended a single document. His response: " I have probably been pushing them into this because at the beginning = it was not really clear why the existing NAT-MIB is fatally flawed such = that it needs a complete replacement. If the behave WG has meanwhile reached consensus that indeed the existing NAT-MIB is fatally flawed and needs a complete replacement, then indeed what you suggest makes sense. I assume = the WG has checked with those who have implementations of the existing = NAT-MIB (if any) that they agree on a need for a complete new MIB." 2) Since deprecated objects are not obsoleted, I think new security considerations might be called for relating to the deprecated objects - especially if there are security implications of implementing BOTH the current and deprecated objects.=20 Some NMS applications will support only the old MIB module; others may support only the new MIB module. Some agents will want to implement = both, to make their devices manageable from either type of NMS application. Some = NMS applications will want to support both, to deal with both legacy and new agents.=20 MIB modules often make information available that could potentially be = used by attackers.=20 Are there particular risks involved in exposing the information of these = two NAT-MIBs in combination?=20 Are there potential risks associated with the potential confusion of = looking at a NAT from the different perspectives used by these two NAT MIB approaches? 3) I notice there is no "Operational Considerations" section. I wonder = if one is called for here, because operators may be faced with NMS = applications and/or agents that support both the deprecated and the new MIB module. = What should operators (and NMS applications) do with this potentially = conflicting information? What should they explicitly NOT do? E.g., What assumptions should they NOT make about the relationships between specific objects in = the old and new versions? My impression is that the old and the new MIB modules might be = appropriate depending on the environment in which they exist, and the old MIB is implemented (to whatever degree of compliance) in existing legacy = devices, so simply saying "never use the old MIB" is not going to be an = acceptable approach.=20 David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of Simon Perreault Sent: Friday, May 31, 2013 3:51 AM To: Dave Thaler Cc: behave@ietf.org; draft-ietf-behave-nat-mib@tools.ietf.org Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib Le 2013-05-30 21:38, Dave Thaler a =E9crit : >>> 4) The MIB compiler I used complained about this: >>>> natMappingPool OBJECT-TYPE >>>> SYNTAX NatPoolId (0|1..4294967295) >>> Because of >>>> NatPoolId ::=3D TEXTUAL-CONVENTION >>>> SYNTAX Unsigned32 (1..4294967295) >>> >>> That is, NatPoolId does not allow 0, and so natMappingPool cannot=20 >>> add it and still use the NatPoolId syntax. >> >> Hmmmm... Would it be OK if I changed natMappingPool to an Unsigned32? >> >> natMappingPool OBJECT-TYPE >> SYNTAX Unsigned32 (0|1..4294967295) > > Yes, but you should remove the range restriction since that's the full range. > So just > SYNTAX Unsigned32 Right. Removed. > I see you added in the security considerations section: >> Note: This section only applies to objects with current status. >> For deprecated objects, please refer to the Security >> Considerations section from [RFC4008]. > > However that doesn't make sense in my opinion unless we make RFC4008 a > Normative (not informative) reference. But I would prefer keeping it = as > an informative reference so it can be obsoleted. So I disagree with = the > quoted limitation. Hmmm... So what should we do instead? Keeping in mind that the security considerations in 4008 aren't up to today's standards. a) Copy the security section verbatim from 4008. Add a preamble saying something like "These considerations apply to the deprecated elements.=20 Others may apply, use at your own risk." b) Create brand new security considerations for deprecated elements. c) ??? Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From ietfdbh@comcast.net Fri May 31 10:04:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA321F938E for ; Fri, 31 May 2013 10:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.838 X-Spam-Level: X-Spam-Status: No, score=-97.838 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7JdneesmZEq for ; Fri, 31 May 2013 10:04:54 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4B821F8F83 for ; Fri, 31 May 2013 10:04:50 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id ih101l0091vXlb85Dh4omg; Fri, 31 May 2013 17:04:48 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta17.westchester.pa.mail.comcast.net with comcast id ih4o1l00B2yZEBF3dh4ot9; Fri, 31 May 2013 17:04:48 +0000 From: "ietfdbh" To: "'Simon Perreault'" , "'Dave Thaler'" Date: Fri, 31 May 2013 13:04:31 -0400 Message-ID: <005a01ce5e20$ebb93130$c32b9390$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5eIOsemTjvHZTxRPGVjUEgOOEGGQ== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370019888; bh=2q7OlRIbV8mMfSG08ekBy8aYo6rB4FBpf+y0wAKLF+Q=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=OxCS9qboCfvp1GimiDpgh0CuMXyBw2x9q9otNIHUsKE4+2ze4i3slB2Q3uH9YT+5j O36OiC3UFgLrBhex7/2Ldu3rGykTGWjmxuESf3TzhmqXIDSh9SeUbqVTQh4vt5nCx2 gw3fNfa/6iCwB09t+yXSO1vIZ9ETAxACp5EINMk7Ercie4StH4djdvrPwWHDVTP9Ri byqgssJd2USXMYNTmyTR85vlMcXJlugWqkFlUlKDCvFaNDHQpMgysbp3l1Yf1G/QuF Wmg0ENqt8RsppxepHqgBVf+YV5/ZUOls6OGMNY6ziurlIV84QOsppCnN972Sy8yYoU 6MrDMsTonreIA== Cc: behave@ietf.org, draft-ietf-behave-nat-mib@tools.ietf.org Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib - SMI violation? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 17:04:58 -0000 Hi, natAddrPortBindLocalAddr - the one being deprecated - is redefined in = the new document. The original had InetAddress syntax with no range; the new = doc adds a range (thereby redefining the range). I think this violates SMI rules (but it deserves checking to be sure). David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of ietfdbh Sent: Friday, May 31, 2013 9:48 AM To: 'Simon Perreault'; 'Dave Thaler' Cc: draft-ietf-behave-nat-mib@tools.ietf.org; behave@ietf.org Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib Hi, Three things. 1) A while back, I suggested that, if you are deprecating all of the = NAT-MIB in rfc4008, that it would be better to do this as a separate document = from the NEW-NAT-MIB (or whatever the new module gets called). Simon asked me = to get consensus from the MIB Doctors. I checked with the MIB Doctor list, and only got one reply - from = Juergen, who apparently recommended a single document. His response: " I have probably been pushing them into this because at the beginning = it was not really clear why the existing NAT-MIB is fatally flawed such = that it needs a complete replacement. If the behave WG has meanwhile reached consensus that indeed the existing NAT-MIB is fatally flawed and needs a complete replacement, then indeed what you suggest makes sense. I assume = the WG has checked with those who have implementations of the existing = NAT-MIB (if any) that they agree on a need for a complete new MIB." 2) Since deprecated objects are not obsoleted, I think new security considerations might be called for relating to the deprecated objects - especially if there are security implications of implementing BOTH the current and deprecated objects.=20 Some NMS applications will support only the old MIB module; others may support only the new MIB module. Some agents will want to implement = both, to make their devices manageable from either type of NMS application. Some = NMS applications will want to support both, to deal with both legacy and new agents.=20 MIB modules often make information available that could potentially be = used by attackers.=20 Are there particular risks involved in exposing the information of these = two NAT-MIBs in combination?=20 Are there potential risks associated with the potential confusion of = looking at a NAT from the different perspectives used by these two NAT MIB approaches? 3) I notice there is no "Operational Considerations" section. I wonder = if one is called for here, because operators may be faced with NMS = applications and/or agents that support both the deprecated and the new MIB module. = What should operators (and NMS applications) do with this potentially = conflicting information? What should they explicitly NOT do? E.g., What assumptions should they NOT make about the relationships between specific objects in = the old and new versions? My impression is that the old and the new MIB modules might be = appropriate depending on the environment in which they exist, and the old MIB is implemented (to whatever degree of compliance) in existing legacy = devices, so simply saying "never use the old MIB" is not going to be an = acceptable approach.=20 David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf = Of Simon Perreault Sent: Friday, May 31, 2013 3:51 AM To: Dave Thaler Cc: behave@ietf.org; draft-ietf-behave-nat-mib@tools.ietf.org Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib Le 2013-05-30 21:38, Dave Thaler a =E9crit : >>> 4) The MIB compiler I used complained about this: >>>> natMappingPool OBJECT-TYPE >>>> SYNTAX NatPoolId (0|1..4294967295) >>> Because of >>>> NatPoolId ::=3D TEXTUAL-CONVENTION >>>> SYNTAX Unsigned32 (1..4294967295) >>> >>> That is, NatPoolId does not allow 0, and so natMappingPool cannot=20 >>> add it and still use the NatPoolId syntax. >> >> Hmmmm... Would it be OK if I changed natMappingPool to an Unsigned32? >> >> natMappingPool OBJECT-TYPE >> SYNTAX Unsigned32 (0|1..4294967295) > > Yes, but you should remove the range restriction since that's the full range. > So just > SYNTAX Unsigned32 Right. Removed. > I see you added in the security considerations section: >> Note: This section only applies to objects with current status. >> For deprecated objects, please refer to the Security >> Considerations section from [RFC4008]. > > However that doesn't make sense in my opinion unless we make RFC4008 a > Normative (not informative) reference. But I would prefer keeping it = as > an informative reference so it can be obsoleted. So I disagree with = the > quoted limitation. Hmmm... So what should we do instead? Keeping in mind that the security considerations in 4008 aren't up to today's standards. a) Copy the security section verbatim from 4008. Add a preamble saying something like "These considerations apply to the deprecated elements.=20 Others may apply, use at your own risk." b) Create brand new security considerations for deprecated elements. c) ??? Simon _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave