From iesg-secretary@ietf.org Mon Dec 2 04:53:49 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62BF1AE41C; Mon, 2 Dec 2013 04:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbaFQ6Kzq34V; Mon, 2 Dec 2013 04:53:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C111ADEB7; Mon, 2 Dec 2013 04:53:48 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> Date: Mon, 02 Dec 2013 04:53:48 -0800 Cc: opsec@ietf.org Subject: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 12:53:50 -0000 The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-12-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear from the local network to the final destination. This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. Additionally, it discusses possible mitigations for the aforementioned issue. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Mon Dec 2 05:49:37 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42B91AE483; Mon, 2 Dec 2013 05:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag1mncz37WEY; Mon, 2 Dec 2013 05:49:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 862D21AE47D; Mon, 2 Dec 2013 05:49:36 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131202134936.24876.26322.idtracker@ietfa.amsl.com> Date: Mon, 02 Dec 2013 05:49:36 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:49:38 -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 : Using Only Link-Local Addressing Inside an IPv6 Network Author(s) : Michael Behringer Eric Vyncke Filename : draft-ietf-opsec-lla-only-05.txt Pages : 10 Date : 2013-12-02 Abstract: In an IPv6 network it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to help the decision process for a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-only-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbehring@cisco.com Mon Dec 2 05:53:27 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB2C1ADF8D for ; Mon, 2 Dec 2013 05:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-AE1QTOf7l8 for ; Mon, 2 Dec 2013 05:53:26 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id EABAE1AE22A for ; Mon, 2 Dec 2013 05:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=629; q=dns/txt; s=iport; t=1385992403; x=1387202003; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=fkuyRvCXedq2KJetA1iElC9p3rpJ+apO8sW5gcnogxY=; b=Uov3qq35WQo5+ZbgH7Nsvpe6Zt76n8lnRoykZuB5hXZj3RLf+ros25z1 7WcWqdR2Osw6PdvsexuyuIVRBiM/TLPeFiJQGMHL3cCytyrSQKPGXrsvr piA6DzCWVtpgyS39EwCsM9V7NOwmNtvIr4007D5fYrWPwutalg+7E0rhd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwPABmQnFKtJXHB/2dsb2JhbABZgwc4TQa4XQICgSQWbQeCJwEEOlEBKhRCJgEEGwGHeAgFoE+fHReOV4NYgRMDmUSQY4Mpgio X-IronPort-AV: E=Sophos;i="4.93,811,1378857600"; d="scan'208";a="3633710" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-4.cisco.com with ESMTP; 02 Dec 2013 13:53:23 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB2DrNvm028366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Dec 2013 13:53:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 07:53:23 -0600 From: "Michael Behringer (mbehring)" To: "opsec@ietf.org" Thread-Topic: Version 5 of draft-ietf-opsec-lla-only Thread-Index: Ac7vZWsG6LrbWv6mTRyEnuDbbfaISQ== Date: Mon, 2 Dec 2013 13:53:22 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FD60F@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSEC] Version 5 of draft-ietf-opsec-lla-only X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:53:27 -0000 OPsec WG,=20 Eric and I worked through the reviews we got on the WGLC (see Eric's emails= last week).=20 Version 04 includes WGLC reviews from:=20 - Wes George - Fernando Gont - Rama Darbha Version 05 includes now the reviews from: - Bill Cerveny - Jen Linkova Version 5 is now posted.=20 Htmlized: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-05 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-on= ly-05 Chairs, could you please indicate whether you would like to see more review= s, or whether we're good to advance this draft?=20 Thanks, Eric and Michael From warren@kumari.net Tue Dec 3 09:22:01 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414611ACCE8 for ; Tue, 3 Dec 2013 09:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz2fYIjvqFY9 for ; Tue, 3 Dec 2013 09:21:59 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F11C1AC499 for ; Tue, 3 Dec 2013 09:21:59 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id DB70C1B40525; Tue, 3 Dec 2013 12:21:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FD60F@xmb-rcd-x14.cisco.com> Date: Tue, 3 Dec 2013 12:21:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FD60F@xmb-rcd-x14.cisco.com> To: Michael Behringer (mbehring) X-Mailer: Apple Mail (2.1510) Cc: "opsec@ietf.org" , Warren Kumari Subject: Re: [OPSEC] Version 5 of draft-ietf-opsec-lla-only X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:22:01 -0000 On Dec 2, 2013, at 8:53 AM, Michael Behringer (mbehring) = wrote: > OPsec WG,=20 >=20 > Eric and I worked through the reviews we got on the WGLC (see Eric's = emails last week).=20 >=20 > Version 04 includes WGLC reviews from:=20 > - Wes George > - Fernando Gont > - Rama Darbha >=20 > Version 05 includes now the reviews from: > - Bill Cerveny > - Jen Linkova >=20 > Version 5 is now posted.=20 > Htmlized: = http://tools.ietf.org/html/draft-ietf-opsec-lla-only-05 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-only-05 >=20 > Chairs, could you please indicate whether you would like to see more = reviews, At the meeting Fernando, Ron, Jen, Andrew Y. and Bill Cerveny agreed to = review. Fernando, Jen and Bill have submitted reviews -- Ron and Andrew, can you = please get yours in? > or whether we're good to advance this draft?=20 We should be meeting / chatting tomorrow morning and will discuss this.=20= W >=20 > Thanks, > Eric and Michael >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --=20 "Does Emacs have the Buddha nature? Why not? It has bloody well = everything else..." From rbonica@juniper.net Tue Dec 3 10:54:59 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887C11AE14F for ; Tue, 3 Dec 2013 10:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRdjbmf7IdlH for ; Tue, 3 Dec 2013 10:54:57 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id ABECD1AD34C for ; Tue, 3 Dec 2013 10:54:54 -0800 (PST) Received: from mail169-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Dec 2013 18:54:51 +0000 Received: from mail169-va3 (localhost [127.0.0.1]) by mail169-va3-R.bigfish.com (Postfix) with ESMTP id 9280B2201A0 for ; Tue, 3 Dec 2013 18:54:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz8275dh1de097h18602ehz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail169-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(65816001)(2656002)(54316002)(74706001)(77982001)(80022001)(81542001)(74366001)(74316001)(87936001)(66066001)(15974865002)(85306002)(63696002)(79102001)(59766001)(76176001)(81342001)(87266001)(56776001)(83072001)(47976001)(50986001)(49866001)(47736001)(31966008)(4396001)(81686001)(33646001)(19580395003)(77096001)(80976001)(47446002)(54356001)(46102001)(76482001)(76796001)(69226001)(76786001)(76576001)(53806001)(74662001)(74876001)(74502001)(51856001)(81816001)(83322001)(56816005)(90146001)(85852002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail169-va3 (localhost.localdomain [127.0.0.1]) by mail169-va3 (MessageSwitch) id 138609689058844_20780; Tue, 3 Dec 2013 18:54:50 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.245]) by mail169-va3.bigfish.com (Postfix) with ESMTP id E5317160078 for ; Tue, 3 Dec 2013 18:54:49 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Dec 2013 18:54:48 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Tue, 3 Dec 2013 18:54:47 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.825.14; Tue, 3 Dec 2013 18:54:45 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Tue, 3 Dec 2013 18:54:45 +0000 From: Ronald Bonica To: "opsec@ietf.org" Thread-Topic: Review of draft-ietf-opsec-lla-only-05 Thread-Index: Ac7wWSDptQScqWK/Td6betnie2vjoQ== Date: Tue, 3 Dec 2013 18:54:44 +0000 Message-ID: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0049B3F387 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:54:59 -0000 Folks, Reading through Sections 2.2 and 2.3 of this document, I question whether t= he benefits of numbering router interfaces from link-local address space ac= tually outweigh the cost. The document lists the following as benefits: 1) Smaller routing tables 2) Simpler address management 3) Lower configuration complexity 4) Simpler DNS 5) Reduced attack surface IMHO, advantages 1, 2 and 3 are dubious. In this draft, we consider numberi= ng router-to-router interfaces from link-local space. In a large network, t= he number of router-to-router interfaces is dwarfed by the total number of = interfaces. So, numbering router-to-router interfaces reduces the magnitude= of some problems, but not by a significant amount. Advantage #5 also is dubious. If you think of an address as being "the atta= ck surface" of a router, then numbering selected interfaces from link-local= reduces the attack surface. But miscreants don't attack addresses. They at= tack the resource that an address represents. Since all of those resources = are accessible using the box's globally routable loopback address, numberin= g some interfaces from link-local really doesn't reduce the attack surface. I realize that this may not be the kind of review that you want. So, I am h= appy to be told that mine is the minority opinion. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From rdobbins@arbor.net Tue Dec 3 17:47:59 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1151ADF92 for ; Tue, 3 Dec 2013 17:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPZmCwNDUsyG for ; Tue, 3 Dec 2013 17:47:57 -0800 (PST) Received: from gwo3.mbox.net (gwo3.mbox.net [165.212.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id CB0331ADF7E for ; Tue, 3 Dec 2013 17:47:57 -0800 (PST) Received: from gwo3.mbox.net (localhost [127.0.0.1]) by gwo3.mbox.net (Postfix) with ESMTP id 3dZ2y26fckzfk8wM for ; Wed, 4 Dec 2013 01:47:54 +0000 (UTC) X-USANET-Received: from gwo3.mbox.net [127.0.0.1] by gwo3.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 868RLDBv24848Mo3; Wed, 04 Dec 2013 01:47:53 -0000 X-USANET-GWS2-Tagid: UNKN Received: from S1P5HUB6.EXCHPROD.USA.NET [165.212.120.254] by gwo3.mbox.net via smtad (C8.MAIN.3.93K) with ESMTPS id XID272RLDBv22619Xo3; Wed, 04 Dec 2013 01:47:53 -0000 X-USANET-Source: 165.212.120.254 OUT rdobbins@arbor.net S1P5HUB6.EXCHPROD.USA.NET X-USANET-MsgId: XID272RLDBv22619Xo3 Received: from S1P5DAG6A.EXCHPROD.USA.NET ([169.254.1.197]) by S1P5HUB6.EXCHPROD.USA.NET ([10.120.223.36]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 01:47:52 +0000 From: "Dobbins, Roland" To: "opsec@ietf.org" Thread-Topic: [OPSEC] Review of draft-ietf-opsec-lla-only-05 Thread-Index: Ac7wWSDptQScqWK/Td6betnie2vjoQAObcUA Date: Wed, 4 Dec 2013 01:47:52 +0000 Message-ID: <9A2B514E-613F-4837-9B56-23B020508C1B@arbor.net> References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.176.81.112] Content-Type: text/plain; charset="us-ascii" Content-ID: <88E9667CE4C5FC48BD4FC4F6FD876C2B@EXCHPROD.USA.NET> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 01:48:00 -0000 On Dec 4, 2013, at 1:54 AM, Ronald Bonica wrote: > I question whether the benefits of numbering router interfaces from link-= local address space actually outweigh the cost. I'd be very interested to hear the view of the authors on how this differs = in effect from numbering IPv4 router interfaces from RFC1918 spaces, and th= e operational issues which arise from doing so. =20 While link-local addresses are generally unique, we should consider the exp= erience to date in dealing with privately-addressed router interfaces on th= e public Internet, and determine whether the benefits of doing something si= milar with IPv6 outweigh the possible negatives. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mbehring@cisco.com Wed Dec 4 00:59:35 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAF61AE09A for ; Wed, 4 Dec 2013 00:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtH1NYnhUOwr for ; Wed, 4 Dec 2013 00:59:31 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id A15D81ADFFF for ; Wed, 4 Dec 2013 00:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3372; q=dns/txt; s=iport; t=1386147569; x=1387357169; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6btWxwk2bNfHW+zWAGjL+m/M/WnKIbgwLwa0oZxyUSY=; b=ECiFZ9sLUTJe4mQiY4JqOi8QQIBtSC5wGIcB0VlRtumGgDu0CaGi1xJB O3tzOWLUKEOuIJamm+KgHVCQ0YmlPFpFetBYid8Yi3mXLDSd73xSNDXnc gjFARCjCTgI0vGEbR0EMG7PYRhmd93+6nygOwZ2+bkq2MnPXlSjGe6hnj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FABzunlKtJV2Z/2dsb2JhbABagwc4U7hogR4WdIIlAQEBBAEBATcPJQYRBAIBCA4DBAEBCxQJBycLFAkIAQEEARIIARCHaQ3BIBeOTTgGgxqBEwOqJ4Mpgio X-IronPort-AV: E=Sophos;i="4.93,823,1378857600"; d="scan'208";a="4201695" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 04 Dec 2013 08:59:28 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB48xSdX007006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 08:59:28 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 02:59:27 -0600 From: "Michael Behringer (mbehring)" To: Ronald Bonica , "opsec@ietf.org" Thread-Topic: Review of draft-ietf-opsec-lla-only-05 Thread-Index: Ac7wWSDptQScqWK/Td6betnie2vjoQAdI4tQ Date: Wed, 4 Dec 2013 08:59:27 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB4B@xmb-rcd-x14.cisco.com> References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:59:35 -0000 Ron,=20 When we started this work we wanted to make a recommendation, because we be= lieve that there are advantages in the approach. Quite early it has become = clear that there is no consensus in the IETF on whether the link local appr= oach actually makes life simpler or not. Some people say it doesn't, some p= eople say it does.=20 So the agreement at the time was to list, factually, without any weighing o= f judgement, the technical aspects, pros and cons. This is what we're tryin= g to do.=20 We have removed all "recommend" and similar phrases. (Thanks to our reviewe= rs, who kept us honest here).=20 The idea is that a network operator has easy access to all the aspects to c= onsider, potential advantages, and caveats. And this operator should now be= able to say for his network: this advantage doesn't make much difference t= o me; the other one does. This caveat does apply to me, the other one not. = And you're making those calls below; my point would be: We've seen in the e= arly stages of this draft that it's hard to get global consensus on those.= =20 So I suggest we keep the document factual, and let operators make their own= choices. This is what the document should achieve. It should not make a ju= dgement on the value of any aspects, because those would be context-depende= nt.=20 My question is: Is the document in any place not factual? Or missing facts?= If so, please let us know - that should be fixed! Michael > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Ronald Bonica > Sent: 03 December 2013 19:55 > To: opsec@ietf.org > Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-05 >=20 > Folks, >=20 > Reading through Sections 2.2 and 2.3 of this document, I question whether > the benefits of numbering router interfaces from link-local address space > actually outweigh the cost. The document lists the following as benefits: >=20 > 1) Smaller routing tables > 2) Simpler address management > 3) Lower configuration complexity > 4) Simpler DNS > 5) Reduced attack surface >=20 > IMHO, advantages 1, 2 and 3 are dubious. In this draft, we consider > numbering router-to-router interfaces from link-local space. In a large > network, the number of router-to-router interfaces is dwarfed by the tota= l > number of interfaces. So, numbering router-to-router interfaces reduces > the magnitude of some problems, but not by a significant amount. >=20 > Advantage #5 also is dubious. If you think of an address as being "the at= tack > surface" of a router, then numbering selected interfaces from link-local > reduces the attack surface. But miscreants don't attack addresses. They > attack the resource that an address represents. Since all of those resour= ces > are accessible using the box's globally routable loopback address, > numbering some interfaces from link-local really doesn't reduce the attac= k > surface. >=20 > I realize that this may not be the kind of review that you want. So, I am > happy to be told that mine is the minority opinion. >=20 > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From gert@space.net Wed Dec 4 01:06:26 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36A91AE1D3 for ; Wed, 4 Dec 2013 01:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_tCII8ARqHn for ; Wed, 4 Dec 2013 01:06:24 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id E34D81AE0D0 for ; Wed, 4 Dec 2013 01:06:23 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E725060B10 for ; Wed, 4 Dec 2013 10:06:18 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id BAF95608C7 for ; Wed, 4 Dec 2013 10:06:18 +0100 (CET) Received: (qmail 26957 invoked by uid 1007); 4 Dec 2013 10:06:18 +0100 Date: Wed, 4 Dec 2013 10:06:18 +0100 From: Gert Doering To: "Michael Behringer \(mbehring\)" Message-ID: <20131204090618.GU81676@Space.Net> References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB4B@xmb-rcd-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB4B@xmb-rcd-x14.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 09:06:26 -0000 Hi, On Wed, Dec 04, 2013 at 08:59:27AM +0000, Michael Behringer (mbehring) wrote: > So the agreement at the time was to list, factually, without any weighing of judgement, the technical aspects, pros and cons. This is what we're trying to do. ... and this I support :-) - even if I'm in the "I don't like this approach" camp. > So I suggest we keep the document factual, and let operators make their own choices. This is what the document should achieve. It should not make a judgement on the value of any aspects, because those would be context-dependent. +1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From mbehring@cisco.com Wed Dec 4 01:07:01 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5021AE219 for ; Wed, 4 Dec 2013 01:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhcLMEhmKq-F for ; Wed, 4 Dec 2013 01:06:58 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id A85A61AE217 for ; Wed, 4 Dec 2013 01:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1882; q=dns/txt; s=iport; t=1386148016; x=1387357616; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=b3b742hElEUH/3TWqaHhSHSpHIZmM6FZ/RwcDduTG6s=; b=nEczm0KgWcb3dWikZkHDBkE46zVFVK1BJirkbY7F4LkOeFjLh2/iSlDH GnHH4DNziiAIRhGBBq19j3lBh6tbTv84wy3pg47MIJgeWH98n2C9O8F1w 2yqW2iv+ZlZv3AOC+J2Tco0drFpkTllOiO6XWGp8NF7zfAbZShOANhDc8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAGnwnlKtJXG+/2dsb2JhbABagwc4U7hogR4WdIIlAQEBAwEBAQE3NBAHBAIBCBEEAQEBChQJBycLFAkIAQEEARIIh3QGDcEYF45NOAaDGoETA6ongymCKg X-IronPort-AV: E=Sophos;i="4.93,823,1378857600"; d="scan'208";a="4195075" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 04 Dec 2013 09:06:55 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB496tRc008362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 09:06:55 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 03:06:55 -0600 From: "Michael Behringer (mbehring)" To: "Dobbins, Roland" , "opsec@ietf.org" Thread-Topic: [OPSEC] Review of draft-ietf-opsec-lla-only-05 Thread-Index: Ac7wWSDptQScqWK/Td6betnie2vjoQAObcUAAA8TlRA= Date: Wed, 4 Dec 2013 09:06:54 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB77@xmb-rcd-x14.cisco.com> References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> <9A2B514E-613F-4837-9B56-23B020508C1B@arbor.net> In-Reply-To: <9A2B514E-613F-4837-9B56-23B020508C1B@arbor.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 09:07:01 -0000 > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Dobbins, > Roland > Sent: 04 December 2013 02:48 > To: opsec@ietf.org > Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 >=20 >=20 > On Dec 4, 2013, at 1:54 AM, Ronald Bonica wrote: >=20 > > I question whether the benefits of numbering router interfaces from lin= k- > local address space actually outweigh the cost. >=20 > I'd be very interested to hear the view of the authors on how this differ= s in > effect from numbering IPv4 router interfaces from RFC1918 spaces, and the > operational issues which arise from doing so. Roland, in short: We're not addressing RFC1918 in this doc. It's outside sc= ope.=20 > While link-local addresses are generally unique, we should consider the > experience to date in dealing with privately-addressed router interfaces = on > the public Internet, and determine whether the benefits of doing > something similar with IPv6 outweigh the possible negatives. The 1918 method is different. It would be an interesting discussion to have= , in another document. =20 For the LLA approach, we were told in no uncertain terms that we should NOT= make a judgement, but just list the facts to consider. That's what we trie= d to do. Each operator should be able to take those and make his judgement.= =20 Please let us know where we're not factual or misleading - that needs fixin= g.=20 Michael > ----------------------------------------------------------------------- > Roland Dobbins // > >=20 > Luck is the residue of opportunity and design. >=20 > -- John Milton >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From robbird@gmail.com Wed Dec 4 01:12:09 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8354A1ADF7C for ; Wed, 4 Dec 2013 01:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V07iV2MHvJ4c for ; Wed, 4 Dec 2013 01:12:07 -0800 (PST) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 79F3D1ADF73 for ; Wed, 4 Dec 2013 01:12:07 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id nc12so14153197qeb.26 for ; Wed, 04 Dec 2013 01:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=xm8aP42QIT9npbYSfIHGPOXWWfN9yLemimQRANZE4OA=; b=uho/oOXHJFWGPrhiYcyieAbTiYslltUBYhOvTLKCl/uh60QVoIkMYY3CfNP3mS62qq A0pTw95eXszlYHbsldM80NtJGpVKCmeYtv22maHfcQuY6P/XZrYdcui6JgZGk4Tz11hg Qib94GhbIcY0jUshFO875Q1sSRFukC+BQXjce8NDR0bPxeFmnmF2EDpcmOMI+OOyHDol oEUO1TLZOt0lOQd7hg0rju+H37BYonqDlIZFbnG3vpmnj2PPGYHj+sDcuT2L8ScWpGED 0bVvu/Mzjt5t51INTMBgwzccnVl3YCR7+B9DuTN4OgQ21a0hcIXFFDMuJZewq+68OGDz ckhw== X-Received: by 10.229.185.6 with SMTP id cm6mr80602168qcb.10.1386148324357; Wed, 04 Dec 2013 01:12:04 -0800 (PST) Received: from [192.168.1.106] ([50.55.57.72]) by mx.google.com with ESMTPSA id f19sm4845716qaq.12.2013.12.04.01.12.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 01:12:03 -0800 (PST) References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB4B@xmb-rcd-x14.cisco.com> <20131204090618.GU81676@Space.Net> Mime-Version: 1.0 (1.0) In-Reply-To: <20131204090618.GU81676@Space.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <01DD44FD-83AD-40F3-9AD9-47CAFBA3A282@gmail.com> X-Mailer: iPad Mail (11B511) From: Rob Bird Date: Wed, 4 Dec 2013 04:12:04 -0500 To: Gert Doering Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 09:12:09 -0000 Well put! > On Dec 4, 2013, at 4:06 AM, Gert Doering wrote: >=20 > Hi, >=20 >> On Wed, Dec 04, 2013 at 08:59:27AM +0000, Michael Behringer (mbehring) wr= ote: >> So the agreement at the time was to list, factually, without any weighing= of judgement, the technical aspects, pros and cons. This is what we're tryi= ng to do.=20 >=20 > ... and this I support :-) - even if I'm in the "I don't like this approac= h" > camp. >=20 >> So I suggest we keep the document factual, and let operators make their o= wn choices. This is what the document should achieve. It should not make a j= udgement on the value of any aspects, because those would be context-depende= nt.=20 >=20 > +1 >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culeman= n > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From rbonica@juniper.net Wed Dec 4 07:03:58 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120AA1AE159 for ; Wed, 4 Dec 2013 07:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExQANO3U9rM0 for ; Wed, 4 Dec 2013 07:03:55 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4B38E1AE08F for ; Wed, 4 Dec 2013 07:03:55 -0800 (PST) Received: from mail96-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 15:03:51 +0000 Received: from mail96-am1 (localhost [127.0.0.1]) by mail96-am1-R.bigfish.com (Postfix) with ESMTP id ABFCB12007B; Wed, 4 Dec 2013 15:03:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068h18602ehz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail96-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(51704005)(377454003)(13464003)(4396001)(2656002)(47736001)(87266001)(54316002)(85306002)(80976001)(74662001)(74366001)(15975445006)(15974865002)(85852002)(81342001)(56776001)(77982001)(59766001)(69226001)(19580395003)(50986001)(47976001)(49866001)(76796001)(87936001)(81816001)(46102001)(33646001)(77096001)(66066001)(80022001)(76482001)(74316001)(54356001)(74876001)(79102001)(19580405001)(83072001)(81542001)(83322001)(31966008)(74502001)(63696002)(81686001)(76576001)(51856001)(47446002)(76786001)(65816001)(74706001)(53806001)(90146001)(56816005)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail96-am1 (localhost.localdomain [127.0.0.1]) by mail96-am1 (MessageSwitch) id 1386169430416499_31107; Wed, 4 Dec 2013 15:03:50 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.252]) by mail96-am1.bigfish.com (Postfix) with ESMTP id 621033A004D; Wed, 4 Dec 2013 15:03:50 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 15:03:49 +0000 Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 15:03:48 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.825.14; Wed, 4 Dec 2013 15:03:46 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Wed, 4 Dec 2013 15:03:45 +0000 From: Ronald Bonica To: "Michael Behringer (mbehring)" , "opsec@ietf.org" Thread-Topic: Review of draft-ietf-opsec-lla-only-05 Thread-Index: Ac7wWSDptQScqWK/Td6betnie2vjoQAdI4tQAAzt6RA= Date: Wed, 4 Dec 2013 15:03:45 +0000 Message-ID: References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB4B@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB4B@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0050CEFE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:03:58 -0000 Hi Michael, I realize that I am in the rough on this one and would be happy to back off= .=20 But before I do that, could you respond to my question regarding whether nu= mbering router-to-router interfaces from link-local really reduces the atta= ck surface of a router? After all, every resource that is vulnerable to att= ack when numbered from global address space is also vulnerable when numbere= d from link-local address space. You haven't reduced the number of vulnerab= le interfaces, only the number and specificity of the addresses by which th= ey can be addressed. Ron > -----Original Message----- > From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] > Sent: Wednesday, December 04, 2013 3:59 AM > To: Ronald Bonica; opsec@ietf.org > Subject: RE: Review of draft-ietf-opsec-lla-only-05 >=20 > Ron, >=20 > When we started this work we wanted to make a recommendation, because > we believe that there are advantages in the approach. Quite early it > has become clear that there is no consensus in the IETF on whether the > link local approach actually makes life simpler or not. Some people say > it doesn't, some people say it does. >=20 > So the agreement at the time was to list, factually, without any > weighing of judgement, the technical aspects, pros and cons. This is > what we're trying to do. >=20 > We have removed all "recommend" and similar phrases. (Thanks to our > reviewers, who kept us honest here). >=20 > The idea is that a network operator has easy access to all the aspects > to consider, potential advantages, and caveats. And this operator > should now be able to say for his network: this advantage doesn't make > much difference to me; the other one does. This caveat does apply to > me, the other one not. And you're making those calls below; my point > would be: We've seen in the early stages of this draft that it's hard > to get global consensus on those. >=20 > So I suggest we keep the document factual, and let operators make their > own choices. This is what the document should achieve. It should not > make a judgement on the value of any aspects, because those would be > context-dependent. >=20 > My question is: Is the document in any place not factual? Or missing > facts? If so, please let us know - that should be fixed! >=20 > Michael >=20 > > -----Original Message----- > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Ronald > Bonica > > Sent: 03 December 2013 19:55 > > To: opsec@ietf.org > > Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-05 > > > > Folks, > > > > Reading through Sections 2.2 and 2.3 of this document, I question > > whether the benefits of numbering router interfaces from link-local > > address space actually outweigh the cost. The document lists the > following as benefits: > > > > 1) Smaller routing tables > > 2) Simpler address management > > 3) Lower configuration complexity > > 4) Simpler DNS > > 5) Reduced attack surface > > > > IMHO, advantages 1, 2 and 3 are dubious. In this draft, we consider > > numbering router-to-router interfaces from link-local space. In a > > large network, the number of router-to-router interfaces is dwarfed > by > > the total number of interfaces. So, numbering router-to-router > > interfaces reduces the magnitude of some problems, but not by a > significant amount. > > > > Advantage #5 also is dubious. If you think of an address as being > "the > > attack surface" of a router, then numbering selected interfaces from > > link-local reduces the attack surface. But miscreants don't attack > > addresses. They attack the resource that an address represents. Since > > all of those resources are accessible using the box's globally > > routable loopback address, numbering some interfaces from link-local > > really doesn't reduce the attack surface. > > > > I realize that this may not be the kind of review that you want. So, > I > > am happy to be told that mine is the minority opinion. > > > > -------------------------- > > Ron Bonica > > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec >=20 From mbehring@cisco.com Wed Dec 4 09:06:33 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25691AE2E2 for ; Wed, 4 Dec 2013 09:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1Y35BDnw5Dm for ; Wed, 4 Dec 2013 09:06:31 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4871AE2DE for ; Wed, 4 Dec 2013 09:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6617; q=dns/txt; s=iport; t=1386176788; x=1387386388; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3V8hBxcjCooG7dJy7514TZzIP0dm12KLagg8DCBkLm8=; b=Xy6hr56hk0U6GqP/f2zEFIpxdMnKCLGfkObsqZKmuYKI3b8eEZkeN80k MMRF9ZGRFJ6LPPeUNGERbQ2gDDDCwynr7piZoDv1DmxIWeIokeNdOo+bG Thc0AjNbTF4w52InXI8Cit9JYy/RiRuzN4FvcumU3tV9cj/sX8pFpsEN8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAL9fn1KtJV2Y/2dsb2JhbABagwc4U7hjgSMWdIIlAQEBAwEBAQE3DyMCBgIIBwQCAQgOAwQBAQsOBgkHJwsUCQgBAQQBEggBEIdjBg3BaBeOTTgGEoMIgRMDmUSQY4Mpgio X-IronPort-AV: E=Sophos;i="4.93,825,1378857600"; d="scan'208";a="289317706" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 04 Dec 2013 17:06:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB4H6SIN029056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 17:06:28 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 11:06:27 -0600 From: "Michael Behringer (mbehring)" To: Ronald Bonica , "opsec@ietf.org" Thread-Topic: Review of draft-ietf-opsec-lla-only-05 Thread-Index: Ac7wWSDptQScqWK/Td6betnie2vjoQAdI4tQAAzt6RAAA9xMMA== Date: Wed, 4 Dec 2013 17:06:27 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D902CB2@xmb-rcd-x14.cisco.com> References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB4B@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:06:34 -0000 > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: 04 December 2013 16:04 > To: Michael Behringer (mbehring); opsec@ietf.org > Subject: RE: Review of draft-ietf-opsec-lla-only-05 >=20 > Hi Michael, >=20 > I realize that I am in the rough on this one and would be happy to back o= ff. This is about clarity, and a good discussion. Thanks! We want this draft to= be factually correct and clear.=20 > But before I do that, could you respond to my question regarding whether > numbering router-to-router interfaces from link-local really reduces the > attack surface of a router? After all, every resource that is vulnerable = to > attack when numbered from global address space is also vulnerable when > numbered from link-local address space. You haven't reduced the number > of vulnerable interfaces, only the number and specificity of the addresse= s > by which they can be addressed. That is strictly speaking correct. An interface doesn't become un-vulnerabl= e because it uses a link-local address. But a link local address can only b= e reached (and therefore attacked) from the link. That significantly reduce= s the exposure of that address, and this is a recognised concept:=20 http://tools.ietf.org/html/rfc5082 (GTSM) states in section 5.3 clearly tha= t on-link attacks are possible, yet I think there is consensus that there i= s value in reducing the attack horizon.=20 So yes, link local reduces the number of addresses a device can be reached = by. We try to be clear in section 2.2:=20 " Reduced attack surface: Every routable address on a router constitutes a po= tential attack point: a remote attacker can send traffic to that address. E= xamples are a TCP SYN flood (see [RFC4987]), or SSH brute force password at= tacks. If a network only uses the addresses of the router loopback interfac= e(s), only those addresses need to be protected from outside the network. T= his may ease protection measures, such as infrastructure access control lis= ts. " Note we're talking about addresses, not interfaces (as you point out). Re-r= eading this paragraph, I still think it's factually correct.=20 Now, as Gert has pointed out previously, if you address your entire core ad= dress space (loopbacks and interface addresses) out of the same supernet, a= nd if you have iACLs at the edge blocking that supernet, you don't gain on = this point. If you address them out of different blocks, your life becomes = slightly easier. So it depends on your deployment model.=20 Please suggest how we could be clearer, or if we're factually incorrect.=20 Michael >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] > > Sent: Wednesday, December 04, 2013 3:59 AM > > To: Ronald Bonica; opsec@ietf.org > > Subject: RE: Review of draft-ietf-opsec-lla-only-05 > > > > Ron, > > > > When we started this work we wanted to make a recommendation, > because > > we believe that there are advantages in the approach. Quite early it > > has become clear that there is no consensus in the IETF on whether the > > link local approach actually makes life simpler or not. Some people > > say it doesn't, some people say it does. > > > > So the agreement at the time was to list, factually, without any > > weighing of judgement, the technical aspects, pros and cons. This is > > what we're trying to do. > > > > We have removed all "recommend" and similar phrases. (Thanks to our > > reviewers, who kept us honest here). > > > > The idea is that a network operator has easy access to all the aspects > > to consider, potential advantages, and caveats. And this operator > > should now be able to say for his network: this advantage doesn't make > > much difference to me; the other one does. This caveat does apply to > > me, the other one not. And you're making those calls below; my point > > would be: We've seen in the early stages of this draft that it's hard > > to get global consensus on those. > > > > So I suggest we keep the document factual, and let operators make > > their own choices. This is what the document should achieve. It should > > not make a judgement on the value of any aspects, because those would > > be context-dependent. > > > > My question is: Is the document in any place not factual? Or missing > > facts? If so, please let us know - that should be fixed! > > > > Michael > > > > > -----Original Message----- > > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Ronald > > Bonica > > > Sent: 03 December 2013 19:55 > > > To: opsec@ietf.org > > > Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-05 > > > > > > Folks, > > > > > > Reading through Sections 2.2 and 2.3 of this document, I question > > > whether the benefits of numbering router interfaces from link-local > > > address space actually outweigh the cost. The document lists the > > following as benefits: > > > > > > 1) Smaller routing tables > > > 2) Simpler address management > > > 3) Lower configuration complexity > > > 4) Simpler DNS > > > 5) Reduced attack surface > > > > > > IMHO, advantages 1, 2 and 3 are dubious. In this draft, we consider > > > numbering router-to-router interfaces from link-local space. In a > > > large network, the number of router-to-router interfaces is dwarfed > > by > > > the total number of interfaces. So, numbering router-to-router > > > interfaces reduces the magnitude of some problems, but not by a > > significant amount. > > > > > > Advantage #5 also is dubious. If you think of an address as being > > "the > > > attack surface" of a router, then numbering selected interfaces from > > > link-local reduces the attack surface. But miscreants don't attack > > > addresses. They attack the resource that an address represents. > > > Since all of those resources are accessible using the box's globally > > > routable loopback address, numbering some interfaces from link-local > > > really doesn't reduce the attack surface. > > > > > > I realize that this may not be the kind of review that you want. So, > > I > > > am happy to be told that mine is the minority opinion. > > > > > > -------------------------- > > > Ron Bonica > > > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > > > > > > > > _______________________________________________ > > > OPSEC mailing list > > > OPSEC@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsec > > >=20 From rbonica@juniper.net Wed Dec 4 09:10:06 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CF61AE2EF for ; Wed, 4 Dec 2013 09:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51j3ctW_NZEY for ; Wed, 4 Dec 2013 09:10:03 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFAC1AE2EE for ; Wed, 4 Dec 2013 09:10:03 -0800 (PST) Received: from mail111-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 17:10:00 +0000 Received: from mail111-tx2 (localhost [127.0.0.1]) by mail111-tx2-R.bigfish.com (Postfix) with ESMTP id 05228420098; Wed, 4 Dec 2013 17:10:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz9371I103dKd772h542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068h18602ehz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail111-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(199002)(51704005)(13464003)(41574002)(74502001)(77096001)(65816001)(80022001)(83072001)(31966008)(54316002)(87266001)(69226001)(76796001)(87936001)(76786001)(74662001)(85852002)(47446002)(66066001)(76576001)(46102001)(56776001)(33646001)(15202345003)(74316001)(77982001)(15974865002)(59766001)(76482001)(53806001)(54356001)(15975445006)(74876001)(74366001)(2656002)(4396001)(83322001)(80976001)(85306002)(81686001)(50986001)(19580405001)(81342001)(74706001)(51856001)(551544002)(49866001)(63696002)(79102001)(19580395003)(47736001)(81542001)(81816001)(47976001)(56816005)(90146001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail111-tx2 (localhost.localdomain [127.0.0.1]) by mail111-tx2 (MessageSwitch) id 1386176997229881_10077; Wed, 4 Dec 2013 17:09:57 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.242]) by mail111-tx2.bigfish.com (Postfix) with ESMTP id 2477720004C; Wed, 4 Dec 2013 17:09:57 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 17:09:56 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 17:09:54 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.825.14; Wed, 4 Dec 2013 17:09:51 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.127]) with mapi id 15.00.0825.006; Wed, 4 Dec 2013 17:09:51 +0000 From: Ronald Bonica To: "Michael Behringer (mbehring)" , "opsec@ietf.org" Thread-Topic: Review of draft-ietf-opsec-lla-only-05 Thread-Index: Ac7wWSDptQScqWK/Td6betnie2vjoQAdI4tQAAzt6RAAA9xMMAAArJvw Date: Wed, 4 Dec 2013 17:09:50 +0000 Message-ID: <8f439d8fed1443bcafec703a000f1856@CO1PR05MB442.namprd05.prod.outlook.com> References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB4B@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D902CB2@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D902CB2@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0050CEFE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:10:06 -0000 Michael, OK, I am happy to back off on this one. Chairs, Please consider my review as being without objection. Ron > -----Original Message----- > From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] > Sent: Wednesday, December 04, 2013 12:06 PM > To: Ronald Bonica; opsec@ietf.org > Subject: RE: Review of draft-ietf-opsec-lla-only-05 >=20 > > -----Original Message----- > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > Sent: 04 December 2013 16:04 > > To: Michael Behringer (mbehring); opsec@ietf.org > > Subject: RE: Review of draft-ietf-opsec-lla-only-05 > > > > Hi Michael, > > > > I realize that I am in the rough on this one and would be happy to > back off. >=20 > This is about clarity, and a good discussion. Thanks! We want this > draft to be factually correct and clear. >=20 > > But before I do that, could you respond to my question regarding > > whether numbering router-to-router interfaces from link-local really > > reduces the attack surface of a router? After all, every resource > that > > is vulnerable to attack when numbered from global address space is > > also vulnerable when numbered from link-local address space. You > > haven't reduced the number of vulnerable interfaces, only the number > > and specificity of the addresses by which they can be addressed. >=20 > That is strictly speaking correct. An interface doesn't become un- > vulnerable because it uses a link-local address. But a link local > address can only be reached (and therefore attacked) from the link. > That significantly reduces the exposure of that address, and this is a > recognised concept: >=20 > http://tools.ietf.org/html/rfc5082 (GTSM) states in section 5.3 clearly > that on-link attacks are possible, yet I think there is consensus that > there is value in reducing the attack horizon. >=20 > So yes, link local reduces the number of addresses a device can be > reached by. We try to be clear in section 2.2: >=20 > " > Reduced attack surface: Every routable address on a router constitutes > a potential attack point: a remote attacker can send traffic to that > address. Examples are a TCP SYN flood (see [RFC4987]), or SSH brute > force password attacks. If a network only uses the addresses of the > router loopback interface(s), only those addresses need to be protected > from outside the network. This may ease protection measures, such as > infrastructure access control lists. > " >=20 > Note we're talking about addresses, not interfaces (as you point out). > Re-reading this paragraph, I still think it's factually correct. >=20 > Now, as Gert has pointed out previously, if you address your entire > core address space (loopbacks and interface addresses) out of the same > supernet, and if you have iACLs at the edge blocking that supernet, you > don't gain on this point. If you address them out of different blocks, > your life becomes slightly easier. So it depends on your deployment > model. >=20 > Please suggest how we could be clearer, or if we're factually > incorrect. >=20 > Michael >=20 > > > > Ron > > > > > > > -----Original Message----- > > > From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] > > > Sent: Wednesday, December 04, 2013 3:59 AM > > > To: Ronald Bonica; opsec@ietf.org > > > Subject: RE: Review of draft-ietf-opsec-lla-only-05 > > > > > > Ron, > > > > > > When we started this work we wanted to make a recommendation, > > because > > > we believe that there are advantages in the approach. Quite early > it > > > has become clear that there is no consensus in the IETF on whether > > > the link local approach actually makes life simpler or not. Some > > > people say it doesn't, some people say it does. > > > > > > So the agreement at the time was to list, factually, without any > > > weighing of judgement, the technical aspects, pros and cons. This > is > > > what we're trying to do. > > > > > > We have removed all "recommend" and similar phrases. (Thanks to our > > > reviewers, who kept us honest here). > > > > > > The idea is that a network operator has easy access to all the > > > aspects to consider, potential advantages, and caveats. And this > > > operator should now be able to say for his network: this advantage > > > doesn't make much difference to me; the other one does. This caveat > > > does apply to me, the other one not. And you're making those calls > > > below; my point would be: We've seen in the early stages of this > > > draft that it's hard to get global consensus on those. > > > > > > So I suggest we keep the document factual, and let operators make > > > their own choices. This is what the document should achieve. It > > > should not make a judgement on the value of any aspects, because > > > those would be context-dependent. > > > > > > My question is: Is the document in any place not factual? Or > missing > > > facts? If so, please let us know - that should be fixed! > > > > > > Michael > > > > > > > -----Original Message----- > > > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Ronald > > > Bonica > > > > Sent: 03 December 2013 19:55 > > > > To: opsec@ietf.org > > > > Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-05 > > > > > > > > Folks, > > > > > > > > Reading through Sections 2.2 and 2.3 of this document, I question > > > > whether the benefits of numbering router interfaces from > > > > link-local address space actually outweigh the cost. The document > > > > lists the > > > following as benefits: > > > > > > > > 1) Smaller routing tables > > > > 2) Simpler address management > > > > 3) Lower configuration complexity > > > > 4) Simpler DNS > > > > 5) Reduced attack surface > > > > > > > > IMHO, advantages 1, 2 and 3 are dubious. In this draft, we > > > > consider numbering router-to-router interfaces from link-local > > > > space. In a large network, the number of router-to-router > > > > interfaces is dwarfed > > > by > > > > the total number of interfaces. So, numbering router-to-router > > > > interfaces reduces the magnitude of some problems, but not by a > > > significant amount. > > > > > > > > Advantage #5 also is dubious. If you think of an address as being > > > "the > > > > attack surface" of a router, then numbering selected interfaces > > > > from link-local reduces the attack surface. But miscreants don't > > > > attack addresses. They attack the resource that an address > represents. > > > > Since all of those resources are accessible using the box's > > > > globally routable loopback address, numbering some interfaces > from > > > > link-local really doesn't reduce the attack surface. > > > > > > > > I realize that this may not be the kind of review that you want. > > > > So, > > > I > > > > am happy to be told that mine is the minority opinion. > > > > > > > > -------------------------- > > > > Ron Bonica > > > > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > > > > > > > > > > > > _______________________________________________ > > > > OPSEC mailing list > > > > OPSEC@ietf.org > > > > https://www.ietf.org/mailman/listinfo/opsec > > > > > >=20 >=20 From warren@kumari.net Wed Dec 4 09:16:30 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61551AE303 for ; Wed, 4 Dec 2013 09:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9tBNPv-rLKK for ; Wed, 4 Dec 2013 09:16:28 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8E21AE2F0 for ; Wed, 4 Dec 2013 09:16:28 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id DF5B21B40410; Wed, 4 Dec 2013 12:16:24 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB77@xmb-rcd-x14.cisco.com> Date: Wed, 4 Dec 2013 12:16:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3FB5AA3E-2B83-4DF1-90B5-AABF70C0F874@kumari.net> References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> <9A2B514E-613F-4837-9B56-23B020508C1B@arbor.net> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB77@xmb-rcd-x14.cisco.com> To: Michael Behringer (mbehring) X-Mailer: Apple Mail (2.1510) Cc: "opsec@ietf.org" , Warren Kumari Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:16:31 -0000 On Dec 4, 2013, at 4:06 AM, Michael Behringer (mbehring) = wrote: >> -----Original Message----- >> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Dobbins, >> Roland >> Sent: 04 December 2013 02:48 >> To: opsec@ietf.org >> Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 >>=20 >>=20 >> On Dec 4, 2013, at 1:54 AM, Ronald Bonica = wrote: >>=20 >>> I question whether the benefits of numbering router interfaces from = link- >> local address space actually outweigh the cost. >>=20 >> I'd be very interested to hear the view of the authors on how this = differs in >> effect from numbering IPv4 router interfaces from RFC1918 spaces, and = the >> operational issues which arise from doing so. >=20 > Roland, in short: We're not addressing RFC1918 in this doc. It's = outside scope.=20 >=20 >> While link-local addresses are generally unique, we should consider = the >> experience to date in dealing with privately-addressed router = interfaces on >> the public Internet, and determine whether the benefits of doing >> something similar with IPv6 outweigh the possible negatives. >=20 > The 1918 method is different. It would be an interesting discussion to = have, in another document. >=20 > For the LLA approach, we were told in no uncertain terms that we = should NOT make a judgement, but just list the facts to consider. That's = what we tried to do. Each operator should be able to take those and make = his judgement.=20 Yup, I think that this is one of the sticking points with this draft -- = it seems fairly clear that you can do what the draft describes (we have = an existence proof), much of the discussion has been on the "Are we = advocating this as a solution?" topic. A number of folk have asked that = we document be more of a "If you use LLA for links, this is what to keep = in mind / this is what we have found" and not a value judgment on doing = this. When commenting can folk please also include if they think the draft = tone correctly captures this? I have read all the versions of this document and think that the tone = has greatly improved, but feel that section 2.5 (Summary) still has a = bit too much of the "this is a good idea" feel. Personally I think that = the Summary section doesn't really add anything to the document and = should be dropped. W >=20 > Please let us know where we're not factual or misleading - that needs = fixing.=20 >=20 > Michael >=20 >> = ----------------------------------------------------------------------- >> Roland Dobbins // >> >>=20 >> Luck is the residue of opportunity and design. >>=20 >> -- John Milton >>=20 >> _______________________________________________ >> 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 >=20 -- "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." -- Terry Pratchett From mbehring@cisco.com Wed Dec 4 09:27:14 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94A51A802B for ; Wed, 4 Dec 2013 09:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87BMo4koU8wC for ; Wed, 4 Dec 2013 09:27:12 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id E0F031A1F66 for ; Wed, 4 Dec 2013 09:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8068; q=dns/txt; s=iport; t=1386178029; x=1387387629; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mBl5flXQ8hwMD88HUo3h3aZqOiPl5+lEGqokxuaqZeY=; b=Oz9AGDx8YSfHkHxHp9HJB6WlRwv8z6Cnm9TAUwJ50GFuxKu02cenA/lg toh/puzRjCQZEJJzQnDoN2AZeOvKuC5LpEvE+qToW3yHBrCwEcKewwZvR nzPlJwbnUguC20c9O97oeLEaCtcBJyvqrD0qDTzx2RCr/e8o2p3vnlbjN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALJln1KtJXG9/2dsb2JhbABagwc4U7hjgSQWdIIlAQEBAwEBAQE3DyMCBgIPBAIBCA4DBAEBCw4GCQcnCxQJCAEBBAESCAEQh2MGDcFoF45NOAYSgwiBEwOZRJBjgymCKg X-IronPort-AV: E=Sophos;i="4.93,825,1378857600"; d="scan'208";a="4304184" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-1.cisco.com with ESMTP; 04 Dec 2013 17:27:08 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB4HR8gF019814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 17:27:08 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 11:27:08 -0600 From: "Michael Behringer (mbehring)" To: Ronald Bonica , "opsec@ietf.org" Thread-Topic: Review of draft-ietf-opsec-lla-only-05 Thread-Index: Ac7wWSDptQScqWK/Td6betnie2vjoQAdI4tQAAzt6RAAA9xMMAAArJvwAACaVuA= Date: Wed, 4 Dec 2013 17:27:07 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D902D62@xmb-rcd-x14.cisco.com> References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB4B@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D902CB2@xmb-rcd-x14.cisco.com> <8f439d8fed1443bcafec703a000f1856@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <8f439d8fed1443bcafec703a000f1856@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:27:14 -0000 Ron, thank you for your review! This is a hairy topic, and it's good to hav= e these concerns and discussions voiced and sorted.=20 Michael > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: 04 December 2013 18:10 > To: Michael Behringer (mbehring); opsec@ietf.org > Subject: RE: Review of draft-ietf-opsec-lla-only-05 >=20 > Michael, >=20 > OK, I am happy to back off on this one. >=20 > Chairs, >=20 > Please consider my review as being without objection. >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] > > Sent: Wednesday, December 04, 2013 12:06 PM > > To: Ronald Bonica; opsec@ietf.org > > Subject: RE: Review of draft-ietf-opsec-lla-only-05 > > > > > -----Original Message----- > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > Sent: 04 December 2013 16:04 > > > To: Michael Behringer (mbehring); opsec@ietf.org > > > Subject: RE: Review of draft-ietf-opsec-lla-only-05 > > > > > > Hi Michael, > > > > > > I realize that I am in the rough on this one and would be happy to > > back off. > > > > This is about clarity, and a good discussion. Thanks! We want this > > draft to be factually correct and clear. > > > > > But before I do that, could you respond to my question regarding > > > whether numbering router-to-router interfaces from link-local really > > > reduces the attack surface of a router? After all, every resource > > that > > > is vulnerable to attack when numbered from global address space is > > > also vulnerable when numbered from link-local address space. You > > > haven't reduced the number of vulnerable interfaces, only the number > > > and specificity of the addresses by which they can be addressed. > > > > That is strictly speaking correct. An interface doesn't become un- > > vulnerable because it uses a link-local address. But a link local > > address can only be reached (and therefore attacked) from the link. > > That significantly reduces the exposure of that address, and this is a > > recognised concept: > > > > http://tools.ietf.org/html/rfc5082 (GTSM) states in section 5.3 > > clearly that on-link attacks are possible, yet I think there is > > consensus that there is value in reducing the attack horizon. > > > > So yes, link local reduces the number of addresses a device can be > > reached by. We try to be clear in section 2.2: > > > > " > > Reduced attack surface: Every routable address on a router constitutes > > a potential attack point: a remote attacker can send traffic to that > > address. Examples are a TCP SYN flood (see [RFC4987]), or SSH brute > > force password attacks. If a network only uses the addresses of the > > router loopback interface(s), only those addresses need to be > > protected from outside the network. This may ease protection measures, > > such as infrastructure access control lists. > > " > > > > Note we're talking about addresses, not interfaces (as you point out). > > Re-reading this paragraph, I still think it's factually correct. > > > > Now, as Gert has pointed out previously, if you address your entire > > core address space (loopbacks and interface addresses) out of the same > > supernet, and if you have iACLs at the edge blocking that supernet, > > you don't gain on this point. If you address them out of different > > blocks, your life becomes slightly easier. So it depends on your > > deployment model. > > > > Please suggest how we could be clearer, or if we're factually > > incorrect. > > > > Michael > > > > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] > > > > Sent: Wednesday, December 04, 2013 3:59 AM > > > > To: Ronald Bonica; opsec@ietf.org > > > > Subject: RE: Review of draft-ietf-opsec-lla-only-05 > > > > > > > > Ron, > > > > > > > > When we started this work we wanted to make a recommendation, > > > because > > > > we believe that there are advantages in the approach. Quite early > > it > > > > has become clear that there is no consensus in the IETF on whether > > > > the link local approach actually makes life simpler or not. Some > > > > people say it doesn't, some people say it does. > > > > > > > > So the agreement at the time was to list, factually, without any > > > > weighing of judgement, the technical aspects, pros and cons. This > > is > > > > what we're trying to do. > > > > > > > > We have removed all "recommend" and similar phrases. (Thanks to > > > > our reviewers, who kept us honest here). > > > > > > > > The idea is that a network operator has easy access to all the > > > > aspects to consider, potential advantages, and caveats. And this > > > > operator should now be able to say for his network: this advantage > > > > doesn't make much difference to me; the other one does. This > > > > caveat does apply to me, the other one not. And you're making > > > > those calls below; my point would be: We've seen in the early > > > > stages of this draft that it's hard to get global consensus on thos= e. > > > > > > > > So I suggest we keep the document factual, and let operators make > > > > their own choices. This is what the document should achieve. It > > > > should not make a judgement on the value of any aspects, because > > > > those would be context-dependent. > > > > > > > > My question is: Is the document in any place not factual? Or > > missing > > > > facts? If so, please let us know - that should be fixed! > > > > > > > > Michael > > > > > > > > > -----Original Message----- > > > > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Ronald > > > > Bonica > > > > > Sent: 03 December 2013 19:55 > > > > > To: opsec@ietf.org > > > > > Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-05 > > > > > > > > > > Folks, > > > > > > > > > > Reading through Sections 2.2 and 2.3 of this document, I > > > > > question whether the benefits of numbering router interfaces > > > > > from link-local address space actually outweigh the cost. The > > > > > document lists the > > > > following as benefits: > > > > > > > > > > 1) Smaller routing tables > > > > > 2) Simpler address management > > > > > 3) Lower configuration complexity > > > > > 4) Simpler DNS > > > > > 5) Reduced attack surface > > > > > > > > > > IMHO, advantages 1, 2 and 3 are dubious. In this draft, we > > > > > consider numbering router-to-router interfaces from link-local > > > > > space. In a large network, the number of router-to-router > > > > > interfaces is dwarfed > > > > by > > > > > the total number of interfaces. So, numbering router-to-router > > > > > interfaces reduces the magnitude of some problems, but not by a > > > > significant amount. > > > > > > > > > > Advantage #5 also is dubious. If you think of an address as > > > > > being > > > > "the > > > > > attack surface" of a router, then numbering selected interfaces > > > > > from link-local reduces the attack surface. But miscreants don't > > > > > attack addresses. They attack the resource that an address > > represents. > > > > > Since all of those resources are accessible using the box's > > > > > globally routable loopback address, numbering some interfaces > > from > > > > > link-local really doesn't reduce the attack surface. > > > > > > > > > > I realize that this may not be the kind of review that you want. > > > > > So, > > > > I > > > > > am happy to be told that mine is the minority opinion. > > > > > > > > > > -------------------------- > > > > > Ron Bonica > > > > > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > OPSEC mailing list > > > > > OPSEC@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/opsec > > > > > > > > > > > >=20 From joelja@bogus.com Wed Dec 4 09:56:06 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287551ADDBD for ; Wed, 4 Dec 2013 09:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNqZja2bHLMY for ; Wed, 4 Dec 2013 09:56:04 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 304DD1AE2C0 for ; Wed, 4 Dec 2013 09:56:04 -0800 (PST) Received: from 23508tpuyot.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id rB4Hu1DB036213 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 4 Dec 2013 17:56:01 GMT (envelope-from joelja@bogus.com) Message-ID: <529F6CAB.5000801@bogus.com> Date: Wed, 04 Dec 2013 09:55:55 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: Ronald Bonica , "opsec@ietf.org" References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NIjQsNE4xQ8S3xouLujXgFCHoP2jEPmrB" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 04 Dec 2013 17:56:01 +0000 (UTC) Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:56:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NIjQsNE4xQ8S3xouLujXgFCHoP2jEPmrB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/3/13, 10:54 AM, Ronald Bonica wrote: > Folks, >=20 > Reading through Sections 2.2 and 2.3 of this document, I question > whether the benefits of numbering router interfaces from link-local > address space actually outweigh the cost. The document lists the > following as benefits: >=20 > 1) Smaller routing tables 2) Simpler address management 3) Lower > configuration complexity 4) Simpler DNS 5) Reduced attack surface >=20 > IMHO, advantages 1, 2 and 3 are dubious. In this draft, we consider > numbering router-to-router interfaces from link-local space. In a > large network, the number of router-to-router interfaces is dwarfed > by the total number of interfaces. So, numbering router-to-router > interfaces reduces the magnitude of some problems, but not by a > significant amount. >=20 > Advantage #5 also is dubious. If you think of an address as being > "the attack surface" of a router, then numbering selected interfaces > from link-local reduces the attack surface. But miscreants don't > attack addresses. They attack the resource that an address > represents. Since all of those resources are accessible using the > box's globally routable loopback address, numbering some interfaces > from link-local really doesn't reduce the attack surface. > > I realize that this may not be the kind of review that you want. So, > I am happy to be told that mine is the minority opinion. I'm generally concerned when the question of whether we should put our stamp on something that we don't consider to be a good idea. As I noted for the 88 minutes I feel a bit more sanguine about this if it looks more like a case study, e.g. we "did it because of foo, this is what we did." personally I feel that this is a bad idea in general there may be specific cases where it is appropriate. > -------------------------- Ron Bonica vcard: > www.bonica.org/ron/ronbonica.vcf >=20 >=20 >=20 > _______________________________________________ OPSEC mailing list=20 > OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec >=20 --NIjQsNE4xQ8S3xouLujXgFCHoP2jEPmrB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKfbKsACgkQ8AA1q7Z/VrLEZACcDEijsUPhUELUJIHJIHTYuvca UvAAmgN15Es1k8vzz2vMrvy6nCcOF4bW =Ps43 -----END PGP SIGNATURE----- --NIjQsNE4xQ8S3xouLujXgFCHoP2jEPmrB-- From iesg-secretary@ietf.org Wed Dec 4 12:02:10 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402651AE1AA; Wed, 4 Dec 2013 12:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-62UwxRnT8b; Wed, 4 Dec 2013 12:02:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 969DF1AD945; Wed, 4 Dec 2013 12:01:49 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131204200149.9848.28316.idtracker@ietfa.amsl.com> Date: Wed, 04 Dec 2013 12:01:49 -0800 Cc: opsec WG Subject: [OPSEC] WG Action: Rechartered Operational Security Capabilities for IP Network Infrastructure (opsec) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:02:10 -0000 The Operational Security Capabilities for IP Network Infrastructure (opsec) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Operational Security Capabilities for IP Network Infrastructure (opsec) ------------------------------------------------ Current Status: Active WG Chairs: Warren Kumari Gunter Van de Velde KK Chittimaneni Assigned Area Director: Joel Jaeggli Mailing list Address: opsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsec Archive: http://www.ietf.org/mail-archive/web/opsec/ Charter: Goals: The OPSEC WG will document operational issues and best current practices with regard to network security. In particular, the working group will clarify the rationale of supporting current operational practice, addressing gaps in currently understood best practices and clarifying liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG includes the protection and secure operation of the forwarding, control and management planes. Documentation of operational issues, revision of existing operational security practices documents and proposals for new approaches to operational challenges related to network security are in scope. Method: The work will result in the publication of informational or BCP RFCs. Taxonomy or problem statement documents may provide a basis for such documents. Informational or Best Current Practices Documents For each topic addressed, the working group will produce a document that captures common practices related to secure network operation. This will be primarily based on operational experience. A document might convey: * a threat or threats to be addressed * current practices for addressing the threat * protocols, tools and technologies extant at the time of writing that are used to address the threat * the possibility that a solution does not exist within existing tools or technologies Taxonomy and Problem Statement Documents These are documents that describe the scope of particular operational security challenges or problem spaces without necessarily coming to conclusions or proposing solutions. Such a document might be the precursor to an informational or best current practices document. While the principal input of the working group is operational experience and needs, the output should be directed towards providing guidance to the operators community, other working groups that develop protocols or the protocol development community. Non-Goals: The OPSEC WG is will not write or modify protocols. New protocol work must be addressed through a working group chartered for that work, or via one of the individual submission processes. The OPSEC WG may take on documents related to the practices of using such work. Milestones: Done - Complete Charter Done - First draft of Framework Document as Internet Draft Done - First draft of Standards Survey Document as Internet Draft Done - First draft of Packet Filtering Capabilities Done - First draft of Event Logging Capabilities Done - First draft of Network Operator Current Security Practices Done - First draft of In-Band management capabilities Done - First draft of Out-of-Band management capabilities Done - First draft of Configuration and Management Interface Capabilities Done - Submit Network Operator Current Security Practices to IESG Dec 2012 - WG Adoption of 'BGP operations and security' document Dec 2012 - WG Adoption of 'Network Reconnaissance in IPv6 Networks' document Dec 2012 - WG Adoption of 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Dec 2012 - WG Adoption of 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Jan 2013 - WG Last Call for 'Operational Security Considerations for IPv6 Networks' document Jan 2013 - WG Last Call for 'Recommendations for filtering ICMP messages' document Jan 2013 - WG Last Call for 'Recommendations on filtering of IPv4 packets containing IPv4 options' document Jan 2013 - WG Last Call for 'Security Implications of IPv6 on IPv4 networks' document Mar 2013 - WG Last Call for 'Using Only Link-Local Addressing Inside an IPv6 Network' document Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG Mar 2013 - Submit 'Recommendations on filtering of IPv4 packets containing IPv4 options' document to IESG Mar 2013 - Submit 'Operational Security Considerations for IPv6 Networks' document to IESG Mar 2013 - Submit 'Recommendations for filtering ICMP messages' document to IESG May 2013 - Submit 'Using Only Link-Local Addressing Inside an IPv6 Network' document to IESG Jul 2013 - WG Last Call for 'BGP operations and security' document Jul 2013 - WG Last Call for 'Network Reconnaissance in IPv6 Networks' document Jul 2013 - WG Last Call for 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document Jul 2013 - WG Last Call for 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks' document Sep 2013 - Submit 'BGP operations and security' document to IESG Sep 2013 - Submit 'Network Reconnaissance in IPv6 Networks' document to IESG Sep 2013 - Submit 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' document to IESG From martin.vigoureux@alcatel-lucent.com Thu Dec 5 08:09:33 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAA11AE0B6; Thu, 5 Dec 2013 08:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYfpH9PciaLh; Thu, 5 Dec 2013 08:09:31 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1E51A1AE0AA; Thu, 5 Dec 2013 08:09:31 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rB5G9PAX027296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Dec 2013 10:09:26 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rB5G9MwE001093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 17:09:24 +0100 Received: from [172.27.205.188] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 5 Dec 2013 17:09:23 +0100 Message-ID: <52A0A533.8050100@alcatel-lucent.com> Date: Thu, 5 Dec 2013 17:09:23 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.39] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Thu, 05 Dec 2013 08:23:23 -0800 Cc: rtg-dir@ietf.org, draft-ietf-opsec-vpn-leakages.all@tools.ietf.org, opsec@ietf.org Subject: [OPSEC] RtgDir review: draft-ietf-opsec-vpn-leakages-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:09:33 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF Last Call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsec-vpn-leakages-02 Reviewer: Martin Vigoureux Review Date: 2013-12-05 IETF LC End Date: 2013-12-16 Intended Status: Informational Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document is short, focussed, and well written. However it is unclear, beyond that fact that users do not know that traffic is leaking from (rather not mapped onto) their VPN, what the real issue is. Yes, a man in the middle, might intercept the leaked traffic but this traffic is a priori intended to resources only accessible through the VPN. So, knowing that the leaked traffic will not reach the targeted destination, it is not clear which critical information it may carry. I believe that it would be worth giving an example. Note that this relates to/extends a comment raised against draft-gont-opsec-vpn-leakages-00 but which was apparently not addressed. http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html Minor Issues: Abstract: This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. I believe this sentence does not exactly reflect the content of the document. For the first part, I think it is not only because of enabling IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN client has poor capabilities in handling securely (i.e., mapping on the VPN) packets which use one of the two address families. By the way this is said in section 4: the resulting VPN traffic leakage is a side-effect of employing IPv6-unaware VPN software in a dual-stacked host/network. Thanks -m From warren@kumari.net Thu Dec 5 11:49:16 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18A11AE05B; Thu, 5 Dec 2013 11:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVfLfQEz-M82; Thu, 5 Dec 2013 11:49:14 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793161AE04F; Thu, 5 Dec 2013 11:49:14 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id 5AB561B4046D; Thu, 5 Dec 2013 14:49:10 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <52A0A533.8050100@alcatel-lucent.com> Date: Thu, 5 Dec 2013 14:49:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8426E7F4-A2D8-4200-8642-8E10A9B70619@kumari.net> References: <52A0A533.8050100@alcatel-lucent.com> To: Martin Vigoureux X-Mailer: Apple Mail (2.1510) Cc: rtg-dir@ietf.org, draft-ietf-opsec-vpn-leakages.all@tools.ietf.org, Warren Kumari , opsec@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [OPSEC] RtgDir review: draft-ietf-opsec-vpn-leakages-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:49:17 -0000 On Dec 5, 2013, at 11:09 AM, Martin Vigoureux = wrote: > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this = draft. Just a quick note to say think you for the helpful review=85 W > The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF Last Call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html >=20 > Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. >=20 > Document: draft-ietf-opsec-vpn-leakages-02 > Reviewer: Martin Vigoureux > Review Date: 2013-12-05 > IETF LC End Date: 2013-12-16 > Intended Status: Informational >=20 > Summary: > This document is basically ready for publication, but has nits that = should be considered prior to publication. >=20 > Comments: > This document is short, focussed, and well written. > However it is unclear, beyond that fact that users do not know that = traffic is leaking from (rather not mapped onto) their VPN, what the = real issue is. Yes, a man in the middle, might intercept the leaked = traffic but this traffic is a priori intended to resources only = accessible through the VPN. So, knowing that the leaked traffic will not = reach the targeted destination, it is not clear which critical = information it may carry. I believe that it would be worth giving an = example. > Note that this relates to/extends a comment raised against = draft-gont-opsec-vpn-leakages-00 but which was apparently not addressed. > http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html >=20 > Minor Issues: > Abstract: > This document discusses some scenarios in which such VPN leakages > may occur, either as a side effect of enabling IPv6 on a local > network, or as a result of a deliberate attack from a local > attacker. > I believe this sentence does not exactly reflect the content of the = document. For the first part, I think it is not only because of enabling = IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN = client has poor capabilities in handling securely (i.e., mapping on the = VPN) packets which use one of the two address families. > By the way this is said in section 4: > the resulting VPN traffic leakage is a side-effect of employing > IPv6-unaware VPN software in a dual-stacked host/network. >=20 > Thanks > -m >=20 --=20 "Does Emacs have the Buddha nature? Why not? It has bloody well = everything else..." From fgont@si6networks.com Fri Dec 6 09:02:29 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749D21AE0B3; Fri, 6 Dec 2013 09:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HQu4Lf7Yzf2; Fri, 6 Dec 2013 09:02:27 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B47011AE054; Fri, 6 Dec 2013 09:02:27 -0800 (PST) Received: from [2001:5c0:1000:a::25b9] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Voyn6-0001Um-LV; Fri, 06 Dec 2013 18:02:13 +0100 Message-ID: <52A20312.9080408@si6networks.com> Date: Fri, 06 Dec 2013 14:02:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Martin Vigoureux , rtg-ads@tools.ietf.org References: <52A0A533.8050100@alcatel-lucent.com> In-Reply-To: <52A0A533.8050100@alcatel-lucent.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-opsec-vpn-leakages.all@tools.ietf.org, opsec@ietf.org Subject: Re: [OPSEC] RtgDir review: draft-ietf-opsec-vpn-leakages-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:02:29 -0000 Hi, Martin! Thanks so much for your review! -- Please find my comments inline... On 12/05/2013 01:09 PM, Martin Vigoureux wrote: > Comments: > This document is short, focussed, and well written. > However it is unclear, beyond that fact that users do not know that > traffic is leaking from (rather not mapped onto) their VPN, what the > real issue is. Yes, a man in the middle, might intercept the leaked > traffic but this traffic is a priori intended to resources only > accessible through the VPN. The most basic scenario, as described in the I-D is this: You attend a conference and tunnel everything through the VPN (for security/privacy reasons). But then all your traffic goes in the clear... The implications are that the user can now be monitored wrt which istes he visits, etc., his location is leaked out, plaintext passwords come up in the clear, MITM attacks become possible, etc. > So, knowing that the leaked traffic will not > reach the targeted destination, it is not clear which critical > information it may carry. I believe that it would be worth giving an > example. This is what we currently have in the I-D, as an example, in the intro: ---- cut here ---- It is a very common practice for employees working at remote locations to establish a VPN connection with their office or home office. This is typically done to gain access to some resources only available within the company's network, but also to secure the host's traffic against attackers that might be connected to the same remote location. The same is true for mobile nodes that establish VPN connections to secure their traffic while they roam from one network to another. In some scenarios, it is even assumed that employing a VPN connection makes the use of insecure protocols (e.g. that transfer sensitive information in the clear) acceptable, as the VPN provides security services (such as data integrity and/or confidentiality) for all communications made over the VPN. ---- cut here ---- Please let me know if you think this should be modified/augmented... and, if possible, provide advice regarding "how" that should be done. :-) > Minor Issues: > Abstract: > This document discusses some scenarios in which such VPN leakages > may occur, either as a side effect of enabling IPv6 on a local > network, or as a result of a deliberate attack from a local > attacker. > I believe this sentence does not exactly reflect the content of the > document. For the first part, I think it is not only because of enabling > IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN > client has poor capabilities in handling securely (i.e., mapping on the > VPN) packets which use one of the two address families. Would this modification address your comment?: ---- cut here ---- This document discusses some scenarios in which such VPN leakages may occur as a result of employing IPv6-unaware software in networks that support IPv6 (either legitimately, or as a result of a deliberate attack from a local attacker). ---- cut here ---- 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 ler762@gmail.com Fri Dec 6 09:41:48 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F721AC7F0 for ; Fri, 6 Dec 2013 09:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvb5lHPElpFm for ; Fri, 6 Dec 2013 09:41:46 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 915271AE092 for ; Fri, 6 Dec 2013 09:41:33 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so1221459wid.17 for ; Fri, 06 Dec 2013 09:41:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R5vrzSC20yyhxzpn32mt4PcCYKUmFF9c6t7PjJ3phPw=; b=FkuWHSz3SjACpXmQy/DfGA9r4AJ6xIWhrk689CX7a3kf3MRbbHHtwZV6NjI2ze080I JlwZfPlbyTpDwm+XgH0h2yFr0zB95s8lt7MEIYYrfsuUsFhc/7sKkbMJOg+fm9/mkBJa n+j+qc2NKKdsLW/izhjZLQ5bkgmkLqKIQ0CmYffvN6xFzJxFvImG6YR1i0E66o2EwWQm VKgiijDOQhpqfwl2E07znvYf/c2mJORNnKQ1q/W8Pcbcrx/Sq0/CMwQsW+vNcluMpCh/ Hraxg3IilrSDgEGjHT2sZ5Ao4U7A64QanAu+9qgu97WvQxzMPIP2zFGh+0z2F7Q1ibYG V8tA== MIME-Version: 1.0 X-Received: by 10.194.94.167 with SMTP id dd7mr23812973wjb.43.1386351689254; Fri, 06 Dec 2013 09:41:29 -0800 (PST) Received: by 10.194.222.40 with HTTP; Fri, 6 Dec 2013 09:41:29 -0800 (PST) In-Reply-To: <52A0A533.8050100@alcatel-lucent.com> References: <52A0A533.8050100@alcatel-lucent.com> Date: Fri, 6 Dec 2013 12:41:29 -0500 Message-ID: From: Lee To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: martin.vigoureux@alcatel-lucent.com Subject: Re: [OPSEC] RtgDir review: draft-ietf-opsec-vpn-leakages-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:41:48 -0000 Hi, > Yes, a man in the middle, might intercept the leaked > traffic but this traffic is a priori intended to resources only > accessible through the VPN. I almost read the draft the same way. With the lead-off sentence being It is a very common practice for employees working at remote locations to establish a VPN connection with their office or home office. and not explicitly mentioning cybercafe until section 6, the "problem space" does initially seem to be accessing private networks. The next sentence didn't help This is typically done to gain access to some resources only available within the company's network, but also to secure the host's traffic against attackers that might be connected to the same remote location. because wherever I am is the local location. So I interpreted 'securing against attackers connected to the same remote location' as 'other VPN users'. Which didn't make a whole lot of sense, but RFCs all too often don't on my first reading :( If someone wants to argue that I need to work on my reading comprehension skills, yes, I probably do, but changing it to "attackers that might be connected to the same remote location (e.g. cybercafe)" would have immediately fixed the problem. It would also be helpful if the intro lead off with something along the lines of "employing the VPN for having some sort of confidentiality at least on the way out of the insecure network he's connecting to" (http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html) to prevent setting up the 'vpns are for accessing private resources' mental mind-map and explicitly putting 'insecure local network' into the problem space right at the beginning. Regards, Lee On 12/5/13, Martin Vigoureux wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF Last Call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-opsec-vpn-leakages-02 > Reviewer: Martin Vigoureux > Review Date: 2013-12-05 > IETF LC End Date: 2013-12-16 > Intended Status: Informational > > Summary: > This document is basically ready for publication, but has nits that > should be considered prior to publication. > > Comments: > This document is short, focussed, and well written. > However it is unclear, beyond that fact that users do not know that > traffic is leaking from (rather not mapped onto) their VPN, what the > real issue is. Yes, a man in the middle, might intercept the leaked > traffic but this traffic is a priori intended to resources only > accessible through the VPN. So, knowing that the leaked traffic will not > reach the targeted destination, it is not clear which critical > information it may carry. I believe that it would be worth giving an > example. > Note that this relates to/extends a comment raised against > draft-gont-opsec-vpn-leakages-00 but which was apparently not addressed. > http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html > > Minor Issues: > Abstract: > This document discusses some scenarios in which such VPN leakages > may occur, either as a side effect of enabling IPv6 on a local > network, or as a result of a deliberate attack from a local > attacker. > I believe this sentence does not exactly reflect the content of the > document. For the first part, I think it is not only because of enabling > IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN > client has poor capabilities in handling securely (i.e., mapping on the > VPN) packets which use one of the two address families. > By the way this is said in section 4: > the resulting VPN traffic leakage is a side-effect of employing > IPv6-unaware VPN software in a dual-stacked host/network. > > Thanks > -m > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From internet-drafts@ietf.org Fri Dec 6 10:47:29 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09E1AE074; Fri, 6 Dec 2013 10:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztlHXiSjVfu3; Fri, 6 Dec 2013 10:47:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDDC1AC828; Fri, 6 Dec 2013 10:47:27 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206184727.31676.6446.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 10:47:27 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:47:29 -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 : Security Implications of IPv6 on IPv4 Networks Author(s) : Fernando Gont Will (Shucheng) Liu Filename : draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07.txt Pages : 18 Date : 2013-12-06 Abstract: This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4= -nets There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-= 07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ipv6-implications-on-ip= v4-nets-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.vigoureux@alcatel-lucent.com Mon Dec 9 08:10:32 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DDD1ADF73; Mon, 9 Dec 2013 08:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7IS5y-uLiJh; Mon, 9 Dec 2013 08:10:30 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7A1ADFCE; Mon, 9 Dec 2013 08:10:29 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rB9GAKM6008758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 10:10:22 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rB9GAHK7023717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 17:10:18 +0100 Received: from [172.27.205.188] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 9 Dec 2013 17:10:17 +0100 Message-ID: <52A5EB68.4000409@alcatel-lucent.com> Date: Mon, 9 Dec 2013 17:10:16 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fernando Gont References: <52A0A533.8050100@alcatel-lucent.com> <52A20312.9080408@si6networks.com> In-Reply-To: <52A20312.9080408@si6networks.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Mailman-Approved-At: Mon, 09 Dec 2013 08:15:39 -0800 Cc: rtg-dir@ietf.org, draft-ietf-opsec-vpn-leakages.all@tools.ietf.org, opsec@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [OPSEC] RtgDir review: draft-ietf-opsec-vpn-leakages-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:10:32 -0000 Fernando, thanks for following up. Your explanations clarify a lot, so I think these clarifications need to be brought to the draft. You are free not to take the suggested text as is, but I think you need to keep the objective. I would start by clarifying the Abstract: OLD: That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear from the local network to the final destination. NEW: That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be sent in the clear on the local network towards the final destination. OLD: This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. NEW: This document discusses some scenarios in which such VPN leakages may occur as a result of employing IPv6-unaware VPN software. Then I believe you need to rework the first paragraph of the Introduction to clearly and rapidly state your problem space rather than loosing the reader in the VPN-to-corporate-resources sink. This echoes the comment you also received from Lee and the original one from KK. OLD: It is a very common practice for employees working at remote locations to establish a VPN connection with their office or home office. This is typically done to gain access to some resources only available within the company's network, but also to secure the host's traffic against attackers that might be connected to the same remote location. The same is true for mobile nodes that establish VPN connections to secure their traffic while they roam from one network to another. In some scenarios, it is even assumed that employing a VPN connection makes the use of insecure protocols (e.g. that transfer sensitive information in the clear) acceptable, as the VPN provides security services (such as data integrity and/or confidentiality) for all communications made over the VPN. NEW: It is a very common practice for users of a VPN software to establish a VPN connection towards a targeted endpoint when their terminal, which hosts the VPN software, is itself connected to a local network (e.g., a conference network). This is typically done to gain access to some resources which are otherwise not accessible, but also to secure the terminal's traffic through the local network (e.g., against attackers that might be connected to the same local network). The latter case constitute the problem space of this document. Indeed, it is sometimes assumed that employing a VPN connection makes the use of insecure protocols (e.g., that transfer sensitive information in the clear) acceptable, as a VPN provides security services (such as data integrity and/or confidentiality) for all communications made over that VPN. However, this document illustrates that under certain circumstances, some traffic might not be mapped onto the VPN and thus be sent in the clear on the local network. -m Le 06/12/2013 18:02, Fernando Gont a écrit : > Hi, Martin! > > Thanks so much for your review! -- Please find my comments inline... > > On 12/05/2013 01:09 PM, Martin Vigoureux wrote: >> Comments: >> This document is short, focussed, and well written. >> However it is unclear, beyond that fact that users do not know that >> traffic is leaking from (rather not mapped onto) their VPN, what the >> real issue is. Yes, a man in the middle, might intercept the leaked >> traffic but this traffic is a priori intended to resources only >> accessible through the VPN. > > The most basic scenario, as described in the I-D is this: > You attend a conference and tunnel everything through the VPN (for > security/privacy reasons). But then all your traffic goes in the clear... > > The implications are that the user can now be monitored wrt which istes > he visits, etc., his location is leaked out, plaintext passwords come up > in the clear, MITM attacks become possible, etc. > > > >> So, knowing that the leaked traffic will not >> reach the targeted destination, it is not clear which critical >> information it may carry. I believe that it would be worth giving an >> example. > > This is what we currently have in the I-D, as an example, in the intro: > > ---- cut here ---- > It is a very common practice for employees working at remote > locations to establish a VPN connection with their office or home > office. This is typically done to gain access to some resources only > available within the company's network, but also to secure the host's > traffic against attackers that might be connected to the same remote > location. The same is true for mobile nodes that establish VPN > connections to secure their traffic while they roam from one network > to another. In some scenarios, it is even assumed that employing a > VPN connection makes the use of insecure protocols (e.g. that > transfer sensitive information in the clear) acceptable, as the VPN > provides security services (such as data integrity and/or > confidentiality) for all communications made over the VPN. > ---- cut here ---- > > Please let me know if you think this should be modified/augmented... > and, if possible, provide advice regarding "how" that should be done. :-) > > > >> Minor Issues: >> Abstract: >> This document discusses some scenarios in which such VPN leakages >> may occur, either as a side effect of enabling IPv6 on a local >> network, or as a result of a deliberate attack from a local >> attacker. >> I believe this sentence does not exactly reflect the content of the >> document. For the first part, I think it is not only because of enabling >> IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN >> client has poor capabilities in handling securely (i.e., mapping on the >> VPN) packets which use one of the two address families. > > Would this modification address your comment?: > > ---- cut here ---- > This document discusses some scenarios in which such VPN leakages > may occur as a result of employing IPv6-unaware software in networks > that support IPv6 (either legitimately, or as a result of a > deliberate attack from a local attacker). > ---- cut here ---- > > Thanks! > > Best regards, > From internet-drafts@ietf.org Mon Dec 9 11:45:39 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01EE1AE50B; Mon, 9 Dec 2013 11:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgN96lBqhiK8; Mon, 9 Dec 2013 11:45:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5699C1AE4F9; Mon, 9 Dec 2013 11:45:38 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209194538.10933.2957.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 11:45:38 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ip-options-filtering-07.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:45:40 -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-07.txt Pages : 35 Date : 2013-12-09 Abstract: This 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From warren@kumari.net Tue Dec 10 13:21:38 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F851AE06B for ; Tue, 10 Dec 2013 13:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CSWqLCMBG3K for ; Tue, 10 Dec 2013 13:21:36 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2CD1AE07A for ; Tue, 10 Dec 2013 13:21:36 -0800 (PST) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id 68A401B406FA; Tue, 10 Dec 2013 16:21:30 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Dec 2013 16:21:29 -0500 Message-Id: To: OpSec@ietf.org, draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Cc: Warren Kumari Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-ipv6-host-scanning X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 21:21:38 -0000 Dear OpSec WG, The authors of draft-ietf-opsec-ipv6-host-scanning have requested WGLC. The draft is available here: = https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. This WGLC ends Tue 24-Dec-2013. As this is a holiday for many folk, = please get your review / comments in soon. Thanks, Warren Kumari (as OpSec WG co-chair) --=20 American Non-Sequitur Society;=20 we don't make sense, but we do like pizza! From warren@kumari.net Tue Dec 10 13:22:08 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF431AE18A for ; Tue, 10 Dec 2013 13:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifZn_0WpW255 for ; Tue, 10 Dec 2013 13:22:07 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86081AE0E0 for ; Tue, 10 Dec 2013 13:22:04 -0800 (PST) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id F3F6A1B40FBD; Tue, 10 Dec 2013 16:21:58 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Dec 2013 16:21:58 -0500 Message-Id: To: OpSec@ietf.org, draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Cc: Warren Kumari Subject: [OPSEC] Reminder about IPR relating to draft-ietf-opsec-ipv6-host-scanning X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 21:22:09 -0000 To: OpSec@ietf.org, draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org Subject: Reminder about IPR relating to = draft-ietf-opsec-ipv6-host-scanning 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.txt). The authors of draft-ietf-opsec-ipv6-host-scanning have asked for a = Working Group Last Call. Before issuing the Working Group Last Call, we = would like to check whether any claims of Intellectual Property Rights = (IPR) on the document have not yet been disclosed. Are you personally aware of any IPR that applies to = draft-ietf-opsec-ipv6-host-scanning? If so, has this IPR been 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 = 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. 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. 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 = devised for telling one another when the best fruit is." --Terry = Prachett=20 From fgont@si6networks.com Tue Dec 10 13:33:19 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14D1AE070 for ; Tue, 10 Dec 2013 13:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYcYo2pNtoYO for ; Tue, 10 Dec 2013 13:33:17 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 72DA31AD73F for ; Tue, 10 Dec 2013 13:33:17 -0800 (PST) Received: from [186.137.77.127] (helo=[192.168.3.105]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VqUvP-0005S7-TB; Tue, 10 Dec 2013 22:33:04 +0100 Message-ID: <52A7888A.5030905@si6networks.com> Date: Tue, 10 Dec 2013 18:32:58 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Warren Kumari , OpSec@ietf.org, draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSEC] Reminder about IPR relating to draft-ietf-opsec-ipv6-host-scanning X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 21:33:19 -0000 Folks, I'm not aware of any IPR on this document. Thanks! Cheers, Fernando (co-author) On 12/10/2013 06:21 PM, Warren Kumari wrote: > To: OpSec@ietf.org, draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org > Subject: Reminder about IPR relating to draft-ietf-opsec-ipv6-host-scanning > > 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.txt). > > > The authors of draft-ietf-opsec-ipv6-host-scanning have asked for a Working Group Last Call. Before issuing the Working Group Last Call, we would like to check whether any claims of Intellectual Property Rights (IPR) on the document have not yet been disclosed. > > Are you personally aware of any IPR that applies to draft-ietf-opsec-ipv6-host-scanning? If so, has this IPR been 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 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. > > 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. > > 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 devised for telling one another when the best fruit is." --Terry Prachett > > > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tjc@ecs.soton.ac.uk Tue Dec 10 15:38:23 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BE51ADBD2 for ; Tue, 10 Dec 2013 15:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAg2xfBHyzVE for ; Tue, 10 Dec 2013 15:38:21 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id DB3C41AD845 for ; Tue, 10 Dec 2013 15:38:20 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rBANc8H5026234; Tue, 10 Dec 2013 23:38:08 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rBANc8H5026234 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1386718689; bh=+pr6sDQ2vBFEeadGRYqgbYyftE0=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=asSqI4w/pE50YC7GffQN39lKjqMRFmDkD33+pWuRNtkOrj40sP5t35Vwo5gVSiqRv tJpv4an46/qGRCCbqHK6rn5G/XleGkMTDThbtkgUo4rbhW4QYiQ/AQ23D+mT05z6m5 TLHvSD/eRnKvOvXHXXZSLBCpy21O35qevwzzrOOk= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id pB9Nc80959610665SJ ret-id none; Tue, 10 Dec 2013 23:38:09 +0000 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rBANamAT030323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 23:36:49 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Tim Chown In-Reply-To: <52A7888A.5030905@si6networks.com> Date: Tue, 10 Dec 2013 23:36:50 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52A7888A.5030905@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1822) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pB9Nc8095961066500; tid=pB9Nc80959610665SJ; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rBANc8H5026234 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Tue, 10 Dec 2013 16:00:01 -0800 Cc: OpSec@ietf.org, draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org, Warren Kumari Subject: Re: [OPSEC] Reminder about IPR relating to draft-ietf-opsec-ipv6-host-scanning X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 23:38:23 -0000 Nor am I. On 10 Dec 2013, at 21:32, Fernando Gont wrote: > Folks, >=20 > I'm not aware of any IPR on this document. >=20 > Thanks! >=20 > Cheers, > Fernando (co-author) >=20 >=20 >=20 >=20 > On 12/10/2013 06:21 PM, Warren Kumari wrote: >> To: OpSec@ietf.org, = draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org >> Subject: Reminder about IPR relating to = draft-ietf-opsec-ipv6-host-scanning >>=20 >> Dear OpSec WG, >>=20 >> Be not alarmed. >> This email was created to satisfy RFC 6702 "Promoting Compliance with = Intellectual Property Rights (IPR)" = (http://tools.ietf.org/rfc/rfc6702.txt). >>=20 >>=20 >> The authors of draft-ietf-opsec-ipv6-host-scanning have asked for a = Working Group Last Call. Before issuing the Working Group Last Call, we = would like to check whether any claims of Intellectual Property Rights = (IPR) on the document have not yet been disclosed. >>=20 >> Are you personally aware of any IPR that applies to = draft-ietf-opsec-ipv6-host-scanning? 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 >>=20 >=20 >=20 > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From joelja@bogus.com Wed Dec 11 09:29:12 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECEC1ADF6B for ; Wed, 11 Dec 2013 09:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EJQFZMWf9e2 for ; Wed, 11 Dec 2013 09:29:10 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 91EB61ADF9C for ; Wed, 11 Dec 2013 09:29:10 -0800 (PST) Received: from 23508tpuyot.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id rBBHT39A001907 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 11 Dec 2013 17:29:04 GMT (envelope-from joelja@bogus.com) Message-ID: <52A8A0DA.3030002@bogus.com> Date: Wed, 11 Dec 2013 09:28:58 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: "opsec@ietf.org" , "draft-ietf-opsec-ip-options-filtering@tools.ietf.org" X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RNB1kAWGeTDoRHSVUXsbJmHqU8irKQ0GH" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 11 Dec 2013 17:29:05 +0000 (UTC) Subject: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:29:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RNB1kAWGeTDoRHSVUXsbJmHqU8irKQ0GH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable you can refer to the diff here. http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filterin= g-07.txt if anyone has issue with any of the changes made to address iesg review or post-last-call change please squawk soon. thanks joel --RNB1kAWGeTDoRHSVUXsbJmHqU8irKQ0GH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKooNoACgkQ8AA1q7Z/VrInBwCfQLlRITQEfuTN9nvXxSq82W6+ rW8An1OviG/+JJR2YmDeti84kux4+4bh =lROy -----END PGP SIGNATURE----- --RNB1kAWGeTDoRHSVUXsbJmHqU8irKQ0GH-- From seun.ojedeji@gmail.com Wed Dec 11 10:54:35 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18ED01AE022 for ; Wed, 11 Dec 2013 10:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXHeYAtKO_SW for ; Wed, 11 Dec 2013 10:54:32 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 96ADC1ADF79 for ; Wed, 11 Dec 2013 10:54:32 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so7535495wid.5 for ; Wed, 11 Dec 2013 10:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u7UTJ4/60xRxuS5YyE5MuNMC2CAKkjDuJm7nCFOpcCM=; b=zQL/PKjzY5AEJb5qwb/BpjY0WiCnSkL8X8s4BhsnFVNbbVjMfMWJjBtFWygV0l88oX +gXcM6vZ+3rBAt9/X9cm1zQ82JifaZBPDau7fldIO853hLq/VIRC5nlPCbtten6Hoqcf PlrlFsfn5zWd2kJTwSJWN4L04Q18Ix02vnZIPGxauL3IYU2EkA0CcKGy0ZOa+1uemSik hRv0xLXZCu3FLFo+EcYmTPZD04cXvHsilY1KrenN+YVHs9FUraKqFzIwdAY+cjq9KnoU rWpWiWYJwbBO691s20TiEBix4bYB5fRt1c/+S8ZS3LnDGdtpvkPuRcVZMAtgCZBzMaJc O2DQ== X-Received: by 10.194.5.138 with SMTP id s10mr196037wjs.91.1386788066407; Wed, 11 Dec 2013 10:54:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.133.40 with HTTP; Wed, 11 Dec 2013 10:53:56 -0800 (PST) In-Reply-To: <52A8A0DA.3030002@bogus.com> References: <52A8A0DA.3030002@bogus.com> From: Seun Ojedeji Date: Wed, 11 Dec 2013 19:53:56 +0100 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=047d7b5d87b313bbb404ed46c28d Cc: "opsec@ietf.org" , "draft-ietf-opsec-ip-options-filtering@tools.ietf.org" Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:54:35 -0000 --047d7b5d87b313bbb404ed46c28d Content-Type: text/plain; charset=ISO-8859-1 Thanks for the share, I am looking at the section below and i am wondering whether the part in bold could be removed to avoid un-necessary query from members of the various groups who were not contacted "offlist". IMHO i think in an environment like this, offlist contacting which does not really have its inputs publicly available to the working group should not necessarily be added 1.2. Operational Focus All of the recommendations in this document have been made in an effort to optimise for operational community consensus, as best the editors have been able to determine that. This has included not only accepting feedback from public lists, *but also accepting off-list* *feedback from people at various network operators (e.g. ISPs,* *content providers, educational institutions, commercial firms).* Kind Regards On Wed, Dec 11, 2013 at 6:28 PM, joel jaeggli wrote: > you can refer to the diff here. > > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-ip-options-filtering-07.txt > > if anyone has issue with any of the changes made to address iesg review > or post-last-call change please squawk soon. > > thanks > joel > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji@fuoye.edu.ng * --047d7b5d87b313bbb404ed46c28d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the share,

