From nobody Tue Jul 1 13:13:54 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2841B28A6; Tue, 1 Jul 2014 13:13:44 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzL4SUAhYiPG; Tue, 1 Jul 2014 13:13:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ED11B28B4; Tue, 1 Jul 2014 13:13:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701201338.11177.1545.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 13:13:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/P4-3WUBROvAlp3SwDcHa6OOSLRg Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-04.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 20:13:45 -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 Working Group of the IETF. Title : DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers Authors : Fernando Gont Will Liu Gunter Van de Velde Filename : draft-ietf-opsec-dhcpv6-shield-04.txt Pages : 9 Date : 2014-07-01 Abstract: This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-04 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 Thu Jul 10 08:49:16 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266351A043D; Thu, 10 Jul 2014 08:49:13 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d--0WFP7ewX5; Thu, 10 Jul 2014 08:49:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 190821A0ABB; Thu, 10 Jul 2014 08:48:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140710154851.16234.30741.idtracker@ietfa.amsl.com> Date: Thu, 10 Jul 2014 08:48:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/JUPKLY8mOz1_oxobS_VSM9rZxOg Cc: opsec mailing list , opsec chair , RFC Editor Subject: [OPSEC] Document Action: 'Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- stack hosts/networks' to Informational RFC (draft-ietf-opsec-vpn-leakages-06.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:49:13 -0000 The IESG has approved the following document: - 'Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- stack hosts/networks' (draft-ietf-opsec-vpn-leakages-06.txt) as Informational RFC This document is the product of the Operational Security Capabilities for IP Network Infrastructure Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ Technical Summary Due to the lack of proper IPv6 support in some popular Virtual Private Network (VPN) products, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear from the local network to the final destination. This document discusses some scenarios in which such leakages may occur and discusses possible mitigations. Working Group Summary There was no drama in the WG regarding this draft. The document is well written and easy to understand. There was good support in the WG for progressing this document. Merike Kaeo in particular provided good review and comments. There was decent feedback that resulted in changes during IETF LC. Document Quality The document is well written and easy to understand. There was good support in the WG for progressing this document. Merike Kaeo in particular provided good review and comments. Personnel Warren Kumari is the Document Shepherd. Joel Jaeggli is Responsible AD. RFC Editor Note Note, please add the IESG note. IESG Note This document describes a problem of information leakage in VPN software and attributes that problem to the software's inability to deal with IPv6. We do not think this is an appropriate characterization of the problem. It is true that when a device supports more than one address family, the inability to apply policy to more than one address family on that device is a defect. Despite that, inadvertent or maliciously- induced information leakage may also occur due to the existence of any unencrypted interface allowed on the system, including the configuration of split tunnels in the VPN software itself. While there are some attacks that are unique to an IPv6 interface, the sort of information leakage described by this document is a general problem that is not unique to the situation of IPv6-unaware VPN software. We do not think this document sufficiently describes the general issue. From nobody Sun Jul 13 14:52:45 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5251B1A0183 for ; Sun, 13 Jul 2014 14:52:43 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4YH4AfqtUNh for ; Sun, 13 Jul 2014 14:52:42 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4EB1A0180 for ; Sun, 13 Jul 2014 14:52:41 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hu12so731012vcb.28 for ; Sun, 13 Jul 2014 14:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=87N1DeZ5QlHEeOK4taOlN09a0/HhO60/pccNBAXiVIo=; b=0ABgDCndqcyKfv7tfzkDQEnw8nA9Kc1U75Uwfky83A/g80YeEdJ0x39lJM8PjhOcwY e9jDZmpi/tu6uyR/Ho+BRwBqfuUvizn7P5LTwIvuz5ECZLUvevQrw5u0YXsrOpoklTvW jah4QYMeQ7lgBNIPMzzisIvV1GV8fXpOU4KfmEvcDdWqCSMBmpUj4w30AtVCCL5WjZZb YH6EuiwIZ2Sdv4hIYosC2G3GX8H+Hko3T9tB8zIQsTz+AVaUYu4Wq3c0DazgJUNwWzcV uZEKHKJ7fqoorQY1skcXys6PN0eRGe6Xm+pYIbM6LsTNBx0lZGSVgrdCcuz1FWYvtPAh emHQ== X-Received: by 10.52.117.209 with SMTP id kg17mr2456308vdb.28.1405288359051; Sun, 13 Jul 2014 14:52:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.1.83 with HTTP; Sun, 13 Jul 2014 14:52:18 -0700 (PDT) From: KK Chittimaneni Date: Sun, 13 Jul 2014 14:52:18 -0700 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=bcaec547cbcb72c68904fe1a3173 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/0rmRqp5gH3FmQHvVRjVu_IgOtVo Cc: opsec chairs Subject: [OPSEC] OPSEC IETF 90 - Call for Agenda Items X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 21:52:43 -0000 --bcaec547cbcb72c68904fe1a3173 Content-Type: text/plain; charset=UTF-8 Dear All, If you have a draft you would like to discuss during IETF 90, please send your request for agenda time to the opsec chairs. Please include in the request, the title and file name of the draft, the speaker's name, and how much time you would need. We have one hour allocated to our session. We will prioritize drafts that are WG items, drafts that have been actively discussed on the list, and other individual submissions in that order. Regards, KK, Gunter --bcaec547cbcb72c68904fe1a3173 Content-Type: text/html; charset=UTF-8

Dear All,


If you have a draft you would like to discuss during IETF 90, please send your request for agenda time to the opsec chairs. Please include in the request, the title and file name of the draft, the speaker's name, and how much time you would need. We have one hour allocated to our session.


We will prioritize drafts that are WG items, drafts that have been actively discussed on the list, and other individual submissions in that order.


Regards,

KK, Gunter
--bcaec547cbcb72c68904fe1a3173-- From nobody Sun Jul 13 21:30:04 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138511A02ED; Sun, 13 Jul 2014 21:30:01 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvZ2U9StOnDc; Sun, 13 Jul 2014 21:29:59 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544221A02EC; Sun, 13 Jul 2014 21:29:59 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id fp1so1178830pdb.19 for ; Sun, 13 Jul 2014 21:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+cd6+vjRdCcmam3O6LwKu3YbsMT5+KeHLiTcovA8ORk=; b=RcDSXseeW0+m6488i9YAYp3uhRKjpAFF76jdJYpDbPDicT/PpPKcQtXEUbI3ZhXNlf JU+JAQXyIeecGGEd0cu08R/gJPmRRa6cW+sZ+uLN5GKMnu29PEnI6GT7cQJLmo+cF1yY LYupq/hZSWIfs98Ad7wFr70Eh4N5eEVR9WbE6UwkKLNVeDoQLs6YsmHvYrmvpMQ19RMq Rk5o8FX/FaUHtK9d+R76/JsBh00l+S0uY9SSG77M8gQMGAMXuog1vsH3MxRxqRyEI1q2 g2sLMq3QRZXQ5BBf8Cn8rZ0K9Sz18qPzyrTn6eq46aoKvrSOUdAYCuETd6VwekcAUQZG fZQw== X-Received: by 10.68.68.131 with SMTP id w3mr14523726pbt.90.1405312198852; Sun, 13 Jul 2014 21:29:58 -0700 (PDT) Received: from [192.168.178.23] (232.198.69.111.dynamic.snap.net.nz. [111.69.198.232]) by mx.google.com with ESMTPSA id wp3sm9320627pbc.67.2014.07.13.21.29.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jul 2014 21:29:58 -0700 (PDT) Message-ID: <53C35CC4.2070304@gmail.com> Date: Mon, 14 Jul 2014 16:29:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> In-Reply-To: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/YdCELZZNNHENjVlWVMF-7e8q34Q Cc: opsec@ietf.org, IPv6 Operations Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 04:30:01 -0000 Hi, (Excuse cross posting but I'm sure v6ops folk will have an opinion, and I'm not on opsec.) Thanks for starting this work. First, a general point. I think you need to be much clearer in the Introduction that there are rules in RFC 7045 that need to be followed. The advice that you give later is all conditional on those rules being applied first. In particular, 7045 has this requirement: > If a forwarding node discards a packet containing a standard IPv6 > extension header, it MUST be the result of a configurable policy and > not just the result of a failure to recognise such a header. This > means that the discard policy for each standard type of extension > header MUST be individually configurable. The default configuration > SHOULD allow all standard extension headers. There is also a reminder in the Security Considerations that this requirement applies to firewalls. You need to be explicit, perhaps, that you are advising operational configurations, not changing the implementation defaults required by RFC 7045. It was out of scope for 7045, but IMHO we should have the same rule for IPv6 options: provide a configuration switch (allow/drop) for each one, and a reasonable default. You could certainly suggest that. I won't comment in detail on the options - at a quick glance, your suggested defaults seems about right. Now some more specific comments on the extension headers: > 2.3.1.1. Uses > > > The Hop-by-Hop Options header is used to carry optional information > that must be examined by every node along a packet's delivery path. In fact, RFC 7145 changes that: > 2.2. Hop-by-Hop Options > > The IPv6 Hop-by-Hop Options header SHOULD be processed by > intermediate forwarding nodes as described in [RFC2460]. However, it > is to be expected that high-performance routers will either ignore it > or assign packets containing it to a slow processing path. You could s/must/should/. More important: > 2.3.1.5. Advice > > > Intermediate systems should, by default, drop packets containing a > IPv6 Hop-by-Hop Option Extension Header. You can't say that! Firstly, RFC 7045 makes it permissible to simply ignore them. That's the simplest DoS defence. Secondly, well, dropping them is the wrong default because it breaks stuff. You could discuss whether to inspect them for valid contents, and you could discuss rate-limiting, which I understand some vendors support already. > 2.3.2. Routing Header for IPv6 (Number=43) ... > 2.3.2.5. Advice > > > Drop packets containing a RHT0. In fact there is considerably more detailed guidance already in RFC 7045 (last paragraph of section 2.1). I think you should send the reader to that. > 2.3.9. Shim6 Protocol (Number=140) ... > 2.3.9.3. Specific Security Implications > > > TBD. You could mention that shim6 uses CGA or HBA cryptographic addresses to prevent a 3rd party hijacking a session by forging shim6 headers with a bogus address. There is an extensive security discussion in RFC 5533. > 2.3.10. Use for experimentation and testing (Numbers=253 and 254) ... > 2.3.10.5. Advice > > > Routers, security gateways, and firewalls SHOULD have configuration > knobs for IP packets that contain this extension header to select > between "ignore & forward" and "drop & log". Well, you might prefer to put that text at the top, since RFC 7045 requires all headers to have a configuration option. To be precise, 7045 says: > Experimental IPv6 extension headers SHOULD be treated in the same way > as standard extension headers, including an individually configurable > discard policy. However, the default configuration MAY drop > experimental extension headers. Regards Brian From nobody Sun Jul 13 23:55:26 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301E91A0322; Sun, 13 Jul 2014 23:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7Il6VCGye8w; Sun, 13 Jul 2014 23:55:22 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA8D1A0320; Sun, 13 Jul 2014 23:55:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4E3CFA1; Mon, 14 Jul 2014 08:55:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1405320917; bh=AR/Nj4RK1F7IG76UYL0GT0PclUh46mkC7uV2e9+CAr0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Y2Qte1AasdwH2IiGu56bytTrdP8IBY+TcIOIh0iQ6FLYfcEOWoc0H3JTtvjxmRlYm JJTeZ2pdunQqp23V1NtTzcPXEwbC5rXYbfNILTMKChOQMLAFaGE4HB3r7opif10tgS os1QRGDzr4u+oYhFjn3HayqHkFwWv+2szzDHLPDw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 433239F; Mon, 14 Jul 2014 08:55:17 +0200 (CEST) Date: Mon, 14 Jul 2014 08:55:17 +0200 (CEST) From: Mikael Abrahamsson To: draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org In-Reply-To: <53C35CC4.2070304@gmail.com> Message-ID: References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ckX_EQ6UsNBIN-APotCFhTNAraQ Cc: opsec@ietf.org, IPv6 Operations Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 06:55:24 -0000 On Mon, 14 Jul 2014, Brian E Carpenter wrote: > Hi, > > (Excuse cross posting but I'm sure v6ops folk will have an opinion, > and I'm not on opsec.) Yes, at least I do. Thanks for bringing it to v6ops attention. Weird thing, I can't even find the original announcement neither in my opsec nor v6ops folder. Oh, well. Feedback: I find this document advocates dropping things way too much. It uses the term "intermediate" devices. I would like this split up into two types of devices, a "pure packet forwarding device" (=core router), and a "security inspection device" (=device that might have ACLs or being a stateful firewall). I believe a core router which just forwards packets, should not drop packets because of options it can't handle very well. If it can't handle a lot of hop-by-hop header packets, then don't inspect these hop-by-hop header packets, just forward the packets without looking at them. The thought of our core networks limiting what we can and can't do in the future with IPv6, makes me a sad panda. I can understand devices that enforce some kind of security to drop packets they don't understand, but generally recommending blanket dropping of some packets in the core because of potential edge problems, that just doesn't make sense to me. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Jul 15 16:31:11 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432471A0172; Tue, 15 Jul 2014 16:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymm62sjUDFJ6; Tue, 15 Jul 2014 16:30:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 1CA161A0164; Tue, 15 Jul 2014 16:30:53 -0700 (PDT) Received: from r200-40-240-99.su-static.anteldata.net.uy ([200.40.240.99] helo=[10.0.135.233]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7CBL-0008OR-Si; Wed, 16 Jul 2014 01:30:49 +0200 Message-ID: <53C57F39.7080800@gont.com.ar> Date: Tue, 15 Jul 2014 16:21:29 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> In-Reply-To: <53C35CC4.2070304@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/_BrpQ-PpF6h2AHg4-j5JajK9J_Y Cc: opsec@ietf.org, IPv6 Operations Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 23:30:56 -0000 Hi, Brian, Thanks so much for your feedback! Please find my comments in-line... On 07/14/2014 01:29 AM, Brian E Carpenter wrote: > > Thanks for starting this work. > > First, a general point. I think you need to be much clearer in the > Introduction that there are rules in RFC 7045 that need to be followed. > The advice that you give later is all conditional on those rules being > applied first. In particular, 7045 has this requirement: > >> If a forwarding node discards a packet containing a standard IPv6 >> extension header, it MUST be the result of a configurable policy and >> not just the result of a failure to recognise such a header. This >> means that the discard policy for each standard type of extension >> header MUST be individually configurable. We will try to make this explicit -- but yes, we were assuming this (the filtering rules not being the result of failure to recognise a header, etc.). > The default configuration > SHOULD allow all standard extension headers. > > There is also a reminder in the Security Considerations that this > requirement applies to firewalls. You need to be explicit, perhaps, > that you are advising operational configurations, not changing the > implementation defaults required by RFC 7045. Good point. FWIW, we were kind of hesitating between doing an IPv6 version of RFC7123, and writing a document aimed at firewalls. I'd argue that this one is mostly an IPv6 version of RFC7126 -- i.e., much more permisive than what a firewalls document would be. > It was out of scope for 7045, but IMHO we should have the same rule > for IPv6 options: provide a configuration switch (allow/drop) for > each one, and a reasonable default. You could certainly suggest > that. I'd generally agree with you. The only issue is that for some architectures, doing a per-option-type filtering would imply processing the packet on the slow path.... and this requirement might be deemed as honerous. I guess one could say something like "If you support filtering on a per-option-type basis, then such filtering should be configurable on a per-option-type basis", etc.? > Now some more specific comments on the extension headers: > >> 2.3.1.1. Uses >> >> >> The Hop-by-Hop Options header is used to carry optional information >> that must be examined by every node along a packet's delivery path. > > In fact, RFC 7145 changes that: > >> 2.2. Hop-by-Hop Options >> >> The IPv6 Hop-by-Hop Options header SHOULD be processed by >> intermediate forwarding nodes as described in [RFC2460]. However, it >> is to be expected that high-performance routers will either ignore it >> or assign packets containing it to a slow processing path. > > You could s/must/should/. Will do. Thanks! > More important: > >> 2.3.1.5. Advice >> >> Intermediate systems should, by default, drop packets containing a >> IPv6 Hop-by-Hop Option Extension Header. > > You can't say that! Firstly, RFC 7045 makes it permissible to > simply ignore them. While I understand your point (and agree that RFC7045 is authoritative here), (FWIW) this is what RFC7126 says about Router Alert option, which in some sense is analogous to the HBH EH: ---- cut here ---- This option SHOULD be allowed only in controlled environments, where the option can be used safely. [RFC6398] identifies some such environments. In unsafe environments, packets containing this option SHOULD be dropped. A given router, security gateway, or firewall system has no way of knowing a priori whether this option is valid in its operational environment. Therefore, routers, security gateways, and firewalls SHOULD, by default, ignore the Router Alert option. Additionally, routers, security gateways, and firewalls SHOULD have a configuration setting that governs their reaction in the presence of packets containing the Router Alert option. This configuration setting SHOULD allow to honor and process the option, ignore the option, or drop packets containing this option. ---- cut here ---- My question is: do we want to do something different with HBH EH than what we do with Router Alert in IPv4? FWIW, defaulting to "ignore" seems sensible to me. >> 2.3.2. Routing Header for IPv6 (Number=43) > ... >> 2.3.2.5. Advice >> >> >> Drop packets containing a RHT0. > > In fact there is considerably more detailed guidance already > in RFC 7045 (last paragraph of section 2.1). I think you should > send the reader to that. Will do. > >> 2.3.9. Shim6 Protocol (Number=140) > ... >> 2.3.9.3. Specific Security Implications >> >> >> TBD. > > You could mention that shim6 uses CGA or HBA cryptographic > addresses to prevent a 3rd party hijacking a session by > forging shim6 headers with a bogus address. There is an > extensive security discussion in RFC 5533. Thanks for the note! >> 2.3.10. Use for experimentation and testing (Numbers=253 and 254) > ... >> 2.3.10.5. Advice >> >> >> Routers, security gateways, and firewalls SHOULD have configuration >> knobs for IP packets that contain this extension header to select >> between "ignore & forward" and "drop & log". > > Well, you might prefer to put that text at the top, since RFC 7045 requires > all headers to have a configuration option. To be precise, 7045 says: > >> Experimental IPv6 extension headers SHOULD be treated in the same way >> as standard extension headers, including an individually configurable >> discard policy. However, the default configuration MAY drop >> experimental extension headers. Our bad :-( -- will cite RFC7045 as appropriate. Thanks so much! -- 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 Tue Jul 15 17:08:28 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B141B2999; Tue, 15 Jul 2014 17:08:25 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59WzYqPkBZic; Tue, 15 Jul 2014 17:08:23 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE34F1A01D0; Tue, 15 Jul 2014 17:08:23 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so185550pde.23 for ; Tue, 15 Jul 2014 17:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/mHOiE71DLmwXK56st2CE4KNHSYtCYlryBxkJkM6Gmg=; b=FNGKID6Ssvn6oqaOy9ZiVdoYUL2/Ff5ijmoqaUBG/1ascOZiqhphVIm+QWw3eQZ0JS FTrh4y0BziH5yZLYaWs2Hw+QXijkJGHDpGkLF7qSABjjG/oDbznh0zdebJn2d5x3bFvH 73TwLxUA5xjfe9uRjryr7nf6SxdrSBsGQR3+HcTuiblLHIzRUdfIm9MCrwFvh4y4Xb5W +/tAbPmk+elMXUA+hy/r0Nive7TRQXsz0QAwaKkJMj1zqQO3zxnzBY1Y6gD4jfV90oNC nenj8Y+frdiZHczQ2c7tH9hZcIDTvz1hC+rzuX88MfzjblkoAqL3Ty2uJLNAa2Qd3/rH o85g== X-Received: by 10.70.38.1 with SMTP id c1mr17390369pdk.108.1405469303163; Tue, 15 Jul 2014 17:08:23 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id fv12sm20245109pdb.25.2014.07.15.17.08.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 17:08:22 -0700 (PDT) Message-ID: <53C5C279.2090600@gmail.com> Date: Wed, 16 Jul 2014 12:08:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> In-Reply-To: <53C57F39.7080800@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Oxc96SqmeQfAgXRhg4D4pPqJcpQ Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:08:25 -0000 Thanks Fernando, so to focus on your question: > My question is: do we want to do something different with HBH EH than > what we do with Router Alert in IPv4? The problem with both of these great inventions is that a single box on the path that takes the "drop" option breaks everything, whereas "ignore" at least provides best effort service and protects against any specific attack on the middlebox. As far as the destination host goes, HbH can't be any more dangerous than a destination option. I personally don't care much in the IPv4 case, since router alert seems to be a dead duck anyway. It's possible that's going to be the case for HbH, but I think we should give it a chance. > FWIW, defaulting to "ignore" seems sensible to me. I agree, obviously. Regards Brian From nobody Tue Jul 15 17:37:12 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED7E1B27B0; Tue, 15 Jul 2014 17:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkJ-UdbSt1La; Tue, 15 Jul 2014 17:37:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99611B27AA; Tue, 15 Jul 2014 17:37:07 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6G0ai8a015004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 17:36:44 -0700 (PDT) Message-ID: <53C5C91C.2020203@isi.edu> Date: Tue, 15 Jul 2014 17:36:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , Fernando Gont References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> In-Reply-To: <53C5C279.2090600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Mece41mIEePTvI4k7VvwfUMf0v8 Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:37:09 -0000 On 7/15/2014 5:08 PM, Brian E Carpenter wrote: > The problem with both of these great inventions is that a single > box on the path that takes the "drop" option breaks everything, > whereas "ignore" at least provides best effort service and > protects against any specific attack on the middlebox. > As far as the destination host goes, HbH can't be any more > dangerous than a destination option. IPv6 already indicates - inside the option type - what to do if an option isn't supported. Why is honoring that set of flags not the only correct behavior? Joe From nobody Tue Jul 15 17:53:18 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED83A1B27BB; Tue, 15 Jul 2014 17:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5ukmzEFGgV6; Tue, 15 Jul 2014 17:53:13 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 6CFC61B27AB; Tue, 15 Jul 2014 17:53:13 -0700 (PDT) Received: from r200-40-240-99.su-static.anteldata.net.uy ([200.40.240.99] helo=[10.0.135.233]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7DT4-0000Da-FL; Wed, 16 Jul 2014 02:53:10 +0200 Message-ID: <53C5C911.8080905@si6networks.com> Date: Tue, 15 Jul 2014 21:36:33 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , Fernando Gont References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> In-Reply-To: <53C5C279.2090600@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/BfdYRWzRVtxnXhO4VQcIBgweBao Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:53:16 -0000 On 07/15/2014 09:08 PM, Brian E Carpenter wrote: > Thanks Fernando, so to focus on your question: > >> My question is: do we want to do something different with HBH EH than >> what we do with Router Alert in IPv4? > > The problem with both of these great inventions is that a single > box on the path that takes the "drop" option breaks everything, > whereas "ignore" at least provides best effort service and > protects against any specific attack on the middlebox. As noted, I think this options is a sensible one. That said, let me provide a "heads up" on the current state of affairs with respect to IPv6 EHs: +--------------+-----------------+-----------------+----------------+ | Dataset | DO8 | HBH8 | FH512 | +--------------+-----------------+-----------------+----------------+ | Web | 11.88% | 40.70% | 30.51% | | | (17.60%-20.80%) | (31.43%-40.00%) | (5.08%-6.78%) | +--------------+-----------------+-----------------+----------------+ | Mailservers | 17.07% | 48.86% | 39.17% | | | (6.35%-26.98%) | (40.50%-65.42%) | (2.91%-12.73%) | +--------------+-----------------+-----------------+----------------+ | Namerservers | 15.37% | 43.25% | 38.55% | | | (14.29%-33.46%) | (42.49%-72.07%) | (3.90%-13.96%) | +--------------+-----------------+-----------------+----------------+ (DO8: Dest Options Header of 8 bytes, etc.) The numbers indicate the packet drop rate. The numbers within parenthesis indicate the percentage of cases where such packet drops occur in an AS different from that of the destination system. (i.e., this would suggest "think twice before employing IPv6 EHs.. then don't). > As far as the destination host goes, HbH can't be any more > dangerous than a destination option. As long as intermmediate systems ignore them (as suggested in RFC7045). > I personally don't care much in the IPv4 case, since router > alert seems to be a dead duck anyway. It's possible that's > going to be the case for HbH, but I think we should give it > a chance. That's why I raised the question. That said, the numbers I've provided above would suggest that this other duck is dead already, too. :-( Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 15 17:53:33 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36B1B29CB; Tue, 15 Jul 2014 17:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjSrHYwXO-Bl; Tue, 15 Jul 2014 17:53:22 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 437A41B29D0; Tue, 15 Jul 2014 17:53:22 -0700 (PDT) Received: from r200-40-240-99.su-static.anteldata.net.uy ([200.40.240.99] helo=[10.0.135.233]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7DTD-0000Dh-3C; Wed, 16 Jul 2014 02:53:19 +0200 Message-ID: <53C5CAEE.5080805@si6networks.com> Date: Tue, 15 Jul 2014 21:44:30 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , Brian E Carpenter , Fernando Gont References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> In-Reply-To: <53C5C91C.2020203@isi.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/FxENw6PS7t-eXAFpDSx_HOtvsaI Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations Subject: Re: [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 00:53:27 -0000 On 07/15/2014 09:36 PM, Joe Touch wrote: > > On 7/15/2014 5:08 PM, Brian E Carpenter wrote: >> The problem with both of these great inventions is that a single >> box on the path that takes the "drop" option breaks everything, >> whereas "ignore" at least provides best effort service and >> protects against any specific attack on the middlebox. >> As far as the destination host goes, HbH can't be any more >> dangerous than a destination option. > > IPv6 already indicates - inside the option type - what to do if an > option isn't supported. > > Why is honoring that set of flags not the only correct behavior? Because, with the world as we know it, that ends up killing performance -- with the corresponding implications (DoS) in extreme cases. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 16 02:29:27 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C9B1A001A for ; Wed, 16 Jul 2014 02:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU5duyNU0Y98 for ; Wed, 16 Jul 2014 02:29:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFEA1A00C2 for ; Wed, 16 Jul 2014 02:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10490; q=dns/txt; s=iport; t=1405502961; x=1406712561; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZsaHgSLhaQ19Ar+Zqk86C+Nv6hnooOb5SWdAyw4YByI=; b=fqabK/ox/LlBaVoVp/AGuLwcT5G/l+wcJ+8TDT5WeY3wKfSEmjKe8dKW 26dtJk6Vw80XZ1fXzDbY9mn58ylcyihbc0m28JPl00ty78ZlhyH9YydAa Hj8Okjr+6m+927LEVTue/8rIPpJtK3uSKe+AXjEGAdTU6ujQoBSeoVvRD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFADVFxlOtJV2Y/2dsb2JhbABZgkdHUlcEwEGBYIdCAYERFnWEAwEBAQQtRxUCAQgRBAEBCx0HMhQJCAIEARIIAYg5DcpOF45pEQEfNwGDLYEWBZxokluCAoFCbAGBCzk X-IronPort-AV: E=Sophos;i="5.01,670,1400025600"; d="scan'208,217";a="340452027" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2014 09:29:03 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6G9T3DZ011170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 09:29:03 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.10]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 04:29:03 -0500 From: "Gunter Van de Velde (gvandeve)" To: KK , "opsec@ietf.org" , "" Thread-Topic: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-bgp-security Thread-Index: AQHOKMdRISmCg+rDtE6iiLkGbc3WWZulXttA Date: Wed, 16 Jul 2014 09:28:12 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B241141A7A0@xmb-aln-x12.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.195.44] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B241141A7A0xmbalnx12ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/43t69R9lDckUhhRqTfNnCz2xRW8 Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-bgp-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 09:29:23 -0000 --_000_67832B1175062E48926BF3CB27C49B241141A7A0xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please find this reminder for IPR compliance. If you see any, then please let the WG know. Brgds, G/ From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of K= K Sent: 24 March 2013 20:39 To: opsec@ietf.org; Subject: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-ops= ec-bgp-security Dear OpSec WG, Be not alarmed. This email was created to satisfy RFC 6702 "Promoting Compliance with Intel= lectual Property Rights (IPR)" (http://tools.ietf.org/rfc/rfc6702.txt). The authors of draft-ietf-opsec-bgp-security have asked for a Working Group= Last Call. Before issuing the Working Group Last Call, we would like to c= heck whether any claims of Intellectual Property Rights (IPR) on the docume= nt have not yet been disclosed. Are you personally aware of any IPR that applies to draft-ietf-opsec-bgp-se= curity? If so, has this IPR been disclosed in compliance with IETF IPR rul= es? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please= reply to this email regardless of whether or not you are personally aware = of any relevant IPR. We might not be able to advance this document to the = next stage until we have received a reply from each author and listed contr= ibutor. If you are on the OpSec WG email list but are not an author or listed contr= ibutor for this document, you are reminded of your opportunity for a volunt= ary IPR disclosure under BCP 79. Please do not reply unless you want to ma= ke such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Thanks, KK (as OpSec WG co-chair) --_000_67832B1175062E48926BF3CB27C49B241141A7A0xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 <= /p>

Please find this reminder= for IPR compliance.

If you see any, then plea= se let the WG know.

 <= /p>

Brgds,<= /p>

G/

 <= /p>

From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org= ] On Behalf Of KK
Sent: 24 March 2013 20:39
To: opsec@ietf.org; <draft-ietf-opsec-bgp-security@tools.ietf.org= >
Subject: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-i= etf-opsec-bgp-security

 

Dear O= pSec WG,

 

Be not= alarmed.

This e= mail was created to satisfy RFC 6702 "Promoting Compliance with Intell= ectual Property Rights (IPR)"  (http://tools.ietf.org/rfc/rf= c6702.txt).

 

The au= thors of draft-ietf-opsec-bgp-security have asked for a Working Group Last = Call.  Before issuing the Working Group Last Call, we would like to check whether any claims of Intellectual Property Rights (IPR) on = the document have not yet been disclosed.

 

Are yo= u personally aware of any IPR that applies to draft-ietf-opsec-bgp-security= ?  If so, has this IPR been disclosed in compliance with IETF IPR rules?

(See R= FCs 3979, 4879, 3669, and 5378 for more details.)

 

If you= are a document author or listed contributor on this document, please reply= to this email regardless of whether or not you are personally aware of any relevant IPR.  We might not be able to advance this docu= ment to the next stage until we have received a reply from each author and = listed contributor.

 

If you= are on the OpSec WG email list but are not an author or listed contributor= for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79.  Please do not reply unl= ess you want to make such a voluntary disclosure.

 

Online= tools for filing IPR disclosures can be found at <http://www.iet= f.org/ipr/file-disclosure>.

 

Thanks= ,

KK

(as OpSec WG co-chair)=

--_000_67832B1175062E48926BF3CB27C49B241141A7A0xmbalnx12ciscoc_-- From nobody Wed Jul 16 09:57:00 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C601A0091 for ; Wed, 16 Jul 2014 09:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4tV3RLuZo6T for ; Wed, 16 Jul 2014 09:56:51 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACB11A008B for ; Wed, 16 Jul 2014 09:56:50 -0700 (PDT) Received: (qmail 15160 invoked from network); 16 Jul 2014 09:56:46 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Jul 2014 09:56:46 -0700 Date: Wed, 16 Jul 2014 09:56:46 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: OPSEC In-Reply-To: <53C5C279.2090600@gmail.com> Message-ID: References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/0QWiJsmi6xM38SboDJkgWWNyiL4 Cc: Fernando Gont , V6OPS Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 16:56:52 -0000 On Wed, 16 Jul 2014, Brian E Carpenter wrote: > The problem with both of these great inventions is that a single > box on the path that takes the "drop" option breaks everything, In that same vein, I wanted to object to this: | 2.3.6. Destination Options for IPv6 (Number=60) | | 2.3.6.1. Uses | | The Destination Options header is used to carry optional information | that need be examined only by a packet's destination node(s). | | 2.3.6.2. Specification | | This Extension Header is specified in [RFC2460]. At the time of this | writing, no options have been specified for this extension header. | | 2.3.6.3. Specific Security Implications | | No security implications are known, other than the general | implications of IPv6 extension headers. | | 2.3.6.4. Operational and Interoperability Impact if Blocked | | None. Even if there were no destination options currently defined -- which in fact is not true -- there is huge operational impact if this extension header is routinely blocked: it would make it impossible to deploy any destination options at all. The damage caused to the Internet by such practices is a recurring theme, and it should be spelled out explicitly here. Failure to do so makes the advice that follows ("Pass packets that contain the Destination Options Header") seem weak and ill-motivated. In fact, however, an examination of the references in the IANA IPv6 options registry indicates that the following destination options have been defined: Hex Value Binary Value Description Reference Status act chg rest 0x04 00 0 00100 Tunnel Encapsulation Limit [RFC2473] PS 0xC9 11 0 01001 Home Address [RFC6275] PS 0x8B 10 0 01011 ILNP Nonce [RFC6744] EXP 0x8C 10 0 01100 Line-Identification Option [RFC6788] PS The text in 2.3.6.2 needs to be reworked to mention these options. Mike Heard From nobody Wed Jul 16 10:10:14 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CF01A008B; Wed, 16 Jul 2014 10:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyiPDkXVDpSF; Wed, 16 Jul 2014 10:10:09 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4202D1A0068; Wed, 16 Jul 2014 10:10:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6GH9vnE009427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Jul 2014 10:09:58 -0700 (PDT) Message-ID: <53C6B1E5.4060905@isi.edu> Date: Wed, 16 Jul 2014 10:09:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: opsec@ietf.org, IPv6 Operations , Internet Area References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> In-Reply-To: <53C5CAEE.5080805@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/2J1HA2C8VjNKcyjbGjDXTTqwq74 Subject: Re: [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 17:10:10 -0000 Hi, all, I'm including INTAREA in the discussion because this doc seems to be an end-run around intending to deprecate IPv6 HBH options, or at least to redefine the option behavior bits defined in RFC 2460. IMO, that ought to be addressed in INTAREA, not V6OPS. IMO, the real DOS attack here is twofold: 1) vendors who misrepresent their boxes as IPv6-capable at a given packet rate 2) documents, such as this, that invert the Postel Principle into the Gont Principle: - Postel Principle: Be conservative in what you send and liberal in what you receive. - Gont Principle: Be paranoid in what you receive. Just because you receive something you didn't expect, does NOT make it an attack. I sincerely hope there are others who share this view, or we might as well just go straight to the conclusion that IPv6 routers that can't process 128-bit addresses really ought to be OK just forwarding based on the last 32. Joe On 7/15/2014 5:44 PM, Fernando Gont wrote: > On 07/15/2014 09:36 PM, Joe Touch wrote: >> >> On 7/15/2014 5:08 PM, Brian E Carpenter wrote: >>> The problem with both of these great inventions is that a single >>> box on the path that takes the "drop" option breaks everything, >>> whereas "ignore" at least provides best effort service and >>> protects against any specific attack on the middlebox. >>> As far as the destination host goes, HbH can't be any more >>> dangerous than a destination option. >> >> IPv6 already indicates - inside the option type - what to do if an >> option isn't supported. >> >> Why is honoring that set of flags not the only correct behavior? > > Because, with the world as we know it, that ends up killing performance > -- with the corresponding implications (DoS) in extreme cases. > > Cheers, > From nobody Wed Jul 16 15:13:29 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2273E1A0354 for ; Wed, 16 Jul 2014 15:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VMO7jSbzy-P for ; Wed, 16 Jul 2014 15:13:24 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EFA1A035A for ; Wed, 16 Jul 2014 15:13:24 -0700 (PDT) Received: (qmail 31778 invoked from network); 16 Jul 2014 15:13:16 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Jul 2014 15:13:16 -0700 Date: Wed, 16 Jul 2014 15:13:16 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Joe Touch In-Reply-To: <53C6B1E5.4060905@isi.edu> Message-ID: References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/3lPWF7-s4M-_DBgYZ0JCfvLXSso Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [OPSEC] [Int-area] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:13:26 -0000 On Wed, 16 Jul 2014, Joe Touch wrote: JT> I'm including INTAREA in the discussion because this doc seems to be an JT> end-run around intending to deprecate IPv6 HBH options, or at least to JT> redefine the option behavior bits defined in RFC 2460. IMO, that ought to be JT> addressed in INTAREA, not V6OPS. I think this would be within the purview, not of INTAREA, but of 6MAN, which, as noted by Brian Carpenter earlier in this thread, has recently spoken the subject: On Mon, 14 Jul 2014, Brian E Carpenter wrote: BEC> In fact, RFC [7045] changes that: BEC> BEC> > 2.2. Hop-by-Hop Options BEC> > BEC> > The IPv6 Hop-by-Hop Options header SHOULD be processed by BEC> > intermediate forwarding nodes as described in [RFC2460]. However, it BEC> > is to be expected that high-performance routers will either ignore it BEC> > or assign packets containing it to a slow processing path. BEC> BEC> You could s/must/should/. BEC> BEC> More important: BEC> BEC> > 2.3.1.5. Advice BEC> > BEC> > Intermediate systems should, by default, drop packets containing a BEC> > IPv6 Hop-by-Hop Option Extension Header. BEC> BEC> You can't say that! Firstly, RFC 7045 makes it permissible to BEC> simply ignore them. That's the simplest DoS defence. Secondly, BEC> well, dropping them is the wrong default because it breaks stuff. BEC> You could discuss whether to inspect them for valid contents, and BEC> you could discuss rate-limiting, which I understand some vendors BEC> support already. JT> IMO, the real DOS attack here is twofold: JT> JT> 1) vendors who misrepresent their boxes as IPv6-capable JT> at a given packet rate JT> JT> 2) documents, such as this, JT> that invert the Postel Principle into the Gont Principle: JT> JT> - Postel Principle: JT> Be conservative in what you send JT> and liberal in what you receive. JT> JT> - Gont Principle: JT> Be paranoid in what you receive. JT> JT> Just because you receive something you didn't expect, does NOT make it an JT> attack. JT> JT> I sincerely hope there are others who share this view, or we might as well JT> just go straight to the conclusion that IPv6 routers that can't process JT> 128-bit addresses really ought to be OK just forwarding based on the last 32. I've complained before about "default deny" bias harming the internet, and so have many others. It is a real problem. And it appears that both of the factors you mention are responsible for large-scale dropping of packets with IPv6 fragment headers in today's Internet. That being said, it is a different and more hostile Internet than in Postel's day. Under the Postel Principle, something useless but harmless (w.g., the IPv4 stream ID option) would be ignored; nowadays, you will probably find consensus that it is OK, or even desirable, to block things like that. In fairness to Mr. Gont, this draft is MUCH better that the initial versions of the corresponding IPv4 options filtering document. Even it I don't agree with all of them, the filtering recommendations in this draft do seem to motivated by legitimate operational concerns, not blanket paranoia. I think we should move further discussion back to OPSEC and V6OPS. //cmh From nobody Thu Jul 17 04:33:11 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76F41A0ADC for ; Thu, 17 Jul 2014 04:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.603 X-Spam-Level: X-Spam-Status: No, score=-12.603 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGml3ySLMPS1 for ; Thu, 17 Jul 2014 04:33:05 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1431A0ADD for ; Thu, 17 Jul 2014 04:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1103; q=dns/txt; s=iport; t=1405596781; x=1406806381; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hLeP+x1t6abXuYMg59w88GARA9kbuDYsmHGn/X9PTfs=; b=jnCMgHjCMVzmR/zbzERaeOAf03tjyBR45bHNLJlTbu73Jqwl38NZqI8e egOXJO+MZ4O346cwEVrUnvyKQGPsYPW9TIzFnQ0Qa9hzyQtpN7/jVSiiC 8IKzUslz+pT6Njl1WgD48oxVHLamwhrlbtik33Og/jbA3ev68axVszDfq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAIyzx1OtJA2G/2dsb2JhbABZgw6BKQTKfwGBBRZ2hAMBAQEEOksEAgEIEQQBAQEKFAkHMhQHAQEFAwIEEwiIOrRykTwXjmkRAR84BoMogRgBBK9LggKBQmyBDDk X-IronPort-AV: E=Sophos;i="5.01,678,1400025600"; d="scan'208";a="337596379" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 17 Jul 2014 11:33:00 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6HBWxnh027044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Jul 2014 11:32:59 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.10]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 06:32:59 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-bgp-security Thread-Index: AQHPoQ8UQE4e3Tb2ckyIdR9CE5GPa5ukIvpg Date: Thu, 17 Jul 2014 11:32:03 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B241141CAF6@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B241141A7B3@xmb-aln-x12.cisco.com> <20140716153654.GW51793@Space.Net> In-Reply-To: <20140716153654.GW51793@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.195.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/-6jDZQ3uWORyxq_X9zFtlH3dDXQ Subject: [OPSEC] FW: DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-bgp-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 11:33:06 -0000 fwd to keep track of the record. G/ -----Original Message----- From: Gert Doering [mailto:gert@space.net]=20 Sent: 16 July 2014 17:37 To: Gunter Van de Velde (gvandeve) Cc: ; kk@dropbox.com Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf= -opsec-bgp-security Hi, On Wed, Jul 16, 2014 at 09:29:59AM +0000, Gunter Van de Velde (gvandeve) wr= ote: > I have on the email list confirmation that there is no IPR attached to th= is document from Ivan and Jerome. >=20 > Could you please send also your answer to email list so I can complete th= e Shepherd write-up for IESG submit? No IPR attached as far as I know - definitely nothing from my side. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jul 17 13:11:45 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3571A01EB; Thu, 17 Jul 2014 13:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JDLGvVk9nGX; Thu, 17 Jul 2014 13:11:36 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2551A01E0; Thu, 17 Jul 2014 13:11:36 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6HKBEmq004052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Jul 2014 13:11:14 -0700 (PDT) Message-ID: <53C82DE3.5010007@isi.edu> Date: Thu, 17 Jul 2014 13:11:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "C. M. Heard" References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/8fdUP2jkFHNymT5-dIgcS64Wojw Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [OPSEC] [Int-area] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 20:11:42 -0000 On 7/16/2014 3:13 PM, C. M. Heard wrote: > Even it I don't agree with all of them, the filtering > recommendations in this draft do seem to motivated by legitimate operational > concerns, not blanket paranoia. They need to be characterized as what they are: - an attempt to accommodate devices that are NOT IPv6-compliant I agree that there are legitimate operational concerns, but redefining the behavior or the IPv6 flags is not the purview of operational or management groups in the IETF. If these features cannot be supported, then deprecate them through standards-track updates, not by de-facto deprecation through operational neutering. Joe From nobody Thu Jul 17 14:34:23 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40E71A0302; Thu, 17 Jul 2014 14:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.568 X-Spam-Level: * X-Spam-Status: No, score=1.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQXfSUZGckWq; Thu, 17 Jul 2014 14:34:18 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 DFB231B280A; Thu, 17 Jul 2014 14:34:17 -0700 (PDT) Received: from [209.226.201.241] (helo=[10.205.138.219]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7tJd-0002dg-1O; Thu, 17 Jul 2014 23:34:13 +0200 Message-ID: <53C8392D.9030206@gont.com.ar> Date: Thu, 17 Jul 2014 14:59:25 -0600 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , opsec@ietf.org, IPv6 Operations , Internet Area References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> In-Reply-To: <53C6B1E5.4060905@isi.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ZLI3j71q4IlwDRZVz4kVM4T6vPc Subject: Re: [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 21:34:20 -0000 Hi, Joe, On 07/16/2014 11:09 AM, Joe Touch wrote: > > I'm including INTAREA in the discussion because this doc seems to be an > end-run around intending to deprecate IPv6 HBH options, or at least to > redefine the option behavior bits defined in RFC 2460. IMO, that ought > to be addressed in INTAREA, not V6OPS. May I ask if you have read the I-D? Because this document is not trying to do any of the above. It simply aims at providing operational advice on how to filter packets with IPv6 EHs/options. > IMO, the real DOS attack here is twofold: > > 1) vendors who misrepresent their boxes as IPv6-capable > at a given packet rate > 2) documents, such as this, > that invert the Postel Principle into the Gont Principle: > > - Postel Principle: > Be conservative in what you send > and liberal in what you receive. > > - Gont Principle: > Be paranoid in what you receive. This document doesn't follow the "be paranoid principle" (if there's such a thing): It recommends to pass lots of stuff that that, if you were really paranoid, you wouldn't pass. And while Postel principle's aims at interoperability, here we're talking about avoiding some specific traffic from breaking your network. SO I don't really follow your analysis. > I sincerely hope there are others who share this view, What's "this view"? Have you followed the thread with Brian Carpenter regarding ignoring rather than dropping HBH? > or we might as > well just go straight to the conclusion that IPv6 routers that can't > process 128-bit addresses really ought to be OK just forwarding based on > the last 32. This document is an operations-related document, not a std track one. As such, it provides advice to the folks *running* the routers not the folks manufacturing them. Just for the sake of reality check: Packet drops rates for different traffic types (and, within parenthesis, the percentage of such drops occurring in a different AS): +--------------+-----------------+-----------------+----------------+ | Dataset | DO8 | HBH8 | FH512 | +--------------+-----------------+-----------------+----------------+ | Web | 11.88% | 40.70% | 30.51% | | | (17.60%-20.80%) | (31.43%-40.00%) | (5.08%-6.78%) | +--------------+-----------------+-----------------+----------------+ | Mailservers | 17.07% | 48.86% | 39.17% | | | (6.35%-26.98%) | (40.50%-65.42%) | (2.91%-12.73%) | +--------------+-----------------+-----------------+----------------+ | Namerservers | 15.37% | 43.25% | 38.55% | | | (14.29%-33.46%) | (42.49%-72.07%) | (3.90%-13.96%) | +--------------+-----------------+-----------------+----------------+ Yes: over 40% of packet drop rate for HBH, already. And quite a few folks (e.g. Google) drop all packets that contain IPv6 EHs. Thanks, -- 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 Thu Jul 17 14:43:52 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6171A028B; Thu, 17 Jul 2014 14:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xw1p7m09ksT; Thu, 17 Jul 2014 14:43:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B171A00BE; Thu, 17 Jul 2014 14:43:46 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s6HLhKaV008918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Jul 2014 14:43:20 -0700 (PDT) Message-ID: <53C84378.2010200@isi.edu> Date: Thu, 17 Jul 2014 14:43:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , opsec@ietf.org, IPv6 Operations , Internet Area References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C8392D.9030206@gont.com.ar> In-Reply-To: <53C8392D.9030206@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/JQ4dTVpxYP-8WNNPWAqoHnXGTdM Subject: Re: [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 21:43:48 -0000 On 7/17/2014 1:59 PM, Fernando Gont wrote: > On 07/16/2014 11:09 AM, Joe Touch wrote: >> > >> >I'm including INTAREA in the discussion because this doc seems to be an >> >end-run around intending to deprecate IPv6 HBH options, or at least to >> >redefine the option behavior bits defined in RFC 2460. IMO, that ought >> >to be addressed in INTAREA, not V6OPS. > > May I ask if you have read the I-D? Because this document is not trying > to do any of the above. ... From draft-gont-opsec-ipv6-eh-filtering-00.txt: 2.3.1.5. Advice Intermediate systems should, by default, drop packets containing a IPv6 Hop-by-Hop Option Extension Header. The currently required behavior of HBH option type "00" in RFC2460: 4.2 Options Two of the currently-defined extension headers -- the Hop-by-Hop Options header and the Destination Options header -- carry a variable number of type-length-value (TLV) encoded "options", of the following format: ... The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 00 - skip over this option and continue processing the header. ... From nobody Thu Jul 17 15:04:08 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480921A0302; Thu, 17 Jul 2014 15:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBpWr8sR9bvN; Thu, 17 Jul 2014 15:03:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 7E4681A0332; Thu, 17 Jul 2014 15:03:59 -0700 (PDT) Received: from [209.226.201.241] (helo=[10.205.138.219]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7tmL-0002jy-Dv; Fri, 18 Jul 2014 00:03:53 +0200 Message-ID: <53C84841.3050702@si6networks.com> Date: Thu, 17 Jul 2014 16:03:45 -0600 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , "C. M. Heard" References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C82DE3.5010007@isi.edu> In-Reply-To: <53C82DE3.5010007@isi.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/qIGQoxQc40hZH8hXEtvk06damrk Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [OPSEC] [v6ops] [Int-area] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 22:04:01 -0000 On 07/17/2014 02:11 PM, Joe Touch wrote: > > > On 7/16/2014 3:13 PM, C. M. Heard wrote: >> Even it I don't agree with all of them, the filtering >> recommendations in this draft do seem to motivated by legitimate >> operational >> concerns, not blanket paranoia. > > They need to be characterized as what they are: > > - an attempt to accommodate devices that are NOT IPv6-compliant I'd have a hard time coming uup with a vendor/device that can process IPv6 packets with HBH header with the same performance as regular packets. So.. are you suggesting that we start claiming that "we currently do not know of any ipv6-compliant routers", or what? (fwiw, I expect you are not) > I agree that there are legitimate operational concerns, but redefining > the behavior or the IPv6 flags is not the purview of operational or > management groups in the IETF. We're not redefining anything. We're just saying "look, if you're running an IPv6 network, this is probably the most sane thing to do". Having that sane advice doesn't prevent you from doing something else if you know better, if you want to allow everything withing your organization, or if you just don't care if your network melts down. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 17 15:06:08 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AA91B281A; Thu, 17 Jul 2014 15:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 197EmMqK-Ayh; Thu, 17 Jul 2014 15:06:03 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 DED6A1A0342; Thu, 17 Jul 2014 15:06:02 -0700 (PDT) Received: from [209.226.201.241] (helo=[10.205.138.219]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7toM-0002kw-Fe; Fri, 18 Jul 2014 00:05:58 +0200 Message-ID: <53C848C0.8040506@si6networks.com> Date: Thu, 17 Jul 2014 16:05:52 -0600 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "C. M. Heard" , Joe Touch References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/L0bPrSLW88TnFvBOxHPAr9PWcys Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [OPSEC] [Int-area] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 22:06:03 -0000 Hi, Mike, On 07/16/2014 04:13 PM, C. M. Heard wrote: > OK, or even desirable, to block things like that. In fairness to Mr. Gont, this > draft is MUCH better that the initial versions of the corresponding IPv4 options > filtering document. Thanks. And it's an individual -00 version. Nothing is set on stone. Even it I don't agree with all of them, the filtering > recommendations in this draft do seem to motivated by legitimate operational > concerns, not blanket paranoia. > > I think we should move further discussion back to OPSEC and V6OPS. Agree. Thanks! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 17 15:39:15 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2E71A0329; Thu, 17 Jul 2014 15:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmMqbWFBxrxm; Thu, 17 Jul 2014 15:39:00 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C601A0334; Thu, 17 Jul 2014 15:38:59 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s6HMcc8B002175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Jul 2014 15:38:38 -0700 (PDT) Message-ID: <53C8506E.1050002@isi.edu> Date: Thu, 17 Jul 2014 15:38:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , "C. M. Heard" References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C82DE3.5010007@isi.edu> <53C84841.3050702@si6networks.com> In-Reply-To: <53C84841.3050702@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/wVrmmlktYWc2E4WVZrDfy44hhkk Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [OPSEC] [v6ops] [Int-area] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 22:39:05 -0000 On 7/17/2014 3:03 PM, Fernando Gont wrote: > On 07/17/2014 02:11 PM, Joe Touch wrote: >> >> >> On 7/16/2014 3:13 PM, C. M. Heard wrote: >>> Even it I don't agree with all of them, the filtering >>> recommendations in this draft do seem to motivated by legitimate >>> operational >>> concerns, not blanket paranoia. >> >> They need to be characterized as what they are: >> >> - an attempt to accommodate devices that are NOT IPv6-compliant > > I'd have a hard time coming uup with a vendor/device that can process > IPv6 packets with HBH header with the same performance as regular > packets. So.. are you suggesting that we start claiming that "we > currently do not know of any ipv6-compliant routers", or what? (fwiw, I > expect you are not) If we are, then it's time to adjust RFC2460. IMO, we ought to: - define the features/capabilities we think are necessary - require that anything that doesn't support what's necessary as non-compliant Otherwise, you're just un-doing all the work that goes into the standards process in the first place. All because you think that anything you don't expect is an attack. It isn't. It just means you're not prepared. Joe From nobody Thu Jul 17 21:34:47 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFBB1A0495; Thu, 17 Jul 2014 21:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpkaa5DwxI_k; Thu, 17 Jul 2014 21:34:42 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 3E8FE1A0415; Thu, 17 Jul 2014 21:34:42 -0700 (PDT) Received: from static-68-179-14-169.ptr.terago.net ([68.179.14.169] helo=[172.16.52.172]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7zsO-0006Ml-HY; Fri, 18 Jul 2014 06:34:33 +0200 Message-ID: <53C8A0DF.9000605@si6networks.com> Date: Thu, 17 Jul 2014 22:21:51 -0600 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , "C. M. Heard" References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C82DE3.5010007@isi.edu> <53C84841.3050702@si6networks.com> <53C8506E.1050002@isi.edu> In-Reply-To: <53C8506E.1050002@isi.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/o8Xr87bs6_7FC2E41ZQNRv8GzIM Cc: OPSEC , Internet Area , IPv6 Operations Subject: Re: [OPSEC] [v6ops] [Int-area] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 04:34:44 -0000 On 07/17/2014 04:38 PM, Joe Touch wrote: >>> >>> They need to be characterized as what they are: >>> >>> - an attempt to accommodate devices that are NOT IPv6-compliant >> >> I'd have a hard time coming uup with a vendor/device that can process >> IPv6 packets with HBH header with the same performance as regular >> packets. So.. are you suggesting that we start claiming that "we >> currently do not know of any ipv6-compliant routers", or what? (fwiw, I >> expect you are not) > > If we are, then it's time to adjust RFC2460. I disagree. Operational policy != protocol specification. Actually, the IETF can do whatever it wants with the protocol specs, but not that much with the operational stuff (other than providing *advice* -- because ops folks can do whatever they want with their networks). > IMO, we ought to: > > - define the features/capabilities we think are necessary > > - require that anything that doesn't support what's necessary > as non-compliant > > Otherwise, you're just un-doing all the work that goes into the > standards process in the first place. All because you think that > anything you don't expect is an attack. It isn't. It just means you're > not prepared. We seem to be in disagreement. If anything, anything that I don't want is not an attack, but rather an unnecessary attack surface. But again, please read the I-D... because it really doesn't follow that reasoning. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jul 18 08:52:23 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BB51A0199 for ; Fri, 18 Jul 2014 08:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 KwckupEWJZ8U for ; Fri, 18 Jul 2014 08:52:04 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177CB1A05E5 for ; Fri, 18 Jul 2014 08:52:01 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so4688333wes.6 for ; Fri, 18 Jul 2014 08:51:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NfxyEZ9iRUl0lxbOMdCha4PUUQLAiShZnj3smyaOdNk=; b=JIzkfTHyGi/+AbvqHoymZ3hrTTh1V/Xxq+ETvjdDy+pAcPTu9tlld5YLZnB66Oe5Nu Lf/wDYr7pz7D6ldvRg9211KsiBhtKK9aVhuXiDLuWe8IS93tdrsBq1DCoaJzZYxu1cFF SpCl+PdV1sft+Qp2i6CD87YqDfgBK6kswefs3PJw3kMFfpIgSz7Vj4vObjSsfIa8yXOU IM41jeASXTRdFhU9RQGvqnFk3NanOMGM49vT+r6pUKPMlxOz1mjMK4JaYO2wvU35U4CM 2YxCvz5Fq27F4pDIT89BqT+Y2sqHyv0EV5WTnOS0qN7KRTTwUlR85o/1CsNjMkpzHvFx QBFQ== X-Gm-Message-State: ALoCoQkkEqMZ4ckXqmIOoTz2s3xAAvZ62S3hJa3cHpZKxucHwa295XhIz+jfnMawvnSscXQ915BM MIME-Version: 1.0 X-Received: by 10.180.90.132 with SMTP id bw4mr32715259wib.42.1405698719213; Fri, 18 Jul 2014 08:51:59 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Fri, 18 Jul 2014 08:51:59 -0700 (PDT) In-Reply-To: <53C8A0DF.9000605@si6networks.com> References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53C57F39.7080800@gont.com.ar> <53C5C279.2090600@gmail.com> <53C5C91C.2020203@isi.edu> <53C5CAEE.5080805@si6networks.com> <53C6B1E5.4060905@isi.edu> <53C82DE3.5010007@isi.edu> <53C84841.3050702@si6networks.com> <53C8506E.1050002@isi.edu> <53C8A0DF.9000605@si6networks.com> Date: Fri, 18 Jul 2014 11:51:59 -0400 Message-ID: From: Warren Kumari To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/otvk8DA1-xckLHz9l8ugXS5t6VA Cc: "C. M. Heard" , OPSEC , Internet Area , IPv6 Operations , Joe Touch Subject: Re: [OPSEC] [v6ops] [Int-area] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 15:52:05 -0000 On Fri, Jul 18, 2014 at 12:21 AM, Fernando Gont wrote: > On 07/17/2014 04:38 PM, Joe Touch wrote: >>>> >>>> They need to be characterized as what they are: >>>> >>>> - an attempt to accommodate devices that are NOT IPv6-compliant >>> >>> I'd have a hard time coming uup with a vendor/device that can process >>> IPv6 packets with HBH header with the same performance as regular >>> packets. So.. are you suggesting that we start claiming that "we >>> currently do not know of any ipv6-compliant routers", or what? (fwiw, I >>> expect you are not) >> >> If we are, then it's time to adjust RFC2460. > > I disagree. Operational policy != protocol specification. Actually, the > IETF can do whatever it wants with the protocol specs, but not that much > with the operational stuff (other than providing *advice* -- because ops > folks can do whatever they want with their networks). > > >> IMO, we ought to: >> >> - define the features/capabilities we think are necessary >> >> - require that anything that doesn't support what's necessary >> as non-compliant >> >> Otherwise, you're just un-doing all the work that goes into the >> standards process in the first place. All because you think that >> anything you don't expect is an attack. It isn't. It just means you're >> not prepared. > > We seem to be in disagreement. If anything, anything that I don't want > is not an attack, but rather an unnecessary attack surface. Related to this is http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 -- Why Operators Filter Fragments and What It Implies This expired, but I suspect we may need to revive it... W > But again, > please read the I-D... because it really doesn't follow that reasoning. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From nobody Mon Jul 21 07:42:00 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC3A1A002A for ; Mon, 21 Jul 2014 07:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-DpDaC0j4Z1 for ; Mon, 21 Jul 2014 07:41:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C48D1A000F for ; Mon, 21 Jul 2014 07:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2611; q=dns/txt; s=iport; t=1405953716; x=1407163316; h=from:to:cc:subject:date:message-id:mime-version; bh=Lyn3963zugejANpT5UppekOgbShHMYcMQvSjBSfvKbg=; b=VvUh7cMSGLm03EkqztZXXPKWnGHCkBt2mLKgkIsC5TALDQ+ihWdoowbP Eisz/kMmQyN/++W2jJsdynJAc9Lnf6rC8nvMxTahCuzWN/w55aqK9JQKs EyzUTEGB5QYqZH5OFbfl7DoAXWrawx2dK3x9RsykV+oY9BknbOvrCtNat k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAN4lzVOtJA2B/2dsb2JhbABZgkdHUlvNEQGBGBZ2hAUBBC1MEgEMHlYmAQQODYg6vlMXjBwBgn0xgzWBGAWvVINEgjE X-IronPort-AV: E=Sophos;i="5.01,701,1400025600"; d="scan'208,217";a="341675573" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jul 2014 14:41:55 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6LEftCw009080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 14:41:55 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.10]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 09:41:55 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: IETF90 - Notes and scribe volunteers requested Thread-Index: Ac+k8cBD2ScPTgwtTOa6Kg4FKvvDyw== Date: Mon, 21 Jul 2014 14:40:41 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B241141E10E@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.85.189] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B241141E10Exmbalnx12ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/R8gg74-_2i1iWPYfVvfpFbjZ0hc Cc: "kk@dropbox.com" Subject: [OPSEC] IETF90 - Notes and scribe volunteers requested X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:41:58 -0000 --_000_67832B1175062E48926BF3CB27C49B241141E10Exmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Is there a generous volunteer willing to take notes or as jabber scribe at = IETF90 OPSEC WG meeting? Let me know, Be well, G/ --_000_67832B1175062E48926BF3CB27C49B241141E10Exmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Is there a generous volunteer willing to take notes = or as jabber scribe at IETF90 OPSEC WG meeting?

 

