From tim@haitabu.net Wed Jan 9 02:29:41 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5930721F8678 for ; Wed, 9 Jan 2013 02:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMnvSgTz9-fn for ; Wed, 9 Jan 2013 02:29:40 -0800 (PST) Received: from samstag.members.selfnet.de (samstag.members.selfnet.de [141.31.176.199]) by ietfa.amsl.com (Postfix) with ESMTP id 7210921F848B for ; Wed, 9 Jan 2013 02:29:40 -0800 (PST) Received: from chekov.ws.belwue.de (chekov.ws.belwue.de [IPv6:2001:7c0:0:f00::9d]) by samstag.members.selfnet.de (Postfix) with ESMTPSA id 72A4421C06E for ; Wed, 9 Jan 2013 11:29:17 +0100 (CET) Message-ID: <50ED467D.3090108@haitabu.net> Date: Wed, 09 Jan 2013 11:29:17 +0100 From: Tim Kleefass User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "opsec@ietf.org" References: <506C5954.9050807@haitabu.net> In-Reply-To: <506C5954.9050807@haitabu.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSEC] Comments on draft-jdurand-bgp-security-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 10:29:41 -0000 On 03.10.2012 5:27 PM, Tim Kleefass wrote: > * About route flap dampening > > """ > 6. BGP route flap dampening > > BGP route flap dampening mechanism makes it possible to give > penalties to routes each time they change in the BGP routing table. > Initially this mechanism was created to protect the entire internet > from multiple events impacting a single network. RIPE community now > recommends not using BGP route flap dampening [20]. Author of this > document proposes to follow the proposal of the RIPE community. > """ > > On that topic there are some "updates" at the RIPE-64: > > Randy Bush, Route Flap Damping Considered Usable @ RIPE-64 > https://ripe64.ripe.net/presentations/136-120418.ripe-rfd.pdf > https://ripe64.ripe.net/archives/video/80 > > [routing-wg] Route flap damping considered usable > http://www.ripe.net/ripe/mail/archives/routing-wg/2012-July/002163.html > > So maybe the recommendation of the RIPE community will change in the > future... RIPE published a few days ago an update on this. "RIPE Routing Working Group Recommendations on Route Flap Damping" https://www.ripe.net/ripe/docs/ripe-580/ Cheers, Tim From warren@kumari.net Thu Jan 10 08:28:17 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7121F8931 for ; Thu, 10 Jan 2013 08:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvCoLPyR2Nk5 for ; Thu, 10 Jan 2013 08:28:12 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D58421F892F for ; Thu, 10 Jan 2013 08:28:11 -0800 (PST) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BF4B71B40805; Thu, 10 Jan 2013 11:28:10 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jan 2013 11:28:09 -0500 Message-Id: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> To: opsec@ietf.org, opsec chairs Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: Warren Kumari Subject: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 16:28:17 -0000 Hello OpSec! This starts a working group last call for = draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 -- "Security = Implications of IPv6 on IPv4 Networks" The draft is available at = http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets= -02 and = https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv= 4-nets/=20 Please review this draft to see if you think it is ready for = publication. Send comments to the list. =20 The WGLC will end on 25th January 2013. --Warren, speaking as OpSec WG co-chair --=20 I had no shoes and wept. Then I met a man who had no feet. So I said, = "Hey man, got any shoes you're not using?"=20 From fgont@si6networks.com Fri Jan 11 08:55:41 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F288421F8A08 for ; Fri, 11 Jan 2013 08:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6wax435jvoJ for ; Fri, 11 Jan 2013 08:55:34 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 35DD721F89AA for ; Fri, 11 Jan 2013 08:55:27 -0800 (PST) Received: from [186.134.32.129] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Ttht2-0007ze-4L; Fri, 11 Jan 2013 17:55:21 +0100 Message-ID: <50F043F4.6010508@si6networks.com> Date: Fri, 11 Jan 2013 13:55:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "'opsec@ietf.org'" References: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> In-Reply-To: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OPSEC] IPv6 smurf amplifiers (draft-gont-6man-ipv6-smurf-amplifier-01.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:55:42 -0000 Folks, We have published a revision of our I-D entitled "Security Implications of IPv6 options of Type 10xxxxxx", about IPv6 smurf amplifiers. The I-D is available at: . The I-D is targeted at the 6man wg, but I thought it might be of interest to v6ops folks, too. Any comments will be very appreciated. Thanks! Best regards, Fernando -------- Original Message -------- From: - Fri Jan 11 13:40:47 2013 From: internet-drafts@ietf.org To: fgont@si6networks.com Cc: liushucheng@huawei.com Subject: New Version Notification for draft-gont-6man-ipv6-smurf-amplifier-01.txt Message-ID: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 08:40:12 -0800 A new version of I-D, draft-gont-6man-ipv6-smurf-amplifier-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-6man-ipv6-smurf-amplifier Revision: 01 Title: Security Implications of IPv6 options of Type 10xxxxxx Creation date: 2013-01-11 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-smurf-amplifier-01.txt Status: http://datatracker.ietf.org/doc/draft-gont-6man-ipv6-smurf-amplifier Htmlized: http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-gont-6man-ipv6-smurf-amplifier-01 Abstract: When an IPv6 node processing an IPv6 packet does not support an IPv6 option whose two-highest-order bits of the Option Type are '10', it is required to respond with an ICMPv6 Parameter Problem error message, even if the Destination Address of the packet was a multicast address. This feature provides an amplification vector, opening the door to an IPv6 version of the 'Smurf' Denial-of-Service (DoS) attack found in IPv4 networks. This document discusses the security implications of the aforementioned options, and formally updates RFC 2460 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector. The IETF Secretariat From fgont@si6networks.com Fri Jan 11 16:24:06 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BD121F8919 for ; Fri, 11 Jan 2013 16:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQo+NvxM9tgt for ; Fri, 11 Jan 2013 16:24:06 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id C669A21F8888 for ; Fri, 11 Jan 2013 16:24:05 -0800 (PST) Received: from [186.134.32.129] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TtosX-00030a-Li; Sat, 12 Jan 2013 01:23:18 +0100 Message-ID: <50F0ACF0.5080809@si6networks.com> Date: Fri, 11 Jan 2013 21:23:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "'opsec@ietf.org'" References: <20130111215008.22931.81394.idtracker@ietfa.amsl.com> In-Reply-To: <20130111215008.22931.81394.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: <20130111215008.22931.81394.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OPSEC] IPv6 Neighbor Discovery Security (draft-gont-opsec-ipv6-nd-security-01.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 00:24:06 -0000 Folks, We have published a revision of our IETF I-D entitled "Security Assessment of Neighbor Discovery (ND) for IPv6" (draft-gont-opsec-ipv6-nd-security-01) -- which is the first one that we are "socializing". The I-D is available at: . This document follows the same spirit as RFC6274 (produced by opsec a couple of years ago) and is meant to improve the resiliency of IPv6 Neighbor Discovery implementations -- this time in a more timely fashion. ;-) Any comments will be welcome! P.S.: There are some comments that we received since version -00, but have not yet addressed (they are on my TODO list). Thanks! Best regards, Fernando -------- Original Message -------- From: internet-drafts@ietf.org To: fgont@si6networks.com Subject: New Version Notification for draft-gont-opsec-ipv6-nd-security-01.txt Date: Fri, 11 Jan 2013 13:50:08 -0800 A new version of I-D, draft-gont-opsec-ipv6-nd-security-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-opsec-ipv6-nd-security Revision: 01 Title: Security Assessment of Neighbor Discovery (ND) for IPv6 Creation date: 2013-01-11 WG ID: Individual Submission Number of pages: 62 URL: http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-nd-security-01.txt Status: http://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-nd-security Htmlized: http://tools.ietf.org/html/draft-gont-opsec-ipv6-nd-security-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-nd-security-01 Abstract: Neighbor Discovery is one of the core protocols of the IPv6 suite, and provides in IPv6 similar functions to those provided in the IPv4 protocol suite by the Address Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP). Its increased flexibility implies a somewhat increased complexity, which has resulted in a number of bugs and vulnerabilities found in popular implementations. This document provides guidance in the implementation of Neighbor Discovery, and documents issues that have affected popular implementations, in the hopes that the same issues do not repeat in other implementations. The IETF Secretariat From wesley.george@twcable.com Wed Jan 16 12:25:09 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D15C11E80A2 for ; Wed, 16 Jan 2013 12:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=0.984, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KegdTybDSM8Z for ; Wed, 16 Jan 2013 12:25:08 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9653F21F8812 for ; Wed, 16 Jan 2013 12:25:04 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,480,1355115600"; d="scan'208";a="12846638" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Jan 2013 15:24:39 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 16 Jan 2013 15:25:04 -0500 From: "George, Wes" To: Warren Kumari , "opsec@ietf.org" , opsec chairs Date: Wed, 16 Jan 2013 15:25:03 -0500 Thread-Topic: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Index: Ac3vT4KL6YoJsxtcRjisFvi0i/XnbQE1/fbA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033C09B541@PRVPEXVS15.corp.twcable.com> References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> In-Reply-To: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> 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 Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 20:25:09 -0000 All of my concerns with this document have been addressed, and I think it's= ready to go. Thanks, Wes George > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf > Of Warren Kumari > Sent: Thursday, January 10, 2013 11:28 AM > To: opsec@ietf.org; opsec chairs > Cc: Warren Kumari > Subject: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4- > nets-02 > > Hello OpSec! > > This starts a working group last call for draft-ietf-opsec-ipv6- > implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 > Networks" > > The draft is available at http://tools.ietf.org/html/draft-ietf-opsec- > ipv6-implications-on-ipv4-nets-02 and > https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on- > ipv4-nets/ > > Please review this draft to see if you think it is ready for > publication. Send comments to the list. > > The WGLC will end on 25th January 2013. > > --Warren, speaking as OpSec WG co-chair > > > -- > I had no shoes and wept. Then I met a man who had no feet. So I said, > "Hey man, got any shoes you're not using?" > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec 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 gvandeve@cisco.com Thu Jan 17 04:33:19 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6921F863A for ; Thu, 17 Jan 2013 04:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.599 X-Spam-Level: X-Spam-Status: No, score=-14.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frUAL1R4HaMm for ; Thu, 17 Jan 2013 04:33:13 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0881C21F8742 for ; Thu, 17 Jan 2013 04:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7086; q=dns/txt; s=iport; t=1358425993; x=1359635593; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JQzcObpI3jawnp9B5bnRmH6+5CLvgmOKoHMSLblMGt4=; b=NzX3jUqFVXtWtc9jYCS0O58UsLHJVlvCq9x7+QIz3O0xl4ziqEGK/EPM MKVjbVwpSGEbXICWD4Fz4zlz9aYzltY8FmymEEhjvGjeiNIOAiqV47MAd yqlHGazeMjv90bnUNjLQBiHVLywlDb+ZjWWHLVSUOB7YfFFkGimOP5Fgg 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAMLu91CtJXG8/2dsb2JhbABEAYZEtl9/FnOCHgEBAQQBAQEgESEZBxAEAgEIEQMBAQEDAgYdAwICAiULFAEGAQEFAwIEEwgBiBAMqDiRJoEji10KEIMLMmEDklmET4oehQ+CdYFmBAUXHg X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="163796844" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jan 2013 12:33:12 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0HCXCvM023832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Jan 2013 12:33:12 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.96]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 06:33:12 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: IETF 86 - Meeting Information Thread-Index: AQHN8/khD7IzPWnxNU2pY2Yvm/oGfZhNdYfQ Date: Thu, 17 Jan 2013 12:33:11 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C875B03@xmb-aln-x12.cisco.com> References: <20130116145125.29768.56592.idtracker@ietfa.amsl.com> In-Reply-To: <20130116145125.29768.56592.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.89.215] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OPSEC] FW: IETF 86 - Meeting Information X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 12:33:19 -0000 Rm9yIHRob3NlIG5vdCBvbiB0aGUgSUVURiBBbm5vdW5jZW1lbnQgZW1haWwgYWxpYXMuDQoNCkcv DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB3Z2NoYWlycy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86d2djaGFpcnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElF VEYgU2VjcmV0YXJpYXQNClNlbnQ6IDE2IEphbnVhcnkgMjAxMyAxNTo1MQ0KVG86IElFVEYgQW5u b3VuY2VtZW50IExpc3QNCkNjOiB3Z2NoYWlyc0BpZXRmLm9yZzsgaXJzZ0BpcnRmLm9yZw0KU3Vi amVjdDogSUVURiA4NiAtIE1lZXRpbmcgSW5mb3JtYXRpb24NCg0KODZ0aCBJRVRGIE1lZXRpbmcN Ck9ybGFuZG8sIEZMLCBVU0ENCk1hcmNoIDEwLTE1LCAyMDEzDQpIb3N0OiBDb21jYXN0IGFuZCBO QkNVbml2ZXJzYWwNCg0KTWVldGluZyB2ZW51ZTogIENhcmliZSBSb3lhbGUgaHR0cDovL3d3dy5j YXJpYmVyb3lhbGUuY29tDQoNClJlZ2lzdGVyIG9ubGluZSBhdDogaHR0cDovL3d3dy5pZXRmLm9y Zy9tZWV0aW5ncy84Ni8NCg0KMS4gIFJlZ2lzdHJhdGlvbg0KMi4gIFNvY2lhbCBFdmVudA0KMy4g IFZpc2FzICYgTGV0dGVycyBvZiBJbnZpdGF0aW9uDQo0LiAgQWNjb21tb2RhdGlvbnMNCjUuICBD b21wYW5pb24gUHJvZ3JhbQ0KNi4gIElFVEYgYW5kIElFRUUgYmFjay10by1iYWNrIE1lZXRpbmdz DQoNCjEuIFJlZ2lzdHJhdGlvbg0KICAgQS4gRWFybHktQmlyZCBSZWdpc3RyYXRpb24gLSBVU0Qg NjUwLjAwIFBheSBieSBGcmlkYXksIDEgTWFyY2ggMjAxMyBVVEMgMjQ6MDANCiAgIEIuIEFmdGVy IEVhcmx5LUJpcmQgY3V0b2ZmIC0gVVNEIDgwMC4wMA0KICAgQy4gRnVsbC10aW1lIFN0dWRlbnQg UmVnaXN0cmF0aW9ucyAtIFVTRCAxNTAuMDAgKHdpdGggcHJvcGVyIElEKQ0KICAgRC4gT25lIERh eSBQYXNzIFJlZ2lzdHJhdGlvbiAtIFVTRCAzNTAuMDANCiAgIEUuIFJlZ2lzdHJhdGlvbiBDYW5j ZWxsYXRpb24gICANCiAgICAgICAgICAgICAgIEN1dC1vZmYgZm9yIHJlZ2lzdHJhdGlvbiBjYW5j ZWxsYXRpb24gaXMgTW9uZGF5LA0KICAgICAgICAgICAgICAgNCBNYXJjaCAyMDEzIGF0IFVUQyAy NDowMC4NCiAgICAgICAgICAgICAgIENhbmNlbGxhdGlvbnMgYXJlIHN1YmplY3QgdG8gYSAxMCUg KHRlbiBwZXJjZW50KQ0KICAgICAgICAgICAgICAgY2FuY2VsbGF0aW9uIGZlZSBpZiByZXF1ZXN0 ZWQgYnkgdGhhdCBkYXRlIGFuZCB0aW1lLg0KICAgRi4gT25saW5lIFJlZ2lzdHJhdGlvbiBhbmQg UGF5bWVudCBlbmRzIEZyaWRheSwgOCBNYXJjaCAyMDEzLCAxNzAwIGxvY2FsIE9ybGFuZG8gdGlt ZS4NCiAgIEcuIE9uLXNpdGUgUmVnaXN0cmF0aW9uIHN0YXJ0aW5nIFN1bmRheSwgMTAgTWFyY2gg MjAxMyBhdCAxMTAwIGxvY2FsIE9ybGFuZG8gdGltZS4NCg0KMi4gU29jaWFsIEV2ZW50DQogICBJ RVRGODYncyBzb2NpYWwgZXZlbnQgc3BvbnNvcmVkIGJ5IENvbWNhc3QgYW5kIE5CQ1VuaXZlcnNh bCB3aWxsIGJlIGF0IFVuaXZlcnNhbCBTdHVkaW9zIE9ybGFuZG8ncyBXaXphcmRpbmcgV29ybGQg b2YgSGFycnkgUG90dGVyIG9uIFR1ZXNkYXkgZXZlbmluZy4gDQogICBUaGUgV2l6YXJkaW5nIFdv cmxkIG9mIEhhcnJ5IFBvdHRlciB3aWxsIGJlIG9wZW4gZXhjbHVzaXZlbHkgZm9yIHRoZSBJRVRG ODYgc29jaWFsLiBBdHRlbmRlZXMgd2lsbCBiZSB0cmFuc3BvcnRlZCBmcm9tIHRoZSBDYXJpYmUg Um95YWwgdG8gVW5pdmVyc2FsIFN0dWRpb3Mgd2hlcmUgdGhleSB3aWxsIGVuam95IHRoZSBtYW55 IGF0dHJhY3Rpb25zIG9mIEhhcnJ5IFBvdHRlciBpbmNsdWRpbmcgdGhlIHRocmlsbGluZyBIYXJy eSBQb3R0ZXIgYW5kIHRoZSBGb3JiaWRkZW4gSm91cm5leSByaWRlLiAgIA0KICAgR3Vlc3Qgd2ls bCBlbmpveSBhIGJ1ZmZldCBkaW5uZXIsIHNvZnQgZHJpbmtzLCB3aW5lLCBiZWVyIGFuZCBIYXJy eSBQb3R0ZXIncyBvd24gQnV0dGVyYmVlciBzZXJ2ZWQgaW4gSG9nc21lYWRlIFZpbGxhZ2UgdGhy b3VnaCBvdXQgdGhlIGV2ZW5pbmcuICANCiAgIFJldHVybiB0cmFuc3BvcnRhdGlvbiB3aWxsIGJl IHByb3ZpZGVkIHRvIHRoZSBDYXJpYmUgUm95YWxlIHRocm91Z2hvdXQgdGhlIGV2ZW5pbmcuDQog ICBUaGUgY29zdCBmb3IgdGhlIGV2ZW50IGlzICQzMCBwZXIgcGVyc29uIGFuZCBkdWUgdG8gdGhl IGV4cGVjdGVkIGhpZ2ggZGVtYW5kLCByZWdpc3RyYXRpb24gaXMgbGltaXRlZCB0byB0d28gdGlj a2V0cyBhbiBhdHRlbmRlZS4NCg0KMy4gVmlzYXMgJiBMZXR0ZXJzIG9mIEludml0YXRpb246DQog ICBJbmZvcm1hdGlvbiBvbiBWaXNpdGluZyB0aGUgVW5pdGVkIFN0YXRlcywgcGxlYXNlIHZpc2l0 Og0KaHR0cDovL3RyYXZlbC5zdGF0ZS5nb3YvdmlzYS8NCg0KICAgQWZ0ZXIgeW91IGNvbXBsZXRl IHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcywgeW91IGNhbiByZXF1ZXN0IGFuIGVsZWN0cm9uaWMg SUVURiBsZXR0ZXIgb2YgaW52aXRhdGlvbiBhcyB3ZWxsLiBUaGUgcmVnaXN0cmF0aW9uIHN5c3Rl bSBhbHNvIGFsbG93cyBmb3IgeW91IHRvIHJlcXVlc3QgYSBoYXJkIGNvcHkgSUVURiBsZXR0ZXIg b2YgaW52aXRhdGlvbi4gWW91IG1heSBhbHNvIHJlcXVlc3Qgb25lIGF0IGEgbGF0ZXIgdGltZSBi eSBmb2xsb3dpbmcgdGhlIGxpbmsgcHJvdmlkZWQgaW4gdGhlIGNvbmZpcm1hdGlvbiBlbWFpbC4N Cg0KICAgUGxlYXNlIG5vdGUgdGhhdCB0aGUgSUVURiBMZXR0ZXIgb2YgSW52aXRhdGlvbiBtYXkg bm90IGJlIHN1ZmZpY2llbnQgZm9yIG9idGFpbmluZyBhIHZpc2EgdG8gZW50ZXIgdGhlIFVuaXRl ZCBTdGF0ZXMuDQoNCjQuICBBY2NvbW1vZGF0aW9ucw0KICAgVGhlIElFVEYgaXMgaG9sZGluZyBh IGJsb2NrIG9mIGd1ZXN0IHJvb21zIGF0IHRoZSBDYXJpYmUgUm95YWxlLCB0aGUgbWVldGluZyB2 ZW51ZS4NCiAgIFJvb20gUmF0ZXMgaW5jbHVkZSBpbiByb29tIGhpZ2gtc3BlZWQgSW50ZXJuZXQg YWNjZXNzLiBTYWxlcy9yb29tIHRheCAoYXBwbGljYWJsZSB0YXhlcyBhcmUgc3ViamVjdCB0byBj aGFuZ2UpIGFyZSBleGNsdWRlZCBpbiB0aGUgYWJvdmUgcHJpY2VzLCBjdXJyZW50bHkgMTIuNSUu IFJvb20gcmF0ZXMgRE8gTk9UIGluY2x1ZGUgZGFpbHkgYnJlYWtmYXN0Lg0KDQogICBSZXNlcnZh dGlvbnMgQ3V0IG9mZiBEYXRlOiAxMyBGZWJydWFyeSAyMDEzIA0KDQpGb3IgYWRkaXRpb25hbCBp bmZvcm1hdGlvbiBvbiByYXRlcyBhbmQgcG9saWNpZXMsIHBsZWFzZSB2aXNpdDogaHR0cDovL3d3 dy5pZXRmLm9yZy9tZWV0aW5nLzg2L2hvdGVsLmh0bWwNCg0KNS4gIENvbXBhbmlvbiBQcm9ncmFt DQogIElmIHlvdSBhcmUgdHJhdmVsaW5nIHdpdGggYSBmcmllbmQgb3IgZmFtaWx5IG1lbWJlciBv dmVyIDE4IHllYXJzIG9mIGFnZSB5b3UgY2FuIHJlZ2lzdGVyIHRoZW0gZm9yIHRoZSBJRVRGIENv bXBhbmlvbiBQcm9ncmFtIGZvciBvbmx5IFVTRCAyNS4wMA0KDQogIEJlbmVmaXRzIGluY2x1ZGU6 DQogIC0gQSBzcGVjaWFsIHdlbGNvbWUgcmVjZXB0aW9uIGZvciBjb21wYW5pb25zIGZyb20gMTYz MC0xNzMwIG9uIFN1bmRheSwgMTAgTWFyY2gNCiAgLSBBYmlsaXR5IHRvIGF0dGVuZCB0aGUgb2Zm aWNpYWwgV2VsY29tZSBSZWNlcHRpb24gZnJvbSAxNzAwLTE5MDAgb24gU3VuZGF5LCAxMCBNYXJj aA0KICAtIEEgZGlzdGluY3RpdmUgbWVldGluZyBiYWRnZSB0aGF0IGdyYW50cyBhY2Nlc3MgdG8g dGhlIHZlbnVlIChub3QgdG8gYmUgdXNlZCB0byBhdHRlbmQgd29ya2luZyBzZXNzaW9ucykNCiAg LSBQYXJ0aWNpcGF0aW9uIGluIGEgc2VwYXJhdGUgY29tcGFuaW9uIGVtYWlsIGxpc3QgaWYgeW91 IGNob29zZSB0byBoZWxwIGNvbW11bmljYXRlIGFuZCBtYWtlIHBsYW5zIHdpdGggb3RoZXIgSUVU RiBDb21wYW5pb25zLg0KDQogIFlvdSBjYW4gcmVnaXN0ZXIgeW91ciBjb21wYW5pb24gYXQgYW55 IHRpbWUgdmlhIHRoZSBJRVRGIHdlYnNpdGUgb3Igb25zaXRlIGF0IHRoZSBtZWV0aW5nLg0KDQog IFRvIGpvaW4gdGhlIDg2IGNvbXBhbmlvbnMgbWFpbGluZyBsaXN0IG9ubHkgc2VlOg0KICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzg2Y29tcGFuaW9ucw0KDQo2LiAgSUVU RiBhbmQgSUVFRSBiYWNrLXRvLWJhY2sgTWVldGluZ3MNCiAgVGhlIElFRUUgODAyIEV4ZWN1dGl2 ZSBDb21taXR0ZWUgYW5kIHRoZSBJRVRGLCBJRVNHIGFuZCBJQU9DIGFyZSBwbGVhc2VkIHRvIGNv bmZpcm0gdGhlIE1hcmNoIDIwMTMgSUVFRSA4MDIgUGxlbmFyeSBTZXNzaW9uIGFuZCBJRVRGODYg d2lsbCBib3RoIHRha2UgcGxhY2UgYXQgdGhlIENhcmliZSBSb3lhbGUgUmVzb3J0ICYgQ29udmVu dGlvbiBDZW50ZXIgaW4gT3JsYW5kbywgRmxvcmlkYSwgVVNBIGR1cmluZyB0aGUgbW9udGggb2Yg TWFyY2ggMjAxMy4gSUVURjg2IHdpbGwgdGFrZSBwbGFjZSBNYXJjaCAxMC0xNSwgMjAxMyBhbmQg dGhlIElFRUUgODAyIFBsZW5hcnkgU2Vzc2lvbiB3aWxsIG9jY3VyIE1hcmNoIDE3LTIyLCAyMDEz Lg0KICBSZWdpc3RyYXRpb24gZm9yIHRoZSBNYXJjaCAyMDEzIElFRUUgODAyIFBsZW5hcnkgU2Vz c2lvbiBhbmQgSUVURjg2IGFyZSBub3cgYXZhaWxhYmxlIGFuZCB0aGUgQ2FyaWJlIFJveWFsZSBo YXMgZXh0ZW5kZWQgZ3JlYXQgcmF0ZXMgZm9yIHNlc3Npb24gYXR0ZW5kZWVzIG92ZXIgdGhlIGRh dGVzIG9mIGJvdGggc2Vzc2lvbnMuIFdlIGVuY291cmFnZSBJRUVFIDgwMiBhbmQgSUVURiBwYXJ0 aWNpcGFudHMgdG8gY29uc2lkZXIgcmVnaXN0ZXJpbmcgZm9yIGJvdGggZXZlbnRzIGluIG9yZGVy IHRvIHRha2UgYWR2YW50YWdlIG9mIHRoaXMgZmluZSBvcHBvcnR1bml0eSB0byBsZWFybiBtb3Jl IGFib3V0IGVhY2ggZ3JvdXAuDQogICBGb3IgUmVnaXN0cmF0aW9uLCBIb3RlbCBSZXNlcnZhdGlv bnMgYW5kIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNwZWNpZmljIGV2ZW50cyBwbGVhc2Ug dmlzaXQgdGhlIGV2ZW50IHdlYnNpdGVzIGZvciB0aGUgTWFyY2ggMjAxMyBJRUVFIDgwMiBQbGVu YXJ5IFNlc3Npb24sIGh0dHBzOi8vODAyd29ybGQub3JnL2FwcHMvc2Vzc2lvbi83OS9yZWdpc3Rl cjEvcmVnaXN0ZXIgYW5kIHRoZSBJRVRGODYsIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZ3Mv ODYvLg0KDQpPbmx5IDUyIGRheXMgdW50aWwgdGhlIE9ybGFuZG8gSUVURiENCg== From internet-drafts@ietf.org Fri Jan 18 06:48:36 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA3921F8899; Fri, 18 Jan 2013 06:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72B71tlOOY2F; Fri, 18 Jan 2013 06:48:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB9D21F8619; Fri, 18 Jan 2013 06:48:35 -0800 (PST) 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.37 Message-ID: <20130118144835.18337.67362.idtracker@ietfa.amsl.com> Date: Fri, 18 Jan 2013 06:48:35 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 14:48:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : BGP operations and security Author(s) : Jerome Durand Ivan Pepelnjak Gert Doering Filename : draft-ietf-opsec-bgp-security-00.txt Pages : 24 Date : 2013-01-18 Abstract: BGP (Border Gateway Protocol) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it's important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself (like TTL, MD5, control plane filtering) and to better control the flow of routing information, using prefix filtering and automatization of prefix filters, max-prefix filtering, AS path filtering, route flap dampening and BGP community scrubbing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From radarbha@cisco.com Sun Jan 20 10:15:09 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6C021F8600 for ; Sun, 20 Jan 2013 10:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGGsFlSxysUS for ; Sun, 20 Jan 2013 10:15:08 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0BE21F8611 for ; Sun, 20 Jan 2013 10:15:08 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0KIF65N020957; Sun, 20 Jan 2013 13:15:07 -0500 (EST) Received: from rtp-radarbha-8711.cisco.com (rtp-vpn4-911.cisco.com [10.82.211.143]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0KIF3eH012940; Sun, 20 Jan 2013 13:15:03 -0500 (EST) Message-ID: <50FC3427.7060208@cisco.com> Date: Sun, 20 Jan 2013 13:15:03 -0500 From: Rama Darbha User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: opsec@ietf.org, opsec-chairs@tools.ietf.org References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <2671C6CDFBB59E47B64C10B3E0BD5923033C09B541@PRVPEXVS15.corp.twcable.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010201000106050800080508" Subject: Re: [OPSEC] Fwd: WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 18:15:09 -0000 This is a multi-part message in MIME format. --------------010201000106050800080508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I concur with Wes. After you've put in the concerns he raised, this document looks good to publish. - Rama > ---------- Forwarded message ---------- > From: *George, Wes* > > Date: Wed, Jan 16, 2013 at 3:25 PM > Subject: Re: [OPSEC] WGLC on > draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 > To: Warren Kumari >, > "opsec@ietf.org " >, opsec chairs > > > > All of my concerns with this document have been addressed, and I think > it's ready to go. > > Thanks, > > Wes George > > > -----Original Message----- > > From: opsec-bounces@ietf.org > [mailto:opsec-bounces@ietf.org ] On Behalf > > Of Warren Kumari > > Sent: Thursday, January 10, 2013 11:28 AM > > To: opsec@ietf.org ; opsec chairs > > Cc: Warren Kumari > > Subject: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4- > > nets-02 > > > > Hello OpSec! > > > > This starts a working group last call for draft-ietf-opsec-ipv6- > > implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 > > Networks" > > > > The draft is available at http://tools.ietf.org/html/draft-ietf-opsec- > > ipv6-implications-on-ipv4-nets-02 and > > https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on- > > ipv4-nets/ > > > > Please review this draft to see if you think it is ready for > > publication. Send comments to the list. > > > > The WGLC will end on 25th January 2013. > > > > --Warren, speaking as OpSec WG co-chair > > > > > > -- > > I had no shoes and wept. Then I met a man who had no feet. So I said, > > "Hey man, got any shoes you're not using?" > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use 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 dissemination, distribution, copying, or > action taken in relation to the contents of and attachments to this > E-mail is strictly prohibited and may be unlawful. If you have > received this E-mail in error, please notify the sender immediately > and permanently delete the original and any copy of this E-mail and > any printout. > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- Rama Darbha, CCIE#28006 919-574-5071 radarbha@cisco.com Cisco TAC - Security Solutions RTP, NC, USA Hours: 8h30 - 17h00 (EST) http://www.cisco.com/tac/ --------------010201000106050800080508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I concur with Wes. After you've put in the concerns he raised, this document looks good to publish.

