From internet-drafts@ietf.org Mon Feb 3 20:50:43 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 2F3BB1A0366; Mon, 3 Feb 2014 20:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLcBVeJ-xHV5; Mon, 3 Feb 2014 20:50:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 075461A036A; Mon, 3 Feb 2014 20:50:41 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204045041.28117.86966.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2014 20:50:41 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-02.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, 04 Feb 2014 04:50:43 -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-02.txt Pages : 9 Date : 2014-02-03 Abstract: This document specifies a mechanism for protecting hosts connected to a broadcast 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-02 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 wwwrun@rfc-editor.org Mon Feb 10 20:25: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 9643E1A07A1; Mon, 10 Feb 2014 20:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 Fn-8ysvt4i6M; Mon, 10 Feb 2014 20:25:27 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 4C01B1A08AA; Mon, 10 Feb 2014 20:25:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EC1D97FC3A4; Mon, 10 Feb 2014 20:25:26 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140211042526.EC1D97FC3A4@rfc-editor.org> Date: Mon, 10 Feb 2014 20:25:26 -0800 (PST) Cc: drafts-update-ref@iana.org, opsec@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSEC] RFC 7123 on Security Implications of IPv6 on IPv4 Networks 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, 11 Feb 2014 04:25:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7123 Title: Security Implications of IPv6 on IPv4 Networks Author: F. Gont, W. Liu Status: Informational Stream: IETF Date: February 2014 Mailbox: fgont@si6networks.com, liushucheng@huawei.com Pages: 19 Characters: 42374 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07.txt URL: http://www.rfc-editor.org/rfc/rfc7123.txt This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Feb 10 20:26:01 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 F12E31A08C0; Mon, 10 Feb 2014 20:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 tWsLJrrJgxyL; Mon, 10 Feb 2014 20:25:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id EB3101A08BD; Mon, 10 Feb 2014 20:25:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B749B7FC399; Mon, 10 Feb 2014 20:25:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140211042558.B749B7FC399@rfc-editor.org> Date: Mon, 10 Feb 2014 20:25:58 -0800 (PST) Cc: drafts-update-ref@iana.org, opsec@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSEC] BCP 186, RFC 7126 on Recommendations on Filtering of IPv4 Packets Containing IPv4 Options 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, 11 Feb 2014 04:26:01 -0000 A new Request for Comments is now available in online RFC libraries. BCP 186 RFC 7126 Title: Recommendations on Filtering of IPv4 Packets Containing IPv4 Options Author: F. Gont, R. Atkinson, C. Pignataro Status: Best Current Practice Stream: IETF Date: February 2014 Mailbox: fgont@si6networks.com, rja.lists@gmail.com, cpignata@cisco.com Pages: 36 Characters: 72504 See Also: BCP 186 I-D Tag: draft-ietf-opsec-ip-options-filtering-07.txt URL: http://www.rfc-editor.org/rfc/rfc7126.txt This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From gvandeve@cisco.com Tue Feb 11 03:34:57 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 738661A07F2 for ; Tue, 11 Feb 2014 03:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 BZGwNV92Ct4V for ; Tue, 11 Feb 2014 03:34:55 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 987B61A07E4 for ; Tue, 11 Feb 2014 03:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1441; q=dns/txt; s=iport; t=1392118495; x=1393328095; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=mfNTb1IfgTNQWk5X16N2eBihSR4eMF9ewfnYWyDCImc=; b=fbkVjEc2JpA1tYJrcaBs9YBPgjuWUnjjfWzpLwas7beuI7KCl9p8msQK g40v1568WuMqiFVA4m8kEceblInHPf++UtryorT4gmd2Ue3wE2+FO5AQ7 1HO8pXYbiFYX1P2BUlr7xyC9+gM+mx3m7G2iB7tEkyGs/v+AUuzhXxBb0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHUK+lKtJV2b/2dsb2JhbABZgww4V75lgRAWdIInAQQ6OgUSASoUQiYBBA4NAYd8DckMF44XEQEfMYMrgRQEmVyQboMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,825,1384300800"; d="scan'208";a="303060199" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 11 Feb 2014 11:34:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1BBYiYa024414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 11:34:44 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.234]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 05:34:44 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-lla-only-06 Thread-Index: Ac8nHJjtu92E2OduQ/ahVi/xjtThwQ== Date: Tue, 11 Feb 2014 11:34:44 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B241132F95B@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.202.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-lla-only-06 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, 11 Feb 2014 11:34:57 -0000 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). We would like to check whether any claims of Intellectual Property Rights (= IPR) on the document have not yet been disclosed. (I know none were submitted for the -03 version, however the draft progress= ed since request to -06) Are you personally aware of any IPR that applies to draft-ietf-opsec-lla-on= ly-06? If so, has this IPR been disclosed in compliance with IETF IPR rule= s? (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. Please add opsec WG email list as recipient. 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, Gunter Van de Velde (as OpSec WG co-chair) From internet-drafts@ietf.org Thu Feb 13 01:05:48 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 2AD051A015F; Thu, 13 Feb 2014 01:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpyzm2sN5o3U; Thu, 13 Feb 2014 01:05:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E76461A01AB; Thu, 13 Feb 2014 01:05:44 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213090544.4453.16675.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 01:05:44 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-07.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 09:05:48 -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-07.txt Pages : 10 Date : 2014-02-13 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-lla-only-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbehring@cisco.com Thu Feb 13 01:50:06 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 3E29D1A012D for ; Thu, 13 Feb 2014 01:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 JZyg7gOBeLw0 for ; Thu, 13 Feb 2014 01:50:03 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id C18121A013C for ; Thu, 13 Feb 2014 01:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2043; q=dns/txt; s=iport; t=1392285003; x=1393494603; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=crnt0JMFaXltG9JdrX5j+pwX1vjPJIRbSpcU2JAIXKg=; b=fcRslvDdB2uGbnHHwEyW6oPtB9L6G96u7Gu4/92vuXuYES2dYZdsD9tc KZtX0uU2iJaLGxaLAYxfN867FtM4wiUMkhE02NngOlz8bO9xg9GlphjeO Q6sbCs0t42cfmEGLxcp0vmK9X1oQSekwsjvwSPEyS++ms5MH2WhePYegc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAC6U/FKtJXG+/2dsb2JhbABZgwg4V79KgRUWdIIlAQEBBAEBATc0BhEEAgEIEQQBAQsUCQcnCxQJCAEBBAESCAGHfA3IBxeOFxEBHzgGgx6BFASZXpBxgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,837,1384300800"; d="scan'208";a="20122568" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-5.cisco.com with ESMTP; 13 Feb 2014 09:50:02 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1D9o2Qg011332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Feb 2014 09:50:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.215]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 03:50:02 -0600 From: "Michael Behringer (mbehring)" To: "Gunter Van de Velde (gvandeve)" , "opsec@ietf.org" Thread-Topic: DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-lla-only-06 Thread-Index: Ac8nHJjtu92E2OduQ/ahVi/xjtThwQBhEa8A Date: Thu, 13 Feb 2014 09:50:02 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D97A9AD@xmb-rcd-x14.cisco.com> References: <67832B1175062E48926BF3CB27C49B241132F95B@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B241132F95B@xmb-aln-x12.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-lla-only-06 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, 13 Feb 2014 09:50:06 -0000 For the record: I am not aware of any IPR relating to draft-ietf-opsec-lla-= only Michael > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de > Velde (gvandeve) > Sent: 11 February 2014 12:35 > To: opsec@ietf.org > Subject: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf- > opsec-lla-only-06 >=20 > Dear OpSec WG, >=20 > Be not alarmed. > This email was created to satisfy RFC 6702 "Promoting Compliance with > Intellectual Property Rights (IPR)" (http://tools.ietf.org/rfc/rfc6702.t= xt). >=20 >=20 > We would like to check whether any claims of Intellectual Property Rights > (IPR) on the document have not yet been disclosed. > (I know none were submitted for the -03 version, however the draft > progressed since request to -06) >=20 > Are you personally aware of any IPR that applies to draft-ietf-opsec-lla-= only- > 06? If so, has this IPR been disclosed in compliance with IETF IPR rules= ? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) >=20 > If you are a document author or listed contributor on this document, plea= se > reply to this email regardless of whether or not you are personally aware= of > any relevant IPR. We might not be able to advance this document to the > next stage until we have received a reply from each author and listed > contributor. Please add opsec WG email list as recipient. >=20 > If you are on the OpSec WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity for a > voluntary IPR disclosure under BCP 79. Please do not reply unless you wa= nt > to make such a voluntary disclosure. >=20 > Online tools for filing IPR disclosures can be found at > . >=20 > Thanks, > Gunter Van de Velde > (as OpSec WG co-chair) >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From evyncke@cisco.com Thu Feb 13 01:57: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 558DC1A0172 for ; Thu, 13 Feb 2014 01:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 pWDAQce5NJ00 for ; Thu, 13 Feb 2014 01:57:10 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id E67371A0110 for ; Thu, 13 Feb 2014 01:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2434; q=dns/txt; s=iport; t=1392285429; x=1393495029; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wQWwzv7ONayoWCUiWEWR1u4+cxgicY43DRbKGWDHWsI=; b=XkEb+AcABHkEbbVsQUnQAICcGkXFZV+PhFdyzPriHorUQTSAmzyoWqos BZHHnCOi/N0rNAHYaI27+CJn+Dumbdy6t5faFD7+AbLn6+/qC/zqbieQC UNScsCLpWZ7ULTPm2pmkfxqIEr8ZqVoWiGb7ga1+Wv+5EU/TWJTOCpEUs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FALmW/FKtJXG9/2dsb2JhbABZgwg4V79LgRUWdIIlAQEBBAEBAWsGEQYBCBEEAQEoLgsUCQoEARIJh3wNyAoXjhcRAV2EMgSJEI8cgTKQcYFvgT6BcTk X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208";a="20111738" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-3.cisco.com with ESMTP; 13 Feb 2014 09:57:07 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1D9v7X2017948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Feb 2014 09:57:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 03:57:07 -0600 From: "Eric Vyncke (evyncke)" To: "Michael Behringer (mbehring)" , "Gunter Van de Velde (gvandeve)" , "opsec@ietf.org" Thread-Topic: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-lla-only-06 Thread-Index: AQHPKKH03RbNkjb2AEW2CGbR4f323A== Date: Thu, 13 Feb 2014 09:57:07 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.55.185.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-lla-only-06 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, 13 Feb 2014 09:57:12 -0000 Michael and others, Same boat here: I am not aware of any IPR related to draft-ietf-opsec-lla-only -=E9ric On 13/02/14 10:50, "Michael Behringer (mbehring)" wrote: >For the record: I am not aware of any IPR relating to >draft-ietf-opsec-lla-only > >Michael > >> -----Original Message----- >> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de >> Velde (gvandeve) >> Sent: 11 February 2014 12:35 >> To: opsec@ietf.org >> Subject: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf- >> opsec-lla-only-06 >>=20 >> Dear OpSec WG, >>=20 >> Be not alarmed. >> This email was created to satisfy RFC 6702 "Promoting Compliance with >> Intellectual Property Rights (IPR)" >>(http://tools.ietf.org/rfc/rfc6702.txt). >>=20 >>=20 >> We would like to check whether any claims of Intellectual Property >>Rights >> (IPR) on the document have not yet been disclosed. >> (I know none were submitted for the -03 version, however the draft >> progressed since request to -06) >>=20 >> Are you personally aware of any IPR that applies to >>draft-ietf-opsec-lla-only- >> 06? If so, has this IPR been disclosed in compliance with IETF IPR >>rules? >> (See RFCs 3979, 4879, 3669, and 5378 for more details.) >>=20 >> If you are a document author or listed contributor on this document, >>please >> reply to this email regardless of whether or not you are personally >>aware of >> any relevant IPR. We might not be able to advance this document to the >> next stage until we have received a reply from each author and listed >> contributor. Please add opsec WG email list as recipient. >>=20 >> If you are on the OpSec WG email list but are not an author or listed >> contributor for this document, you are reminded of your opportunity for >>a >> voluntary IPR disclosure under BCP 79. Please do not reply unless you >>want >> to make such a voluntary disclosure. >>=20 >> Online tools for filing IPR disclosures can be found at >> . >>=20 >> Thanks, >> Gunter Van de Velde >> (as OpSec WG co-chair) >>=20 >>=20 >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec > >_______________________________________________ >OPSEC mailing list >OPSEC@ietf.org >https://www.ietf.org/mailman/listinfo/opsec From evyncke@cisco.com Thu Feb 13 01:57:58 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 EB0761A0172; Thu, 13 Feb 2014 01:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 rO-_AmHDSBRV; Thu, 13 Feb 2014 01:57:56 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED271A0117; Thu, 13 Feb 2014 01:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1686; q=dns/txt; s=iport; t=1392285475; x=1393495075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DYTFIxV94qBIhrFwEyzv50Xm6Yx99HgC3I7l5qzoWMo=; b=SK+8jioMCz9X/TtHlLCKbuPyAmasu33C2gprugsURe8FF2hWJ12lKPmr wWFfhkvnI+ixtzjfZqmN0cTQZdJyd9DjbS9pPgNNc5Vr6NuqPaLZFvw12 XysE6DbbHfXYsVsLx7UELpAYLTZgJGrLPpOCGj/cgrMZFmBqfUB9IdD+t E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAIGW/FKtJV2d/2dsb2JhbABZgwg4UQa/S4EVFnSCJgEBBAEBAWsLEAIBCEYnCyUCBAENBQmHfAgFyAoXjnkHhDgEiRCPHIEykHGDLYIq X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208";a="303808302" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 13 Feb 2014 09:57:55 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1D9vtrq011913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 09:57:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 03:57:54 -0600 From: "Eric Vyncke (evyncke)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-07.txt Thread-Index: AQHPKJrNez/PmwqGWkSWQAq+5kf6c5qzaEKA Date: Thu, 13 Feb 2014 09:57:54 +0000 Message-ID: References: <20140213090544.4453.16675.idtracker@ietfa.amsl.com> In-Reply-To: <20140213090544.4453.16675.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.55.185.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6848829A28336E468C0D5B7DC7C6FBF3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-07.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, 13 Feb 2014 09:57:59 -0000 Fixing the latest idnits =3D=3D removing a dangling reference to RFC 792 -=E9ric On 13/02/14 10:05, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the 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-07.txt > Pages : 10 > Date : 2014-02-13 > >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-07 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-only-07 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >OPSEC mailing list >OPSEC@ietf.org >https://www.ietf.org/mailman/listinfo/opsec From Marco.Ermini@ResMed.com Tue Feb 18 06:57: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 1D4A91A064A for ; Tue, 18 Feb 2014 06:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=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 d-XplGRMN_Zg for ; Tue, 18 Feb 2014 06:57:05 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.9]) by ietfa.amsl.com (Postfix) with ESMTP id DBB1C1A04FE for ; Tue, 18 Feb 2014 06:57:05 -0800 (PST) Received: from [216.82.250.99:60635] by server-9.bemta-12.messagelabs.com id EB/90-31016-EB473035; Tue, 18 Feb 2014 14:57:02 +0000 X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-14.tower-126.messagelabs.com!1392735421!11806066!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=resmed.com,-,- X-VirusChecked: Checked Received: (qmail 29647 invoked from network); 18 Feb 2014 14:57:02 -0000 Received: from unknown (HELO mail.resmed.de) (195.234.33.10) by server-14.tower-126.messagelabs.com with SMTP; 18 Feb 2014 14:57:02 -0000 Received: from GE2EML2K1002.corp.resmed.org ([172.17.6.117]) by mail.resmed.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 15:57:01 +0100 Received: from GE2EML2K1003.corp.resmed.org ([fe80::8547:a85:1c2d:a4bd]) by GE2EML2K1002.corp.resmed.org ([fe80::f03c:7713:9fd9:8984%17]) with mapi id 14.01.0355.002; Tue, 18 Feb 2014 15:57:01 +0100 From: Marco Ermini To: "opsec@ietf.org" Thread-Topic: I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt Thread-Index: Ac8suawmwS2WEn1STli9AEMChgEPqA== Date: Tue, 18 Feb 2014 14:57:00 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C469B76AA@GE2EML2K1003.corp.resmed.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Feb 2014 14:57:01.0780 (UTC) FILETIME=[AE0EA140:01CF2CB9] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/nZPK9vo1TqtBnw3kBcJPQHcrZ2Y Subject: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-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, 18 Feb 2014 14:59:27 -0000 Hi everyone, a new Internet-Draft is available from the on-line Internet-Drafts directo= ries. This draft is about defining requirements for IPv6-capable Firewalls. You = are welcome to have a look and contribute. =09Title=09=09: Using Only Link-Local Addressing Inside an IPv6 Network =09Authors=09: F. Gont =09=09=09 M. Ermini =09=09=09 W. Liu =09Filename=09: draft-gont-opsec-ipv6-firewall-reqs-00.txt =09Pages=09=09: 12 =09Date=09=09: 2014-02-14 Abstract: While there are a large number of documents discussing IP and IPv6 packet filtering, requirements for IPv6 firewalls have never been specified in the RFC series. When it comes to IPv6, the more limited experience with the protocols, and reduced variety of products has made it rather difficult to specify what are reasonable features to be expected from an IPv6 firewall. This has typically been a problem for network operators, who typically have to produce a "Request for Proposal" (from scratch) that describes such features. This document specifies a set of requirements for IPv6 firewalls, marked as "mandatory", "recommended", or "optional". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-firewall-reqs/ Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Kind regards, Marco Ermini - PhD CISSP CISA CEH ITIL MCP Senior IT Security & Compliance Analyst | Compliance Europe ResMed Germany Inc. Gesch=E4ftsf=FChrer: Frank Rebbert, Eric Paffrath, Michael Taube Sitz der Gesellschaft: M=FCnchen Registergericht: M=FCnchen, HRB 156206 ---------------------------------------------------------------------- Warning: Copyright ResMed. Where the contents of this email and/or attac= hment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between R= esMed and the intended recipient. This communication is confidential and = may contain legally privileged information. By the use of email over the = Internet or other communication systems, ResMed is not waiving either conf= identiality of, or legal privilege in, the content of the email and of any= attachments. If the recipient of this message is not the intended addres= see, please call ResMed immediately on 1 (800) 424-0737 USA. ---------------------------------------------------------------------- From nobody Tue Feb 18 15:43: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 BC5681A02BB for ; Tue, 18 Feb 2014 15:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE3QogWaiAiV for ; Tue, 18 Feb 2014 15:42:55 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF901A0106 for ; Tue, 18 Feb 2014 15:42:55 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1INgl8D000942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 16:42:47 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 417EC1E006F; Tue, 18 Feb 2014 17:42:42 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 122AE1E0049; Tue, 18 Feb 2014 17:42:42 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1INdUrY026352; Tue, 18 Feb 2014 16:39:30 -0700 (MST) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1INdUHB026338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 16:39:30 -0700 (MST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 16:39:30 -0700 From: "Smith, Donald" To: Marco Ermini , "opsec@ietf.org" Thread-Topic: I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt Thread-Index: Ac8suawmwS2WEn1STli9AEMChgEPqAAQEsj4 Date: Tue, 18 Feb 2014 23:39:29 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D123C146D@PDDCWMBXEX503.ctl.intranet> References: <38465846B6383D4A8688C0A13971900C469B76AA@GE2EML2K1003.corp.resmed.org> In-Reply-To: <38465846B6383D4A8688C0A13971900C469B76AA@GE2EML2K1003.corp.resmed.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/keyVzhkch6kCp1WrA4WuV0e_zTI Cc: "fgont@si6networks.com" Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-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, 18 Feb 2014 23:42:59 -0000 Just a nit initially. "This document specifies a set of requirements for IPv6 firewalls, marked as "mandatory", "recommended", or "optional"." That isn't the language we use. In fact in terminology Mr Gont uses the right language. " 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]." This is hard very hard I don't know of a single v4 firewall that can do ful= l proxies for all tcp applications. REQ GEN-3: MUST support full-proxy for the TCP [RFC0793] connections (the handshake is validated on the firewall before reaching the target system). I think what you want is proxies for common layer 7 protocols (like http, f= tp etc...) So maybe something like this: REQ GEN-3: Should support full-proxy for common TCP [RFC0793] layer seven protoc= ols. However if what you really want is TCP three ways proxied that is a little = different. Would a tcp cookie implementation meet this requirement? Or do you want the= three way done with the firewall then thrown away and you add the src to a= whitelist for the next attempt or replay one side or do you want the fw to= proxy the syn in, syn/ack out and ack back in? If so what is the benefit i= f it keeps all the state in two places now (host and firewall)? Time outs are generally used mostly for UDP not TCP. I don't object to havi= ng a timeout ability on tcp connections too but their primary use is UDP to= day in v4. REQ GEN-4: MUST be able to enforce timeouts on TCP connections based on specific protocols (e.g. enforce DNS timeout to a specific number of seconds, or FIN-WAIT, etc.). In general, it MUST have different kind of timeout values and thresholds to be used to prevent idle established connections to saturate resources on both the device and the service that is defended. So maybe "timeouts on UDP, TCP and other IP protocols" ... This is sometimes referred to as policy routing. REQ GEN-6: MUST be able to redirect specific traffic to a proxy server e.g. for HTTP/S protocols. But by saying "redirect" in theory a FW could meet that requirement by just= rewriting the MAC and replaying the packet. Not really routing a layer 2 r= edirect. Which did you mean or did you mean both? REQ SPC-1 and 4 are the same. It says here that we want to match icmpv6 errors to tcp and udp you should = include "and other ipv6 protocols" and won't this bring on new icmp blind t= cp reset issues? REQ SPC-6: MUST be able to statefully match ICMPv6 errors to TCP [RFC0793], UDP [RFC0768], and ICMPv6 [RFC4443] communication instances. Split tunneling is almost always a concern on the client side not on firewa= lls. REQ VPN-5: MUST be able to disable or enable split-tunnelling feature on VPN as required. I have never seen that applied to a firewall but can't say it couldn't be:) In general you allow in a vpn remote access client and DON'T want them also= connected directly to the internet as that punches a whole in your firewal= l (potentially anyways). This: REQ VPN-6: MUST be able to work indifferently on IPv4 and IPv6, and also offer both protocol in dual-stack in the same VPN connection. Should be this: REQ VPN-6: MUST be able to transit IPv4 and IPv6 packets providing full parity f= or services, and also offer both protocols in dual-stack in the same VPN connection. I am thinking tunnel instead of connection but do not feel strongly about i= t. The use of indifferently isn't technically wrong but isn't the common use o= f that word. This is really ip stack specific attacks (not really os specific). I have run non-native ip stacks on some OSes in the past (win3.1...) REQ DoS-1: MUST be able to protect against OS-specific attacks: nuke, ping- of-death (NOTE: this list should be expanded, and references added). And all of those pretty much died out. Having said that in there isn't bad. Here are a few more of those ip stack attacks. ICMP Fragments based attacks (this would include POD) and you include frage= ment based attacks in the next requirement. Smurf Attack Xmas Tree Attack LAND Attack Teardrop Attack This one probably needs some expansion. REQ DoS-4: MUST be able to protect against TCP resource exhaustion attacks: zero-window attacks, SYN-floods, etc. (see e.g. [CPNI-TCP]) So for syn flooding do we want proxied tcp cookies, or simple tcp ratelimit= ing and do you expect grey, white and blacklisting to be done based on some= form of authentication (completes the hand shake or gets the cookie right = ...)? Or can any or all methods be treated the same? Wrong RFC :) REQ DoS-8: MUST be able to participate to a blackhole/sync hole routing infrastructure as per [RFC5635]. You probably want this one https://tools.ietf.org/rfc/rfc3882.txt as it tal= ks about sinkholing (and it is sink hole not sync hole :) The other one is about doing urpf with BHF and being able to do src based B= HF. Also we may need to define what "participate" means. I generally don't expe= ct firewalls (FW) to talk bgp and BHF is generally done with BGP. I will stop here for now to allow you to think about it and the next sectio= n is going to take more thought. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: OPSEC [opsec-bounces@ietf.org] on behalf of Marco Ermini [Marco.Ermin= i@ResMed.com] Sent: Tuesday, February 18, 2014 7:57 AM To: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt Hi everyone, a new Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is about defining requirements for IPv6-capable Firewalls. You a= re welcome to have a look and contribute. Title : Using Only Link-Local Addressing Inside an IPv6 N= etwork Authors : F. Gont M. Ermini W. Liu Filename : draft-gont-opsec-ipv6-firewall-reqs-00.txt Pages : 12 Date : 2014-02-14 Abstract: While there are a large number of documents discussing IP and IPv6 packet filtering, requirements for IPv6 firewalls have never been specified in the RFC series. When it comes to IPv6, the more limited experience with the protocols, and reduced variety of products has made it rather difficult to specify what are reasonable features to be expected from an IPv6 firewall. This has typically been a problem for network operators, who typically have to produce a "Request for Proposal" (from scratch) that describes such features. This document specifies a set of requirements for IPv6 firewalls, marked as "mandatory", "recommended", or "optional". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-firewall-reqs/ Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Kind regards, Marco Ermini - PhD CISSP CISA CEH ITIL MCP Senior IT Security & Compliance Analyst | Compliance Europe ResMed Germany Inc. Gesch=E4ftsf=FChrer: Frank Rebbert, Eric Paffrath, Michael Taube Sitz der Gesellschaft: M=FCnchen Registergericht: M=FCnchen, HRB 156206 ---------------------------------------------------------------------- Warning: Copyright ResMed. Where the contents of this email and/or attach= ment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between Re= sMed and the intended recipient. This communication is confidential and ma= y contain legally privileged information. By the use of email over the Int= ernet or other communication systems, ResMed is not waiving either confiden= tiality of, or legal privilege in, the content of the email and of any atta= chments. If the recipient of this message is not the intended addressee, p= lease call ResMed immediately on 1 (800) 424-0737 USA. ---------------------------------------------------------------------- _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec= From nobody Tue Feb 18 21:06: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 AFDFC1A0332 for ; Tue, 18 Feb 2014 21:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO4dYlnOg7wz for ; Tue, 18 Feb 2014 21:06:20 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B73AE1A0434 for ; Tue, 18 Feb 2014 21:06:20 -0800 (PST) Received: from [2001:5c0:1400:a::12e3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WFzMP-0005Gx-0e; Wed, 19 Feb 2014 06:06:17 +0100 Message-ID: <53043BB4.9020707@gont.com.ar> Date: Wed, 19 Feb 2014 02:05:56 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "'opsec@ietf.org'" 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/6royPASdokN0ww_bt4JPuFHL-O0 Subject: [OPSEC] Meta-comment on draft-gont-opsec-ipv6-firewall-reqs-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, 19 Feb 2014 05:06:22 -0000 Folks, Just as a clarification (please read the whole thing before responding on this thread): This first revision of the I-D has these goals (in order of priority, I'd say): 1) Agree on a rationale to write this spec. For example, one possible rationale is "aim at providing parity of features with IPv4". Another one could be that "should should aim a little higher". For example, in the light of draft-farrell-perpass-attack we may aim at requiring some privacy features that might not be that common in IPv4 firewalls. 2) Expose different aspects of firewalls that we may want to standardize. High-level feedback along the lines of "this other aspect is missing, and should be added" or "we probably should not address this or that other aspect" are very valuable. 3) Discussion of concrete requirements. Here the feedback would be in the form of "This or that requirement is missing", "this or that requirement doesn't make sense and should be eliminated", etc. And for each of those that we keep in, arguments in favor of "mandatory", "recommended", or "optional" (i.e., what the level of each requirement should be). I will start a new thread to start discussing item #1 above. Thanks! Fernando -- 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 Feb 18 21:09:19 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 3FC1D1A04E0 for ; Tue, 18 Feb 2014 21:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixZGPHZJINLz for ; Tue, 18 Feb 2014 21:09:16 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id AF2BB1A027C for ; Tue, 18 Feb 2014 21:09:16 -0800 (PST) Received: from [2001:5c0:1400:a::12e3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WFzPE-0005Hb-1P; Wed, 19 Feb 2014 06:09:12 +0100 Message-ID: <53043C77.2060100@gont.com.ar> Date: Wed, 19 Feb 2014 02:09:11 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "'opsec@ietf.org'" 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/WsxH1hP7fxj6HWnSV93btmjFFWs Subject: [OPSEC] IPv6 firewalls reqs: Rationale 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, 19 Feb 2014 05:09:18 -0000 Folks, As noted in my previous email, this is a request to discuss the first item listed in my previous email: 1) Agree on a rationale to write this spec. For example, one possible rationale is "aim at providing parity of features with IPv4". Another one could be that "should should aim a little higher". For example, in the light of draft-farrell-perpass-attack we may aim at requiring some privacy features that might not be that common in IPv4 firewalls. Thoughts? Yours, -- 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 Feb 18 21:17: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 0488C1A026C for ; Tue, 18 Feb 2014 21:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 RFeA0bqrpoGM for ; Tue, 18 Feb 2014 21:17:15 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5303E1A01DC for ; Tue, 18 Feb 2014 21:17:15 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w62so12514535wes.1 for ; Tue, 18 Feb 2014 21:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H8Bkv7CCNiDC13hclkyYhZu/1y4a0Hq703Rzrv9I4no=; b=1ACNKg9QOWg+DOmAVKK5GsMN/ta2bh9nsmIYvfsZmKxim4P2rmXjmgmypI1y76f0sM gYI5hktf4TLoy0tB36snBgohvKrKuRxhpzzxeKYZxPkrcln6EflVQq2DepH2RiTTgiaB Zu9mheGwKjFr6LVNUx6AVmggROyCfRyLmuEFEUHoQK5M5217WubETE6mZtK8rzYtBRwI Ldsiafrjl+TaCuqny+hi1TwIwdlJsqqljR0qfne2U4WXrEYGJqRn0rC8Mp31sFp5Sg1t t43lIxoFqr7DrwSg+lrGBuIM5yWZac1Ei0u9nJnWuTROFuWjMZkKQbnvf5K7ruuS2cht sbqQ== MIME-Version: 1.0 X-Received: by 10.194.90.144 with SMTP id bw16mr25812505wjb.1.1392787031663; Tue, 18 Feb 2014 21:17:11 -0800 (PST) Received: by 10.194.133.169 with HTTP; Tue, 18 Feb 2014 21:17:11 -0800 (PST) In-Reply-To: <53043C77.2060100@gont.com.ar> References: <53043C77.2060100@gont.com.ar> Date: Tue, 18 Feb 2014 21:17:11 -0800 Message-ID: From: Cb B To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/9nEZJF4pYQQMhb074mb8HHL7MyQ Cc: "opsec@ietf.org" Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale 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, 19 Feb 2014 05:17:17 -0000 On Tue, Feb 18, 2014 at 9:09 PM, Fernando Gont wrote: > Folks, > > As noted in my previous email, this is a request to discuss the first > item listed in my previous email: > > 1) Agree on a rationale to write this spec. > > For example, one possible rationale is "aim at providing parity of > features with IPv4". Another one could be that "should should aim a > little higher". For example, in the light of > draft-farrell-perpass-attack we may aim at requiring some privacy > features that might not be that common in IPv4 firewalls. > > > Thoughts? > Why would you look to a middle box to add privacy or any feature at all? AFAIK, "firewalls" are in a unique position to be a single point of failure for confidentiality , availability , and integrit. data point - https://isc.sans.edu/forums/diary/Linksys+Worm+TheMoon+Summary+What+we+know+so+far/17633 Is there an IPv4 document that is similar in nature at the IETF? Or is spec'ing firewalls a novel thing that for some reason is only relevant to IPv6 CB > Yours, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From nobody Tue Feb 18 21:37:30 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 0DF621A0424 for ; Tue, 18 Feb 2014 21:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl52_EhazRsL for ; Tue, 18 Feb 2014 21:37:26 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id AC6821A0443 for ; Tue, 18 Feb 2014 21:37:26 -0800 (PST) Received: from [2001:5c0:1400:a::12e3] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WFzqU-0005zT-R5; Wed, 19 Feb 2014 06:37:23 +0100 Message-ID: <530442FF.3090807@gont.com.ar> Date: Wed, 19 Feb 2014 02:37:03 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cb B References: <53043C77.2060100@gont.com.ar> 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/57PJYTq22sC1W_q5JbP-3b3Sb_o Cc: "opsec@ietf.org" Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale 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, 19 Feb 2014 05:37:28 -0000 On 02/19/2014 02:17 AM, Cb B wrote: > > Why would you look to a middle box to add privacy or any feature at > all? Yep, sloppy terminology, sorry. -- I meant confidentiality, and I was referring to e.g. the VPN requirements in the current version of the document. *And*, I wasn't really arguing in favor. Just posing the question. > AFAIK, "firewalls" are in a unique position to be a single point of > failure for confidentiality , availability , and integrit. > > data point - > https://isc.sans.edu/forums/diary/Linksys+Worm+TheMoon+Summary+What+we+know+so+far/17633 > > Is there an IPv4 document that is similar in nature at the IETF? No. Firewalls have been mostly ignored in the IETF series. > Or is spec'ing firewalls a novel thing that for some reason is only > relevant to IPv6 I wouldn't call it novel. And it's certainly also relevant for IPv4, too. We probably left the IPv4 stuff out on the reasoning that it's probably rather late for that. The goal of specifying the requirements for v6 is because we have heard from many operators that whenever they want to purchase an IPv6 firewall, they have to come up with the requirements themselves, and then what they get from vendors is usually "not that nice" (so to speak :-) ). Please see e.g. the IPv6 firewalls talk(s) from the ipv6hackers meeting in Berlin 2013 (http://www.ipv6hackers.org). P.S.: Bottom-line: I posted this request for feedback for folks to make their point, not to necessarily agree with what's currently in the I-D! ;-) Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Feb 19 04:35: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 2D8201A05B5 for ; Wed, 19 Feb 2014 04:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, 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 o4XthyXE8AFr for ; Wed, 19 Feb 2014 04:35:10 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4EC1A0487 for ; Wed, 19 Feb 2014 04:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4188; q=dns/txt; s=iport; t=1392813307; x=1394022907; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=k3zbBodFdgTXriYt6l66d0EUHv8ZL0cUl4HNLoTF2f0=; b=WeDD54OEsh+5gu14en6tHgKe35Tx1/jhUQmsoJ1knXyS5EnOTEZ5lIcu FwKQBqg4VbS/HrtIHvBsTJ6VkM+AYaEBEYeyh8JRFmq1XX1r5Dn9nC7Ef IQg8CA8bZCUnDtp6gqJzyFONxAx3Kz3X60c53wrgW3d6Qut9IUL7GX7vC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFALajBFOtJXHA/2dsb2JhbABZgkREgQ28SoEeFgF0g30BAQEEgQkCAQgEDQMBAigHMhQJCAIEARKIBMU1F44+QxiENgEDmBaSFIMrgio X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208,217";a="302017410" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 19 Feb 2014 12:35:07 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1JCZ6kW025866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 12:35:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 06:35:06 -0600 From: "Eric Vyncke (evyncke)" To: KK , "opsec@ietf.org" Thread-Topic: [OPSEC] London IETF Meeting Thread-Index: AQHPEuzlaire8uSSOkuIbDbw1jf+z5q9LYUA Date: Wed, 19 Feb 2014 12:35:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.55.185.70] Content-Type: multipart/alternative; boundary="_000_CF2A637AD7C9evynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/nfcIObHaDUeghfvi10--ZmHsJ-g Subject: Re: [OPSEC] London IETF Meeting 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, 19 Feb 2014 12:35:13 -0000 --_000_CF2A637AD7C9evynckeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So, it looks like we will not meet in London? From: Kiran Chittimaneni > Date: jeudi 16 janvier 2014 19:57 To: "opsec@ietf.org" > Subject: [OPSEC] London IETF Meeting Dear Opsec WG, We need to request a meeting timeslot for London by 17th January. There hav= en=92t been any major updates to any of the drafts and little discussion on= -list since IETF88. In our attempt to make the lives of the secretariat eas= ier, our current thought is to not request a meeting timeslot for IETF89. H= owever, before doing so, we wanted to check with the WG. It would be good t= o hear from you and get some guidance on this matter. Regards, KK and Gunter --_000_CF2A637AD7C9evynckeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <96BE5F7F4880804F8EE11CE3E0B0DAD0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
So, it looks like we will not meet in London?