Let me know,

Be well,

G/

--_000_67832B1175062E48926BF3CB27C49B241141E10Exmbalnx12ciscoc_-- From nobody Wed Jul 23 15:37:02 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F119E1B2932; Wed, 23 Jul 2014 15:36:58 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqb4ioWHsMQK; Wed, 23 Jul 2014 15:36:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF901A004D; Wed, 23 Jul 2014 15:36:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723223657.28210.93797.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 15:36:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ruedURjbRcWD_vUKGhsE_ALO8F0 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-09.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:36:59 -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 Working Group of the IETF. Title : Using Only Link-Local Addressing Inside an IPv6 Network Authors : Michael Behringer Eric Vyncke Filename : draft-ietf-opsec-lla-only-09.txt Pages : 10 Date : 2014-07-23 Abstract: In an IPv6 network it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to help the decision process for a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-lla-only-09 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 Wed Jul 23 15:42:21 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3F11ADDC6 for ; Wed, 23 Jul 2014 15:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcFuFq4YHdxu for ; Wed, 23 Jul 2014 15:42:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C161AD62A for ; Wed, 23 Jul 2014 15:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1946; q=dns/txt; s=iport; t=1406155339; x=1407364939; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kWCQq6PnPLe+EacPqxxfaIe9mHZCd4gYoiA3pSRLSn4=; b=SxbQq99Oqmy46m6qzNKBSrOlvq49UPn85Msiqu2LL3wtgcGF/eiAn0sd RWEWRrukkdLpfNVr2zqTUgUBdGU7Eqevagez/LE6OZqbUhj4YZCE1eh+7 ymrkTuUJG5fnRjiAi46nWo/OVViqrxMk/8/X2De+KbogTJMZKJd3OTc5O I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAMk50FOtJA2I/2dsb2JhbABZgw5SUwQEgnTGO4dFARlyFnaEAwEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEDgUIAYg5CAWobpdgF4EsjW4xBwaCcjaBGAWcf5Jug0hsAYFE X-IronPort-AV: E=Sophos;i="5.01,720,1400025600"; d="scan'208";a="342339135" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2014 22:42:19 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6NMgHdl009565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 22:42:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 17:42:17 -0500 From: "Michael Behringer (mbehring)" To: "opsec@ietf.org" Thread-Topic: New Version Notification - draft-ietf-opsec-lla-only-09.txt Thread-Index: AQHPpsaj4BMWeFeseUa7UZGTov4z4JuuP82w Date: Wed, 23 Jul 2014 22:42:16 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF367D@xmb-rcd-x14.cisco.com> References: <20140723223657.28210.96429.idtracker@ietfa.amsl.com> In-Reply-To: <20140723223657.28210.96429.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.126] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/yvCO54ysNbayijQa0gyydiuDBUo Cc: "draft-ietf-opsec-lla-only@tools.ietf.org" Subject: [OPSEC] FW: New Version Notification - draft-ietf-opsec-lla-only-09.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:42:20 -0000 T1BzZWMgV0csIA0KDQpKb2VsIGhhcyByZXF1ZXN0ZWQgdXMgdG8gYWRkIGEgcGFyYWdyYXBoIHRv IHRoZSBpbnRybyBvZiB0aGlzIGRyYWZ0LCBleHByZXNzaW5nIHRoZSBjb25jZXJuIG9mIHNldmVy YWwgZm9sa3MgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0LiBUaGlzIGlzIHRoZSBvbmx5IGNoYW5nZSBm cm9tIC0wOCB0byAtMDksIGFuZCB0aGUgcGFyYWdyYXBoIGluIHF1ZXN0aW9uIHJlYWRzOiANCg0K ICAgRHVyaW5nIElFU0cgcmV2aWV3IHRoZSB0ZWNobmljYWwgY29ycmVjdG5lc3MgYW5kIGNvbXBs ZXRlbmVzcyBvZiB0aGUNCiAgIGRvY3VtZW50IGhhcyBiZWVuIGZ1bGx5IHJldmlld2VkIGFuZCB2 ZXJpZmllZCwgSG93ZXZlciwgSUVTRyBub3RlZA0KICAgdGhhdCB0aGVyZSB3YXMgbm8gZnVsbCBj b25zZW5zdXMgd2l0aGluIHRoZSB3b3JraW5nIGdyb3VwIG9uIHdoZXRoZXINCiAgIHRvIHJlY29t bWVuZCB0aGlzIHRlY2huaXF1ZS4NCg0KV2l0aCB0aGlzLCB3ZSBiZWxpZXZlIHRoYXQgYWxsIG91 dHN0YW5kaW5nIGlzc3VlcyBhcmUgcmVzb2x2ZWQuIA0KDQpNaWNoYWVsDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IDIzIEp1bHkgMjAxNCAxODoz Nw0KPiBUbzogb3BzZWMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW9wc2VjLWxs YS1vbmx5QHRvb2xzLmlldGYub3JnOw0KPiBqb2VsamFAYm9ndXMuY29tDQo+IFN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtb3BzZWMtbGxhLW9ubHktMDkudHh0 DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiAoLTA5KSBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIGRy YWZ0LWlldGYtb3BzZWMtbGxhLW9ubHk6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtb3BzZWMtbGxhLW9ubHktMDkudHh0DQo+IA0KPiANCj4gVGhlIElF VEYgZGF0YXRyYWNrZXIgcGFnZSBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNlYy1sbGEtb25seS8NCj4g DQo+IERpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2VjLWxsYS1vbmx5LTA5DQo+IA0KPiBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0K PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJRVRGIFNlY3JldGFyaWF0Lg0KDQo= From nobody Thu Jul 24 14:57:27 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BA11A00DE; Thu, 24 Jul 2014 14:57:12 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY1nYLwpsd07; Thu, 24 Jul 2014 14:57:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 101211A026E; Thu, 24 Jul 2014 14:57:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140724215710.16003.13002.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 14:57:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/zoEgfx0R1z67W65EwjO7f1UT1h0 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-04.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 21:57:12 -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 Working Group of the IETF. Title : BGP operations and security Authors : Jerome Durand Ivan Pepelnjak Gert Doering Filename : draft-ietf-opsec-bgp-security-04.txt Pages : 29 Date : 2014-07-24 Abstract: BGP (Border Gateway Protocol) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself (like TTL, TCP-AO, control plane filtering) and to better control the flow of routing information, using prefix filtering and automatization of prefix filters, max-prefix filtering, AS path filtering, route flap dampening and BGP community scrubbing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-bgp-security-04 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 Sat Jul 26 04:05:13 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB7B1A854B for ; Sat, 26 Jul 2014 04:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6I0Xs4vNMF3 for ; Sat, 26 Jul 2014 04:05:09 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E511A8BAF for ; Sat, 26 Jul 2014 04:05:09 -0700 (PDT) Received: from mb-aye.local ([207.164.2.187]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s6QB54A0035169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 26 Jul 2014 11:05:04 GMT (envelope-from joelja@bogus.com) Message-ID: <53D38B5B.8040501@bogus.com> Date: Sat, 26 Jul 2014 07:04:59 -0400 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "opsec@ietf.org" References: <20140723223657.28210.96429.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF367D@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF367D@xmb-rcd-x14.cisco.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AA7P1Ugrms8jP7ppPajdwaJDBkhblw7wC" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sat, 26 Jul 2014 11:05:05 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Cs5kS-oft48LIWTZMl9DYU9afZ4 Cc: "draft-ietf-opsec-lla-only@tools.ietf.org" Subject: Re: [OPSEC] FW: New Version Notification - draft-ietf-opsec-lla-only-09.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 11:05:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AA7P1Ugrms8jP7ppPajdwaJDBkhblw7wC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/23/14, 6:42 PM, Michael Behringer (mbehring) wrote: > OPsec WG,=20 >=20 > Joel has requested us to add a paragraph to the intro of this draft, ex= pressing the concern of several folks discussed on the list. This is the = only change from -08 to -09, and the paragraph in question reads:=20 >=20 > During IESG review the technical correctness and completeness of the= > document has been fully reviewed and verified, However, IESG noted > that there was no full consensus within the working group on whether= > to recommend this technique. Sorry, I'm going to have to apologize becasue reading this again while not under the duress of the meeting I think it misses the point (it's not the IESG) and we need to tweak one last time. During WG and IETF last call the technical correctness of the document has been reviewed, however debate exists as to whether to recommend this technique. The deployment of this technique is appropriate where it is found to be necessary. > With this, we believe that all outstanding issues are resolved.=20 >=20 > Michael >=20 >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: 23 July 2014 18:37 >> To: opsec-chairs@tools.ietf.org; draft-ietf-opsec-lla-only@tools.ietf.= org; >> joelja@bogus.com >> Subject: New Version Notification - draft-ietf-opsec-lla-only-09.txt >> >> >> A new version (-09) has been submitted for draft-ietf-opsec-lla-only: >> http://www.ietf.org/internet-drafts/draft-ietf-opsec-lla-only-09.txt >> >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/ >> >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-only-09 >> >> 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. >> >> IETF Secretariat. >=20 >=20 --AA7P1Ugrms8jP7ppPajdwaJDBkhblw7wC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPTi1wACgkQ8AA1q7Z/VrJHbACeMhVh1mJoGuQAbJHaYUCOXDg1 GHwAn2Hb9v/+WFpQP8Z5FogFZ8cmsUKg =7w2N -----END PGP SIGNATURE----- --AA7P1Ugrms8jP7ppPajdwaJDBkhblw7wC-- From nobody Mon Jul 28 00:16:00 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DAB1A027C; Mon, 28 Jul 2014 00:15:28 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 260XqQC2eo5N; Mon, 28 Jul 2014 00:15:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 464F11A028E; Mon, 28 Jul 2014 00:15:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140728071522.16158.68728.idtracker@ietfa.amsl.com> Date: Mon, 28 Jul 2014 00:15:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/MK_oSM1zo0NLvY0HQswaNwt9Rmo Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-10.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 07:15: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 Working Group of the IETF. Title : Using Only Link-Local Addressing Inside an IPv6 Network Authors : Michael Behringer Eric Vyncke Filename : draft-ietf-opsec-lla-only-10.txt Pages : 10 Date : 2014-07-28 Abstract: In an IPv6 network it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to help the decision process for a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-lla-only-10 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 Mon Jul 28 00:17:08 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE8C1A017C for ; Mon, 28 Jul 2014 00:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJInPEC9qi7C for ; Mon, 28 Jul 2014 00:17:00 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159701A02E8 for ; Mon, 28 Jul 2014 00:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4208; q=dns/txt; s=iport; t=1406531785; x=1407741385; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OukLfhvEKE49dG3f7MJDpSFLjtkBkVyk2ZR1rkPatR4=; b=PiJOYNcvZDV2b0d1ogBeQvdRS1LhmbhFFXi/2xLrmIhWknOzw+AqRsaD T3kpd7guGAXKCQs90eKWuHZO/Bp0pLC+Rp+/wteQfYYONxBviVDMlB8MN ZsZjiVRPsl0p0upTdNh5LB048AfLf20PjrCmDRypLTGi9cgHGli6yMJ4y E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAMv31VOtJV2a/2dsb2JhbABZgw5SUwQEgnTIbYdFARl6FneEAwEBAQQjEUMCDAQCAQgRBAEBAQICBh0DAgICMBQBBwEIAgQBDQUIAYg5CAWmSZZsF4EsjW8xBwaCczaBGwWdHpJ6g0lsAYFE X-IronPort-AV: E=Sophos;i="5.01,747,1400025600"; d="scan'208";a="64488894" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 28 Jul 2014 07:16:24 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6S7GO1L006771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 07:16:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 02:15:47 -0500 From: "Michael Behringer (mbehring)" To: joel jaeggli , "opsec@ietf.org" Thread-Topic: FW: New Version Notification - draft-ietf-opsec-lla-only-09.txt Thread-Index: AQHPpsaj4BMWeFeseUa7UZGTov4z4JuuP82wgARJWICAApDIsA== Date: Mon, 28 Jul 2014 07:16:23 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF7F32@xmb-rcd-x14.cisco.com> References: <20140723223657.28210.96429.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21BF367D@xmb-rcd-x14.cisco.com> <53D38B5B.8040501@bogus.com> In-Reply-To: <53D38B5B.8040501@bogus.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.72.28] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/HjmF00eahDoU0rIvERMj8gmPO_o Cc: "draft-ietf-opsec-lla-only@tools.ietf.org" Subject: Re: [OPSEC] FW: New Version Notification - draft-ietf-opsec-lla-only-09.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 07:17:04 -0000 Q2hhbmdlZCBhcyByZXF1ZXN0ZWQuIE5vdyB2ZXJzaW9uIC0xMC4gDQoNCi0tDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1vcHNlYy1sbGEtb25seS0xMC50eHQgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaWNoYWVsIEJlaHJpbmdlciBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1pZXRmLW9wc2VjLWxsYS1vbmx5DQpS ZXZpc2lvbjoJMTANClRpdGxlOgkJVXNpbmcgT25seSBMaW5rLUxvY2FsIEFkZHJlc3NpbmcgSW5z aWRlIGFuIElQdjYgTmV0d29yaw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wNy0yOA0KR3JvdXA6CQlv cHNlYw0KUGFnZXM6CQkxMA0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb3BzZWMtbGxhLW9ubHktMTAudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNlYy1s bGEtb25seS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9wc2VjLWxsYS1vbmx5LTEwDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vcHNlYy1sbGEtb25seS0xMA0KLS0NCg0KTWlj aGFlbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGpvZWwgamFlZ2ds aSBbbWFpbHRvOmpvZWxqYUBib2d1cy5jb21dDQo+IFNlbnQ6IDI2IEp1bHkgMjAxNCAxMzowNQ0K PiBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgb3BzZWNAaWV0Zi5vcmcNCj4gQ2M6 IGRyYWZ0LWlldGYtb3BzZWMtbGxhLW9ubHlAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLW9wc2VjLWxsYS1vbmx5 LTA5LnR4dA0KPiANCj4gT24gNy8yMy8xNCwgNjo0MiBQTSwgTWljaGFlbCBCZWhyaW5nZXIgKG1i ZWhyaW5nKSB3cm90ZToNCj4gPiBPUHNlYyBXRywNCj4gPg0KPiA+IEpvZWwgaGFzIHJlcXVlc3Rl ZCB1cyB0byBhZGQgYSBwYXJhZ3JhcGggdG8gdGhlIGludHJvIG9mIHRoaXMgZHJhZnQsDQo+IGV4 cHJlc3NpbmcgdGhlIGNvbmNlcm4gb2Ygc2V2ZXJhbCBmb2xrcyBkaXNjdXNzZWQgb24gdGhlIGxp c3QuIFRoaXMgaXMgdGhlIG9ubHkNCj4gY2hhbmdlIGZyb20gLTA4IHRvIC0wOSwgYW5kIHRoZSBw YXJhZ3JhcGggaW4gcXVlc3Rpb24gcmVhZHM6DQo+ID4NCj4gPiAgICBEdXJpbmcgSUVTRyByZXZp ZXcgdGhlIHRlY2huaWNhbCBjb3JyZWN0bmVzcyBhbmQgY29tcGxldGVuZXNzIG9mIHRoZQ0KPiA+ ICAgIGRvY3VtZW50IGhhcyBiZWVuIGZ1bGx5IHJldmlld2VkIGFuZCB2ZXJpZmllZCwgSG93ZXZl ciwgSUVTRyBub3RlZA0KPiA+ICAgIHRoYXQgdGhlcmUgd2FzIG5vIGZ1bGwgY29uc2Vuc3VzIHdp dGhpbiB0aGUgd29ya2luZyBncm91cCBvbiB3aGV0aGVyDQo+ID4gICAgdG8gcmVjb21tZW5kIHRo aXMgdGVjaG5pcXVlLg0KPiANCj4gU29ycnksIEknbSBnb2luZyB0byBoYXZlIHRvIGFwb2xvZ2l6 ZSBiZWNhc3VlIHJlYWRpbmcgdGhpcyBhZ2FpbiB3aGlsZSBub3QNCj4gdW5kZXIgdGhlIGR1cmVz cyBvZiB0aGUgbWVldGluZyBJIHRoaW5rIGl0IG1pc3NlcyB0aGUgcG9pbnQgIChpdCdzIG5vdCB0 aGUNCj4gSUVTRykgYW5kIHdlIG5lZWQgdG8gdHdlYWsgb25lIGxhc3QgdGltZS4NCj4gDQo+ICAg IER1cmluZyAgV0cgYW5kIElFVEYgIGxhc3QgY2FsbCB0aGUgdGVjaG5pY2FsIGNvcnJlY3RuZXNz ICBvZiB0aGUgZG9jdW1lbnQNCj4gaGFzIGJlZW4NCj4gICAgcmV2aWV3ZWQsIGhvd2V2ZXIgZGVi YXRlIGV4aXN0cyBhcyB0byB3aGV0aGVyIHRvIHJlY29tbWVuZCB0aGlzDQo+IHRlY2huaXF1ZS4g VGhlDQo+ICAgIGRlcGxveW1lbnQgb2YgdGhpcyB0ZWNobmlxdWUgaXMgYXBwcm9wcmlhdGUgd2hl cmUgaXQgaXMgZm91bmQgdG8gYmUNCj4gbmVjZXNzYXJ5Lg0KPiANCj4gPiBXaXRoIHRoaXMsIHdl IGJlbGlldmUgdGhhdCBhbGwgb3V0c3RhbmRpbmcgaXNzdWVzIGFyZSByZXNvbHZlZC4NCj4gPg0K PiA+IE1pY2hhZWwNCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4gPj4gU2VudDogMjMgSnVseSAyMDE0IDE4OjM3DQo+ID4+IFRvOiBvcHNl Yy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7DQo+ID4+IGRyYWZ0LWlldGYtb3BzZWMtbGxhLW9ubHlA dG9vbHMuaWV0Zi5vcmc7DQo+ID4+IGpvZWxqYUBib2d1cy5jb20NCj4gPj4gU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1vcHNlYy1sbGEtb25seS0wOS50eHQN Cj4gPj4NCj4gPj4NCj4gPj4gQSBuZXcgdmVyc2lvbiAoLTA5KSBoYXMgYmVlbiBzdWJtaXR0ZWQg Zm9yIGRyYWZ0LWlldGYtb3BzZWMtbGxhLW9ubHk6DQo+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb3BzZWMtbGxhLW9ubHktMDkudHh0DQo+ID4+DQo+ ID4+DQo+ID4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHBhZ2UgZm9yIHRoaXMgSW50ZXJuZXQtRHJh ZnQgaXM6DQo+ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt b3BzZWMtbGxhLW9ubHkvDQo+ID4+DQo+ID4+IERpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uOg0K PiA+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2VjLWxs YS1vbmx5LTA5DQo+ID4+DQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+IHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiB0b29scy5pZXRm Lm9yZy4NCj4gPj4NCj4gPj4gSUVURiBTZWNyZXRhcmlhdC4NCj4gPg0KPiA+DQo+IA0KDQo=