- Rama
---------- Forwarded message ----------
From: George, Wes <wesley.george@twcable.com>
Date: Wed, Jan 16, 2013 at 3:25 PM
Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02
To: Warren Kumari <warren@kumari.net>, "opsec@ietf.org" <opsec@ietf.org>, opsec chairs <opsec-chairs@tools.ietf.org>


All of my concerns with this document have been addressed, and I think it's ready to go.

Thanks,

Wes George

> -----Original Message-----
> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf
> Of Warren Kumari
> Sent: Thursday, January 10, 2013 11:28 AM
> To: opsec@ietf.org; opsec chairs
> Cc: Warren Kumari
> Subject: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-
> nets-02
>
> Hello OpSec!
>
> This starts a working group last call for draft-ietf-opsec-ipv6-
> implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4
> Networks"
>
> The draft is available at http://tools.ietf.org/html/draft-ietf-opsec-
> ipv6-implications-on-ipv4-nets-02 and
> https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-
> ipv4-nets/
>
> Please review this draft to see if you think it is ready for
> publication. Send comments to the list.
>
> The WGLC will end on 25th January 2013.
>
> --Warren, speaking as OpSec WG co-chair
>
>
> --
> I had no shoes and wept.  Then I met a man who had no feet.  So I said,
> "Hey man, got any shoes you're not using?"
>
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use 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 dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec



