From dwing@cisco.com Tue May 1 13:04:09 2012 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 755C421E8434 for ; Tue, 1 May 2012 13:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.074 X-Spam-Level: X-Spam-Status: No, score=-110.074 tagged_above=-999 required=5 tests=[AWL=0.525, 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 gKhfDOF683kv for ; Tue, 1 May 2012 13:04:08 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BAE2F21E842A for ; Tue, 1 May 2012 13:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4108; q=dns/txt; s=iport; t=1335902648; x=1337112248; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=W1EMVHwgnr0LrFrDOs952opUmzj2qQGMTD7hYIkLcnA=; b=IxOAjc97T6X8b2E41rhItZeWv8AZ0fjsGj07vZ/s/f5Sw8ezBDhmYSSZ DvZdKghSiKavpkIXXa6MrsOrQI9OcXK0lJUM+IBBQpdf/ZLoSiQvqkSDw rmz8Mt3vlUwbBP2Fog3DMJ7FUHyaZQ/jbJynLCc6RB0azbu6jjZaVDM2X o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkFAPtAoE+rRDoI/2dsb2JhbABEhWmcQI1PgwGBB4IJAQEBAwEBAQEFCgEQBz0HEAcBBRgCBAEBAwIJGgMCGwgGFQoHAgkBBBMJAgkHB4ddAwYEDJh1gSiNE4hLDYlTgS+IWH+Ea4EYBIhkhRaTQ4MagWmDCIE8 X-IronPort-AV: E=Sophos;i="4.75,512,1330905600"; d="scan'208";a="42923912" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 01 May 2012 20:04:08 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q41K48FO028810 for ; Tue, 1 May 2012 20:04:08 GMT From: "Dan Wing" To: Date: Tue, 1 May 2012 13:04:08 -0700 Message-ID: <08f801cd27d5$91424890$b3c6d9b0$@com> 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: Ac0nwms+mjZ+I4vlTGqyvAGhbNjmKAAEvoVg Content-Language: en-us Subject: [BEHAVE] Fwd: WG Action: sunset4 (sunset4) 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, 01 May 2012 20:04:09 -0000 The new SUNSET4 working group will probably be of interest to BEHAVE. = Subscription information is below. -d -----Original Message----- From: ietf-announce-bounces@ietf.org = [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, May 01, 2012 10:46 AM To: IETF Announcement List Cc: sunset4@ietf.org Subject: CORRECTED WG Action: sunset4 (sunset4) Minor update to the published charter: Marc and Wes are confirmed as WG = chairs (not "proposed"). Thanks to both Marc and Wes for taking on the = leadership of sunset4. - Ralph On May 1, 2012, at 12:33 PM 5/1/12, IESG Secretary wrote: > A new IETF working group has been formed in the Internet Area. For = additional information, please contact the Area Directors or the WG = Chairs. > > sunset4 (sunset4) > -------------------- > Current Status: Active > > Chairs: > Marc Blanchet > Wes George > > INT Area Director: > Ralph Droms > > Area Advisors: > OPS: Fred Baker > TSV: Martin Stiemerling > RTG: Stewart Bryant > > Mailing Lists: > Address: sunset4@ietf.org > List Subscription: https://www.ietf.org/mailman/listinfo/sunset4 > Email Archive: http://www.ietf.org/mail-archive/web/sunset4/ > > Description of Working Group: > > The IETF is committed to the deployment of IPv6 to ensure the > evolution of the Internet. However, the IPv4-only components of the > Internet must continue to operate as much as possible during the > transition from IPv4 to IPv6. > > The Working Group will standardize technologies that facilitate the > graceful sunsetting of the IPv4 Internet in the context of the > exhaustion of IPv4 address space while IPv6 is deployed. These > technologies will likely be less optimal than equivalent technologies > for IPv6-only and dual-stack networks. The Working Group works only > on IPv4 protocols to facilitate IPv4 sunsetting. > > The Working Group may work on fixing security bugs in existing > IPv4-specific protocols but is not chartered to add new security > functionality to those protocols. > > The working group will provide a single venue for the consideration of > IPv4 sunsetting, while ensuring that any such technologies do not > impede the deployment of IPv6 and do not duplicate functions and > capabilities already available in existing technologies. Therefore, > along the lines of draft-george-ipv6-support, before the working > group adopts any technology, it must: > > 1) describe the problem to be solved and show that there is widespread > demand for a solution > 2) demonstrate that the problem can not be solved with existing > technologies > 3) provide a description of the proposed solution along with the > impact on current IPv4-only use and its ability to promote the > deployment of IPv6 > > These steps will likely be described in the form of a use case and > requirements document. > > Only after the above mentioned steps have been completed and the > results accepted by the community will the IETF consider adding new > work items to the Working Group charter. This new work may include > protocol specifications. > > The work spans over multiple IETF areas including as Internet, > Operations, Transport and Routing. Therefore, cross-area coordination > and support is essential and required. Any work on IPv4 to IPv6 > transition methods is out of scope. > > The initial work items are: > > * Review current Carrier-Grade NAT (CGN) documents and related issues, > including requirements for standardization, and determine if CGN is > a suitable sunsetting technology to become a work item: > draft-ietf-behave-lsn-requirements > draft-ietf-behave-nat-mib > CGN port allocation methods > * Gap analysis of IPv4 features to facilitate IPv4 sunsetting > > Milestones > > 2012-09 Complete review of CGN and, if necessary, propose CGN work > items > 2013-06 Send gap analysis on IPv4 sunsetting to IESG From internet-drafts@ietf.org Thu May 3 07:46:45 2012 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 5CD1E21F85CF; Thu, 3 May 2012 07:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, 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 kt35h05LPIMY; Thu, 3 May 2012 07:46:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1F221F8495; Thu, 3 May 2012 07:46:44 -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.02 Message-ID: <20120503144644.25265.56412.idtracker@ietfa.amsl.com> Date: Thu, 03 May 2012 07:46:44 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-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: Thu, 03 May 2012 14:46:45 -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 Av= oidance Working Group of the IETF. Title : Common requirements for Carrier Grade NATs (CGNs) Author(s) : Simon Perreault Ikuhei Yamagata Shin Miyakawa Akira Nakagawa Hiroyuki Ashida Filename : draft-ietf-behave-lsn-requirements-06.txt Pages : 19 Date : 2012-05-03 This document defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-06.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/ From simon.perreault@viagenie.ca Thu May 3 07:51:01 2012 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 9320E21F846C for ; Thu, 3 May 2012 07:51:01 -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 s3dC8IvyeG5G for ; Thu, 3 May 2012 07:51:00 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D0A6B21F846B for ; Thu, 3 May 2012 07:51:00 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:fd74:94dc:fbc7:7264]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 48AB241364 for ; Thu, 3 May 2012 10:51:00 -0400 (EDT) Message-ID: <4FA29B53.4000909@viagenie.ca> Date: Thu, 03 May 2012 10:50:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <20120503144644.25265.56412.idtracker@ietfa.amsl.com> In-Reply-To: <20120503144644.25265.56412.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-lsn-requirements-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: Thu, 03 May 2012 14:51:01 -0000 On 2012-05-03 10:46, 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 : Common requirements for Carrier Grade NATs (CGNs) > Filename : draft-ietf-behave-lsn-requirements-06.txt This new revision addresses the AD review by David Harrington. Here's the change log: o Expanded some acronyms. o Added example IP addresses to ASCII art. o Reword transport protocol section. o Stronger words of caution about CGNs. o Refer to RFC for DCCP NAT behaviour. o Note in headers and abstract that this updates RFC 4787. o Remove sentence "This is not to be considered a solution to the shortage of IPv4 addresses." o Remove text having marketing scent. o Change some "MUST ... unless" requirements to "SHOULD ... unless". o Merge REQ-8 and REQ-9. o PCP is now a MUST. o NAT-MIB is now an example rather than specificially required. o When a quota is hit, send ICMP DU code 1 instead of code 3. o Remove mention of "lawful intercept". o Remove discussion on destination logging from section on bulk port allocation. o Remove discussion on address sharing ratio. 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 From simon.perreault@viagenie.ca Fri May 4 06:33:04 2012 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 79B2721F863F for ; Fri, 4 May 2012 06:33:04 -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 4goR36KbF0mN for ; Fri, 4 May 2012 06:33:03 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D64DC21F847D for ; Fri, 4 May 2012 06:33:03 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:fd74:94dc:fbc7:7264]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 651CC41590 for ; Fri, 4 May 2012 09:33:03 -0400 (EDT) Message-ID: <4FA3DA8E.5050107@viagenie.ca> Date: Fri, 04 May 2012 09:33:02 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] CGN default IP address pooling behaviour 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, 04 May 2012 13:33:04 -0000 Behaviers, In draft-ietf-behave-lsn-requirements-05, REQ-2 specifies the default CGN IP address pooling behaviour: "Paired", meaning that an internal address is always mapped to the same external address. Here's the full text: REQ-2: A CGN MUST have a default "IP address pooling" behavior of "Paired" (as defined in [RFC4787] section 4.1). A CGN MAY provide a mechanism for administrators to change this behavior on an application protocol basis. From -05 to -06, this requirement went from MUST to SHOULD. The cause was the following excerpt from the AD review by David Harrington: > 8) in REQ-2, you say the default must be xxx, but a CGN may do > something else. Typically, combining MUST with a MAY means you should > be using a SHOULD. MUST should be used used when a protocol will not > work if the specified behavior is not done. Private emails made me realize that this change may have been a mistake. The MUST would apply to the *default* behaviour. The MAY does not apply to the default behaviour. It applies to the existence of a mechanism for changing the behaviour (not the default, but the one being used) to something else. Unless the WG disagrees, it will be changed back to a MUST in the next revision. 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 From dthaler@microsoft.com Fri May 4 15:37:33 2012 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 5DB6C21F84F1 for ; Fri, 4 May 2012 15:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.869 X-Spam-Level: X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 iD2JeNf+NnP1 for ; Fri, 4 May 2012 15:37:32 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1D421F84F0 for ; Fri, 4 May 2012 15:37:32 -0700 (PDT) Received: from mail49-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 4 May 2012 22:37:16 +0000 Received: from mail49-am1 (localhost [127.0.0.1]) by mail49-am1-R.bigfish.com (Postfix) with ESMTP id 7AA412C05BD; Fri, 4 May 2012 22:37:16 +0000 (UTC) X-SpamScore: -23 X-BigFish: VS-23(zz9371I542M853kzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail49-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail49-am1 (localhost.localdomain [127.0.0.1]) by mail49-am1 (MessageSwitch) id 1336171034806364_30942; Fri, 4 May 2012 22:37:14 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.245]) by mail49-am1.bigfish.com (Postfix) with ESMTP id B550B240050; Fri, 4 May 2012 22:37:14 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 4 May 2012 22:37:14 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.298.5; Fri, 4 May 2012 22:37:22 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.298.5; Fri, 4 May 2012 15:37:22 -0700 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.160]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0298.005; Fri, 4 May 2012 15:37:22 -0700 From: Dave Thaler To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] CGN default IP address pooling behaviour Thread-Index: AQHNKfpzyVwZU/jGQ0SyFMR7WBYFA5a6OMvA Date: Fri, 4 May 2012 22:37:21 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B5B2C70@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> References: <4FA3DA8E.5050107@viagenie.ca> In-Reply-To: <4FA3DA8E.5050107@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [BEHAVE] CGN default IP address pooling behaviour 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, 04 May 2012 22:37:33 -0000 I agree with your interpretation Simon and the proposed action. -Dave -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Simon Perreault Sent: Friday, May 4, 2012 6:33 AM To: behave@ietf.org Subject: [BEHAVE] CGN default IP address pooling behaviour Behaviers, In draft-ietf-behave-lsn-requirements-05, REQ-2 specifies the default CGN I= P address pooling behaviour: "Paired", meaning that an internal address is = always mapped to the same external address. Here's the full text: REQ-2: A CGN MUST have a default "IP address pooling" behavior of "Paired" (as defined in [RFC4787] section 4.1). A CGN MAY provide a mechanism for administrators to change this behavior on an application protocol basis. From -05 to -06, this requirement went from MUST to SHOULD. The cause was = the following excerpt from the AD review by David Harrington: > 8) in REQ-2, you say the default must be xxx, but a CGN may do=20 > something else. Typically, combining MUST with a MAY means you should=20 > be using a SHOULD. MUST should be used used when a protocol will not=20 > work if the specified behavior is not done. Private emails made me realize that this change may have been a mistake.=20 The MUST would apply to the *default* behaviour. The MAY does not apply to = the default behaviour. It applies to the existence of a mechanism for chang= ing the behaviour (not the default, but the one being used) to something el= se. Unless the WG disagrees, it will be changed back to a MUST in the next revi= sion. 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 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From harald@alvestrand.no Mon May 7 14:58:51 2012 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 3150421F84A6 for ; Mon, 7 May 2012 14:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 wwQ5iqRnaUHK for ; Mon, 7 May 2012 14:58:50 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1F821F8498 for ; Mon, 7 May 2012 14:58:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D797639E1E2 for ; Mon, 7 May 2012 23:58:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl0eiPT0a3a9 for ; Mon, 7 May 2012 23:58:49 +0200 (CEST) Received: from [172.28.93.74] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2C87239E107 for ; Mon, 7 May 2012 23:58:49 +0200 (CEST) Message-ID: <4FA84596.6010903@alvestrand.no> Date: Mon, 07 May 2012 23:58:46 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: behave@ietf.org References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-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, 07 May 2012 21:58:51 -0000 Apologies for not catching this until it came up on RTCWEB recently.... I have two issues with draft-muthu-behave-consent-freshness: 1) I can't tell from the draft which direction an exchange verifies consent for 2) I don't think I am convinced by the arguments against including MESSAGE-INTEGRITY. My attack scenario: A -------------------------- >>>>>> ---- media --->>>>>>>>>>> B M - may listen to the media stream, can send packets to A Attack scenario 1: B wishes to stop receiving media from A. M wishes to keep media flowing in order to inconvenience B somehow. If A is supposed to send a Consent-Request, M has to capture the Consent-Request packet and reply with a Consent Success response, copying the transaction ID. Since B has presumably stopped listening, B won't bother generating a Consent Error. If B is supposed to send the Consent-Request, M can simply manufacture a Consent-Request every 30 seconds; it doesn't care what happens to the Consent Success response. Attack scenario 2: B wishes to receive media from A. M wishes to stop the media flow. If M listens to the media stream, M can fake a single Consent Error response to a Consent Request. My suggested modifications to the I-D: - Reinstate use of USERNAME and MESSAGE-INTEGRITY. This protects against all the attacks above. - Make it clear that A (media sender) is the one generating Consent Request. That makes attack 1 more difficult. - Remove Consent Error. It's useless, and can form an attack surface. Hope this feedback is useful. Harald From dwing@cisco.com Tue May 8 08:40:20 2012 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 309CE21F852A for ; Tue, 8 May 2012 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 jjCNgcPd4lTG for ; Tue, 8 May 2012 08:40:19 -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 1DC5221F8642 for ; Tue, 8 May 2012 08:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3770; q=dns/txt; s=iport; t=1336491619; x=1337701219; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=Oo+espLcRfNFXdX1j5OoCbOF4C06iY0RKJM8wVyQUL4=; b=fiDfGTbxwZphdQVWBx8hz2VsbiSVGvR9TaH7DRg373Wl03hZBtPZPm02 +vBK3dOgqn1U1BJ3wlhbNLrMUmMWtaaQkLI3S54c3DEAKm2SkcUJ1w++f 2Qndc6CDe0lhVrov4mLkCkD7jUK9qsoEOURqDYa8CJ1g1i4ADPAKeDULY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAEE9qU+rRDoI/2dsb2JhbABEomqQOoEHggwBAQEDAQEBAQUKARQDEDQQBwEDAgkPAgQBASgHGQ4VCggBCAEBBAESCxeHZwQMmxagNASLA4YJBIhkhRaWXYFpgwk X-IronPort-AV: E=Sophos;i="4.75,552,1330905600"; d="scan'208";a="43974694" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 08 May 2012 15:40:18 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q48FeHPG023312; Tue, 8 May 2012 15:40:17 GMT From: "Dan Wing" To: "'Harald Alvestrand'" , References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com> <4FA84596.6010903@alvestrand.no> In-Reply-To: <4FA84596.6010903@alvestrand.no> Date: Tue, 8 May 2012 08:40:17 -0700 Message-ID: <028401cd2d30$de36dcf0$9aa496d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0snJktlAetGdv+SWS+tstSJJuLGwAkVHrg Content-Language: en-us Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-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, 08 May 2012 15:40:20 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Monday, May 07, 2012 2:59 PM > To: behave@ietf.org > Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent- > freshness-00.txt > > Apologies for not catching this until it came up on RTCWEB recently.... > > I have two issues with draft-muthu-behave-consent-freshness: > > 1) I can't tell from the draft which direction an exchange verifies > consent for That will be improved in the next version. The sender of a stream has to obtain consent before sending that stream. > 2) I don't think I am convinced by the arguments against including > MESSAGE-INTEGRITY. > > My attack scenario: > > A -------------------------- >>>>>> ---- media --->>>>>>>>>>> B > M - may listen to the media > stream, can send packets to A So, "M" is on the media path. > Attack scenario 1: > B wishes to stop receiving media from A. M wishes to keep media flowing > in order to inconvenience B somehow. > > If A is supposed to send a Consent-Request, M has to capture the > Consent-Request packet and reply with a Consent Success response, > copying the transaction ID. Right, that is what "M" would do. But M, being on path, could send its own packets towards B. M could perhaps even spoof A's address when sending its own packets towards B. Similar attacks are possible if the connection between A and B is TCP, M is on-path, and M can spoof B's address. With TCP, M sees the TCP sequence number and responds with a spoofed ACK. To my knowledge, the only protections for such a TCP attack are TCP-MD5 and TCP-AO (both don't work across NATs, which are pervasive on home networks). Or of course tunneling TCP over an encryption tunnel (IPsec or DTLS). > Since B has presumably stopped listening, B > won't bother generating a Consent Error. > > If B is supposed to send the Consent-Request, M can simply manufacture > a > Consent-Request every 30 seconds; it doesn't care what happens to the > Consent Success response. > > Attack scenario 2: > B wishes to receive media from A. M wishes to stop the media flow. > > If M listens to the media stream, M can fake a single Consent Error > response to a Consent Request. Comparing this to TCP again, if the connection between A and B was TCP and M can spoof B's address, M could send a TCP RST. > My suggested modifications to the I-D: > > - Reinstate use of USERNAME and MESSAGE-INTEGRITY. This protects > against all the attacks above. I agree that MESSAGE-INTEGRITY does protect from an on-path attacker. But if the requirement is to protect ourselves from on-path attackers, it means we cannot bring up a TCP channel -- not between the peers and not to a TURN server (because we don't know where the attacker, M, is located). > - Make it clear that A (media sender) is the one generating Consent > Request. That makes attack 1 more difficult. > - Remove Consent Error. It's useless, and can form an attack surface. Consent Error allows a receiver to immediately quit receiving packets -- much like RTCP BYE (back in the day). But RTCP BYE had no authentication, so nobody uses it. The purpose of Consent Error is to more quickly stop an undesired flow. If RTCWEB is really going to use SRTP everywhere, we can rely on the ability to do an SRTCP BYE and eliminate Consent Error. -d > Hope this feedback is useful. > > Harald > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From harald@alvestrand.no Tue May 8 10:15:49 2012 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 53CAC21F85C0 for ; Tue, 8 May 2012 10:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.364 X-Spam-Level: X-Spam-Status: No, score=-110.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 ygXbRDcIF-Uv for ; Tue, 8 May 2012 10:15:48 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2254221F85AC for ; Tue, 8 May 2012 10:15:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9C9139E149; Tue, 8 May 2012 19:15:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIaAENWZTkiJ; Tue, 8 May 2012 19:15:45 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EBF3439E0F3; Tue, 8 May 2012 19:15:45 +0200 (CEST) Message-ID: <4FA954C1.5070600@alvestrand.no> Date: Tue, 08 May 2012 19:15:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Dan Wing References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com> <4FA84596.6010903@alvestrand.no> <028401cd2d30$de36dcf0$9aa496d0$@com> In-Reply-To: <028401cd2d30$de36dcf0$9aa496d0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-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, 08 May 2012 17:15:49 -0000 Higher-level response..... I'm not sure the comparision to TCP is entirely appropriate. The discussion of "voice hammer" seemed to indicate that media streams (which "just keep on coming" until the next consent check) are more "dangerous" than TCP streams (which require a continuous stream of ACKs). that said, the setup consent requirement does not protect against the combination of a malicious site (to steal the credentials) and an on-path attacker (to steal the transaction IDs). So perhaps it's OK to not protect against an on-path attacker; the only attack that can be mounted that way is an attack where a flow was once legitimate and is no longer desired, which doesn't seem a huge case. On 05/08/2012 05:40 PM, Dan Wing wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Harald Alvestrand >> Sent: Monday, May 07, 2012 2:59 PM >> To: behave@ietf.org >> Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent- >> freshness-00.txt >> >> Apologies for not catching this until it came up on RTCWEB recently.... >> >> I have two issues with draft-muthu-behave-consent-freshness: >> >> 1) I can't tell from the draft which direction an exchange verifies >> consent for > That will be improved in the next version. > > The sender of a stream has to obtain consent before sending that stream. And while sending that stream, I assume. >> 2) I don't think I am convinced by the arguments against including >> MESSAGE-INTEGRITY. >> >> My attack scenario: >> >> A -------------------------->>>>>> ---- media --->>>>>>>>>>> B >> M - may listen to the media >> stream, can send packets to A > So, "M" is on the media path. Not necessarily. To give a contrived example, consider a case where B has a wireless hop to it where it associates securely with the sender, but does not encrypt the packets, and has good spoofing filters, while A is generically Internet-connected and not spoofing-filtered; M can listen to packets, and send to A with B's source address, but cannot inject packets to B. Told you it was contrived :-) > >> Attack scenario 1: >> B wishes to stop receiving media from A. M wishes to keep media flowing >> in order to inconvenience B somehow. >> >> If A is supposed to send a Consent-Request, M has to capture the >> Consent-Request packet and reply with a Consent Success response, >> copying the transaction ID. > Right, that is what "M" would do. > > But M, being on path, could send its own packets towards B. M could > perhaps even spoof A's address when sending its own packets towards > B. > > > Similar attacks are possible if the connection between A and B > is TCP, M is on-path, and M can spoof B's address. With TCP, M sees > the TCP sequence number and responds with a spoofed ACK. To my > knowledge, the only protections for such a TCP attack are > TCP-MD5 and TCP-AO (both don't work across NATs, which are > pervasive on home networks). Or of course tunneling TCP over an > encryption tunnel (IPsec or DTLS). I'm not sure the attacks are the same; the TCP attack buys you one window of data, while the consent-freshness attack buys you 30 seconds of media. Is there a significant difference in bang-for-the-buck? >> Since B has presumably stopped listening, B >> won't bother generating a Consent Error. >> >> If B is supposed to send the Consent-Request, M can simply manufacture >> a >> Consent-Request every 30 seconds; it doesn't care what happens to the >> Consent Success response. >> >> Attack scenario 2: >> B wishes to receive media from A. M wishes to stop the media flow. >> >> If M listens to the media stream, M can fake a single Consent Error >> response to a Consent Request. > Comparing this to TCP again, if the connection between A and B was > TCP and M can spoof B's address, M could send a TCP RST. Yup, and this is a technique known to be used by the Great Firewall. When creating a new protocol, shouldn't we take the opportunity to not open ourselves to well known attacks? >> My suggested modifications to the I-D: >> >> - Reinstate use of USERNAME and MESSAGE-INTEGRITY. This protects >> against all the attacks above. > I agree that MESSAGE-INTEGRITY does protect from an on-path > attacker. > > But if the requirement is to protect ourselves from on-path > attackers, it means we cannot bring up a TCP channel -- not > between the peers and not to a TURN server (because we don't > know where the attacker, M, is located). The way draft-ietf-rtcweb-security-04 is formulated, the requirement is to protect against media flows (the term "voice hammer" is not used there). It does not protect against the combination of a malicuous site (required to steal the credentials) and an on-path attacker (required to steal the transaction IDs). But it will protect against one of the two. See comments above about whether media flows are more harmful than TCP flows, and about whether we should repeat existing vulnerabilities. >> - Make it clear that A (media sender) is the one generating Consent >> Request. That makes attack 1 more difficult. >> - Remove Consent Error. It's useless, and can form an attack surface. > Consent Error allows a receiver to immediately quit receiving packets -- > much like RTCP BYE (back in the day). But RTCP BYE had no authentication, > so nobody uses it. > > The purpose of Consent Error is to more quickly stop an undesired flow. Is the idea that one would send Consent Error without a Consent Request? Or is it OK to require that the recipient hang around for 30 seconds after closing in order to say "no" to a Consent Request? > If RTCWEB is really going to use SRTP everywhere, we can rely on > the ability to do an SRTCP BYE and eliminate Consent Error. Seems clearer to me. > From dwing@cisco.com Tue May 8 10:29:07 2012 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 46FB921F8546 for ; Tue, 8 May 2012 10:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.337 X-Spam-Level: X-Spam-Status: No, score=-110.337 tagged_above=-999 required=5 tests=[AWL=0.263, 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 LGMuOOy5vaAw for ; Tue, 8 May 2012 10:29:06 -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 5D41221F8535 for ; Tue, 8 May 2012 10:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=7816; q=dns/txt; s=iport; t=1336498146; x=1337707746; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=TnMaLhFfk49Pyv0H/n6hQzOioCqeXE6Ml4BcI7EYams=; b=fjg3FyHUllk21HvWFstmq9L9Xof46FrELoJEYi7o5hBiu7R1luOrqB+8 kTc/DOugmgC6VvLy/vo3HUB9Bwj+cp8je06Fe6rsEfKHPT/lY5MSgg6+j RAJHqNVsLsTpCfV+T3GywikXN6xUmdXizNcr7/TtvxjXczC2E+4FrkyRF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAP9WqU+rRDoJ/2dsb2JhbABEom2QQIEHggwBAQEDAQgKARQDED8MAQMCCQ8CBAEBAScHGSMKCAEIAQEEEwsXh2cEmzGgMIsDhhIEiGSFFpZdgWmDCYE2BQ X-IronPort-AV: E=Sophos;i="4.75,552,1330905600"; d="scan'208";a="40877903" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 08 May 2012 17:29:05 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q48HT5B3029152; Tue, 8 May 2012 17:29:05 GMT From: "Dan Wing" To: "'Harald Alvestrand'" References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com> <4FA84596.6010903@alvestrand.no> <028401cd2d30$de36dcf0$9aa496d0$@com> <4FA954C1.5070600@alvestrand.no> In-Reply-To: <4FA954C1.5070600@alvestrand.no> Date: Tue, 8 May 2012 10:29:05 -0700 Message-ID: <033c01cd2d40$11a909a0$34fb1ce0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0tPjjush600EYbRdynh6NlDNy7agAAJJdA Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-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, 08 May 2012 17:29:07 -0000 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Tuesday, May 08, 2012 10:16 AM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent- > freshness-00.txt > > Higher-level response..... > > I'm not sure the comparision to TCP is entirely appropriate. The > discussion of "voice hammer" seemed to indicate that media streams > (which "just keep on coming" until the next consent check) are more > "dangerous" than TCP streams (which require a continuous stream of > ACKs). > > that said, the setup consent requirement does not protect against the > combination of a malicious site (to steal the credentials) and an > on-path attacker (to steal the transaction IDs). So perhaps it's OK to > not protect against an on-path attacker; the only attack that can be > mounted that way is an attack where a flow was once legitimate and is > no longer desired, which doesn't seem a huge case. Voice Hammer is described in ICE (RFC5245) and prevented by the initial ICE connectivity checks -- which use MESSAGE-INTEGRITY. This protection is necessary for RTP flows and for SDESC-keyed SRTP. (However, if WEBRTC uses DTLS-SRTP handshakes, WEBRTC can use DTLS- SRTP to protect from the Voice Hammer attack, and could eliminate MESSAGE-INTEGRITY, which is helpful to reduce CPU load. I hope to have an I-D published soon to explain that.) After a media flow is authorized by the receiver, the Voice Hammer attack goes away, as you mention above, which leaves us with the continued consent problem - the receiver crashes, gets unplugged, or is still powered on and running properly but no longer wants to receive the media stream. It was for that case we had the Consent Error message. I suggest we can eliminate the Consent Error message if WEBRTC has SRTP, because we can use SRTCP BYE. But if WEBRTC allows RTP, it's useless to send an RTCP BYE, because it will be ignored (because it can be trivially spoofed by an off-path attacker). We could ignore that problem as one of the risks of running plain RTP, or keep Consent Error for that case. It comes down to if WEBRTC really chooses to use SRTP everywhere or if WEBRTC allows RTP to be used in some cases. -d > > > On 05/08/2012 05:40 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > >> Behalf Of Harald Alvestrand > >> Sent: Monday, May 07, 2012 2:59 PM > >> To: behave@ietf.org > >> Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent- > >> freshness-00.txt > >> > >> Apologies for not catching this until it came up on RTCWEB > recently.... > >> > >> I have two issues with draft-muthu-behave-consent-freshness: > >> > >> 1) I can't tell from the draft which direction an exchange verifies > >> consent for > > That will be improved in the next version. > > > > The sender of a stream has to obtain consent before sending that > stream. > And while sending that stream, I assume. > >> 2) I don't think I am convinced by the arguments against including > >> MESSAGE-INTEGRITY. > >> > >> My attack scenario: > >> > >> A -------------------------->>>>>> ---- media --->>>>>>>>>>> B > >> M - may listen to the > media > >> stream, can send packets to A > > So, "M" is on the media path. > Not necessarily. To give a contrived example, consider a case where B > has a wireless hop to it where it associates securely with the sender, > but does not encrypt the packets, and has good spoofing filters, while > A > is generically Internet-connected and not spoofing-filtered; M can > listen to packets, and send to A with B's source address, but cannot > inject packets to B. > > Told you it was contrived :-) > > > >> Attack scenario 1: > >> B wishes to stop receiving media from A. M wishes to keep media > flowing > >> in order to inconvenience B somehow. > >> > >> If A is supposed to send a Consent-Request, M has to capture the > >> Consent-Request packet and reply with a Consent Success response, > >> copying the transaction ID. > > Right, that is what "M" would do. > > > > But M, being on path, could send its own packets towards B. M could > > perhaps even spoof A's address when sending its own packets towards > > B. > > > > > > Similar attacks are possible if the connection between A and B > > is TCP, M is on-path, and M can spoof B's address. With TCP, M sees > > the TCP sequence number and responds with a spoofed ACK. To my > > knowledge, the only protections for such a TCP attack are > > TCP-MD5 and TCP-AO (both don't work across NATs, which are > > pervasive on home networks). Or of course tunneling TCP over an > > encryption tunnel (IPsec or DTLS). > > I'm not sure the attacks are the same; the TCP attack buys you one > window of data, while the consent-freshness attack buys you 30 seconds > of media. Is there a significant difference in bang-for-the-buck? > >> Since B has presumably stopped listening, B > >> won't bother generating a Consent Error. > >> > >> If B is supposed to send the Consent-Request, M can simply > manufacture > >> a > >> Consent-Request every 30 seconds; it doesn't care what happens to > the > >> Consent Success response. > >> > >> Attack scenario 2: > >> B wishes to receive media from A. M wishes to stop the media flow. > >> > >> If M listens to the media stream, M can fake a single Consent Error > >> response to a Consent Request. > > Comparing this to TCP again, if the connection between A and B was > > TCP and M can spoof B's address, M could send a TCP RST. > Yup, and this is a technique known to be used by the Great Firewall. > When creating a new protocol, shouldn't we take the opportunity to not > open ourselves to well known attacks? > >> My suggested modifications to the I-D: > >> > >> - Reinstate use of USERNAME and MESSAGE-INTEGRITY. This protects > >> against all the attacks above. > > I agree that MESSAGE-INTEGRITY does protect from an on-path > > attacker. > > > > But if the requirement is to protect ourselves from on-path > > attackers, it means we cannot bring up a TCP channel -- not > > between the peers and not to a TURN server (because we don't > > know where the attacker, M, is located). > The way draft-ietf-rtcweb-security-04 is formulated, the requirement is > to protect against media flows (the term "voice hammer" is not used > there). It does not protect against the combination of a malicuous site > (required to steal the credentials) and an on-path attacker (required > to > steal the transaction IDs). But it will protect against one of the two. > > See comments above about whether media flows are more harmful than TCP > flows, and about whether we should repeat existing vulnerabilities. > >> - Make it clear that A (media sender) is the one generating Consent > >> Request. That makes attack 1 more difficult. > >> - Remove Consent Error. It's useless, and can form an attack > surface. > > Consent Error allows a receiver to immediately quit receiving packets > -- > > much like RTCP BYE (back in the day). But RTCP BYE had no > authentication, > > so nobody uses it. > > > > The purpose of Consent Error is to more quickly stop an undesired > flow. > Is the idea that one would send Consent Error without a Consent > Request? > Or is it OK to require that the recipient hang around for 30 seconds > after closing in order to say "no" to a Consent Request? > > If RTCWEB is really going to use SRTP everywhere, we can rely on > > the ability to do an SRTCP BYE and eliminate Consent Error. > > Seems clearer to me. > > From mperumal@cisco.com Tue May 8 11:51:35 2012 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 B0FAD21F853B for ; Tue, 8 May 2012 11:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 lz7aOy8qFEWI for ; Tue, 8 May 2012 11:51:34 -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 6C4BF21F8534 for ; Tue, 8 May 2012 11:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=9289; q=dns/txt; s=iport; t=1336503093; x=1337712693; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MfqqU7O2K8oRSWiqMpblVdEL0piDZUduwxwxE4/8dgU=; b=bp9i11SqEXpVaWB5R0LOIzVrammSbPdn/k5KymTahvMoRPf5OGFQFUyv h8PPbLWzrAychzNZ0SaW7MVzTzVN0oKK7T9yihGHlx81p7IZ7+1buh/xG iMkFJYH5ytG/5EOWJ1lIoQ9EZQK0P6urO+yg3uSdJeKGLfmscK8gA5Aam E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EADlqqU9Io8UY/2dsb2JhbABEtDSCDAEBAQQBAQEPARQJCjQLDAQCAQgRBAEBCwYXAQYBJh8IAQgBAQQBCggIGodsC5seoCIEiwOFL2MEiGKbdYFpgnGBTgUC X-IronPort-AV: E=Sophos;i="4.75,552,1330905600"; d="scan'208";a="11722276" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 08 May 2012 18:51:31 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q48IpVCI025470; Tue, 8 May 2012 18:51:31 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 00:21:30 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 May 2012 00:21:29 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020865B624@XMB-BGL-414.cisco.com> In-Reply-To: <033c01cd2d40$11a909a0$34fb1ce0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent-freshness-00.txt Thread-Index: Ac0tPjjush600EYbRdynh6NlDNy7agAAJJdAAAJtEKA= References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com><4FA84596.6010903@alvestrand.no><028401cd2d30$de36dcf0$9aa496d0$@com><4FA954C1.5070600@alvestrand.no> <033c01cd2d40$11a909a0$34fb1ce0$@com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Dan Wing (dwing)" , "Harald Alvestrand" X-OriginalArrivalTime: 08 May 2012 18:51:30.0928 (UTC) FILETIME=[9500FF00:01CD2D4B] Cc: behave@ietf.org Subject: Re: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent-freshness-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, 08 May 2012 18:51:35 -0000 |I suggest we can eliminate the Consent Error message if=20 |WEBRTC has SRTP, because we can use SRTCP BYE. I see two issues relying on SRTCP BYE: 1. I think BYE isn't mandatory to send as per RFC3550. There are cases where a participant may leave a session without sending a BYE. Here is a snip from section 6.3.7 of RFC3550: A participant that does not want to wait for the above=20 mechanism to allow transmission of a BYE packet MAY leave the group without sending a BYE at all. That participant will eventually be timed out by the other group members. That doesn't prevent WebRTC mandating BYE, however. It would probably require some signaling (in the form an SDP attribute). 2. BYE isn't reliably sent. WebRTC could add reliability and mandate it, though. Consent Error would be much simpler, I think. Muthu |-----Original Message----- |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Dan Wing (dwing) |Sent: Tuesday, May 08, 2012 10:59 PM |To: 'Harald Alvestrand' |Cc: behave@ietf.org |Subject: Re: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent-freshness-00.txt | |> -----Original Message----- |> From: Harald Alvestrand [mailto:harald@alvestrand.no] |> Sent: Tuesday, May 08, 2012 10:16 AM |> To: Dan Wing |> Cc: behave@ietf.org |> Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent- |> freshness-00.txt |> |> Higher-level response..... |> |> I'm not sure the comparision to TCP is entirely appropriate. The |> discussion of "voice hammer" seemed to indicate that media streams |> (which "just keep on coming" until the next consent check) are more |> "dangerous" than TCP streams (which require a continuous stream of |> ACKs). |> |> that said, the setup consent requirement does not protect against the |> combination of a malicious site (to steal the credentials) and an |> on-path attacker (to steal the transaction IDs). So perhaps it's OK to |> not protect against an on-path attacker; the only attack that can be |> mounted that way is an attack where a flow was once legitimate and is |> no longer desired, which doesn't seem a huge case. | |Voice Hammer is described in ICE (RFC5245) and prevented by the |initial ICE connectivity checks -- which use MESSAGE-INTEGRITY. |This protection is necessary for RTP flows and for SDESC-keyed |SRTP. | |(However, if WEBRTC uses DTLS-SRTP handshakes, WEBRTC can use DTLS- |SRTP to protect from the Voice Hammer attack, and could eliminate |MESSAGE-INTEGRITY, which is helpful to reduce CPU load. I hope |to have an I-D published soon to explain that.) | |After a media flow is authorized by the receiver, the Voice Hammer |attack goes away, as you mention above, which leaves us with the |continued consent problem - the receiver crashes, gets unplugged, or |is still powered on and running properly but no longer wants to |receive the media stream. It was for that case we had the |Consent Error message. I suggest we can eliminate the Consent |Error message if WEBRTC has SRTP, because we can use SRTCP BYE. |But if WEBRTC allows RTP, it's useless to send an RTCP BYE, |because it will be ignored (because it can be trivially spoofed |by an off-path attacker). We could ignore that problem as |one of the risks of running plain RTP, or keep Consent Error |for that case. It comes down to if WEBRTC really chooses to |use SRTP everywhere or if WEBRTC allows RTP to be used in some |cases. | |-d | | |> |> |> On 05/08/2012 05:40 PM, Dan Wing wrote: |> >> -----Original Message----- |> >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On |> >> Behalf Of Harald Alvestrand |> >> Sent: Monday, May 07, 2012 2:59 PM |> >> To: behave@ietf.org |> >> Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent- |> >> freshness-00.txt |> >> |> >> Apologies for not catching this until it came up on RTCWEB |> recently.... |> >> |> >> I have two issues with draft-muthu-behave-consent-freshness: |> >> |> >> 1) I can't tell from the draft which direction an exchange verifies |> >> consent for |> > That will be improved in the next version. |> > |> > The sender of a stream has to obtain consent before sending that |> stream. |> And while sending that stream, I assume. |> >> 2) I don't think I am convinced by the arguments against including |> >> MESSAGE-INTEGRITY. |> >> |> >> My attack scenario: |> >> |> >> A -------------------------->>>>>> ---- media --->>>>>>>>>>> B |> >> M - may listen to the |> media |> >> stream, can send packets to A |> > So, "M" is on the media path. |> Not necessarily. To give a contrived example, consider a case where B |> has a wireless hop to it where it associates securely with the sender, |> but does not encrypt the packets, and has good spoofing filters, while |> A |> is generically Internet-connected and not spoofing-filtered; M can |> listen to packets, and send to A with B's source address, but cannot |> inject packets to B. |> |> Told you it was contrived :-) |> > |> >> Attack scenario 1: |> >> B wishes to stop receiving media from A. M wishes to keep media |> flowing |> >> in order to inconvenience B somehow. |> >> |> >> If A is supposed to send a Consent-Request, M has to capture the |> >> Consent-Request packet and reply with a Consent Success response, |> >> copying the transaction ID. |> > Right, that is what "M" would do. |> > |> > But M, being on path, could send its own packets towards B. M could |> > perhaps even spoof A's address when sending its own packets towards |> > B. |> > |> > |> > Similar attacks are possible if the connection between A and B |> > is TCP, M is on-path, and M can spoof B's address. With TCP, M sees |> > the TCP sequence number and responds with a spoofed ACK. To my |> > knowledge, the only protections for such a TCP attack are |> > TCP-MD5 and TCP-AO (both don't work across NATs, which are |> > pervasive on home networks). Or of course tunneling TCP over an |> > encryption tunnel (IPsec or DTLS). |> |> I'm not sure the attacks are the same; the TCP attack buys you one |> window of data, while the consent-freshness attack buys you 30 seconds |> of media. Is there a significant difference in bang-for-the-buck? |> >> Since B has presumably stopped listening, B |> >> won't bother generating a Consent Error. |> >> |> >> If B is supposed to send the Consent-Request, M can simply |> manufacture |> >> a |> >> Consent-Request every 30 seconds; it doesn't care what happens to |> the |> >> Consent Success response. |> >> |> >> Attack scenario 2: |> >> B wishes to receive media from A. M wishes to stop the media flow. |> >> |> >> If M listens to the media stream, M can fake a single Consent Error |> >> response to a Consent Request. |> > Comparing this to TCP again, if the connection between A and B was |> > TCP and M can spoof B's address, M could send a TCP RST. |> Yup, and this is a technique known to be used by the Great Firewall. |> When creating a new protocol, shouldn't we take the opportunity to not |> open ourselves to well known attacks? |> >> My suggested modifications to the I-D: |> >> |> >> - Reinstate use of USERNAME and MESSAGE-INTEGRITY. This protects |> >> against all the attacks above. |> > I agree that MESSAGE-INTEGRITY does protect from an on-path |> > attacker. |> > |> > But if the requirement is to protect ourselves from on-path |> > attackers, it means we cannot bring up a TCP channel -- not |> > between the peers and not to a TURN server (because we don't |> > know where the attacker, M, is located). |> The way draft-ietf-rtcweb-security-04 is formulated, the requirement is |> to protect against media flows (the term "voice hammer" is not used |> there). It does not protect against the combination of a malicuous site |> (required to steal the credentials) and an on-path attacker (required |> to |> steal the transaction IDs). But it will protect against one of the two. |> |> See comments above about whether media flows are more harmful than TCP |> flows, and about whether we should repeat existing vulnerabilities. |> >> - Make it clear that A (media sender) is the one generating Consent |> >> Request. That makes attack 1 more difficult. |> >> - Remove Consent Error. It's useless, and can form an attack |> surface. |> > Consent Error allows a receiver to immediately quit receiving packets |> -- |> > much like RTCP BYE (back in the day). But RTCP BYE had no |> authentication, |> > so nobody uses it. |> > |> > The purpose of Consent Error is to more quickly stop an undesired |> flow. |> Is the idea that one would send Consent Error without a Consent |> Request? |> Or is it OK to require that the recipient hang around for 30 seconds |> after closing in order to say "no" to a Consent Request? |> > If RTCWEB is really going to use SRTP everywhere, we can rely on |> > the ability to do an SRTCP BYE and eliminate Consent Error. |> |> Seems clearer to me. |> > | |_______________________________________________ |Behave mailing list |Behave@ietf.org |https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Tue May 8 12:55:32 2012 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 EE5B021F8455 for ; Tue, 8 May 2012 12:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.352 X-Spam-Level: X-Spam-Status: No, score=-110.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 dp1K6SR7I89r for ; Tue, 8 May 2012 12:55:32 -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 EDB7021F8453 for ; Tue, 8 May 2012 12:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=10482; q=dns/txt; s=iport; t=1336506932; x=1337716532; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=x2opjb5o70uNEsmmzDiYUKJjLuD3SltocCbnmfBId+w=; b=DVpy+bLMMsCrv2dbuG/pJ6yLc1vmzK6bxHlIrFjp17Ji1lHzNRro/VDu mXBtAPKgENxLrKu6Intq13vKhXjkNjgrOAEYFlzfQgA8fyLDjv2spYsgR Qon2Rvlbu4d2iRqCA3OijmQr3o1dyR9EjmtC6Crt1tclhjTgPvzw/NLMT 4=; X-IronPort-AV: E=Sophos;i="4.75,553,1330905600"; d="scan'208";a="44017405" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 08 May 2012 19:55:32 +0000 Received: from dwingWS ([10.154.162.77]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q48JtVrI020821; Tue, 8 May 2012 19:55:31 GMT From: "Dan Wing" To: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , "'Harald Alvestrand'" References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com><4FA84596.6010903@alvestrand.no><028401cd2d30$de36dcf0$9aa496d0$@com><4FA954C1.5070600@alvestrand.no> <033c01cd2d40$11a909a0$34fb1ce0$@com> <1D062974A4845E4D8A343C65380492020865B624@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020865B624@XMB-BGL-414.cisco.com> Date: Tue, 8 May 2012 12:55:31 -0700 Message-ID: <03c201cd2d54$8646c4a0$92d44de0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0tPjjush600EYbRdynh6NlDNy7agAAJJdAAAJtEKAAAt27MA== Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent-freshness-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, 08 May 2012 19:55:33 -0000 > -----Original Message----- > From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Tuesday, May 08, 2012 11:51 AM > To: Dan Wing (dwing); Harald Alvestrand > Cc: behave@ietf.org > Subject: RE: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent- > freshness-00.txt > > |I suggest we can eliminate the Consent Error message if > |WEBRTC has SRTP, because we can use SRTCP BYE. > > I see two issues relying on SRTCP BYE: > 1. I think BYE isn't mandatory to send as per RFC3550. There are cases > where a participant may leave a session without sending a BYE. Here is > a > snip from section 6.3.7 of RFC3550: > > A participant that does not want to wait for the above > mechanism to allow transmission of a BYE packet MAY leave > the group without sending a BYE at all. That participant > will eventually be timed out by the other group members. I believe that last sentence is a quiet assumption that the lack of RTCP receiver reports would cause a timeout, or that some higher-level function (the human) would terminate the call. > That doesn't prevent WebRTC mandating BYE, however. It would probably > require some signaling (in the form an SDP attribute). > > 2. BYE isn't reliably sent. WebRTC could add reliability and mandate > it, though. Consent Error would be much simpler, I think. And another point, in favor of your argument for keeping Consent Error: we cannot send SRTCP BYE on the data channel (SRTP channel), and need some way for that channel to be aborted faster than timing out. -d > Muthu > > |-----Original Message----- > |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dan Wing (dwing) > |Sent: Tuesday, May 08, 2012 10:59 PM > |To: 'Harald Alvestrand' > |Cc: behave@ietf.org > |Subject: Re: [BEHAVE] FW: I-DAction: > draft-muthu-behave-consent-freshness-00.txt > | > |> -----Original Message----- > |> From: Harald Alvestrand [mailto:harald@alvestrand.no] > |> Sent: Tuesday, May 08, 2012 10:16 AM > |> To: Dan Wing > |> Cc: behave@ietf.org > |> Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent- > |> freshness-00.txt > |> > |> Higher-level response..... > |> > |> I'm not sure the comparision to TCP is entirely appropriate. The > |> discussion of "voice hammer" seemed to indicate that media streams > |> (which "just keep on coming" until the next consent check) are more > |> "dangerous" than TCP streams (which require a continuous stream of > |> ACKs). > |> > |> that said, the setup consent requirement does not protect against > the > |> combination of a malicious site (to steal the credentials) and an > |> on-path attacker (to steal the transaction IDs). So perhaps it's OK > to > |> not protect against an on-path attacker; the only attack that can be > |> mounted that way is an attack where a flow was once legitimate and > is > |> no longer desired, which doesn't seem a huge case. > | > |Voice Hammer is described in ICE (RFC5245) and prevented by the > |initial ICE connectivity checks -- which use MESSAGE-INTEGRITY. > |This protection is necessary for RTP flows and for SDESC-keyed > |SRTP. > | > |(However, if WEBRTC uses DTLS-SRTP handshakes, WEBRTC can use DTLS- > |SRTP to protect from the Voice Hammer attack, and could eliminate > |MESSAGE-INTEGRITY, which is helpful to reduce CPU load. I hope > |to have an I-D published soon to explain that.) > | > |After a media flow is authorized by the receiver, the Voice Hammer > |attack goes away, as you mention above, which leaves us with the > |continued consent problem - the receiver crashes, gets unplugged, or > |is still powered on and running properly but no longer wants to > |receive the media stream. It was for that case we had the > |Consent Error message. I suggest we can eliminate the Consent > |Error message if WEBRTC has SRTP, because we can use SRTCP BYE. > |But if WEBRTC allows RTP, it's useless to send an RTCP BYE, > |because it will be ignored (because it can be trivially spoofed > |by an off-path attacker). We could ignore that problem as > |one of the risks of running plain RTP, or keep Consent Error > |for that case. It comes down to if WEBRTC really chooses to > |use SRTP everywhere or if WEBRTC allows RTP to be used in some > |cases. > | > |-d > | > | > |> > |> > |> On 05/08/2012 05:40 PM, Dan Wing wrote: > |> >> -----Original Message----- > |> >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > |> >> Behalf Of Harald Alvestrand > |> >> Sent: Monday, May 07, 2012 2:59 PM > |> >> To: behave@ietf.org > |> >> Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent- > |> >> freshness-00.txt > |> >> > |> >> Apologies for not catching this until it came up on RTCWEB > |> recently.... > |> >> > |> >> I have two issues with draft-muthu-behave-consent-freshness: > |> >> > |> >> 1) I can't tell from the draft which direction an exchange > verifies > |> >> consent for > |> > That will be improved in the next version. > |> > > |> > The sender of a stream has to obtain consent before sending that > |> stream. > |> And while sending that stream, I assume. > |> >> 2) I don't think I am convinced by the arguments against > including > |> >> MESSAGE-INTEGRITY. > |> >> > |> >> My attack scenario: > |> >> > |> >> A -------------------------->>>>>> ---- media --->>>>>>>>>>> B > |> >> M - may listen to > the > |> media > |> >> stream, can send packets to A > |> > So, "M" is on the media path. > |> Not necessarily. To give a contrived example, consider a case where > B > |> has a wireless hop to it where it associates securely with the > sender, > |> but does not encrypt the packets, and has good spoofing filters, > while > |> A > |> is generically Internet-connected and not spoofing-filtered; M can > |> listen to packets, and send to A with B's source address, but cannot > |> inject packets to B. > |> > |> Told you it was contrived :-) > |> > > |> >> Attack scenario 1: > |> >> B wishes to stop receiving media from A. M wishes to keep media > |> flowing > |> >> in order to inconvenience B somehow. > |> >> > |> >> If A is supposed to send a Consent-Request, M has to capture the > |> >> Consent-Request packet and reply with a Consent Success response, > |> >> copying the transaction ID. > |> > Right, that is what "M" would do. > |> > > |> > But M, being on path, could send its own packets towards B. M > could > |> > perhaps even spoof A's address when sending its own packets > towards > |> > B. > |> > > |> > > |> > Similar attacks are possible if the connection between A and B > |> > is TCP, M is on-path, and M can spoof B's address. With TCP, M > sees > |> > the TCP sequence number and responds with a spoofed ACK. To my > |> > knowledge, the only protections for such a TCP attack are > |> > TCP-MD5 and TCP-AO (both don't work across NATs, which are > |> > pervasive on home networks). Or of course tunneling TCP over an > |> > encryption tunnel (IPsec or DTLS). > |> > |> I'm not sure the attacks are the same; the TCP attack buys you one > |> window of data, while the consent-freshness attack buys you 30 > seconds > |> of media. Is there a significant difference in bang-for-the-buck? > |> >> Since B has presumably stopped listening, B > |> >> won't bother generating a Consent Error. > |> >> > |> >> If B is supposed to send the Consent-Request, M can simply > |> manufacture > |> >> a > |> >> Consent-Request every 30 seconds; it doesn't care what happens to > |> the > |> >> Consent Success response. > |> >> > |> >> Attack scenario 2: > |> >> B wishes to receive media from A. M wishes to stop the media > flow. > |> >> > |> >> If M listens to the media stream, M can fake a single Consent > Error > |> >> response to a Consent Request. > |> > Comparing this to TCP again, if the connection between A and B was > |> > TCP and M can spoof B's address, M could send a TCP RST. > |> Yup, and this is a technique known to be used by the Great Firewall. > |> When creating a new protocol, shouldn't we take the opportunity to > not > |> open ourselves to well known attacks? > |> >> My suggested modifications to the I-D: > |> >> > |> >> - Reinstate use of USERNAME and MESSAGE-INTEGRITY. This protects > |> >> against all the attacks above. > |> > I agree that MESSAGE-INTEGRITY does protect from an on-path > |> > attacker. > |> > > |> > But if the requirement is to protect ourselves from on-path > |> > attackers, it means we cannot bring up a TCP channel -- not > |> > between the peers and not to a TURN server (because we don't > |> > know where the attacker, M, is located). > |> The way draft-ietf-rtcweb-security-04 is formulated, the requirement > is > |> to protect against media flows (the term "voice hammer" is not used > |> there). It does not protect against the combination of a malicuous > site > |> (required to steal the credentials) and an on-path attacker > (required > |> to > |> steal the transaction IDs). But it will protect against one of the > two. > |> > |> See comments above about whether media flows are more harmful than > TCP > |> flows, and about whether we should repeat existing vulnerabilities. > |> >> - Make it clear that A (media sender) is the one generating > Consent > |> >> Request. That makes attack 1 more difficult. > |> >> - Remove Consent Error. It's useless, and can form an attack > |> surface. > |> > Consent Error allows a receiver to immediately quit receiving > packets > |> -- > |> > much like RTCP BYE (back in the day). But RTCP BYE had no > |> authentication, > |> > so nobody uses it. > |> > > |> > The purpose of Consent Error is to more quickly stop an undesired > |> flow. > |> Is the idea that one would send Consent Error without a Consent > |> Request? > |> Or is it OK to require that the recipient hang around for 30 seconds > |> after closing in order to say "no" to a Consent Request? > |> > If RTCWEB is really going to use SRTP everywhere, we can rely on > |> > the ability to do an SRTCP BYE and eliminate Consent Error. > |> > |> Seems clearer to me. > |> > > | > |_______________________________________________ > |Behave mailing list > |Behave@ietf.org > |https://www.ietf.org/mailman/listinfo/behave From harald@alvestrand.no Tue May 8 14:32:04 2012 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 C66A611E8080 for ; Tue, 8 May 2012 14:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.393 X-Spam-Level: X-Spam-Status: No, score=-110.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 yTNp1oTHfiAp for ; Tue, 8 May 2012 14:32:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E982211E8072 for ; Tue, 8 May 2012 14:32:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4349039E149; Tue, 8 May 2012 23:32:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSesNzp5q5IO; Tue, 8 May 2012 23:32:02 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 857CD39E0F3; Tue, 8 May 2012 23:32:02 +0200 (CEST) Message-ID: <4FA990D1.401@alvestrand.no> Date: Tue, 08 May 2012 23:32:01 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Dan Wing References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com><4FA84596.6010903@alvestrand.no><028401cd2d30$de36dcf0$9aa496d0$@com><4FA954C1.5070600@alvestrand.no> <033c01cd2d40$11a909a0$34fb1ce0$@com> <1D062974A4845E4D8A343C65380492020865B624@XMB-BGL-414.cisco.com> <03c201cd2d54$8646c4a0$92d44de0$@com> In-Reply-To: <03c201cd2d54$8646c4a0$92d44de0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , behave@ietf.org Subject: Re: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent-freshness-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, 08 May 2012 21:32:04 -0000 On 05/08/2012 09:55 PM, Dan Wing wrote: >> -----Original Message----- >> From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >> Sent: Tuesday, May 08, 2012 11:51 AM >> To: Dan Wing (dwing); Harald Alvestrand >> Cc: behave@ietf.org >> Subject: RE: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent- >> freshness-00.txt >> >> |I suggest we can eliminate the Consent Error message if >> |WEBRTC has SRTP, because we can use SRTCP BYE. >> >> I see two issues relying on SRTCP BYE: >> 1. I think BYE isn't mandatory to send as per RFC3550. There are cases >> where a participant may leave a session without sending a BYE. Here is >> a >> snip from section 6.3.7 of RFC3550: >> >> A participant that does not want to wait for the above >> mechanism to allow transmission of a BYE packet MAY leave >> the group without sending a BYE at all. That participant >> will eventually be timed out by the other group members. > I believe that last sentence is a quiet assumption that the lack > of RTCP receiver reports would cause a timeout, or that some > higher-level function (the human) would terminate the call. The RTP procedures in RFC 3550 specify when a recipient that doesn't send RR RTCP packets is deemed to have left an RTP session. It's not a quiet assumption; it's part of the RTP protocol. But I still don't understand Consent Error. I asked this before: Is the intent of Consent Error that the recipient of the stream has to hang around for at least 30 seconds in order to reply to the next Consent Request, in order to make the streams stop? >> That doesn't prevent WebRTC mandating BYE, however. It would probably >> require some signaling (in the form an SDP attribute). >> >> 2. BYE isn't reliably sent. WebRTC could add reliability and mandate >> it, though. Consent Error would be much simpler, I think. > And another point, in favor of your argument for keeping Consent > Error: we cannot send SRTCP BYE on the data channel (SRTP channel), > and need some way for that channel to be aborted faster than > timing out. SRTP data channel? Do you mean SCTP? SCTP associations are closed using the SHUTDOWN message (RFC 4960 section 3.3.8), or ABORT (section 3.3.7) if you're in a hurry. Since it's carried on top of the DTLS layer, it can't be spoofed. From dwing@cisco.com Tue May 8 16:05:48 2012 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 48D2F9E800B for ; Tue, 8 May 2012 16:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.366 X-Spam-Level: X-Spam-Status: No, score=-110.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 SRPHcKSnSCDI for ; Tue, 8 May 2012 16:05:47 -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 5E7439E8001 for ; Tue, 8 May 2012 16:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3248; q=dns/txt; s=iport; t=1336518347; x=1337727947; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=9CXBaPYd99bdIB0eObEaEPbtelW+I0qTja0QLk1sNX8=; b=EPBAei8hi7HVH03y4cpDHgq2LkFZdgMbs3VqBeYnDbrqaNgtbARsmHwM uLLBip/CkWVhfdstok1QWuhTvhivH8QtRGpKFlAUM2BZqdWoHxqqYO6qM UffnK0OTYb0xBIMIK4l2vqfhL6yCKL+JQKSi74VogWbFM8hXGWq+kijw5 s=; X-IronPort-AV: E=Sophos;i="4.75,553,1330905600"; d="scan'208";a="40926171" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 08 May 2012 23:05:47 +0000 Received: from dwingWS ([10.154.162.77]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q48N5l21032723; Tue, 8 May 2012 23:05:47 GMT From: "Dan Wing" To: "'Harald Alvestrand'" References: <1D062974A4845E4D8A343C653804920207BF0445@XMB-BGL-414.cisco.com><4FA84596.6010903@alvestrand.no><028401cd2d30$de36dcf0$9aa496d0$@com><4FA954C1.5070600@alvestrand.no> <033c01cd2d40$11a909a0$34fb1ce0$@com> <1D062974A4845E4D8A343C65380492020865B624@XMB-BGL-414.cisco.com> <03c201cd2d54$8646c4a0$92d44de0$@com> <4FA990D1.401@alvestrand.no> In-Reply-To: <4FA990D1.401@alvestrand.no> Date: Tue, 8 May 2012 16:05:47 -0700 Message-ID: <047601cd2d6f$1a6b93d0$4f42bb70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0tYguzsqDV8MMfSpC/I6Gf2mJAtwADINew Content-Language: en-us Cc: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , behave@ietf.org Subject: Re: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent-freshness-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, 08 May 2012 23:05:48 -0000 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Tuesday, May 08, 2012 2:32 PM > To: Dan Wing > Cc: 'Muthu Arul Mozhi Perumal (mperumal)'; behave@ietf.org > Subject: Re: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent- > freshness-00.txt > > On 05/08/2012 09:55 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Muthu Arul Mozhi Perumal (mperumal) > [mailto:mperumal@cisco.com] > >> Sent: Tuesday, May 08, 2012 11:51 AM > >> To: Dan Wing (dwing); Harald Alvestrand > >> Cc: behave@ietf.org > >> Subject: RE: [BEHAVE] FW: I-DAction: draft-muthu-behave-consent- > >> freshness-00.txt > >> > >> |I suggest we can eliminate the Consent Error message if > >> |WEBRTC has SRTP, because we can use SRTCP BYE. > >> > >> I see two issues relying on SRTCP BYE: > >> 1. I think BYE isn't mandatory to send as per RFC3550. There are > cases > >> where a participant may leave a session without sending a BYE. Here > is > >> a > >> snip from section 6.3.7 of RFC3550: > >> > >> A participant that does not want to wait for the above > >> mechanism to allow transmission of a BYE packet MAY leave > >> the group without sending a BYE at all. That participant > >> will eventually be timed out by the other group members. > > I believe that last sentence is a quiet assumption that the lack > > of RTCP receiver reports would cause a timeout, or that some > > higher-level function (the human) would terminate the call. > The RTP procedures in RFC 3550 specify when a recipient that doesn't > send RR RTCP packets is deemed to have left an RTP session. It's not a > quiet assumption; it's part of the RTP protocol. > > But I still don't understand Consent Error. > > I asked this before: > Is the intent of Consent Error that the recipient of the stream has to > hang around for at least 30 seconds in order to reply to the next > Consent Request, in order to make the streams stop? It's to allow informing the sender that consent (to continue to send media) has been revoked. Without it, the sender will send 2 or 3 consent checks, and not receive responses, before the sender believes consent has been revoked. Consider 'Consent Error' sortof like sending an ICMP. Everything works without ICMP, but errors are recovered faster with ICMP. Same with Consent Error -- errors are recovered faster. > >> That doesn't prevent WebRTC mandating BYE, however. It would > probably > >> require some signaling (in the form an SDP attribute). > >> > >> 2. BYE isn't reliably sent. WebRTC could add reliability and mandate > >> it, though. Consent Error would be much simpler, I think. > > And another point, in favor of your argument for keeping Consent > > Error: we cannot send SRTCP BYE on the data channel (SRTP channel), > > and need some way for that channel to be aborted faster than > > timing out. > SRTP data channel? Do you mean SCTP? Sorry, yes -- I meant to type "SCTP". > SCTP associations are closed using the SHUTDOWN message (RFC 4960 > section 3.3.8), or ABORT (section 3.3.7) if you're in a hurry. > > Since it's carried on top of the DTLS layer, it can't be spoofed. Great. -d From wwwrun@rfc-editor.org Thu May 10 00:28:35 2012 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 E570D21F8577 for ; Thu, 10 May 2012 00:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, 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 EvqtIi5C2htR for ; Thu, 10 May 2012 00:28:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8039C21F8576 for ; Thu, 10 May 2012 00:28:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C0A0C62180; Thu, 10 May 2012 00:26:12 -0700 (PDT) To: bill.huang@chinamobile.com, denghui@chinamobile.com, teemu.savolainen@nokia.com, wes@mti-systems.com, martin.stiemerling@neclab.eu, dwing@cisco.com, dthaler@microsoft.com From: RFC Errata System Message-Id: <20120510072612.C0A0C62180@rfc-editor.org> Date: Thu, 10 May 2012 00:26:12 -0700 (PDT) Cc: etienne.duble@imag.fr, behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Editorial Errata Reported] RFC6535 (3221) 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, 10 May 2012 07:28:36 -0000 The following errata report has been submitted for RFC6535, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6535&eid=3221 -------------------------------------- Type: Editorial Reported by: Etienne Dublé Section: 7 Original Text ------------- This document recommends the socket API-layer implementation option over network layer translation, i.e., it recommends the approach introduced in RFC 2767 over the approach of RFC 3338. Corrected Text -------------- This document recommends the socket API-layer implementation option over network layer translation, i.e., it recommends the approach introduced in RFC 3338 over the approach of RFC 2767. Notes ----- RFC numbers are swapped in this sentence. RFC 3338 describes the socket-API layer implementation, RFC 2767 describes the alternative (network-based) implementation. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6535 (draft-ietf-behave-v4v6-bih-09) -------------------------------------- Title : Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) Publication Date : February 2012 Author(s) : B. Huang, H. Deng, T. Savolainen Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From denghui@chinamobile.com Thu May 10 01:49:32 2012 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 75F6C21F8603 for ; Thu, 10 May 2012 01:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] 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 joLh5LPQTGB4 for ; Thu, 10 May 2012 01:49:32 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 97DC521F8606 for ; Thu, 10 May 2012 01:49:31 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 45564E426; Thu, 10 May 2012 16:49:30 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 395B8E5E1; Thu, 10 May 2012 16:49:30 +0800 (CST) Received: from Hui ([10.2.54.218]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051016492834-46858 ; Thu, 10 May 2012 16:49:28 +0800 From: "Hui Deng" To: "'RFC Errata System'" , , , , , , References: <20120510072612.C0A0C62180@rfc-editor.org> In-Reply-To: <20120510072612.C0A0C62180@rfc-editor.org> Date: Thu, 10 May 2012 16:49:34 +0800 Message-ID: <007f01cd2e89$d2cc6420$78652c60$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0ufoXZmkUcjEClRhi5eou0A8H5+wACy4Kg X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-10 16:49:28, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-10 16:49:29, Serialize complete at 2012-05-10 16:49:29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18896.005 X-TM-AS-Result: No--28.344-7.0-31-10 X-imss-scan-details: No--28.344-7.0-31-10;No--28.344-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: etienne.duble@imag.fr, behave@ietf.org Subject: Re: [BEHAVE] [Editorial Errata Reported] RFC6535 (3221) 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, 10 May 2012 08:49:32 -0000 Hello all It should be verified, it has been swapped between two documents Thanks a lot -Hui > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Thursday, May 10, 2012 3:26 PM > To: bill.huang@chinamobile.com; denghui@chinamobile.com; > teemu.savolainen@nokia.com; wes@mti-systems.com; > martin.stiemerling@neclab.eu; dwing@cisco.com; dthaler@microsoft.com > Cc: etienne.duble@imag.fr; behave@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC6535 (3221) > > > The following errata report has been submitted for RFC6535, "Dual-Stack Hosts > Using "Bump-in-the-Host" (BIH)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6535&eid=3221 > > -------------------------------------- > Type: Editorial > Reported by: Etienne Dubl? > > Section: 7 > > Original Text > ------------- > This document recommends the socket API-layer implementation option over > network layer translation, i.e., it recommends the approach introduced in RFC > 2767 over the approach of RFC 3338. > > > Corrected Text > -------------- > This document recommends the socket API-layer implementation option over > network layer translation, i.e., it recommends the approach introduced in RFC > 3338 over the approach of RFC 2767. > > Notes > ----- > RFC numbers are swapped in this sentence. RFC 3338 describes the socket-API > layer implementation, RFC 2767 describes the alternative (network-based) > implementation. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please use "Reply > All" to discuss whether it should be verified or rejected. When a decision is > reached, the verifying party (IESG) can log in to change the status and edit the > report, if necessary. > > -------------------------------------- > RFC6535 (draft-ietf-behave-v4v6-bih-09) > -------------------------------------- > Title : Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) > Publication Date : February 2012 > Author(s) : B. Huang, H. Deng, T. Savolainen > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG From internet-drafts@ietf.org Mon May 14 01:52:41 2012 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 8850F21F8478; Mon, 14 May 2012 01:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, 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 l3y2UAxBniYg; Mon, 14 May 2012 01:52:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1630321F8469; Mon, 14 May 2012 01:52:41 -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.02 Message-ID: <20120514085241.27184.98775.idtracker@ietfa.amsl.com> Date: Mon, 14 May 2012 01:52:41 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-08.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, 14 May 2012 08:52:41 -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 Av= oidance Working Group of the IETF. Title : Discovery of IPv6 Prefix Used for IPv6 Address Synthesis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-08.txt Pages : 14 Date : 2012-05-14 This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network. The method depends on 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 traversal through NAT64 on dual-stack accesses and multi-interface deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri= stic-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris= tic-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristi= c/ From teemu.savolainen@nokia.com Mon May 14 01:58:56 2012 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 4F71E21F85A8 for ; Mon, 14 May 2012 01:58:56 -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 Ayg7j6hLGQjH for ; Mon, 14 May 2012 01:58:55 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2F41F21F8475 for ; Mon, 14 May 2012 01:58:54 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4E8wRjB030083 for ; Mon, 14 May 2012 11:58:53 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 May 2012 11:58:26 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.148]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Mon, 14 May 2012 10:58:26 +0200 From: To: Thread-Topic: [BEHAVE] Two changes proposed for draft-ietf-behave-nat64-discovery-heuristic (to be done before interim) Thread-Index: Ac0jfQ6tEdy+1zC8SECLXrPNI+EhDwOMestw Date: Mon, 14 May 2012 08:58:25 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620437B18E@008-AM1MPN1-052.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE4430969620434C8AE@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620434C8AE@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7ImOqelkNNXZi1By/EBXMMlwjTSBHQ0rA7E1VadZcknvd+SbBfUS8SvhmshSce1Z6oFW1gtgC7X/8SjtLHiLgplwPTwU9M2EjAAYQK1OZlwkAFgdhOhCJpa5fEmhvCEsShLD6xdeMk6lRE9wK1XvZJaC7sVbBRY7Sq6vLqcBKQq83rLVwFXaUf7uCKK5KUoyBUHEHdKwjyY/GngUUrUUi5K1Dis/i2jamu0q7SRLNbRnnuPfGXz+zkDkgVH/JQknnrSLqMF/44gib9MHz38euXlLNovHtkeX27zKS6S8TZQgcDFtrKDom/HVKq+zYD2ZP8Q== x-originating-ip: [10.163.21.0] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 May 2012 08:58:26.0600 (UTC) FILETIME=[B991F280:01CD31AF] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Two changes proposed for draft-ietf-behave-nat64-discovery-heuristic (to be done before interim) 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, 14 May 2012 08:58:56 -0000 Hi, I just uploaded a new rev with clarification that two IPv4 addresses are ne= eded and with removal of infrastructure considerations text. http://www.ietf.org/id/draft-ietf-behave-nat64-discovery-heuristic-08.txt Related to this, FYI, the draft-ietf-behave-nat64-learn-analysis-03.txt is = now in RFC Editor's queue and is waiting for this heuristic draft to procee= d (due normative reference). Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Savolainen Teemu (Nokia-NRC/Tampere) > Sent: 26. huhtikuuta 2012 10:43 > To: behave@ietf.org > Subject: [BEHAVE] Two changes proposed for draft-ietf-behave-nat64- > discovery-heuristic (to be done before interim) >=20 > Hi, >=20 > There are two issues we'd like to update for the draft-ietf-behave-nat64- > discovery-heuristic before interim. Please comment. >=20 > 1. Clarify that IANA needs to assign two IPv4 addresses for the well-know= n > name. I.e. update IANA section to say something like: > -- > This document requests IANA to assign at least one, but preferably two, p= ublic > IPv4 addresses for the well-known name. The addresses must be reserved > from public IPv4 address space that is not allocated for any special use = as per > RFC5735 section 3. This is because RFC6052 section 3.1 forbids IPv6 addre= ss > synthesis using well-known prefix if IPv4 address is from any address spa= ce > described in the RFC5735 section 3. > -- > The RFC6052 section 3.1. limitation is quite hard, as it seems to rule ou= t use > of 192.0.0.0/24 (and 240.0.0.0/4) address spaces even if I'm not sure tho= se > are "non-global"? >=20 >=20 >=20 > 2. Remove the infrastructure & volume comment from section 4: > -- > It is expected that volumes for well-known name related queries are > roughly SOMETHING, TBD. The infrastructure required to serve well- > known name is SOMETHING, TBD. > -- >=20 > At least I don't know what else to do, as we have not received any figure= s for > what kind of volumes there could be and what kind of infrastructure is > required... and if that information is really needed for protocol specifi= cation at > first place. >=20 > Best regards, >=20 > Teemu > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iesg-secretary@ietf.org Tue May 15 10:53:25 2012 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 F126421F876C; Tue, 15 May 2012 10:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 xq-S8oeAtCvw; Tue, 15 May 2012 10:53:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47F121F8778; Tue, 15 May 2012 10:53:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515175324.14098.64192.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 10:53:24 -0700 Cc: behave@ietf.org, dthaler@microsoft.com, dwing@cisco.com Subject: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 15 May 2012 17:53:25 -0000 A modified charter has been submitted for the Behavior Engineering for Hind= rance Avoidance (behave) working group in the Transport Area of the IETF. = The IESG has not made any determination as yet. The modified charter is pr= ovided below for informational purposes only. Please send your comments to= the IESG mailing list (iesg@ietf.org) by Tuesday, May 22, 2012. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Current Status: Active Last updated: 2012-05-10 Chairs: Dan Wing Dave Thaler Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: behave@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network to an IPv4 network, and (4) an IPv4 network to an IPv6 network. Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible. = In addition, when a NAT (such as a NAT64 in the "An IPv6 network to IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber fairness issues arise. As such, BEHAVE will complete its work on Carrier Grade NAT requirements for such scenarios, and update the NAT MIB as needed to meet such requirements. BEHAVE will not, however, standardize IPv4-specific behavioral mechanisms. The following scenarios remain in scope for discussion, but will not be solved by BEHAVE: * An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. * IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. This group will also provide reviews of any work by the MBoneD WG on multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). If the WG deems it necessary, BEHAVE will revise RFCs previously published by BEHAVE. Goals and Milestones Done Submit BCP that defines unicast UDP behavioral requirements for = NATs to IESG = Done Submit a BCP that defines TCP behavioral requirements for NATs = to IESG = Done Submit a BCP that defines ICMP behavioral requirements for NATs = to IESG = Done Submit informational that discusses current NAT traversal = techniques used by applications = Done Submit BCP that defines multicast UDP = Done Submit revision of RFC 3489 to IESG behavioral requirements for = NATs to IESG = Done Submit informational document for rfc3489bis test vectors = Done Submit experimental document that describes how an application = can determine the type of NAT it is behind = Done Submit BCP document for DCCP NAT behavior = Done Determine relative prioritization of the four translation cases. = Documented in IETF74 minutes. = Done Determine what solutions(s) and components are needed to solve = each of the four cases. Create new milestones for the = solution(s) and the components. Documented in IETF74 minutes. = Done Submit to IESG: relaying of a TCP bytestream (std) = Done Submit to IESG: relay protocol (std) = Done Submit to IESG: TURN-URI document (std) = Done Submit to IESG: IPv6 relay protocol (std) = Done Submit to IESG: framework for IPv6/IPv4 translation (info) = Done Submit to IESG: stateless IPv6/IPv4 translation (std) = Done Submit to IESG: stateful IPv6/IPv4 translation (std) = Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) = Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) = Done Determine need and scope of multicast 6/4 translation = Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) = Jul 2012 Submit to IESG: large scale NAT requirements (BCP) = Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 = translation (info) Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for = local networks (std) = Done Submit to IESG: host-based NAT46 translation for IPv4-only = applications to access IPv6-only servers (std) = Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) Nov 2012 Submit to IESG: IPFIX information elements (std) From linfeng.john.zheng@gmail.com Tue May 15 14:59:48 2012 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 D831B11E80B7 for ; Tue, 15 May 2012 14:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.103 X-Spam-Level: ** X-Spam-Status: No, score=2.103 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_16=0.013, CN_BODY_24=0.034, CN_BODY_832=0.004, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, 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 vsmjUPKRX08t for ; Tue, 15 May 2012 14:59:47 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBEB11E8074 for ; Tue, 15 May 2012 14:59:47 -0700 (PDT) Received: by ggnc4 with SMTP id c4so111077ggn.31 for ; Tue, 15 May 2012 14:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xTp1L321W5J6T4ScpdiVbtwls0nM238Wi1zoIcoOtCo=; b=WhrmD3L6flARajlFvEJQDCBizusqkus3VX0XVSgXBMpKBDCP439tdp5iPWU1TgxJ/N O67K096Wt/Fz9Lo8hUw4y9q7qXvSeifxPw22Nn6c8gwhNmBTTI+8z8vR5p/mOq5jUmFW Jm3TbcaXrUC/irRqQZGmp3rMrmi9IeyPEWXxoQ6XF/MYDhEas32xlJ8JM2LtPjQnXExh uA0l45toI0/a0ng1L3PE94NI68RSQikawSXE/f7cJN9BJ0H3j50ajbCujwNs+IHLqgHx B2sJG8ycp+nF3/YISNnm8gh796rRVTPMe0nputJhXRiZeFAMq2EJS+Uuc7egFEV09iYT fvEA== MIME-Version: 1.0 Received: by 10.50.186.132 with SMTP id fk4mr8533455igc.23.1337119186397; Tue, 15 May 2012 14:59:46 -0700 (PDT) Received: by 10.231.48.15 with HTTP; Tue, 15 May 2012 14:59:46 -0700 (PDT) Date: Wed, 16 May 2012 05:59:46 +0800 Message-ID: From: Linfeng Zheng To: behave@ietf.org Content-Type: multipart/alternative; boundary=14dae934068d20a8e804c01a52d3 Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 15 May 2012 21:59:49 -0000 --14dae934068d20a8e804c01a52d3 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Sounds good... > From: IESG Secretary > To: IETF Announcement List > Cc: behave@ietf.org, dthaler@microsoft.com, dwing@cisco.com > Date: Tue, 15 May 2012 10:53:24 -0700 > Subject: [BEHAVE] WG Review: Recharter of Behavior Engineering for > Hindrance Avoidance (behave) > A modified charter has been submitted for the Behavior Engineering for > Hindrance Avoidance (behave) working group in the Transport Area of the > IETF. The IESG has not made any determination as yet. The modified > charter is provided below for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May > 22, 2012. > > Behavior Engineering for Hindrance Avoidance (behave) > ----------------------------------------------------- > Current Status: Active > Last updated: 2012-05-10 > > Chairs: > Dan Wing > Dave Thaler > > Transport Area Directors: > Wesley Eddy > Martin Stiemerling > > Transport Area Advisor: > Wesley Eddy > > Mailing Lists: > General Discussion: behave@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/behave > Archive: http://www.ietf.org/mail-archive/web/behave > > Description of Working Group > > The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 > NATs to function in as deterministic a fashion as possible. > > To support deployments where communicating hosts require using > different address families (IPv4 or IPv6), address family translation is > needed to establish communication. In BEHAVE's specification work on > this topic it will coordinate with the V6ops WG on requirements and > operational considerations. > > "An IPv4 network" or "an IPv6 network" in the descriptions below refer > to a network with a clearly identifiable administrative domain (e.g., an > enterprise campus network, a mobile operator's cellular network, a > residential subscriber network, etc.). It will also be that network that > deploys the necessary equipment for translation. > > BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 > Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network > to an IPv4 network, and (4) an IPv4 network to an IPv6 network. > > Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be > consistent with the management aspects of its IPv6/IPv4 NAT solutions, > and specify IPFIX information elements to meet logging requirements, > reusing existing elements, if possible. > > In addition, when a NAT (such as a NAT64 in the "An IPv6 network to > IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber > fairness issues arise. As such, BEHAVE will complete its work on > Carrier Grade NAT requirements for such scenarios, and update the NAT > MIB as needed to meet such requirements. BEHAVE will not, however, > standardize IPv4-specific behavioral mechanisms. > > The following scenarios remain in scope for discussion, but will not be > solved by BEHAVE: > > * An IPv4 network to IPv6 Internet, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv4 network using either > public or private IPv4 address space. > > * IPv4 Internet to an IPv6 network, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv6 network where selected > IPv6 hosts and services are to be reachable. > > This group will also provide reviews of any work by the MBoneD WG on > multicast translation, including control traffic (IGMP and MLD), Single > Source Multicast (SSM) and Any Source Multicast (ASM). > > If the WG deems it necessary, BEHAVE will revise RFCs previously > published by BEHAVE. > > Goals and Milestones > > Done Submit BCP that defines unicast UDP behavioral requirements for > NATs to IESG > Done Submit a BCP that defines TCP behavioral requirements for NATs > to IESG > Done Submit a BCP that defines ICMP behavioral requirements for NATs > to IESG > Done Submit informational that discusses current NAT traversal > techniques used by applications > Done Submit BCP that defines multicast UDP > Done Submit revision of RFC 3489 to IESG behavioral requirements for > NATs to IESG > Done Submit informational document for rfc3489bis test vectors > Done Submit experimental document that describes how an application > can determine the type of NAT it is behind > Done Submit BCP document for DCCP NAT behavior > Done Determine relative prioritization of the four translation cases. > Documented in IETF74 minutes. > Done Determine what solutions(s) and components are needed to solve > each of the four cases. Create new milestones for the > solution(s) and the components. Documented in IETF74 minutes. > Done Submit to IESG: relaying of a TCP bytestream (std) > Done Submit to IESG: relay protocol (std) > Done Submit to IESG: TURN-URI document (std) > Done Submit to IESG: IPv6 relay protocol (std) > Done Submit to IESG: framework for IPv6/IPv4 translation (info) > Done Submit to IESG: stateless IPv6/IPv4 translation (std) > Done Submit to IESG: stateful IPv6/IPv4 translation (std) > Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) > Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) > Done Determine need and scope of multicast 6/4 translation > Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) > Jul 2012 Submit to IESG: large scale NAT requirements (BCP) > Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 > translation (info) > Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for > local networks (std) > Done Submit to IESG: host-based NAT46 translation for IPv4-only > applications to access IPv6-only servers (std) > Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) > Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) > Nov 2012 Submit to IESG: IPFIX information elements (std) > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > --=20 =D0=BB=D0=BB=A3=AC=D6=A3=C1=D6=B7=E5 John Linfeng Zheng *=CC=EC=B5=D8=B2=CA=BB=AA*=CE=C4=BB=AF=D0=C5=CF=A2=D7=C9=D1=AF=D3=D0=CF=DE= =D4=F0=C8=CE=B9=AB=CB=BE CHA Consulting Firm =D6=B4=D0=D0=B6=AD=CA=C2/=BE=AD=C0=ED President/CEO =B5=E7=BB=B0(Tel): +86-591-83809031(O) 15306915548(Cell) 15195762065(=C4= =FENJ) =B5=D8=D6=B7(Addr): =B8=A3=D6=DD=CA=D0=B8=A3=D0=C2=C2=B7239=BA=C5=CB=AB=D7= =D3=D0=C7=B4=F3=CF=C3=C8=FD=C2=A5=A3=C2=C7=F8810=A3=ACP.R.China =B2=A9=BF=CD(Blog): http://blog.sina.com.cn/23gtrees --14dae934068d20a8e804c01a52d3 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Sounds good...
 
From: IESG Secretary <iesg-secretary@ietf.org>
To:&= nbsp;IETF Announcement List <i= etf-announce@ietf.org>
Cc: behave@ietf.org, dthaler@microsoft.com, dwing@cisco.com
Date: Tue, 15 May 2012 10:53:= 24 -0700
Subject: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hin= drance Avoidance (behave)
A modified charter has been submitted for the = Behavior Engineering for Hindrance Avoidance (behave) working group in the = Transport Area of the IETF.  The IESG has not made any determination a= s yet.  The modified charter is provided below for informational purpo= ses only.  Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 22, 2012.

Behavior Engineering for Hindrance Avoidance (behave)
--------------= ---------------------------------------
Current Status: Active
Last u= pdated: 2012-05-10

 Chairs:
    Dan Wing <dwing@cisco.com>
    Dave Thaler <dtha= ler@microsoft.com>

 Transport Area Directors:
  =   Wesley Eddy <wes@mti-syste= ms.com>
    Martin Stiemerling <martin.stiemerling@neclab.eu>

 Transport Area Advisor:
    Wesley Eddy <wes@mti-systems.com>

 Ma= iling Lists:
    General Discussion: behave@ietf.org
    To Subscribe:       https://www.ietf.org/mailm= an/listinfo/behave
    Archive:        = ;    http://www.ietf.org/mail-archive/web/behave

Description of Working Group

The working group creates documents= to enable IPv4/IPv4 and IPv6/IPv4
NATs to function in as deterministic = a fashion as possible.

To support deployments where communicating ho= sts require using
different address families (IPv4 or IPv6), address family translation isneeded to establish communication. In BEHAVE's specification work onthis topic it will coordinate with the V6ops WG on requirements and
operational considerations.

"An IPv4 network" or "an = IPv6 network" in the descriptions below refer
to a network with a c= learly identifiable administrative domain (e.g., an
enterprise campus ne= twork, a mobile operator's cellular network, a
residential subscriber network, etc.). It will also be that network thatdeploys the necessary equipment for translation.

BEHAVE will finish= four scenarios: (1) An IPv6 network to IPv4
Internet, (2) an IPv6 Inter= net to an IPv4 network, (3) an IPv6 network
to an IPv4 network, and (4) an IPv4 network to an IPv6 network.

Spec= ifically, BEHAVE will update the NAT MIB (RFC 4008) to be
consistent wit= h the management aspects of its IPv6/IPv4 NAT solutions,
and specify IPF= IX information elements to meet logging requirements,
reusing existing elements, if possible.

In addition, when a NAT (suc= h as a NAT64 in the "An IPv6 network to
IPv4 Internet" scenari= o) serves multiple subscribers, inter-subscriber
fairness issues arise. =  As such, BEHAVE will complete its work on
Carrier Grade NAT requirements for such scenarios, and update the NAT
MI= B as needed to meet such requirements.  BEHAVE will not, however,
s= tandardize IPv4-specific behavioral mechanisms.

The following scenar= ios remain in scope for discussion, but will not be
solved by BEHAVE:

* An IPv4 network to IPv6 Internet, i.e. perform t= ranslation between
IPv4 and IPv6 for packets in uni- or bi-directional f= lows that are
initiated from an IPv4 host towards an IPv6 host. The tran= slator
function is intended to service a specific IPv4 network using either
pub= lic or private IPv4 address space.

* IPv4 Internet to an IPv6 networ= k, i.e. perform translation between
IPv4 and IPv6 for packets in uni- or= bi-directional flows that are
initiated from an IPv4 host towards an IPv6 host. The translator
functio= n is intended to service a specific IPv6 network where selected
IPv6 hos= ts and services are to be reachable.

This group will also provide re= views of any work by the MBoneD WG on
multicast translation, including control traffic (IGMP and MLD),  Sing= le
Source Multicast (SSM) and Any Source Multicast (ASM).

If the = WG deems it necessary, BEHAVE will revise RFCs previously
published by B= EHAVE.

Goals and Milestones

Done    Submit BCP that defines u= nicast UDP behavioral requirements for
       NATs t= o IESG
Done    Submit a BCP that defines TCP behavioral requir= ements for NATs
       to IESG
Done    Submit a BCP that defines ICMP behavioral requirements fo= r NATs
       to IESG
Done    Submit in= formational that discusses current NAT traversal
      &n= bsp;techniques used by applications
Done    Submit BCP that de= fines multicast UDP
Done    Submit revision of RFC 3489 to IESG behavioral requiremen= ts for
       NATs to IESG
Done    Subm= it informational document for rfc3489bis test vectors
Done    = Submit experimental document that describes how an application
       can determine the type of NAT it is behind
Do= ne    Submit BCP document for DCCP NAT behavior
Done   &n= bsp;Determine relative prioritization of the four translation cases.
&nb= sp;      Documented in IETF74 minutes.
Done    Determine what solutions(s) and components are needed to = solve
       each of the four cases. Create new mile= stones for the
       solution(s) and the components= . Documented in IETF74 minutes.
Done    Submit to IESG: relayi= ng of a TCP bytestream (std)
Done    Submit to IESG: relay protocol (std)
Done    = ;Submit to IESG: TURN-URI document (std)
Done    Submit to IES= G: IPv6 relay protocol (std)
Done    Submit to IESG: framework= for IPv6/IPv4 translation (info)
Done    Submit to IESG: stateless IPv6/IPv4 translation (std)
= Done    Submit to IESG: stateful IPv6/IPv4 translation (std)
D= one    Submit to IESG: DNS rewriting for IPv6/IPv4 translation (s= td)
Done    Submit to IESG: IPv6 prefix for IPv6/IPv4 translat= or (std)
Done    Determine need and scope of multicast 6/4 translation
= Done    Submit to IESG: FTP ALG for IPv6/IPv4 translation (std)Jul 2012  Submit to IESG: large scale NAT requirements (BCP)
Done=    Submit to IESG: Analysis of NAT-PT considerations with IPv6/I= Pv4
       translation (info)
Jul 2012  Submit to I= ESG: avoiding NAT64 with dual-stack host for
       =  local networks (std)
Done    Submit to IESG: host-based= NAT46 translation for IPv4-only
       applications= to access IPv6-only servers (std)
Nov 2012  Submit to IESG: updates to NAT MIB for NAT64 (std)
Nov 20= 12  Submit to IESG: updates to NAT MIB for CGNs (std)
Nov 2012 &nbs= p;Submit to IESG: IPFIX information elements (std)


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

=



--
=D0=BB=D0=BB= =A3=AC=D6=A3=C1=D6=B7=E5 John Linfeng Zheng 
 
=CC=EC=B5=D8=B2=CA=BB=AA=CE=C4=BB=AF=D0=C5=CF=A2=D7=C9= =D1=AF=D3=D0=CF=DE=D4=F0=C8=CE=B9=AB=CB=BE CHA Consulting Firm
=D6=B4=D0=D0=B6=AD=CA=C2/=BE=AD=C0=ED President/CEO
 
=B5=E7=BB=B0(Tel): +86-591-83809031(O)  15306915548(Cell) 1519576= 2065(=C4=FENJ)
=B5=D8=D6=B7(Addr): =B8=A3=D6=DD=CA=D0=B8=A3=D0=C2=C2=B7239=BA=C5=CB= =AB=D7=D3=D0=C7=B4=F3=CF=C3=C8=FD=C2=A5=A3=C2=C7=F8810=A3=ACP.R.China
=B2=A9= =BF=CD(Blog): http://blog.sina.c= om.cn/23gtrees

--14dae934068d20a8e804c01a52d3-- From lee.howard@twcable.com Wed May 16 07:17:10 2012 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 A1F7F21F8622; Wed, 16 May 2012 07:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 4fxbX75S1xlS; Wed, 16 May 2012 07:17:10 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D5D8D21F8613; Wed, 16 May 2012 07:17:09 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,603,1330923600"; d="scan'208";a="365040803" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 16 May 2012 10:15:47 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 16 May 2012 10:16:02 -0400 From: "Howard, Lee" To: IESG Secretary , IETF Announcement List Date: Wed, 16 May 2012 10:16:01 -0400 Thread-Topic: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) Thread-Index: Ac0yw8q5zq8cND2sTiK7sg9+fRxK9gAqTgYA Message-ID: References: <20120515175324.14098.64192.idtracker@ietfa.amsl.com> In-Reply-To: <20120515175324.14098.64192.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 16 May 2012 08:47:39 -0700 Cc: "behave@ietf.org" , "dwing@cisco.com" , "dthaler@microsoft.com" Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 16 May 2012 14:17:10 -0000 Doing a visual diff from the 25 Feb 2012 charter. . . > Description of Working Group > > The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 NAT= s to function > in as deterministic a fashion as possible. That's a new sentence. We now have two WGs chartered to work on NAT44: BEH= AVE and sunset4. How do I know what kind of contribution should go to which group? > > Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be consistent = with the > management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX info= rmation > elements to meet logging requirements, reusing existing elements, if poss= ible. Good. > In addition, when a NAT (such as a NAT64 in the "An IPv6 network to > IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber fa= irness issues arise. As > such, BEHAVE will complete its work on Carrier Grade NAT requirements for= such > scenarios, and update the NAT MIB as needed to meet such requirements. B= EHAVE will > not, however, standardize IPv4-specific behavioral mechanisms. > > The following scenarios remain in scope for discussion, but will not be s= olved by BEHAVE: So we can talk about them, as long as we don't try to solve problems? Where does problem-solving happen, then? Again, I'm just confused about th= e scope here. > > This group will also provide reviews of any work by the MBoneD WG on mult= icast > translation, including control traffic (IGMP and MLD), Single Source Mul= ticast (SSM) and > Any Source Multicast (ASM). This language is better than the old version. > If the WG deems it necessary, BEHAVE will revise RFCs previously publishe= d by > BEHAVE. > > Goals and Milestones ... > Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) > Jul 2012 Submit to IESG: large scale NAT requirements (BCP) I guess sunset4 better hurry up with the review in its charter, then. > Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 > translation (info) > Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for > local networks (std) > Done Submit to IESG: host-based NAT46 translation for IPv4-only > applications to access IPv6-only servers (std) > Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) > Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) > Nov 2012 Submit to IESG: IPFIX information elements (std) Lee This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From dthaler@microsoft.com Thu May 17 06:34:12 2012 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 71D8C21F862B for ; Thu, 17 May 2012 06:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.903 X-Spam-Level: X-Spam-Status: No, score=-103.903 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 GGHFHPAEMZSK for ; Thu, 17 May 2012 06:34:11 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 899D921F8621 for ; Thu, 17 May 2012 06:34:11 -0700 (PDT) Received: from mail52-db3-R.bigfish.com (10.3.81.241) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 17 May 2012 13:34:02 +0000 Received: from mail52-db3 (localhost [127.0.0.1]) by mail52-db3-R.bigfish.com (Postfix) with ESMTP id B17076050A for ; Thu, 17 May 2012 13:34:02 +0000 (UTC) X-SpamScore: -11 X-BigFish: VS-11(z4c5Iab3rzzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail52-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail52-db3 (localhost.localdomain [127.0.0.1]) by mail52-db3 (MessageSwitch) id 1337261641173652_12045; Thu, 17 May 2012 13:34:01 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.236]) by mail52-db3.bigfish.com (Postfix) with ESMTP id 1C3C04008C for ; Thu, 17 May 2012 13:34:01 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 17 May 2012 13:34:00 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 17 May 2012 13:33:53 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 17 May 2012 06:33:53 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.48]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0298.005; Thu, 17 May 2012 06:33:53 -0700 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Reminder: BEHAVE interim today in 30 minutes Thread-Index: Ac00MYer0zc/IvKVQeCToohpAbrXOQ== Date: Thu, 17 May 2012 13:33:52 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B5E9503@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [BEHAVE] Reminder: BEHAVE interim today in 30 minutes 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, 17 May 2012 13:34:12 -0000 As a reminder, we will begin our WebEx meeting in 30 minutes. Agenda and WebEx information are at http://trac.tools.ietf.org/wg/behave/tr= ac/wiki If you have slides and haven't sent me them yet, please do so immediately. -Dave From ssenthil@cisco.com Fri May 18 07:44:13 2012 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 09ADC21F86D1 for ; Fri, 18 May 2012 07:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.9 X-Spam-Level: X-Spam-Status: No, score=-9.9 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 exTH6DVkNkRn for ; Fri, 18 May 2012 07:44:12 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB3A21F86A1 for ; Fri, 18 May 2012 07:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssenthil@cisco.com; l=1499; q=dns/txt; s=iport; t=1337352252; x=1338561852; h=date:subject:from:to:message-id:mime-version; bh=tMiPnUsitXVvk5EBmW0ZAsUZhWBsyGIoguyCP/wqmCM=; b=aiOdOPR63Fw6sakUA37eCBf25jsos2LQ43Sa6Smrt3v2AQqY69F+Nl6A Gj9oikW5CsCCHW6U2kf/4XIBDXJgbt4M+v6VAWdLfhTAAHJOrjYRCj9lX WhZiT5hdWi0dvOVGI4WXnJRsxk5/RHy5VT7bDewjYqFXhhKo6WzgEcoya Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFhftk+rRDoH/2dsb2JhbABFgkWwHYELgQeCDAsBBBIBKk4BCwEFgRUBBDWHawGbI4EooAONJ4MeA41Vh0uOEYFkgwU X-IronPort-AV: E=Sophos;i="4.75,617,1330905600"; d="scan'208,217";a="45241765" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 May 2012 14:44:12 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4IEiCO8010391 for ; Fri, 18 May 2012 14:44:12 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 May 2012 07:44:12 -0700 Received: from 10.150.24.92 ([10.150.24.92]) by xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 May 2012 14:44:11 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Fri, 18 May 2012 10:44:09 -0400 From: ssenthil To: Message-ID: Thread-Topic: One MIB document or two? Thread-Index: Ac01BK6ofqqVweSs10SNjYFbSCCidQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3420182651_11867656" X-OriginalArrivalTime: 18 May 2012 14:44:12.0026 (UTC) FILETIME=[B075BDA0:01CD3504] Subject: [BEHAVE] One MIB document or two? 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, 18 May 2012 14:44:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3420182651_11867656 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The initial MIB draft had both NAT MIB objects and CGN specific MIB objects. It was later decided to split the CGN objects into a separate MIB document. That was done with the last revision, but we are back again on the topic if one document is better or two. There are mixed opinions on either side and hence would like some guidance from WG. Please share your opinions and rationale for having one or two. Thanks Senthil --B_3420182651_11867656 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable One MIB document or two? The initial MIB draft had both NAT MIB objects and  CGN specific MIB = objects. It was later decided to split the CGN objects into a separate MIB d= ocument.
That was done with the last revision, but we are back again on the topic if= one document is better or two. There are mixed opinions on either side and = hence
would like some guidance from WG. Please share your opinions and rationale = for having one or two.

Thanks
Senthil --B_3420182651_11867656-- From teemu.savolainen@nokia.com Mon May 21 23:38:44 2012 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 104D421F8480 for ; Mon, 21 May 2012 23:38:44 -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 XCI6-HVNcuKM for ; Mon, 21 May 2012 23:38:43 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 741DF21F847F for ; Mon, 21 May 2012 23:38:43 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4M6cFUQ028954 for ; Tue, 22 May 2012 09:38:35 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 May 2012 09:37:38 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.148]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Tue, 22 May 2012 08:37:38 +0200 From: To: Thread-Topic: RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP Thread-Index: Ac035EdMZAkwY9XkQbuhwSq5iWSzUw== Date: Tue, 22 May 2012 06:37:37 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204380A2B@008-AM1MPN1-052.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IpQxMUXtONfvl1934VOO1ElboOZ10+9WOY+xpTcPXUBalvop1myCjQCPWcttFSopdR45JSYd6D7P0k9sgIE94OPb8hdtCcYiigi2dXzCDt8d7+YolIEh5IwbaieNVzGPBqM8SRLiEoEgrOj5JybYFHVbAwI8mjI8n4OvL6IFtzsSIhXsxowJZ/JyzvUq69yu1bhhivoDK6/A4htDBJkKMbgDt/GQS6c7GawlRPgEvp6bJOGH7jPIBlL00Z0RQ42cig== x-originating-ip: [10.163.19.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 May 2012 06:37:38.0877 (UTC) FILETIME=[61A3B6D0:01CD37E5] X-Nokia-AV: Clean Subject: [BEHAVE] RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP 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, 22 May 2012 06:38:44 -0000 Hi, RFC6052 says in section 3.1: -- The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. -- After reading the sentence, again, and few times more, does it mean WKP *ca= n* be used to represent *global* IPv4 addresses listed in Section 3 of RFC5= 735?=20 If they can be used with WKP, are all of these address blocks considered gl= obal: - 192.88.99.0/24 - 6to4 relay anycast address - these can appear in public = Internet - 192.0.0.0/24 - IETF protocol assignments - The RFC5735 does not really st= ate if that block is global or not..=20 - 224.0.0.0/4 multicast block I'm asking this clarification as I'm thinking what could be good IPv4 addre= sses for well-known names used for NAT64 heuristic discovery. And maybe if = 192.0.0.0/24 can be considered global in the spirit of RFC6052, that might = be best place to get addresses. Best regards, Teemu From huitema@microsoft.com Mon May 21 23:51:41 2012 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 A67FE9E8013 for ; Mon, 21 May 2012 23:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 bfrhnLzW+ERH for ; Mon, 21 May 2012 23:51:41 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 904609E8019 for ; Mon, 21 May 2012 23:51:40 -0700 (PDT) Received: from mail126-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 22 May 2012 06:51:26 +0000 Received: from mail126-am1 (localhost [127.0.0.1]) by mail126-am1-R.bigfish.com (Postfix) with ESMTP id EDFD7164006A; Tue, 22 May 2012 06:51:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz9371Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail126-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=huitema@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail126-am1 (localhost.localdomain [127.0.0.1]) by mail126-am1 (MessageSwitch) id 1337669484182793_31202; Tue, 22 May 2012 06:51:24 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.241]) by mail126-am1.bigfish.com (Postfix) with ESMTP id 2AE141C40046; Tue, 22 May 2012 06:51:24 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 22 May 2012 06:51:23 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.76]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Tue, 22 May 2012 06:51:35 +0000 From: Christian Huitema To: "teemu.savolainen@nokia.com" , "behave@ietf.org" Thread-Topic: RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP Thread-Index: Ac035EdMZAkwY9XkQbuhwSq5iWSzUwAAqVTC Date: Tue, 22 May 2012 06:51:34 +0000 Message-ID: References: <916CE6CF87173740BC8A2CE44309696204380A2B@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204380A2B@008-AM1MPN1-052.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [BEHAVE] RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP 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, 22 May 2012 06:51:41 -0000 The rationale behind the text is simple: if an address is not global, then = the translation is ambiguous. If an address is global, the translation will= work as expected -- even if the address is IETF assigned, or otherwise spe= cial. For example, many root DNS servers seat behind the same IPV4 address= , effectively an "anycast" address. Using the WKP with such addresses would= work just fine. ________________________________________ From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of teemu.= savolainen@nokia.com [teemu.savolainen@nokia.com] Sent: Monday, May 21, 2012 11:37 PM To: behave@ietf.org Subject: [BEHAVE] RFC6052, RFC5735, and "non-global IPv4 addresses" with WK= P Hi, RFC6052 says in section 3.1: -- The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. -- After reading the sentence, again, and few times more, does it mean WKP *ca= n* be used to represent *global* IPv4 addresses listed in Section 3 of RFC5= 735? If they can be used with WKP, are all of these address blocks considered gl= obal: - 192.88.99.0/24 - 6to4 relay anycast address - these can appear in public = Internet - 192.0.0.0/24 - IETF protocol assignments - The RFC5735 does not really st= ate if that block is global or not.. - 224.0.0.0/4 multicast block I'm asking this clarification as I'm thinking what could be good IPv4 addre= sses for well-known names used for NAT64 heuristic discovery. And maybe if = 192.0.0.0/24 can be considered global in the spirit of RFC6052, that might = be best place to get addresses. Best regards, Teemu _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave= From teemu.savolainen@nokia.com Tue May 22 01:18:46 2012 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 1B20B21F85CE for ; Tue, 22 May 2012 01:18:46 -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 uYmbVSgHxK0s for ; Tue, 22 May 2012 01:18:44 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E478221F8552 for ; Tue, 22 May 2012 01:18:42 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4M8IVs6009445; Tue, 22 May 2012 11:18:39 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 May 2012 11:18:38 +0300 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.148]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0283.004; Tue, 22 May 2012 10:18:37 +0200 From: To: , Thread-Topic: RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP Thread-Index: Ac035EdMZAkwY9XkQbuhwSq5iWSzUwAAqVTCAALgGZA= Date: Tue, 22 May 2012 08:18:36 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204380B57@008-AM1MPN1-052.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696204380A2B@008-AM1MPN1-052.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IpdRy85yS/uiAOzK55iCpCFtaNKfObtPYiGlAP57EuItglnxfm3MA7TrPXUMQUAy1AeN1BR4wvxgGWXu+naULvjQYSd2PX9PpWoQ0855nxqGQj7w8RHMxrqQZ+MOKWFGwKZ/DheVfnwyur5R09nLGV2au6xbQFVIEjtUSXuFx2SSERqer35dhChygNCHJs3TY+TK8g5LaviTQsxgil4glYMVtJppFq7sD490oJBMsQQnwZohIwQLQzmgyug0nGrz0g== x-originating-ip: [10.163.19.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 May 2012 08:18:38.0477 (UTC) FILETIME=[7D714BD0:01CD37F3] X-Nokia-AV: Clean Subject: Re: [BEHAVE] RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP 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, 22 May 2012 08:18:46 -0000 Great. So then we could simply use two or so addresses from 192.0.0.0/24 an= d specify in the heuristic document that these addresses are considered as = global scope (and hence valid to appear with WKP).=20 I hope there are no existing validation codes in DNS64s that would get head= ache with A record containing addresses from this 192.0.0.0/24 block? Best regards, Teemu > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@microsoft.com] > Sent: 22. toukokuuta 2012 09:52 > To: Savolainen Teemu (Nokia-NRC/Tampere); behave@ietf.org > Subject: RE: RFC6052, RFC5735, and "non-global IPv4 addresses" with WKP >=20 > The rationale behind the text is simple: if an address is not global, the= n the > translation is ambiguous. If an address is global, the translation will w= ork as > expected -- even if the address is IETF assigned, or otherwise special. = For > example, many root DNS servers seat behind the same IPV4 address, > effectively an "anycast" address. Using the WKP with such addresses would > work just fine. >=20 > ________________________________________ > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of > teemu.savolainen@nokia.com [teemu.savolainen@nokia.com] > Sent: Monday, May 21, 2012 11:37 PM > To: behave@ietf.org > Subject: [BEHAVE] RFC6052, RFC5735, and "non-global IPv4 addresses" with > WKP >=20 > Hi, >=20 > RFC6052 says in section 3.1: > -- > The Well-Known Prefix MUST NOT be used to represent non-global IPv4 > addresses, such as those defined in [RFC1918] or listed in Section 3 > of [RFC5735]. > -- > After reading the sentence, again, and few times more, does it mean WKP > *can* be used to represent *global* IPv4 addresses listed in Section 3 of > RFC5735? >=20 > If they can be used with WKP, are all of these address blocks considered > global: > - 192.88.99.0/24 - 6to4 relay anycast address - these can appear in publi= c > Internet > - 192.0.0.0/24 - IETF protocol assignments - The RFC5735 does not really = state > if that block is global or not.. > - 224.0.0.0/4 multicast block >=20 > I'm asking this clarification as I'm thinking what could be good IPv4 add= resses > for well-known names used for NAT64 heuristic discovery. And maybe if > 192.0.0.0/24 can be considered global in the spirit of RFC6052, that migh= t be > best place to get addresses. >=20 > Best regards, >=20 > Teemu > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From internet-drafts@ietf.org Thu May 24 03:13:24 2012 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 8DE6721F860D; Thu, 24 May 2012 03:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 19DNTlRYADUC; Thu, 24 May 2012 03:13:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CC821F85B1; Thu, 24 May 2012 03:13:24 -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.02 Message-ID: <20120524101324.16675.77939.idtracker@ietfa.amsl.com> Date: Thu, 24 May 2012 03:13:24 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-09.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, 24 May 2012 10:13:24 -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 Av= oidance Working Group of the IETF. Title : Discovery of IPv6 Prefix Used for IPv6 Address Synthesis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-09.txt Pages : 14 Date : 2012-05-24 This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network. The method depends on 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 traversal through NAT64 on dual-stack accesses and multi-interface deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuri= stic-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuris= tic-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristi= c/ From teemu.savolainen@nokia.com Thu May 24 07:07:57 2012 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 CA46221F8694 for ; Thu, 24 May 2012 07:07:57 -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 CEwsoVRKD9jS for ; Thu, 24 May 2012 07:07:57 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 261AD21F8687 for ; Thu, 24 May 2012 07:07:56 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4OE7sT0016533 for ; Thu, 24 May 2012 17:07:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 17:07:53 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.37]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Thu, 24 May 2012 16:07:53 +0200 From: To: Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-09.txt Thread-Index: AQHNOZXnqLkIi2nxtE626SVz7/rKcpbY+S3Q Date: Thu, 24 May 2012 14:07:52 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620438F996@008-AM1MPN1-053.mgdnok.nokia.com> References: <20120524101324.16675.77939.idtracker@ietfa.amsl.com> In-Reply-To: <20120524101324.16675.77939.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiK+ntKbo4xPTApCTPxRn9Xp0LtY+cpSPQLNR71P2TG4kgg0XOW5vk1ilxPAk1qHuq6hNFWU6OECc3tPiMkO+UbST8BGaFKjycAtfY//P/cLFjCBjyU+KYyo/uNXoBQrwnI2vmW4vgtYopjunkxapILJTj6021N6+/pCMfxrp7LByvTZPGSOk6VpusAZe9U5zfHt6xR0NGSG9y6TiMQtnPfddhriYeGq8B+vovaVsIhvzEHNjRWBKV/3GgiLbYOcmWWGTa1/IJd/V8JQzO3Mh8s= x-originating-ip: [10.163.19.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 May 2012 14:07:53.0933 (UTC) FILETIME=[9CB19FD0:01CD39B6] X-Nokia-AV: Clean Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-09.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, 24 May 2012 14:07:57 -0000 Here is an update to the draft according to what was discussed in the inter= im, and briefly in this list. 1) Further clarifications to the connectivity check procedures 2) Clear request for IANA to allocate at least two global IPv4 addresses fr= om 192.0.0.0/24 address pool Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext internet-drafts@ietf.org > Sent: 24. toukokuuta 2012 13:13 > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic= - > 09.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Behavior Engineering for Hindrance Avoid= ance > Working Group of the IETF. > > Title : Discovery of IPv6 Prefix Used for IPv6 Address Sy= nthesis > Author(s) : Teemu Savolainen > Jouni Korhonen > Dan Wing > Filename : draft-ietf-behave-nat64-discovery-heuristic-09.tx= t > Pages : 14 > Date : 2012-05-24 > > This document describes a method for detecting presence of DNS64 and > for learning IPv6 prefix used for protocol translation on an access > network. The method depends on 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 > traversal through NAT64 on dual-stack accesses and multi-interface > deployments. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery- > heuristic-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heur= istic- > 09.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuris= tic/ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From fluffy@iii.ca Fri May 25 15:30:57 2012 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 EE9A021F882D; Fri, 25 May 2012 15:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 GvZrM6qL2Hvx; Fri, 25 May 2012 15:30:56 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id DF77521F882E; Fri, 25 May 2012 15:30:55 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5FE2022E259; Fri, 25 May 2012 18:30:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <20120515175324.14098.64192.idtracker@ietfa.amsl.com> Date: Fri, 25 May 2012 16:30:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120515175324.14098.64192.idtracker@ietfa.amsl.com> To: The IESG , IETF discussion X-Mailer: Apple Mail (2.1084) Cc: behave@ietf.org, Dan Wing , dthaler@microsoft.com Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 25 May 2012 22:30:57 -0000 WIll the IPFIX and MIB work also be usable by v4 to v4 NATs? On May 15, 2012, at 11:53 AM, IESG Secretary wrote: > A modified charter has been submitted for the Behavior Engineering for = Hindrance Avoidance (behave) working group in the Transport Area of the = IETF. The IESG has not made any determination as yet. The modified = charter is provided below for informational purposes only. Please send = your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May = 22, 2012. >=20 > Behavior Engineering for Hindrance Avoidance (behave) > ----------------------------------------------------- > Current Status: Active > Last updated: 2012-05-10 >=20 > Chairs: > Dan Wing > Dave Thaler >=20 > Transport Area Directors: > Wesley Eddy > Martin Stiemerling >=20 > Transport Area Advisor: > Wesley Eddy >=20 > Mailing Lists: > General Discussion: behave@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/behave > Archive: http://www.ietf.org/mail-archive/web/behave >=20 > Description of Working Group >=20 > The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 > NATs to function in as deterministic a fashion as possible. >=20 > To support deployments where communicating hosts require using > different address families (IPv4 or IPv6), address family translation = is > needed to establish communication. In BEHAVE's specification work on > this topic it will coordinate with the V6ops WG on requirements and > operational considerations. >=20 > "An IPv4 network" or "an IPv6 network" in the descriptions below refer > to a network with a clearly identifiable administrative domain (e.g., = an > enterprise campus network, a mobile operator's cellular network, a > residential subscriber network, etc.). It will also be that network = that > deploys the necessary equipment for translation. >=20 > BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 > Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network > to an IPv4 network, and (4) an IPv4 network to an IPv6 network. >=20 > Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be > consistent with the management aspects of its IPv6/IPv4 NAT solutions, > and specify IPFIX information elements to meet logging requirements, > reusing existing elements, if possible.=20 >=20 > In addition, when a NAT (such as a NAT64 in the "An IPv6 network to > IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber > fairness issues arise. As such, BEHAVE will complete its work on > Carrier Grade NAT requirements for such scenarios, and update the NAT > MIB as needed to meet such requirements. BEHAVE will not, however, > standardize IPv4-specific behavioral mechanisms. >=20 > The following scenarios remain in scope for discussion, but will not = be > solved by BEHAVE: >=20 > * An IPv4 network to IPv6 Internet, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv4 network using either > public or private IPv4 address space. >=20 > * IPv4 Internet to an IPv6 network, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv6 network where selected > IPv6 hosts and services are to be reachable. >=20 > This group will also provide reviews of any work by the MBoneD WG on > multicast translation, including control traffic (IGMP and MLD), = Single > Source Multicast (SSM) and Any Source Multicast (ASM). >=20 > If the WG deems it necessary, BEHAVE will revise RFCs previously > published by BEHAVE. >=20 > Goals and Milestones >=20 > Done Submit BCP that defines unicast UDP behavioral requirements for=20= > NATs to IESG=20 > Done Submit a BCP that defines TCP behavioral requirements for NATs=20= > to IESG=20 > Done Submit a BCP that defines ICMP behavioral requirements for NATs=20= > to IESG=20 > Done Submit informational that discusses current NAT traversal=20 > techniques used by applications=20 > Done Submit BCP that defines multicast UDP=20 > Done Submit revision of RFC 3489 to IESG behavioral requirements for=20= > NATs to IESG=20 > Done Submit informational document for rfc3489bis test vectors=20 > Done Submit experimental document that describes how an application=20= > can determine the type of NAT it is behind=20 > Done Submit BCP document for DCCP NAT behavior=20 > Done Determine relative prioritization of the four translation cases.=20= > Documented in IETF74 minutes.=20 > Done Determine what solutions(s) and components are needed to solve=20= > each of the four cases. Create new milestones for the=20 > solution(s) and the components. Documented in IETF74 minutes.=20= > Done Submit to IESG: relaying of a TCP bytestream (std)=20 > Done Submit to IESG: relay protocol (std)=20 > Done Submit to IESG: TURN-URI document (std)=20 > Done Submit to IESG: IPv6 relay protocol (std)=20 > Done Submit to IESG: framework for IPv6/IPv4 translation (info)=20 > Done Submit to IESG: stateless IPv6/IPv4 translation (std)=20 > Done Submit to IESG: stateful IPv6/IPv4 translation (std)=20 > Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std)=20 > Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std)=20 > Done Determine need and scope of multicast 6/4 translation=20 > Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std)=20 > Jul 2012 Submit to IESG: large scale NAT requirements (BCP)=20 > Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4=20= > translation (info) > Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for=20 > local networks (std)=20 > Done Submit to IESG: host-based NAT46 translation for IPv4-only=20 > applications to access IPv6-only servers (std)=20 > Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) > Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) > Nov 2012 Submit to IESG: IPFIX information elements (std) From ietfdbh@comcast.net Fri May 25 22:00:38 2012 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 F0FF621F8818 for ; Fri, 25 May 2012 22:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 j1J4Iq2iHAd9 for ; Fri, 25 May 2012 22:00:36 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 49EF221F87E2 for ; Fri, 25 May 2012 22:00:35 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id EUzW1j0011ap0As51V0aHF; Sat, 26 May 2012 05:00:34 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta22.westchester.pa.mail.comcast.net with comcast id EV0W1j00k3Ecudz3iV0XpH; Sat, 26 May 2012 05:00:34 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Sat, 26 May 2012 01:00:29 -0400 From: David Harrington To: Cullen Jennings , The IESG , IETF discussion Message-ID: Thread-Topic: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: behave@ietf.org, dthaler@microsoft.com, Dan Wing Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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: Sat, 26 May 2012 05:00:38 -0000 Hi Cullen, I would assume the MIB module would be written in a way to be IP version agnostic. But I'm not sure the NAT technologies are version agnostic. And I'm not sure that the current NAT-MIB can support the version-agnostic addressing textual conventions (I haven't looked yet). I have similar expectations regarding ipfix IEs. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 5/25/12 6:30 PM, "Cullen Jennings" wrote: > >WIll the IPFIX and MIB work also be usable by v4 to v4 NATs? > > >On May 15, 2012, at 11:53 AM, IESG Secretary wrote: > >> A modified charter has been submitted for the Behavior Engineering for >>Hindrance Avoidance (behave) working group in the Transport Area of the >>IETF. The IESG has not made any determination as yet. The modified >>charter is provided below for informational purposes only. Please send >>your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May >>22, 2012. >> >> Behavior Engineering for Hindrance Avoidance (behave) >> ----------------------------------------------------- >> Current Status: Active >> Last updated: 2012-05-10 >> >> Chairs: >> Dan Wing >> Dave Thaler >> >> Transport Area Directors: >> Wesley Eddy >> Martin Stiemerling >> >> Transport Area Advisor: >> Wesley Eddy >> >> Mailing Lists: >> General Discussion: behave@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/behave >> Archive: http://www.ietf.org/mail-archive/web/behave >> >> Description of Working Group >> >> The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 >> NATs to function in as deterministic a fashion as possible. >> >> To support deployments where communicating hosts require using >> different address families (IPv4 or IPv6), address family translation is >> needed to establish communication. In BEHAVE's specification work on >> this topic it will coordinate with the V6ops WG on requirements and >> operational considerations. >> >> "An IPv4 network" or "an IPv6 network" in the descriptions below refer >> to a network with a clearly identifiable administrative domain (e.g., an >> enterprise campus network, a mobile operator's cellular network, a >> residential subscriber network, etc.). It will also be that network that >> deploys the necessary equipment for translation. >> >> BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 >> Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network >> to an IPv4 network, and (4) an IPv4 network to an IPv6 network. >> >> Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be >> consistent with the management aspects of its IPv6/IPv4 NAT solutions, >> and specify IPFIX information elements to meet logging requirements, >> reusing existing elements, if possible. >> >> In addition, when a NAT (such as a NAT64 in the "An IPv6 network to >> IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber >> fairness issues arise. As such, BEHAVE will complete its work on >> Carrier Grade NAT requirements for such scenarios, and update the NAT >> MIB as needed to meet such requirements. BEHAVE will not, however, >> standardize IPv4-specific behavioral mechanisms. >> >> The following scenarios remain in scope for discussion, but will not be >> solved by BEHAVE: >> >> * An IPv4 network to IPv6 Internet, i.e. perform translation between >> IPv4 and IPv6 for packets in uni- or bi-directional flows that are >> initiated from an IPv4 host towards an IPv6 host. The translator >> function is intended to service a specific IPv4 network using either >> public or private IPv4 address space. >> >> * IPv4 Internet to an IPv6 network, i.e. perform translation between >> IPv4 and IPv6 for packets in uni- or bi-directional flows that are >> initiated from an IPv4 host towards an IPv6 host. The translator >> function is intended to service a specific IPv6 network where selected >> IPv6 hosts and services are to be reachable. >> >> This group will also provide reviews of any work by the MBoneD WG on >> multicast translation, including control traffic (IGMP and MLD), Single >> Source Multicast (SSM) and Any Source Multicast (ASM). >> >> If the WG deems it necessary, BEHAVE will revise RFCs previously >> published by BEHAVE. >> >> Goals and Milestones >> >> Done Submit BCP that defines unicast UDP behavioral requirements for >> NATs to IESG >> Done Submit a BCP that defines TCP behavioral requirements for NATs >> to IESG >> Done Submit a BCP that defines ICMP behavioral requirements for NATs >> to IESG >> Done Submit informational that discusses current NAT traversal >> techniques used by applications >> Done Submit BCP that defines multicast UDP >> Done Submit revision of RFC 3489 to IESG behavioral requirements for >> NATs to IESG >> Done Submit informational document for rfc3489bis test vectors >> Done Submit experimental document that describes how an application >> can determine the type of NAT it is behind >> Done Submit BCP document for DCCP NAT behavior >> Done Determine relative prioritization of the four translation cases. >> Documented in IETF74 minutes. >> Done Determine what solutions(s) and components are needed to solve >> each of the four cases. Create new milestones for the >> solution(s) and the components. Documented in IETF74 minutes. >> Done Submit to IESG: relaying of a TCP bytestream (std) >> Done Submit to IESG: relay protocol (std) >> Done Submit to IESG: TURN-URI document (std) >> Done Submit to IESG: IPv6 relay protocol (std) >> Done Submit to IESG: framework for IPv6/IPv4 translation (info) >> Done Submit to IESG: stateless IPv6/IPv4 translation (std) >> Done Submit to IESG: stateful IPv6/IPv4 translation (std) >> Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) >> Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) >> Done Determine need and scope of multicast 6/4 translation >> Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) >> Jul 2012 Submit to IESG: large scale NAT requirements (BCP) >> Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 >> translation (info) >> Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for >> local networks (std) >> Done Submit to IESG: host-based NAT46 translation for IPv4-only >> applications to access IPv6-only servers (std) >> Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) >> Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) >> Nov 2012 Submit to IESG: IPFIX information elements (std) > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Mon May 28 06:35:20 2012 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 5548B21F8494; Mon, 28 May 2012 06:35:20 -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 bFybxoFbHtnp; Mon, 28 May 2012 06:35:19 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CD5CB21F8493; Mon, 28 May 2012 06:35:19 -0700 (PDT) Received: from [192.168.0.100] (modemcable010.192-131-66.mc.videotron.ca [66.131.192.10]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6E81440031; Mon, 28 May 2012 09:35:18 -0400 (EDT) Message-ID: <4FC37F16.6070904@viagenie.ca> Date: Mon, 28 May 2012 09:35:18 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Cullen Jennings References: <20120515175324.14098.64192.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dthaler@microsoft.com, behave@ietf.org, The IESG , Dan Wing , IETF discussion Subject: Re: [BEHAVE] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 28 May 2012 13:35:20 -0000 On 2012-05-25 18:30, Cullen Jennings wrote: > WIll the IPFIX and MIB work also be usable by v4 to v4 NATs? Speaking as an author of draft-ietf-behave-nat-mib, our intent is to support all kinds of NAT, but it isn't clear yet whether it will be done in multiple drafts or a single one. There is stuff that is common to all NAT no matter the IP version, and there stuff that is IP version specific. 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 From wwwrun@rfc-editor.org Wed May 30 17:49:36 2012 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 8F19E11E812C for ; Wed, 30 May 2012 17:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, 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 ZtqApMJNOgkt for ; Wed, 30 May 2012 17:49:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2621D11E80D5 for ; Wed, 30 May 2012 17:49:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CB703621A0; Wed, 30 May 2012 17:48:55 -0700 (PDT) To: marcelo@it.uc3m.es, ajs@shinkuro.com, philip_matthews@magma.ca, iljitsch@muada.com, wes@mti-systems.com, martin.stiemerling@neclab.eu, dwing@cisco.com, dthaler@microsoft.com From: RFC Errata System Message-Id: <20120531004855.CB703621A0@rfc-editor.org> Date: Wed, 30 May 2012 17:48:55 -0700 (PDT) Cc: behave@ietf.org, marka@isc.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC6147 (3236) 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, 31 May 2012 00:49:36 -0000 The following errata report has been submitted for RFC6147, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6147&eid=3236 -------------------------------------- Type: Technical Reported by: Mark Andrews Section: 5.5 Original Text ------------- An application that wants to perform validation on its own should use the CD bit. Corrected Text -------------- Section 5.5 needs to be completely re analysed, Notes ----- Section 5.5 is written around the assumption that a validating stub resolver will be setting CD=1 as well as DO=1. There is no such requirement RFC 4035 and in fact setting both CD=1 and DO=1 leaves the stub resolver vulnerable to answers from authoritative servers for the zone that are serving a stale copy of the zone and spoofed answers being sent to the DNS64 server. Non CD=1 queries result in the DNS64 server in its recursive roll, filtering out, cryptographically bad answers. DO=1 alone should disable synthesis. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6147 (draft-ietf-behave-dns64-11) -------------------------------------- Title : DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Publication Date : April 2011 Author(s) : M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From wes@mti-systems.com Wed May 30 21:19:41 2012 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 536E211E80A3 for ; Wed, 30 May 2012 21:19:41 -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 BFBEnxtFsknW for ; Wed, 30 May 2012 21:19:40 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB6711E80FA for ; Wed, 30 May 2012 21:19:37 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q4V4JXDm028791 for ; Thu, 31 May 2012 00:19:36 -0400 Authentication-Results: cm-omr11 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.202] ([69.81.143.202:34777] helo=[192.168.1.106]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C0/70-11548-551F6CF4; Thu, 31 May 2012 00:19:33 -0400 Message-ID: <4FC6F151.3080404@mti-systems.com> Date: Thu, 31 May 2012 00:19:29 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: draft-ietf-behave-lsn-requirements-all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: [BEHAVE] AD review of LSN requirements draft 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, 31 May 2012 04:19:41 -0000 Hi, I've completed an AD review of the LSN requirements draft. I think it's generally in pretty good shape, but do have some comments that we should at least talk about before going forward. This could require a small update. I also understand from the mailing list that Simon has a proposed reversal of one of the previous changes, and I think he's totally correct. So, we should get a revision anyways before moving on. Here are my comments: (1) it strongly seems like RFC 6264 should be mentioned here; it would probably work in the 2nd paragraph of the Introduction about providing IPv6 services alongside IPv4 CGN (2) it seems like it should be really clear in section 1 that this document isn't considering multi-subscriber IPv6 NPT or dual layers of IPv6 NPT as being a CGN, only multi-subscriber IPv4 NAT and dual layers of IPv4 NAT (3) Note that the sub-requirements for individual NAT behavior RFCs are labelled "REQ-1", "REQ-2", etc. duplicatively with the higher-level REQ-1, REQ-2, etc. (4) Several of the requirements have "SHOULD" in them, which makes them more of a recommendation than an actual requirement (those are MUSTs!); if we want to retain "SHOULD"s, then we probably need to suggest why they aren't MUSTs by giving some cogent example of a case where it would be acceptable not to implement the feature. (this applies to the SHOULD NOTs as well) (5) Should there be a requirement to support use of the prefix allocated via RFC 6598? (6) I think it would be good to have an advisory reference to the issues in: http://tools.ietf.org/html/draft-donley-nat444-impacts-03 and whether or not following the recommendations in this document helps to avoid such issues. The RFC 6269 reference already in the introduction is okay, but it probably glosses over this topic too quickly. (7) I suspect that we should be more clear in the abstract and introduction that this is not an IETF endorsement of CGN or a real specification for CGN, but rather just a minimal set of requirements that we believe need to be followed for implementing CGNs on the Internet; CGNs are still not something we have consensus on being desirable for the Internet. -- Wes Eddy MTI Systems From dwing@cisco.com Thu May 31 08:01:55 2012 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 293D021F8753 for ; Thu, 31 May 2012 08:01:55 -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 03fz85-+4rzC for ; Thu, 31 May 2012 08:01:54 -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 72FD221F8746 for ; Thu, 31 May 2012 08:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2990; q=dns/txt; s=iport; t=1338476514; x=1339686114; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Azk9D06zVy6SBHyT3alA29cfmEUC2RgxyWoW78tT2+E=; b=eJYgksUilKVwtwzayku4jm3hTKr8foWxpR+S4NQJRaVRn81asPoWdfDf /5yQTLG31aC8K5rt+0j2rKhgZ38yIovjaGqE26464oGFbwB7rMMYpG03h EJyMQDpTUe1XUqB3BpT3v8noJ1GHLk7xMENiGco0reECyaR65Rp3iDdFL Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAGHx0+rRDoI/2dsb2JhbABEpQ6OfYEHghgBAQEECAoBFxA0CwwBAwIJDgECBAEBKAcZIwoJCAEBBBMJAheHaAyZHZ9aixEahSwDiECEe4hsjH6BZoMAgT8 X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="47123231" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 31 May 2012 15:01:54 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4VF1rL5018067; Thu, 31 May 2012 15:01:53 GMT From: "Dan Wing" To: "'Wesley Eddy'" References: <4FC6F151.3080404@mti-systems.com> In-Reply-To: <4FC6F151.3080404@mti-systems.com> Date: Thu, 31 May 2012 08:01:53 -0700 Message-ID: <05b701cd3f3e$50a5ae50$f1f10af0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0+5J/qd3ctvhB7T02yRqKRdBmHdgAWJjuw Content-Language: en-us Cc: behave@ietf.org, 'Behave Chairs' Subject: Re: [BEHAVE] AD review of LSN requirements draft 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, 31 May 2012 15:01:55 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Wesley Eddy > Sent: Wednesday, May 30, 2012 9:19 PM > To: draft-ietf-behave-lsn-requirements-all@tools.ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] AD review of LSN requirements draft > > Hi, I've completed an AD review of the LSN requirements draft. > > I think it's generally in pretty good shape, but do have some > comments that we should at least talk about before going forward. > This could require a small update. I also understand from the > mailing list that Simon has a proposed reversal of one of the > previous changes, and I think he's totally correct. So, we > should get a revision anyways before moving on. > > Here are my comments: > > (1) it strongly seems like RFC 6264 should be mentioned here; > it would probably work in the 2nd paragraph of the Introduction > about providing IPv6 services alongside IPv4 CGN > > (2) it seems like it should be really clear in section 1 that > this document isn't considering multi-subscriber IPv6 NPT or > dual layers of IPv6 NPT as being a CGN, only multi-subscriber > IPv4 NAT and dual layers of IPv4 NAT > > (3) Note that the sub-requirements for individual NAT > behavior RFCs are labelled "REQ-1", "REQ-2", etc. > duplicatively with the higher-level REQ-1, REQ-2, etc. > > (4) Several of the requirements have "SHOULD" in them, > which makes them more of a recommendation than an > actual requirement (those are MUSTs!); if we want to > retain "SHOULD"s, then we probably need to suggest > why they aren't MUSTs by giving some cogent example > of a case where it would be acceptable not to implement > the feature. (this applies to the SHOULD NOTs as well) > > (5) Should there be a requirement to support use of > the prefix allocated via RFC 6598? > > (6) I think it would be good to have an advisory > reference to the issues in: > http://tools.ietf.org/html/draft-donley-nat444-impacts-03 > and whether or not following the recommendations in this > document helps to avoid such issues. The RFC 6269 > reference already in the introduction is okay, but it > probably glosses over this topic too quickly. The test results of draft-donley-nat444-impacts received comments by myself and Reinaldo Penno in 2010, http://www.ietf.org/mail-archive/web/behave/current/msg09027.html http://www.ietf.org/mail-archive/web/behave/current/msg09030.html and the authors have been unable to provide sufficient detail for others to duplicate the test results. > (7) I suspect that we should be more clear in the abstract > and introduction that this is not an IETF endorsement of > CGN or a real specification for CGN, but rather just a > minimal set of requirements that we believe need to be > followed for implementing CGNs on the Internet; CGNs are > still not something we have consensus on being desirable > for the Internet. -d From simon.perreault@viagenie.ca Thu May 31 10:39:53 2012 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 1F40411E80C5 for ; Thu, 31 May 2012 10:39:53 -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 vF++J0x04l0R for ; Thu, 31 May 2012 10:39:52 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 8167211E80F5 for ; Thu, 31 May 2012 10:39:49 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:d124:e508:53bd:2021]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CD4574264E; Thu, 31 May 2012 13:39:48 -0400 (EDT) Message-ID: <4FC7ACE4.2010301@viagenie.ca> Date: Thu, 31 May 2012 13:39:48 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Wesley Eddy References: <4FC6F151.3080404@mti-systems.com> In-Reply-To: <4FC6F151.3080404@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-behave-lsn-requirements.all@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] AD review of LSN requirements draft 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, 31 May 2012 17:39:53 -0000 On 2012-05-31 00:19, Wesley Eddy wrote: > Hi, I've completed an AD review of the LSN requirements draft. > > I think it's generally in pretty good shape, but do have some > comments that we should at least talk about before going forward. > This could require a small update. I also understand from the > mailing list that Simon has a proposed reversal of one of the > previous changes, and I think he's totally correct. So, we > should get a revision anyways before moving on. > > Here are my comments: > > (1) it strongly seems like RFC 6264 should be mentioned here; > it would probably work in the 2nd paragraph of the Introduction > about providing IPv6 services alongside IPv4 CGN Added: One approach to CGN deployment is described in . > (2) it seems like it should be really clear in section 1 that > this document isn't considering multi-subscriber IPv6 NPT or > dual layers of IPv6 NPT as being a CGN, only multi-subscriber > IPv4 NAT and dual layers of IPv4 NAT Added: Note that the CGN mechanism described in this document only applies to IPv4. Any IPv6 address translation is out of scope. Also tweaked the definition of CGN in the terminology section. > (3) Note that the sub-requirements for individual NAT > behavior RFCs are labelled "REQ-1", "REQ-2", etc. > duplicatively with the higher-level REQ-1, REQ-2, etc. Already mentioned to me privately and fixed in my copy. > (4) Several of the requirements have "SHOULD" in them, > which makes them more of a recommendation than an > actual requirement (those are MUSTs!); if we want to > retain "SHOULD"s, then we probably need to suggest > why they aren't MUSTs by giving some cogent example > of a case where it would be acceptable not to implement > the feature. (this applies to the SHOULD NOTs as well) My intent as editor has always been to include justification for any SHOULD. e.g. Sending an ICMP error may be rate-limited for security reasons, which is why requirement B is a SHOULD, not a MUST. Proposal: I'll make a list of justification-less SHOULDs and submit it to the WG so that we can either turn them into MUSTs or add justification. > (5) Should there be a requirement to support use of > the prefix allocated via RFC 6598? I can't see how any networking equipment could not support it. > (6) I think it would be good to have an advisory > reference to the issues in: > http://tools.ietf.org/html/draft-donley-nat444-impacts-03 > and whether or not following the recommendations in this > document helps to avoid such issues. The RFC 6269 > reference already in the introduction is okay, but it > probably glosses over this topic too quickly. In addition to Dan's response, the draft-donley does not evaluate CGNs that have a PCP server, which our draft requires. I think the inclusion of PCP would affect the results significantly. > (7) I suspect that we should be more clear in the abstract > and introduction that this is not an IETF endorsement of > CGN or a real specification for CGN, but rather just a > minimal set of requirements that we believe need to be > followed for implementing CGNs on the Internet; CGNs are > still not something we have consensus on being desirable > for the Internet. I added this: "It is not an IETF endorsement of CGN or a real specification for CGN, but rather just a minimal set of requirements that will increase the likelihood of applications working across CGNs." But I believe it would be more appropriate to put such text in an IESG Note. 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 From dthaler@microsoft.com Thu May 31 16:11:06 2012 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 DE9B221F8636 for ; Thu, 31 May 2012 16:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.275 X-Spam-Level: X-Spam-Status: No, score=-105.275 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 2VIxPxv5Fdjy for ; Thu, 31 May 2012 16:11:06 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5B71721F8630 for ; Thu, 31 May 2012 16:11:06 -0700 (PDT) Received: from mail100-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 31 May 2012 23:10:36 +0000 Received: from mail100-tx2 (localhost [127.0.0.1]) by mail100-tx2-R.bigfish.com (Postfix) with ESMTP id 87D50E062F for ; Thu, 31 May 2012 23:10:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail100-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail100-tx2 (localhost.localdomain [127.0.0.1]) by mail100-tx2 (MessageSwitch) id 1338505834804615_12232; Thu, 31 May 2012 23:10:34 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.238]) by mail100-tx2.bigfish.com (Postfix) with ESMTP id B7B7B460046 for ; Thu, 31 May 2012 23:10:34 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 31 May 2012 23:10:34 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 31 May 2012 23:10:55 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 31 May 2012 16:10:54 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.48]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Thu, 31 May 2012 16:10:54 -0700 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: May 17 interim meeting proceedings available Thread-Index: Ac0/gnfo8043p1z8Qt2ZCqiVTvxyOwAABwfg Date: Thu, 31 May 2012 23:10:53 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B61856F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [BEHAVE] May 17 interim meeting proceedings available 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, 31 May 2012 23:11:07 -0000 The minutes and slides from our May 17 webex interim are all posted at http= ://www.ietf.org/proceedings/interim/2012/05/17/behave/proceedings.html Let me know if there are any corrections to the minutes. -Dave From dwing@cisco.com Thu May 31 19:09:06 2012 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 3ABAA11E80E0; Thu, 31 May 2012 19:09:06 -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 7r4XlkZdiTsE; Thu, 31 May 2012 19:09:05 -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 5578211E80DC; Thu, 31 May 2012 19:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=324; q=dns/txt; s=iport; t=1338516537; x=1339726137; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=OPQrJxBJQgaXIFPMXuFP3ivjBlezpz/ttfM8v6nF4Vo=; b=FU+HSBhNJ8YqnH1f5cR7s+1ND5KjiwLyOCGXr/aBEwRiDJPNImXA7b94 wSB4lH7A3s6BIc3KQ6vZKwmM+FdKxugR7ViF1CxyePy/Hbilwn1/zTk9p tE7SzOvvXGxJOC6iESnDKy6EaVHRzh85cJ2yUwt84i16vJxCtO8sJDFFM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4KAK8jyE+rRDoJ/2dsb2JhbABEpSiNVwQCgSSBB4IfCAoBFxAuEQ0FGFAjChIBBAESCxeHaAyZA59WkQYDiECEfIhsjH+BZoMAgT8 X-IronPort-AV: E=Sophos;i="4.75,695,1330905600"; d="scan'208";a="44108514" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 01 Jun 2012 02:08:57 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5128uO8015495; Fri, 1 Jun 2012 02:08:56 GMT From: "Dan Wing" To: , Date: Thu, 31 May 2012 19:08:56 -0700 Message-ID: <08c201cd3f9b$805fdfa0$811f9ee0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0/m4ALdEmLr75+Sqe43zBBxr60zQ== Content-Language: en-us Cc: behave-ads@tools.ietf.org, behave-chairs@tools.ietf.org Subject: [BEHAVE] BEHAVE interim conference call, June 21 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, 01 Jun 2012 02:09:06 -0000 BEHAVE will have a conference call interim meeting at 7am PDT on Thursday, June 21. Details on the conference call will be posted at http://trac.tools.ietf.org/wg/behave/trac/wiki. We expect the meeting to last 1.5 - 2 hours. If you want to be on the agenda, please send email to behave-chairs@tools.ietf.org. -d From dwing@cisco.com Thu May 31 19:14:35 2012 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 2781311E80E3 for ; Thu, 31 May 2012 19:14:35 -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 k820CqGow1WD for ; Thu, 31 May 2012 19:14:34 -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 ABD7411E8072 for ; Thu, 31 May 2012 19:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=70; q=dns/txt; s=iport; t=1338516874; x=1339726474; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=u4mRef32jmhsdpPFviX24W9bpqJQIArESlVkv6aNYog=; b=nCcXJfBtwEYATRXeEH8CDuBc0SA4EEDMj0wFMejCzi4QMFKvbP7BxPOl E8EjsJ8+/3AqDZ149i4TZ8huP5dfGP1S3bCz/uLGmbnB9oOp9hVx0t5tg wMjN8FCAgrWWDDjXPlQqns3OMpk5/T9piUQ3Y/MFBKWeYjc2FdQxUFmdd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8KAAklyE+rRDoG/2dsb2JhbABEpSiNVQEDAQOBJIEHghQLCAoBFxBMBRhQIxwBBB4XhScHAYIjFpdtgSifVowEgWyDFgOIQIR8lWuBZoMA X-IronPort-AV: E=Sophos;i="4.75,695,1330905600"; d="scan'208";a="47222893" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 01 Jun 2012 02:14:34 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q512EYZ0008526 for ; Fri, 1 Jun 2012 02:14:34 GMT From: "Dan Wing" To: Date: Thu, 31 May 2012 19:14:33 -0700 Message-ID: <08c301cd3f9c$495a11a0$dc0e34e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0/nEkL6V1Bu4E9TIugejRnCweIqQ== Content-Language: en-us Subject: [BEHAVE] BEHAVE at IETF84 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, 01 Jun 2012 02:14:35 -0000 We requested a one hour slot for BEHAVE at IETF84 (Vancouver). -d