I am looking at th= e section below and i am wondering whether the part in bold could be remove= d to avoid un-necessary query from members of the various groups who were n= ot contacted "offlist". IMHO i think in an environment like this,= offlist contacting which does not really have its inputs publicly availabl= e to the working group should not necessarily be added



1.2. = Operational Focus








All of the recommendations in this document have b= een made in an



effort to optimise for operational community consensus, as best the



editors have been able to determine that. This has included not only<= /span>



accepting feedback from public lists, = but also accepting off-list



feedback from people at various networ= k operators (e.g. ISPs,



content providers, educational institu= tions, commercial firms).



Kind Regards


On Wed, Dec 11, = 2013 at 6:28 PM, joel jaeggli <joelja@bogus.com> wrote:
you can refer to the diff here.

http://tools.ietf.org/rfcdiff?url2=3Dd= raft-ietf-opsec-ip-options-filtering-07.txt

if anyone has issue with any of the changes made to address iesg review
or post-last-call change please squawk soon.

thanks
joel


_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec




--
-------------------= -----------------------------------------------------
Seun Ojedeji,
Federal University Oye-E= kiti
web:=A0 =A0 =A0 http://www.fuoye.edu.ng
Mobile: +2348035233535
alt email: seun.ojedeji@fuoy= e.edu.ng

