From nobody Mon Jul 2 08:59:36 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45010131232; Mon, 2 Jul 2018 08:59:21 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu 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 TFQIl9RJswMN; Mon, 2 Jul 2018 08:59:19 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498901311F7; Mon, 2 Jul 2018 08:59:19 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.21/8.16.0.21) with ESMTP id w62Fx78L007573; Mon, 2 Jul 2018 08:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1530547147; bh=J4+IAUYnsSmQd294Zlx/YfbQ+1TD14gjIJI2Wd5xxJs=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=D3iOOmqNAhcS+RbA53lbjOlCFukofkhdErCxcUvj2banA7eKdsvlDgSz1+8bJbIRQ 35fyD7N4w7TO0bR11pqudzygknnPAhAVTfZWAIrLgRJ6tijB8618gPiaygtA0Iuw5d PTuwVQVtmfjcjPrXHv59bxqlGfonVPwSztelDJr8= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w62Fx52u043820; Mon, 2 Jul 2018 08:59:05 -0700 (PDT) From: David Mazieres To: Jordi =?utf-8?Q?Pailliss=C3=A9?= Vilanova , sidrops@ietf.org, din@irtf.org, Stephane Bortzmeyer , sandy@tislabs.com, Greg Skinner , leo@vegoda.org, "natal\@cisco.com" , Vina Ermagan , Fabio Maino , Albert Cabellos , opsec@ietf.org In-Reply-To: References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> Reply-To: David Mazieres expires 2018-09-30 PDT Date: Mon, 02 Jul 2018 08:59:10 -0700 Message-ID: <87lgat633l.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] [Din] blockchain for IP addresses draft update X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 15:59:30 -0000 Jordi Pailliss=C3=A9 Vilanova writes: > (apologies for cross-posting) > > Dear all, > > We have submitted a new version of the draft addressing comments=20 > received both on the mailing list and IETF meetings. > > Thanks to all of you for taking the time to read the draft :) > > Regards, > > Jordi Very interesting draft. One high-level comment, I would avoid terms like "tamper-proof" or really anything-"proof" except possibly in the context of information-theoretic security, in favor of tamper-resistant. This is particularly important in the context of blockchains that have experienced a number of forks in practice and where it would likely take only a few tens of millions of dollars a day to tamper with history. I think the draft would benefit from a much finer-grained consideration of several different forms of proof-of-stake, because there are a number of assertions that do not hold for all forms of proof of stake. E.g., will there be delegation like peercoin, randomization like algorand, penalties like Casper, sleepy nodes like snowwhite? And while of course I'm biased on this issue, I think that a Byzantine-agreement-based approach like SCP (https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work better than PoS. SCP is well matched to the Internet peering model, which we already know is a workable decentralized governance model. You may not agree, but it would at least be nice for the document to explain why you reject this approach. David From nobody Mon Jul 2 10:52:08 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD3F131160; Mon, 2 Jul 2018 10:52:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Chown To: Cc: opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153055392479.16095.569198674604354407@ietfa.amsl.com> Date: Mon, 02 Jul 2018 10:52:04 -0700 Archived-At: Subject: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 17:52:05 -0000 Reviewer: Tim Chown Review result: Not Ready Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft analyses operational security issues related to the deployment of IPv6, and describes appropriate mechanisms and practices to mitigate potential threats. The document is Not Ready for publication. General comments: The draft is well written, and the authors are clearly experts in the area, but the evolution of 13 versions of the draft since WG adoption in 2012 means the draft is somewhat disjoint, and has a number of sections where current best practices and related RFCs are not included. A prime example is in the area of address configuration. There are seven pages on transition technologies; might that be better homed in a -bis of RFC 4942? The sections on control plane and routing (2.4, 2.5) are somewhat generic to IPv4 and IPv6; there is very little IPv6-specific information in there. While this isn't bad per se, it pads the length of the document somewhat without much new material. There are many typos and grammatical errors throughout the document. Specific comments: p.3 "subtle differences between IPv4 and IPv6" - I don't think L2 vs L3 resolution, ND vs ARP, is that subtle? Do we need to mention NPTv6 here? p.4 Mention 6renum and the gaps draft it produced (RFC 7010)? The recommendation to use PI for a larger network implicitly means no NPTv6? Any value in adding a note about the size of prefix an ISP offers? (6177, etc) That affects how the network is configured. Where is topology discovery / probing mentioned? Cite RFC 4864? p.5 I think the phrase in para 1 is "security by obscurity". I would argue that that can complement other security, but must not be depended upon! Para 2 - or do both! p.6 Section 2.1.3 - and ND cache exhaustion protection Section 2.1.4 - "Normal" SLAAC no longer relies on EUI-64 from MAC addresses - now RFC 8064 recommends the RFC 7217 version of SLAAC. This whole section is written in a jumbled order. There should be a separate section on address accountability - whether it's needed in a given scenario, and where it is, how best to achieve it - there's bits of this scattered around in many places, but it's independent of privacy addressing. Para 3 - see section 2.1.7. p.7 first line - you can't always control managed vs unmanaged of course; a university eduroam WiFi is unmanaged, generally, where admin systems probably are managed. second para - these are just hints; and for a host not supporting DHCPv6, it gets no address at all. Perhaps also mention SAVI here. Section 2.1.6 - Should mentioned DHCPv6 anonymity profile - RFC 7824 and RFC 7844. RFC 7934 suggests not using DHCPv6 in certain circumstances as a result. Also RFC 7077 recommends to not issue DHCPv6 addresses sequentially from a small pool. Section 2.1.7 - note RFC 8273 is designed for shared environments, and isolation is a primary goal; add reference to RFC 7934. p.8 Perhaps check against text in draft-ietf-6man-rfc6434-bis-08 in section 5.2, and the excessive EH option processing text in 5.3 there. p.9 Section 2.2.4 - worth adding RFC 8221 and RFC 8247? Section 2.3 - split out the NS/NA messaging here from ND in general, else you should include SLAAC. Given you discuss SLAAC later, focus on NS/NA here in its own subsection? p.10 Spurious DHCP-Shield wording at end of para 2. Section 2.3.2 - mention ND cache exhaustion p.11 Rate limit also on ICMP messages? Perhaps separate out the power drain issue as a threat? RFC 7772 is relevant here. The two drafts cited here by thubert and chakrabarti died in 2012 and 2015 respectively? Maybe RFC 6775 instead? Section 2.3.3 - or just supply a 'bad' DNS resolver address p.12 After para 3 emphasise still need RAs in a DHC environment for default router and on-link prefix(es) p.13 A lot of text on something hardly used? p.14 - 20 Lots of generic text applicable to IPv4 too? p.16 Replace RFC 2460 with RFC 8200? p.17 There is now draft-ietf-6man-rfc6434-bis-08 p.20 What's required to differentiate logging of different IP versions? Value in mentioning RFC 8096? Or YANG modules (as per Section 16 of draft-ietf-6man-rfc6434-bis-08) p.21 And RESTCONF? Windows 7? At bottom, "was usually done in the IPv4 era" -> "is commonly used in IPv4 networking" p.22 "era" again. Mention DHCPv6 anonymity profiles - RFC 7844 P.23 Forensics - that's *one* way - can e.g. use a NMS; one that harvests network device data via SNMP; many open source options available. p.24 Mostly duplicating RFC 7077. Section 2.6.2.3 - rfer to RFC 5952, or se Sec 2.6.1.1 p.26 Perhaps be consistent with rather than maintain parity? p.29 6to4...? p.31 Last para is very handwavey! Device OSes are more secure these days to work in IPv4 hotspots too? p.33 A campus enterprise is different - BYOD vs managed, esp. wifi/eduroam, or Science DMZ networks; perhaps mention RFC 7381, esp. sections 2.4, 3.2 and 4.1? p.35 last para - better to omit, I think? From nobody Mon Jul 2 13:14:33 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5713129E; Mon, 2 Jul 2018 13:14:25 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 GxznrPVvtCJL; Mon, 2 Jul 2018 13:14:21 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0C01312EB; Mon, 2 Jul 2018 13:14:18 -0700 (PDT) Received: from lxdnp04n.corp.intranet (emailout.qintra.com [151.119.92.83]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id w62KEGGJ000883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 2 Jul 2018 15:14:17 -0500 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id w62KEBuq020935; Mon, 2 Jul 2018 14:14:11 -0600 Received: from lxdnp32k.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id w62KEBP7020931 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Mon, 2 Jul 2018 14:14:11 -0600 Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id w62KEBJM055830; Mon, 2 Jul 2018 14:14:11 -0600 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id w62KEBMM055827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jul 2018 14:14:11 -0600 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([151.119.128.28]) with mapi id 14.03.0339.000; Mon, 2 Jul 2018 14:14:11 -0600 From: "Smith, Donald" To: Tim Chown , "ops-dir@ietf.org" CC: "opsec@ietf.org" , "draft-ietf-opsec-v6.all@ietf.org" Thread-Topic: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13 Thread-Index: AQHUEi2KzBjHl60AmkiB+/z/svyR46R8RkUe Date: Mon, 2 Jul 2018 20:14:10 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D53DE8559@PDDCWMBXEX503.ctl.intranet> References: <153055392479.16095.569198674604354407@ietfa.amsl.com> In-Reply-To: <153055392479.16095.569198674604354407@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 20:14:32 -0000 Before approval, all the URIs should be checked, for example the cymru link= is broken. Routing security talks exclusively to OSFPv3 which isn't in common use exte= rnally today, BGP would be a better choice. 2.1.1 This: There are many scanning techniques and more to come possible, hence, operators should never relly on the 'impossible to find because my address is random' paradigm. Should probably be this: There are many scanning techniques and possibly more to come, hence, operat= ors should never rely on the 'impossible to find because my address is rand= om' paradigm. Or adding Tom's suggestion: There are many scanning techniques and possibly more to come, hence, operat= ors should never rely on the 'security by obscurity' paradigm. Maybe it doesn't belong there but this appears to be a potential new smurf = amplification vector. "Another way works only for local network, it consists in sending a ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which is all IPv6 nodes on the network. All nodes should reply to this ECHO_REQUEST per [RFC4443]." But maybe that belongs in 4443 or some other draft? I feel some mention of anycast used for DDoS Reflection and Amplification (= RA) should be included (again might be out of scope)? Metric System < +000 > -000 Extra People's Terribly Good Meals Kept mY uNCLE Ned Purring For A= ges Exa Peta Tera Giga Mega Kilo milli Micro(u) Nano Pico Fe= mto Atto Donald.Smith@centurylink.com ________________________________________ From: OPSEC [opsec-bounces@ietf.org] on behalf of Tim Chown [tim.chown@jisc= .ac.uk] Sent: Monday, July 02, 2018 11:52 AM To: ops-dir@ietf.org Cc: opsec@ietf.org; draft-ietf-opsec-v6.all@ietf.org Subject: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13 Reviewer: Tim Chown Review result: Not Ready Hi, I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects = of the IETF drafts. Comments that are not addressed in last call may be includ= ed in AD reviews during the IESG review. Document editors and WG chairs shoul= d treat these comments just like any other last call comments. This draft analyses operational security issues related to the deployment o= f IPv6, and describes appropriate mechanisms and practices to mitigate potent= ial threats. The document is Not Ready for publication. General comments: The draft is well written, and the authors are clearly experts in the area,= but the evolution of 13 versions of the draft since WG adoption in 2012 means t= he draft is somewhat disjoint, and has a number of sections where current best practices and related RFCs are not included. A prime example is in the are= a of address configuration. There are seven pages on transition technologies; might that be better home= d in a -bis of RFC 4942? The sections on control plane and routing (2.4, 2.5) are somewhat generic t= o IPv4 and IPv6; there is very little IPv6-specific information in there. Whi= le this isn't bad per se, it pads the length of the document somewhat without = much new material. There are many typos and grammatical errors throughout the document. Specific comments: p.3 "subtle differences between IPv4 and IPv6" - I don't think L2 vs L3 resolut= ion, ND vs ARP, is that subtle? Do we need to mention NPTv6 here? p.4 Mention 6renum and the gaps draft it produced (RFC 7010)? The recommendation to use PI for a larger network implicitly means no NPTv6= ? Any value in adding a note about the size of prefix an ISP offers? (6177, = etc) That affects how the network is configured. Where is topology discovery / probing mentioned? Cite RFC 4864? p.5 I think the phrase in para 1 is "security by obscurity". I would argue tha= t that can complement other security, but must not be depended upon! Para 2 - or do both! p.6 Section 2.1.3 - and ND cache exhaustion protection Section 2.1.4 - "Normal" SLAAC no longer relies on EUI-64 from MAC addresse= s - now RFC 8064 recommends the RFC 7217 version of SLAAC. This whole section is written in a jumbled order. There should be a separate section on address accountability - whether it's needed in a given scenario, and where it is, how best to achieve it - there= 's bits of this scattered around in many places, but it's independent of priva= cy addressing. Para 3 - see section 2.1.7. p.7 first line - you can't always control managed vs unmanaged of course; a university eduroam WiFi is unmanaged, generally, where admin systems probab= ly are managed. second para - these are just hints; and for a host not supporting DHCPv6, i= t gets no address at all. Perhaps also mention SAVI here. Section 2.1.6 - Should mentioned DHCPv6 anonymity profile - RFC 7824 and RF= C 7844. RFC 7934 suggests not using DHCPv6 in certain circumstances as a res= ult. Also RFC 7077 recommends to not issue DHCPv6 addresses sequentially from a small pool. Section 2.1.7 - note RFC 8273 is designed for shared environments, and isolation is a primary goal; add reference to RFC 7934. p.8 Perhaps check against text in draft-ietf-6man-rfc6434-bis-08 in section 5.2= , and the excessive EH option processing text in 5.3 there. p.9 Section 2.2.4 - worth adding RFC 8221 and RFC 8247? Section 2.3 - split out the NS/NA messaging here from ND in general, else y= ou should include SLAAC. Given you discuss SLAAC later, focus on NS/NA here i= n its own subsection? p.10 Spurious DHCP-Shield wording at end of para 2. Section 2.3.2 - mention ND cache exhaustion p.11 Rate limit also on ICMP messages? Perhaps separate out the power drain issue as a threat? RFC 7772 is releva= nt here. The two drafts cited here by thubert and chakrabarti died in 2012 and 2015 respectively? Maybe RFC 6775 instead? Section 2.3.3 - or just supply a 'bad' DNS resolver address p.12 After para 3 emphasise still need RAs in a DHC environment for default rout= er and on-link prefix(es) p.13 A lot of text on something hardly used? p.14 - 20 Lots of generic text applicable to IPv4 too? p.16 Replace RFC 2460 with RFC 8200? p.17 There is now draft-ietf-6man-rfc6434-bis-08 p.20 What's required to differentiate logging of different IP versions? Value in mentioning RFC 8096? Or YANG modules (as per Section 16 of draft-ietf-6man-rfc6434-bis-08) p.21 And RESTCONF? Windows 7? At bottom, "was usually done in the IPv4 era" -> "is commonly used in IPv4 networking" p.22 "era" again. Mention DHCPv6 anonymity profiles - RFC 7844 P.23 Forensics - that's *one* way - can e.g. use a NMS; one that harvests networ= k device data via SNMP; many open source options available. p.24 Mostly duplicating RFC 7077. Section 2.6.2.3 - rfer to RFC 5952, or se Sec 2.6.1.1 p.26 Perhaps be consistent with rather than maintain parity? p.29 6to4...? p.31 Last para is very handwavey! Device OSes are more secure these days to wor= k in IPv4 hotspots too? p.33 A campus enterprise is different - BYOD vs managed, esp. wifi/eduroam, or Science DMZ networks; perhaps mention RFC 7381, esp. sections 2.4, 3.2 and = 4.1? p.35 last para - better to omit, I think? _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Mon Jul 2 16:24:29 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F564131208; Mon, 2 Jul 2018 16:24:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057385943.16259.5713811757012856716@ietfa.amsl.com> Date: Mon, 02 Jul 2018 16:24:19 -0700 Archived-At: Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-06.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 23:24:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. Title : Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers Authors : Fernando Gont Will(Shucheng) Liu Filename : draft-ietf-opsec-ipv6-eh-filtering-06.txt Pages : 36 Date : 2018-07-02 Abstract: It is common operator practice to mitigate security risks by enforcing appropriate packet filtering. This document analyzes both the general security implications of IPv6 Extension Headers and the specific security implications of each Extension Header and Option type. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic *not* directed to them, for those cases in which such filtering is deemed as necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-eh-filtering-06 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 nobody Tue Jul 3 09:01:02 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5573D130FAF; Tue, 3 Jul 2018 09:00:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Secretariat\"" To: , Cc: opsec@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361134.4893.9988110607541869062.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:11 -0700 Archived-At: Subject: [OPSEC] opsec - Requested session has been scheduled for IETF 102 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:12 -0000 Dear Éric Vyncke, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. opsec Session 1 (1:30 requested) Friday, 20 July 2018, Afternoon Session I 1150-1320 Room Name: Viger size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/opsec.ics Request Information: --------------------------------------------------------- Working Group Name: Operational Security Capabilities for IP Network Infrastructure Area Name: Operations and Management Area Session Requester: Éric Vyncke Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: 6man v6ops intarea Second Priority: tls opsawg opsarea capport Third Priority: mile People who must be present: Ron Bonica Eric Vyncke Warren Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jul 4 04:28:38 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51AD130E3B; Wed, 4 Jul 2018 04:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 y7RDy6qVhZrF; Wed, 4 Jul 2018 04:28:33 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8F952130DCE; Wed, 4 Jul 2018 04:28:32 -0700 (PDT) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id w64BSGja007150; Wed, 4 Jul 2018 13:28:16 +0200 Received: from [147.83.35.225] (dync-35-225.ac.upc.es [147.83.35.225]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 5EC98165; Wed, 4 Jul 2018 13:28:11 +0200 (CEST) To: David Mazieres expires 2018-09-30 PDT , sidrops@ietf.org, din@irtf.org, Stephane Bortzmeyer , sandy@tislabs.com, Greg Skinner , leo@vegoda.org, "natal@cisco.com" , Vina Ermagan , Fabio Maino , Albert Cabellos , opsec@ietf.org References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> <87lgat633l.fsf@ta.scs.stanford.edu> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: Date: Wed, 4 Jul 2018 13:28:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87lgat633l.fsf@ta.scs.stanford.edu> Content-Type: multipart/alternative; boundary="------------556A0A05FB0DA42423EC9986" Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] [Din] blockchain for IP addresses draft update X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 11:28:37 -0000 This is a multi-part message in MIME format. --------------556A0A05FB0DA42423EC9986 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi David, Indeed, we did not delve deeper into the PoS algorithm. This depends on the specific implementation, our opinion is that an Algroand-like would be a good option, and if it can tolerate a large portion of offline participants even better. In addition, we think that punishing or deposit mechanisms are not desirable because they don't fit the characteristics of the scenario. Overall the incentive is "a more secure Internet", we believe that this is well-aligned with the economical interests of the participants. Regarding SCP, the fact that you only need to trust your neighbours may prove very convenient in this scenario. As you said, it reflects current Internet trust schemes, this basically means that BGP Peering = Trust = Stellar quorum slices. We'll look into this for the next iteration of the draft. Thanks Jordi El 02/07/18 a les 17:59, David Mazieres ha escrit: > Jordi Paillissé Vilanova writes: > >> (apologies for cross-posting) >> >> Dear all, >> >> We have submitted a new version of the draft addressing comments >> received both on the mailing list and IETF meetings. >> >> Thanks to all of you for taking the time to read the draft :) >> >> Regards, >> >> Jordi > Very interesting draft. One high-level comment, I would avoid terms > like "tamper-proof" or really anything-"proof" except possibly in the > context of information-theoretic security, in favor of tamper-resistant. > This is particularly important in the context of blockchains that have > experienced a number of forks in practice and where it would likely take > only a few tens of millions of dollars a day to tamper with history. > > I think the draft would benefit from a much finer-grained consideration > of several different forms of proof-of-stake, because there are a number > of assertions that do not hold for all forms of proof of stake. E.g., > will there be delegation like peercoin, randomization like algorand, > penalties like Casper, sleepy nodes like snowwhite? > > And while of course I'm biased on this issue, I think that a > Byzantine-agreement-based approach like SCP > (https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work > better than PoS. SCP is well matched to the Internet peering model, > which we already know is a workable decentralized governance model. You > may not agree, but it would at least be nice for the document to explain > why you reject this approach. > > David --------------556A0A05FB0DA42423EC9986 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi David,

Indeed, we did not delve deeper into the PoS algorithm. This depends on the specific implementation, our opinion is that an Algroand-like would be a good option, and if it can tolerate a large portion of offline participants even better. In addition, we think that punishing or deposit mechanisms are not desirable because they don't fit the characteristics of the scenario. Overall the incentive is "a more secure Internet", we believe that this is well-aligned with the economical interests of the participants.

Regarding SCP, the fact that you only need to trust your neighbours may prove very convenient in this scenario. As you said, it reflects current Internet trust schemes, this basically means that BGP Peering = Trust = Stellar quorum slices. We'll look into this for the next iteration of the draft.

Thanks

Jordi


El 02/07/18 a les 17:59, David Mazieres ha escrit:
Jordi Paillissé Vilanova <jordip@ac.upc.edu> writes:


(apologies for cross-posting)

Dear all,

We have submitted a new version of the draft addressing comments 
received both on the mailing list and IETF meetings.

Thanks to all of you for taking the time to read the draft :)