From: Kiran Chittimaneni <kk@google.com>
Date: jeudi 16 janvier 2014 19:57 To: "opsec@ietf.org" <ops= ec@ietf.org>
Subject: [OPSEC] London IETF Meetin= g

= Dear Opsec WG,


= We need to request a meeting timeslot for London by 17= th January. There haven=92t been any major updates to any of the drafts and little discussion on-list since IETF88. I= n our attempt to make the lives of the secretariat easier, our current thou= ght is to not request a meeting timeslot for IETF89. However, before doing = so, we wanted to check with the WG. It would be good to hear from you and get some guidance on this matter= .


= Regards,

= KK and Gunter


 --_000_CF2A637AD7C9evynckeciscocom_-- From nobody Wed Feb 19 05:32: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 D53C91A04B4 for ; Wed, 19 Feb 2014 05:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 j1agxdh21Q83 for ; Wed, 19 Feb 2014 05:32:16 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.106]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8E1A0148 for ; Wed, 19 Feb 2014 05:32:16 -0800 (PST) Received: from [216.82.253.147:4137] by server-10.bemta-7.messagelabs.com id 6F/04-15119-D52B4035; Wed, 19 Feb 2014 13:32:13 +0000 X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-10.tower-165.messagelabs.com!1392816731!12922537!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=resmed.com,-,- X-VirusChecked: Checked Received: (qmail 2203 invoked from network); 19 Feb 2014 13:32:12 -0000 Received: from unknown (HELO mail.resmed.de) (195.234.33.10) by server-10.tower-165.messagelabs.com with SMTP; 19 Feb 2014 13:32:12 -0000 Received: from GE2EML2K1002.corp.resmed.org ([172.17.6.117]) by mail.resmed.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Feb 2014 14:32:10 +0100 Received: from GE2EML2K1003.corp.resmed.org ([fe80::8547:a85:1c2d:a4bd]) by GE2EML2K1002.corp.resmed.org ([fe80::f03c:7713:9fd9:8984%17]) with mapi id 14.01.0355.002; Wed, 19 Feb 2014 14:32:10 +0100 From: Marco Ermini To: "Smith, Donald" , "opsec@ietf.org" Thread-Topic: I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt Thread-Index: Ac8suawmwS2WEn1STli9AEMChgEPqAAQEsj4ABjGMiA= Date: Wed, 19 Feb 2014 13:32:09 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C469BA6EF@GE2EML2K1003.corp.resmed.org> References: <38465846B6383D4A8688C0A13971900C469B76AA@GE2EML2K1003.corp.resmed.org> <68EFACB32CF4464298EA2779B058889D123C146D@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D123C146D@PDDCWMBXEX503.ctl.intranet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2014 13:32:10.0876 (UTC) FILETIME=[FE0E13C0:01CF2D76] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/XqxOne7carokG-hvQZ9i2ZPL-M0 Cc: "fgont@si6networks.com" Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-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, 19 Feb 2014 13:32:20 -0000 Apologies for my crap quoting, I am stuck to Outlook :-( > From: Smith, Donald [mailto:Donald.Smith@CenturyLink.com]=20 > Sent: Mittwoch, 19. Februar 2014 00:39 > To: Marco Ermini; opsec@ietf.org > Cc: fgont@si6networks.com; liushucheng@huawei.com > Subject: RE: I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt > [...] > > This is hard very hard I don't know of a single v4 firewall that can do = full proxies for all tcp applications. > > REQ GEN-3: > MUST support full-proxy for the TCP [RFC0793] connections (the > handshake is validated on the firewall before reaching the target > system). > I think what you want is proxies for common layer 7 protocols (like http= , ftp etc...) So maybe something like this: > REQ GEN-3: > Should support full-proxy for common TCP [RFC0793] layer seven pro= tocols. Hi Donald, Almost every IPv4 firewall today can do it. Even certain NIPS can do it. I= am pretty certain about all of the Juniper SRX series, including the Juni= per IDP NIPS - they do full TCP=20handshake on behalf of the clients, and = CheckPoint can do that too I think. Cisco ASA do the same, they just call it "TCP Intercept and Limiting Embry= onic Connections" but practically they do TCP proxy, verify syn-cookies, r= ate limits, and so on. It is pretty much a standard feature, so I see no reason to lower the bar.= Actually being that at the TCP level, I would expect it to work equally fo= r IPv4 and IPv6 easily. It should be low hanging fruits for firewall vendo= rs. > However if what you really want is TCP three ways proxied that is a litt= le different. > Would a tcp cookie implementation meet this requirement? Or do you want = the three way done with the firewall then thrown away and you add the src = to > a whitelist for the next attempt or replay one side or do you want the = fw to proxy the syn in, syn/ack out and ack back in? If so what is the ben= efit if it > keeps all the state in two places now (host and firewall)? The benefit of a TCP proxy is to normalize the connection, and as you corr= ectly mentioned, check if a source (which can be spoofed) has too many TCP= -SYN without acting on TCP-ACK, or syn-cookies are not set, or even add a = sequence randomization for the response port in place of an incapable host= . Generally firewalls are even smart enough to avoid applying randomization = in certain cases (e.g., eBGP peers using MD5 checksum would be broken by r= andomization applied by the firewall, so it will not apply it to this kind= of traffic. Or at least, the documentation says an administrator should a= pply it in that case ;-)). Do not underestimate the power of these appliances, especially if you have= n't really used them in large scale environment. They are very effective a= nd proven on IPv4 - the real problem is to have these features on IPv6 too= ; this is where vendors are lazy, mostly because of the usual adoption iss= ues that generally affects IPv6 (vendors go where they can smell the money= , unless "encouraged"). > Time outs are generally used mostly for UDP not TCP. I don't object to h= aving a timeout ability on tcp connections too but their primary use is UD= P > today in v4. Connection limits are pretty common on UDP too, and are necessary to limit= UDP DoS/DDoS. I do not think removing them for UDP is really a smart move= . Of course, the only kind of UDP connection limits are maximum number of si= multaneous connections and per client connections; you cannot define how m= any proxied connection can be done as this is a TCP-only feature. > REQ GEN-4: > MUST be able to enforce timeouts on TCP connections based on > specific protocols (e.g. enforce DNS timeout to a specific number > of seconds, or FIN-WAIT, etc.). In general, it MUST have > different kind of timeout values and thresholds to be used to > prevent idle established connections to saturate resources on both= > the device and the service that is defended. > > > So maybe "timeouts on UDP, TCP and other IP protocols" ... > > This is sometimes referred to as policy routing. Donald, I agree with your comment. > REQ GEN-6: > MUST be able to redirect specific traffic to a proxy server e.g. > for HTTP/S protocols. > > But by saying "redirect" in theory a FW could meet that requirement by j= ust rewriting the MAC and replaying the packet. Not really routing a layer= 2 > redirect. Which did you mean or did you mean both? They should divert the traffic to a proxy. They should take the traffic, s= end it to an inspection engine, receive it back and forward it. It should = be completely transparent to the users. Users won't even require setting u= p a proxy in their browser. JunOS does it with WebSense, although it could be any kind of HTTP filter = in theory; with Cisco, it is not possible with an ASA, so you create two V= RFs and forward the traffic through an "in" and "out" ports and have an in= line filter connected; with the Microsoft TMG firewall, it's point and cli= ck :-) > REQ SPC-1 and 4 are the same. > Well spotted Donald. > It says here that we want to match icmpv6 errors to tcp and udp you shou= ld include "and other ipv6 protocols" and won't this bring on new icmp bli= nd > tcp reset issues? I agree on the principle; could you elaborate more on the issue this would= bring? > Split tunneling is almost always a concern on the client side not on fir= ewalls. > > REQ VPN-5: > MUST be able to disable or enable split-tunnelling feature on VPN > as required. Split tunneling is generally enabled by policy on the concentrator. I agre= e that technically the client could not obey... but it is nevertheless con= figured as a policy, and the clients and server would agree on a policy du= ring handshake. > I have never seen that applied to a firewall but can't say it couldn't b= e:) In general you allow in a vpn remote access client and DON'T want them= also > connected directly to the internet as that punches a whole in your firew= all (potentially anyways). Daniel, in an enterprise environment, VPN behavior is controlled centrally= . It is a required feature and pretty normal on IPv4. Of course, if you ju= st use some kind of open source VPN client and there is no cumbersome prop= rietary set up server side, you can have your client doing what it wants; = however normally the administrators will try to avoid that. The reason is not just because of punching holes in the firewall (although= that is correct), but more simply company compliance, necessity to have a= ll of the traffic filtered, and so on. Read like "prevent stupid to be stu= pid" as much as possible. > This: > REQ VPN-6: > MUST be able to work indifferently on IPv4 and IPv6, and also > offer both protocol in dual-stack in the same VPN connection. > > Should be this: > REQ VPN-6: > MUST be able to transit IPv4 and IPv6 packets providing full parit= y for services, and also > offer both protocols in dual-stack in the same VPN connection. > > I am thinking tunnel instead of connection but do not feel strongly abou= t it. > The use of indifferently isn't technically wrong but isn't the common us= e of that word. I do not mind either formulation. I feel this is a good contribution. > This is really ip stack specific attacks (not really os specific). > I have run non-native ip stacks on some OSes in the past (win3.1...) > > REQ DoS-1: > MUST be able to protect against OS-specific attacks: nuke, ping- > of-death (NOTE: this list should be expanded, and references > added). > > And all of those pretty much died out. Having said that in there isn't b= ad. > Here are a few more of those ip stack attacks. > > ICMP Fragments based attacks (this would include POD) and you include fr= agement based attacks in the next requirement. > Smurf Attack > Xmas Tree Attack > LAND Attack > Teardrop Attack > > This one probably needs some expansion. Maybe we could simply reference rfc4949 ("Internet Security Glossary, Vers= ion 2"). The only one missing is the Xmas Tree Attack/scan. I would also add generic sweeps, scans, and so on. Also, probably mentioni= ng that the firewall should be able to understand the meaning of a specifi= c IP option in a certain context and act accordingly (that would cover Xma= s Tree attacks). If you look from page 906 of this guide: http://www.juniper.net/techpubs/e= n_US/junos10.4/information-products/topic-collections/security/software-al= l/security/junos-security-swconfig-security.pdf you have a very detailed l= ist of reconnaissance attacks that can be perpetrated just setting up the = right IP options. As a minimum, there should be the possibility to sanitiz= e obsolete options - I have seen some firewalls require to enable a NIPS l= icense/card to be able to do it. > REQ DoS-4: > MUST be able to protect against TCP resource exhaustion attacks: > zero-window attacks, SYN-floods, etc. (see e.g. [CPNI-TCP]) > So for syn flooding do we want proxied tcp cookies, or simple tcp rateli= miting and do you expect grey, white and blacklisting to be done based on = some form > of authentication (completes the hand shake or gets the cookie= right ...)? > Or can any or all methods be treated the same? > Wrong RFC :) > REQ DoS-8: > =20 MUST be able to participate to a blackhole/sync hole routing > infrastructure as per [RFC5635]. > > You probably want this one https://tools.ietf.org/rfc/rfc3882.txt as it = talks about sinkholing (and it is sink hole not sync hole :) The other one= is about > doing urpf with BHF and being able to do src based BHF. RFC5635 is an expansion to 3882. The latter is old, and it can only "black= hole" the DoS to an RFC1918 (private) address. With the former, you can re= direct the traffic to a destination where the traffic can be scrubbed. (Yo= u are right about the "sink" thing - sorry). Maybe better references could be https://tools.ietf.org/html/draft-simpson= -idr-flowspec-redirect-02 and https://tools.ietf.org/html/rfc5575 which sp= ecifies a new kind of BGP NLRI called "Flowspec", which allows this scrubb= ing to happen. > > Also we may need to define what "participate" means. I generally don't e= xpect firewalls (FW) to talk bgp and BHF is generally done with BGP. > First of all, firewalls can do BGP since ages.=20On JunOS, routers and fir= ewalls have the same software; CheckPoint can also do all of the routing p= rotocols. Cisco firewalls can only do "BGP stub" routing with the purpose = of route injection. In many situations, firewalls are required to speak BGP; the classical ins= tance is to manage route leakages (e.g. they do OSPF on an internal interf= ace, and inject matching BGP rules in the external interface). Therefore, = they are required to understand BGP, and it is even more important when it= 's a security feature. In the past, it was considered inappropriate to have a firewall work as a = router, since they lack the fast forwarding plane that allowed a router to= crunch packets without doing deep inspection. Today, there is a general c= onvergence on both hardware and software of both router and firewalls, mor= e and more we are moving towards virtualization (and SDNs) and there is al= so a differentiation between Internal and External BGP, so that companies = with huge networks actually use BGP as an internal routing protocol. Some companies like Cisco still think as BGP as a "service provider" proto= col, but that is mostly a marketing issue (in fact they actually license t= heir useless BGP stub implementation in their PIX/ASA), or a difficulties = in having the same software base for routers and firewalls. The majority o= f the other companies have overcome this already. > > I will stop here for now to allow you to think about it and the next sec= tion is going to take more thought. > [...] Thank you very much for your useful contribution and keep on doing it! Marco Marco Ermini - PhD CISSP CISA CEH ITIL MCP Senior IT Security & Compliance Analyst | Compliance Europe ResMed Germany Inc. Gesch=E4ftsf=FChrer: Frank Rebbert, Eric Paffrath, Michael Taube Sitz der Gesellschaft: M=FCnchen Registergericht: M=FCnchen, HRB 156206 ---------------------------------------------------------------------- Warning: Copyright ResMed. Where the contents of this email and/or attac= hment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between R= esMed and the intended recipient. This communication is confidential and = may contain legally privileged information. By the use of email over the = Internet or other communication systems, ResMed is not waiving either conf= identiality of, or legal privilege in, the content of the email and of any= attachments. If the recipient of this message is not the intended addres= see, please call ResMed immediately on 1 (800) 424-0737 USA. ---------------------------------------------------------------------- From nobody Wed Feb 19 07:36: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 DBF771A032C for ; Wed, 19 Feb 2014 07:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 wz9thlcqPfj9 for ; Wed, 19 Feb 2014 07:36:00 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4081A0206 for ; Wed, 19 Feb 2014 07:36:00 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id uy17so9664249igb.4 for ; Wed, 19 Feb 2014 07:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=MBlAowKuOVNg/qwDpnUfHvdyGjHh+K14xVUDkL7hc/k=; b=GZBiS2ZLzbjQOU7FPcv1XcErropRhWvq3bLuh1bqEtKSqIpXMHPILx4DdyJyqEeLa3 ORqCOi5EyLdkZgQNtgEuSGC3YY2tEWY1CHCAgEpMJgqXVEvGPBn+TIa01gtvaVkEGoZf Dwii3V3hGyjHNWsgHyyHWEXZbdJ15Eppkk9W0tGFkJnE4v4d5slTNW74e+6XmL65ug42 H23+1MV5DBvrTEuoXRgXYuLmkCGQ6Z9SHs+MsNnTNdVmr+JlNL6oww+IQmCi3PeQaWR6 fLIqcj4f8rfPjQpPv9yDBCbiKl1kT/bc/Tx0R7tHRTLoHdlCzl4aOmvyrflaBQtCQpbK s8kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=MBlAowKuOVNg/qwDpnUfHvdyGjHh+K14xVUDkL7hc/k=; b=M/MZ3zWQW45XKepNvc59g1XTtC7KG1o3yWr4NLbOfI+YEIHWXvzKCDxogRmrVZiWi1 GWF5vQbnmru7e1Ytyx62bqjZP57Id+FGX8B21XgE1cUvMxTEOrd7gMhgEWBHlv8tIqZC 0D/FvFK2o1NbWgwx052xUsP5ePXpNfLVOV7dRE7XU9hSbzYIOEf42nsTsCC/pbneKoVm dF4EvWI5vfBXdJGwIcLqx/JSIq2Gz3lc+Kz7lHnLauWBbHAbJlShVltU532gPbrU9wY1 6eHvCXN5lVegs9w5JpcH9drctRdSMBp9y/lzoU4BFNR7AuA633nYJXtDNwEVSguYSwf8 OLgg== X-Gm-Message-State: ALoCoQkB8VKr/RTNjuYAXt7ohgt+2sG1ryEXOHnIq7RjskbEtdKWVMpdBzzLeb3eJ+BE8ZCfNQOT2s03V7fdHuQ0l9Bkea6rhn2QQKNH7Dsk7I0X9Oa05KfVD/rTFJtr99miXqEzvDIsJ/7d1ONrnq6MNwR27QTEQ2ooGnyuZum697+OYYGYP7OjjFpoNqaiAJQazMMy+FK4 X-Received: by 10.50.97.98 with SMTP id dz2mr1876592igb.34.1392824156783; Wed, 19 Feb 2014 07:35:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.81.18 with HTTP; Wed, 19 Feb 2014 07:35:36 -0800 (PST) From: KK Date: Wed, 19 Feb 2014 07:35:36 -0800 Message-ID: To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=047d7b111a45199b1f04f2c42562 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/QRh5pyfdTpOvqiJq5XuFIJtk5_c Subject: [OPSEC] OPSEC WG meeting at IETF 89 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, 19 Feb 2014 15:36:02 -0000 --047d7b111a45199b1f04f2c42562 Content-Type: text/plain; charset=UTF-8 Dear OPSEC WG, The chairs have been watching the activity on the OPSEC WG mailing list and concluded that there are no open topics on the list that seem to be problematic in nature to the extent that a 1:1 discussion at IETF 89 is justified. As a direct result, we have requested the ADs to cancel the OPSEC slot at the IETF 89 meeting. We encourage the working group to continue discussing drafts on the mailing list. Kind Regards, KK and Gunter --047d7b111a45199b1f04f2c42562 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear OPSEC WG,