-- 
Rama Darbha, CCIE#28006
919-574-5071
radarbha@cisco.com
Cisco TAC - Security Solutions
RTP, NC, USA
Hours: 8h30 - 17h00 (EST)

http://www.cisco.com/tac/
--------------010201000106050800080508-- From warren@kumari.net Tue Jan 22 12:17:37 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE7121F859A for ; Tue, 22 Jan 2013 12:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77JkkDMrcQ+I for ; Tue, 22 Jan 2013 12:17:36 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61E521F8583 for ; Tue, 22 Jan 2013 12:17:36 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id CDAD01B409B0; Tue, 22 Jan 2013 15:17:26 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> Date: Tue, 22 Jan 2013 15:17:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> To: opsec@ietf.org, opsec chairs X-Mailer: Apple Mail (2.1499) Cc: Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:17:37 -0000 On Jan 10, 2013, at 11:28 AM, Warren Kumari wrote: > Hello OpSec! >=20 > This starts a working group last call for = draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 -- "Security = Implications of IPv6 on IPv4 Networks" >=20 > The draft is available at = http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets= -02 and = https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv= 4-nets/=20 >=20 > Please review this draft to see if you think it is ready for = publication. Send comments to the list. =20 >=20 > The WGLC will end on 25th January 2013. This is a reminder to please provide feedback on this draft -- so far I = do not think we have enough feedback to call consensus. Thanks to the folk we do have feedback from; Wes, Simon and Rama... W >=20 > --Warren, speaking as OpSec WG co-chair >=20 >=20 > --=20 > I had no shoes and wept. Then I met a man who had no feet. So I = said, "Hey man, got any shoes you're not using?"=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- The duke had a mind that ticked like a clock and, like a clock, it = regularly went cuckoo. -- (Terry Pratchett, Wyrd Sisters) From Donald.Smith@CenturyLink.com Tue Jan 22 15:12:50 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BCA21F85EE for ; Tue, 22 Jan 2013 15:12:47 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzMPgJC7tD5r for ; Tue, 22 Jan 2013 15:12:43 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1707921F8583 for ; Tue, 22 Jan 2013 15:12:37 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r0MNCZ1U004410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2013 17:12:36 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7A9511E0154; Tue, 22 Jan 2013 16:12:12 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 4AB7F1E014A; Tue, 22 Jan 2013 16:12:12 -0700 (MST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r0MNBnRO010027; Tue, 22 Jan 2013 17:11:49 -0600 (CST) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.qintra.com [151.119.128.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r0MNBm9m010024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jan 2013 17:11:49 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.02.0318.001; Tue, 22 Jan 2013 16:11:48 -0700 From: "Smith, Donald" To: Warren Kumari , "opsec@ietf.org" , opsec chairs Thread-Topic: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Index: AQHN+N2Ky5zPuhKv+UOZqxiq4JCq+JhV8xLB Date: Tue, 22 Jan 2013 23:11:48 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A2AA17E@PDDCWMBXEX503.ctl.intranet> References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net>, <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> In-Reply-To: <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:12:50 -0000 1.=20 No mention of v6 aware devices that haven't been configured for v6. One exa= mple is acls on most routers have to be duplicated for v6. Firewall rules t= oo. So it isn't just a "can it support issue" but also a is it configured t= o examine v6 or other tunneled traffic. Only in some exceptional cases (such as military operations networks) could this approach to mitigating the aforementioned security implications be thought of as a longer-term strategy. I am not sure that is true. Some enterprise may very well be able to use ju= st v4 for quite a while especially internally. They might have to offer ser= vices on v6 but via some hosting or other DMZ methods they may be able to k= eep their internal network v4 for many more years. 3.6=20 The corresponding addresses can be easily obtained from a UNIX host by issuing the command 'dig teredo.ipv6.microsoft.com a' (without quotes). dig isn't a "standard" unix tool. nslookup or host is in nearly all cases b= ut not all unix systems have dig installed by default. (nslookup is depreca= ted for host but still fairly common if not universal). How about nslookup since that is also on windows and other platforms? 4. This: This is likely to cause IPv6-capable hosts to attempt to reach an ever-increasing number of popular destinations via IPv6, even if this IPv6 connectivity is provided relies on a transition technology over an IPv4-only network. Should be this: This is likely to cause IPv6-capable hosts to attempt to reach an ever-increasing number of popular destinations via IPv6, even if this IPv6 connectivity as provided relies on a transition technology over an IPv4-only network. Shouldn't this be NXD instead of dropping the requests. That way the client= can see it is getting errors not just blackholeing the aaaa requests? For this reason, networks attempting to prevent IPv6 traffic from traversing their devices should consider configuring their local recursive DNS servers to ignore queries for AAAA DNS records, or even consider filtering AAAA records at the network ingress point to prevent end hosts from attempting their own DNS resolution. That could also be done on a forwarder right not just a local recursive dns= server? A firewall could signal the packet drop by means of an ICMPv6 error message (or TCP [RFC0793] RST segment if appropriate), such that the source node can e.g. quickly react as described in [RFC5461]. If there is no v6 connectivity I wouldn't expect icmpv6 to work and the que= ries will usually be udp so a tcp resest is not valid. I think therefore that NXD from dns server or icmpv4 from a middle box is = better. And I would change firewall to middle box since there are IPSes, UT= M devices, portals etc... that could be dropping the v6 queries. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] on behalf of Warren K= umari [warren@kumari.net] Sent: Tuesday, January 22, 2013 1:17 PM To: opsec@ietf.org; opsec chairs Cc: Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-net= s-02 On Jan 10, 2013, at 11:28 AM, Warren Kumari wrote: > Hello OpSec! >=20 > This starts a working group last call for draft-ietf-opsec-ipv6-implicati= ons-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 Networks" >=20 > The draft is available at http://tools.ietf.org/html/draft-ietf-opsec-ipv= 6-implications-on-ipv4-nets-02 and https://datatracker.ietf.org/doc/draft-i= etf-opsec-ipv6-implications-on-ipv4-nets/=20 >=20 > Please review this draft to see if you think it is ready for publication.= Send comments to the list. =20 >=20 > The WGLC will end on 25th January 2013. This is a reminder to please provide feedback on this draft -- so far I do = not think we have enough feedback to call consensus. Thanks to the folk we do have feedback from; Wes, Simon and Rama... W >=20 > --Warren, speaking as OpSec WG co-chair >=20 >=20 > --=20 > I had no shoes and wept. Then I met a man who had no feet. So I said, "= Hey man, got any shoes you're not using?"=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- The duke had a mind that ticked like a clock and, like a clock, it regularl= y went cuckoo. -- (Terry Pratchett, Wyrd Sisters) _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec= From pkampana@cisco.com Wed Jan 23 08:52:52 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B9721F854F for ; Wed, 23 Jan 2013 08:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxVrUuarZZ6r for ; Wed, 23 Jan 2013 08:52:51 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 52A0321F854E for ; Wed, 23 Jan 2013 08:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1953; q=dns/txt; s=iport; t=1358959971; x=1360169571; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CoBPvOw7X3TQhtfNut4n5iZx1tK5b+mZM+oq3pu9jog=; b=QyX7+ZQ9ROhs7pF+hWiqNQa4mPFNmqUOY2WDSf+LV9eaAgUm0hIo1CVg M+nGt+UiQ9BQJkU7KyRgePxZqAOQ+s8R7xduIHspGnDAO0LEgyFs/dvwu 06WxbKDRgN3ksazZktw9EyZdR70e/lPzg3coxDiK7AteV2aUJaUSLxOTZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHEUAFGtJXG9/2dsb2JhbABEvjAWc4IeAQEBAwEBAQEaHTQQBwQCAQgRBAEBCxQJBycLFAkIAgQBEgiIDAYMvWSQUmEDlyiPLYJ1giQ X-IronPort-AV: E=Sophos;i="4.84,523,1355097600"; d="scan'208";a="166859690" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 23 Jan 2013 16:52:50 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0NGqoFT018234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jan 2013 16:52:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 10:52:50 -0600 From: "Panos Kampanakis (pkampana)" To: Warren Kumari , "opsec@ietf.org" , opsec chairs , Fernando Gont Thread-Topic: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Index: AQHN+N2LrmtfJy6BU0yH5COaBfKdjZhXIaNg Date: Wed, 23 Jan 2013 16:52:50 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A75161C92@xmb-rcd-x10.cisco.com> References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> In-Reply-To: <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 16:52:52 -0000 After reviewing it again, I think the doc is mostly ready. I didn't see a question about it before, but would it be worth to also add = a section on how to filter AYIYA? Rgs, Panos -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of W= arren Kumari Sent: Tuesday, January 22, 2013 3:17 PM To: opsec@ietf.org; opsec chairs Cc: Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-net= s-02 On Jan 10, 2013, at 11:28 AM, Warren Kumari wrote: > Hello OpSec! >=20 > This starts a working group last call for draft-ietf-opsec-ipv6-implicati= ons-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 Networks" >=20 > The draft is available at http://tools.ietf.org/html/draft-ietf-opsec-ipv= 6-implications-on-ipv4-nets-02 and https://datatracker.ietf.org/doc/draft-i= etf-opsec-ipv6-implications-on-ipv4-nets/=20 >=20 > Please review this draft to see if you think it is ready for publication.= Send comments to the list. =20 >=20 > The WGLC will end on 25th January 2013. This is a reminder to please provide feedback on this draft -- so far I do = not think we have enough feedback to call consensus. Thanks to the folk we do have feedback from; Wes, Simon and Rama... W >=20 > --Warren, speaking as OpSec WG co-chair >=20 >=20 > --=20 > I had no shoes and wept. Then I met a man who had no feet. So I said, "= Hey man, got any shoes you're not using?"=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- The duke had a mind that ticked like a clock and, like a clock, it regularl= y went cuckoo. -- (Terry Pratchett, Wyrd Sisters) _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From fgont@si6networks.com Wed Jan 23 20:24:36 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7721F8863 for ; Wed, 23 Jan 2013 20:24:36 -0800 (PST) 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=[AWL=0.496, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejpiqP7K6aGA for ; Wed, 23 Jan 2013 20:24:36 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id EB6C521F8712 for ; Wed, 23 Jan 2013 20:24:35 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TyELv-0000Ov-3c; Thu, 24 Jan 2013 05:23:58 +0100 Message-ID: <5100B74F.7090600@si6networks.com> Date: Thu, 24 Jan 2013 01:23:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Panos Kampanakis (pkampana)" References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <1C9F17D1873AFA47A969C4DD98F98A75161C92@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A75161C92@xmb-rcd-x10.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , opsec chairs , Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 04:24:36 -0000 Hi, Panos, On 01/23/2013 01:52 PM, Panos Kampanakis (pkampana) wrote: > After reviewing it again, I think the doc is mostly ready. > > I didn't see a question about it before, but would it be worth to > also add a section on how to filter AYIYA? I've dropped a note to the author of the aforementioned I-D regarding the status (in terms of standardization and deployment/use) of AYIYA. If it's still alive, we should add a section about it -- not that I'm happy to go through the whole , but.... :-) Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Donald.Smith@CenturyLink.com Thu Jan 24 09:34:06 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D3121F89B9 for ; Thu, 24 Jan 2013 09:34:06 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8przRS5xM6O for ; Thu, 24 Jan 2013 09:34:05 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id A22DA21F87A6 for ; Thu, 24 Jan 2013 09:34:05 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r0OHY3VL007186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jan 2013 11:34:04 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B0E091E007F; Thu, 24 Jan 2013 11:33:58 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 94A0C1E005A; Thu, 24 Jan 2013 11:33:58 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r0OHXvcC005058; Thu, 24 Jan 2013 11:33:58 -0600 (CST) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r0OHXvND005027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jan 2013 11:33:57 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0318.001; Thu, 24 Jan 2013 10:33:57 -0700 From: "Smith, Donald" To: "'fgont@si6networks.com'" , "'opsec@ietf.org'" Thread-Topic: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Index: AQHN+PYIZDsZ1OHyBUOS6U1ze2rTfZhYv6GA Date: Thu, 24 Jan 2013 17:33:56 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A2ABC1A@PDDCWMBXEX503.ctl.intranet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OPSEC] FW: WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:34:06 -0000 Fernando, I posted this the other day but you may not have seen it. Nothing TOO major just a few comments and recommendations. "Pampers use multiple layers of protection to prevent leakage. Rommel used = defense in depth to defend European fortresses." (A.White) Donald.Smith@Cen= turyLink.com >-----Original Message----- >From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf >Of Smith, Donald >Sent: Tuesday, January 22, 2013 4:12 PM >To: Warren Kumari; opsec@ietf.org; opsec chairs >Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4- >nets-02 > >1. > >No mention of v6 aware devices that haven't been configured for v6. One >example is acls on most routers have to be duplicated for v6. Firewall >rules too. So it isn't just a "can it support issue" but also a is it >configured to examine v6 or other tunneled traffic. > > > > >Only in some exceptional cases (such as military operations networks) > could this approach to mitigating the aforementioned security > implications be thought of as a longer-term strategy. > >I am not sure that is true. Some enterprise may very well be able to use >just v4 for quite a while especially internally. They might have to >offer services on v6 but via some hosting or other DMZ methods they may >be able to keep their internal network v4 for many more years. > > >3.6 >The corresponding addresses can be easily obtained from a UNIX > host by issuing the command 'dig teredo.ipv6.microsoft.com a' > (without quotes). > >dig isn't a "standard" unix tool. nslookup or host is in nearly all >cases but not all unix systems have dig installed by default. (nslookup >is deprecated for host but still fairly common if not universal). > >How about nslookup since that is also on windows and other platforms? > >4. >This: >This is likely to cause IPv6-capable hosts to attempt to > reach an ever-increasing number of popular destinations via IPv6, > even if this IPv6 connectivity is provided relies on a transition > technology over an IPv4-only network. >Should be this: >This is likely to cause IPv6-capable hosts to attempt to > reach an ever-increasing number of popular destinations via IPv6, > even if this IPv6 connectivity as provided relies on a transition > technology over an IPv4-only network. > >Shouldn't this be NXD instead of dropping the requests. That way the >client can see it is getting errors not just blackholeing the aaaa >requests? > >For this reason, networks attempting to prevent IPv6 traffic from > traversing their devices should consider configuring their local > recursive DNS servers to ignore queries for AAAA DNS records, or even > consider filtering AAAA records at the network ingress point to > prevent end hosts from attempting their own DNS resolution. > >That could also be done on a forwarder right not just a local recursive >dns server? > > >A firewall could signal the packet drop by means of an ICMPv6 > error message (or TCP [RFC0793] RST segment if appropriate), such > that the source node can e.g. quickly react as described in > [RFC5461]. > >If there is no v6 connectivity I wouldn't expect icmpv6 to work and the >queries will usually be udp so a tcp resest is not valid. > >I think therefore that NXD from dns server or icmpv4 from a middle box >is better. And I would change firewall to middle box since there are >IPSes, UTM devices, portals etc... that could be dropping the v6 >queries. > > > > > >(coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@centurylink.com > > > >From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] on behalf of >Warren Kumari [warren@kumari.net] >Sent: Tuesday, January 22, 2013 1:17 PM >To: opsec@ietf.org; opsec chairs >Cc: Warren Kumari >Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4- >nets-02 > > > >On Jan 10, 2013, at 11:28 AM, Warren Kumari wrote: > >> Hello OpSec! >> >> This starts a working group last call for draft-ietf-opsec-ipv6- >implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 >Networks" >> >> The draft is available at http://tools.ietf.org/html/draft-ietf-opsec- >ipv6-implications-on-ipv4-nets-02 and >https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on- >ipv4-nets/ >> >> Please review this draft to see if you think it is ready for >publication. Send comments to the list. >> >> The WGLC will end on 25th January 2013. > >This is a reminder to please provide feedback on this draft -- so far I >do not think we have enough feedback to call consensus. >Thanks to the folk we do have feedback from; Wes, Simon and Rama... > >W > >> >> --Warren, speaking as OpSec WG co-chair >> >> >> -- >> I had no shoes and wept. Then I met a man who had no feet. So I >said, "Hey man, got any shoes you're not using?" >> >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > >-- >The duke had a mind that ticked like a clock and, like a clock, it >regularly went cuckoo. > > -- (Terry Pratchett, Wyrd Sisters) > > >_______________________________________________ >OPSEC mailing list >OPSEC@ietf.org >https://www.ietf.org/mailman/listinfo/opsec >_______________________________________________ >OPSEC mailing list >OPSEC@ietf.org >https://www.ietf.org/mailman/listinfo/opsec From joelja@bogus.com Thu Jan 24 18:17:19 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB17721F86D6 for ; Thu, 24 Jan 2013 18:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zErqFVSMQTsm for ; Thu, 24 Jan 2013 18:17:19 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E60EE1F0CF6 for ; Thu, 24 Jan 2013 18:17:15 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0P2HEpD096391 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 25 Jan 2013 02:17:14 GMT (envelope-from joelja@bogus.com) Message-ID: <5101EB24.2020204@bogus.com> Date: Thu, 24 Jan 2013 18:17:08 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Warren Kumari , opsec@ietf.org, opsec chairs References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> In-Reply-To: <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 25 Jan 2013 02:17:15 +0000 (UTC) Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 02:17:19 -0000 I reread this document with an eye towards publication. generally I think it is good and ready for publication modula the comments below which obviously you can take at your discretion or not. section 1 Among such controls is the enforcement of filtering policies, such that undesirable traffic is blocked. is awkward. IPv6 supporting security controls can enforce filtering policy such that undesirable traffic is blocked. I take issue with the example in this sentence Only in some exceptional cases (such as military operations networks) could this approach to mitigating the aforementioned security implications be thought of as a longer-term strategy. the people who find that sort of approach necessary know who they are. the same applies to a similar stanza in 2.1 the citations in section 2 for toolkits. read like advertising and should be detuned accordingly. citing them as examples is fine. if the third citation is factually incorrect in some fashion it should be dropped. [Waters2011] provides an example of how this could be achieved using publicly available tools (besides incorrectly claiming the discovery of a "0day vulnerability"). section 3. Unless properly managed, tunneling mechanisms might result in negative security implications statement is vague even when followed by the citation. might result in exposure is more explicit and simpler. drop "therefore" from the second paragraph section 3.6 It should be noted that dig is part of bind or bindutils it is a product of ISC and while it comes with lots of unix systems it is not generic to them. On 1/22/13 12:17 PM, Warren Kumari wrote: > On Jan 10, 2013, at 11:28 AM, Warren Kumari wrote: > >> Hello OpSec! >> >> This starts a working group last call for draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 -- "Security Implications of IPv6 on IPv4 Networks" >> >> The draft is available at http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 and https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/ >> >> Please review this draft to see if you think it is ready for publication. Send comments to the list. >> >> The WGLC will end on 25th January 2013. > This is a reminder to please provide feedback on this draft -- so far I do not think we have enough feedback to call consensus. > Thanks to the folk we do have feedback from; Wes, Simon and Rama... > > W > >> --Warren, speaking as OpSec WG co-chair >> >> >> -- >> I had no shoes and wept. Then I met a man who had no feet. So I said, "Hey man, got any shoes you're not using?" >> >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > -- > The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo. > > -- (Terry Pratchett, Wyrd Sisters) > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From Alec.Waters@dataline.co.uk Fri Jan 25 05:07:48 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E59921F862D for ; Fri, 25 Jan 2013 05:07:48 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+vd32oFcP6H for ; Fri, 25 Jan 2013 05:07:47 -0800 (PST) Received: from mailfirewall.dataline.co.uk (mailfirewall.dataline.co.uk [194.242.137.218]) by ietfa.amsl.com (Postfix) with ESMTP id 8058621F8619 for ; Fri, 25 Jan 2013 05:07:47 -0800 (PST) X-ASG-Debug-ID: 1359108693-75cc00ce0000-KyVq2t X-Barracuda-URL: http://194.242.137.218:8000/cgi-bin/mark.cgi Received: from zeus.olympus.dataline.co.uk (localhost [127.0.0.1]) by mailfirewall.dataline.co.uk (Spam & Virus Firewall) with ESMTP id 1AF1623B803; Fri, 25 Jan 2013 10:11:33 +0000 (GMT) Received: from zeus.olympus.dataline.co.uk ([192.168.88.2]) by mailfirewall.dataline.co.uk with ESMTP id D1w1mvyesmxPoypj (version=TLSv1 cipher=RC4-MD5 bits=128 verify=NO); Fri, 25 Jan 2013 10:11:33 +0000 (GMT) X-Barracuda-Envelope-From: Alec.Waters@dataline.co.uk X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-ASG-Whitelist: Client Received: from ZEUS.olympus.dataline.co.uk ([fe80::1d33:1da5:a901:3828]) by ZEUS.olympus.dataline.co.uk ([fe80::1d33:1da5:a901:3828%13]) with mapi id 14.02.0328.009; Fri, 25 Jan 2013 10:11:33 +0000 From: Alec Waters X-Barracuda-BWL-IP: fe80::1d33:1da5:a901:3828 X-Barracuda-BBL-IP: fe80::1d33:1da5:a901:3828 X-Barracuda-RBL-IP: fe80::1d33:1da5:a901:3828 To: joel jaeggli , "opsec@ietf.org" X-ASG-Orig-Subj: RE: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Topic: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Index: AQHN+Oradf0EinXrdEWjZ6oX83PiYphZUlEAgACDnZA= Date: Fri, 25 Jan 2013 10:11:32 +0000 Message-ID: <8350146BADDCE04480B969B36967473D0252D257@ZEUS.olympus.dataline.co.uk> References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <5101EB24.2020204@bogus.com> In-Reply-To: <5101EB24.2020204@bogus.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.88.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.88.2] X-Barracuda-Start-Time: 1359108694 X-Barracuda-Encrypted: RC4-MD5 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at dataline.co.uk Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 13:07:48 -0000 Hi Joel, > if the third citation is factually incorrect in some fashion it should be= dropped. >=20 > [Waters2011] provides an example of how this could be achieved > using publicly available tools (besides incorrectly claiming the > discovery of a "0day vulnerability"). If the reference is deemed of value to the draft, I (as author of the refer= ence) can reproduce it at another location minus all the 0day nonsense put = in there by the "editors" at Infosec Institute. alec --=A0 From fgont@si6networks.com Sat Jan 26 16:50:39 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA0621F89FD for ; Sat, 26 Jan 2013 16:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piHQg2W1e47b for ; Sat, 26 Jan 2013 16:50:39 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3B21F869A for ; Sat, 26 Jan 2013 16:50:32 -0800 (PST) Received: from [190.220.138.191] (helo=[192.168.1.44]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TzGRd-0001Hw-35; Sun, 27 Jan 2013 01:50:01 +0100 Message-ID: <5103765D.801@si6networks.com> Date: Sat, 26 Jan 2013 03:23:25 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: joel jaeggli References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <5101EB24.2020204@bogus.com> In-Reply-To: <5101EB24.2020204@bogus.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, opsec chairs , Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 00:50:40 -0000 Hi, Joel, Thanks so much for your feedback! Please find my comments in-line... On 01/24/2013 11:17 PM, joel jaeggli wrote: > I reread this document with an eye towards publication. > > generally I think it is good and ready for publication modula the > comments below which obviously you can take at your discretion or not. > > section 1 > > Among such controls is the enforcement of > filtering policies, such that undesirable traffic is blocked. > > is awkward. mmm.. what do you mean by "awkward"? > IPv6 supporting security controls can enforce filtering policy such > that undesirable traffic is blocked. Is this a proposed text to replace the above? Something else? > I take issue with the example in this sentence > > Only > in some exceptional cases (such as military operations networks) > could this approach to mitigating the aforementioned security > implications be thought of as a longer-term strategy. > > the people who find that sort of approach necessary know who they are. > the same applies to a similar stanza in 2.1 Are you suggesting that we should remove this paragraph, or something else? > the citations in section 2 for toolkits. read like advertising and > should be detuned accordingly. citing them as examples is fine. Please suggest how I could rephrease the text to look better -- the text is meant to just provide examples of tools that readers can use to play with this stuff. (FWIW, both toolkits are free software... so nobody is making money out of them). > if the > third citation is factually incorrect in some fashion it should be dropped. > > [Waters2011] provides an example of how this could be achieved > using publicly available tools (besides incorrectly claiming the > discovery of a "0day vulnerability"). Others have complained about it, already. I personally find the example valuable -- modulo the reference to it being a 0-day. -- SHould we leave it in if Alec modifies the text as noted on-list? > section 3. > > Unless properly managed, tunneling mechanisms might result in > negative security implications > > statement is vague even when followed by the citation. > > might result in exposure is more explicit and simpler. Exposure is one factor. They might also help to evade security controls, might contain bugs with security implications, and might contain protocol-based vulnerabilities (think Nakibly et al's paper on routing loops). > drop "therefore" from the second paragraph > > section 3.6 > > It should be noted that dig is part of bind or bindutils it is a > product of ISC and while it comes with lots of unix systems it is not > generic to them. Should I replace it with something else? host? nslookup? Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From internet-drafts@ietf.org Sat Jan 26 21:52:25 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698AA21F866F; Sat, 26 Jan 2013 21:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doBzuugtw4jF; Sat, 26 Jan 2013 21:52:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B5F21F85DB; Sat, 26 Jan 2013 21:52:23 -0800 (PST) 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.37 Message-ID: <20130127055223.26999.85537.idtracker@ietfa.amsl.com> Date: Sat, 26 Jan 2013 21:52:23 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ip-options-filtering-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 05:52:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Recommendations on filtering of IPv4 packets containing = IPv4 options Author(s) : Fernando Gont RJ Atkinson Carlos Pignataro Filename : draft-ietf-opsec-ip-options-filtering-02.txt Pages : 31 Date : 2013-01-26 Abstract: This document document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From joelja@bogus.com Sun Jan 27 11:49:08 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C7421F85B2 for ; Sun, 27 Jan 2013 11:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBqOUNgyaZWZ for ; Sun, 27 Jan 2013 11:49:07 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 89EFF21F8581 for ; Sun, 27 Jan 2013 11:49:07 -0800 (PST) Received: from joels-MacBook-Air.local ([64.9.242.111]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0RJn5TH035646 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 27 Jan 2013 19:49:06 GMT (envelope-from joelja@bogus.com) Message-ID: <510584AB.1070501@bogus.com> Date: Sun, 27 Jan 2013 11:48:59 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Fernando Gont References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <5101EB24.2020204@bogus.com> <5103765D.801@si6networks.com> In-Reply-To: <5103765D.801@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 27 Jan 2013 19:49:07 +0000 (UTC) Cc: opsec@ietf.org, opsec chairs , Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 19:49:08 -0000 On 1/25/13 10:23 PM, Fernando Gont wrote: > Hi, Joel, > > Thanks so much for your feedback! Please find my comments in-line... > > On 01/24/2013 11:17 PM, joel jaeggli wrote: >> I reread this document with an eye towards publication. >> >> generally I think it is good and ready for publication modula the >> comments below which obviously you can take at your discretion or not. >> >> section 1 >> >> Among such controls is the enforcement of >> filtering policies, such that undesirable traffic is blocked. >> >> is awkward. > mmm.. what do you mean by "awkward"? I mean if if you read that sentence alone it doesn't make a lot of sense. I suspect a copy editor would ask you to fix it. > >> IPv6 supporting security controls can enforce filtering policy such >> that undesirable traffic is blocked. > Is this a proposed text to replace the above? Something else? > yes >> I take issue with the example in this sentence >> >> Only >> in some exceptional cases (such as military operations networks) >> could this approach to mitigating the aforementioned security >> implications be thought of as a longer-term strategy. >> >> the people who find that sort of approach necessary know who they are. >> the same applies to a similar stanza in 2.1 > Are you suggesting that we should remove this paragraph, or something else? I'm suggesting that the authors and contributors don't run military operations networks so it's speculative, and that the people that do run networks that find this necessary won't find the example relatable, it's a property of operational requirements, not which industrial vertical you happen to be in that drives the requiresments. > > >> the citations in section 2 for toolkits. read like advertising and >> should be detuned accordingly. citing them as examples is fine. > Please suggest how I could rephrease the text to look better -- the text > is meant to just provide examples of tools that readers can use to play > with this stuff. (FWIW, both toolkits are free software... so nobody is > making money out of them). So if it's not addressed it likely will be an issue for the IESG review. these simples possible answer would be something like. 1. This is a toolkit, it does foo --> 2. this is also a toolkit, it does foo --> > >> if the >> third citation is factually incorrect in some fashion it should be dropped. >> >> [Waters2011] provides an example of how this could be achieved >> using publicly available tools (besides incorrectly claiming the >> discovery of a "0day vulnerability"). > Others have complained about it, already. I personally find the example > valuable -- modulo the reference to it being a 0-day. -- SHould we leave > it in if Alec modifies the text as noted on-list? alec's suggestion on the list was fine. a citation that says, this like is great except all the parts we dispute or which are just wrong is less useful in my book than being able to say foo is a source for bar. if the link is sufficiently stable that it's likely to be there a decade from now so much the better. > > >> section 3. >> >> Unless properly managed, tunneling mechanisms might result in >> negative security implications >> >> statement is vague even when followed by the citation. >> >> might result in exposure is more explicit and simpler. > Exposure is one factor. They might also help to evade security controls, > might contain bugs with security implications, and might contain > protocol-based vulnerabilities (think Nakibly et al's paper on routing > loops). right so, you could expand on the implications a bit. the text you wrote above it pretty good for example. > > >> drop "therefore" from the second paragraph >> >> section 3.6 >> >> It should be noted that dig is part of bind or bindutils it is a >> product of ISC and while it comes with lots of unix systems it is not >> generic to them. > Should I replace it with something else? host? nslookup? just cite that it's part of bind. > Thanks so much! > > Best regards, From fgont@si6networks.com Sun Jan 27 15:12:59 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D3521F84F8 for ; Sun, 27 Jan 2013 15:12:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIckapIqM38c for ; Sun, 27 Jan 2013 15:12:58 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9A921F84F5 for ; Sun, 27 Jan 2013 15:12:58 -0800 (PST) Received: from [190.15.90.24] (helo=[192.168.1.126]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TzbOj-0007i3-B5; Mon, 28 Jan 2013 00:12:26 +0100 Message-ID: <5105B451.50008@si6networks.com> Date: Sun, 27 Jan 2013 20:12:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: joel jaeggli References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <5101EB24.2020204@bogus.com> <5103765D.801@si6networks.com> <510584AB.1070501@bogus.com> In-Reply-To: <510584AB.1070501@bogus.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, opsec chairs , Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 23:12:59 -0000 On 01/27/2013 04:48 PM, joel jaeggli wrote: >>> section 1 >>> >>> Among such controls is the enforcement of >>> filtering policies, such that undesirable traffic is blocked. >>> >>> is awkward. >> mmm.. what do you mean by "awkward"? > I mean if if you read that sentence alone it doesn't make a lot of > sense. I suspect a copy editor would ask you to fix it. English as non-native language here, but... what this text is supposed to mean is "one of the things that you can do is enforce IPv6 filtering, such that the IPv6-based traffic you don't like is blocked"). Doesn't that sentence convey that information? >>> IPv6 supporting security controls can enforce filtering policy >>> such >>> that undesirable traffic is blocked. >> Is this a proposed text to replace the above? Something else? >> > yes If anything, shouldn't it be "IPv6-supporting security controls..."? (or maybe "IPv6-enabled security controls"..). >>> I take issue with the example in this sentence >>> >>> Only >>> in some exceptional cases (such as military operations networks) >>> could this approach to mitigating the aforementioned security >>> implications be thought of as a longer-term strategy. >>> >>> the people who find that sort of approach necessary know who they are. >>> the same applies to a similar stanza in 2.1 >> Are you suggesting that we should remove this paragraph, or something >> else? > I'm suggesting that the authors and contributors don't run military > operations networks so it's speculative, FWIW, this note was added in response to feedback from folks involved in military networks. > and that the people that do run > networks that find this necessary won't find the example relatable, it's > a property of operational requirements, not which industrial vertical > you happen to be in that drives the requiresments. I couldn't parse tis last sentence... Anyway... What's your proposed path to addresss the point you've raised? FWIW, this note was included because the previous paragraph noted that, if anything, this should only be considered as a "short-term" strategy. However, in some networks (in which you only deploy stuff you have no other option to), this could be a longer-term strategy. >>> the citations in section 2 for toolkits. read like advertising and >>> should be detuned accordingly. citing them as examples is fine. >> Please suggest how I could rephrease the text to look better -- the text >> is meant to just provide examples of tools that readers can use to play >> with this stuff. (FWIW, both toolkits are free software... so nobody is >> making money out of them). > So if it's not addressed it likely will be an issue for the IESG review. > > these simples possible answer would be something like. > > 1. This is a toolkit, it does foo --> > 2. this is also a toolkit, it does foo --> I will tweak the I-D as suggested. >>> if the >>> third citation is factually incorrect in some fashion it should be >>> dropped. >>> >>> [Waters2011] provides an example of how this could be achieved >>> using publicly available tools (besides incorrectly claiming the >>> discovery of a "0day vulnerability"). >> Others have complained about it, already. I personally find the example >> valuable -- modulo the reference to it being a 0-day. -- SHould we leave >> it in if Alec modifies the text as noted on-list? > alec's suggestion on the list was fine. a citation that says, this like > is great except all the parts we dispute or which are just wrong is less > useful in my book than being able to say foo is a source for bar. Agreed. But we only had the former. > if the > link is sufficiently stable that it's likely to be there a decade from > now so much the better. What I can personally offer is to put it on my personal site. I'll wait and see what Alec has to offer in this respect, anyway. >>> section 3. >>> >>> Unless properly managed, tunneling mechanisms might result in >>> negative security implications >>> >>> statement is vague even when followed by the citation. >>> >>> might result in exposure is more explicit and simpler. >> Exposure is one factor. They might also help to evade security controls, >> might contain bugs with security implications, and might contain >> protocol-based vulnerabilities (think Nakibly et al's paper on routing >> loops). > right so, you could expand on the implications a bit. the text you wrote > above it pretty good for example. Ok, will do. >>> drop "therefore" from the second paragraph >>> >>> section 3.6 >>> >>> It should be noted that dig is part of bind or bindutils it is a >>> product of ISC and while it comes with lots of unix systems it is not >>> generic to them. >> Should I replace it with something else? host? nslookup? > just cite that it's part of bind. Will do. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Alec.Waters@dataline.co.uk Sun Jan 27 23:23:17 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4657821F88B5 for ; Sun, 27 Jan 2013 23:23:17 -0800 (PST) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C65YNm1tdoWb for ; Sun, 27 Jan 2013 23:23:16 -0800 (PST) Received: from mailfirewall.dataline.co.uk (mailfirewall.dataline.co.uk [194.242.137.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3847521F889A for ; Sun, 27 Jan 2013 23:23:15 -0800 (PST) X-ASG-Debug-ID: 1359357772-7666004e0000-KyVq2t X-Barracuda-URL: http://194.242.137.218:8000/cgi-bin/mark.cgi Received: from zeus.olympus.dataline.co.uk (localhost [127.0.0.1]) by mailfirewall.dataline.co.uk (Spam & Virus Firewall) with ESMTP id F387F2489B6; Mon, 28 Jan 2013 07:22:52 +0000 (GMT) Received: from zeus.olympus.dataline.co.uk ([192.168.88.2]) by mailfirewall.dataline.co.uk with ESMTP id WWLN0jVdnQGQYGmB (version=TLSv1 cipher=RC4-MD5 bits=128 verify=NO); Mon, 28 Jan 2013 07:22:52 +0000 (GMT) X-Barracuda-Envelope-From: Alec.Waters@dataline.co.uk X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-ASG-Whitelist: Client Received: from ZEUS.olympus.dataline.co.uk ([fe80::1d33:1da5:a901:3828]) by ZEUS.olympus.dataline.co.uk ([fe80::1d33:1da5:a901:3828%13]) with mapi id 14.02.0328.009; Mon, 28 Jan 2013 07:22:51 +0000 From: Alec Waters X-Barracuda-BWL-IP: fe80::1d33:1da5:a901:3828 X-Barracuda-BBL-IP: fe80::1d33:1da5:a901:3828 X-Barracuda-RBL-IP: fe80::1d33:1da5:a901:3828 To: "fgont@si6networks.com" , "joelja@bogus.com" X-ASG-Orig-Subj: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Topic: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Index: Ac39KEe1df0EinXrdEWjZ6oX83PiYg== Date: Mon, 28 Jan 2013 07:22:50 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_fem2cev6gisu6pox3fef15y71359357768407emailandroidcom_" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.88.2] X-Barracuda-Start-Time: 1359357772 X-Barracuda-Encrypted: RC4-MD5 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at dataline.co.uk Cc: "opsec@ietf.org" , "opsec-chairs@tools.ietf.org" , "warren@kumari.net" Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alec Waters List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 07:23:17 -0000 --_000_fem2cev6gisu6pox3fef15y71359357768407emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRmVybmFuZG8sDQoNCj4gSSdsbCB3YWl0IGFuZCBzZWUgd2hhdCBBbGVjIGhhcyB0byBvZmZl ciBpbiB0aGlzIHJlc3BlY3QsIGFueXdheS4NCg0KSSB3YXMgcGxhbm5pbmcgdG8gcHV0IGEgcmV2 aXNlZCB2ZXJzaW9uIG9uIG15IGJsb2cgYXQgaHR0cDovL3dpcmV3YXRjaGVyLndvcmRwcmVzcy5j b20gLSB3b3VsZCB0aGF0IGJlIGFwcHJvcHJpYXRlPw0KDQpNYW55IHRoYW5rcywNCkFsZWMNCg0K --_000_fem2cev6gisu6pox3fef15y71359357768407emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <299087A2CE1FAC4A9017EA94A58D1E68@dataline.co.uk> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj5IaSBGZXJu YW5kbyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDs8c3BhbiBjbGFz cz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzMzMzMDE1NDQxODk1 cHg7ICI+SSdsbCB3YWl0Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFu IiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzMzMwMTU0NDE4OTVweDsgIj5hbmQgc2VlIHdoYXQg QWxlYyBoYXMgdG8gb2ZmZXIgaW4gdGhpcyByZXNwZWN0LCBhbnl3YXkuPC9zcGFuPjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB3YXMgcGxhbm5pbmcgdG8gcHV0IGEgcmV2aXNlZCB2 ZXJzaW9uIG9uIG15IGJsb2cgYXQgaHR0cDovL3dpcmV3YXRjaGVyLndvcmRwcmVzcy5jb20gLSB3 b3VsZCB0aGF0IGJlIGFwcHJvcHJpYXRlPyZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+TWFueSB0aGFua3MsJm5ic3A7PC9kaXY+DQo8ZGl2PkFsZWM8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJmb250LXNpemU6NzUlO2NvbG9yOiM1NzU3NTciPjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_fem2cev6gisu6pox3fef15y71359357768407emailandroidcom_-- From fgont@si6networks.com Mon Jan 28 18:30:38 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AA321F8495 for ; Mon, 28 Jan 2013 18:30:38 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpSo1FlC7+Hu for ; Mon, 28 Jan 2013 18:30:37 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 53B4A21F8488 for ; Mon, 28 Jan 2013 18:30:36 -0800 (PST) Received: from [186.134.13.189] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U00xD-0006N3-FM; Tue, 29 Jan 2013 03:29:43 +0100 Message-ID: <51073410.8000101@si6networks.com> Date: Mon, 28 Jan 2013 23:29:36 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alec Waters References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , "opsec-chairs@tools.ietf.org" , "warren@kumari.net" Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 02:30:38 -0000 Hi, Alec, On 01/28/2013 04:22 AM, Alec Waters wrote: > >> I'll wait and see what Alec has to offer in this respect, anyway. > > I was planning to put a revised version on my blog at > http://wirewatcher.wordpress.com - would that be appropriate? Please do it. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Alec.Waters@dataline.co.uk Tue Jan 29 07:19:03 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AA021F886E for ; Tue, 29 Jan 2013 07:19:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB4h+44Zm+ZH for ; Tue, 29 Jan 2013 07:19:03 -0800 (PST) Received: from mailfirewall.dataline.co.uk (mailfirewall.dataline.co.uk [194.242.137.218]) by ietfa.amsl.com (Postfix) with ESMTP id 01BA921F886C for ; Tue, 29 Jan 2013 07:19:02 -0800 (PST) X-ASG-Debug-ID: 1359472532-28d700470000-KyVq2t X-Barracuda-URL: http://194.242.137.218:8000/cgi-bin/mark.cgi Received: from zeus.olympus.dataline.co.uk (localhost [127.0.0.1]) by mailfirewall.dataline.co.uk (Spam & Virus Firewall) with ESMTP id B9917403D71; Tue, 29 Jan 2013 15:15:32 +0000 (GMT) Received: from zeus.olympus.dataline.co.uk ([192.168.88.2]) by mailfirewall.dataline.co.uk with ESMTP id IdBBhWcnOKUOCWmE (version=TLSv1 cipher=RC4-MD5 bits=128 verify=NO); Tue, 29 Jan 2013 15:15:32 +0000 (GMT) X-Barracuda-Envelope-From: Alec.Waters@dataline.co.uk X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-Barracuda-RBL-Trusted-Forwarder: 192.168.88.2 X-ASG-Whitelist: Client Received: from ZEUS.olympus.dataline.co.uk ([fe80::1d33:1da5:a901:3828]) by ZEUS.olympus.dataline.co.uk ([fe80::1d33:1da5:a901:3828%13]) with mapi id 14.02.0328.009; Tue, 29 Jan 2013 15:15:32 +0000 From: Alec Waters X-Barracuda-BWL-IP: fe80::1d33:1da5:a901:3828 X-Barracuda-BBL-IP: fe80::1d33:1da5:a901:3828 X-Barracuda-RBL-IP: fe80::1d33:1da5:a901:3828 To: Fernando Gont , joel jaeggli , "opsec@ietf.org" X-ASG-Orig-Subj: RE: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Topic: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 Thread-Index: AQHN+Oradf0EinXrdEWjZ6oX83PiYphZUlEAgAHXJICAAnNngIAAOM2AgAKfNGA= Date: Tue, 29 Jan 2013 15:15:30 +0000 Message-ID: <8350146BADDCE04480B969B36967473D0253C5A5@ZEUS.olympus.dataline.co.uk> References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <5101EB24.2020204@bogus.com> <5103765D.801@si6networks.com> <510584AB.1070501@bogus.com> <5105B451.50008@si6networks.com> In-Reply-To: <5105B451.50008@si6networks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.88.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.88.2] X-Barracuda-Start-Time: 1359472532 X-Barracuda-Encrypted: RC4-MD5 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at dataline.co.uk Cc: opsec chairs , Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 15:19:03 -0000 Hi Fernando, > What I can personally offer is to put it on my personal site. I'll wait > and see what Alec has to offer in this respect, anyway. How's this: http://wirewatcher.wordpress.com/2011/04/04/the-slaac-attack-using-ipv6-as-= a-weapon-against-ipv4/ alec --=A0 From joelja@bogus.com Tue Jan 29 17:39:16 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C49E21F898A for ; Tue, 29 Jan 2013 17:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suVfalUtAnTc for ; Tue, 29 Jan 2013 17:39:15 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98421F88B2 for ; Tue, 29 Jan 2013 17:39:15 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0U1ZX15069834 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 30 Jan 2013 01:35:34 GMT (envelope-from joelja@bogus.com) Message-ID: <510878DF.705@bogus.com> Date: Tue, 29 Jan 2013 17:35:27 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Alec Waters , Fernando Gont , "opsec@ietf.org" References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <5101EB24.2020204@bogus.com> <5103765D.801@si6networks.com> <510584AB.1070501@bogus.com> <5105B451.50008@si6networks.com> <8350146BADDCE04480B969B36967473D0253C5A5@ZEUS.olympus.dataline.co.uk> In-Reply-To: <8350146BADDCE04480B969B36967473D0253C5A5@ZEUS.olympus.dataline.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 30 Jan 2013 01:35:35 +0000 (UTC) Cc: opsec chairs , Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 01:39:16 -0000 On 1/29/13 7:15 AM, Alec Waters wrote: > Hi Fernando, > >> What I can personally offer is to put it on my personal site. I'll wait >> and see what Alec has to offer in this respect, anyway. > How's this: > > http://wirewatcher.wordpress.com/2011/04/04/the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/ it's excellent. > alec > -- > From warren@kumari.net Tue Jan 29 18:26:16 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5B721F8996 for ; Tue, 29 Jan 2013 18:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.754 X-Spam-Level: X-Spam-Status: No, score=-101.754 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n9z1M3DHh5n for ; Tue, 29 Jan 2013 18:26:15 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFD621F8995 for ; Tue, 29 Jan 2013 18:26:15 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id CDCEB1B40925; Fri, 25 Jan 2013 09:11:18 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <8350146BADDCE04480B969B36967473D0252D257@ZEUS.olympus.dataline.co.uk> Date: Fri, 25 Jan 2013 09:11:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7E860414-6F8E-4656-BB4F-928568B167D1@kumari.net> References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <5101EB24.2020204@bogus.com> <8350146BADDCE04480B969B36967473D0252D257@ZEUS.olympus.dataline.co.uk> To: Alec Waters X-Mailer: Apple Mail (2.1499) Cc: "opsec@ietf.org" , Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 02:26:16 -0000 On Jan 25, 2013, at 5:11 AM, Alec Waters = wrote: > Hi Joel, >=20 >> if the third citation is factually incorrect in some fashion it = should be dropped. >>=20 >> [Waters2011] provides an example of how this could be achieved >> using publicly available tools (besides incorrectly claiming = the >> discovery of a "0day vulnerability"). >=20 > If the reference is deemed of value to the draft, I (as author of the = reference) can reproduce it at another location minus all the 0day = nonsense put in there by the "editors" at Infosec Institute. Personally I think that that would be useful, although another option = would be for Fernando to remove the somewhat snide parenthetical=85 >=20 > alec > --=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." -- Terry Pratchett From joelja@bogus.com Tue Jan 29 18:40:30 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C621F86CE for ; Tue, 29 Jan 2013 18:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WkKhvtZQDBn for ; Tue, 29 Jan 2013 18:40:30 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5629421F86CC for ; Tue, 29 Jan 2013 18:40:30 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0U2eP4k070550 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 30 Jan 2013 02:40:26 GMT (envelope-from joelja@bogus.com) Message-ID: <51088815.2060608@bogus.com> Date: Tue, 29 Jan 2013 18:40:21 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Warren Kumari , Alec Waters References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <5101EB24.2020204@bogus.com> <8350146BADDCE04480B969B36967473D0252D257@ZEUS.olympus.dataline.co.uk> <7E860414-6F8E-4656-BB4F-928568B167D1@kumari.net> In-Reply-To: <7E860414-6F8E-4656-BB4F-928568B167D1@kumari.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 30 Jan 2013 02:40:26 +0000 (UTC) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 02:40:30 -0000 On 1/25/13 6:11 AM, Warren Kumari wrote: > On Jan 25, 2013, at 5:11 AM, Alec Waters wrote: > >> Hi Joel, >> >>> if the third citation is factually incorrect in some fashion it should be dropped. >>> >>> [Waters2011] provides an example of how this could be achieved >>> using publicly available tools (besides incorrectly claiming the >>> discovery of a "0day vulnerability"). >> If the reference is deemed of value to the draft, I (as author of the reference) can reproduce it at another location minus all the 0day nonsense put in there by the "editors" at Infosec Institute. > > Personally I think that that would be useful, although another option would be for Fernando to remove the somewhat snide parenthetical… > new proposed reference created by alec, cited is more than fine. >> alec >> -- >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > -- > "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." > -- Terry Pratchett > > > > > From warren@kumari.net Wed Jan 30 07:04:29 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7212321F8804 for ; Wed, 30 Jan 2013 07:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jko4xGJRQgYe for ; Wed, 30 Jan 2013 07:04:29 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC96321F87CD for ; Wed, 30 Jan 2013 07:04:28 -0800 (PST) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id DF1221B40429; Wed, 30 Jan 2013 10:04:27 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <7E860414-6F8E-4656-BB4F-928568B167D1@kumari.net> Date: Wed, 30 Jan 2013 10:04:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <847C906C-1AFC-46F5-9D80-FC54B118DF54@kumari.net> References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> <5101EB24.2020204@bogus.com> <8350146BADDCE04480B969B36967473D0252D257@ZEUS.olympus.dataline.co.uk> <7E860414-6F8E-4656-BB4F-928568B167D1@kumari.net> To: Alec Waters X-Mailer: Apple Mail (2.1499) Cc: "opsec@ietf.org" , Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 15:04:29 -0000 On Jan 25, 2013, at 9:11 AM, Warren Kumari wrote: >=20 > On Jan 25, 2013, at 5:11 AM, Alec Waters = wrote: >=20 >> Hi Joel, >>=20 >>> if the third citation is factually incorrect in some fashion it = should be dropped. >>>=20 >>> [Waters2011] provides an example of how this could be achieved >>> using publicly available tools (besides incorrectly claiming = the >>> discovery of a "0day vulnerability"). >>=20 >> If the reference is deemed of value to the draft, I (as author of the = reference) can reproduce it at another location minus all the 0day = nonsense put in there by the "editors" at Infosec Institute. >=20 > > Personally I think that that would be useful, although another option = would be for Fernando to remove the somewhat snide parenthetical=85 > Sorry, this was spooled in a mail queue from a while back=85. W >>=20 >> alec >> --=20 >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >>=20 >=20 > -- > "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." > -- Terry Pratchett >=20 >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- "Let's just say that if complete and utter chaos was lightning, he'd be = the sort to stand on a hilltop in a thunderstorm wearing wet copper = armour and shouting 'All gods are bastards'." -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of = Magic) From warren@kumari.net Thu Jan 31 08:36:36 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DDE21F84B6 for ; Thu, 31 Jan 2013 08:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uTSEDpxS81s for ; Thu, 31 Jan 2013 08:36:35 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A958E21F851F for ; Thu, 31 Jan 2013 08:36:34 -0800 (PST) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 7D8C11B40639; Thu, 31 Jan 2013 11:36:33 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Thu, 31 Jan 2013 11:36:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> To: opsec@ietf.org, opsec chairs X-Mailer: Apple Mail (2.1499) Cc: Warren Kumari Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:36:36 -0000 On Jan 24, 2013, at 11:25 AM, Warren Kumari wrote: >=20 > On Jan 22, 2013, at 3:17 PM, Warren Kumari wrote: >=20 >>=20 >> On Jan 10, 2013, at 11:28 AM, Warren Kumari = wrote: >>=20 >>> Hello OpSec! >>>=20 >>> This starts a working group last call for = draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 -- "Security = Implications of IPv6 on IPv4 Networks" >>>=20 >>> The draft is available at = http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets= -02 and = https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv= 4-nets/=20 >>>=20 >>> Please review this draft to see if you think it is ready for = publication. Send comments to the list. =20 >>>=20 >>> The WGLC will end on 25th January 2013. >>=20 >> This is a reminder to please provide feedback on this draft -- so far = I do not think we have enough feedback to call consensus. >> Thanks to the folk we do have feedback from; Wes, Simon and Rama=85 >=20 > And another reminder -- we are extending the WGLC to Feb 1st -- but, = feel *free* to get your comments in sooner than that! with no hats=85 And hare are a chunk more comments. These are just nits / readability = bits=85 On a slightly more substantive note, I also think that the reference to = military networks is unneeded / not helpful.=20 W 1. Introduction Most general-purpose operating systems implement and enable by default native IPv6 [RFC2460] support and a number of transition/ co-existence technologies. In those cases in which the corresponding devices are deployed on networks that are assumed to be IPv4-only, native IPv6 support and/or IPv6 transition/co-existence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example, O: implement and enable by default[...]technologies. P: implement and enable [...] technologies by default. C: Readability O: In those cases P: For cases=20 C: Readability o A Network Intrusion Detection System (NIDS) might be prepared to detect attack patterns for IPv4 traffic, but might be unable to detect the same attack patterns when a transition/co-existence technology is leveraged for that purpose. O: might be prepared [...] might be unable P: may be prepared [...] but may not be able o An IPv4 firewall might enforce a specific security policy in IPv4, but might be unable to enforce the same policy in IPv6. O: might (twice) P: may (twice) o Some transition/co-existence mechanisms might cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure. O: might P: could Some transition/co-existence mechanisms (notably Teredo) are designed to traverse Network Address Port Translation (NAPT) [RFC2663] devices, allowing incoming IPv6 connections from the Internet to hosts behind the organizational firewall or NAPT (which in many deployments provides a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network). O: or NAPT (which in many deployments=20 P: or NAPT. (In many deployments, this o IPv6 support might, either inadvertently or as a result of a deliberate attack, result in VPN traffic leaks if IPv6-unaware Virtual Private Network (VPN) software is employed by dual-stacked hosts [I-D.ietf-opsec-vpn-leakages]. O: might P: could In general, most of the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and on IPv4-tunneled traffic. Among such controls is the enforcement of filtering policies, such that undesirable traffic is blocked. While O: , such that undesirable traffic is blocked. P: to block undesirable traffic. =20 IPv6 widespread/global IPv6 deployment has been slower than expected, it is nevertheless happening, and thus filtering IPv6 traffic (whether native or transition/co-existence) to mitigate IPv6 security implications on IPv4 networks should only be considered as a temporary solution to protect a network until IPv6 is deployed. Only in some exceptional cases (such as military operations networks) could this approach to mitigating the aforementioned security implications be thought of as a longer-term strategy. O: happening, and thus filtering P: happening; and thus, filtering O: considered as a temporary solution to protect a network until IPv6 is = deployed. P: considered as a temporary measure, until IPv6 is deployed. Gont & Liu Expires July 1, 2013 [Page 3] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 This document discusses the security implications of IPv6 and IPv6 transition/co-existence technologies on (allegedly) IPv4-only networks, and provides guidance on how to mitigate the aforementioned issues. O: This document discusses the security implications of IPv6 and IPv6 transition/co-existence technologies on (allegedly) IPv4-only networks, and provides guidance on how to mitigate the aforementioned issues. P: Delete above paragraph C: Already in the abstract; not sure why it is here as well? Gont & Liu Expires July 1, 2013 [Page 4] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 2. Security Implications of Native IPv6 Support Most popular operating systems include IPv6 support that is enabled by default. This means that even if a network is expected to be IPv4-only, much of its infrastructure is nevertheless likely to be IPv6 enabled. For example, hosts are likely to have at least link- local IPv6 connectivity which might be exploited by attackers with access to the local network. [CORE2007] is a security advisory about a buffer overflow which could be remotely-exploited by leveraging link-local IPv6 connectivity that is enabled by default. Additionally, unless appropriate measures are taken, an attacker with access to an 'IPv4-only' local network could impersonate a local router and cause local hosts to enable their 'non-link-local' IPv6 connectivity (e.g. by sending Router Advertisement messages), possibly circumventing security controls that were enforced only on IPv4 communications. [THC-IPV6] is the first publicly-available toolkit that implemented this attack vector (along with many others). [IPv6-Toolkit] is a fully-featured trouble-shooting and security assessment tool that implements this attack vector (along with many others). [Waters2011] provides an example of how this could be achieved using publicly available tools (besides incorrectly claiming the discovery of a "0day vulnerability"). Native IPv6 support could also possibly lead to VPN traffic leakages when hosts employ VPN software that not only does not support IPv6, but that does nothing about IPv6 traffic. O: about IPv6 traffic. P: with IPv6 traffic, instead allowing that to bypass the VPN. C: Not sure if this is what is meant? [I-D.ietf-opsec-vpn-leakages] describes this issue, along with possible mitigations. In general, networks should enforce on native IPv6 traffic the same security policies they currently enforce on IPv4 traffic. However, in those networks in which IPv6 has not yet been deployed, and enforcing the aforementioned policies is deemed as unfeasible, a network administrator might mitigate IPv6-based attack vectors by means of appropriate packet filtering. O: they currently enforce P: currently enforced O: might P: could 2.1. Filtering Native IPv6 Traffic Some layer-2 devices might have the ability to selectively filter packets based on the type of layer-2 payload. When such Gont & Liu Expires July 1, 2013 [Page 5] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 functionality is available, IPv6 traffic could be blocked at those layer-2 devices by blocking e.g. Ethernet frames with the Protocol Type field set to 0x86dd [IANA-ETHER]. O: devices by blocking e.g.=20 P: devices by, for example, blocking C: Readability SLAAC-based attacks [RFC3756] can be mitigated with technologies such as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a similar way, DHCPv6-based attacks can be mitigated with technologies such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. However, neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DCHPv6- server messages. Administrators considering the filtering of native IPv6 traffic at layer-3 devices are urged to pay attention to the general considerations for IPv6 traffic filtering discussed in Section 4. If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only get to configure IPv6 link-local addresses. In order to mitigate attacks based on native IPv6 traffic, IPv6 security controls should be enforced on both IPv4 and IPv6 networks. The aforementioned controls might include: deploying IPv6-enabled NIDS, implementing IPv6 firewalling, etc. In some very specific scenarios (e.g., military operations networks) in which only IPv4 service might be desired, a network administrator might want to disable IPv6 support in all the communicating devices. Gont & Liu Expires July 1, 2013 [Page 6] Internet-Draft Sec. Impl. of IPv6 on IPv4 networks December 2012 3. Security Implications of Tunneling Mechanisms Unless properly managed, tunneling mechanisms might result in negative security implications ([RFC6169] describes the security implications of tunneling mechanisms in detail). O: might P: could Of the plethora of tunneling mechanism that have so far been O: mechanism P: mechanisms standardized and widely implemented, the so-called "automatic tunneling" mechanisms (such as Teredo, ISATAP, and 6to4) are of particular interest from a security standpoint, since they might be employed without prior consent or action of the user or network administrator. Therefore, tunneling mechanisms should be a concern not only to network administrators that have consciously deployed them, but also to network and security administrators whose security policies might be bypassed by exploiting these mechanisms. O: , but also [...] mechanisms. P: , but also to those who have not deployed them, as these mechanisms = may bypass their security policies. C: Original was a bit unclear. [CERT2009] contains some examples of how tunnels can be leveraged to bypass firewall rules. The aforementioned issues could be mitigated by applying the common security practice of only allowing traffic deemed as "necessary" (i.e., the so-called "default deny" policy). Thus, when such policy is enforced IPv6 transition/co-existence traffic would be blocked by default, and would only be allowed as a result of an explicit decision (rather than as a result of lack of awareness about such traffic). O: is enforced P: is enforced, O: (rather than as a result of lack of awareness about such traffic) P: delete the above C: redundant; already implied in "explicit." It should be noted that this type of policy is usually enforced at a network that is the target of such traffic (such as an O: at a network P: on a network enterprise network). IPv6 transition traffic should generally never be filtered e.g. by an ISP when it is transit traffic. In those scenarios in which transition/co-existence traffic is meant to be blocked, it is highly recommended that, in addition to the enforcement of filtering policies at the organizational perimeter, the corresponding transition/co-existence mechanisms be disabled on each node connected to the organizational network. This would not only prevent security breaches resulting from accidental use of these mechanisms, but would also disable this functionality altogether, possibly mitigating vulnerabilities that might be present in the host implementation of these transition/co-existence mechanisms. [ End of nits / comments ]=20 >=20 > W >=20 >>=20 >> W >>=20 >>>=20 >>> --Warren, speaking as OpSec WG co-chair >>>=20 >>>=20 >>> --=20 >>> I had no shoes and wept. Then I met a man who had no feet. So I = said, "Hey man, got any shoes you're not using?"=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >>>=20 >>=20 >> -- >> The duke had a mind that ticked like a clock and, like a clock, it = regularly went cuckoo. >>=20 >> -- (Terry Pratchett, Wyrd Sisters) >>=20 >>=20 >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >>=20 >=20 > -- > "Have you got any previous convictions?" >=20 > "Well, I dunno... I suppose I used to believe very firmly that a penny = saved is a penny earned--" > -- Terry Pratchett >=20 >=20 >=20 -- Life is a concentration camp. You're stuck here and there's no way out = and you can only rage impotently against your persecutors. -- Woody Allen From warren@kumari.net Thu Jan 31 11:39:31 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3314921F84D7 for ; Thu, 31 Jan 2013 11:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQkVCO8hEA1c for ; Thu, 31 Jan 2013 11:39:29 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F3121F84C9 for ; Thu, 31 Jan 2013 11:39:26 -0800 (PST) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id DCF0D1B40429; Thu, 31 Jan 2013 14:39:24 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari Date: Thu, 31 Jan 2013 14:39:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "opsec@ietf.org" , "draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org" , opsec chairs X-Mailer: Apple Mail (2.1499) Cc: Warren Kumari Subject: [OPSEC] Fwd: Reminder about IPR relating to draft-ietf-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:39:31 -0000 For some reason this seems to have been eaten by the mailer=85=20 Resending=85 W Begin forwarded message: > From: Warren Kumari > Subject: Reminder about IPR relating to = draft-ietf-opsec-ipv6-implications-on-ipv4-nets=20 > Date: January 24, 2013 12:02:07 PM EST > To: "opsec@ietf.org" , = draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org, opsec = chairs > Cc: Warren Kumari >=20 > Dear OpSec WG, >=20 > Be not alarmed. = =20 > This email was created to satisfy RFC 6702 "Promoting Compliance with = Intellectual Property Rights (IPR)" = (http://tools.ietf.org/rfc/rfc6702.txt). = = =20 >=20 > We are doing the IPR reminder in parallel with the WGLC so that we = have all our ducks in a row... = = =20 >=20 > Are you personally aware of any IPR that applies to = draft-ietf-opsec-ipv6-implications-on-ipv4-nets? If so, has this IPR = been disclosed in compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) >=20 > If you are a document author or listed contributor on this document, = please reply to this email regardless of whether or not you are = personally aware of any relevant IPR. We might not be able to advance = this document to the next stage until we have received a reply from each = author and listed contributor. >=20 > If you are on the OpSec WG email list but are not an author or listed = contributor for this document, you are reminded of your opportunity for = a voluntary IPR disclosure under BCP 79. Please do not reply unless you = want to make such a voluntary disclosure. >=20 > Online tools for filing IPR disclosures can be found at = . >=20 > Thanks, > Warren Kumari > (as OpSec WG co-chair) >=20 > -- > "I think perhaps the most important problem is that we are trying to = understand the fundamental workings of the universe via a language = devised for telling one another when the best fruit is." --Terry = Prachett=20 >=20 >=20 -- "I think perhaps the most important problem is that we are trying to = understand the fundamental workings of the universe via a language = devised for telling one another when the best fruit is." --Terry = Prachett=20 From fgont@si6networks.com Thu Jan 31 16:34:41 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF39B21F89E9 for ; Thu, 31 Jan 2013 16:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w73VPGLqUUMF for ; Thu, 31 Jan 2013 16:34:41 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB0221F89E1 for ; Thu, 31 Jan 2013 16:34:41 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U14a4-0001SC-Cp; Fri, 01 Feb 2013 01:34:14 +0100 Message-ID: <510B0531.10208@si6networks.com> Date: Thu, 31 Jan 2013 20:58:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Warren Kumari References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" , opsec chairs , "draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org" Subject: Re: [OPSEC] Fwd: Reminder about IPR relating to draft-ietf-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 00:34:42 -0000 Folks, As noted below, I'm not aware of any relevant IPR. That said, is it possible/desirable for these questions to be asked/answered off-list? (and then the results posted on list) -- I must admit that the subject kind of scared me into "who the h* filed an IPR on this document?" :-) On 01/31/2013 04:39 PM, Warren Kumari wrote: >> Are you personally aware of any IPR that applies to >> draft-ietf-opsec-ipv6-implications-on-ipv4-nets? No. And I'd be surprised if there was (is that even possible)? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From liushucheng@huawei.com Thu Jan 31 17:02:57 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EFB21F8A61 for ; Thu, 31 Jan 2013 17:02:57 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaKJBY3evPh6 for ; Thu, 31 Jan 2013 17:02:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B5ECD21F8A14 for ; Thu, 31 Jan 2013 17:02:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APH40833; Fri, 01 Feb 2013 01:02:54 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Feb 2013 01:02:11 +0000 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Feb 2013 01:02:53 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.40]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.007; Fri, 1 Feb 2013 09:02:10 +0800 From: "Will Liu (Shucheng)" To: "warren@kumari.net" Thread-Topic: Fwd: Reminder about IPR relating to draft-ietf-opsec-ipv6-implications-on-ipv4-nets Thread-Index: AQHOAAXuVP52Xb/r7kCaQIPgdrQCQphkLm+Q Date: Fri, 1 Feb 2013 01:02:09 +0000 Message-ID: References: <510AF609.5080802@si6networks.com> In-Reply-To: <510AF609.5080802@si6networks.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Fernando Gont , "opsec@ietf.org" Subject: Re: [OPSEC] Fwd: Reminder about IPR relating to draft-ietf-opsec-ipv6-implications-on-ipv4-nets X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 01:02:57 -0000 Hi, Warren, Sorry for being late. I'm personally not aware of any relevant IPR. Thanks.=20 Regards, Will > -------- Original Message -------- > From: Warren Kumari > Date: Thu, 31 Jan 2013 14:39:23 -0500 > Cc: Warren Kumari > Content-Transfer-Encoding: quoted-printable > Message-Id: > References: > To: opsec@ietf.org , > draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org > , opsec > chairs > Subject: Fwd: Reminder about IPR relating to > draft-ietf-opsec-ipv6-implications-on-ipv4-nets >=20 > For some reason this seems to have been eaten by the mailer... >=20 > Resending... >=20 > W >=20 > Begin forwarded message: >=20 > > From: Warren Kumari > > Subject: Reminder about IPR relating to > draft-ietf-opsec-ipv6-implications-on-ipv4-nets > > Date: January 24, 2013 12:02:07 PM EST > > To: "opsec@ietf.org" , > draft-ietf-opsec-ipv6-implications-on-ipv4-nets@tools.ietf.org, opsec cha= irs > > > Cc: Warren Kumari > > > > Dear OpSec WG, > > > > Be not alarmed. > > This email was created to satisfy RFC 6702 "Promoting Compliance with > Intellectual Property Rights (IPR)" (http://tools.ietf.org/rfc/rfc6702.t= xt). > > > > We are doing the IPR reminder in parallel with the WGLC so that we have > all our ducks in a row... > > > > Are you personally aware of any IPR that applies to > draft-ietf-opsec-ipv6-implications-on-ipv4-nets? If so, has this IPR bee= n > disclosed in compliance with IETF IPR rules? > > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > > > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are personall= y > aware of any relevant IPR. We might not be able to advance this document > to the next stage until we have received a reply from each author and lis= ted > contributor. > > > > If you are on the OpSec WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity for a > voluntary IPR disclosure under BCP 79. Please do not reply unless you wa= nt > to make such a voluntary disclosure. > > > > Online tools for filing IPR disclosures can be found at > . > > > > Thanks, > > Warren Kumari > > (as OpSec WG co-chair) > > > > -- > > "I think perhaps the most important problem is that we are trying to > understand the fundamental workings of the universe via a language devise= d > for telling one another when the best fruit is." --Terry Prachett > > > > >=20 > -- > "I think perhaps the most important problem is that we are trying to > understand the fundamental workings of the universe via a language > devised for telling one another when the best fruit is." --Terry Prachett >=20 >=20 >=20 >=20 From fgont@si6networks.com Thu Jan 31 23:03:10 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33C721F88BD for ; Thu, 31 Jan 2013 23:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTD8h-Z+WZGV for ; Thu, 31 Jan 2013 23:03:10 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id D573821F88BE for ; Thu, 31 Jan 2013 23:03:09 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U1Adx-0004E8-Cq; Fri, 01 Feb 2013 08:03:02 +0100 Message-ID: <510B6886.30005@si6networks.com> Date: Fri, 01 Feb 2013 04:02:30 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Warren Kumari References: <0DF8F7D8-01EF-44AC-9ABB-A48D7E4855FC@kumari.net> <99E981C1-88DA-4BED-9E1C-8914BB271223@kumari.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: opsec@ietf.org, opsec chairs Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 07:03:10 -0000 Hi, Warren, Thanks so much for your feedback! -- Please find my comments in-line... On 01/31/2013 01:36 PM, Warren Kumari wrote: > And hare are a chunk more comments. These are just nits / readability > bits… > > On a slightly more substantive note, I also think that the reference > to military networks is unneeded / not helpful. The only reason for which it was added is because the text just preceding it essentially claims that "blocking transition technologies should only be considered a short-term strategy" (but that doesn't hold true for some networks). To be honest, I wouldn't waste anyone's energy on this one :-), and could just remove such note if the wg thinks that's the best way forward. (As a matter of personal taste, I'd remove any wording of short-term vs. longer-term strategies, or note in which cases (such as military networks) blocking this stuff might be seen as a longer term thing). Input is certainly welcome! [I've removed all the readability bits that I'll apply "as suggested"] > o A Network Intrusion Detection System (NIDS) might be prepared to > detect attack patterns for IPv4 traffic, but might be unable to > detect the same attack patterns when a transition/co-existence > technology is leveraged for that purpose. > > O: might be prepared [...] might be unable P: may be prepared [...] > but may not be able Some native-English-speaking folk advised me to phrase the text as suggested, noting that "may" implies "permission", rather than "probability" (FWIW, I studied this a looong time :-) ago, and I'm not sure I could tell the difference). > o An IPv4 firewall might enforce a specific security policy in > IPv4, but might be unable to enforce the same policy in IPv6. > > O: might (twice) P: may (twice) Same as above -- please double-check... > o Some transition/co-existence mechanisms might cause an internal > host with otherwise limited IPv4 connectivity to become globally > reachable over IPv6, therefore resulting in increased (and possibly > unexpected) host exposure. > > O: might P: could Fixed. > Some transition/co-existence mechanisms (notably Teredo) are designed > to traverse Network Address Port Translation (NAPT) [RFC2663] > devices, allowing incoming IPv6 connections from the Internet to > hosts behind the organizational firewall or NAPT (which in many > deployments provides a minimum level of protection by only allowing > those instances of communication that have been initiated from the > internal network). > > O: or NAPT (which in many deployments P: or NAPT. (In many > deployments, this Is it okay to have a full sentece within parenthesis? > o IPv6 support might, either inadvertently or as a result of a > deliberate attack, result in VPN traffic leaks if IPv6-unaware > Virtual Private Network (VPN) software is employed by dual-stacked > hosts [I-D.ietf-opsec-vpn-leakages]. > > O: might P: could Fixed. > In general, most of the aforementioned security implications can be > mitigated by enforcing security controls on native IPv6 traffic and > on IPv4-tunneled traffic. Among such controls is the enforcement of > filtering policies, such that undesirable traffic is blocked. While > > O: , such that undesirable traffic is blocked. P: to block > undesirable traffic. Fixed. > This document discusses the security implications of IPv6 and IPv6 > transition/co-existence technologies on (allegedly) IPv4-only > networks, and provides guidance on how to mitigate the > aforementioned issues. > > O: This document discusses the security implications of IPv6 and > IPv6 transition/co-existence technologies on (allegedly) IPv4-only > networks, and provides guidance on how to mitigate the > aforementioned issues. P: Delete above paragraph C: Already in the > abstract; not sure why it is here as well? Common practice of producing the abstract from the Intro? :-) > 2. Security Implications of Native IPv6 Support > > Most popular operating systems include IPv6 support that is enabled > by default. This means that even if a network is expected to be > IPv4-only, much of its infrastructure is nevertheless likely to be > IPv6 enabled. For example, hosts are likely to have at least link- > local IPv6 connectivity which might be exploited by attackers with > access to the local network. > > [CORE2007] is a security advisory about a buffer overflow which could > be remotely-exploited by leveraging link-local IPv6 connectivity that > is enabled by default. > > Additionally, unless appropriate measures are taken, an attacker > with access to an 'IPv4-only' local network could impersonate a > local router and cause local hosts to enable their 'non-link-local' > IPv6 connectivity (e.g. by sending Router Advertisement messages), > possibly circumventing security controls that were enforced only on > IPv4 communications. > > [THC-IPV6] is the first publicly-available toolkit that implemented > this attack vector (along with many others). > > [IPv6-Toolkit] is a fully-featured trouble-shooting and security > assessment tool that implements this attack vector (along with many > others). > > [Waters2011] provides an example of how this could be achieved using > publicly available tools (besides incorrectly claiming the discovery > of a "0day vulnerability"). > > Native IPv6 support could also possibly lead to VPN traffic leakages > when hosts employ VPN software that not only does not support IPv6, > but that does nothing about IPv6 traffic. > > O: about IPv6 traffic. P: with IPv6 traffic, instead allowing that to > bypass the VPN. C: Not sure if this is what is meant? What I meant is that is not just that they cannot tunnel v6 traffic, but that they also don't even bother to block it. Should we s/about/with/, or keep it "as is"? Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492