Regards,

Jordi

Very interesting draft.  One high-level comment, I would avoid terms
like "tamper-proof" or really anything-"proof" except possibly in the
context of information-theoretic security, in favor of tamper-resistant.
This is particularly important in the context of blockchains that have
experienced a number of forks in practice and where it would likely take
only a few tens of millions of dollars a day to tamper with history.

I think the draft would benefit from a much finer-grained consideration
of several different forms of proof-of-stake, because there are a number
of assertions that do not hold for all forms of proof of stake.  E.g.,
will there be delegation like peercoin, randomization like algorand,
penalties like Casper, sleepy nodes like snowwhite?

And while of course I'm biased on this issue, I think that a
Byzantine-agreement-based approach like SCP
(https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work
better than PoS.  SCP is well matched to the Internet peering model,
which we already know is a workable decentralized governance model.  You
may not agree, but it would at least be nice for the document to explain
why you reject this approach.

David

--------------556A0A05FB0DA42423EC9986-- From nobody Wed Jul 4 05:09:17 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E298130E06; Wed, 4 Jul 2018 05:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Gpcqgx3vDYUb; Wed, 4 Jul 2018 05:09:10 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B438D130DC2; Wed, 4 Jul 2018 05:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17626; q=dns/txt; s=iport; t=1530706150; x=1531915750; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NzkZmiVK3+330cARcbpPSwcOWYOZKWcGM2QJj2AEWNk=; b=HWeSp3aT1ZNNlX1tgLC7HfNEpei1HhuUGVTJPZHNoFVGrYvPORkWHgjQ f7uBZ8OsTHUF4XjNfW+fKWgsTppTzxxCShAjumgGEPun3KAHWhe4Damor DupmMimKmKxIJyR5KV6wdvm8TkBC3uBBu0PWKaYOf7LZG06ofEaGb8qVa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAgA1uDxb/5tdJa1cDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCU3ZifygKg3CUIRmCB5AfhQ4UgWYLI4RJAheCDCE1FwE?= =?us-ascii?q?CAQECAQECbRwMhTYBAQEEI0cEGwIBCBEDAQIoAwICAjAUCQgCBAESgyABgRt?= =?us-ascii?q?kD6gughyDegEBhFeBNQWIRyaBVj+BNoFqUC6DGAIDAYEkWBaCSzGCJAKHQIo?= =?us-ascii?q?nh2UJAoYEiRqBQIZ3hSCHe4I6hy0CERMBgSQeATaBPQ0IcBU7KgGCPoIkF4h?= =?us-ascii?q?ZhQQEATVvAY5hAiQEA4EBgRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,306,1526342400"; d="scan'208,217";a="138540286" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 12:09:09 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w64C99s7017895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Jul 2018 12:09:09 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 4 Jul 2018 08:09:08 -0400 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1320.000; Wed, 4 Jul 2018 08:09:08 -0400 From: "Roque Gagliano (rogaglia)" To: =?utf-8?B?Sm9yZGkgUGFpbGxpc3PDqSBWaWxhbm92YQ==?= , David Mazieres expires 2018-09-30 PDT , "sidrops@ietf.org" , "din@irtf.org" , Stephane Bortzmeyer , "sandy@tislabs.com" , Greg Skinner , "leo@vegoda.org" , "Alberto Rodriguez Natal (natal)" , "Vina Ermagan (vermagan)" , "Fabio Maino (fmaino)" , Albert Cabellos , "opsec@ietf.org" Thread-Topic: [OPSEC] [Din] blockchain for IP addresses draft update Thread-Index: AQHUEh4PNQ99JdAUUUS0yUmJnadF4KR/Mv+AgAAs94A= Date: Wed, 4 Jul 2018 12:09:08 +0000 Message-ID: <9BC0DE80-D827-414B-916B-C102C3460563@cisco.com> References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> <87lgat633l.fsf@ta.scs.stanford.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.172.244] Content-Type: multipart/alternative; boundary="_000_9BC0DE80D827414B916BC102C3460563ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSEC] [Din] blockchain for IP addresses draft update X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 12:09:16 -0000 --_000_9BC0DE80D827414B916BC102C3460563ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGksDQoNClZlcnkgZ29vZCBkb2N1bWVudC4NCg0KSSBoYXRlIHRvIGFzayB0aGluZ3Mg d2l0aG91dCBwcm92aWRpbmcgY29kZSBidXQgSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGdyZWF0IGlm IHlvdSBhZGQgYSBzZWN0aW9uIHJlZ2FyZGluZyB0aGUg4oCccmVseWluZyBwYXJ0eeKAnSwgaG93 IHdvdWxkIHRoZSB2YWxpZGF0aW9uIGFsZ29yaXRobSB3b3VsZCBsb29rIGxpa2UgYW5kIHdoYXQg aXMgdGhlIGJvb3RzdHJhcCBwcm9jZXNzLiBJIGNhbiBzZWUgdGhhdCBzb21lIHB1YmxpYyBrZXkg aW5mbyB3b3VsZCBuZWVkIHRvIGJlIGtub3duIGJ5IHRoZSBSUC4NCg0KUmVnYXJkcywNClJvcXVl DQoNCg0KRnJvbTogT1BTRUMgPG9wc2VjLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBK b3JkaSBQYWlsbGlzc8OpIFZpbGFub3ZhIDxqb3JkaXBAYWMudXBjLmVkdT4NCkRhdGU6IFdlZG5l c2RheSA0IEp1bHkgMjAxOCBhdCAxMzoyOA0KVG86IERhdmlkIE1hemllcmVzIGV4cGlyZXMgMjAx OC0wOS0zMCBQRFQgPG1hemllcmVzLXBlYmFncjd5c2pnaHdwcWtjcXFuampmNHRhQHRlbXBvcmFy eS1hZGRyZXNzLnNjcy5zdGFuZm9yZC5lZHU+LCAic2lkcm9wc0BpZXRmLm9yZyIgPHNpZHJvcHNA aWV0Zi5vcmc+LCAiZGluQGlydGYub3JnIiA8ZGluQGlydGYub3JnPiwgU3RlcGhhbmUgQm9ydHpt ZXllciA8Ym9ydHptZXllckBuaWMuZnI+LCAic2FuZHlAdGlzbGFicy5jb20iIDxzYW5keUB0aXNs YWJzLmNvbT4sIEdyZWcgU2tpbm5lciA8Z3JlZ3NraW5uZXIwQGljbG91ZC5jb20+LCAibGVvQHZl Z29kYS5vcmciIDxsZW9AdmVnb2RhLm9yZz4sICJBbGJlcnRvIFJvZHJpZ3VleiBOYXRhbCAobmF0 YWwpIiA8bmF0YWxAY2lzY28uY29tPiwgIlZpbmEgRXJtYWdhbiAodmVybWFnYW4pIiA8dmVybWFn YW5AY2lzY28uY29tPiwgIkZhYmlvIE1haW5vIChmbWFpbm8pIiA8Zm1haW5vQGNpc2NvLmNvbT4s IEFsYmVydCBDYWJlbGxvcyA8YWNhYmVsbG9AYWMudXBjLmVkdT4sICJvcHNlY0BpZXRmLm9yZyIg PG9wc2VjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPUFNFQ10gW0Rpbl0gYmxvY2tjaGFpbiBm b3IgSVAgYWRkcmVzc2VzIGRyYWZ0IHVwZGF0ZQ0KDQoNCkhpIERhdmlkLA0KDQpJbmRlZWQsIHdl IGRpZCBub3QgZGVsdmUgZGVlcGVyIGludG8gdGhlIFBvUyBhbGdvcml0aG0uIFRoaXMgZGVwZW5k cyBvbiB0aGUgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24sIG91ciBvcGluaW9uIGlzIHRoYXQgYW4g QWxncm9hbmQtbGlrZSB3b3VsZCBiZSBhIGdvb2Qgb3B0aW9uLCBhbmQgaWYgaXQgY2FuIHRvbGVy YXRlIGEgbGFyZ2UgcG9ydGlvbiBvZiBvZmZsaW5lIHBhcnRpY2lwYW50cyBldmVuIGJldHRlci4g SW4gYWRkaXRpb24sIHdlIHRoaW5rIHRoYXQgcHVuaXNoaW5nIG9yIGRlcG9zaXQgbWVjaGFuaXNt cyBhcmUgbm90IGRlc2lyYWJsZSBiZWNhdXNlIHRoZXkgZG9uJ3QgZml0IHRoZSBjaGFyYWN0ZXJp c3RpY3Mgb2YgdGhlIHNjZW5hcmlvLiBPdmVyYWxsIHRoZSBpbmNlbnRpdmUgaXMgImEgbW9yZSBz ZWN1cmUgSW50ZXJuZXQiLCB3ZSBiZWxpZXZlIHRoYXQgdGhpcyBpcyB3ZWxsLWFsaWduZWQgd2l0 aCB0aGUgZWNvbm9taWNhbCBpbnRlcmVzdHMgb2YgdGhlIHBhcnRpY2lwYW50cy4NCg0KUmVnYXJk aW5nIFNDUCwgdGhlIGZhY3QgdGhhdCB5b3Ugb25seSBuZWVkIHRvIHRydXN0IHlvdXIgbmVpZ2hi b3VycyBtYXkgcHJvdmUgdmVyeSBjb252ZW5pZW50IGluIHRoaXMgc2NlbmFyaW8uIEFzIHlvdSBz YWlkLCBpdCByZWZsZWN0cyBjdXJyZW50IEludGVybmV0IHRydXN0IHNjaGVtZXMsIHRoaXMgYmFz aWNhbGx5IG1lYW5zIHRoYXQgQkdQIFBlZXJpbmcgPSBUcnVzdCA9IFN0ZWxsYXIgcXVvcnVtIHNs aWNlcy4gV2UnbGwgbG9vayBpbnRvIHRoaXMgZm9yIHRoZSBuZXh0IGl0ZXJhdGlvbiBvZiB0aGUg ZHJhZnQuDQoNClRoYW5rcw0KDQpKb3JkaQ0KDQpFbCAwMi8wNy8xOCBhIGxlcyAxNzo1OSwgRGF2 aWQgTWF6aWVyZXMgaGEgZXNjcml0Og0KDQpKb3JkaSBQYWlsbGlzc8OpIFZpbGFub3ZhIDxqb3Jk aXBAYWMudXBjLmVkdT48bWFpbHRvOmpvcmRpcEBhYy51cGMuZWR1PiB3cml0ZXM6DQoNCg0KDQoo YXBvbG9naWVzIGZvciBjcm9zcy1wb3N0aW5nKQ0KDQoNCg0KRGVhciBhbGwsDQoNCg0KDQpXZSBo YXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBhZGRyZXNzaW5nIGNvbW1l bnRzDQoNCnJlY2VpdmVkIGJvdGggb24gdGhlIG1haWxpbmcgbGlzdCBhbmQgSUVURiBtZWV0aW5n cy4NCg0KDQoNClRoYW5rcyB0byBhbGwgb2YgeW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmVh ZCB0aGUgZHJhZnQgOikNCg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpKb3JkaQ0KDQpWZXJ5IGludGVy ZXN0aW5nIGRyYWZ0LiAgT25lIGhpZ2gtbGV2ZWwgY29tbWVudCwgSSB3b3VsZCBhdm9pZCB0ZXJt cw0KDQpsaWtlICJ0YW1wZXItcHJvb2YiIG9yIHJlYWxseSBhbnl0aGluZy0icHJvb2YiIGV4Y2Vw dCBwb3NzaWJseSBpbiB0aGUNCg0KY29udGV4dCBvZiBpbmZvcm1hdGlvbi10aGVvcmV0aWMgc2Vj dXJpdHksIGluIGZhdm9yIG9mIHRhbXBlci1yZXNpc3RhbnQuDQoNClRoaXMgaXMgcGFydGljdWxh cmx5IGltcG9ydGFudCBpbiB0aGUgY29udGV4dCBvZiBibG9ja2NoYWlucyB0aGF0IGhhdmUNCg0K ZXhwZXJpZW5jZWQgYSBudW1iZXIgb2YgZm9ya3MgaW4gcHJhY3RpY2UgYW5kIHdoZXJlIGl0IHdv dWxkIGxpa2VseSB0YWtlDQoNCm9ubHkgYSBmZXcgdGVucyBvZiBtaWxsaW9ucyBvZiBkb2xsYXJz IGEgZGF5IHRvIHRhbXBlciB3aXRoIGhpc3RvcnkuDQoNCg0KDQpJIHRoaW5rIHRoZSBkcmFmdCB3 b3VsZCBiZW5lZml0IGZyb20gYSBtdWNoIGZpbmVyLWdyYWluZWQgY29uc2lkZXJhdGlvbg0KDQpv ZiBzZXZlcmFsIGRpZmZlcmVudCBmb3JtcyBvZiBwcm9vZi1vZi1zdGFrZSwgYmVjYXVzZSB0aGVy ZSBhcmUgYSBudW1iZXINCg0Kb2YgYXNzZXJ0aW9ucyB0aGF0IGRvIG5vdCBob2xkIGZvciBhbGwg Zm9ybXMgb2YgcHJvb2Ygb2Ygc3Rha2UuICBFLmcuLA0KDQp3aWxsIHRoZXJlIGJlIGRlbGVnYXRp b24gbGlrZSBwZWVyY29pbiwgcmFuZG9taXphdGlvbiBsaWtlIGFsZ29yYW5kLA0KDQpwZW5hbHRp ZXMgbGlrZSBDYXNwZXIsIHNsZWVweSBub2RlcyBsaWtlIHNub3d3aGl0ZT8NCg0KDQoNCkFuZCB3 aGlsZSBvZiBjb3Vyc2UgSSdtIGJpYXNlZCBvbiB0aGlzIGlzc3VlLCBJIHRoaW5rIHRoYXQgYQ0K DQpCeXphbnRpbmUtYWdyZWVtZW50LWJhc2VkIGFwcHJvYWNoIGxpa2UgU0NQDQoNCihodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYXppZXJlcy1kaW5yZy1zY3AvKSB3b3Vs ZCB3b3JrDQoNCmJldHRlciB0aGFuIFBvUy4gIFNDUCBpcyB3ZWxsIG1hdGNoZWQgdG8gdGhlIElu dGVybmV0IHBlZXJpbmcgbW9kZWwsDQoNCndoaWNoIHdlIGFscmVhZHkga25vdyBpcyBhIHdvcmth YmxlIGRlY2VudHJhbGl6ZWQgZ292ZXJuYW5jZSBtb2RlbC4gIFlvdQ0KDQptYXkgbm90IGFncmVl LCBidXQgaXQgd291bGQgYXQgbGVhc3QgYmUgbmljZSBmb3IgdGhlIGRvY3VtZW50IHRvIGV4cGxh aW4NCg0Kd2h5IHlvdSByZWplY3QgdGhpcyBhcHByb2FjaC4NCg0KDQoNCkRhdmlkDQoNCg0K --_000_9BC0DE80D827414B916BC102C3460563ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <00879672BE7E5B4392948F6B3925BC61@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFtZTppbTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEpvcmRpLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5WZXJ5IGdvb2QgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgaGF0ZSB0byBhc2sgdGhpbmdzIHdpdGhvdXQgcHJvdmlkaW5nIGNvZGUgYnV0IEkg YmVsaWV2ZSBpdCB3b3VsZCBiZSBncmVhdCBpZiB5b3UgYWRkIGEgc2VjdGlvbiByZWdhcmRpbmcg dGhlIOKAnHJlbHlpbmcgcGFydHnigJ0sIGhvdyB3b3VsZCB0aGUgdmFsaWRhdGlvbiBhbGdvcml0 aG0gd291bGQgbG9vayBsaWtlIGFuZCB3aGF0IGlzIHRoZSBib290c3RyYXAgcHJvY2Vzcy4gSSBj YW4gc2VlIHRoYXQgc29tZSBwdWJsaWMNCiBrZXkgaW5mbyB3b3VsZCBuZWVkIHRvIGJlIGtub3du IGJ5IHRoZSBSUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvcXVlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PUFNFQyAmbHQ7b3BzZWMtYm91bmNlc0Bp ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEpvcmRpIFBhaWxsaXNzw6kgVmlsYW5vdmEgJmx0O2pv cmRpcEBhYy51cGMuZWR1Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXkgNCBKdWx5IDIw MTggYXQgMTM6Mjg8YnI+DQo8Yj5UbzogPC9iPkRhdmlkIE1hemllcmVzIGV4cGlyZXMgMjAxOC0w OS0zMCBQRFQgJmx0O21hemllcmVzLXBlYmFncjd5c2pnaHdwcWtjcXFuampmNHRhQHRlbXBvcmFy eS1hZGRyZXNzLnNjcy5zdGFuZm9yZC5lZHUmZ3Q7LCAmcXVvdDtzaWRyb3BzQGlldGYub3JnJnF1 b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0OywgJnF1b3Q7ZGluQGlydGYub3JnJnF1b3Q7ICZs dDtkaW5AaXJ0Zi5vcmcmZ3Q7LCBTdGVwaGFuZSBCb3J0em1leWVyICZsdDtib3J0em1leWVyQG5p Yy5mciZndDssICZxdW90O3NhbmR5QHRpc2xhYnMuY29tJnF1b3Q7ICZsdDtzYW5keUB0aXNsYWJz LmNvbSZndDssDQogR3JlZyBTa2lubmVyICZsdDtncmVnc2tpbm5lcjBAaWNsb3VkLmNvbSZndDss ICZxdW90O2xlb0B2ZWdvZGEub3JnJnF1b3Q7ICZsdDtsZW9AdmVnb2RhLm9yZyZndDssICZxdW90 O0FsYmVydG8gUm9kcmlndWV6IE5hdGFsIChuYXRhbCkmcXVvdDsgJmx0O25hdGFsQGNpc2NvLmNv bSZndDssICZxdW90O1ZpbmEgRXJtYWdhbiAodmVybWFnYW4pJnF1b3Q7ICZsdDt2ZXJtYWdhbkBj aXNjby5jb20mZ3Q7LCAmcXVvdDtGYWJpbyBNYWlubyAoZm1haW5vKSZxdW90OyAmbHQ7Zm1haW5v QGNpc2NvLmNvbSZndDssIEFsYmVydCBDYWJlbGxvcyAmbHQ7YWNhYmVsbG9AYWMudXBjLmVkdSZn dDssDQogJnF1b3Q7b3BzZWNAaWV0Zi5vcmcmcXVvdDsgJmx0O29wc2VjQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09QU0VDXSBbRGluXSBibG9ja2NoYWluIGZvciBJUCBh ZGRyZXNzZXMgZHJhZnQgdXBkYXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhp IERhdmlkLDxicj4NCjxicj4NCkluZGVlZCwgd2UgZGlkIG5vdCBkZWx2ZSBkZWVwZXIgaW50byB0 aGUgUG9TIGFsZ29yaXRobS4gVGhpcyBkZXBlbmRzIG9uIHRoZSBzcGVjaWZpYyBpbXBsZW1lbnRh dGlvbiwgb3VyIG9waW5pb24gaXMgdGhhdCBhbg0KPHNwYW4gY2xhc3M9ImltIj5BbGdyb2FuZC1s aWtlIHdvdWxkIGJlIGEgZ29vZCBvcHRpb24sIGFuZCBpZiBpdCBjYW4gdG9sZXJhdGUgYSBsYXJn ZSBwb3J0aW9uIG9mIG9mZmxpbmUgcGFydGljaXBhbnRzIGV2ZW4gYmV0dGVyLiBJbiBhZGRpdGlv biwgd2UgdGhpbmsgdGhhdCBwdW5pc2hpbmcgb3IgZGVwb3NpdCBtZWNoYW5pc21zIGFyZSBub3Qg ZGVzaXJhYmxlIGJlY2F1c2UgdGhleQ0KPC9zcGFuPmRvbid0IGZpdCB0aGUgY2hhcmFjdGVyaXN0 aWNzIG9mIHRoZSBzY2VuYXJpby4gT3ZlcmFsbCB0aGUgaW5jZW50aXZlIGlzICZxdW90O2EgbW9y ZSBzZWN1cmUgSW50ZXJuZXQmcXVvdDssIHdlIGJlbGlldmUgdGhhdCB0aGlzIGlzIHdlbGwtYWxp Z25lZCB3aXRoIHRoZSBlY29ub21pY2FsIGludGVyZXN0cyBvZiB0aGUgcGFydGljaXBhbnRzLg0K PGJyPg0KPGJyPg0KUmVnYXJkaW5nIFNDUCwgdGhlIGZhY3QgdGhhdCB5b3Ugb25seSBuZWVkIHRv IHRydXN0IHlvdXIgbmVpZ2hib3VycyA8c3BhbiBjbGFzcz0iaW0iPg0KbWF5IHByb3ZlIHZlcnkg Y29udmVuaWVudCBpbiB0aGlzIHNjZW5hcmlvLiBBcyB5b3Ugc2FpZCwgaXQgcmVmbGVjdHMgPC9z cGFuPmN1cnJlbnQgSW50ZXJuZXQgdHJ1c3Qgc2NoZW1lcywgdGhpcyBiYXNpY2FsbHkgbWVhbnMg dGhhdCBCR1AgUGVlcmluZyA9IFRydXN0ID0gU3RlbGxhciBxdW9ydW0gc2xpY2VzLiBXZSdsbCBs b29rIGludG8gdGhpcyBmb3IgdGhlIG5leHQgaXRlcmF0aW9uIG9mIHRoZSBkcmFmdC48YnI+DQo8 YnI+DQpUaGFua3M8YnI+DQo8YnI+DQpKb3JkaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ RWwgMDIvMDcvMTggYSBsZXMgMTc6NTksIERhdmlkIE1hemllcmVzIGhhIGVzY3JpdDo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkpvcmRp IFBhaWxsaXNzw6kgVmlsYW5vdmEgPGEgaHJlZj0ibWFpbHRvOmpvcmRpcEBhYy51cGMuZWR1Ij4m bHQ7am9yZGlwQGFjLnVwYy5lZHUmZ3Q7PC9hPiB3cml0ZXM6PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4oYXBvbG9naWVzIGZvciBjcm9zcy1wb3N0 aW5nKTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkRl YXIgYWxsLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFkZHJlc3Npbmcg Y29tbWVudHMgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+cmVjZWl2ZWQgYm90aCBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCBJRVRGIG1lZXRpbmdzLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYW5rcyB0 byBhbGwgb2YgeW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmVhZCB0aGUgZHJhZnQgOik8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkpvcmRpPG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+VmVyeSBpbnRlcmVzdGluZyBkcmFmdC4mbmJzcDsgT25lIGhpZ2gtbGV2ZWwgY29tbWVu dCwgSSB3b3VsZCBhdm9pZCB0ZXJtczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPmxpa2UgJnF1b3Q7dGFtcGVyLXByb29mJnF1b3Q7IG9yIHJlYWxseSBh bnl0aGluZy0mcXVvdDtwcm9vZiZxdW90OyBleGNlcHQgcG9zc2libHkgaW4gdGhlPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Y29udGV4dCBvZiBpbmZv cm1hdGlvbi10aGVvcmV0aWMgc2VjdXJpdHksIGluIGZhdm9yIG9mIHRhbXBlci1yZXNpc3RhbnQu PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhpcyBp cyBwYXJ0aWN1bGFybHkgaW1wb3J0YW50IGluIHRoZSBjb250ZXh0IG9mIGJsb2NrY2hhaW5zIHRo YXQgaGF2ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PmV4cGVyaWVuY2VkIGEgbnVtYmVyIG9mIGZvcmtzIGluIHByYWN0aWNlIGFuZCB3aGVyZSBpdCB3 b3VsZCBsaWtlbHkgdGFrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPm9ubHkgYSBmZXcgdGVucyBvZiBtaWxsaW9ucyBvZiBkb2xsYXJzIGEgZGF5IHRv IHRhbXBlciB3aXRoIGhpc3RvcnkuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+SSB0aGluayB0aGUgZHJhZnQgd291bGQgYmVuZWZpdCBmcm9tIGEgbXVj aCBmaW5lci1ncmFpbmVkIGNvbnNpZGVyYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5vZiBzZXZlcmFsIGRpZmZlcmVudCBmb3JtcyBvZiBwcm9v Zi1vZi1zdGFrZSwgYmVjYXVzZSB0aGVyZSBhcmUgYSBudW1iZXI8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5vZiBhc3NlcnRpb25zIHRoYXQgZG8gbm90 IGhvbGQgZm9yIGFsbCBmb3JtcyBvZiBwcm9vZiBvZiBzdGFrZS4mbmJzcDsgRS5nLiw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij53aWxsIHRoZXJlIGJl IGRlbGVnYXRpb24gbGlrZSBwZWVyY29pbiwgcmFuZG9taXphdGlvbiBsaWtlIGFsZ29yYW5kLDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnBlbmFsdGll cyBsaWtlIENhc3Blciwgc2xlZXB5IG5vZGVzIGxpa2Ugc25vd3doaXRlPzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFuZCB3aGlsZSBvZiBjb3Vyc2Ug SSdtIGJpYXNlZCBvbiB0aGlzIGlzc3VlLCBJIHRoaW5rIHRoYXQgYTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkJ5emFudGluZS1hZ3JlZW1lbnQtYmFz ZWQgYXBwcm9hY2ggbGlrZSBTQ1A8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4oPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbWF6aWVyZXMtZGlucmctc2NwLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbWF6aWVyZXMtZGlucmctc2NwLzwvYT4pIHdvdWxkIHdvcms8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5iZXR0ZXIgdGhhbiBQb1MuJm5i c3A7IFNDUCBpcyB3ZWxsIG1hdGNoZWQgdG8gdGhlIEludGVybmV0IHBlZXJpbmcgbW9kZWwsPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+d2hpY2ggd2Ug YWxyZWFkeSBrbm93IGlzIGEgd29ya2FibGUgZGVjZW50cmFsaXplZCBnb3Zlcm5hbmNlIG1vZGVs LiZuYnNwOyBZb3U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5tYXkgbm90IGFncmVlLCBidXQgaXQgd291bGQgYXQgbGVhc3QgYmUgbmljZSBmb3IgdGhl IGRvY3VtZW50IHRvIGV4cGxhaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij53aHkgeW91IHJlamVjdCB0aGlzIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkRhdmlkPG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_9BC0DE80D827414B916BC102C3460563ciscocom_-- From nobody Wed Jul 4 08:50:41 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C054130E6C; Wed, 4 Jul 2018 08:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3zOPeRILVRne; Wed, 4 Jul 2018 08:50:33 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 93CF112785F; Wed, 4 Jul 2018 08:50:32 -0700 (PDT) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id w64FoIqD012465; Wed, 4 Jul 2018 17:50:18 +0200 Received: from [147.83.35.232] (dync-35-232.ac.upc.es [147.83.35.232]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 1CED1283; Wed, 4 Jul 2018 17:50:13 +0200 (CEST) To: "Roque Gagliano (rogaglia)" , David Mazieres expires 2018-09-30 PDT , "sidrops@ietf.org" , "din@irtf.org" , Stephane Bortzmeyer , "sandy@tislabs.com" , Greg Skinner , "leo@vegoda.org" , "Alberto Rodriguez Natal (natal)" , "Vina Ermagan (vermagan)" , "Fabio Maino (fmaino)" , Albert Cabellos , "opsec@ietf.org" References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> <87lgat633l.fsf@ta.scs.stanford.edu> <9BC0DE80-D827-414B-916B-C102C3460563@cisco.com> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: <56694f02-cf91-8569-c57f-7f3c319a7e9f@ac.upc.edu> Date: Wed, 4 Jul 2018 17:50:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <9BC0DE80-D827-414B-916B-C102C3460563@cisco.com> Content-Type: multipart/alternative; boundary="------------C635D4B6DCE5FBC5E32EEF32" Content-Language: en-US Archived-At: Subject: Re: [OPSEC] [Din] blockchain for IP addresses draft update X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 15:50:40 -0000 This is a multi-part message in MIME format. --------------C635D4B6DCE5FBC5E32EEF32 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Roque, We have built an open-source prototype [1], and it works like you mentioned: the genesis block includes the public keys that the RP has to trust. It is a one-time action in which you trust the source code and the keys contained in it. Thanks for your comments, we'll include them in the next version. Regards, Jordi [1] https://github.com/OpenOverlayRouter/blockchain-mapping-system El 04/07/18 a les 14:09, Roque Gagliano (rogaglia) ha escrit: > > Hi Jordi, > > Very good document. > > I hate to ask things without providing code but I believe it would be > great if you add a section regarding the “relying party”, how would > the validation algorithm would look like and what is the bootstrap > process. I can see that some public key info would need to be known by > the RP. > > Regards, > > Roque > > *From: *OPSEC on behalf of Jordi Paillissé > Vilanova > *Date: *Wednesday 4 July 2018 at 13:28 > *To: *David Mazieres expires 2018-09-30 PDT > , > "sidrops@ietf.org" , "din@irtf.org" , > Stephane Bortzmeyer , "sandy@tislabs.com" > , Greg Skinner , > "leo@vegoda.org" , "Alberto Rodriguez Natal (natal)" > , "Vina Ermagan (vermagan)" , > "Fabio Maino (fmaino)" , Albert Cabellos > , "opsec@ietf.org" > *Subject: *Re: [OPSEC] [Din] blockchain for IP addresses draft update > > Hi David, > > Indeed, we did not delve deeper into the PoS algorithm. This depends > on the specific implementation, our opinion is that an Algroand-like > would be a good option, and if it can tolerate a large portion of > offline participants even better. In addition, we think that punishing > or deposit mechanisms are not desirable because they don't fit the > characteristics of the scenario. Overall the incentive is "a more > secure Internet", we believe that this is well-aligned with the > economical interests of the participants. > > Regarding SCP, the fact that you only need to trust your neighbours > may prove very convenient in this scenario. As you said, it reflects > current Internet trust schemes, this basically means that BGP Peering > = Trust = Stellar quorum slices. We'll look into this for the next > iteration of the draft. > > Thanks > > Jordi > > El 02/07/18 a les 17:59, David Mazieres ha escrit: > > Jordi Paillissé Vilanova writes: > > (apologies for cross-posting) > > Dear all, > > We have submitted a new version of the draft addressing comments > > received both on the mailing list and IETF meetings. > > Thanks to all of you for taking the time to read the draft :) > > Regards, > > Jordi > > Very interesting draft.  One high-level comment, I would avoid terms > > like "tamper-proof" or really anything-"proof" except possibly in the > > context of information-theoretic security, in favor of tamper-resistant. > > This is particularly important in the context of blockchains that have > > experienced a number of forks in practice and where it would likely take > > only a few tens of millions of dollars a day to tamper with history. > > I think the draft would benefit from a much finer-grained consideration > > of several different forms of proof-of-stake, because there are a number > > of assertions that do not hold for all forms of proof of stake.  E.g., > > will there be delegation like peercoin, randomization like algorand, > > penalties like Casper, sleepy nodes like snowwhite? > > And while of course I'm biased on this issue, I think that a > > Byzantine-agreement-based approach like SCP > > (https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work > > better than PoS.  SCP is well matched to the Internet peering model, > > which we already know is a workable decentralized governance model.  You > > may not agree, but it would at least be nice for the document to explain > > why you reject this approach. > > David > > > --------------C635D4B6DCE5FBC5E32EEF32 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Roque,

We have built an open-source prototype [1], and it works like you mentioned: the genesis block includes the public keys that the RP has to trust. It is a one-time action in which you trust the source code and the keys contained in it.

Thanks for your comments, we'll include them in the next version.

Regards,

Jordi

[1] https://github.com/OpenOverlayRouter/blockchain-mapping-system


El 04/07/18 a les 14:09, Roque Gagliano (rogaglia) ha escrit:

Hi Jordi,

 

Very good document.

 

I hate to ask things without providing code but I believe it would be great if you add a section regarding the “relying party”, how would the validation algorithm would look like and what is the bootstrap process. I can see that some public key info would need to be known by the RP.

 

Regards,

Roque

 

 

From: OPSEC <opsec-bounces@ietf.org> on behalf of Jordi Paillissé Vilanova <jordip@ac.upc.edu>
Date: Wednesday 4 July 2018 at 13:28
To: David Mazieres expires 2018-09-30 PDT <mazieres-pebagr7ysjghwpqkcqqnjjf4ta@temporary-address.scs.stanford.edu>, "sidrops@ietf.org" <sidrops@ietf.org>, "din@irtf.org" <din@irtf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, "sandy@tislabs.com" <sandy@tislabs.com>, Greg Skinner <gregskinner0@icloud.com>, "leo@vegoda.org" <leo@vegoda.org>, "Alberto Rodriguez Natal (natal)" <natal@cisco.com>, "Vina Ermagan (vermagan)" <vermagan@cisco.com>, "Fabio Maino (fmaino)" <fmaino@cisco.com>, Albert Cabellos <acabello@ac.upc.edu>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [Din] blockchain for IP addresses draft update

 

Hi David,

Indeed, we did not delve deeper into the PoS algorithm. This depends on the specific implementation, our opinion is that an Algroand-like would be a good option, and if it can tolerate a large portion of offline participants even better. In addition, we think that punishing or deposit mechanisms are not desirable because they don't fit the characteristics of the scenario. Overall the incentive is "a more secure Internet", we believe that this is well-aligned with the economical interests of the participants.

Regarding SCP, the fact that you only need to trust your neighbours may prove very convenient in this scenario. As you said, it reflects current Internet trust schemes, this basically means that BGP Peering = Trust = Stellar quorum slices. We'll look into this for the next iteration of the draft.

Thanks

Jordi

 

El 02/07/18 a les 17:59, David Mazieres ha escrit:

Jordi Paillissé Vilanova <jordip@ac.upc.edu> writes:
 
(apologies for cross-posting)
 
Dear all,
 
We have submitted a new version of the draft addressing comments 
received both on the mailing list and IETF meetings.
 
Thanks to all of you for taking the time to read the draft :)
 