--047d7b5d87b313bbb404ed46c28d-- From rja.lists@gmail.com Wed Dec 11 11:27:05 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC43D1AE0F5 for ; Wed, 11 Dec 2013 11:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xB-zstr3MlN for ; Wed, 11 Dec 2013 11:27:03 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 80DCB1AE0F2 for ; Wed, 11 Dec 2013 11:27:03 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id md12so10531070pbc.21 for ; Wed, 11 Dec 2013 11:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TVyTDvIUcMJezcCc9+Ik7tDLBUWc0bni8Ftfpm6puDQ=; b=x7NniLTW4ND6B14JPlDoEnFBK07gqNvB/xluvUTAL2Hp8hIppCnC988ACHAtXNmesO ROO8Dhu1Q7Dbj28X+EYqIZMnRUMyIsCWSkFC3Lcfeh5Yu6LU0/N+V5zkf8aETucdfNap +bbGAxaSkDEb/8JvHmqCwsWIkYclFlYX6tSVuMQ3l55OBy/CP5yb00F9Ze1rdsX/ST0a 6Gkf2kPxczzD9PQIoQVA5krQWuEH9oQComrSxCURPr5Ef2cLTh3K+sMoDfWX+qgmIWpl VUlRoPcDBpXH8Svc3w+dyd8gTFT5i3ZOAb6rzTq4/w7aHrUqxeJNWn0gPg5GQkM1/skm +AdA== X-Received: by 10.68.243.99 with SMTP id wx3mr4056313pbc.29.1386790017893; Wed, 11 Dec 2013 11:26:57 -0800 (PST) Received: from [10.71.10.5] (rrcs-24-43-233-135.west.biz.rr.com. [24.43.233.135]) by mx.google.com with ESMTPSA id uf2sm34540003pbc.28.2013.12.11.11.26.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 11:26:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: RJ Atkinson In-Reply-To: Date: Wed, 11 Dec 2013 14:26:54 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <52A8A0DA.3030002@bogus.com> To: Seun Ojedeji X-Mailer: Apple Mail (2.1283) Cc: opsec@ietf.org Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:27:05 -0000 On 11 Dec 2013, at 13:53 , Seun Ojedeji wrote: > I am looking at the section below and i am wondering whether the part in > bold could be removed to avoid un-necessary query from members of the > various groups who were not contacted "offlist". The IETF's basic principle is that ALL feedback is considered for an IETF track document. The specific text was added to this document during handling of Last Call comments in an effort to clarify that all inputs also were considered in this specific case. Accepting off-list feedback, in addition to accepting on-list feedback, has been both common and acceptable practice within the IETF for more than 20 years (from my own first-hand knowledge). As an example, for many I-Ds where I am the person commenting on someone else's document, I send the authors/editors unicast email in order to avoid disturbing an entire mailing list with my humble suggestions. It is the choice of the person sending the comments whether they wish to send those to a list or just send them to the authors/editors. Yours, Ran From iesg-secretary@ietf.org Wed Dec 11 15:20:00 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500E91A1F72; Wed, 11 Dec 2013 15:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t3CvvK9tHQT; Wed, 11 Dec 2013 15:19:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E93531AE027; Wed, 11 Dec 2013 15:19:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211231955.9686.79139.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 15:19:55 -0800 Cc: opsec mailing list , opsec chair , RFC Editor Subject: [OPSEC] Document Action: 'Security Implications of IPv6 on IPv4 Networks' to Informational RFC (draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 23:20:00 -0000 The IESG has approved the following document: - 'Security Implications of IPv6 on IPv4 Networks' (draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07.txt) as Informational RFC This document is the product of the Operational Security Capabilities for IP Network Infrastructure Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/ Technical Summary This document discusses the security implications (and provides possible mitigations) of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks. It details a number of operational security concerns, and provides mitigations for many of them. In many cases operators of IPv4 only networks have not considered the security implications of an attacker (or an automatic tunneling mechanism) enabling IPv6 on their network / hosts. Working Group Summary There was no drama in the WG on this topic. Document Quality This document does not describe any protocol/ specifications, and so there are no existing implementations / things to implement. The document is of good quality. It is easily read and clear. Personnel Warren Kumari is the Document Shepherd. Joel Jaeggli is the responsible AD. From seun.ojedeji@gmail.com Wed Dec 11 16:00:00 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA301AE218 for ; Wed, 11 Dec 2013 16:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWnFjU4vjIiS for ; Wed, 11 Dec 2013 15:59:58 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 130771AE220 for ; Wed, 11 Dec 2013 15:59:57 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t61so7139925wes.25 for ; Wed, 11 Dec 2013 15:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BDnU8pe4zdgWPoUJKAhLbnlnvl8Gxnt3s2xTnp/Rhnk=; b=aj6vti4N0ls0fIydaW8OiBIrdo+mcGjczy3DaxzAwUCMMQhH8ja8kdmOHU67fpUjE5 wLkMi1X5p5T4o/rofzIGjNR89PL2yFzmqYewCufR1XkjBY0DYIlWgh1HSjruERxdTBRO 25ezfKLy8RWgr48TiatZvENyBe24vkdxu/PJLAi+rT7T7HDUr0SHgbST5f0ZRWBJ+lb1 qfTRoDvIT5Jh0ADfnnh/1Hc75+hzurIy6QP+8UdCT4LF+REVcyG0h1uAgXfe8OOnpate 6F+29VAPMroeFObs6+E0VrLv27vE4io2y7FJlsEuwWqDVicDoEq4biFmnTVl7Ks6u6e3 bc3A== MIME-Version: 1.0 X-Received: by 10.180.7.136 with SMTP id j8mr27014677wia.17.1386806391968; Wed, 11 Dec 2013 15:59:51 -0800 (PST) Received: by 10.194.133.40 with HTTP; Wed, 11 Dec 2013 15:59:51 -0800 (PST) Received: by 10.194.133.40 with HTTP; Wed, 11 Dec 2013 15:59:51 -0800 (PST) In-Reply-To: References: <52A8A0DA.3030002@bogus.com> Date: Thu, 12 Dec 2013 00:59:51 +0100 Message-ID: From: Seun Ojedeji To: RJ Atkinson Content-Type: multipart/alternative; boundary=14dae9cdc8ff5d9ba904ed4b06f2 Cc: opsec@ietf.org Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 00:00:00 -0000 --14dae9cdc8ff5d9ba904ed4b06f2 Content-Type: text/plain; charset=ISO-8859-1 Hello Ran, Thanks for those clarification, especially with reference to IETF historical approach to handling last call comments period. Kind Regards sent from Google nexus 4 On 11 Dec 2013 20:26, "RJ Atkinson" wrote: > > On 11 Dec 2013, at 13:53 , Seun Ojedeji wrote: > > I am looking at the section below and i am wondering whether the part in > > bold could be removed to avoid un-necessary query from members of the > > various groups who were not contacted "offlist". > > The IETF's basic principle is that ALL feedback is considered > for an IETF track document. > > The specific text was added to this document during handling > of Last Call comments in an effort to clarify that all inputs > also were considered in this specific case. > > Accepting off-list feedback, in addition to accepting on-list > feedback, has been both common and acceptable practice within > the IETF for more than 20 years (from my own first-hand knowledge). > > As an example, for many I-Ds where I am the person commenting > on someone else's document, I send the authors/editors unicast > email in order to avoid disturbing an entire mailing list with > my humble suggestions. It is the choice of the person sending > the comments whether they wish to send those to a list or just > send them to the authors/editors. > > Yours, > > Ran > > --14dae9cdc8ff5d9ba904ed4b06f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello Ran,

Thanks for those clarification, especially with reference to= IETF historical approach to handling last call comments period.

Kind Regards

sent from Google nexus 4

On 11 Dec 2013 20:26, "RJ Atkinson" &l= t;rja.lists@gmail.com> wrote:=

On 11 =A0Dec 2013, at 13:53 , Seun Ojedeji wrote:
> I am looking at the section below and i am wondering whether the part = in
> bold could be removed to avoid un-necessary query from members of the<= br> > various groups who were not contacted "offlist".

The IETF's basic principle is that ALL feedback is considered
for an IETF track document.

The specific text was added to this document during handling
of Last Call comments in an effort to clarify that all inputs
also were considered in this specific case.

Accepting off-list feedback, in addition to accepting on-list
feedback, has been both common and acceptable practice within
the IETF for more than 20 years (from my own first-hand knowledge).

As an example, for many I-Ds where I am the person commenting
on someone else's document, I send the authors/editors unicast
email in order to avoid disturbing an entire mailing list with
my humble suggestions. =A0It is the choice of the person sending
the comments whether they wish to send those to a list or just
send them to the authors/editors.

Yours,

Ran

--14dae9cdc8ff5d9ba904ed4b06f2-- From warren@kumari.net Fri Dec 13 07:48:32 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351241AD34C for ; Fri, 13 Dec 2013 07:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnAhNih5yeNs for ; Fri, 13 Dec 2013 07:48:30 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB8D1A1F56 for ; Fri, 13 Dec 2013 07:48:29 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.105]) by vimes.kumari.net (Postfix) with ESMTPSA id 0A2111B40314; Fri, 13 Dec 2013 10:48:21 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Warren Kumari In-Reply-To: Date: Fri, 13 Dec 2013 10:48:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: OpSec@ietf.org, draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org X-Mailer: Apple Mail (2.1822) Cc: Warren Kumari Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-ipv6-host-scanning [ Reminder ] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 15:48:32 -0000 A reminder=85. On Dec 10, 2013, at 4:21 PM, Warren Kumari wrote: > Dear OpSec WG, >=20 > The authors of draft-ietf-opsec-ipv6-host-scanning have requested = WGLC. >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ >=20 > Please review this draft to see if you think it is ready for = publication > and send comments to the list, clearly stating your view. >=20 > This WGLC ends Tue 24-Dec-2013. As this is a holiday for many folk, = please get your review / comments in soon. There are many religious and other events around this time of year (for = example, December 24th is Christmas eve) =97 you probably don=92t want = to be doing reviews during your holidays, so get =91em in early... >=20 > Thanks, > Warren Kumari > (as OpSec WG co-chair) > --=20 > American Non-Sequitur Society;=20 > we don't make sense, but we do like pizza! >=20 >=20 -- For every complex problem, there is a solution that is simple, neat, and = wrong. -- H. L. Mencken From joelja@bogus.com Sat Dec 14 11:13:45 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90E71AE170 for ; Sat, 14 Dec 2013 11:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8cPqg41uMSE for ; Sat, 14 Dec 2013 11:13:25 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 76FC91AE142 for ; Sat, 14 Dec 2013 11:13:25 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id rBEJDHQ5035686 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 14 Dec 2013 19:13:18 GMT (envelope-from joelja@bogus.com) Message-ID: <52ACADC7.4020906@bogus.com> Date: Sat, 14 Dec 2013 11:13:11 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: "opsec@ietf.org" , "draft-ietf-opsec-ip-options-filtering@tools.ietf.org" References: <52A8A0DA.3030002@bogus.com> In-Reply-To: <52A8A0DA.3030002@bogus.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CHxxuRaqrcKmJjJemSo2MqWsliFoeKi72" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sat, 14 Dec 2013 19:13:18 +0000 (UTC) Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 19:13:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CHxxuRaqrcKmJjJemSo2MqWsliFoeKi72 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am calling this good. Thanks all. joel On 12/11/13, 9:28 AM, joel jaeggli wrote: > you can refer to the diff here. >=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filter= ing-07.txt >=20 > if anyone has issue with any of the changes made to address iesg review= > or post-last-call change please squawk soon. >=20 > thanks > joel >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --CHxxuRaqrcKmJjJemSo2MqWsliFoeKi72 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKsrcgACgkQ8AA1q7Z/VrLMhACfZogNVPXOX5f6sZ+Jr5dEJ+ut yk4An21bmBaxB6yfuzaRtuhiFg8Mmgl3 =DiYk -----END PGP SIGNATURE----- --CHxxuRaqrcKmJjJemSo2MqWsliFoeKi72-- From Donald.Smith@CenturyLink.com Sat Dec 14 17:29:45 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAF81ADFD0 for ; Sat, 14 Dec 2013 17:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeTs8YfBR0cB for ; Sat, 14 Dec 2013 17:29:41 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id A83271ADFCC for ; Sat, 14 Dec 2013 17:29:41 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id rBF1TM0Y025071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Dec 2013 18:29:22 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 4298D1E005B; Sat, 14 Dec 2013 19:29:17 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 10A501E0032; Sat, 14 Dec 2013 19:29:17 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id rBF1TGvW001803; Sat, 14 Dec 2013 18:29:16 -0700 (MST) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id rBF1TGj7001797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Dec 2013 18:29:16 -0700 (MST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0158.001; Sat, 14 Dec 2013 18:29:16 -0700 From: "Smith, Donald" To: joel jaeggli , "opsec@ietf.org" , "draft-ietf-opsec-ip-options-filtering@tools.ietf.org" Thread-Topic: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) Thread-Index: AQHO9paC0SUkEz7wY0G+NCREROK1Q5pUZYK4 Date: Sun, 15 Dec 2013 01:29:15 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D1238C1AA@PDDCWMBXEX503.ctl.intranet> References: <52A8A0DA.3030002@bogus.com> In-Reply-To: <52A8A0DA.3030002@bogus.com> 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: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 01:29:45 -0000 Shouldn't this be environment not environments ? 1.... Additionally, it outlines what a network operator might do in a typical ent= erprise or Service Provider environments. 1.2. Operational Focus =20 =20 All of the recommendations in this document have been made in an =20 effort to optimise for operational community consensus, as best the = =20 editors have been able to determine that. =20 optimize not optimiSe and that isn't English. That is it isn't a complete t= hought/sentence that I can understand anyways? Technical against the draft not just the iesg additions!! I swear I said this before but ISPs and others are going to want at least o= ne more option (possibly two) here. 4.3.5. Advice =20 =20 Routers, security gateways, and firewalls SHOULD implement an option- = =20 specific configuration knob whether packets with this option are dropped, p= ackets with this IP option are forwarded as if they did not contain this IP= option, or packets with this option are processed and forwarded as per [R= FC0791]. =20 Does drop that imply silently drop? (I think it does as opposed to deny whe= re an icmp error should be sent). Shouldn't there be a deny with some icmp = code being sent saying the packet contained unsupported options? Either 3,5= (source router failed for SSRR or LSRR) or 3,9 (admin prohibited) for othe= r options? Forwarded as if they did not contain ... is commonly called ignored or not = processed. I like spelling it out but lets give it a short version name for= router heads/configs. Next we SHOULD permit a "clear" where by the device removes the unwanted op= tions and repads/rechecksums the packet if it could potentially be dangerou= s to an "inner" device. This: Please note that treating packets with LSRR as if they did not =20 contain this option can result in such packets being sent to a =20 different device that the initially intended destination. With =20 appropriate ingress filtering this should not open an attack vector = =20 into the infrastructure. Nonetheless, it could result in traffic =20 that would never reach the initially intended destination. Dropping= =20 these packets prevents unnecessary network traffic, and does not mak= e =20 end-to-end communication any worse. =20 =20 Should be this: Please note that treating packets with LSRR as if they did not =20 contain this option can result in such packets being sent to a =20 different device THAN the initially intended destination. With =20 appropriate ingress filtering this should not open an attack vector = =20 into the infrastructure. Nonetheless, it could result in traffic =20 that would never reach the initially intended destination. Dropping= =20 these packets prevents unnecessary network traffic, and does not mak= e =20 end-to-end communication any worse. =20 =20 It also isn't true:( Consider a LSRR A-B-C-D=20 If A received it and ignores it (including the record route part) and hands= it off to something next to A (1 hop away) that device could hand it back = to A (since it should be in the RR path but isn't) causing a loop that boun= ces between A and it neighbor until the ttl expires right? So not only did = it not arrive at the destination it also could be used to ddos A. 4.4.5 different device that=20 should be: different device than (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: OPSEC [opsec-bounces@ietf.org] on behalf of joel jaeggli [joelja@bogu= s.com] Sent: Wednesday, December 11, 2013 10:28 AM To: opsec@ietf.org; draft-ietf-opsec-ip-options-filtering@tools.ietf.org Subject: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-fil= tering (07) you can refer to the diff here. http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-= 07.txt if anyone has issue with any of the changes made to address iesg review or post-last-call change please squawk soon. thanks joel= From cpignata@cisco.com Sun Dec 15 07:08:54 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01771ADEC0 for ; Sun, 15 Dec 2013 07:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVBUgXNLlA_v for ; Sun, 15 Dec 2013 07:08:45 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A9FC01AE046 for ; Sun, 15 Dec 2013 07:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7573; q=dns/txt; s=iport; t=1387120119; x=1388329719; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=76hgughauZbh+kiVXDMcdQrJW7BAInEGyyJdBgBchP4=; b=YOwq9NIPPaW8zC2mae5ZXkKUA+j0b4P3+anYQWioWVHcVpbHWSfKUigC 6+kNqgne1Tas6oJTd4lBtFLAmr+wBhZV6zq4SrS149dNBnPyhLSXX2Zk4 /sUCGRtknEjAYPRfs2IXW03lLzWUVfXGtf6jL2bxu/HLmXwfD4znOt6tG U=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAL7FrVKtJV2b/2dsb2JhbABZgwo4VbhjgRkWdIIlAQEBAwEnUgULAgEIEQQBAS8yHQgCBA4FDgaHaAgNyDAXjxkHgyOBEwSQM4ExhjKBMJBkgWyBPoIq X-IronPort-AV: E=Sophos;i="4.95,489,1384300800"; d="asc'?scan'208";a="291634819" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 15 Dec 2013 15:08:26 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBFF8PUH020513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Dec 2013 15:08:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Sun, 15 Dec 2013 09:08:25 -0600 From: "Carlos Pignataro (cpignata)" To: "Smith, Donald" Thread-Topic: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) Thread-Index: AQHO9paE1w94bgMXI0CTdpTMtmQ765pU4YmAgADk3gA= Date: Sun, 15 Dec 2013 15:08:25 +0000 Message-ID: <38259622-8A5E-4014-AA02-64F29A1A7D48@cisco.com> References: <52A8A0DA.3030002@bogus.com> <68EFACB32CF4464298EA2779B058889D1238C1AA@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D1238C1AA@PDDCWMBXEX503.ctl.intranet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.250.104] Content-Type: multipart/signed; boundary="Apple-Mail=_9F994E4B-F126-4788-9ABE-BE1ED4FAD110"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "opsec@ietf.org" , "draft-ietf-opsec-ip-options-filtering@tools.ietf.org" Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 15:08:54 -0000 --Apple-Mail=_9F994E4B-F126-4788-9ABE-BE1ED4FAD110 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Donald, Thank you for your comments, please see inline. On Dec 14, 2013, at 8:29 PM, Smith, Donald = wrote: > Shouldn't this be environment not environments ? > 1.... > Additionally, it outlines what a network operator might do in a = typical enterprise or Service Provider environments. >=20 Seems like something the RFC Editor would catch if it is incorrect. "Environment" in singular potentially 'sounds' better; however, your = proposal seems incorrect without an "a" before "Service Provider". In = any case -- to me, if the sentence intends to convey "in a typical = enterprise environment or a typical SP environment" (i.e., "environment" = applying to both), then "in a typical enterprise or SP environments" = should be correct as-is. That said, we could make a note and ask the RFC Editor. Thank you.=20 >=20 > 1.2. Operational Focus =20 >=20 > All of the recommendations in this document have been made in an = =20 > effort to optimise for operational community consensus, as best = the =20 > editors have been able to determine that. =20 >=20 > optimize not optimiSe and that isn't English. That is it isn't a = complete thought/sentence that I can understand anyways? I can say the same thing about your comment :-) What exactly is not = English? It is not clear :-) We can make an RFC Editor note to replace "optimise" with "optimize". = Thank you. I think "optimize" is American and "optimise" is British, but the = dictionary recognizes (and recognises) both. >=20 > Technical against the draft not just the iesg additions!! > I swear I said this before but ISPs and others are going to want at = least one more option (possibly two) here. >=20 > 4.3.5. Advice =20 >=20 > Routers, security gateways, and firewalls SHOULD implement an option- = =20 > specific configuration knob whether packets with this option are = dropped, packets with this IP option are forwarded as if they did not = contain this IP option, or packets with this option are processed and = forwarded as per [RFC0791]. =20 >=20 >=20 > Does drop that imply silently drop? (I think it does as opposed to = deny where an icmp error should be sent). Shouldn't there be a deny with = some icmp code being sent saying the packet contained unsupported = options? Either 3,5 (source router failed for SSRR or LSRR) or 3,9 = (admin prohibited) for other options? >=20 To prevent misuse of CPU resources, this does not send an ICMP. Similar = to 4.11.3. Additionally, both your proposals would be incorrect. ICMP 3/5 is = incorrect since it is not a failure of the source route, ICMP 3/9 as = well as ICMP3/10 are also incorrect, because what is admin prohibited is = neither the network nor the host. There is no ICMP type that says = "option admin prohibited", and we do not want to create one. > Forwarded as if they did not contain ... is commonly called ignored or = not processed. I like spelling it out but lets give it a short version = name for router heads/configs. >=20 Yes, we use "ignore" throughout. >=20 > Next we SHOULD permit a "clear" where by the device removes the = unwanted options and repads/rechecksums the packet if it could = potentially be dangerous to an "inner" device. >=20 Do you know of any device that supports that? This is a BCP for current = practices. > This: > Please note that treating packets with LSRR as if they did not =20 > contain this option can result in such packets being sent to a =20= > different device that the initially intended destination. With =20= > appropriate ingress filtering this should not open an attack = vector =20 > into the infrastructure. Nonetheless, it could result in = traffic =20 > that would never reach the initially intended destination. = Dropping =20 > these packets prevents unnecessary network traffic, and does not = make =20 > end-to-end communication any worse. =20 >=20 >=20 > Should be this: > Please note that treating packets with LSRR as if they did not =20 > contain this option can result in such packets being sent to a =20= > different device THAN the initially intended destination. With =20= > appropriate ingress filtering this should not open an attack = vector =20 > into the infrastructure. Nonetheless, it could result in = traffic =20 > that would never reach the initially intended destination. = Dropping =20 > these packets prevents unnecessary network traffic, and does not = make =20 > end-to-end communication any worse. =20 >=20 OK, we can have an RFC Editor note to replace "that" with "than". > It also isn't true:( >=20 > Consider a LSRR A-B-C-D=20 > If A received it and ignores it (including the record route part) and = hands it off to something next to A (1 hop away) that device could hand = it back to A (since it should be in the RR path but isn't) causing a = loop that bounces between A and it neighbor until the ttl expires right? Wrong. If A ignores the option, it means if performs forwarding based on the = destination IP address in the IP Header. If it sends it to B, B does the = same IP header address destination-based forwarding, why would it send = it to A? I mean, of course unless there is a routing loop regardless of = the presence of LSRR... The only reason for that paragraph is that strictly, based on the LSRR = presence, the packet could be destined to a different end device than = the one on the IP address destination, based on the pointer. In other = words, the ip address points to an intermediate device. Now, that does = not create loops. > So not only did it not arrive at the destination it also could be used = to ddos A. >=20 No. See above. > 4.4.5 >=20 > different device that=20 >=20 > should be: > different device than >=20 >=20 >=20 >=20 Yes. Net-net: "optimise" -> "optimize", and "that" -> "than". Thank you, Carlos. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@centurylink.com >=20 >=20 >=20 > From: OPSEC [opsec-bounces@ietf.org] on behalf of joel jaeggli = [joelja@bogus.com] > Sent: Wednesday, December 11, 2013 10:28 AM > To: opsec@ietf.org; = draft-ietf-opsec-ip-options-filtering@tools.ietf.org > Subject: [OPSEC] post iesg final version of = draft-ietf-opsec-ip-options-filtering (07) >=20 >=20 > you can refer to the diff here. >=20 > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering= -07.txt >=20 > if anyone has issue with any of the changes made to address iesg = review > or post-last-call change please squawk soon. >=20 > thanks > joel --Apple-Mail=_9F994E4B-F126-4788-9ABE-BE1ED4FAD110 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKtxegACgkQtfDPGTp3USyJEQCgrcNoQ00Dmgb/v3GcXJBstmZS C0MAoMGYySxi+nwRZFwotlQHzbfPyzOP =x2eY -----END PGP SIGNATURE----- --Apple-Mail=_9F994E4B-F126-4788-9ABE-BE1ED4FAD110-- From joelja@bogus.com Sun Dec 15 07:56:28 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0D01ADF83 for ; Sun, 15 Dec 2013 07:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_rGDyKOV5OC for ; Sun, 15 Dec 2013 07:56:25 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA841ADF26 for ; Sun, 15 Dec 2013 07:56:25 -0800 (PST) Received: from mb-aye.lan (50-0-150-57.dsl.static.sonic.net [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id rBFFuICd046070 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 15 Dec 2013 15:56:19 GMT (envelope-from joelja@bogus.com) Message-ID: <52ADD121.1050401@bogus.com> Date: Sun, 15 Dec 2013 07:56:17 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , "Smith, Donald" References: <52A8A0DA.3030002@bogus.com> <68EFACB32CF4464298EA2779B058889D1238C1AA@PDDCWMBXEX503.ctl.intranet> <38259622-8A5E-4014-AA02-64F29A1A7D48@cisco.com> In-Reply-To: <38259622-8A5E-4014-AA02-64F29A1A7D48@cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gCf094K0S8Xbf89MTrRqG7PBO0KTe643N" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 15 Dec 2013 15:56:20 +0000 (UTC) Cc: "opsec@ietf.org" , "draft-ietf-opsec-ip-options-filtering@tools.ietf.org" Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 15:56:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gCf094K0S8Xbf89MTrRqG7PBO0KTe643N Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable fwiw the rfc editor will do a scrub of the text. thanks joel On 12/15/13, 7:08 AM, Carlos Pignataro (cpignata) wrote: > Donald, >=20 > Thank you for your comments, please see inline. >=20 > On Dec 14, 2013, at 8:29 PM, Smith, Donald wrote: >=20 >> Shouldn't this be environment not environments ? >> 1.... >> Additionally, it outlines what a network operator might do in a typica= l enterprise or Service Provider environments. >> >=20 > Seems like something the RFC Editor would catch if it is incorrect. >=20 > "Environment" in singular potentially 'sounds' better; however, your pr= oposal seems incorrect without an "a" before "Service Provider". In any c= ase -- to me, if the sentence intends to convey "in a typical enterprise = environment or a typical SP environment" (i.e., "environment" applying to= both), then "in a typical enterprise or SP environments" should be corre= ct as-is. >=20 > That said, we could make a note and ask the RFC Editor. Thank you.=20 >=20 >> >> 1.2. Operational Focus =20 >> >> All of the recommendations in this document have been made in an= =20 >> effort to optimise for operational community consensus, as best = the =20 >> editors have been able to determine that. =20 >> >> optimize not optimiSe and that isn't English. That is it isn't a compl= ete thought/sentence that I can understand anyways? >=20 > I can say the same thing about your comment :-) What exactly is not Eng= lish? It is not clear :-) >=20 > We can make an RFC Editor note to replace "optimise" with "optimize". T= hank you. >=20 > I think "optimize" is American and "optimise" is British, but the dicti= onary recognizes (and recognises) both. >=20 >> >> Technical against the draft not just the iesg additions!! >> I swear I said this before but ISPs and others are going to want at le= ast one more option (possibly two) here. >> >> 4.3.5. Advice =20 >> >> Routers, security gateways, and firewalls SHOULD implement an option- = =20 >> specific configuration knob whether packets with this option are dropp= ed, packets with this IP option are forwarded as if they did not contain = this IP option, or packets with this option are processed and forwarded = as per [RFC0791]. =20 >> >> >> Does drop that imply silently drop? (I think it does as opposed to den= y where an icmp error should be sent). Shouldn't there be a deny with som= e icmp code being sent saying the packet contained unsupported options? E= ither 3,5 (source router failed for SSRR or LSRR) or 3,9 (admin prohibite= d) for other options? >> >=20 > To prevent misuse of CPU resources, this does not send an ICMP. Similar= to 4.11.3. >=20 > Additionally, both your proposals would be incorrect. ICMP 3/5 is incor= rect since it is not a failure of the source route, ICMP 3/9 as well as I= CMP3/10 are also incorrect, because what is admin prohibited is neither t= he network nor the host. There is no ICMP type that says "option admin pr= ohibited", and we do not want to create one. >=20 >> Forwarded as if they did not contain ... is commonly called ignored or= not processed. I like spelling it out but lets give it a short version n= ame for router heads/configs. >> >=20 > Yes, we use "ignore" throughout. >=20 >> >> Next we SHOULD permit a "clear" where by the device removes the unwant= ed options and repads/rechecksums the packet if it could potentially be d= angerous to an "inner" device. >> >=20 > Do you know of any device that supports that? This is a BCP for current= practices. >=20 >> This: >> Please note that treating packets with LSRR as if they did not =20 >> contain this option can result in such packets being sent to a = >> different device that the initially intended destination. With = =20 >> appropriate ingress filtering this should not open an attack vec= tor =20 >> into the infrastructure. Nonetheless, it could result in traffi= c =20 >> that would never reach the initially intended destination. Drop= ping =20 >> these packets prevents unnecessary network traffic, and does not= make =20 >> end-to-end communication any worse. =20 >> >> >> Should be this: >> Please note that treating packets with LSRR as if they did not =20 >> contain this option can result in such packets being sent to a = >> different device THAN the initially intended destination. With = =20 >> appropriate ingress filtering this should not open an attack vec= tor =20 >> into the infrastructure. Nonetheless, it could result in traffi= c =20 >> that would never reach the initially intended destination. Drop= ping =20 >> these packets prevents unnecessary network traffic, and does not= make =20 >> end-to-end communication any worse. =20 >> >=20 > OK, we can have an RFC Editor note to replace "that" with "than". >=20 >> It also isn't true:( >> >> Consider a LSRR A-B-C-D=20 >> If A received it and ignores it (including the record route part) and = hands it off to something next to A (1 hop away) that device could hand i= t back to A (since it should be in the RR path but isn't) causing a loop = that bounces between A and it neighbor until the ttl expires right? >=20 > Wrong. >=20 > If A ignores the option, it means if performs forwarding based on the d= estination IP address in the IP Header. If it sends it to B, B does the s= ame IP header address destination-based forwarding, why would it send it = to A? I mean, of course unless there is a routing loop regardless of the = presence of LSRR... >=20 > The only reason for that paragraph is that strictly, based on the LSRR = presence, the packet could be destined to a different end device than the= one on the IP address destination, based on the pointer. In other words,= the ip address points to an intermediate device. Now, that does not crea= te loops. >=20 >> So not only did it not arrive at the destination it also could be used= to ddos A. >> >=20 > No. See above. >=20 >> 4.4.5 >> >> different device that=20 >> >> should be: >> different device than >> >> >> >> >=20 > Yes. >=20 > Net-net: "optimise" -> "optimize", and "that" -> "than". >=20 > Thank you, >=20 > Carlos. >=20 >> >> >> >> >> >> >> >> >> >> >> >> >> (coffee !=3D sleep) & (!coffee =3D=3D sleep) >> Donald.Smith@centurylink.com >> >> >> >> From: OPSEC [opsec-bounces@ietf.org] on behalf of joel jaeggli [joelja= @bogus.com] >> Sent: Wednesday, December 11, 2013 10:28 AM >> To: opsec@ietf.org; draft-ietf-opsec-ip-options-filtering@tools.ietf.o= rg >> Subject: [OPSEC] post iesg final version of draft-ietf-opsec-ip-option= s-filtering (07) >> >> >> you can refer to the diff here. >> >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filte= ring-07.txt >> >> if anyone has issue with any of the changes made to address iesg revie= w >> or post-last-call change please squawk soon. >> >> thanks >> joel >=20 --gCf094K0S8Xbf89MTrRqG7PBO0KTe643N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKt0SIACgkQ8AA1q7Z/VrJ2NACbBa+kqVGEnPCbBgcF1udC0WYR 9jAAnjHE2TTpp/dA+cFJIyJeUX2JC9nZ =E121 -----END PGP SIGNATURE----- --gCf094K0S8Xbf89MTrRqG7PBO0KTe643N-- From heard@pobox.com Sun Dec 15 07:57:18 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD34F1ADF83 for ; Sun, 15 Dec 2013 07:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[SPF_NEUTRAL=0.652] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4VunmGIPjXq for ; Sun, 15 Dec 2013 07:57:17 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9AE1ADF26 for ; Sun, 15 Dec 2013 07:57:14 -0800 (PST) Received: (qmail 11848 invoked from network); 15 Dec 2013 07:57:13 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Dec 2013 07:57:13 -0800 Date: Sun, 15 Dec 2013 07:57:13 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: "Smith, Donald" In-Reply-To: <68EFACB32CF4464298EA2779B058889D1238C1AA@PDDCWMBXEX503.ctl.intranet> Message-ID: References: <52A8A0DA.3030002@bogus.com> <68EFACB32CF4464298EA2779B058889D1238C1AA@PDDCWMBXEX503.ctl.intranet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "opsec@ietf.org" , "draft-ietf-opsec-ip-options-filtering@tools.ietf.org" Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 15:57:19 -0000 On Sun, 15 Dec 2013, Smith, Donald wrote: > This: > Please note that treating packets with LSRR as if they did not > contain this option can result in such packets being sent to a > different device that the initially intended destination. With > appropriate ingress filtering this should not open an attack vector > into the infrastructure. Nonetheless, it could result in traffic > that would never reach the initially intended destination. Dropping > these packets prevents unnecessary network traffic, and does not make > end-to-end communication any worse. > > > Should be this: > Please note that treating packets with LSRR as if they did not > contain this option can result in such packets being sent to a > different device THAN the initially intended destination. With > appropriate ingress filtering this should not open an attack vector > into the infrastructure. Nonetheless, it could result in traffic > that would never reach the initially intended destination. Dropping > these packets prevents unnecessary network traffic, and does not make > end-to-end communication any worse. > > It also isn't true:( Actually, it IS true. > Consider a LSRR A-B-C-D In this case, when the packet is originated the destination address in the IP header is A and the LSRR route contains BCD with the pointer pointing to B. > If A received it and ignores it (including the record route part) > and hands it off to something next to A (1 hop away) that device > could hand it back to A (since it should be in the RR path but > isn't) causing a loop that bounces between A and it neighbor until > the ttl expires right? So not only did it not arrive at the > destination it also could be used to ddos A. No. If A receives the packet and ignores LSRR it won't forward the packet at all; rather, it will assume that the packet is destined for itself because the destination address in the IP header is A. In other words, the packet will be delivered to A and not to D. //xmh From mbehring@cisco.com Mon Dec 16 07:15:06 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92F61ADE8A for ; Mon, 16 Dec 2013 07:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB7y8v_RGTpf for ; Mon, 16 Dec 2013 07:15:05 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7D05F1AE032 for ; Mon, 16 Dec 2013 07:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1387; q=dns/txt; s=iport; t=1387206905; x=1388416505; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cLuDZIwNN0pbgRqBxIv3qC5yTvxL5Q2VfKYhg4RLXa8=; b=DbCKVEyfXpI8MH8sq3pF5IIuHCJmxyB1tW8e4VpV690Srn2Lgb+qYW5z whDNp5myhO8kCSXfATC8fZ/G/vci/rt0Q+M65flvwJko7BUIfdMoq/Pcj /d6A3Yakvepkw2wMDohiaJycbJeK8cVxj0gSkySs8y0ligWK3P33FBAcx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAHwYr1KtJV2c/2dsb2JhbABZgwqBDbhzgSUWdIIlAQEBBDorFAwEAgEIEQQBAQsUCQcyFAkIAQEEDgUIh3zIDReOaDEHBoMdgRMBA6oqgyqCKg X-IronPort-AV: E=Sophos;i="4.95,495,1384300800"; d="scan'208";a="291835126" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 16 Dec 2013 15:15:03 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBGFF4kr029685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 15:15:04 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 09:15:03 -0600 From: "Michael Behringer (mbehring)" To: Warren Kumari Thread-Topic: [OPSEC] Review of draft-ietf-opsec-lla-only-05 Thread-Index: Ac7wWSDptQScqWK/Td6betnie2vjoQAObcUAAA8TlRAAHeyngADc0dXg Date: Mon, 16 Dec 2013 15:15:03 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D927A25@xmb-rcd-x14.cisco.com> References: <80f95840f7a649bdb0d1ad2f7bd51fc2@CO1PR05MB442.namprd05.prod.outlook.com> <9A2B514E-613F-4837-9B56-23B020508C1B@arbor.net> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D8FFB77@xmb-rcd-x14.cisco.com> <3FB5AA3E-2B83-4DF1-90B5-AABF70C0F874@kumari.net> In-Reply-To: <3FB5AA3E-2B83-4DF1-90B5-AABF70C0F874@kumari.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 15:15:07 -0000 Warren, [sorry for late reply] > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: 04 December 2013 18:16 > To: Michael Behringer (mbehring) > Cc: Warren Kumari; Dobbins, Roland; opsec@ietf.org > Subject: Re: [OPSEC] Review of draft-ietf-opsec-lla-only-05 [...] > I have read all the versions of this document and think that the tone has > greatly improved, but feel that section 2.5 (Summary) still has a bit too > much of the "this is a good idea" feel. Personally I think that the Summa= ry > section doesn't really add anything to the document and should be > dropped. So I've been told throughout school and uni that a document should have int= ro, body and summary; I'm feeling somewhat reluctant to drop a summary, it = just seems wrong. :-) Let's see whether we can get one that "feels" right.= What about: Using exclusively link-local addressing on infrastructure links has a nu= mber of advantages and disadvantages, which are both described in detail in this document. A network operator can use this document to evaluate whether using link-local addressing on infrastructure links is a good idea in the context of his/her network or not. This document=20 makes no particular recommendation either in favour or against.=20 I think this should be balanced, would you agree?=20 Michael From Donald.Smith@CenturyLink.com Mon Dec 16 08:02:22 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15551AE365 for ; Mon, 16 Dec 2013 08:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp665JV5iIbl for ; Mon, 16 Dec 2013 08:02:20 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id E03D81AE33B for ; Mon, 16 Dec 2013 08:02:19 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id rBGG2IGF020579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Dec 2013 09:02:19 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 6BB2F1E005D; Mon, 16 Dec 2013 10:02:13 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 4DF391E004D; Mon, 16 Dec 2013 10:02:13 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rBGG2CxZ017141; Mon, 16 Dec 2013 10:02:12 -0600 (CST) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rBGG25GN016888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 10:02:12 -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.03.0158.001; Mon, 16 Dec 2013 09:02:09 -0700 From: "Smith, Donald" To: "C. M. Heard" Thread-Topic: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) Thread-Index: AQHO9paC0SUkEz7wY0G+NCREROK1Q5pUZYK4gAF/TYCAARu+UA== Date: Mon, 16 Dec 2013 16:02:09 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D1238C5EB@PDDCWMBXEX503.ctl.intranet> References: <52A8A0DA.3030002@bogus.com> <68EFACB32CF4464298EA2779B058889D1238C1AA@PDDCWMBXEX503.ctl.intranet>, In-Reply-To: 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 Cc: "opsec@ietf.org" , "draft-ietf-opsec-ip-options-filtering@tools.ietf.org" Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 16:02:22 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: C. M. Heard [heard@pobox.com] Sent: Sunday, December 15, 2013 8:57 AM To: Smith, Donald Cc: opsec@ietf.org; draft-ietf-opsec-ip-options-filtering@tools.ietf.org Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options= -filtering (07) > On Sun, 15 Dec 2013, Smith, Donald wrote: > > This: > > Please note that treating packets with LSRR as if they did not > > contain this option can result in such packets being sent= to a > > different device that the initially intended destination.= With > > appropriate ingress filtering this should not open an att= ack vector > > into the infrastructure. Nonetheless, it could result in= traffic > > that would never reach the initially intended destination= . Dropping > > these packets prevents unnecessary network traffic, and d= oes not make > > end-to-end communication any worse. > > > > > > Should be this: > > Please note that treating packets with LSRR as if they did not > > contain this option can result in such packets being sent= to a > > different device THAN the initially intended destination.= With > > appropriate ingress filtering this should not open an att= ack vector > > into the infrastructure. Nonetheless, it could result in= traffic > > that would never reach the initially intended destination= . Dropping > > these packets prevents unnecessary network traffic, and d= oes not make > > end-to-end communication any worse. > > > > It also isn't true:( > > Actually, it IS true. > > > Consider a LSRR A-B-C-D > > In this case, when the packet is originated the destination addres= s > in the IP header is A and the LSRR route contains BCD with the > pointer pointing to B. Yea I could be confused as most of us don't support any type of SRR so I ha= ven't had much experience in it. I am always willing to learn so thanks for any education you can provide me= ! It states what to do if you receive a SRR and the pointer is still valid. B= ut I don't see where it defines the creation of the original SRR packet wit= h A in the destination field? >From rfc791.=20 If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four. Does that mean when created the host must copy the first octet from the opt= ion ssr field into the destination address field? Or is that defined somewhere else? I assumed a host with a default router would, in at least LSRR, send the pa= cket to it's default gateway (as the destination addr) is that incorrect? > > In this case, when the packet is originated the destination addres= s > in the IP header is A and the LSRR route contains BCD with the > pointer pointing to B. > > > If A received it and ignores it (including the record route part= ) > > and hands it off to something next to A (1 hop away) that device > > could hand it back to A (since it should be in the RR path but > > isn't) causing a loop that bounces between A and it neighbor unt= il > > the ttl expires right? So not only did it not arrive at the > > destination it also could be used to ddos A. > > No. If A receives the packet and ignores LSRR it won't forward th= e > packet at all; rather, it will assume that the packet is destined > for itself because the destination address in the IP header is A. > In other words, the packet will be delivered to A and not to D. In which case we can and should expect a response if you sent a packet to m= ost routers on a closed port it would send back a tcp reset or a icmp error= saying the port was closed (or maybe silently drop as that is an option to= o). But I don't see where the initial packet assembly is defined only what to d= o when a system receives a SSR with options and valid pointer (not complete= yet). > > //xmh > >= From warren@kumari.net Mon Dec 16 08:19:16 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC91AE35A for ; Mon, 16 Dec 2013 08:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52ZqZ7l6jvAA for ; Mon, 16 Dec 2013 08:19:13 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66EC1ADF83 for ; Mon, 16 Dec 2013 08:19:13 -0800 (PST) Received: from [172.29.46.153] (unknown [72.14.227.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 95A8D1B405B4; Mon, 16 Dec 2013 11:19:12 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Dec 2013 11:19:11 -0500 Message-Id: <0FC5E5F0-016A-457C-9F05-449FB9DAE64C@kumari.net> To: "" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Cc: Warren Kumari Subject: [OPSEC] Stepping down as OpSec Chair. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 16:19:16 -0000 Hi all, I=92d like to thank everyone for the opportunity to have served as one = of your chairs. I have had a fun time doing this, and think that we have made some good = progress, but unfortunately I no longer have the cycles / to serve you = as well as I should.=20 I leave the WG in the capable hands of KK and Gunter. I have been = thinking about this for a while, and believe that the transition will go = well. Once again, thank you all for making this a fun and interesting working = group, W -- Hope is not a strategy. -- Ben Treynor, Google From joelja@bogus.com Mon Dec 16 08:49:22 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927B31AE35F for ; Mon, 16 Dec 2013 08:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwQoEs9P4HTd for ; Mon, 16 Dec 2013 08:49:21 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E85FE1ADF50 for ; Mon, 16 Dec 2013 08:49:20 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id rBGGnJRw052939 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 16 Dec 2013 16:49:20 GMT (envelope-from joelja@bogus.com) Message-ID: <52AF2F0A.8010806@bogus.com> Date: Mon, 16 Dec 2013 08:49:14 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: Warren Kumari , "" References: <0FC5E5F0-016A-457C-9F05-449FB9DAE64C@kumari.net> In-Reply-To: <0FC5E5F0-016A-457C-9F05-449FB9DAE64C@kumari.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1D9gKwEXJV9pfQMDl9hUOiDOlr94q9Cru" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 16 Dec 2013 16:49:20 +0000 (UTC) Subject: Re: [OPSEC] Stepping down as OpSec Chair. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 16:49:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1D9gKwEXJV9pfQMDl9hUOiDOlr94q9Cru Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'd like to thank Warren for his stewardship. Opsec has been well served.= I think that for now we will hold at two chairs as K.K. and Gunter have been doing an excellent job. Thanks joel On 12/16/13, 8:19 AM, Warren Kumari wrote: > Hi all, >=20 > I=92d like to thank everyone for the opportunity to have served as one = of your chairs. > I have had a fun time doing this, and think that we have made some good= progress, but unfortunately I no longer have the cycles / to serve you a= s well as I should.=20 >=20 > I leave the WG in the capable hands of KK and Gunter. I have been think= ing about this for a while, and believe that the transition will go well.= >=20 > Once again, thank you all for making this a fun and interesting working= group, > W >=20 > -- > Hope is not a strategy. > -- Ben Treynor, Google >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --1D9gKwEXJV9pfQMDl9hUOiDOlr94q9Cru Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKvLwoACgkQ8AA1q7Z/VrL3egCdHWi8GAjXpOAV9B2MMVWC8fAn SDoAn0K25ViGQ2pMHhQ4fvoXY5RRBzHB =7JV2 -----END PGP SIGNATURE----- --1D9gKwEXJV9pfQMDl9hUOiDOlr94q9Cru-- From heard@pobox.com Mon Dec 16 09:16:01 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFD01AE35D for ; Mon, 16 Dec 2013 09:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhrpeicwWPu2 for ; Mon, 16 Dec 2013 09:15:59 -0800 (PST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FC01AE30E for ; Mon, 16 Dec 2013 09:15:58 -0800 (PST) Received: (qmail 29332 invoked from network); 16 Dec 2013 09:15:55 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Dec 2013 09:15:55 -0800 Date: Mon, 16 Dec 2013 09:15:55 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: "Smith, Donald" In-Reply-To: <68EFACB32CF4464298EA2779B058889D1238C5EB@PDDCWMBXEX503.ctl.intranet> Message-ID: References: <52A8A0DA.3030002@bogus.com> <68EFACB32CF4464298EA2779B058889D1238C1AA@PDDCWMBXEX503.ctl.intranet>, <68EFACB32CF4464298EA2779B058889D1238C5EB@PDDCWMBXEX503.ctl.intranet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "opsec@ietf.org" Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:16:02 -0000 On Mon, 16 Dec 2013, Smith, Donald wrote: > [ ... ] > From: C. M. Heard [heard@pobox.com] > Sent: Sunday, December 15, 2013 8:57 AM > To: Smith, Donald > Cc: opsec@ietf.org; draft-ietf-opsec-ip-options-filtering@tools.ietf.org > Subject: Re: [OPSEC] post iesg final version of draft-ietf-opsec-ip-options-filtering (07) > > On Sun, 15 Dec 2013, Smith, Donald wrote: [ ... ] > > > Consider a LSRR A-B-C-D > > > > In this case, when the packet is originated the destination address > > in the IP header is A and the LSRR route contains BCD with the > > pointer pointing to B. > > Yea I could be confused as most of us don't support any type of SRR so I haven't had much experience in it. > I am always willing to learn so thanks for any education you can provide me! > > It states what to do if you receive a SRR and the pointer is still > valid. But I don't see where it defines the creation of the > original SRR packet with A in the destination field? > From rfc791. > If the address in destination address field has been reached and > the pointer is not greater than the length, the next address in > the source route replaces the address in the destination address > field, and the recorded route address replaces the source > address just used, and pointer is increased by four. > > Does that mean when created the host must copy the first octet from the option ssr field into the destination address field? > Or is that defined somewhere else? The explanation in RFC 791 is, shall we say, just a bit terse. Excellent supplemental explanation may be found in RFC 1122 and RFC 1812. For this particular question see the DISCUSSION at the top of Page 37 in RFC 1122 for a picture of the correct way to format a source route option at the originating host. > I assumed a host with a default router would, in at least LSRR, send the packet to it's default gateway (as the destination > addr) is that incorrect? The originating host would typically send te packet to its default gateway, though it could in principle choose another gateway if it knew about one. For LSRR the destination address in the IP header would not necessarily be the address of that gateway. For SSRR the destination is required to be the addess of the first-hop gateway. > > > > In this case, when the packet is originated the destination address > > in the IP header is A and the LSRR route contains BCD with the > > pointer pointing to B. > > > > > If A received it and ignores it (including the record route part) > > > and hands it off to something next to A (1 hop away) that device > > > could hand it back to A (since it should be in the RR path but > > > isn't) causing a loop that bounces between A and it neighbor until > > > the ttl expires right? So not only did it not arrive at the > > > destination it also could be used to ddos A. > > > > No. If A receives the packet and ignores LSRR it won't forward the > > packet at all; rather, it will assume that the packet is destined > > for itself because the destination address in the IP header is A. > > In other words, the packet will be delivered to A and not to D. > > In which case we can and should expect a response if you sent a packet to most routers on a closed port it would send back a tcp > reset or a icmp error saying the port was closed (or maybe silently drop as that is an option too). Yes, those are possible outcomes. Even if the port is not closed and the router accepts the packet for processing, it would probably fail the checksum test if the payload was TCP or UDP because the IP address in the pseudo-header is the final destination address. This would cause a silent drop too. It's possible to concoct examples where the packet would not be rejected in this way but all the ones I've come up with are rather far-fetched. The effect on end-to-end communication is of course the same as dropping the packet, but just ignoring the option can put an extra processing load on an intermediate router, and that is not an especially desirable outcome. The purpose of the note in draft-ietf-opsec-ip-options-filtering-07 is to alert operators to this possibility. > But I don't see where the initial packet assembly is defined only what to do when a system receives a SSR with options and valid > pointer (not complete yet). Hopefully the reference to RFC 1122 that I provided above answers the question of initial packet assembly. A good explanation of what to do when the source route option is complete can be found in Section 5.2.4.1 of RFC 1812, which is at the top of page 72. If these references don't answer your questions please feel free to contact me on or off list and I'll see if I can dig up some better ones. Mike Heard From iesg-secretary@ietf.org Mon Dec 16 10:00:45 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81391ADF9B; Mon, 16 Dec 2013 10:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m-czIDpMk2H; Mon, 16 Dec 2013 10:00:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF6A1AE0C4; Mon, 16 Dec 2013 10:00:41 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131216180041.32680.90601.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2013 10:00:41 -0800 Cc: opsec mailing list , opsec chair , RFC Editor Subject: [OPSEC] Protocol Action: 'Recommendations on filtering of IPv4 packets containing IPv4 options.' to Best Current Practice (draft-ietf-opsec-ip-options-filtering-07.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 18:00:46 -0000 The IESG has approved the following document: - 'Recommendations on filtering of IPv4 packets containing IPv4 options.' (draft-ietf-opsec-ip-options-filtering-07.txt) as Best Current Practice This document is the product of the Operational Security Capabilities for IP Network Infrastructure Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/ Technical Summary This document discusses the operational and interoperability implications of filtering IPv4 packets based on the IPv4 options they contain. It also provides advice to operators who wish to do such filtering. Working Group Summary This document received in-depth review from some key WG members. The WGLC concluded that this is useful information that is presented in an easy to read format. Document Quality This documents evaluates, in detail, every IPv4 option that has been specified so far and provides the following analysis: 1) The use case for each option 2) Specific threats that have been identified with said option 3) Operational implications of blocking said option 4) Very specific advice to operators on how to deal with said option The format in which the information is provided makes this document very easy to read. This is very useful information for operators of Internet Service Provider and Enterprise networks. Personnel Kiran Kumar Chittimaneni (KK) is the Document Shepherd. Joel Jaeggli is the Area Director. From cpignata@cisco.com Mon Dec 16 12:20:42 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7C31AC4C5 for ; Mon, 16 Dec 2013 12:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.439 X-Spam-Level: X-Spam-Status: No, score=-14.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYmtUH4naGl1 for ; Mon, 16 Dec 2013 12:20:39 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 18A191AC4C1 for ; Mon, 16 Dec 2013 12:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3973; q=dns/txt; s=iport; t=1387225238; x=1388434838; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=+SUBrxJG232QcPASW7xDRm0vEC3QN7ohBMZEwP+zHZA=; b=S6OKbhg4ijqdGm0PiW/r0SzVS04dvcphZpSCR6rf/1pWFPsKA9zYEZsF LxcqXdPmz+wxHCWqbvcDqAiSOvhLrR1Uo3G1j2ZFC/Mn/FkMSYcrTb0Ad Bohe5Oir+BReyuF3PARyQ8TKkOcyuc9efbEc7evLndFHOTeQsw9ScXPWm Q=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAEJfr1KtJXHA/2dsb2JhbABZgwo4VbhxgSgWdIIlAQEBAwEBAQEkRxsCAQg7CycLFBECBAoJDoduCA3IGxePIIMjgRMEkDOBMYYygTCQZIFsgT6CKg X-IronPort-AV: E=Sophos;i="4.95,497,1384300800"; d="asc'?scan'208";a="291876748" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 16 Dec 2013 20:20:38 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBGKKb4Q014928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Dec 2013 20:20:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 14:20:37 -0600 From: "Carlos Pignataro (cpignata)" To: "opsec@ietf.org" Thread-Topic: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC Thread-Index: AQHO+pxHx7azAjJQKkqONuUSVv/EjQ== Date: Mon, 16 Dec 2013 20:20:37 +0000 Message-ID: <06F2262B-56D4-48E0-AB41-906BE04615F7@cisco.com> References: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> In-Reply-To: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.131.24.87] Content-Type: multipart/signed; boundary="Apple-Mail=_532B962B-5C20-41E8-9FAE-E0D0EC79081B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 20:20:42 -0000 --Apple-Mail=_532B962B-5C20-41E8-9FAE-E0D0EC79081B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Apologies for the lateness of these two small comments, and if it has = been made before -- Looking only at the title and first sentence of the Abstract: --->8--- Virtual Private Network (VPN) traffic leakages in dual-stack = hosts/networks Abstract The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. --->8--- I have one concern and one small comment: First, "VPN" is a pseudo-technical term, or a meta-term. If I = understand, this document refers to a very narrow slice of "VPNs" (not = to L1VPNs, not to L2VPNs, not to MP-BGP/MPLS IP VPNs, not to...). The = document seems to be (only?) focusing on client/concentrator VPNs, and = within these ones the IPsec ones. Can we make this very explicit in the = 1. title, 2. abstract, and even 3. a formal definition of scope? Second, are these "leakages" if the packets are not destined to go in = the tunnel? I guess if the "traffic" (i.e., payload) is not sent on the = IPsec tunnel, then it is leaked. But it is a bit borderline... The second is not a big deal, the first one is, IMHO. Thanks, -- Carlos. On Dec 2, 2013, at 7:53 AM, The IESG wrote: >=20 > The IESG has received a request from the Operational Security > Capabilities for IP Network Infrastructure WG (opsec) to consider the > following document: > - 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ > networks' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-12-16. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > The subtle way in which the IPv6 and IPv4 protocols co-exist in > typical networks, together with the lack of proper IPv6 support in > popular Virtual Private Network (VPN) products, may inadvertently > result in VPN traffic leaks. That is, traffic meant to be > transferred over a VPN connection may leak out of such connection = and > be transferred in the clear from the local network to the final > destination. This document discusses some scenarios in which such > VPN leakages may occur, either as a side effect of enabling IPv6 on = a > local network, or as a result of a deliberate attack from a local > attacker. Additionally, it discusses possible mitigations for the > aforementioned issue. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_532B962B-5C20-41E8-9FAE-E0D0EC79081B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKvYJMACgkQtfDPGTp3USzybwCeOUdsr4L5/aCNs779vXi56z1Q GRgAni3gBFlD2N985aD5YfA1Rgdoyrlv =K6ge -----END PGP SIGNATURE----- --Apple-Mail=_532B962B-5C20-41E8-9FAE-E0D0EC79081B-- From cpignata@cisco.com Mon Dec 16 14:40:18 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253061AD9A9 for ; Mon, 16 Dec 2013 14:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32ICCvnkqMjR for ; Mon, 16 Dec 2013 14:40:16 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9B87E1A1F5B for ; Mon, 16 Dec 2013 14:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1605; q=dns/txt; s=iport; t=1387233616; x=1388443216; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8z7/qlYwnfHVi9W8uuAE2NT/r01525x05X5s8ZhpXo0=; b=iEw4rG6J6uQkO6A7lVN5EmJW07vHeEE0HeB1WvrPSCHwxspGJn0phvf6 tfuzvA30FCYRzOpCLKBB7tZPeJ45SslZYwt5xr4vCGdFYsc/L8VkNVHGj Q6xiJS9BZewJt2H4m8b1n6v52KFoEol9cQn37FM7k0Ynd6ARXSpeoCfir 4=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAP+Ar1KtJXG+/2dsb2JhbABZgwo4VbhJgScWdIIlAQEBAwEBAQFrCwULAgEIRicLJQIEDgUOh24IDcgsEwSPGQeDI4ETBJAzgTGGMpIUgyqCKg X-IronPort-AV: E=Sophos;i="4.95,497,1384300800"; d="asc'?scan'208";a="291725583" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 16 Dec 2013 22:40:15 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBGMeFw1002986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 22:40:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 16:40:15 -0600 From: "Carlos Pignataro (cpignata)" To: Warren Kumari Thread-Topic: [OPSEC] Stepping down as OpSec Chair. Thread-Index: AQHO+nqTfKsDC59KeUCKnjbs7yrap5pXzzIA Date: Mon, 16 Dec 2013 22:40:14 +0000 Message-ID: References: <0FC5E5F0-016A-457C-9F05-449FB9DAE64C@kumari.net> In-Reply-To: <0FC5E5F0-016A-457C-9F05-449FB9DAE64C@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.131.24.87] Content-Type: multipart/signed; boundary="Apple-Mail=_E2AD798B-2D1E-49CE-BCC8-7C39595A4AC9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [OPSEC] Stepping down as OpSec Chair. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 22:40:18 -0000 --Apple-Mail=_E2AD798B-2D1E-49CE-BCC8-7C39595A4AC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Many thanks, Warren, for all your leadership and contributions as chair! On Dec 16, 2013, at 11:19 AM, Warren Kumari wrote: > Hi all, >=20 > I=92d like to thank everyone for the opportunity to have served as one = of your chairs. > I have had a fun time doing this, and think that we have made some = good progress, but unfortunately I no longer have the cycles / to serve = you as well as I should.=20 >=20 > I leave the WG in the capable hands of KK and Gunter. I have been = thinking about this for a while, and believe that the transition will go = well. >=20 > Once again, thank you all for making this a fun and interesting = working group, > W >=20 > -- > Hope is not a strategy. > -- Ben Treynor, Google >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_E2AD798B-2D1E-49CE-BCC8-7C39595A4AC9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKvgU4ACgkQtfDPGTp3USzSJwCgoPbTaROZDTiQ6omTY3EjQsgW NyoAnRiKlenBPVs23GZF6HaDJxIdflXg =MKLn -----END PGP SIGNATURE----- --Apple-Mail=_E2AD798B-2D1E-49CE-BCC8-7C39595A4AC9-- From bertietf@bwijnen.net Tue Dec 17 02:32:29 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6861ADDD2 for ; Tue, 17 Dec 2013 02:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxMPMuY38tht for ; Tue, 17 Dec 2013 02:32:27 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3FF1AE131 for ; Tue, 17 Dec 2013 02:32:26 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vsrwt-0006GC-RI; Tue, 17 Dec 2013 11:32:25 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest127.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Vsrwt-0002e1-MT; Tue, 17 Dec 2013 11:32:23 +0100 Message-ID: <52B02838.2050205@bwijnen.net> Date: Tue, 17 Dec 2013 11:32:24 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , Warren Kumari References: <0FC5E5F0-016A-457C-9F05-449FB9DAE64C@kumari.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41f39368178752b3880eb5d1da9b080c9 Cc: "" Subject: Re: [OPSEC] Stepping down as OpSec Chair. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:32:29 -0000 +1 Bert On 12/16/13 11:40 PM, Carlos Pignataro (cpignata) wrote: > Many thanks, Warren, for all your leadership and contributions as chair! > > On Dec 16, 2013, at 11:19 AM, Warren Kumari wrote: > >> Hi all, >> >> I’d like to thank everyone for the opportunity to have served as one of your chairs. >> I have had a fun time doing this, and think that we have made some good progress, but unfortunately I no longer have the cycles / to serve you as well as I should. >> >> I leave the WG in the capable hands of KK and Gunter. I have been thinking about this for a while, and believe that the transition will go well. >> >> Once again, thank you all for making this a fun and interesting working group, >> W >> >> -- >> Hope is not a strategy. >> -- Ben Treynor, Google >> >> >> _______________________________________________ >> 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 dromasca@avaya.com Tue Dec 17 02:34:19 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2EF1AE0B4 for ; Tue, 17 Dec 2013 02:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpVwsvs6kFe0 for ; Tue, 17 Dec 2013 02:34:17 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 59FF31AE142 for ; Tue, 17 Dec 2013 02:34:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFANMnsFLGmAcV/2dsb2JhbABZgmkhOFW4Z4EeFnSCJQEBAQEDAQEBDyg0CwwEAgEIDQQEAQEBChQJBycLFAkIAgQBDQUIGodiAQyldaJjEwSOYTEHBoMdgRMEnwKLKIMqgio X-IronPort-AV: E=Sophos;i="4.95,501,1384318800"; d="scan'208";a="41608302" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 Dec 2013 05:34:15 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 17 Dec 2013 05:26:16 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 11:34:13 +0100 From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Carlos Pignataro (cpignata)" , Warren Kumari Thread-Topic: [OPSEC] Stepping down as OpSec Chair. Thread-Index: AQHO+nqTtVSz9cNlPkenSc71a6t7fJpXWdkAgADG+gCAABEUQA== Date: Tue, 17 Dec 2013 10:34:12 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129F0FB6@AZ-FFEXMB04.global.avaya.com> References: <0FC5E5F0-016A-457C-9F05-449FB9DAE64C@kumari.net> <52B02838.2050205@bwijnen.net> In-Reply-To: <52B02838.2050205@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OPSEC] Stepping down as OpSec Chair. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:34:19 -0000 +1=20 Dan > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Bert Wijnen > (IETF) > Sent: Tuesday, December 17, 2013 12:32 PM > To: Carlos Pignataro (cpignata); Warren Kumari > Cc: > Subject: Re: [OPSEC] Stepping down as OpSec Chair. >=20 > +1 >=20 > Bert >=20 > On 12/16/13 11:40 PM, Carlos Pignataro (cpignata) wrote: > > Many thanks, Warren, for all your leadership and contributions as > chair! > > > > On Dec 16, 2013, at 11:19 AM, Warren Kumari wrote: > > > >> Hi all, > >> > >> I'd like to thank everyone for the opportunity to have served as one > of your chairs. > >> I have had a fun time doing this, and think that we have made some > good progress, but unfortunately I no longer have the cycles / to serve > you as well as I should. > >> > >> I leave the WG in the capable hands of KK and Gunter. I have been > thinking about this for a while, and believe that the transition will go > well. > >> > >> Once again, thank you all for making this a fun and interesting > >> working group, W > >> > >> -- > >> Hope is not a strategy. > >> -- Ben Treynor, Google > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From fgont@si6networks.com Sat Dec 21 21:56:46 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455531ADF9A for ; Sat, 21 Dec 2013 21:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSGQIibhSQVX for ; Sat, 21 Dec 2013 21:56:44 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id EF3E51AD942 for ; Sat, 21 Dec 2013 21:56:43 -0800 (PST) Received: from pc-61-59-47-190.cm.vtr.net ([190.47.59.61] helo=[192.168.0.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vuc1k-0004w8-DH; Sun, 22 Dec 2013 06:56:36 +0100 Message-ID: <52B67F0F.5030707@si6networks.com> Date: Sun, 22 Dec 2013 02:56:31 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , "opsec@ietf.org" References: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> <06F2262B-56D4-48E0-AB41-906BE04615F7@cisco.com> In-Reply-To: <06F2262B-56D4-48E0-AB41-906BE04615F7@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 05:56:46 -0000 Hola, Carlos, Thanks so much for your feedback! Please find my responses in-line... On 12/16/2013 05:20 PM, Carlos Pignataro (cpignata) wrote: > Apologies for the lateness of these two small comments, and if it > has been made before -- > > Looking only at the title and first sentence of the Abstract: > > --->8--- Virtual Private Network (VPN) traffic leakages in > dual-stack hosts/networks > > Abstract > > The subtle way in which the IPv6 and IPv4 protocols co-exist in > typical networks, together with the lack of proper IPv6 support in > popular Virtual Private Network (VPN) products, may inadvertently > result in VPN traffic leaks. --->8--- > > I have one concern and one small comment: > > First, "VPN" is a pseudo-technical term, or a meta-term. If I > understand, this document refers to a very narrow slice of "VPNs" > (not to L1VPNs, not to L2VPNs, not to MP-BGP/MPLS IP VPNs, not > to...). The document seems to be (only?) focusing on > client/concentrator VPNs, and within these ones the IPsec ones. > Can we make this very explicit in the 1. title, 2. abstract, and > even 3. a formal definition of scope? I'm currently working on a "Terminology" section which describes what we mean by "VPN". Regarding the title... I'm not sure it's easy to come up with something simple that makes this clear (particularly when, as you correctly state, "VPN" is kind of a meta-term)... Do you have any suggestions for some alternative title? wrt to the Abstract, how about changing it to: ---- cut here ---- The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular SSL-based or IPsec-based Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. [...] ---- cut here ---- ? I realize that this might still be a bit unclear, though. If you have any suggestions, please do let me know. > Second, are these "leakages" if the packets are not destined to go > in the tunnel? I guess if the "traffic" (i.e., payload) is not sent > on the IPsec tunnel, then it is leaked. But it is a bit > borderline... We deem it as a "leakage" when traffic to some destination is expected to go through the VPN, but doesn't. Trivial example: You employ e.g. OpenVPN to send all your traffic through some VPN gateway (e.g., some box at you office or home), but then connect to a dual-stacked network. If the destination is IPv6-enabled, your traffic will leak out of your VPN inadvertently. Thoughts? 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 cpignata@cisco.com Sun Dec 22 11:21:20 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B001AEA1F for ; Sun, 22 Dec 2013 11:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.439 X-Spam-Level: X-Spam-Status: No, score=-14.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YzOizGHMJHu for ; Sun, 22 Dec 2013 11:21:18 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7EE1ADFBD for ; Sun, 22 Dec 2013 11:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4086; q=dns/txt; s=iport; t=1387740075; x=1388949675; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6EcZ0ySQXvMXdTd0PKhxKwFh5/2K7zThL0yUKEFtKSI=; b=OLK7ZyW9VG8z9UkL/OPDIhU1lBsge9Yt5jM//FkKl4klIFkiKo3MR/hR hVPXWr6BPvxuBmMcUEUlP+cRTEz9GL8pgrans8efMOGhcegXdUtDr+R2l l2JaecFU3TDX9xNz0Ds18FLuRJFlL04QKck+t9/gVc+HOiv+Q12uGw8bj U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAC46t1KtJXHB/2dsb2JhbABYgwuBDbk/gRQWdIIlAQEBBCdiAgEIDgojCzIlAgQBEogEyxEXjnI6hDYBA5gXkhSBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,532,1384300800"; d="scan'208";a="290256104" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 22 Dec 2013 19:21:15 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBMJLFxv022674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Dec 2013 19:21:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.18]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Sun, 22 Dec 2013 13:21:14 -0600 From: "Carlos Pignataro (cpignata)" To: Fernando Gont , "opsec@ietf.org" Thread-Topic: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC Thread-Index: AQHO+pxHx7azAjJQKkqONuUSVv/EjZpgJHyAgACNAgA= Date: Sun, 22 Dec 2013 19:21:14 +0000 Message-ID: References: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> <06F2262B-56D4-48E0-AB41-906BE04615F7@cisco.com> <52B67F0F.5030707@si6networks.com> In-Reply-To: <52B67F0F.5030707@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.239.63] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5D09CAC1DB960B4C889D77C4E9C19BE5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 19:21:20 -0000 Hola, Fernando! On 12/22/13, 12:56 AM, "Fernando Gont" wrote: >Hola, Carlos, > >Thanks so much for your feedback! Please find my responses in-line... Anytime=8A please see inline. > >On 12/16/2013 05:20 PM, Carlos Pignataro (cpignata) wrote: >> Apologies for the lateness of these two small comments, and if it >> has been made before -- >>=20 >> Looking only at the title and first sentence of the Abstract: >>=20 >> --->8--- Virtual Private Network (VPN) traffic leakages in >> dual-stack hosts/networks >>=20 >> Abstract >>=20 >> The subtle way in which the IPv6 and IPv4 protocols co-exist in >> typical networks, together with the lack of proper IPv6 support in >> popular Virtual Private Network (VPN) products, may inadvertently >> result in VPN traffic leaks. --->8--- >>=20 >> I have one concern and one small comment: >>=20 >> First, "VPN" is a pseudo-technical term, or a meta-term. If I >> understand, this document refers to a very narrow slice of "VPNs" >> (not to L1VPNs, not to L2VPNs, not to MP-BGP/MPLS IP VPNs, not >> to...). The document seems to be (only?) focusing on >> client/concentrator VPNs, and within these ones the IPsec ones. >> Can we make this very explicit in the 1. title, 2. abstract, and >> even 3. a formal definition of scope? > >I'm currently working on a "Terminology" section which describes what >we mean by "VPN". This is a good start. > >Regarding the title... I'm not sure it's easy to come up with >something simple that makes this clear (particularly when, as you >correctly state, "VPN" is kind of a meta-term)... Do you have any >suggestions for some alternative title? I think that, for the title, saying =B3VPN traffic leakages=B2 is too gener= ic to be accurate, and you need to qualify =B3VPN=B2. The document seems to hint at the type of VPNs in scope. Although this would be more clear after the terminology section, basically the document covers VPNs that are: 1. Hub-and-Spoke (I.e., client-based in a client-gateway model) VPNs, as opposed to Mesh VPNs (MPLS BGP VPNs). 2. Encryption-based VPNs (given the mentions of =B3in the clear=B2), as opposed to simply tunneling. This is similar to the Cisco AnyConnect software client in my mac. Based on this, =B3Client-based encryption-based VPNs=B2? Again, maybe it will be more clear after the terminology section. > >wrt to the Abstract, how about changing it to: > >---- cut here ---- > The subtle way in which the IPv6 and IPv4 protocols co-exist in > typical networks, together with the lack of proper IPv6 support in > popular SSL-based or IPsec-based Virtual Private Network (VPN) > products, may inadvertently result in VPN traffic leaks. >[...] >---- cut here ---- > >? I think this covers one of the qualities (SSL-based or IPsec-based) but not the other (client-based vs. full mesh). > >I realize that this might still be a bit unclear, though. If you have >any suggestions, please do let me know. I do think it=B9s better, but not quite there yet. > > >> Second, are these "leakages" if the packets are not destined to go >> in the tunnel? I guess if the "traffic" (i.e., payload) is not sent >> on the IPsec tunnel, then it is leaked. But it is a bit >> borderline... > >We deem it as a "leakage" when traffic to some destination is expected >to go through the VPN, but doesn't. Trivial example: You employ e.g. >OpenVPN to send all your traffic through some VPN gateway (e.g., some >box at you office or home), but then connect to a dual-stacked >network. If the destination is IPv6-enabled, your traffic will leak >out of your VPN inadvertently. I agree with your perspective. Although it can be argued both ways, I do think it is totally fair to call it a leakage in this case. > >Thoughts? > >Thanks! Thanks, =8B Carlos. > >Best regards, >--=20 >Fernando Gont >SI6 Networks >e-mail: fgont@si6networks.com >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From fgont@si6networks.com Sun Dec 22 11:52:40 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1671E1AEAE6 for ; Sun, 22 Dec 2013 11:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IFalr_XDP52 for ; Sun, 22 Dec 2013 11:52:37 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 173E71AEAE5 for ; Sun, 22 Dec 2013 11:52:36 -0800 (PST) Received: from pc-61-59-47-190.cm.vtr.net ([190.47.59.61] helo=[192.168.0.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vup4f-0007Q5-FK; Sun, 22 Dec 2013 20:52:29 +0100 Message-ID: <52B742AB.30202@si6networks.com> Date: Sun, 22 Dec 2013 16:51:07 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , "opsec@ietf.org" References: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> <06F2262B-56D4-48E0-AB41-906BE04615F7@cisco.com> <52B67F0F.5030707@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 19:52:40 -0000 On 12/22/2013 04:21 PM, Carlos Pignataro (cpignata) wrote: >> >> I'm currently working on a "Terminology" section which describes what >> we mean by "VPN". > > This is a good start. FWIW, this is what we hae at the time of this writing (still subject to comments and edits); ---- cut here ---- When employing the term VPN (or its acronym, "VPN"), this document refers to IPsec-based or TLS-based tunnels, where traffic is encapsulated and sent from a client to a middle-box, to access multiple network services (potentially emplying different transport and/or application protocols). Our use of the term "Virtual Private Networks" excludes the so-called SSL/TLS VPN portals (a front-end provided by the middlebox to add security to a normally-unsecured site). Further discussion of SSL- based VPNs can be found in [SSL-VPNs]. We note that, in addition to the general case of "send all traffic through the VPN", this document additionally considers the so-called "split-tunnel" case, where some subset of the traffic is sent through the VPN, while other traffic is send to its intended destination with a direct routing path (i.e., without employing the VPN tunnel). We note that many organizations will prevent split-tunneling in their VPN configurations if they would like to make sure the users data goes through a gateway with protections (malware detection, URL filtering, etc.), but others are more interested in performance of the user's access or the ability for researchers to have options to access sites they may not be able to through the gateway. ---- cut here ---- Where: [SSL-VPNs] Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72, SAAG Meeting., 2008, . >> Regarding the title... I'm not sure it's easy to come up with >> something simple that makes this clear (particularly when, as you >> correctly state, "VPN" is kind of a meta-term)... Do you have any >> suggestions for some alternative title? > > I think that, for the title, saying ³VPN traffic leakages² is too generic > to be accurate, and you need to qualify ³VPN². Is that possible in a one-liner? > The document seems to hint at the type of VPNs in scope. Although this > would be more clear after the terminology section, basically the document > covers VPNs that are: > 1. Hub-and-Spoke (I.e., client-based in a client-gateway model) VPNs, as > opposed to Mesh VPNs (MPLS BGP VPNs). > 2. Encryption-based VPNs (given the mentions of ³in the clear²), as > opposed to simply tunneling. Please see if the above text clarifies this point. > This is similar to the Cisco AnyConnect software client in my mac. > > Based on this, ³Client-based encryption-based VPNs²? Client-based would seem to still lead to ambiguity. Also, some parts of the I-D notes that some VPNs may not employ encryption 8even when for the most part we focus on VPNs that do encryption). My take is that one way or another we'll ahve to live with a generic title which makes sense when one defines the terminology... thoughts? > Again, maybe it will be more clear after the terminology section. > >> >> wrt to the Abstract, how about changing it to: >> >> ---- cut here ---- >> The subtle way in which the IPv6 and IPv4 protocols co-exist in >> typical networks, together with the lack of proper IPv6 support in >> popular SSL-based or IPsec-based Virtual Private Network (VPN) >> products, may inadvertently result in VPN traffic leaks. >> [...] >> ---- cut here ---- >> >> ? > > I think this covers one of the qualities (SSL-based or IPsec-based) but > not the other (client-based vs. full mesh). How about "...popular client-based (whether SSL or IPsec) Virtual Private Network..."? -- Although I'd like to check with Paul Hoffman et al before applying... Further suggestions welcome ;-) 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 cpignata@cisco.com Sun Dec 22 12:54:27 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F4C1AEC23 for ; Sun, 22 Dec 2013 12:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.439 X-Spam-Level: X-Spam-Status: No, score=-14.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Orcn7XN8FEHC for ; Sun, 22 Dec 2013 12:54:25 -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 D194D1AEC1B for ; Sun, 22 Dec 2013 12:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8208; q=dns/txt; s=iport; t=1387745662; x=1388955262; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9XDextBaJ+e6E2vySLSJS++qQ5MDQFKmvUtc7DHUoFE=; b=bWGZeG5wm2AEA0tuSBUuWwsEtNm10Dbz7IFg/+x/9f1vw00ay/kIOQtC AevoAvRZLyLsS96NBW4vRTJo1ugkiTSPXL9/l7YBMrDr/iac9yxpL0CJj IDXbpNBijrLXYkvraxL+iE8fyjLVfuHUw7qrwZhPSLSAgXykszhdHEGXH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAD9Qt1KtJXG//2dsb2JhbABYgws4VYMBtj8YfBZ0giUBAQECAQE0VQIBCA4KBB8JAgIwJQIEARIJh3MIDZUum2UGmWQXgSONZyKCaIFOAQOYF4EwkGSBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,532,1384300800"; d="scan'208";a="293257379" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 22 Dec 2013 20:54:21 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBMKsLRm020383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Dec 2013 20:54:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.18]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Sun, 22 Dec 2013 14:54:21 -0600 From: "Carlos Pignataro (cpignata)" To: Fernando Gont , "opsec@ietf.org" Thread-Topic: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC Thread-Index: AQHO+pxHx7azAjJQKkqONuUSVv/EjZpgJHyAgACNAgCAAFwtgP//vdeA Date: Sun, 22 Dec 2013 20:54:21 +0000 Message-ID: References: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> <06F2262B-56D4-48E0-AB41-906BE04615F7@cisco.com> <52B67F0F.5030707@si6networks.com> <52B742AB.30202@si6networks.com> In-Reply-To: <52B742AB.30202@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.239.63] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 20:54:27 -0000 VGhhbmtzIEZlcm5hbmRvLiBQbGVhc2Ugc2VlIGlubGluZS4NCg0KT24gMTIvMjIvMTMsIDI6NTEg UE0sICJGZXJuYW5kbyBHb250IiA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPiB3cm90ZToNCg0KPk9u IDEyLzIyLzIwMTMgMDQ6MjEgUE0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSB3cm90ZToN Cj4+Pg0KPj4+IEknbSBjdXJyZW50bHkgd29ya2luZyBvbiBhICJUZXJtaW5vbG9neSIgc2VjdGlv biB3aGljaCBkZXNjcmliZXMgd2hhdA0KPj4+IHdlIG1lYW4gYnkgIlZQTiIuDQo+PiANCj4+IFRo aXMgaXMgYSBnb29kIHN0YXJ0Lg0KPg0KPkZXSVcsIHRoaXMgaXMgd2hhdCB3ZSBoYWUgYXQgdGhl IHRpbWUgb2YgdGhpcyB3cml0aW5nIChzdGlsbCBzdWJqZWN0IHRvDQo+Y29tbWVudHMgYW5kIGVk aXRzKTsNCj4NCj4tLS0tIGN1dCBoZXJlIC0tLS0NCj4gICBXaGVuIGVtcGxveWluZyB0aGUgdGVy bSBWUE4gKG9yIGl0cyBhY3JvbnltLCAiVlBOIiksIHRoaXMgZG9jdW1lbnQNCj4gICByZWZlcnMg dG8gSVBzZWMtYmFzZWQgb3IgVExTLWJhc2VkIHR1bm5lbHMsIHdoZXJlIHRyYWZmaWMgaXMNCj4g ICBlbmNhcHN1bGF0ZWQgYW5kIHNlbnQgZnJvbSBhIGNsaWVudCB0byBhIG1pZGRsZS1ib3gsIHRv IGFjY2Vzcw0KPiAgIG11bHRpcGxlIG5ldHdvcmsgc2VydmljZXMgKHBvdGVudGlhbGx5IGVtcGx5 aW5nIGRpZmZlcmVudCB0cmFuc3BvcnQNCj4gICBhbmQvb3IgYXBwbGljYXRpb24gcHJvdG9jb2xz KS4NCg0KSSBkbyBub3QgdGhpbmsgdGhpcyBpcyB0aGUgYmVzdCBhcHByb2FjaC4gSGVyZSB5b3Ug YXJlIHNheWluZzogobB3aGVuIHdlDQpzYXkgVlBOIHdlIGFjdHVhbGx5IG1lYW4gdGhpcywgc28g d2Ugd2lsbCBtYWtlIHN0YXRlbWVudHMgYWJvdXQgVlBOc6GxLg0KSW5zdGVhZCwgSaGvZCBzdWdn ZXN0IHRoZSBtb3JlIHByZWNpc2UgYXBwcm9hY2ggaXMgdG8gc2F5IKGwaW4gdGhpcyBkb2N1bWVu dA0Kd2UgY29uc2lkZXIgRm9vYmFyIFZQTnMsIHNvIHdlIHdpbGwgbWFrZSBzdGF0ZW1lbnRzIGFi b3V0IEZvb2JhciBWUE5zobENCih3aGVyZSBGb29iYXIgaXMgYSBtb2RpZmllci9xdWFsaWZpZXIg b2YgVlBOLCBkZWZpbmVkIGluIHRoZSBkb2N1bWVudCkuDQoNCj4NCj4gICBPdXIgdXNlIG9mIHRo ZSB0ZXJtICJWaXJ0dWFsIFByaXZhdGUgTmV0d29ya3MiIGV4Y2x1ZGVzIHRoZSBzby1jYWxsZWQN Cj4gICBTU0wvVExTIFZQTiBwb3J0YWxzIChhIGZyb250LWVuZCBwcm92aWRlZCBieSB0aGUgbWlk ZGxlYm94IHRvIGFkZA0KPiAgIHNlY3VyaXR5IHRvIGEgbm9ybWFsbHktdW5zZWN1cmVkIHNpdGUp LiAgRnVydGhlciBkaXNjdXNzaW9uIG9mIFNTTC0NCj4gICBiYXNlZCBWUE5zIGNhbiBiZSBmb3Vu ZCBpbiBbU1NMLVZQTnNdLg0KDQpBZGRpdGlvbmFsbHksIHRoaXMgdGFsa3MgYWJvdXQgYSBzcGVj aWZpYyB2aWV3IGZyb20gdGhlIHVzZXIgKGl0IGlzIG5vdCBhDQpwcm92aWRlciBwcm92aXNpb25l ZCBWUE4gZm9yIGV4YW1wbGUpLiBTbyBJoa9kIGRlZmluZSB3aGF0IGl0IGlzIGFuZCBub3QNCndo YXQgaXQgaXMgbm90Lg0KDQo+DQo+ICAgV2Ugbm90ZSB0aGF0LCBpbiBhZGRpdGlvbiB0byB0aGUg Z2VuZXJhbCBjYXNlIG9mICJzZW5kIGFsbCB0cmFmZmljDQo+ICAgdGhyb3VnaCB0aGUgVlBOIiwg dGhpcyBkb2N1bWVudCBhZGRpdGlvbmFsbHkgY29uc2lkZXJzIHRoZSBzby1jYWxsZWQNCj4gICAi c3BsaXQtdHVubmVsIiBjYXNlLCB3aGVyZSBzb21lIHN1YnNldCBvZiB0aGUgdHJhZmZpYyBpcyBz ZW50IHRocm91Z2gNCj4gICB0aGUgVlBOLCB3aGlsZSBvdGhlciB0cmFmZmljIGlzIHNlbmQgdG8g aXRzIGludGVuZGVkIGRlc3RpbmF0aW9uIHdpdGgNCj4gICBhIGRpcmVjdCByb3V0aW5nIHBhdGgg KGkuZS4sIHdpdGhvdXQgZW1wbG95aW5nIHRoZSBWUE4gdHVubmVsKS4gIFdlDQo+ICAgbm90ZSB0 aGF0IG1hbnkgb3JnYW5pemF0aW9ucyB3aWxsIHByZXZlbnQgc3BsaXQtdHVubmVsaW5nIGluIHRo ZWlyDQo+ICAgVlBOIGNvbmZpZ3VyYXRpb25zIGlmIHRoZXkgd291bGQgbGlrZSB0byBtYWtlIHN1 cmUgdGhlIHVzZXJzIGRhdGENCj4gICBnb2VzIHRocm91Z2ggYSBnYXRld2F5IHdpdGggcHJvdGVj dGlvbnMgKG1hbHdhcmUgZGV0ZWN0aW9uLCBVUkwNCj4gICBmaWx0ZXJpbmcsIGV0Yy4pLCBidXQg b3RoZXJzIGFyZSBtb3JlIGludGVyZXN0ZWQgaW4gcGVyZm9ybWFuY2Ugb2YNCj4gICB0aGUgdXNl cidzIGFjY2VzcyBvciB0aGUgYWJpbGl0eSBmb3IgcmVzZWFyY2hlcnMgdG8gaGF2ZSBvcHRpb25z IHRvDQo+ICAgYWNjZXNzIHNpdGVzIHRoZXkgbWF5IG5vdCBiZSBhYmxlIHRvIHRocm91Z2ggdGhl IGdhdGV3YXkuDQo+LS0tLSBjdXQgaGVyZSAtLS0tDQo+DQo+V2hlcmU6DQo+DQo+ICAgW1NTTC1W UE5zXQ0KPiAgICAgICAgICAgICAgSG9mZm1hbiwgUC4sICJTU0wgVlBOczogQW4gSUVURiBQZXJz cGVjdGl2ZSIsICBJRVRGIDcyLA0KPiAgICAgICAgICAgICAgU0FBRyBNZWV0aW5nLiwgMjAwOCwN Cj4gICAgICAgICAgICAgIDxodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzcyL3NsaWRl cy9zYWFnLTQucGRmPi4NCj4NCj4NCj4NCj4+PiBSZWdhcmRpbmcgdGhlIHRpdGxlLi4uIEknbSBu b3Qgc3VyZSBpdCdzIGVhc3kgdG8gY29tZSB1cCB3aXRoDQo+Pj4gc29tZXRoaW5nIHNpbXBsZSB0 aGF0IG1ha2VzIHRoaXMgY2xlYXIgKHBhcnRpY3VsYXJseSB3aGVuLCBhcyB5b3UNCj4+PiBjb3Jy ZWN0bHkgc3RhdGUsICJWUE4iIGlzIGtpbmQgb2YgYSBtZXRhLXRlcm0pLi4uIERvIHlvdSBoYXZl IGFueQ0KPj4+IHN1Z2dlc3Rpb25zIGZvciBzb21lIGFsdGVybmF0aXZlIHRpdGxlPw0KPj4gDQo+ PiBJIHRoaW5rIHRoYXQsIGZvciB0aGUgdGl0bGUsIHNheWluZyCp+FZQTiB0cmFmZmljIGxlYWth Z2VzqfcgaXMgdG9vDQo+PmdlbmVyaWMNCj4+IHRvIGJlIGFjY3VyYXRlLCBhbmQgeW91IG5lZWQg dG8gcXVhbGlmeSCp+FZQTqn3Lg0KPg0KPklzIHRoYXQgcG9zc2libGUgaW4gYSBvbmUtbGluZXI/ DQoNCkl0IGlzIG5lY2Vzc2FyeSwgaW4gYSBvbmUtIG9yIHR3by1saW5lci4NCg0KPg0KPg0KPg0K Pj4gVGhlIGRvY3VtZW50IHNlZW1zIHRvIGhpbnQgYXQgdGhlIHR5cGUgb2YgVlBOcyBpbiBzY29w ZS4gQWx0aG91Z2ggdGhpcw0KPj4gd291bGQgYmUgbW9yZSBjbGVhciBhZnRlciB0aGUgdGVybWlu b2xvZ3kgc2VjdGlvbiwgYmFzaWNhbGx5IHRoZQ0KPj5kb2N1bWVudA0KPj4gY292ZXJzIFZQTnMg dGhhdCBhcmU6DQo+PiAxLiBIdWItYW5kLVNwb2tlIChJLmUuLCBjbGllbnQtYmFzZWQgaW4gYSBj bGllbnQtZ2F0ZXdheSBtb2RlbCkgVlBOcywgYXMNCj4+IG9wcG9zZWQgdG8gTWVzaCBWUE5zIChN UExTIEJHUCBWUE5zKS4NCj4+IDIuIEVuY3J5cHRpb24tYmFzZWQgVlBOcyAoZ2l2ZW4gdGhlIG1l bnRpb25zIG9mIKn4aW4gdGhlIGNsZWFyqfcpLCBhcw0KPj4gb3Bwb3NlZCB0byBzaW1wbHkgdHVu bmVsaW5nLg0KPg0KPlBsZWFzZSBzZWUgaWYgdGhlIGFib3ZlIHRleHQgY2xhcmlmaWVzIHRoaXMg cG9pbnQuDQoNCkkgdGhpbmsgaXQgZG9lc26hr3QuDQoNClRoZSBJRVRGIGhhcyBkZWZpbmVkIHRl cm1pbm9sb2d5IGFuZCB0YXhvbm9teSBmb3IgVlBOcy4gRm9yIGV4YW1wbGU6DQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmMyNzY0DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMz ODA5DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MDI2IGZvciBQUC1WUE5zLCBlc3Au IFMuIDMsIDMuMTAsIDQNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQxMTAjc2VjdGlv bi0xLjUNCg0KQW5kIGFzIHlvdSBhY2tub3dsZWRnZSBpdCBpcyBhIG1ldGEgdGVybSAoYW5kIGFu IG92ZXJ1c2VkIG9uZSk7IEmhr2QgdGFsaw0KYWJvdXQgRm9vYmFyLVZQTnMsIHdpdGggbmFycm93 IGRlZmluaXRpb25zLg0KDQo+DQo+DQo+DQo+PiBUaGlzIGlzIHNpbWlsYXIgdG8gdGhlIENpc2Nv IEFueUNvbm5lY3Qgc29mdHdhcmUgY2xpZW50IGluIG15IG1hYy4NCj4+IA0KPj4gQmFzZWQgb24g dGhpcywgqfhDbGllbnQtYmFzZWQgZW5jcnlwdGlvbi1iYXNlZCBWUE5zqfc/DQo+DQo+Q2xpZW50 LWJhc2VkIHdvdWxkIHNlZW0gdG8gc3RpbGwgbGVhZCB0byBhbWJpZ3VpdHkuIEFsc28sIHNvbWUg cGFydHMgb2YNCj50aGUgSS1EIG5vdGVzIHRoYXQgc29tZSBWUE5zIG1heSBub3QgZW1wbG95IGVu Y3J5cHRpb24gOGV2ZW4gd2hlbiBmb3INCj50aGUgbW9zdCBwYXJ0IHdlIGZvY3VzIG9uIFZQTnMg dGhhdCBkbyBlbmNyeXB0aW9uKS4NCg0KSSBhZ3JlZSBjbGllbnQtYmFzZWQgaXMgbm90IGlkZWFs IKGqIGVzcC4gd2hlbiB0aGVyZaGvcyBjbGllbnRsZXNzIFNTTCBWUE5zDQp0aGF0IG1pZ2h0IGZp dCB5b3VyIHNjb3BlLg0KDQo+DQo+TXkgdGFrZSBpcyB0aGF0IG9uZSB3YXkgb3IgYW5vdGhlciB3 ZSdsbCBhaHZlIHRvIGxpdmUgd2l0aCBhIGdlbmVyaWMNCj50aXRsZSB3aGljaCBtYWtlcyBzZW5z ZSB3aGVuIG9uZSBkZWZpbmVzIHRoZSB0ZXJtaW5vbG9neS4uLiB0aG91Z2h0cz8NCg0KTXkgZXhw ZXJpZW5jZSBpcyB0aGF0IHRoZSB1c2Ugb2YgcXVhbGlmaWVycyBoZWxwcyBhbmQgaXMgYSBiZXN0 IHByYWN0aWNlLg0KTDNWUE5zLCBMMlZQTnMsIFBQVlBOcywgSVBzZWMtVlBOcywgZXRjLiBJoa9k IHByZWZlciBmb2xsb3dpbmcgdGhlIHNhbWUNCm1vZGVsIGhlcmUsIGV2ZW4gd2hlbiB5b3UgbWln aHQgaGF2ZSB0byBkZWZpbmUgYSBuZXcgdGVybS4NCg0KPg0KPg0KPg0KPj4gQWdhaW4sIG1heWJl IGl0IHdpbGwgYmUgbW9yZSBjbGVhciBhZnRlciB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbi4NCj4+ IA0KPj4+DQo+Pj4gd3J0IHRvIHRoZSBBYnN0cmFjdCwgaG93IGFib3V0IGNoYW5naW5nIGl0IHRv Og0KPj4+DQo+Pj4gLS0tLSBjdXQgaGVyZSAtLS0tDQo+Pj4gICBUaGUgc3VidGxlIHdheSBpbiB3 aGljaCB0aGUgSVB2NiBhbmQgSVB2NCBwcm90b2NvbHMgY28tZXhpc3QgaW4NCj4+PiAgIHR5cGlj YWwgbmV0d29ya3MsIHRvZ2V0aGVyIHdpdGggdGhlIGxhY2sgb2YgcHJvcGVyIElQdjYgc3VwcG9y dCBpbg0KPj4+ICAgcG9wdWxhciBTU0wtYmFzZWQgb3IgSVBzZWMtYmFzZWQgVmlydHVhbCBQcml2 YXRlIE5ldHdvcmsgKFZQTikNCj4+PiAgIHByb2R1Y3RzLCBtYXkgaW5hZHZlcnRlbnRseSByZXN1 bHQgaW4gVlBOIHRyYWZmaWMgbGVha3MuDQo+Pj4gWy4uLl0NCj4+PiAtLS0tIGN1dCBoZXJlIC0t LS0NCj4+Pg0KPj4+ID8NCj4+IA0KPj4gSSB0aGluayB0aGlzIGNvdmVycyBvbmUgb2YgdGhlIHF1 YWxpdGllcyAoU1NMLWJhc2VkIG9yIElQc2VjLWJhc2VkKSBidXQNCj4+IG5vdCB0aGUgb3RoZXIg KGNsaWVudC1iYXNlZCB2cy4gZnVsbCBtZXNoKS4NCj4NCj5Ib3cgYWJvdXQgIi4uLnBvcHVsYXIg Y2xpZW50LWJhc2VkICh3aGV0aGVyIFNTTCBvciBJUHNlYykgVmlydHVhbA0KPlByaXZhdGUgTmV0 d29yay4uLiI/ICAtLSBBbHRob3VnaCBJJ2QgbGlrZSB0byBjaGVjayB3aXRoIFBhdWwgSG9mZm1h biBldA0KPmFsIGJlZm9yZSBhcHBseWluZy4uLg0KDQpJbiBteSBvcGluaW9uLCB0aGF0IGlzIGJl dHRlciB0aGFuIHNheWluZyChsHBvcHVsYXIgVlBOc6GxLiBUaGF0IGRvZXMNCmV4Y2x1ZGUgTDJU UCwgUFBUUCwgZXRjLiwgYWx0aG91Z2ggdGhvc2UgYXJlIHBvdGVudGlhbGx5IHN1YmplY3QgdG8g dGhlDQpzYW1lIHZ1bG5lcmFiaWxpdGllcyBkZXNjcmliZWQgaW4gdGhlIGRvYy4NCg0KVGhhbmtz LA0KDQqhqiBDYXJsb3MuDQoNCj4NCj5GdXJ0aGVyIHN1Z2dlc3Rpb25zIHdlbGNvbWUgOy0pDQo+ DQo+VGhhbmtzIQ0KPg0KPkJlc3QgcmVnYXJkcywNCj4tLSANCj5GZXJuYW5kbyBHb250DQo+U0k2 IE5ldHdvcmtzDQo+ZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb20NCj5QR1AgRmluZ2VycHJp bnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIgOEZCMSBFM0M0IEFFMjUgMEQ1NSAxRDRFIDc0OTINCj4N Cj4NCj4NCj4NCg0K From fgont@si6networks.com Sun Dec 22 13:06:40 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6C1AEC54 for ; Sun, 22 Dec 2013 13:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1pR55q_M0Kj for ; Sun, 22 Dec 2013 13:06:38 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B76251AEC53 for ; Sun, 22 Dec 2013 13:06:38 -0800 (PST) Received: from pc-61-59-47-190.cm.vtr.net ([190.47.59.61] helo=[192.168.0.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VuqEL-0000fv-M6; Sun, 22 Dec 2013 22:06:34 +0100 Message-ID: <52B75456.1010004@si6networks.com> Date: Sun, 22 Dec 2013 18:06:30 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , "opsec@ietf.org" References: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> <06F2262B-56D4-48E0-AB41-906BE04615F7@cisco.com> <52B67F0F.5030707@si6networks.com> <52B742AB.30202@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Subject: Re: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 21:06:40 -0000 Hi, Carlos, On 12/22/2013 05:54 PM, Carlos Pignataro (cpignata) wrote: >> FWIW, this is what we hae at the time of this writing (still subject to >> comments and edits); >> >> ---- cut here ---- >> When employing the term VPN (or its acronym, "VPN"), this document >> refers to IPsec-based or TLS-based tunnels, where traffic is >> encapsulated and sent from a client to a middle-box, to access >> multiple network services (potentially emplying different transport >> and/or application protocols). > > I do not think this is the best approach. Here you are saying: ¡°when we > say VPN we actually mean this, so we will make statements about VPNs¡±. > Instead, I¡¯d suggest the more precise approach is to say ¡°in this document > we consider Foobar VPNs, so we will make statements about Foobar VPNs¡± > (where Foobar is a modifier/qualifier of VPN, defined in the document). If you know of such modifier/qualifier, I'd like to know -- particularly if it's a one/two word thing that will not result in cumbersome text throughout the document. Besides, at the end of the day, foobar VPN would still be one definition of ours, so... I'm not sure that would make the text any more precise (as long as the terminoogy is clarified up frnt, as with a "Terminology" section). >> Our use of the term "Virtual Private Networks" excludes the so-called >> SSL/TLS VPN portals (a front-end provided by the middlebox to add >> security to a normally-unsecured site). Further discussion of SSL- >> based VPNs can be found in [SSL-VPNs]. > > Additionally, this talks about a specific view from the user (it is not a > provider provisioned VPN for example). So I¡¯d define what it is and not > what it is not. Not sure what you mean. >>>> Regarding the title... I'm not sure it's easy to come up with >>>> something simple that makes this clear (particularly when, as you >>>> correctly state, "VPN" is kind of a meta-term)... Do you have any >>>> suggestions for some alternative title? >>> >>> I think that, for the title, saying ©øVPN traffic leakages©÷ is too >>> generic >>> to be accurate, and you need to qualify ©øVPN©÷. >> >> Is that possible in a one-liner? > > It is necessary, in a one- or two-liner. So far we have tried to do that with the terminology Section -- and I doubt that can be clearly one with a one liner. But if you have any suggestions, I'm all ears. > The IETF has defined terminology and taxonomy for VPNs. For example: > http://tools.ietf.org/html/rfc2764 > http://tools.ietf.org/html/rfc3809 > http://tools.ietf.org/html/rfc4026 for PP-VPNs, esp. S. 3, 3.10, 4 > http://tools.ietf.org/html/rfc4110#section-1.5 > > And as you acknowledge it is a meta term (and an overused one); I¡¯d talk > about Foobar-VPNs, with narrow definitions. I'll check the references, and will also let others weigh in. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From cpignata@cisco.com Sun Dec 22 15:06:16 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232C91AE0BE for ; Sun, 22 Dec 2013 15:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le8xXHda2FZI for ; Sun, 22 Dec 2013 15:06:14 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD871AE035 for ; Sun, 22 Dec 2013 15:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5088; q=dns/txt; s=iport; t=1387753572; x=1388963172; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wAGZmfW8im/EA1QAuX6343rzRV7OiA8QPTHSRZSR4FE=; b=aXf+N3picOWYwUv3Yw+VPQ/BiOha5mlxt8l60VSa/0bOUOy+b7yNob80 yFu6Oeh1x8IrYR+1Lt+N0QNPVDtSJ1M7hUMp4tzQSu4LyfjzvJ38751IL qx2g0r4NIXfzHTgms7lPXYiR49J0H1Eg3znJqrkMGmBgCHAND/c72L2nk g=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAB9vt1KtJXG8/2dsb2JhbABYgws4VYMBtjyBFRZ0giUBAQEDAXkFCwIBCA4KIwkCMiUCBA4FDoduCA2VNZtlBpliF48lB4JoO4ETAQOQM4ExhjOBMJBkgW+BPoIq X-IronPort-AV: E=Sophos;i="4.95,533,1384300800"; d="asc'?scan'208";a="290269765" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 22 Dec 2013 23:06:10 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBMN69HS022554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Dec 2013 23:06:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.18]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Sun, 22 Dec 2013 17:06:09 -0600 From: "Carlos Pignataro (cpignata)" To: Fernando Gont Thread-Topic: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC Thread-Index: AQHO+pxHx7azAjJQKkqONuUSVv/EjZpgJHyAgACNAgCAAFwtgP//vdeAgABXOQCAACFsgA== Date: Sun, 22 Dec 2013 23:06:08 +0000 Message-ID: References: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> <06F2262B-56D4-48E0-AB41-906BE04615F7@cisco.com> <52B67F0F.5030707@si6networks.com> <52B742AB.30202@si6networks.com> <52B75456.1010004@si6networks.com> In-Reply-To: <52B75456.1010004@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.239.63] Content-Type: multipart/signed; boundary="Apple-Mail=_B5B2EEF4-0A75-4749-BD14-0AEA99F91BD2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 23:06:16 -0000 --Apple-Mail=_B5B2EEF4-0A75-4749-BD14-0AEA99F91BD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=euc-kr Fernando, On Dec 22, 2013, at 4:06 PM, Fernando Gont = wrote: > Hi, Carlos, >=20 > On 12/22/2013 05:54 PM, Carlos Pignataro (cpignata) wrote: >>> FWIW, this is what we hae at the time of this writing (still subject = to >>> comments and edits); >>>=20 >>> ---- cut here ---- >>> When employing the term VPN (or its acronym, "VPN"), this document >>> refers to IPsec-based or TLS-based tunnels, where traffic is >>> encapsulated and sent from a client to a middle-box, to access >>> multiple network services (potentially emplying different transport >>> and/or application protocols). >>=20 >> I do not think this is the best approach. Here you are saying: =A1=B0wh= en we >> say VPN we actually mean this, so we will make statements about = VPNs=A1=B1. >> Instead, I=A1=AFd suggest the more precise approach is to say =A1=B0in = this document >> we consider Foobar VPNs, so we will make statements about Foobar = VPNs=A1=B1 >> (where Foobar is a modifier/qualifier of VPN, defined in the = document). >=20 > If you know of such modifier/qualifier, I'd like to know -- = particularly > if it's a one/two word thing that will not result in cumbersome text > throughout the document. >=20 > Besides, at the end of the day, foobar VPN would still be one = definition > of ours, so... I'm not sure that would make the text any more precise > (as long as the terminoogy is clarified up frnt, as with a = "Terminology" > section). >=20 I proposed a couple, I think they are better than nothing but certainly = not great. Perhaps a potentially good one is hub-and-spoke (like in the = softwires terminology, as I understand you are talking always about = cases with a VPN Concentrator (hub), and the vulnerability in the = (software) clients (spokes)). In any case, my main point is that saying "VPN leakages in dual-stack = networks" is not correct, as it overgeneralizes. And I think that "foobar VPN" is much better than "VPN", provided that = "foobar" is defined in the document. It's OK to create a new term if it = is needed and none exists. >=20 >=20 >>> Our use of the term "Virtual Private Networks" excludes the = so-called >>> SSL/TLS VPN portals (a front-end provided by the middlebox to add >>> security to a normally-unsecured site). Further discussion of SSL- >>> based VPNs can be found in [SSL-VPNs]. >>=20 >> Additionally, this talks about a specific view from the user (it is = not a >> provider provisioned VPN for example). So I=A1=AFd define what it is = and not >> what it is not. >=20 > Not sure what you mean. >=20 >=20 >=20 >>>>> Regarding the title... I'm not sure it's easy to come up with >>>>> something simple that makes this clear (particularly when, as you >>>>> correctly state, "VPN" is kind of a meta-term)... Do you have any >>>>> suggestions for some alternative title? >>>>=20 >>>> I think that, for the title, saying =A9=F8VPN traffic leakages=A9=F7 = is too >>>> generic >>>> to be accurate, and you need to qualify =A9=F8VPN=A9=F7. >>>=20 >>> Is that possible in a one-liner? >>=20 >> It is necessary, in a one- or two-liner. >=20 > So far we have tried to do that with the terminology Section -- and I > doubt that can be clearly one with a one liner. But if you have any > suggestions, I'm all ears. >=20 See above (although you'd need to be "all eyes" or use a text-to-speach = interface :-) Net-net -- given the number of different types of VPNs, if the leakage = does not apply to all (or even most) of them, I still think that = technically the title/abstract/doc needs to narrow scope. >=20 >=20 >> The IETF has defined terminology and taxonomy for VPNs. For example: >> http://tools.ietf.org/html/rfc2764 >> http://tools.ietf.org/html/rfc3809 >> http://tools.ietf.org/html/rfc4026 for PP-VPNs, esp. S. 3, 3.10, 4 >> http://tools.ietf.org/html/rfc4110#section-1.5 >>=20 >> And as you acknowledge it is a meta term (and an overused one); I=A1=AF= d talk >> about Foobar-VPNs, with narrow definitions. >=20 > I'll check the references, and will also let others weigh in. Sounds good -- thanks. Carlos Pignataro. >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 --Apple-Mail=_B5B2EEF4-0A75-4749-BD14-0AEA99F91BD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlK3cF8ACgkQtfDPGTp3USyeKQCgpG4sJl0H+GUlPw77tW6mKGFV 9ycAnjOFI5nMFc2HRPdVzFxaVC+ZH+B3 =u252 -----END PGP SIGNATURE----- --Apple-Mail=_B5B2EEF4-0A75-4749-BD14-0AEA99F91BD2-- From paul.hoffman@gmail.com Sun Dec 22 19:11:26 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190951AE769 for ; Sun, 22 Dec 2013 19:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0QoqQHVgPAq for ; Sun, 22 Dec 2013 19:11:18 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3202E1AE154 for ; Sun, 22 Dec 2013 19:11:18 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so2587394veb.19 for ; Sun, 22 Dec 2013 19:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xtLXUhiPrreiyuxYc68SGOLg9lZ8S+0xt4u7sbeWJ+E=; b=QnUTsvU1g4K3LLEraDkUGv3msx+Us037CQNt6OyiVQa+M+uaa9MJSXrX6sQLApBrly tbi35LFCU6eRzMBEHst9mvm0cvwRjVsHmHPensTDLSVlev+w9wfj69Wk83yOJrQemdtZ HaEb3AwEVXg5vRIHyY1jCE8tJeGuyk8ubPH9GiOjEgmi4KG2qmeiwI2XBCuoplHo2IHL MP+9NiHxuO7TUetluX7kAdF2xgIeCPJQVvJLtXGmCCNcwxgMNUwg6q2hJOPpI9fePiVK 3GtQMnq93dBWjUAY1DOHWiHlIElobXgi1Ct7qYwEBYdh8ZqnmHRJwpoP/Y4IHo3IFuFk bLSQ== MIME-Version: 1.0 X-Received: by 10.52.164.16 with SMTP id ym16mr546734vdb.39.1387768274816; Sun, 22 Dec 2013 19:11:14 -0800 (PST) Received: by 10.220.150.208 with HTTP; Sun, 22 Dec 2013 19:11:14 -0800 (PST) In-Reply-To: <52B75456.1010004@si6networks.com> References: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> <06F2262B-56D4-48E0-AB41-906BE04615F7@cisco.com> <52B67F0F.5030707@si6networks.com> <52B742AB.30202@si6networks.com> <52B75456.1010004@si6networks.com> Date: Sun, 22 Dec 2013 19:11:14 -0800 Message-ID: From: Paul Hoffman To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11c22e580d150204ee2afb2e Cc: "Carlos Pignataro \(cpignata\)" , "opsec@ietf.org" Subject: Re: [OPSEC] Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 03:11:26 -0000 --001a11c22e580d150204ee2afb2e Content-Type: text/plain; charset=UTF-8 The VPN Consortium (www.vpnc.org) differentiates between the two large categories as "secure VPNs" and "trusted VPNs". So, if the WG thinks it is important to make this change in the title, adding "secure" might be it. However, the new terminology section is certainly needed as well. --Paul Hoffman --001a11c22e580d150204ee2afb2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The VPN Consortium (w= ww.vpnc.org) differentiates between the two large categories as "s= ecure VPNs" and "trusted VPNs". So, if the WG thinks it is i= mportant to make this change in the title, adding "secure" might = be it. However, the new terminology section is certainly needed as well.
--Paul Hoffman

--001a11c22e580d150204ee2afb2e--