From nobody Sun Nov 2 16: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 D0B351ACE55 for ; Sun, 2 Nov 2014 16:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpHEumuaLQn3 for ; Sun, 2 Nov 2014 16:16:07 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAA61ACE56 for ; Sun, 2 Nov 2014 16:16:07 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id t59so4264173yho.8 for ; Sun, 02 Nov 2014 16:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Z5cdgdsM1EEte/HPzec4HJvumIHsKI6W6O3iVLFo4xs=; b=Ei915mJ1Up72hhQv8RkmZVmeLpRVtLbqIGEfkgQIrP5SM/8+6YqRneuIHJe/2B8HQE 1R6XZ9/h6Y0ubc2yFrRiyj3W03+oCEORam0eIKP+tQtDzp9CPcIHNmAYgvCab1l+mlPJ INN+NcmQDthACoLOJR4AyFFi9scUQ00ytiFG2XokD8o9DU9PUMpZsUzbIZbgYKahw2RK epQnVp8TkqZbygHvPNYhjc9qlIPLoJyj0dY4/tTaaISQBFYYahUbD1KjUtQWDVCjsiFi IwHKlGxTLWFW6JSRlyoXnCULE37cWXlxOxhmKJdEfN7oPLjcVHGD3edsY1JjIF20B7Lt atIw== X-Received: by 10.170.84.66 with SMTP id b63mr38402141yka.69.1414973766936; Sun, 02 Nov 2014 16:16:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.136.212 with HTTP; Sun, 2 Nov 2014 16:15:46 -0800 (PST) From: KK Chittimaneni Date: Sun, 2 Nov 2014 16:15:46 -0800 Message-ID: To: opsec@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/j6M0wAwb0bn6K0HARUeuQZHx9PE Subject: [OPSEC] OPSEC meeting at IETF 91 canceled 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, 03 Nov 2014 00:16:09 -0000 Dear OPSEC WG, (Sorry, this email was supposed to go out last week, but sat in my drafts folder.) 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 91 is justified. As a direct result, we have requested the ADs to cancel the OPSEC slot at the IETF 91 meeting. We encourage the working group to continue discussing drafts on the mailing list. Kind Regards, KK and Gunter From nobody Fri Nov 14 15:49:14 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F751AD3EF; Fri, 14 Nov 2014 15:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvwwgrSJVFhX; Fri, 14 Nov 2014 15:48:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id C79381AD3E7; Fri, 14 Nov 2014 15:48:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 184C9181D18; Fri, 14 Nov 2014 15:47:38 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141114234738.184C9181D18@rfc-editor.org> Date: Fri, 14 Nov 2014 15:47:38 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/sWiWSLhlpY9tqhyAPbOw-8Zw8t0 Cc: opsec@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSEC] RFC 7404 on Using Only Link-Local Addressing inside an IPv6 Network X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 23:49:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7404 Title: Using Only Link-Local Addressing inside an IPv6 Network Author: M. Behringer, E. Vyncke Status: Informational Stream: IETF Date: November 2014 Mailbox: mbehring@cisco.com, evyncke@cisco.com Pages: 10 Characters: 24444 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsec-lla-only-11.txt URL: https://www.rfc-editor.org/rfc/rfc7404.txt 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 facilitate the decision process for a given network. 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://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 nobody Sun Nov 16 09:47:47 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9701A0386 for ; Sun, 16 Nov 2014 09:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.496 X-Spam-Level: X-Spam-Status: No, score=-107.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wzUrvIGYjVo for ; Sun, 16 Nov 2014 09:47:44 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 601581A0469 for ; Sun, 16 Nov 2014 09:47:44 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 35704181C70; Sun, 16 Nov 2014 09:47:00 -0800 (PST) To: mbehring@cisco.com, evyncke@cisco.com, bclaise@cisco.com, joelja@bogus.com, kk.chittimaneni@gmail.com, gunter@vandevelde.cc X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141116174700.35704181C70@rfc-editor.org> Date: Sun, 16 Nov 2014 09:47:00 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/N3b-CheAPz-TDgnm9NZuaaxlJV0 Cc: opsec@ietf.org, bortzmeyer@nic.fr, rfc-editor@rfc-editor.org Subject: [OPSEC] [Editorial Errata Reported] RFC7404 (4182) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 17:47:46 -0000 The following errata report has been submitted for RFC7404, "Using Only Link-Local Addressing inside an IPv6 Network". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7404&eid=4182 -------------------------------------- Type: Editorial Reported by: Stéphane Bortzmeyer Section: 2.1 Original Text ------------- Telnet [RFC0495] Corrected Text -------------- Telnet [RFC0854] Notes ----- Isn't STD 8 (RFC 854) the official telnet specification? Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7404 (draft-ietf-opsec-lla-only-11) -------------------------------------- Title : Using Only Link-Local Addressing inside an IPv6 Network Publication Date : November 2014 Author(s) : M. Behringer, E. Vyncke Category : INFORMATIONAL Source : Operational Security Capabilities for IP Network Infrastructure Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Sun Nov 16 14:10:59 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 1DCF61A1B63 for ; Sun, 16 Nov 2014 14:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 681VpqKM4Ui7 for ; Sun, 16 Nov 2014 14:10:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 0559A1A1B22 for ; Sun, 16 Nov 2014 14:10:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3EE1D18001B; Sun, 16 Nov 2014 14:09:50 -0800 (PST) To: mbehring@cisco.com, evyncke@cisco.com, bclaise@cisco.com, joelja@bogus.com, kk.chittimaneni@gmail.com, gunter@vandevelde.cc X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141116220950.3EE1D18001B@rfc-editor.org> Date: Sun, 16 Nov 2014 14:09:50 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/8KOpbSKsYaWDaQng3U84cNCBg-o Cc: opsec@ietf.org, rfc-editor@rfc-editor.org, andreas.cudok@datev.de Subject: [OPSEC] [Technical Errata Reported] RFC7404 (4183) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 22:10:38 -0000 The following errata report has been submitted for RFC7404, "Using Only Link-Local Addressing inside an IPv6 Network". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7404&eid=4183 -------------------------------------- Type: Technical Reported by: Andreas Cudok Section: 2.3 Original Text ------------- Hardware dependency: LLAs have usually been based on 64-bit Extended Unique Identifiers (EUI-64); hence, they change when the Message Authentication Code (MAC) address is changed. Corrected Text -------------- Hardware dependency: LLAs have usually been based on 64-bit Extended Unique Identifiers (EUI-64); hence, they change when the Media Access Control (MAC) address is changed. Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7404 (draft-ietf-opsec-lla-only-11) -------------------------------------- Title : Using Only Link-Local Addressing inside an IPv6 Network Publication Date : November 2014 Author(s) : M. Behringer, E. Vyncke Category : INFORMATIONAL Source : Operational Security Capabilities for IP Network Infrastructure Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Nov 17 03:23:53 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 0337D1A1A6C for ; Mon, 17 Nov 2014 03:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 V-YaIRJU7HVR for ; Mon, 17 Nov 2014 03:23:48 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F76E1A19E5 for ; Mon, 17 Nov 2014 03:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2674; q=dns/txt; s=iport; t=1416223429; x=1417433029; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=keJSBzhpcN2dQ/KzZzfGc6Sg1cK5IG+SOqsknuRBMmI=; b=jRtdP3+J32d2n2AiRtDn0oH388JMPKyPs41vHXLW4COJTqU8yQoDNrEW hAA1e1D4LNma1EgbpsQi3t+SO/n0T2LCGYgrwSiGvGDjhNq33Fce0RhyF 0shchTWURu6LLtaZFbbPup9Ej3f93fJkFMTo5APIUnpT9zJnQN0jRiE7k w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcIALDZaVStJV2d/2dsb2JhbABBGoJrI1VZBIMCyReHTgIceRYBAQEBAX2EAwEBBCMRRRACAQgaAiYCAgIwFRACBAENBYhBAQw4uwOVcwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLYwggyIYGweCd4FUBYZAiV+CKIwFgTSDVJFyghCBbG0BE4E0gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,402,1413244800"; d="scan'208";a="369667241" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 17 Nov 2014 11:23:48 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sAHBNlxM005694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Nov 2014 11:23:47 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 17 Nov 2014 05:23:47 -0600 From: "Eric Vyncke (evyncke)" To: RFC Errata System , "Michael Behringer (mbehring)" , "Benoit Claise (bclaise)" , "joelja@bogus.com" , "kk.chittimaneni@gmail.com" , "gunter@vandevelde.cc" Thread-Topic: [Technical Errata Reported] RFC7404 (4183) Thread-Index: AQHQAeonYhKFCcdl10yv+JBXQoLor5xlI2sA Date: Mon, 17 Nov 2014 11:23:47 +0000 Message-ID: References: <20141116220950.3EE1D18001B@rfc-editor.org> In-Reply-To: <20141116220950.3EE1D18001B@rfc-editor.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.185.69] Content-Type: text/plain; charset="utf-8" Content-ID: <1178C79C7D57554F91D19709686B56AB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/za6tI15-_Dsdn1ClA7XAqG5clt4 Cc: "opsec@ietf.org" , "andreas.cudok@datev.de" Subject: Re: [OPSEC] [Technical Errata Reported] RFC7404 (4183) 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, 17 Nov 2014 11:23:51 -0000 QW5kcmVhcw0KDQpUaGFua3MgZm9yIHRoZSByZXBvcnQuDQoNClRoZXJlIGlzIGluZGVlZCBhbiBl cnJvciBpbiBSRkMgNzQwNCBhYm91dCB0aGUgTUFDIGV4cGFuc2lvbi4gSSBjYW5ub3QNCmltYWdp bmUgaG93IHdlICh0aGUgYXV0aG9ycykgZmFpbGVkIHRvIHNwb3QgaXQuDQoNCi3DqXJpYw0KDQpP biAxNi8xMS8xNCAyMzowOSwgIlJGQyBFcnJhdGEgU3lzdGVtIiA8cmZjLWVkaXRvckByZmMtZWRp dG9yLm9yZz4gd3JvdGU6DQoNCj5UaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4g c3VibWl0dGVkIGZvciBSRkM3NDA0LA0KPiJVc2luZyBPbmx5IExpbmstTG9jYWwgQWRkcmVzc2lu ZyBpbnNpZGUgYW4gSVB2NiBOZXR3b3JrIi4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPllvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Og0K Pmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTc0MDQmZWlk PTQxODMNCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPlR5cGU6 IFRlY2huaWNhbA0KPlJlcG9ydGVkIGJ5OiBBbmRyZWFzIEN1ZG9rIDxhbmRyZWFzLmN1ZG9rQGRh dGV2LmRlPg0KPg0KPlNlY3Rpb246IDIuMw0KPg0KPk9yaWdpbmFsIFRleHQNCj4tLS0tLS0tLS0t LS0tDQo+SGFyZHdhcmUgZGVwZW5kZW5jeTogTExBcyBoYXZlIHVzdWFsbHkgYmVlbiBiYXNlZCBv biA2NC1iaXQgRXh0ZW5kZWQNCj5VbmlxdWUgSWRlbnRpZmllcnMgKEVVSS02NCk7IGhlbmNlLCB0 aGV5IGNoYW5nZSB3aGVuIHRoZSBNZXNzYWdlDQo+QXV0aGVudGljYXRpb24gQ29kZSAoTUFDKSBh ZGRyZXNzIGlzIGNoYW5nZWQuDQo+DQo+Q29ycmVjdGVkIFRleHQNCj4tLS0tLS0tLS0tLS0tLQ0K PkhhcmR3YXJlIGRlcGVuZGVuY3k6IExMQXMgaGF2ZSB1c3VhbGx5IGJlZW4gYmFzZWQgb24gNjQt Yml0IEV4dGVuZGVkDQo+VW5pcXVlIElkZW50aWZpZXJzIChFVUktNjQpOyBoZW5jZSwgdGhleSBj aGFuZ2Ugd2hlbiB0aGUgTWVkaWENCj5BY2Nlc3MgQ29udHJvbCAoTUFDKSBhZGRyZXNzIGlzIGNo YW5nZWQuDQo+DQo+Tm90ZXMNCj4tLS0tLQ0KPg0KPg0KPkluc3RydWN0aW9uczoNCj4tLS0tLS0t LS0tLS0tDQo+VGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4g SWYgbmVjZXNzYXJ5LCBwbGVhc2UNCj51c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVy IGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPnJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMg cmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAoSUVTRykNCj5jYW4gbG9nIGluIHRvIGNoYW5n ZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCj4NCj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPlJGQzc0MDQgKGRyYWZ0LWlldGYt b3BzZWMtbGxhLW9ubHktMTEpDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj5UaXRsZSAgICAgICAgICAgICAgIDogVXNpbmcgT25seSBMaW5rLUxvY2FsIEFkZHJlc3Np bmcgaW5zaWRlIGFuIElQdjYNCj5OZXR3b3JrDQo+UHVibGljYXRpb24gRGF0ZSAgICA6IE5vdmVt YmVyIDIwMTQNCj5BdXRob3IocykgICAgICAgICAgIDogTS4gQmVocmluZ2VyLCBFLiBWeW5ja2UN Cj5DYXRlZ29yeSAgICAgICAgICAgIDogSU5GT1JNQVRJT05BTA0KPlNvdXJjZSAgICAgICAgICAg ICAgOiBPcGVyYXRpb25hbCBTZWN1cml0eSBDYXBhYmlsaXRpZXMgZm9yIElQIE5ldHdvcmsNCj5J bmZyYXN0cnVjdHVyZQ0KPkFyZWEgICAgICAgICAgICAgICAgOiBPcGVyYXRpb25zIGFuZCBNYW5h Z2VtZW50DQo+U3RyZWFtICAgICAgICAgICAgICA6IElFVEYNCj5WZXJpZnlpbmcgUGFydHkgICAg IDogSUVTRw0KPg0KDQo= From nobody Mon Nov 17 11:52: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 241F61A8A06; Mon, 17 Nov 2014 11:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2CyqLDbU6VF; Mon, 17 Nov 2014 11:52:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7129B1A8994; Mon, 17 Nov 2014 11:52:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141117195209.16129.53872.idtracker@ietfa.amsl.com> Date: Mon, 17 Nov 2014 11:52:09 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/wJfh0dzjnxOZ6nGOWzTQS9Jn1Pc Cc: opsec@ietf.org Subject: [OPSEC] Last Call: (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best Current Practice X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 19:52:12 -0000 The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Nov 18 03:17:09 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 010661A01AA for ; Tue, 18 Nov 2014 03:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_DOSE=2.3, RP_MATCHES_RCVD=-0.594, 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 RotkAOvFVqGz for ; Tue, 18 Nov 2014 03:17:06 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D14751A01EA for ; Tue, 18 Nov 2014 03:17:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7C4DF87153B for ; Tue, 18 Nov 2014 12:17:02 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zghJQxlEyE3m for ; Tue, 18 Nov 2014 12:17:02 +0100 (CET) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 57D3E870056 for ; Tue, 18 Nov 2014 12:17:02 +0100 (CET) Message-ID: <546B2AAD.9060004@globis.net> Date: Tue, 18 Nov 2014 12:17:01 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: opsec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/gJw79yowWaU6nhwQZfAdIqHUMI8 Subject: Re: [OPSEC] OPSEC Digest, Vol 83, Issue 6 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 Nov 2014 11:17:08 -0000 > opsec-request@ietf.org > 17 November 2014 20:52 > Send OPSEC mailing list submissions to > opsec@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/opsec > or, via email, send a message with subject or body 'help' to > opsec-request@ietf.org > > You can reach the person managing the list at > opsec-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OPSEC digest..." > > > Today's Topics: > > 1. Last Call: > (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best > Current Practice (The IESG) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 17 Nov 2014 11:52:09 -0800 > From: The IESG > To: IETF-Announce > Cc: opsec@ietf.org > Subject: [OPSEC] Last Call: > (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best > Current Practice > Message-ID: <20141117195209.16129.53872.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="us-ascii" > > > The IESG has received a request from the Operational Security > Capabilities for IP Network Infrastructure WG (opsec) to consider the > following document: > - 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' > as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-12-01. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document specifies a mechanism for protecting hosts connected to > a switched network against rogue DHCPv6 servers. The aforementioned > mechanism is based on DHCPv6 packet-filtering at the layer-2 device > at which the packets are received. The aforementioned mechanism has > been widely deployed in IPv4 networks ('DHCP snooping'), and hence it > is desirable that similar functionality be provided for IPv6 > networks. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > > ------------------------------ > > End of OPSEC Digest, Vol 83, Issue 6 > ************************************ > ------------------------------------------------------------------------ I have read this draft and think it is useful. I also realise that this is very late in the day to make comments, but I have a number of issues. Substantive comment: /Before being deployed for production, the DHCPv6-Shield device MUST be explicitly configured with respect to which layer-2 ports are allowed to send DHCPv6 packets to DHCPv6 clients (i.e. DHCPv6-server messages)./ IMHO DHCPv6-Shield is an optional service. Suggest /Unless explicitly configured with one or more ports to which DHCPv6 servers or relays are attached, the DHCPv6-Shield service SHOULD NOT filter any packets./ I also think the terminology of "send" and "receive" is used in a rather confusing and inconsistent manner. Suggest using receive from the perspective of the switch performing the filtering. s/Only those layer-2 ports explicitly configured for such purpose will be allowed to send DHCPv6 packets to DHCPv6 clients/Only those layer-2 ports explicitly configured for such purpose will be allowed to receive DHCPv6 packets for forwarding to other ports where DHCPv6 clients may be connected/ [the L2 switch management process itself will also likely not see the DHCPv6 packet if it is performing ingress filtering, and DHCPv6 servers could theoretically send packets to each other] /on those ports that are not allowed to send DHCPv6 packets to DHCPv6 clients/ Text is confusing. Is the switch blocking ALL DHCPv6 traffic, or ONLY packet originated from a DHCPv6 server? Suggest /on those ports that are not allowed to receive packets originated from a DHCPv6 server/ Also /as not being DHCPv6-server packets/ suggest /packets not originated from a DHCPv6-server/ s/ We note that if an attacker sends a fragmented DHCPv6 packet on a port not allowed to send such packets/We note that if an attacker originates a fragmented DHCPv6 packet that arrives on a switch port not allowed to receive such packets/ There are also a number of textual errors. s/connected to a switched network/connected to a layer-2 switched network/ s/The basic concept behind DHCPv6-Shield is that a layer-2 device filters DHCPv6 messages meant to DHCPv6 clients (henceforth "DHCPv6-server messages"), according to a number of different criteria./The basic concept behind DHCPv6-Shield is that a layer-2 device filters DHCPv6 messages sent to DHCPv6 clients (henceforth "DHCPv6-server messages"), according to a number of different criteria./ s/are received on a specific ports/are received on specific ports/ s/ Before the DCHPv6-Shield device is deployed, the administrator specifies the layer-2 port(s) on which DHCPv6-server messages are to be allowed/ Before the DCHPv6-Shield device is deployed, the administrator specifies the layer-2 port(s) on which messages originated from a DHCPv6-server are expected to be received/ s/(e.g., DoS)/(e.g. DoS)/ s/ If deployed in layer-2 domain with several cascading switches/ If deployed in a layer-2 domain with several cascaded switches/ -- Regards, RayH From nobody Tue Nov 18 11:05:08 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352C61A6F58; Tue, 18 Nov 2014 11:05:07 -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 T-x9DFf3Uu_L; Tue, 18 Nov 2014 11:05:00 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120D01A1ABC; Tue, 18 Nov 2014 11:05:00 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id sAIJ4vrf013200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2014 12:04:58 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 664351E006C; Tue, 18 Nov 2014 13:04:52 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 37C651E002C; Tue, 18 Nov 2014 13:04:52 -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 sAIJ4p6p022771; Tue, 18 Nov 2014 12:04:51 -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 sAIJ4psr022766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Nov 2014 12:04:51 -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.0195.001; Tue, 18 Nov 2014 12:04:50 -0700 From: "Smith, Donald" To: "ietf@ietf.org" , IETF-Announce Thread-Topic: [OPSEC] Last Call: (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best Current Practice Thread-Index: AQHQAqAggGhUU9glBUeO7HjNO+Btvpxmpelm Date: Tue, 18 Nov 2014 19:04:50 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D24C2AFA4@PDDCWMBXEX503.ctl.intranet> References: <20141117195209.16129.53872.idtracker@ietfa.amsl.com> In-Reply-To: <20141117195209.16129.53872.idtracker@ietfa.amsl.com> 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/YNv_Zn4Jp5LI68rzy4MHiXhU6AY Cc: "fgont@si6networks.com" , "opsec@ietf.org" Subject: Re: [OPSEC] Last Call: (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best Current Practice 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 Nov 2014 19:05:07 -0000 Minor suggestion aka nit: pg. 1 This: "Abstract This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. Reads a bit better if it is this: Abstract This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. This mechanism is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. This mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. Ultimately it reads the same but is s a bit simpler swapping The aforementi= oned for this. pg 3. This "first fragment" generally called "original packet", (rfc2460 section= 4.5) , description is a little weak. "First Fragment: An IPv6 fragment with fragment offset equal to 0." Maybe just refer to that rfc/section and call it original packet instead of= trying to redefine and rename it here? There are several instances of "initial fragment with offset of 0" that sho= uld probably be replaced with "original packet" and rfc reference. pg 3. IPv6 Header Chain:... Seems mostly correct but again why restate what is described in rfc2460 sec= tion 4? pg 4. I am not sure I understand this part. "RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a limit on the number of bytes they can inspect (starting from the beginning of the IPv6 packet), since this could introduce false-positives: legitimate packets could be dropped simply because the DHCPv6-Shield device does not parse the entire IPv6 header chain present in the packet. An implementation that has such an implementation-specific limit MUST NOT claim compliance with this specification." If an implementation didn't parse the whole packet and it does not see an d= hcp msg header wouldn't it default to allow not drop? ( MUST drop if see dh= cp , MUST allow if not?) So wouldn't you be more likely to have false negatives because the whole he= ader wasn't examined? pg 5 " 3. When parsing the IPv6 header chain, if the packet is identified to be a DHCPv6 packet meant for a DHCPv6 client or the packet contains an unrecognized Next Header value, DHCPv6-Shield MUST drop the packet, and SHOULD log the packet drop event in an implementation-specific manner as a security alert. DHCPv6-Shield MUST provide a configuration knob that controls whether packets with unrecognized Next Header values are dropped; this configuration knob MUST default to "drop". RATIONALE: [RFC7045] requires that nodes be configurable with respect to whether packets with unrecognized headers are forwarded, and allows the default behavior to be that such packets be dropped." Why discuss "unrecognized Next Header" here? Since this is requirement of 7045 does it need to be restated here? It says SHOULD log, so that implies the default is "drop and log" but I sus= pect many would be ok with "drop don't log". I am not sure most of us would want to know about "unrecognized Next Header= s" but could be wrong here. pg 5 section 4. "If a packet is dropped due to this filtering policy, then the packet drop event SHOULD be logged in an implementation-specific manner as a security fault. The logging mechanism SHOULD include a drop counter dedicated to DHCPv6-Shield packet drops." Doesn't the counter need to include port? A system wide counter wouldn't b= e much good. ... The logging mechanism SHOULD include a per port drop counter ... Note here it says DHCPv6 Shield even though above the logging appears to in= clude "unrecognized Next Header". Would the counter include both or just DH= CPv6 Shield drops? Maybe two counters (but then we are out of scope for dhcp again?) pg 5-6 section 4. "In order to protect current end-node IPv6 implementations, Rule #2 has been defined as a default rule to drop packets that cannot be positively identified as not being DHCPv6-server packets (because the packet is a fragment that fails to include the entire IPv6 header chain). This means that, at least in theory, DHCPv6-Shield could result in false-positive blocking of some legitimate (non DHCPv6-server) packets. However, as noted in [RFC7112], IPv6 packets that fail to include the entire IPv6 header chain are virtually impossible to police with state-less filters and firewalls, and hence are unlikely to survive in real networks. [RFC7112] requires that hosts employing fragmentation include the entire IPv6 header chain in the first fragment (the fragment with the Fragment Offset set to 0), thus eliminating the aforementioned false positives." It seems like 7112 covers this does it need to be part of this? SILICON SENSE I think it would make more sense to require dhcpv6 requests come from a spe= cial OID (Ethernet mac address) and only listen to them from that address. It would require the switch to only allow that oid be used on dhcp server p= orts but that is much simpler from an silicon point of view. It would also require changes to the dhcpv6 clients but does simplify the s= olution from a hw pov. Moving this kind of deep header inspection into layer 2 gives us a new cpu = dos vector as most vendors would initially (forever?) do that in cpu or sha= red npu? We have that problem today with layer 3 routing an headers do we want to pu= sh this to the next layer down? (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: OPSEC [opsec-bounces@ietf.org] on behalf of The IESG [iesg-secretary@= ietf.org] Sent: Monday, November 17, 2014 12:52 PM To: IETF-Announce Cc: opsec@ietf.org Subject: [OPSEC] Last Call: (DHCPv6= -Shield: Protecting Against Rogue DHCPv6 Servers) to Best Current Practice The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Mon Nov 24 19:14:00 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C3B1A1B9C for ; Mon, 24 Nov 2014 19:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.447 X-Spam-Level: * X-Spam-Status: No, score=1.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, MANGLED_DOSE=2.3, 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 pAJSYcpHqf4P for ; Mon, 24 Nov 2014 19:13:54 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D281A1B9B for ; Mon, 24 Nov 2014 19:13:53 -0800 (PST) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xt6ZV-0002D1-KW; Tue, 25 Nov 2014 04:13:45 +0100 Message-ID: <5472DD21.9030704@si6networks.com> Date: Mon, 24 Nov 2014 04:24:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ray Hunter , opsec@ietf.org References: <546B2AAD.9060004@globis.net> In-Reply-To: <546B2AAD.9060004@globis.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/f-RXNv6Uot708sAJTBlZvAOlL_Y Subject: Re: [OPSEC] OPSEC Digest, Vol 83, Issue 6 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, 25 Nov 2014 03:13:56 -0000 Hi, Ray, Thanks so much for your feedback! Please find my comments in-line... On 11/18/2014 08:17 AM, Ray Hunter wrote: >> ------------------------------------------------------------------------ > I have read this draft and think it is useful. I also realise that this > is very late in the day to make comments, but I have a number of issues. > > Substantive comment: > /Before being deployed for production, the DHCPv6-Shield device MUST > be explicitly configured with respect to which layer-2 ports are > allowed to send DHCPv6 packets to DHCPv6 clients (i.e. DHCPv6-server > messages)./ > > IMHO DHCPv6-Shield is an optional service. Suggest /Unless explicitly > configured with one or more ports to which DHCPv6 servers or relays are > attached, the DHCPv6-Shield service SHOULD NOT filter any packets./ FWIW, I personally have no issues with modifying the I-D as indicated. It looks like you're essentially arguing that "by default, DHCPv6-Shieled should be off", whereas the current text essentially means "Do not deploy this unless you've explicitly configured DHCPv6-Shield". At the end of the day, it looks like both phrases essentially have the same end result -- i.e., you could argue that if DHCPv6-shield is not filtering any packets, then it is not enabled/not deployed. Thoughts? > I also think the terminology of "send" and "receive" is used in a rather > confusing and inconsistent manner. Suggest using receive from the > perspective of the switch performing the filtering. > > s/Only those layer-2 ports explicitly configured for such purpose will > be allowed to send DHCPv6 packets to DHCPv6 clients/Only those layer-2 > ports explicitly configured for such purpose will be allowed to receive > DHCPv6 packets for forwarding to other ports where DHCPv6 clients may be > connected/ Maybe also s/receive/accept/? -- because you do receive them anyway (even if you later drop them) > [the L2 switch management process itself will also likely not see the > DHCPv6 packet if it is performing ingress filtering, and DHCPv6 servers > could theoretically send packets to each other] > > /on those ports that are not allowed to send DHCPv6 packets to DHCPv6 > clients/ > > Text is confusing. Is the switch blocking ALL DHCPv6 traffic, or ONLY > packet originated from a DHCPv6 server? The text should read "DHCPv6-server packets". -- Will fix this in the next rev. > Suggest /on those ports that are not allowed to receive packets > originated from a DHCPv6 server/ > > Also /as not being DHCPv6-server packets/ > > suggest > > /packets not originated from a DHCPv6-server/ Not sure what you mean here.... > s/ We note that if an attacker sends a fragmented DHCPv6 packet on a > port not allowed to send such packets/We note that if an attacker > originates a fragmented DHCPv6 packet that arrives on a switch port not > allowed to receive such packets/ s/receive/accept/? > There are also a number of textual errors. > > s/connected to a switched network/connected to a layer-2 switched network/ > > s/The basic concept behind DHCPv6-Shield is that a layer-2 device > filters DHCPv6 messages meant to DHCPv6 clients (henceforth > "DHCPv6-server messages"), according to a number of different > criteria./The basic concept behind DHCPv6-Shield is that a layer-2 > device > filters DHCPv6 messages sent to DHCPv6 clients (henceforth > "DHCPv6-server messages"), according to a number of different > criteria./ Will do. > s/are received on a specific ports/are received on specific ports/ Will fix this. > s/ Before the DCHPv6-Shield device is deployed, the administrator > specifies the layer-2 port(s) on which DHCPv6-server messages are to > be allowed/ Before the DCHPv6-Shield device is deployed, the > administrator > specifies the layer-2 port(s) on which messages originated from a > DHCPv6-server are expected to be received/ Maybe "vBefore the DCHPv6-Shield device is deployed, the administrator specifies the layer-2 port(s) on which DHCPv6-server messages should be accepted" instead? > s/(e.g., DoS)/(e.g. DoS)/ > > s/ If deployed in layer-2 domain with several cascading switches/ If > deployed in a layer-2 domain with several cascaded switches/ Will fix this. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492