Regards,
 
Jordi
Very interesting draft.  One high-level comment, I would avoid terms
like "tamper-proof" or really anything-"proof" except possibly in the
context of information-theoretic security, in favor of tamper-resistant.
This is particularly important in the context of blockchains that have
experienced a number of forks in practice and where it would likely take
only a few tens of millions of dollars a day to tamper with history.
 
I think the draft would benefit from a much finer-grained consideration
of several different forms of proof-of-stake, because there are a number
of assertions that do not hold for all forms of proof of stake.  E.g.,
will there be delegation like peercoin, randomization like algorand,
penalties like Casper, sleepy nodes like snowwhite?
 
And while of course I'm biased on this issue, I think that a
Byzantine-agreement-based approach like SCP
(https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work
better than PoS.  SCP is well matched to the Internet peering model,
which we already know is a workable decentralized governance model.  You
may not agree, but it would at least be nice for the document to explain
why you reject this approach.
 
David




--------------C635D4B6DCE5FBC5E32EEF32-- From nobody Fri Jul 6 06:43:16 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022F9130E36 for ; Fri, 6 Jul 2018 06:43:14 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 whMuiEt3LgyK for ; Fri, 6 Jul 2018 06:43:12 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07B91277BB for ; Fri, 6 Jul 2018 06:43:11 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id h5-v6so9932282qtm.13 for ; Fri, 06 Jul 2018 06:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=YQ31H3vaECbQipHeo4fMz/V/dqQ0DzI8bjMdL9tPL/A=; b=KjJpucLlR/yIm1IMiVddV0CVHbKOzmJKJWAFfgZFzmc2gPMlGND8YPey2w77o5TwmY bHWSyPYE4QFZlTswcH8YkwRQNUM3K4G4HKHsZPfxKhv5VIF+zyEZqOBEX2V4tC2im2Qq V/wQL+laW0ukWBXIvR/lT5EN7nGEgaYF+w+o1brntl4JJzEL75oywrecsNDpStWoCLcg IQVeJx2IjhWLKEGg1MU0o4wj5Gy97lCKijVU5GhI5QcgMbwWPZPSI/wkQ1Sq2kC8h7xF xYQVO6ewlq58HyzjnoTi781dPSi6vXxfrSzKJ047JHRN4fWmX/U7VfuOo43poekdMnjX kgRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=YQ31H3vaECbQipHeo4fMz/V/dqQ0DzI8bjMdL9tPL/A=; b=P/kkuSwAbJbjg6yAKbFwBYZhdpdGNXll8W4lTUjxUXurGVOYSF/ae1V1HT73aVABml M7v7cui9jCdQIKQWN48i/d1kj8ps0exj+HTHw06yPLC9WgXyetuzCebCF3TB8I+irdAz 6if3RZX4lwb3H+tUNhcrTRcimO5y6gciOStdCSO3mTaFeh8+ZCgEKDftsk6iXDvl/eyk TYAXBOUNOSb1aY689ohComxLaskZ63EQ0CWHqDd/gL2qmfy4+hs+izZMFkkJVinRaGc3 FparrwhZ6ks2zAF0fczW/WCkIuJSx3clBVhDSPHhMCKANyxAXw6UlXbIAM39RQAjmpri D6yQ== X-Gm-Message-State: APt69E0Pr8PPgFVr3TAzgOMJnCygQNIONvgYMof4mYwhGP957yh8syAe I8KReU4cheluuResQB1BUlVKjQ== X-Google-Smtp-Source: AAOMgpeCqNP89+g/FIPNE3Pc4nSlxTGDMzjmmguuvSzJuHOA64os6xfbT0uxtHun9A0movHVD+89Pg== X-Received: by 2002:ac8:29e:: with SMTP id p30-v6mr9408699qtg.131.1530884590923; Fri, 06 Jul 2018 06:43:10 -0700 (PDT) Received: from [10.30.20.14] (pool-96-241-84-161.washdc.fios.verizon.net. [96.241.84.161]) by smtp.gmail.com with ESMTPSA id l73-v6sm9088184qkl.78.2018.07.06.06.43.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 06:43:10 -0700 (PDT) From: "R. Atkinson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <533B0D96-D9BE-4A10-A66D-71BC706E1250@gmail.com> Date: Fri, 6 Jul 2018 09:43:09 -0400 Cc: Fernando Gont , RJ Atkinson To: opsec@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [OPSEC] draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 13:43:14 -0000 Fernando, Regarding this draft, I have some feedback with respect to CALIPSO (in part because I am one of the co-authors of RFC-5570, which specifies CALIPSO). 1. Section 4.3.9 makes an incorrect assumption. Contrary to 4.3.9.5, an intermediate system (e.g., IP router) has no = method to learn or know whether or not it is deployed in an MLS-enabled = environment. An MLS-enabled IPv6 environment might well be using globally routable addresses, so the routing prefixes in use are not informative about = the deployment type. Further, the majority of routers in an MLS-enabled environment are = ordinary commercial off-the-shelf IP routers from the usual IP router vendors. = Some routers and firewalls in such environments might have = MLS-enhancements,=20 but many more will NOT have MLS-enhancements. This is partly because the MLS-enabled label enforcement only is needed at enclave = boundaries. Explicit configuration is the only method via which a particular = deployed intermediate system can learn whether or not it is in an MLS-enabled network environment. This is sad, but also is reality. SUGGESTED ADDITIONAL TEXT for 4.3.9.1: "Explicit configuration is the only method via which a particular = deployed intermediate system can learn whether or not it is in an MLS-enabled network environment." 2. As a result, the advice in 4.3.9.5 is not good or correct. Incorrect = assumption above leads to an incorrect conclusion about advice on option = handling. My suggestion is to revise the advice in 4.3.9.5. PROPOSED REPLACEMENT TEXT for 4.3.9.5: =E2=80=9CIntermediate systems that do not implement RFC-5570 SHOULD = have=20 a configuration option to EITHER (a) drop packets containing the=20 CALIPSO option OR (b) to ignore the presence of the CALIPSO option and forward the packets normally.=E2=80=9D =E2=80=9CIntermediate systems that do implement RFC-5570 SHOULD have = both configuration options (a) and (b) from the preceding paragraph and=20 also a third configuration option (c) to process packets containing a CALIPSO option as per RFC-5570." "Such configuration is the only method via which an intermediate = system can know whether or not that particular intermediate system has been=20= deployed within an MLS-enabled environment. In many cases, ordinary=20= commercial intermediate systems (e.g., IPv6 routers & firewalls) are = the=20 majority of the deployed intermediate systems inside an MLS-enabled=20= network environment." =20 Yours, Ran From nobody Fri Jul 6 08:10:54 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E46130E63 for ; Fri, 6 Jul 2018 08:10:52 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 XEWNr8J45TLU for ; Fri, 6 Jul 2018 08:10:50 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F9A0130E96 for ; Fri, 6 Jul 2018 08:10:49 -0700 (PDT) Received: from [192.168.88.59] (unknown [77.120.246.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B95DA82DC5; Fri, 6 Jul 2018 17:10:46 +0200 (CEST) To: "R. Atkinson" , opsec@ietf.org References: <533B0D96-D9BE-4A10-A66D-71BC706E1250@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <96928ad2-953c-20f0-a6b1-4c809caf6d88@gont.com.ar> Date: Fri, 6 Jul 2018 16:41:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <533B0D96-D9BE-4A10-A66D-71BC706E1250@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 15:10:53 -0000 Hello, Ran, I realize that you had sent feedback on this topic before, but for sme reason I had missed it -- my apologies for that! Please find my comments in-line.... On 07/06/2018 03:43 PM, R. Atkinson wrote: > Fernando, > > Regarding this draft, I have some feedback with respect to CALIPSO > (in part because I am one of the co-authors of RFC-5570, which specifies > CALIPSO). > > 1. Section 4.3.9 makes an incorrect assumption. > > Contrary to 4.3.9.5, an intermediate system (e.g., IP router) has no method > to learn or know whether or not it is deployed in an MLS-enabled environment. > > An MLS-enabled IPv6 environment might well be using globally routable > addresses, so the routing prefixes in use are not informative about the > deployment type. > > Further, the majority of routers in an MLS-enabled environment are ordinary > commercial off-the-shelf IP routers from the usual IP router vendors. Some > routers and firewalls in such environments might have MLS-enhancements, > but many more will NOT have MLS-enhancements. This is partly because > the MLS-enabled label enforcement only is needed at enclave boundaries. > > Explicit configuration is the only method via which a particular deployed > intermediate system can learn whether or not it is in an MLS-enabled > network environment. This is sad, but also is reality. Question: would you argue that this would warrant forwarding them at transit routers? (I ask because while the answer to this question would most likely be "yes" if within a domain, I bet at a transit router it would be better to drop the MLS traffic to avoid leaks?) -- please see the applicability statement in Section 2.2. > > SUGGESTED ADDITIONAL TEXT for 4.3.9.1: > > "Explicit configuration is the only method via which a particular deployed > intermediate system can learn whether or not it is in an MLS-enabled > network environment." We will incorporate this. Thanks for suggesting text! > 2. As a result, the advice in 4.3.9.5 is not good or correct. Incorrect assumption > above leads to an incorrect conclusion about advice on option handling. > > My suggestion is to revise the advice in 4.3.9.5. > > PROPOSED REPLACEMENT TEXT for 4.3.9.5: > > “Intermediate systems that do not implement RFC-5570 SHOULD have > a configuration option to EITHER (a) drop packets containing the > CALIPSO option OR (b) to ignore the presence of the CALIPSO option > and forward the packets normally.” A couple of questions here: * What would you argue that de default value of this knob should be? * In any case, I'd somehow rephrase the advice, since it implies a requirement for a CALIPSO-specific knob --while we don't require any option-specific knob for any other option. Thoughts? Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Jul 6 08:49:29 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237A6130E89 for ; Fri, 6 Jul 2018 08:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xbHftkfzZAHL for ; Fri, 6 Jul 2018 08:49:24 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FBF130E6E for ; Fri, 6 Jul 2018 08:49:24 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id u21-v6so6547710qku.2 for ; Fri, 06 Jul 2018 08:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uJS3r7FLuw1JZUow3D2F3BH6acdXKs+ii2SoKfvgrC0=; b=ibilgP2btIjAsBB6YJMbzt3FDC1pMMQkTHcdcjZvB7VEXBTmk1i3Q75r/xGcqCi6y8 TsxrmGO1m2tAh6ZMv4G/RBJFLEL/uSTMZYzxSmcA6Hsgw90MRUM2o/qe6mlD2TXyMFWa vUu5NQojXbfibiLUPaXiuVx+S84QZUTOqVnXoIO0MOe2PHlwhWVlfo8xPm9I5IX3cyyy Y7c4x9ZcTaYaqMmuZC4kgq4QkeUpFz9mT6qtKu7tFUxDjTbRL2B0NtJBRyCf8FvI0R5X DzkCfLKjIk9HOSeFVY+J/FjYI6fwIAZrOClJETkUxYDXcr90as0ZS05R5B1yKjXlJBco Xwlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uJS3r7FLuw1JZUow3D2F3BH6acdXKs+ii2SoKfvgrC0=; b=lVEt+ov+Hde0CDQDOPecxD6WoODFShruea3rP1eLrluhFUVLw4sn94eH5d/rL7s+C+ Rf7KqdelzsxkSRXu69FwdwkIZBqRTLuVCspLzV+4/pqN6xQ8GLx43xLvFtNFwghoIDrm W2lT+gfxHX/uQU6Y0Ncc+OFOGRItYJYT58hSsJIzR8Cx5qXq20YGw+8QG+D0Mc2dEpl4 G+EdbjFkELqejWXEKBcm/1Zm0ph4SZKrZO3LrICziXLulLnsxAjPMr23wAHJVbZMb10a yjE2ju8hrdqLosMmff/FPESG2bOMCrrTAtUl8sIalr5z7z/+v6HagXMy2YyCdQq9p6Ia 0MzQ== X-Gm-Message-State: APt69E0i0szXUF5zApqbgVW0Ti/2siroupZCshGqrfOdOrEQsbj4AVrl 3+nmrPJ8Jld9BoOSracplr75Pw== X-Google-Smtp-Source: AAOMgpfi4LSXGbnmU9KbslzLGTrTJoQ/Z5SpKdyXSaRtl1Qgv5N9ajrUTlRKjndURH+xmxXlwVqfTw== X-Received: by 2002:ae9:ed8f:: with SMTP id c137-v6mr9006053qkg.276.1530892163497; Fri, 06 Jul 2018 08:49:23 -0700 (PDT) Received: from [10.30.20.14] (pool-96-241-84-161.washdc.fios.verizon.net. [96.241.84.161]) by smtp.gmail.com with ESMTPSA id j128-v6sm5600383qkc.50.2018.07.06.08.49.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 08:49:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: "R. Atkinson" In-Reply-To: <96928ad2-953c-20f0-a6b1-4c809caf6d88@gont.com.ar> Date: Fri, 6 Jul 2018 11:49:22 -0400 Cc: opsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <533B0D96-D9BE-4A10-A66D-71BC706E1250@gmail.com> <96928ad2-953c-20f0-a6b1-4c809caf6d88@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [OPSEC] draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 15:49:27 -0000 > On Jul 6, 2018, at 10:41, Fernando Gont wrote: >=20 > Hello, Ran, >=20 > I realize that you had sent feedback on this topic before, but for sme > reason I had missed it -- my apologies for that! >=20 > Please find my comments in-line.... >=20 > On 07/06/2018 03:43 PM, R. Atkinson wrote: >> Fernando, >>=20 >> Regarding this draft, I have some feedback with respect to CALIPSO >> (in part because I am one of the co-authors of RFC-5570, which = specifies >> CALIPSO). >>=20 >> 1. Section 4.3.9 makes an incorrect assumption. >>=20 >> Contrary to 4.3.9.5, an intermediate system (e.g., IP router) has no = method >> to learn or know whether or not it is deployed in an MLS-enabled = environment. >>=20 >> An MLS-enabled IPv6 environment might well be using globally = routable >> addresses, so the routing prefixes in use are not informative about = the >> deployment type. >>=20 >> Further, the majority of routers in an MLS-enabled environment are = ordinary >> commercial off-the-shelf IP routers from the usual IP router = vendors. Some >> routers and firewalls in such environments might have = MLS-enhancements,=20 >> but many more will NOT have MLS-enhancements. This is partly = because >> the MLS-enabled label enforcement only is needed at enclave = boundaries. >>=20 >> Explicit configuration is the only method via which a particular = deployed >> intermediate system can learn whether or not it is in an MLS-enabled >> network environment. This is sad, but also is reality. >=20 > Question: would you argue that this would warrant forwarding them at > transit routers? >=20 > (I ask because while the answer to this question would most likely be > "yes" if within a domain, I bet at a transit router it would be better > to drop the MLS traffic to avoid leaks?) -- please see the = applicability > statement in Section 2.2. Hmm. Good question. At least in principle, there might be MLS-enabled network environments with more than one AS in use. I do not have data on whether those = actually exist today or not. Separately, how does a given deployed IP router learn/know that it is a transit router ? =20 Merely running BGP does not imply that it is a transit router. Merely not running BGP does not imply that it is not a transit router. (It could be a transit router in an MPLS-centric BGP-free-core = backbone.) For clarity, might the Title of the I-D be changed to something like = this: Recommendations on the Filtering of IPv6 Packets=20 Containing IPv6 Extension Headers at Transit Routers >=20 >=20 >>=20 >> SUGGESTED ADDITIONAL TEXT for 4.3.9.1: >>=20 >> "Explicit configuration is the only method via which a particular = deployed >> intermediate system can learn whether or not it is in an MLS-enabled >> network environment." >=20 > We will incorporate this. Thanks for suggesting text! Thanks. >> 2. As a result, the advice in 4.3.9.5 is not good or correct. = Incorrect assumption >> above leads to an incorrect conclusion about advice on option = handling. >>=20 >> My suggestion is to revise the advice in 4.3.9.5. >>=20 >> PROPOSED REPLACEMENT TEXT for 4.3.9.5: >>=20 >> =E2=80=9CIntermediate systems that do not implement RFC-5570 SHOULD = have=20 >> a configuration option to EITHER (a) drop packets containing the=20 >> CALIPSO option OR (b) to ignore the presence of the CALIPSO option >> and forward the packets normally.=E2=80=9D >=20 > A couple of questions here: > * What would you argue that de default value of this knob should be? I do not really care either way about the default value, provided that = there is a knob. > * In any case, I'd somehow rephrase the advice, since it implies a > requirement for a CALIPSO-specific knob --while we don't require any > option-specific knob for any other option. A. Well, this partly goes back to my question towards the top: How does a particular router figure out whether it is a transit = router ? I=E2=80=99ve built IP routers at more than one company, and did = Cisco=E2=80=99s initial IPv6 router implementation. If there are no knobs in the router/IS = configuration, then how does the router know whether to apply the advice here = (because it IS a transit router) or NOT to apply the advice here (because it is = NOT a transit router). B. For the other part, please let me observe that at the top of Page 5, = the=20 current draft=E2=80=99s text reads in part: "We recommend that configuration options are made available to = govern the processing of each IPv6 EH type and each IPv6 option type. = Such configuration options may include the following possible settings: = [=E2=80=A6] " The text I proposed for 4.3.9.5 to me seems __very consistent__ with = the=20 __existing__ text at the top of page 5 =E2=80=94 since that text says = that configuration knobs are recommended and outlines 2 of the 3 configuration choices=20 that I propose to document. My proposed text used =E2=80=9CSHOULD=E2=80= =9D which is=20 consistent with the word =E2=80=9Crecommend=E2=80=9D at the top of = page 5. =20 Also, =E2=80=9CSHOULD=E2=80=9D is different from =E2=80=9CMUST=E2=80=9D.= To my mind, the word =E2=80=9Crequire=E2=80=9D is different from =E2=80=9Crecommend=E2=80=9D and =E2=80=9Crequire=E2=80= =9D would map to =E2=80=9CMUST=E2=80=9D rather than to =E2=80=9CSHOULD=E2=80=9D. =20 In practice, most (all ?) of us realize that any guidance that is = neither =E2=80=9CMUST=E2=80=9D nor =E2=80=9CMUST NOT=E2=80=9D might or might be followed by a = conforming implementation=20 of an IETF standards-track RFC. My goal is simply to offer the best = advice=20 to a (possibly naive) implementer who is not active in IETF, is not = reading=20 IETF mailing list archives for context, and simply has been told to = =E2=80=9Cimplement=20 RFC-wxyz in our intermediate system because customer A asked for = it=E2=80=9D. There are HUGE numbers of implementers of mainstream commercial products who aren=E2=80=99t active in IETF and simply write code from = the RFC. I do fully understand that (at least for some common implementations) = the presence of a Hop-by-Hop Header can create a (D)DOS attack vector on the control plane (for some common router implementations). Having = the configuration knob (which again, is consistent with existing text at = the top=20 of page 5), allows for the desire/need to drop packets with Hop-by-Hop=20= headers while also allows for the desire/need to ignore those packets (or to process them following the RFC-5570 specification). My apologies for the lengthy answers. Does that answer the question ? Yours, Ran :-) PS: At a former employer, we had packet forwarding silicon that could be configured either to ignore xor to honor any Hop-by-Hop options that appeared in an IPv6 packets. The Verilog to do this was pretty simple. =20= Adding that Verilog did not increase the die size or adversely impact = our=20 layout/place time & costs. As a customer, I=E2=80=99d much rather buy a = router=20 with packet forwarding silicon that had such a knob. Other than on=20 very low speed links (e.g., VSAT SATCOM often are Kbps), I want to buy routers that use silicon to forward packets, not a CPU, and with silicon robust against various kinds of (now all too predictable) (D)DOS attacks. :-) From nobody Fri Jul 6 09:26:11 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772D4130EC2 for ; Fri, 6 Jul 2018 09:26:09 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 2b7KOBjZpzrP for ; Fri, 6 Jul 2018 09:26:05 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E865126CC7 for ; Fri, 6 Jul 2018 09:26:05 -0700 (PDT) Received: from [192.168.88.59] (unknown [77.120.246.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 23C7882E0E; Fri, 6 Jul 2018 18:26:02 +0200 (CEST) To: "R. Atkinson" Cc: opsec@ietf.org References: <533B0D96-D9BE-4A10-A66D-71BC706E1250@gmail.com> <96928ad2-953c-20f0-a6b1-4c809caf6d88@gont.com.ar> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <0050d4b0-7cc3-655a-577b-4ef20c05dd6f@gont.com.ar> Date: Fri, 6 Jul 2018 18:24:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 16:26:10 -0000 On 07/06/2018 05:49 PM, R. Atkinson wrote: > >> On Jul 6, 2018, at 10:41, Fernando Gont wrote: >> >> Hello, Ran, >> >> I realize that you had sent feedback on this topic before, but for sme >> reason I had missed it -- my apologies for that! >> >> Please find my comments in-line.... >> >> On 07/06/2018 03:43 PM, R. Atkinson wrote: >>> Fernando, >>> >>> Regarding this draft, I have some feedback with respect to CALIPSO >>> (in part because I am one of the co-authors of RFC-5570, which specifies >>> CALIPSO). >>> >>> 1. Section 4.3.9 makes an incorrect assumption. >>> >>> Contrary to 4.3.9.5, an intermediate system (e.g., IP router) has no method >>> to learn or know whether or not it is deployed in an MLS-enabled environment. >>> >>> An MLS-enabled IPv6 environment might well be using globally routable >>> addresses, so the routing prefixes in use are not informative about the >>> deployment type. >>> >>> Further, the majority of routers in an MLS-enabled environment are ordinary >>> commercial off-the-shelf IP routers from the usual IP router vendors. Some >>> routers and firewalls in such environments might have MLS-enhancements, >>> but many more will NOT have MLS-enhancements. This is partly because >>> the MLS-enabled label enforcement only is needed at enclave boundaries. >>> >>> Explicit configuration is the only method via which a particular deployed >>> intermediate system can learn whether or not it is in an MLS-enabled >>> network environment. This is sad, but also is reality. >> >> Question: would you argue that this would warrant forwarding them at >> transit routers? >> >> (I ask because while the answer to this question would most likely be >> "yes" if within a domain, I bet at a transit router it would be better >> to drop the MLS traffic to avoid leaks?) -- please see the applicability >> statement in Section 2.2. > > Hmm. Good question. > > At least in principle, there might be MLS-enabled network environments > with more than one AS in use. I do not have data on whether those actually > exist today or not. I guess that in those cases the operator could decide to "pass" those packets? > Separately, how does a given deployed IP router learn/know that it is > a transit router ? > > Merely running BGP does not imply that it is a transit router. > > Merely not running BGP does not imply that it is not a transit router. > (It could be a transit router in an MPLS-centric BGP-free-core backbone.) Agreed. I'm not saying the router would detect the scenario and filter accordingly, but rather that the advice applies in such cases. i.e., the folk reading this doc know that this advice is meant only for such scenarios. > For clarity, might the Title of the I-D be changed to something like this: > > Recommendations on the Filtering of IPv6 Packets > Containing IPv6 Extension Headers at Transit Routers I have no issues myself. Will ask the chairs about it. >>> 2. As a result, the advice in 4.3.9.5 is not good or correct. Incorrect assumption >>> above leads to an incorrect conclusion about advice on option handling. >>> >>> My suggestion is to revise the advice in 4.3.9.5. >>> >>> PROPOSED REPLACEMENT TEXT for 4.3.9.5: >>> >>> “Intermediate systems that do not implement RFC-5570 SHOULD have >>> a configuration option to EITHER (a) drop packets containing the >>> CALIPSO option OR (b) to ignore the presence of the CALIPSO option >>> and forward the packets normally.” >> >> A couple of questions here: >> * What would you argue that de default value of this knob should be? > > I do not really care either way about the default value, provided that there > is a knob. > >> * In any case, I'd somehow rephrase the advice, since it implies a >> requirement for a CALIPSO-specific knob --while we don't require any >> option-specific knob for any other option. > > > A. Well, this partly goes back to my question towards the top: > How does a particular router figure out whether it is a transit router ? > > I’ve built IP routers at more than one company, and did Cisco’s initial IPv6 > router implementation. If there are no knobs in the router/IS configuration, > then how does the router know whether to apply the advice here (because > it IS a transit router) or NOT to apply the advice here (because it is NOT a > transit router). The goal is that the operator will apply the advice depending on where the router is being deployed. > > B. For the other part, please let me observe that at the top of Page 5, the > current draft’s text reads in part: > > "We recommend that configuration options are made available to govern > the processing of each IPv6 EH type and each IPv6 option type. Such > configuration options may include the following possible settings: […] " > > The text I proposed for 4.3.9.5 to me seems __very consistent__ with the > __existing__ text at the top of page 5 — since that text says that configuration > knobs are recommended and outlines 2 of the 3 configuration choices > that I propose to document. My proposed text used “SHOULD” which is > consistent with the word “recommend” at the top of page 5. > Yes, my bad. [....] > > I do fully understand that (at least for some common implementations) the > presence of a Hop-by-Hop Header can create a (D)DOS attack vector on > the control plane (for some common router implementations). Having the > configuration knob (which again, is consistent with existing text at the top > of page 5), allows for the desire/need to drop packets with Hop-by-Hop > headers while also allows for the desire/need to ignore those packets > (or to process them following the RFC-5570 specification). > > My apologies for the lengthy answers. Quite the contrary! -- Thans so much for your elaborate anwers! > Does that answer the question ? It does. :-) (agreed on making the knob available) Regarding the advice, I'm wondering what would be the recommended advice for transit routers. I guess it would be "drop, unless it's a MLS network", with the operator applying this configuration (and hence knowing what's the context in which this device s operating) Thoughts? > :-) > PS: At a former employer, we had packet forwarding silicon that could > be configured either to ignore xor to honor any Hop-by-Hop options that > appeared in an IPv6 packets. The Verilog to do this was pretty simple. > Adding that Verilog did not increase the die size or adversely impact our > layout/place time & costs. As a customer, I’d much rather buy a router > with packet forwarding silicon that had such a knob. Other than on > very low speed links (e.g., VSAT SATCOM often are Kbps), I want > to buy routers that use silicon to forward packets, not a CPU, and > with silicon robust against various kinds of (now all too predictable) > (D)DOS attacks. :-) > Agreed :-) Thanks a lot! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Jul 6 10:57:09 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D0C129C6A for ; Fri, 6 Jul 2018 10:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ru4j1gr2rTsH for ; Fri, 6 Jul 2018 10:57:05 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6377130E18 for ; Fri, 6 Jul 2018 10:57:05 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id a132-v6so6745985qkg.3 for ; Fri, 06 Jul 2018 10:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o/09qCjdC5DN4YCOxoITNij7bL8WyGe8tSt5quT20gc=; b=kuRzo4e4OZJA96ypX7RHFZYcnGkUqIc9PBkB1wlwGCpyiqYU+vYXRXFiRR8BtK0LjO R0rhd5RqOldvczDls6B6e3g5Jmv1TAbD82eVMLhu7LTIdKzdxg3nGyNc+SjMelS0+Kw3 tIydCGOb1cQU2qBLxlAVca2JwS6OnJmp5QXO6w5DxjGHKnMB/MiMcY0F/7ltEvovPwTK z6Uh9dCGFssGKZzpvE6issYegy3G4m9CI82L471pSoBoue7aw7EJvCOpZFf12eqjvOkB R+sGfX0xR6ICGBy58v0apGusqwInDfACLCcz5qo8amByNEuW650C9Io8Xg3Sn1Qg/Rum i0Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o/09qCjdC5DN4YCOxoITNij7bL8WyGe8tSt5quT20gc=; b=ZBCHrVSEefyF9FQmWqxhg8E7CJQAhlLrVPmObVPiFU8uq3I4mSEqTaaAJfEDJDGDxC /kZUKjNI10KsBhG2GDX/KPHWVZPlhDw/FPL5pLzMlKUlnsKDYrhDQjOFvrNH9rrzJmAv bUr0VWzzIm1wwLHT4ln7Ri8c4rL5dFAuZvTyW3Jr/sTDm4RYBdzHw8Rx+uNEh4AoODgy 5k42pRj+9fx0sFqNId43s5xmlYq5sXxLnlMNm4EkZf8kxJKKg2qjl2VkNSxQ6aYo3fiE snSDP5xrePUoB/u7FRCJ0j6xorM9zHTEAwLe9EaXFl1B0OBdxOsGtBfKF0v72ExgBHS+ 3/CQ== X-Gm-Message-State: APt69E1eSfGhP7JyoZNvZSH6whJdi539++77D7wmCi1Wa4rW6yLI4qwY LgTZgmaqlcVHEWtsGT3M7RJovw== X-Google-Smtp-Source: AAOMgpdP77IGeoSbFidCZJsIGnsn7BBRhwJTDdBAU+AWlL63A+ubQI9w1BWeCJd0GK2uCbGoeB/siw== X-Received: by 2002:a37:4f85:: with SMTP id d127-v6mr9646753qkb.183.1530899824832; Fri, 06 Jul 2018 10:57:04 -0700 (PDT) Received: from [10.30.20.14] (pool-96-241-84-161.washdc.fios.verizon.net. [96.241.84.161]) by smtp.gmail.com with ESMTPSA id y131-v6sm5431374qka.30.2018.07.06.10.57.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 10:57:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: "R. Atkinson" In-Reply-To: <0050d4b0-7cc3-655a-577b-4ef20c05dd6f@gont.com.ar> Date: Fri, 6 Jul 2018 13:57:03 -0400 Cc: opsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6AE997AE-8D82-4B45-8425-0A5C24FF5ACA@gmail.com> References: <533B0D96-D9BE-4A10-A66D-71BC706E1250@gmail.com> <96928ad2-953c-20f0-a6b1-4c809caf6d88@gont.com.ar> <0050d4b0-7cc3-655a-577b-4ef20c05dd6f@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [OPSEC] draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 17:57:08 -0000 > On Jul 6, 2018, at 12:24, Fernando Gont wrote: > It does. :-) (agreed on making the knob available) >=20 > Regarding the advice, I'm wondering what would be the recommended = advice > for transit routers. I guess it would be "drop, unless it's a MLS > network", with the operator applying this configuration (and hence > knowing what's the context in which this device s operating) Fernando, I don=E2=80=99t think "transit router true/false=E2=80=9D is the = variable that would determine whether to drop CALIPSO packets or not. Instead, it is =E2=80=9CMLS = enabled=20 true/false=E2=80=9D that would determine whether to drop. I am open to word-smithing/editing, but here is some candidate revised=20= replacement text for 4.3.9.5 based on today=E2=80=99s email: "Recommendations for handling the CALIPSO option depend on the=20 deployment environment, rather than whether an intermediate system=20 happens to be deployed as a transit device (e.g., IPv6 transit = router)." =E2=80=9CExplicit configuration is the only method via which an = intermediate system can know whether or not that particular intermediate system has been=20= deployed within a Multi-Level Secure (MLS) environment. In many = cases,=20 ordinary commercial intermediate systems (e.g., IPv6 routers & = firewalls)=20 are the majority of the deployed intermediate systems inside an MLS=20 network environment. =20 =E2=80=9CFor Intermediate systems that DO NOT implement RFC-5570, there=20= SHOULD be a configuration option to EITHER (a) drop packets containing=20= the CALIPSO option OR (b) to ignore the presence of the CALIPSO = option and forward the packets normally. In non-MLS environments, such intermediate systems SHOULD have this configuration option set to (a) above. In MLS environments, such intermediate systems SHOULD have this option set to (b) above. The default setting for this = configuration option SHOULD be set to (a) above, because MLS environments are much less common than non-MLS environments." =E2=80=9CFor Intermediate systems that DO implement RFC-5570, there = SHOULD=20 be configuration options (a) and (b) from the preceding paragraph and=20= also a third configuration option (c) to process packets containing a CALIPSO option as per RFC-5570. When deployed in non-MLS environments, such intermediate systems SHOULD have this configuration option set to (a) above. When deployed in MLS environments, such intermediate systems SHOULD have this set to (c). The default setting for this configuration option MAY be set to (a) above, because MLS=20 environments are much less common than non-MLS environments." Thanks very much. Yours, Ran From nobody Thu Jul 19 07:03:53 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD1130F4A for ; Thu, 19 Jul 2018 07:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 Ws_kkfRDyq0v for ; Thu, 19 Jul 2018 07:03:46 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4169E130F06 for ; Thu, 19 Jul 2018 07:03:46 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6JDs9nn008394 for ; Thu, 19 Jul 2018 07:03:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=2/pJbCkVsoxFf6GzsVMVhYY/bs+HLihFHMUW5C2GvnM=; b=q9jITA2uNWQZ7+e6pbUercMCASxCs6OTB/MVKLrrmf3R5qRwsJSj2UUUGIwkPs9djFhT 1LaHdUryXWe+LuyCrZnNEd0bK23iwLESMLVC4u6sILgJRSbOTq4B3KX7TZTCE27GyDBw +Opl96edHTVjY6Kg63D2jVncc94IhCsL8PxwDwvwp+q6Gry24amBMcDh4vSrnJJuRIlT 4p2xg1byr5Cbx1antyaykAqmIau2JihhmUxGX8yFIehuS4DuMuxNmMkBb4rQy2luvJqe wOoxbVN19xvGDwpgzHUwT6dSJFdia5v38oaOqJg/XhKoglmci0a/Not/kCamH7o7Gozc Fg== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) by mx0b-00273201.pphosted.com with ESMTP id 2kapb30kfy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 19 Jul 2018 07:03:44 -0700 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB538.namprd05.prod.outlook.com (10.141.73.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.973.14; Thu, 19 Jul 2018 14:03:41 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([fe80::59f:773c:1bca:3f73]) by CO1PR05MB443.namprd05.prod.outlook.com ([fe80::59f:773c:1bca:3f73%13]) with mapi id 15.20.0973.016; Thu, 19 Jul 2018 14:03:40 +0000 From: Ron Bonica To: "opsec@ietf.org" Thread-Topic: New Work Thread-Index: AdQfZuZuZCL8tqw2TLKrKxTi6YS8YA== Date: Thu, 19 Jul 2018 14:03:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1PR05MB538; 6:RD3KK/Nazt1A0DGrEQqrM5TYzjvhIWA4oAzJodf8meB66gxkah+FaK7H2u+GZPdf4OXqTcQiilwhFFnNHQqgprRqVoMOLXD0iqUgjDEcBOCdPoylOFFMip0MdEskXQeYsG/WcKmuB/9YTk5noy1X7W7DpYF9xIg16mv8026E4xDC2E0VZaxKnkWiibS1Fvp3vfh7Zb8VOsFVS3BXGiueeLFNLlXs+Iyq70OcugmCulNERIBK7f21O1Nu+5ynN5PQipA6oRx65M0yLY5fS1Hu94XfdRUU4no4F+/raSPfJ59uVUsNBLP7TbS67Cv8/aNyRcAY1cQxdbCZIeq7hLMRuwJGafE4Cw7OnHxyZvUyBOngB3iStbjeOQ3VmkM+dUrL3AmmXLup386W5xe/sVazxtdwGqqi35Ku3NlMfd2tvgiPlqE+HqDvrRx8Bb4TRRdU3wMjXQ//64hfE6GiOCC5Sg==; 5:TktK5l0ZAWBXgCYU8gG597tr9xCClWb5WgIr36Dzm2CNqYXotU2sLi+/TQOW2W22wBKPu9Wz6lKhg4G6/qK2PyVNfstYuhQq5evKooyziIoOyVUtJEQ25IVeOKxP0CWBlVEX48DeKQlewDTfyqBsAS82gnvBBYfCGqhvg06rUxI=; 7:S/1GWtnl+wM1SmzohWpvH93lD9uzuWQVH2Cyz3e87rwTy3C1OiXcAtY/mDxCfMLxWErQ7bXkNsbQAihjRJjjBAqCAT//wGh2bdhvwHFwnUZ7j2sNNYiI7+IbqnXhnCZQWP5fvzYxnrgSYgt/pkEjy9vqjKdQjsjsNUoHgKqyk91fs83jkAuxjNTnEkA7aiPJBSs1NpT5ZGWXZ9Bes6eLc74iN5KaSVdsiYAHIlEKq1wcanCepUi1kuTNenI74jgI x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 10f74d96-da5e-4dec-cd3b-08d5ed806e74 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:CO1PR05MB538; x-ms-traffictypediagnostic: CO1PR05MB538: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CO1PR05MB538; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB538; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(396003)(346002)(136003)(189003)(199004)(81166006)(476003)(66066001)(2351001)(5640700003)(86362001)(6116002)(6916009)(486006)(5250100002)(26005)(8676002)(1730700003)(74316002)(25786009)(6506007)(33656002)(9686003)(3480700004)(81156014)(14444005)(55016002)(102836004)(305945005)(3846002)(2501003)(14454004)(6436002)(256004)(316002)(7736002)(478600001)(7116003)(5660300001)(186003)(97736004)(53936002)(99286004)(106356001)(105586002)(2906002)(68736007)(7696005)(221733001)(8936002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB538; H:CO1PR05MB443.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9j1m8ac7BD1eCDxE10N9hVZp19vt8PMnqcDnOzlr8wfqnJQmcGV5WxAYGUqL24HxjBDSY5/2eJZ/OsKKd87Ivq/XjJ+FgiihblyjgDRmj2uwV9oa4o8s8WTtCMvztNO24Cm/3EecUyAhM3D+cqndgvrvM3kP+udg6rU80TBIt6/VkP+D2IfMNONKrUHOuBVAqPp5kEuHX8xVniRuSCbj0kJGfDTTFgKqaN+3FMQfBWJF2FtPPrR8mLbuezcX6Kb8/YNhzreP3EgOpk9XAiPq43ZANeEMBOP1Zxf15LjNqQcLHbphItiPEvb8Fbsovi4d710jYmOgOGkwrfIQJiv+4Giq9owBeL6HG4mrev8YXtY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 10f74d96-da5e-4dec-cd3b-08d5ed806e74 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 14:03:40.5975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB538 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=13 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=13 clxscore=1015 lowpriorityscore=0 mlxscore=13 impostorscore=0 mlxlogscore=82 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190149 Archived-At: Subject: [OPSEC] New Work X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:03:48 -0000 Folks, I would like to propose some new work for OPSEC. Would anybody be intereste= d in the following topics? - Update RFC 6192 - Protecting the Router Control Plane Since the publication of 6192, most vendors have upgraded there IPv6 ACL ca= pabilities. In light of this, we might want to revisit RFC 6192 - Expand upon selected topics from draft-ietf-opsec-v6 Draft-ietf-opsec-v6 identifies several ipv6 vulnerabilities (e.g. vulnerabi= lities associated with extension headers). OPSEC might want to scan the dra= ft, looking for vulnerabilities at deserve in depth analysis and mitigation= .=20 - Update RFC 7872 - Observations On Dropping of Packets with IPv6 Extension= Headers RFC 7872 demonstrates that many IPv6 paths drop packets that contain IPv6 = extension headers. Follow on work might update the experimental method so t= hat a) ) it identifies the Autonomous Systems that drop packets, b) it is r= epeated periodically, and c) it publishes its results on a web page. We mig= ht also want to figure out why these autonomous systems are dropping packet= s and address the problems that motivate them to do that. Ron From nobody Thu Jul 19 07:43:25 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE45130DF5 for ; Thu, 19 Jul 2018 07:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FAz9hboPZSYo for ; Thu, 19 Jul 2018 07:43:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19434130DE3 for ; Thu, 19 Jul 2018 07:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3906; q=dns/txt; s=iport; t=1532011401; x=1533221001; h=from:to:subject:date:message-id:mime-version; bh=G01idL6NHKeuUF9jCF9++kywwbkum4XMISEXrLL5rF0=; b=TOeeCyrgwLif7/p7b9C726FPNie37W7V7VgTScio/u8nM1hayjD7Ef7y f2Na/uCWBR4D9dXJcCkSBXmAJ7ztCJhDccxFGuRXAztdWGSdS7buS8p62 ndF/LSHh9yRbNdoGxdEp3wN/IfkIAKsl5Ja7smtSwoiqlDDMEkuNcAFqY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHBACLolBb/4UNJK1cGwEBAQEDAQE?= =?us-ascii?q?BCQEBAYJXdmN/MoN0iASMK4VxjEaFEIF6CyOEYoJuITQYAQIBAQIBAQJtHAE?= =?us-ascii?q?LhWBoAQw+AgQwJwSDMwGBG2QPqT6BLoRdhWgFiQKBVz+BOIYDAgOEXjGCJAK?= =?us-ascii?q?ZaAkCgT6ETYkfgUSEEogWij+HNwIRFIEkHTiBUnAVZQGCP4sUhT6LQ4EaAQE?= X-IronPort-AV: E=Sophos;i="5.51,374,1526342400"; d="scan'208,217";a="429288152" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2018 14:43:20 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w6JEhJut001681 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 19 Jul 2018 14:43:20 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 19 Jul 2018 10:43:19 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 19 Jul 2018 10:43:19 -0400 From: "Eric Vyncke (evyncke)" To: "opsec@ietf.org" Thread-Topic: Agenda for OPSEC WG meeting + jabber scribe + minutes taker Thread-Index: AQHUH27VO+vxc3r60ESviEDnDYEP3g== Date: Thu, 19 Jul 2018 14:43:19 +0000 Message-ID: <58DF409D-D6F5-46CA-ABF4-74B2E287DD48@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.181.110] Content-Type: multipart/alternative; boundary="_000_58DF409DD6F546CAABF474B2E287DD48ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: [OPSEC] Agenda for OPSEC WG meeting + jabber scribe + minutes taker X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:43:23 -0000 --_000_58DF409DD6F546CAABF474B2E287DD48ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGFnZW5kYSBoYXMgYmVlbiBzbGlnaHRseSB1cGRhdGVkLCBhIGZyZXNoIGNvcHkgaXMgYXZh aWxhYmxlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMi9tYXRlcmlh bHMvYWdlbmRhLTEwMi1vcHNlYy0wNA0KDQpJcyB0aGVyZSBhbnkgdm9sdW50ZWVyIGZvciBqYWJi ZXIgc2NyaWJlIG9yIG1pbnV0ZXMgdGFrZXI/IFBsZWFzZSBzdGVwIGZvcndhcmQgOi0pDQoNClNl ZSB5b3UgdG9tb3Jyb3cNCg0KLcOpcmljIC1yb24NCg== --_000_58DF409DD6F546CAABF474B2E287DD48ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <845955F0A1EBE24CB3A57FF44ADF533F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+VGhlIGFnZW5kYSBoYXMgYmVlbiBzbGlnaHRseSB1cGRhdGVkLCBh IGZyZXNoIGNvcHkgaXMgYXZhaWxhYmxlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAyL21hdGVyaWFscy9hZ2VuZGEtMTAy LW9wc2VjLTA0Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAyL21hdGVy aWFscy9hZ2VuZGEtMTAyLW9wc2VjLTA0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SXMgdGhlcmUgYW55IHZvbHVudGVlciBmb3IgamFiYmVyIHNjcmliZSBv ciBtaW51dGVzIHRha2VyPyBQbGVhc2Ugc3RlcCBmb3J3YXJkIDotKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VlIHlvdSB0b21vcnJvdzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LcOpcmljIC1yb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_58DF409DD6F546CAABF474B2E287DD48ciscocom_-- From nobody Thu Jul 19 09:14:57 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BCF130ECF for ; Thu, 19 Jul 2018 09:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shortestpathfirst.net 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 VPEPlpyjinLP for ; Thu, 19 Jul 2018 09:14:52 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4395A130E84 for ; Thu, 19 Jul 2018 09:14:45 -0700 (PDT) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id E6A5D1E0B17 for ; Thu, 19 Jul 2018 10:14:44 -0600 (MDT) Received: from box340.bluehost.com ([69.89.31.140]) by cmsmtp with ESMTP id gBZkfyVM3vdTugBZkfKy3i; Thu, 19 Jul 2018 10:14:44 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shortestpathfirst.net; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JOkifloUapEN1F/hoNX86sFT70wS2GO8Jfog/Ttc/7U=; b=gtA08bJvlZNV7Ljpwlpbx79Ir Xgwfx2/zg8lm1rOhq1lJyZizjOyh+SQdZYAmwgmvzHaikfAx/ZnoHpshDaCbiv/6tOzsHGk5gYkuZ GhBCSXmm3WzSk2AKuzPnrMLNOz; Received: from mobile-166-170-28-210.mycingular.net ([166.170.28.210]:13629 helo=[172.20.10.6]) by box340.bluehost.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.91) (envelope-from ) id 1fgBZk-001Ap7-1t; Thu, 19 Jul 2018 10:14:44 -0600 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: ShortestPathFirst In-Reply-To: Date: Thu, 19 Jul 2018 12:14:36 -0400 Cc: "opsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ron Bonica X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box340.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shortestpathfirst.net X-BWhitelist: no X-Source-IP: 166.170.28.210 X-Source-L: No X-Exim-ID: 1fgBZk-001Ap7-1t X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: mobile-166-170-28-210.mycingular.net ([172.20.10.6]) [166.170.28.210]:13629 X-Source-Auth: sfouant@shortestpathfirst.net X-Email-Count: 1 X-Source-Cap: c2hvcnRlczE7c2hvcnRlczE7Ym94MzQwLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [OPSEC] New Work X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 16:14:55 -0000 Hi Ron, I=E2=80=99d be interested in updating RFC 6192. Doesn=E2=80=99t seem = like it would be too involved and could probably be knocked out pretty = quickly. Stefan > On Jul 19, 2018, at 10:03 AM, Ron Bonica wrote: >=20 > Folks, >=20 > I would like to propose some new work for OPSEC. Would anybody be = interested in the following topics? >=20 > - Update RFC 6192 - Protecting the Router Control Plane >=20 > Since the publication of 6192, most vendors have upgraded there IPv6 = ACL capabilities. In light of this, we might want to revisit RFC 6192 >=20 > - Expand upon selected topics from draft-ietf-opsec-v6 >=20 > Draft-ietf-opsec-v6 identifies several ipv6 vulnerabilities (e.g. = vulnerabilities associated with extension headers). OPSEC might want to = scan the draft, looking for vulnerabilities at deserve in depth analysis = and mitigation.=20 >=20 > - Update RFC 7872 - Observations On Dropping of Packets with IPv6 = Extension Headers >=20 > RFC 7872 demonstrates that many IPv6 paths drop packets that contain = IPv6 extension headers. Follow on work might update the experimental = method so that a) ) it identifies the Autonomous Systems that drop = packets, b) it is repeated periodically, and c) it publishes its results = on a web page. We might also want to figure out why these autonomous = systems are dropping packets and address the problems that motivate them = to do that. >=20 > = Ron >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From nobody Sun Jul 22 02:45:48 2018 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC17E130E8D for ; Sun, 22 Jul 2018 02:45:46 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 mOk8ISKvVI5A for ; Sun, 22 Jul 2018 02:45:45 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BC1130E83 for ; Sun, 22 Jul 2018 02:45:44 -0700 (PDT) Received: from [192.168.0.158] (unknown [91.197.16.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0B67B82CBC; Sun, 22 Jul 2018 11:45:43 +0200 (CEST) To: "R. Atkinson" Cc: opsec@ietf.org References: <533B0D96-D9BE-4A10-A66D-71BC706E1250@gmail.com> <96928ad2-953c-20f0-a6b1-4c809caf6d88@gont.com.ar> <0050d4b0-7cc3-655a-577b-4ef20c05dd6f@gont.com.ar> <6AE997AE-8D82-4B45-8425-0A5C24FF5ACA@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <72a2fca5-2d64-832e-e5e9-c0d86ab1ee86@gont.com.ar> Date: Sun, 22 Jul 2018 11:45:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6AE997AE-8D82-4B45-8425-0A5C24FF5ACA@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 09:45:47 -0000 Hello, Ran, Apologies for the delay in my response... On 07/06/2018 07:57 PM, R. Atkinson wrote: > > >> On Jul 6, 2018, at 12:24, Fernando Gont wrote: >> It does. :-) (agreed on making the knob available) >> >> Regarding the advice, I'm wondering what would be the recommended advice >> for transit routers. I guess it would be "drop, unless it's a MLS >> network", with the operator applying this configuration (and hence >> knowing what's the context in which this device s operating) > > Fernando, > > I don’t think "transit router true/false” is the variable that would determine > whether to drop CALIPSO packets or not. Instead, it is “MLS enabled > true/false” that would determine whether to drop. Point taken. (A side question, for my own personal interest: If you have an MLS environment, wouldn't it be your bet that transit drops your packets -- i.e., they are *transit*) > I am open to word-smithing/editing, but here is some candidate revised > replacement text for 4.3.9.5 based on today’s email: > > "Recommendations for handling the CALIPSO option depend on the > deployment environment, rather than whether an intermediate system > happens to be deployed as a transit device (e.g., IPv6 transit router)." > > “Explicit configuration is the only method via which an intermediate system > can know whether or not that particular intermediate system has been > deployed within a Multi-Level Secure (MLS) environment. In many cases, > ordinary commercial intermediate systems (e.g., IPv6 routers & firewalls) > are the majority of the deployed intermediate systems inside an MLS > network environment. > > “For Intermediate systems that DO NOT implement RFC-5570, there > SHOULD be a configuration option to EITHER (a) drop packets containing > the CALIPSO option OR (b) to ignore the presence of the CALIPSO option > and forward the packets normally. In non-MLS environments, such > intermediate systems SHOULD have this configuration option set to (a) > above. In MLS environments, such intermediate systems SHOULD > have this option set to (b) above. The default setting for this configuration > option SHOULD be set to (a) above, because MLS environments are much > less common than non-MLS environments." > > “For Intermediate systems that DO implement RFC-5570, there SHOULD > be configuration options (a) and (b) from the preceding paragraph and > also a third configuration option (c) to process packets containing > a CALIPSO option as per RFC-5570. When deployed in non-MLS > environments, such intermediate systems SHOULD have this configuration > option set to (a) above. When deployed in MLS environments, such > intermediate systems SHOULD have this set to (c). The default setting > for this configuration option MAY be set to (a) above, because MLS > environments are much less common than non-MLS environments." The text looks great, and I will incorporate it in the next rev- If any folks have any objections please do let us know. Thanks so much, Ran! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1