The chairs ha= ve been watching the activity on the OPSEC WG mailing list and concluded th= at there are no open topics on the list that seem to be problematic in natu= re to the extent that a 1:1 discussion at IETF 89 is justified. As a direct= result, we have requested the ADs to cancel the OPSEC slot at the IETF 89 = meeting.=C2=A0

We encourage the working group to continue discussing d= rafts on the mailing list.

Kind Regards,
KK and Gunter
--047d7b111a45199b1f04f2c42562-- From nobody Wed Feb 19 10:01:30 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 D401A1A022F for ; Wed, 19 Feb 2014 10:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 Or8Utcq1ug-4 for ; Wed, 19 Feb 2014 10:01:26 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 546681A00B8 for ; Wed, 19 Feb 2014 10:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1590; q=dns/txt; s=iport; t=1392832883; x=1394042483; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iAOIgHkTxMkGKC9AbelnsO/bR6uXurivZoG4R8ckE+o=; b=NwERhWbxVHzGrKH8t4VYD4PYlMgeoqKKtT2VeVGqiGgqFH6PMwkETzsQ pCbADq1kacHgvJBw/r2zW1ejzmVc7tKuGM0mA5IleHPYzs9oMWr4HkuZH VYnOrf2n99ILuLisy9yElnQrJubbKwAx9e5xTsIMTAvBloSTE2KnwrXW+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADbxBFOtJXG8/2dsb2JhbABZgwY4V798gRoWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiHfQ3NfheOAhEBHzgGgx6BFASZYpBygy2BcTk X-IronPort-AV: E=Sophos;i="4.97,507,1389744000"; d="scan'208";a="305094216" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 19 Feb 2014 18:01:00 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1JI10B5015060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 18:01:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 12:01:00 -0600 From: "Panos Kampanakis (pkampana)" To: Fernando Gont , "'opsec@ietf.org'" Thread-Topic: [OPSEC] IPv6 firewalls reqs: Rationale Thread-Index: AQHPLTDAvj1r/THBXEiKTajCtl2xjJq83GPg Date: Wed, 19 Feb 2014 18:00:58 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FADE6B6@xmb-rcd-x10.cisco.com> References: <53043C77.2060100@gont.com.ar> In-Reply-To: <53043C77.2060100@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.111] 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/399KfdvUckfw0nsn0S2qOSw5-B8 Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale 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, 19 Feb 2014 18:01:29 -0000 Hi Fernando, I am not sure that is within scope. http://tools.ietf.org/html/draft-ietf-o= psec-v6-04 covers many of the IPv6 issues and concerns that someone would n= eed to evaluate its vendors against.=20 Why don't we write a doc on IPv4, as CB mentioned? Why not one for applicat= ion firewalls? Why not one for security features at L2 all products should = support. I am not sure such mandates fall under OPSECs goals or are practic= al to write since requirements and concerns always change based on case and= network design. Just my thoughts. Panos -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Fernando Gont Sent: Wednesday, February 19, 2014 12:09 AM To: 'opsec@ietf.org' Subject: [OPSEC] IPv6 firewalls reqs: Rationale Folks, As noted in my previous email, this is a request to discuss the first item = listed in my previous email: 1) Agree on a rationale to write this spec. For example, one possible rationale is "aim at providing parity of features= with IPv4". Another one could be that "should should aim a little higher".= For example, in the light of draft-farrell-perpass-attack we may aim at re= quiring some privacy features that might not be that common in IPv4 firewal= ls. Thoughts? Yours, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809= 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From nobody Wed Feb 19 10:43: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 4AA651A014C for ; Wed, 19 Feb 2014 10:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q7YYFKPP-_y for ; Wed, 19 Feb 2014 10:42:56 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id CD3CC1A00FB for ; Wed, 19 Feb 2014 10:42:55 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s1JIgkJw005709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Feb 2014 12:42:47 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9EEF01E0077; Wed, 19 Feb 2014 11:42:41 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id F390B1E007E; Wed, 19 Feb 2014 11:42:40 -0700 (MST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1JIge3A011876; Wed, 19 Feb 2014 12:42:40 -0600 (CST) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1JIgdff011859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 12:42:40 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0158.001; Wed, 19 Feb 2014 11:42:39 -0700 From: "Smith, Donald" To: Cb B , Fernando Gont Thread-Topic: [OPSEC] IPv6 firewalls reqs: Rationale Thread-Index: AQHPLTC+DEox0XMbX0KXNRLWW0ihVZq8fqaAgABnhvA= Date: Wed, 19 Feb 2014 18:42:38 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D123C1960@PDDCWMBXEX503.ctl.intranet> References: <53043C77.2060100@gont.com.ar>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/wfqRi1ylv4JenZYNRHca82FMSQM Cc: "opsec@ietf.org" Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale 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, 19 Feb 2014 18:42:59 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com > From: OPSEC [opsec-bounces@ietf.org] on behalf of Cb B [cb.list6@gm= ail.com] > Sent: Tuesday, February 18, 2014 10:17 PM > To: Fernando Gont > Cc: opsec@ietf.org > Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale > > > On Tue, Feb 18, 2014 at 9:09 PM, Fernando Gont wrote: > > Folks, > > > > As noted in my previous email, this is a request to discuss the f= irst > > item listed in my previous email: > > > > 1) Agree on a rationale to write this spec. > > > > For example, one possible rationale is "aim at providing parity o= f > > features with IPv4". Another one could be that "should should aim= a > > little higher". For example, in the light of > > draft-farrell-perpass-attack we may aim at requiring some privacy > > features that might not be that common in IPv4 firewalls. > > > > > > Thoughts? At least parity but given what I have read so far I would say a bit higher. > > > > > Why would you look to a middle box to add privacy or any feature at= all? That is a common expectation of middle boxes. That is why most people have = firewalls, IPSes etc... > > AFAIK, "firewalls" are in a unique position to be a single point o= f > failure for confidentiality , availability , and integrit. Absolutely agree. But only when incorrectly managed. An UNMANAGED or user managed device is frequently ignored and frequently im= properly managed leaving it open to all kinds of attacks. > > data point - https://isc.sans.edu/forums/diary/Linksys+Worm+TheMoon= +Summary+What+we+know+so+far/17633 Not a firewall:) > > Is there an IPv4 document that is similar in nature at the IETF? Tons :) But most were written w/o specifying ipv4. They were generally writ= ten from a ipv4 pov. http://www.ietf.org/rfc/rfc2979.txt http://www.ietf.org/rfc/rfc3093.txt http://tools.ietf.org/search/rfc3511 There is even a IPv6 "not quite firewall" rfc. https://tools.ietf.org/html/rfc6092 > Or > is spec'ing firewalls a novel thing that for some reason is only > relevant to IPv6 I think this work is valid and valuable but am not aware of a direct correl= ation in IPv4 rfcs. Many rfcs reference firewalls, talk to some of the issu= es etc... but I have never read a rfc for IPv4 that matches what Gont and c= ompany are trying to do here. > > CB > > > > Yours, > > -- > > Fernando Gont > > e-mail: fernando@gont.com.ar || fgont@si6networks.com > > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF= 1 > > > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >= From nobody Wed Feb 19 13:37:40 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 D13FE1A0226 for ; Wed, 19 Feb 2014 13:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 GctI9v_AqBin for ; Wed, 19 Feb 2014 13:37:33 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id B38F61A027A for ; Wed, 19 Feb 2014 13:37:33 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5BAA3A1; Wed, 19 Feb 2014 22:37:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 548089A; Wed, 19 Feb 2014 22:37:29 +0100 (CET) Date: Wed, 19 Feb 2014 22:37:29 +0100 (CET) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <53043C77.2060100@gont.com.ar> Message-ID: References: <53043C77.2060100@gont.com.ar> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/KcZV--n251REDIPBRHd582E1DDo Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale 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, 19 Feb 2014 21:37:37 -0000 On Wed, 19 Feb 2014, Fernando Gont wrote: > Thoughts? When I read this document, it feels very much like requirements for an enterprise style firewall. This is not defined in the document, but it just says "firewall". I believe the requirements for a host based firewall, a residential CPE based firewall, and a full-blown enterprise firewall are quite different (considering the amount of complexity both in implementation and configuration required). So while I think this is a worthwhile document for enterprise firewalls, I think it should be clearly stated that this is the indended application. I read some ND validation requirements, which then reminded me that some people run firewalls in L2 mode, and some run in L3 mode. The requirements for these deployment scenarios are different, and the document should probably reflect that. Another requirement that would be beneficial, is that the firewall warns the operator if a policy is to be applied that violates RFC 4890, for instance paragraph 4.3.1. This would mean fewer firewall admins would hopefully filter essential ICMPv6 packets. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Feb 19 14:13:34 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 4A9631A0226 for ; Wed, 19 Feb 2014 14:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm-cipGAIuDg for ; Wed, 19 Feb 2014 14:13:28 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id F11391A0405 for ; Wed, 19 Feb 2014 14:13:27 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1JMDK8W002128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Feb 2014 15:13:20 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 020201E0085; Wed, 19 Feb 2014 16:13:15 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id DD5131E0077; Wed, 19 Feb 2014 16:13:14 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1JMDECl017773; Wed, 19 Feb 2014 16:13:14 -0600 (CST) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s1JMDDiq017748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 16:13:14 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0158.001; Wed, 19 Feb 2014 15:13:13 -0700 From: "Smith, Donald" To: Marco Ermini , "opsec@ietf.org" Thread-Topic: I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt Thread-Index: Ac8suawmwS2WEn1STli9AEMChgEPqAAQEsj4ABjGMiAAF9iHPQ== Date: Wed, 19 Feb 2014 22:13:12 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D123C1ADF@PDDCWMBXEX503.ctl.intranet> References: <38465846B6383D4A8688C0A13971900C469B76AA@GE2EML2K1003.corp.resmed.org> <68EFACB32CF4464298EA2779B058889D123C146D@PDDCWMBXEX503.ctl.intranet>, <38465846B6383D4A8688C0A13971900C469BA6EF@GE2EML2K1003.corp.resmed.org> In-Reply-To: <38465846B6383D4A8688C0A13971900C469BA6EF@GE2EML2K1003.corp.resmed.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/BDvx7TYXDof_XpqluDsc3l3sBok Cc: "fgont@si6networks.com" Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-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, 19 Feb 2014 22:13:33 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com > > > From: Smith, Donald [mailto:Donald.Smith@CenturyLink.com] > > Sent: Mittwoch, 19. Februar 2014 00:39 > > To: Marco Ermini; opsec@ietf.org > > Cc: fgont@si6networks.com; liushucheng@huawei.com > > Subject: RE: I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.= txt > > > [...] > > > > This is hard very hard I don't know of a single v4 firewall that= can do full proxies for all tcp applications. > > > > REQ GEN-3: > > MUST support full-proxy for the TCP [RFC0793] connections = (the > > handshake is validated on the firewall before reaching the= target > > system). > > I think what you want is proxies for common layer 7 protocols (l= ike http, ftp etc...) So maybe something like this: > > REQ GEN-3: > > Should support full-proxy for common TCP [RFC0793] layer s= even protocols. > > Hi Donald, > > Almost every IPv4 firewall today can do it. Even certain NIPS can = do it. I am pretty certain about all of the Juniper SRX series, including t= he Juniper IDP NIPS - they do full TCP handshake on behalf of the clients, = and CheckPoint can do that too I think. > > Cisco ASA do the same, they just call it "TCP Intercept and Limiti= ng Embryonic Connections" but practically they do TCP proxy, verify syn-coo= kies, rate limits, and so on. In that case I with draw my objection. But when I hear "tcp proxy" I genera= lly think of a http or ftp full tcp proxy. Can we call it something else or= add some clarification to that requirement? We probably should also mention syn-cookies ratelimiting and such other "ac= tions". > > It is pretty much a standard feature, so I see no reason to lower = the bar. > > Actually being that at the TCP level, I would expect it to work eq= ually for IPv4 and IPv6 easily. It should be low hanging fruits for firewal= l vendors. > > > > However if what you really want is TCP three ways proxied that i= s a little different. > > Would a tcp cookie implementation meet this requirement? Or do y= ou want the three way done with the firewall then thrown away and you add t= he src to > > a whitelist for the next attempt or replay one side or do you w= ant the fw to proxy the syn in, syn/ack out and ack back in? If so what is = the benefit if it > > keeps all the state in two places now (host and firewall)? > > The benefit of a TCP proxy is to normalize the connection, and as = you correctly mentioned, check if a source (which can be spoofed) has too m= any TCP-SYN without acting on TCP-ACK, or syn-cookies are not > set, or eve= n add a sequence randomization for the response port in place of an incapab= le host. > > Generally firewalls are even smart enough to avoid applying random= ization in certain cases (e.g., eBGP peers using MD5 checksum would be brok= en by randomization applied by the firewall, so it will not apply it > to= this kind of traffic. Or at least, the documentation says an administrator= should apply it in that case ;-)). > > Do not underestimate the power of these appliances, especially if = you haven't really used them in large scale environment. They are very effe= ctive and proven on IPv4 - the real problem is to have these features on >= IPv6 too; this is where vendors are lazy, mostly because of the usual adop= tion issues that generally affects IPv6 (vendors go where they can smell th= e money, unless "encouraged"). > > > > Time outs are generally used mostly for UDP not TCP. I don't obj= ect to having a timeout ability on tcp connections too but their primary us= e is UDP > > today in v4. > > Connection limits are pretty common on UDP too, and are necessary = to limit UDP DoS/DDoS. I do not think removing them for UDP is really a sma= rt move. I agree! > > Of course, the only kind of UDP connection limits are maximum numb= er of simultaneous connections and per client connections; you cannot defin= e how many proxied connection can be done as this is a TCP-only feature. > > > > REQ GEN-4: > > MUST be able to enforce timeouts on TCP connections based = on > > specific protocols (e.g. enforce DNS timeout to a specific= number > > of seconds, or FIN-WAIT, etc.). In general, it MUST have > > different kind of timeout values and thresholds to be used= to > > prevent idle established connections to saturate resources= on both > > the device and the service that is defended. > > > > > > So maybe "timeouts on UDP, TCP and other IP protocols" ... > > > > This is sometimes referred to as policy routing. > > Donald, I agree with your comment. > > > > REQ GEN-6: > > MUST be able to redirect specific traffic to a proxy serve= r e.g. > > for HTTP/S protocols. > > > > But by saying "redirect" in theory a FW could meet that requirem= ent by just rewriting the MAC and replaying the packet. Not really routing = a layer 2 > > redirect. Which did you mean or did you mean both? > > They should divert the traffic to a proxy. They should take the tr= affic, send it to an inspection engine, receive it back and forward it. It = should be completely transparent to the users. Users won't even require s= ettingup a proxy in their browser. > Understood. My question is around layer 2 redirects vs layer 3 policy routi= ng. I would rather have policy routing as it is more flexible you don't hav= e to have the proxy on the same collision domain as you would with a layer = 2 redirect. So would a layer 2 redirect count as compliance? > JunOS does it with WebSense, although it could be any kind of HTTP= filter in theory; with Cisco, it is not possible with an ASA, so you creat= e two VRFs and forward the traffic through an "in" and "out" ports and have= an inline filter connected; with the Microsoft TMG firewall, it's point an= d click :-) > > > > REQ SPC-1 and 4 are the same. > > > > Well spotted Donald. > > > > It says here that we want to match icmpv6 errors to tcp and udp = you should include "and other ipv6 protocols" and won't this bring on new i= cmp blind > > tcp reset issues? > > I agree on the principle; could you elaborate more on the issue th= is would bring? This http://tools.ietf.org/html/rfc5927 > > > > Split tunneling is almost always a concern on the client side no= t on firewalls. > > > > REQ VPN-5: > > MUST be able to disable or enable split-tunnelling feature= on VPN > > as required. > > Split tunneling is generally enabled by policy on the concentrator= . I agree that technically the client could not obey... but it is neverthel= ess configured as a policy, and the clients and server would agree on a pol= icy during handshake. > > > I have never seen that applied to a firewall but can't say it co= uldn't be:) In general you allow in a vpn remote access client and DON'T wa= nt them also > > connected directly to the internet as that punches a whole in yo= ur firewall (potentially anyways). > > Daniel, in an enterprise environment, VPN behavior is controlled c= entrally. It is a required feature and pretty normal on IPv4. Of course, if= you just use some kind of open source VPN client and there is no cumbersom= e proprietary set up server side, you can have your client doing what it wa= nts; however normally the administrators will try to avoid that. > > The reason is not just because of punching holes in the firewall (= although that is correct), but more simply company compliance, necessity to= have all of the traffic filtered, and so on. Read like "prevent stupid to = be stupid" as much as possible. > Right so it still sounds like a client management issue not a firewall vpn = issue? > > > This: > > REQ VPN-6: > > MUST be able to work indifferently on IPv4 and IPv6, and a= lso > > offer both protocol in dual-stack in the same VPN connecti= on. > > > > Should be this: > > REQ VPN-6: > > MUST be able to transit IPv4 and IPv6 packets providing fu= ll parity for services, and also > > offer both protocols in dual-stack in the same VPN connect= ion. > > > > I am thinking tunnel instead of connection but do not feel stron= gly about it. > > The use of indifferently isn't technically wrong but isn't the c= ommon use of that word. > > I do not mind either formulation. I feel this is a good contributi= on. > > > > This is really ip stack specific attacks (not really os specific= ). > > I have run non-native ip stacks on some OSes in the past (win3.1= ...) > > > > REQ DoS-1: > > MUST be able to protect against OS-specific attacks: nuke,= ping- > > of-death (NOTE: this list should be expanded, and referenc= es > > added). > > > > And all of those pretty much died out. Having said that in there= isn't bad. > > Here are a few more of those ip stack attacks. > > > > ICMP Fragments based attacks (this would include POD) and you in= clude fragement based attacks in the next requirement. > > Smurf Attack > > Xmas Tree Attack > > LAND Attack > > Teardrop Attack > > > > This one probably needs some expansion. > > Maybe we could simply reference rfc4949 ("Internet Security Glossa= ry, Version 2"). The only one missing is the Xmas Tree Attack/scan. > > I would also add generic sweeps, scans, and so on. Also, probably = mentioning that the firewall should be able to understand the meaning of a = specific IP option in a certain context and act accordingly (that would cov= er Xmas Tree attacks). > > If you look from page 906 of this guide: http://www.juniper.net/t= echpubs/en_US/junos10.4/information-products/topic-collections/security/sof= tware-all/security/junos-security-swconfig-security.pdf you have a very det= ailed list of reconnaissance attacks that can be perpetrated just setting u= p the right IP options. As a minimum, there should be the possibility to sa= nitize obsolete options - I have seen some firewalls require to enable a NI= PS license/card to be able to do it. > > > > REQ DoS-4: > > MUST be able to protect against TCP resource exhaustion at= tacks: > > zero-window attacks, SYN-floods, etc. (see e.g. [CPNI-TCP]= ) > > > So for syn flooding do we want proxied tcp cookies, or simple tc= p ratelimiting and do you expect grey, white and blacklisting to be done ba= sed on some form > of authentication (completes the hand shake or gets the = cookie right ...)? > > Or can any or all methods be treated the same? > > > > > > Wrong RFC :) > > REQ DoS-8: > > MUST be able to participate to a blackhole/sync hole routi= ng > > infrastructure as per [RFC5635]. > > > > You probably want this one https://tools.ietf.org/rfc/rfc3882.t= xt as it talks about sinkholing (and it is sink hole not sync hole :) The o= ther one is about > > doing urpf with BHF and being able to do src based BHF. > > RFC5635 is an expansion to 3882. The latter is old, and it can onl= y "blackhole" the DoS to an RFC1918 (private) address. With the former, you= can redirect the traffic to a > destination where the traffic can be scrub= bed. (You are right about the "sink" thing - sorry). No problem about sync vs sink:)=20 And I worked on 5635 and am listed as a contributor :) It really is about combining urpf with BHF to get src based BHF. It also al= lows for other ips addresses to be used but there is no mention of sinkholi= ng it it. rfc3882 is the rfc that described the sinkholing tunnel approach. So maybe you want both in there:) > > Maybe better references could be https://tools.ietf.org/html/draf= t-simpson-idr-flowspec-redirect-02 and https://tools.ietf.org/html/rfc5575= which specifies a new kind of BGP NLRI called "Flowspec", which allows thi= s scrubbing to happen. > Yes that would be another good one to list. > > > > Also we may need to define what "participate" means. I generally= don't expect firewalls (FW) to talk bgp and BHF is generally done with BGP= . > > > > First of all, firewalls can do BGP since ages. On JunOS, routers a= nd firewalls have the same software; CheckPoint can also do all of the rout= ing protocols. Cisco firewalls can only do "BGP stub" routing with the purp= ose of route injection. > > In many situations, firewalls are required to speak BGP; the class= ical instance is to manage route leakages (e.g. they do OSPF on an internal= interface, and inject matching > BGP rules in the external interface). Th= erefore, they are required to understand BGP, and it is even more important= when it's a security feature. > I have worked on firewalls that did BGP. Generally they don't do it well. T= he issue being your asking a firewall team to test the bgp implementation. = Router vendors have HUGE bgp testing plans and tools. I don't object to the= firewall doing BGP but would like to see them test it a lot better. I do s= till think it is probably better to use your routers for stuff like this bu= t if firewall vendors supported it WELL I would reconsider. > In the past, it was considered inappropriate to have a firewall wo= rk as a router, since they lack the fast forwarding plane that allowed a ro= uter to crunch packets without doing deep inspection. Today, there is a gen= eral convergence on both hardware and software of both router and firewalls= , more and more we are moving towards virtualization (and SDNs) and there i= s also a differentiation between Internal and External BGP, so that compani= es with huge networks actually use BGP as an internal routing protocol. > > Some companies like Cisco still think as BGP as a "service provide= r" protocol, but that is mostly a marketing issue (in fact they actually li= cense their useless BGP stub implementation in their PIX/ASA), or a difficu= lties in having the same software base for routers and firewalls. The major= ity of the other companies have overcome this already. > > > > > I will stop here for now to allow you to think about it and the = next section is going to take more thought. > > > [...] > > Thank you very much for your useful contribution and keep on doing= it! Thank you for the quick response! > > > Marco > > Marco Ermini - PhD CISSP CISA CEH ITIL MCP > Senior IT Security & Compliance Analyst | Compliance Europe > > ResMed Germany Inc. > Gesch=E4ftsf=FChrer: Frank Rebbert, Eric Paffrath, Michael Taube > Sitz der Gesellschaft: M=FCnchen > Registergericht: M=FCnchen, HRB 156206 > > -----------------------------------------------------------------= ----- > Warning: Copyright ResMed. Where the contents of this email and/o= r attachment includes materials prepared by ResMed, the use of those > materials is subject exclusively to the conditions of engagement b= etween ResMed and the intended recipient. This communication is confidenti= al and may contain legally privileged information. By the use of email ove= r the Internet or other communication systems, ResMed is not waiving either= confidentiality of, or legal privilege in, the content of the email and of= any attachments. If the recipient of this message is not the intended add= ressee, please call ResMed immediately on 1 (800) 424-0737 USA. > -----------------------------------------------------------------= ----- > >= From nobody Wed Feb 19 14:17:58 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 DCB681A025A for ; Wed, 19 Feb 2014 14:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew0Nd-UQ38uX for ; Wed, 19 Feb 2014 14:17:52 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 44E821A0226 for ; Wed, 19 Feb 2014 14:17:52 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.103]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WGFSc-0005Eb-Hf; Wed, 19 Feb 2014 23:17:46 +0100 Message-ID: <53052D7B.6020103@gont.com.ar> Date: Wed, 19 Feb 2014 19:17:31 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <53043C77.2060100@gont.com.ar> 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/Xhs2nnIEGTAfWwED92J20-8s4-A Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale 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, 19 Feb 2014 22:17:55 -0000 Hi, Mikael, Thanks so much for your feedback! Please find my comments in-line... On 02/19/2014 06:37 PM, Mikael Abrahamsson wrote: > > When I read this document, it feels very much like requirements for an > enterprise style firewall. This is not defined in the document, but it > just says "firewall". I believe the requirements for a host based > firewall, a residential CPE based firewall, and a full-blown enterprise > firewall are quite different (considering the amount of complexity both > in implementation and configuration required). > > So while I think this is a worthwhile document for enterprise firewalls, > I think it should be clearly stated that this is the indended application. This is a really good point. Thanks for raising it! We will try to make this point clear in the next rev. > I read some ND validation requirements, which then reminded me that some > people run firewalls in L2 mode, and some run in L3 mode. The > requirements for these deployment scenarios are different, and the > document should probably reflect that. Agreed. > Another requirement that would be beneficial, is that the firewall warns > the operator if a policy is to be applied that violates RFC 4890, for > instance paragraph 4.3.1. This would mean fewer firewall admins would > hopefully filter essential ICMPv6 packets. Not sure if compliance of firewall rules with the whole RFC4890 might be "too much". For instance, if you filter ND packets, you'll find it very easily. Probably the one that'd be worth warning is filtering ICMPv6 PTB.... Thanks so much! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Mon Feb 24 03:03:35 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 983C61A07E2 for ; Mon, 24 Feb 2014 03:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.348 X-Spam-Level: X-Spam-Status: No, score=-12.348 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 6aiEWxA7ZbMS for ; Mon, 24 Feb 2014 03:03:30 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D09021A07DB for ; Mon, 24 Feb 2014 03:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1585; q=dns/txt; s=iport; t=1393239809; x=1394449409; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=++18yY6h9YebnfSG4FfWMNNmi69wMMUWhrfnGSe8H1w=; b=KsREIs9nL6RBJNj7iuh0Vz/dThWXxMex9/dZeIV8m9+9GfnMe8HYMAhE L7l1OGa6eSUTXndC/eJVYH3JvZOJFvyPEZNkOQy66IOqOP5N8TBt67OoA WFEIxolsNfcClp06B/IXLi9xsjFat/4eER+AMMwHPfHmXChJbzexsDjKJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAK4lC1OtJXG//2dsb2JhbABZgwY7V8BogRQWdIIlAQEBBAEBATcrCRcEAgEIEQQBAQsUCQcnCxQJCAIEARIIh30NxhITBI4CEQEfOAaDHoEUBKpbgy2BcTk X-IronPort-AV: E=Sophos;i="4.97,534,1389744000"; d="scan'208";a="306054744" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 24 Feb 2014 11:03:29 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1OB3Tpj032049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 11:03:29 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.200]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 05:03:29 -0600 From: "Gunter Van de Velde (gvandeve)" To: Fernando Gont , "'opsec@ietf.org'" Thread-Topic: [OPSEC] IPv6 firewalls reqs: Rationale Thread-Index: AQHPLTDA6xGSfz2dQEWbcGI1q6VjvprERCkg Date: Mon, 24 Feb 2014 11:03:28 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B241135ADD4@xmb-aln-x12.cisco.com> References: <53043C77.2060100@gont.com.ar> In-Reply-To: <53043C77.2060100@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.165.92] 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/Do55VMgVQbtn_WvVDqUzrXGDBkM Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale 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, 24 Feb 2014 11:03:31 -0000 Hi Fernando, Firewall technology is implemented based upon usage case and may be very di= fferently for each implementation (centralized, distributed, L3-only, L4-on= ly, L3-L4, Session, Services, Applications,=20 etc...)... loads of interpretations on what is the most secure and scalable= method for each usage-case. If a Firewall document would exist, then I believe it must document both IP= v4 and IPv6 technology.=20 You should document all usage cases and agreement on the security risks imp= osed, together with a balanced view on how to address those risks.=20 G/ -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 19 February 2014 06:09 To: 'opsec@ietf.org' Subject: [OPSEC] IPv6 firewalls reqs: Rationale Folks, As noted in my previous email, this is a request to discuss the first item = listed in my previous email: 1) Agree on a rationale to write this spec. For example, one possible rationale is "aim at providing parity of features= with IPv4". Another one could be that "should should aim a little higher".= For example, in the light of draft-farrell-perpass-attack we may aim at re= quiring some privacy features that might not be that common in IPv4 firewal= ls. Thoughts? Yours, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809= 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From nobody Mon Feb 24 08:16: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 8DA861A0199 for ; Mon, 24 Feb 2014 08:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 UVrvx_yvJlNx for ; Mon, 24 Feb 2014 08:16:03 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 63A261A016C for ; Mon, 24 Feb 2014 08:16:03 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WHyCE-0003GN-Ue; Mon, 24 Feb 2014 17:15:59 +0100 Message-ID: <530B7031.8070506@si6networks.com> Date: Mon, 24 Feb 2014 13:15:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" , Fernando Gont , "'opsec@ietf.org'" References: <53043C77.2060100@gont.com.ar> <67832B1175062E48926BF3CB27C49B241135ADD4@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B241135ADD4@xmb-aln-x12.cisco.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/dY_mp9mzpoYgNkyLb3v79uRmpwA Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale 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, 24 Feb 2014 16:16:06 -0000 Hi, Gunter, Thanks so much for your feedback! Please find my coments inline... On 02/24/2014 08:03 AM, Gunter Van de Velde (gvandeve) wrote: > > Firewall technology is implemented based upon usage case and may be > very differently for each implementation (centralized, distributed, > L3-only, L4-only, L3-L4, Session, Services, Applications, etc...)... > loads of interpretations on what is the most secure and scalable > method for each usage-case. Base on the feedback so far, it seems there's agreement to narrow down what we mean by firewall. So far the idea is to work on "L3-and-up Enterprise IPv6 firewall". > If a Firewall document would exist, then I believe it must document > both IPv4 and IPv6 technology. Me, I have no issues with documenting IPv4 technology. Although some folks have argued "forget about IPv4". I'll ask this question in a separate thread to get more input. > You should document all usage cases > and agreement on the security risks imposed, together with a balanced > view on how to address those risks. This seems to be out-of-scope. i.e., our document is on capabilities as opposed to discussing security architectures (i.e., this document is not meant to answer "centralized or distributed?", "what's the most secure architecture", etc.). Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 24 08:33:46 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 E07E81A0177 for ; Mon, 24 Feb 2014 08:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, 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 mEEFRQ4XJLgC for ; Mon, 24 Feb 2014 08:33:44 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EC1801A01A7 for ; Mon, 24 Feb 2014 08:33:43 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4938740396 for ; Mon, 24 Feb 2014 11:33:43 -0500 (EST) Message-ID: <530B7466.2020102@viagenie.ca> Date: Mon, 24 Feb 2014 11:33:42 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: opsec@ietf.org References: <53043C77.2060100@gont.com.ar> <67832B1175062E48926BF3CB27C49B241135ADD4@xmb-aln-x12.cisco.com> <530B7031.8070506@si6networks.com> In-Reply-To: <530B7031.8070506@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/KWj-OS1adPDRwgj5y7zDBF_oUPo Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale 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, 24 Feb 2014 16:33:46 -0000 Le 2014-02-24 11:15, Fernando Gont a écrit : >> You should document all usage cases >> and agreement on the security risks imposed, together with a balanced >> view on how to address those risks. > > This seems to be out-of-scope. i.e., our document is on capabilities as > opposed to discussing security architectures (i.e., this document is not > meant to answer "centralized or distributed?", "what's the most secure > architecture", etc.). Agreed. Personally, I'd be interested in a document for firewall implementers explaining how to do it correctly and how to cause minimal breakage. A little bit like the BEHAVE guidance for NAT implementers. For firewalls, you could talk about how to use ICMP / TCP RST / drop correctly and what the tradeoffs are, how to do L2 stuff, how to do stateful stuff, how to inspect packets and deal with extensions headers intelligently, what are good timeout values, etc. The goal being to define a filtering function that behaves well on the Internet. Ideally that guidance would apply to all kinds of settings: ISP, enterprise, CPE, single host, etc. That RFC could be used as a baseline for RFPs as well. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Feb 24 13:44: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 4DAE51A0190 for ; Mon, 24 Feb 2014 13:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 ztOFfGFYDZs8 for ; Mon, 24 Feb 2014 13:44:51 -0800 (PST) Received: from mx04.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91EB1A0165 for ; Mon, 24 Feb 2014 13:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <530BBD4B.2060008@mykolab.com> Date: Mon, 24 Feb 2014 13:44:43 -0800 From: Paul Ferguson Organization: Clowns R. Mofos To: "Gunter Van de Velde (gvandeve)" References: <53043C77.2060100@gont.com.ar> <67832B1175062E48926BF3CB27C49B241135ADD4@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B241135ADD4@xmb-aln-x12.cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/8GmvGzClHaqQjgKAS0EEDPdeTeM Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fergdawgster@mykolab.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 21:44:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Gunter, I fully concur with you here. $.02, - - ferg On 2/24/2014 3:03 AM, Gunter Van de Velde (gvandeve) wrote: > Hi Fernando, > > Firewall technology is implemented based upon usage case and may be > very differently for each implementation (centralized, distributed, > L3-only, L4-only, L3-L4, Session, Services, Applications, > etc...)... loads of interpretations on what is the most secure and > scalable method for each usage-case. > > If a Firewall document would exist, then I believe it must document > both IPv4 and IPv6 technology. You should document all usage cases > and agreement on the security risks imposed, together with a > balanced view on how to address those risks. > > G/ > > -----Original Message----- From: OPSEC > [mailto:opsec-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 19 > February 2014 06:09 To: 'opsec@ietf.org' Subject: [OPSEC] IPv6 > firewalls reqs: Rationale > > Folks, > > As noted in my previous email, this is a request to discuss the > first item listed in my previous email: > > 1) Agree on a rationale to write this spec. > > For example, one possible rationale is "aim at providing parity of > features with IPv4". Another one could be that "should should aim a > little higher". For example, in the light of > draft-farrell-perpass-attack we may aim at requiring some privacy > features that might not be that common in IPv4 firewalls. > > > Thoughts? > > Yours, -- Fernando Gont e-mail: fernando@gont.com.ar || > fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 > 3945 96EE A9EF D076 FFF1 > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMLvUsACgkQKJasdVTchbKs9QEAuBdkLczR+2m7+zG9yKYnPxDT uVuS5w/O1mub2PpDyvgBAKi+Ml63g9/4IHsy9dtuPkeTioNqveMdE8vSoBBO8ZEK =T8Qp -----END PGP SIGNATURE-----