From nobody Mon Jun 2 09:20: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 DB8571A038E for ; Mon, 2 Jun 2014 09:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og25Db59uD-p for ; Mon, 2 Jun 2014 09:20:09 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53731A035E for ; Mon, 2 Jun 2014 09:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3459; q=dns/txt; s=iport; t=1401726004; x=1402935604; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TJRFxC3JgoDt/2QVJwBJ12GSbTGhFzpvMraq9Abp2+Y=; b=VdOjGN8/LphU053cLG17UehOx1sDd46xtQtIdTPtfKhZd+LzgdrdUJt4 TBmyxZBm7ilQ0CwNDhO/L7F8MY6GmUS6Kr9BUA256U1tPA/jhyFGOqNYT oytOAXhEHza+eOt57IC+kFpryvm8ESXzyEaU2aRcmU+/T6oQO6jJsUNEg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8IAIqjjFOtJV2a/2dsb2JhbABZgwdSUQe7HYc5AYEVFnSCJQEBAQQBAQE3NAQTBAIBCBEEAQELFAkHJwsUCQgCBAESCAELiC4IBdE4F44hOAaDJYEVBJU1hgmRb4M4gi8 X-IronPort-AV: E=Sophos;i="4.98,957,1392163200"; d="scan'208";a="49411624" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 02 Jun 2014 16:20:03 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s52GK37Y032758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 16:20:03 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.80]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Mon, 2 Jun 2014 11:20:03 -0500 From: "Gunter Van de Velde (gvandeve)" To: "George, Wes" , "opsec@ietf.org" Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-03.txt Thread-Index: AQHPYleeAiy0DlL+pU+KfE86V0bfLZsngF2AgDa3ZdA= Date: Mon, 2 Jun 2014 16:20:02 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B24113E2BF0@xmb-aln-x12.cisco.com> References: <20140427203042.20840.34608.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.203.114] 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/dW-FK4B0Q7KYhKbSoQN1Qy9JzD8 Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:20:11 -0000 Many thanks to authors and reviewers to process this document. I'll create the shepherd write-up and submit it to next step. Brgds, G/ -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of George, Wes Sent: 28 April 2014 17:44 To: opsec@ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-03.txt This new version addresses my comments. Thanks to the authors for their wor= k on this document, it will be very useful. Thanks, Wes On 4/27/14, 4:30 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Operational Security Capabilities for=20 >IP Network Infrastructure Working Group of the IETF. > > Title : BGP operations and security > Authors : Jerome Durand > Ivan Pepelnjak > Gert Doering > Filename : draft-ietf-opsec-bgp-security-03.txt > Pages : 29 > Date : 2014-04-27 > >Abstract: > BGP (Border Gateway Protocol) is the protocol almost exclusively used > in the Internet to exchange routing information between network > domains. Due to this central nature, it is important to understand > the security measures that can and should be deployed to prevent > accidental or intentional routing disturbances. > > This document describes measures to protect the BGP sessions itself > (like TTL, TCP-AO, control plane filtering) and to better control the > flow of routing information, using prefix filtering and > automatization of prefix filters, max-prefix filtering, AS path > filtering, route flap dampening and BGP community scrubbing. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-bgp-security-03 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >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 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From nobody Mon Jun 2 12:43:42 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 37E5F1A0369 for ; Mon, 2 Jun 2014 12:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7AkTBaIj0Lg for ; Mon, 2 Jun 2014 12:43:36 -0700 (PDT) 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 6A62D1A0275 for ; Mon, 2 Jun 2014 12:43:36 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s52JhQhP028772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jun 2014 13:43:26 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 6DCD21E006E; Mon, 2 Jun 2014 13:43:21 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 32FB31E0060; Mon, 2 Jun 2014 13:43:21 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s52JhKaT026873; Mon, 2 Jun 2014 14:43:20 -0500 (CDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s52JhJpS026855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 14:43:20 -0500 (CDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.03.0158.001; Mon, 2 Jun 2014 13:43:18 -0600 From: "Smith, Donald" To: "'Ronald Bonica'" , "'Gunter Van de Velde (gvandeve)'" , "'opsec wg mailing list'" Thread-Topic: Start of 2nd WGLC for draft-ietf-opsec-bgp-security Thread-Index: Ac9TCpCty6WW3UV9Rc+t1rBkEBAqQQGX/bdQAAN0kZAACQ/0gA== Date: Mon, 2 Jun 2014 19:43:18 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D1249A9C8@PDDCWMBXEX503.ctl.intranet> References: <67832B1175062E48926BF3CB27C49B24113958CB@xmb-aln-x12.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] 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/MwgTdaVFOVAmY3x2OyY_zl-tG1c Cc: "'draft-ietf-opsec-bgp-security@tools.ietf.org'" , "'kk@dropbox.com'" Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 19:43:39 -0000 Assuming this is discussing the "slipping in the tcp window" tcp reset atta= ck. 4.1. Protection of TCP sessions used by BGP Attacks on TCP sessions used by BGP (ex: sending spoofed TCP RST packets) could bring down the TCP session. Following a successful ARP spoofing attack (or other similar Man-in-the-Middle attack), the attacker might even be able to inject packets into the TCP stream (routing attacks). You do NOT have to do arp spoofing to inject packets into the bgp session. The same "guessing the sequence number within the window" trick works for p= acket injection not just resets. It is possible to blindly inject bgp updates into a bgp stream without doin= g any kind of MITM. You have to know more about the bgp session such as BGP ID etc... but it is= possible. This is mostly true: 4.2. BGP TTL security (GTSM) BGP sessions can be made harder to spoof with the Generalized TTL Security Mechanisms (aka TTL security) [9]. Instead of sending TCP packets with TTL value =3D 1, the routers send the TCP packets with TTL value =3D 255 and the receiver checks that the TTL value equals 255. Since it's impossible to send an IP packet with TTL =3D 255 to a non- directly-connected IP host, BGP TTL security effectively prevents all spoofing attacks coming from third parties not directly connected to the same subnet as the BGP-speaking routers. Network administrators SHOULD implement TTL security on directly connected BGP peerings. Note: Like MD5 protection, TTL security has to be configured on both ends of a BGP session. Many routers today actually do ttl decrement on the line card while GTSM is= likely further up the cpu/npu stack. So depending on vendor and router you= probably need to allow 254 for a directly connected router. "Pampers use multiple layers of protection to prevent leakage. Rommel used = defense in depth to defend European fortresses." (A.White) Donald.Smith@Cen= turyLink.com >-----Original Message----- >From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Ronald Bonica >Sent: Wednesday, April 16, 2014 7:34 AM >To: Gunter Van de Velde (gvandeve); opsec wg mailing list >Cc: draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com >Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security > >Folks, > > > >This document is very comprehensive and well-written. Kudos to the authors= . > > > >However, please take a look at the Forward. > > > > Ron > > > > > >From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Vel= de >(gvandeve) >Sent: Wednesday, April 16, 2014 7:56 AM >To: opsec wg mailing list >Cc: draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com >Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security > > > >Please find this reminder to query for your feedback. > > > >Brgds, > >G/ > > > >From: Gunter Van de Velde (gvandeve) >Sent: 08 April 2014 11:18 >To: opsec wg mailing list >Cc: KK (kk@google.com); draft-ietf-opsec-bgp-security@tools.ietf.org > >Subject: Start of 2nd WGLC for draft-ietf-opsec-bgp-security > > > >Dear OpSec WG, > > > >This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-securit= y. > >Due to the time taken to integrate all comments from the first WGLC this 2= nd >WGLC is initiated. > > > >All three authors have replied, stating that they do not know of any IPR >associated with this draft. > > > >The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-o= psec- >bgp-security/ > > > >Please review this draft to see if you think it is ready for publication a= nd >comments to the list, clearly stating your view. > > > >This WGLC ends 22-April-2014. > > > >Thanks, > >G/ > > From nobody Thu Jun 5 06:41: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 20DB01A0090 for ; Thu, 5 Jun 2014 06:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkkyLGnzO2r3 for ; Thu, 5 Jun 2014 06:41:23 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA3F1A00C6 for ; Thu, 5 Jun 2014 06:41:23 -0700 (PDT) Received: from bsn-61-64-160.static.dsl.siol.net ([86.61.64.160] helo=[10.10.76.86]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WsXup-0001In-Vf; Thu, 05 Jun 2014 15:41:12 +0200 Message-ID: <53907376.50503@si6networks.com> Date: Thu, 05 Jun 2014 15:41:10 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" , KK Chittimaneni , "opsec@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Kott-Jdc9U1HChI0E0LK2FEhHmE Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:41:27 -0000 Hi, Eric, Thanks so much for your feedback! Please find my responses in-line... On 05/12/2014 03:09 PM, Eric Vyncke (evyncke) wrote: > KK, Gunter, Fernando & Will, > > I have reviewed the document and here are my comments (some cosmetic): > > * section 1: "on a specified port of the layer-2 device" => "on > specific port(s) of the layer-2 device" (plural form) > * Section 1: "Only those ports to which a DHCPv6 server" => "Only > those ports to which a DHCPv6 server or relay" (relays should be > allowed as well) I have applied these two. Thanks! > * Section 3: not sure whether it is relevant here, this is well-known > and accepted terminology, I am always uneasy when information is > duplicated as it is an open door for inconsistency FWIW, the reason for which we added this is because we were requested to define these terms for other documents (e.g., RFC 7112). Acording to 6man discussions, this was needed. But we could (alternatively just reference the corresponding section of RFC7112. > * Section 3: should define what a 'DHCP shield device' is Done. > * Section 5: I do not agree with point 1) if the specific platform > cannot handle a long ext header chain, it should be allowed to drop > the packet (the MUST NOT should be SHOULD NOT or even a MAY — > reversing the proposed policy). Of course, such platforms cannot > claim compatibility with DHCP-shield I agree with you. :-) This comes from past discussions surrounding RA-Guard. I've removed the "must not drop" claim. i.e., the text now looks: 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. > * Section 5: "SHOULD be logged in an implementation-specific manner as > security fault" => "security alert" or "security event" Done. > * Section 7: the whole I-D is only handling the physical/wired > switched case while in the introduction it is stated to be > 'broadcast network'. The security section and/or introduction should > mention this. I've s/broadcast/switched/ > * Section 7: should also mention other DHCP related threats? Such as > DoS attack against DHCP servers? Amplification/reflection attacks? > Of course, the mitigation techniques are out of scope, but, I think > that the threats should be mentioned Changed to: ---- cut here ---- The mechanism specified in this document can be used to mitigate DHCPv6-based attacks against hosts. Attack vectors based on other messages meant for network configuration (such as ICMPv6 Router Advertisements) are out of the scope of this document. Additionally, the mechanism specified in this document does not mitigate attacks against DHCPv6 servers (e.g., DoS). ---- cut here ---- > * Add a reference to SAVI-DHCP ? SAVI-DHCP seems rather orthogonal... but I might be wrong. i.e., savi-dhcp seems to be about building state on the layer-2 device based on DHCPv6 exchanges, rather than about preventing malicious DHCPv6 exchanges. Am I right? In any case, I guess one could add an informational reference as follows: "The security of a site employing DHCPv6 Shield could be further improved by deploying [SAVI-DHCP], to mitigate IPv6 address spoofing". Thoughts? > Else, good document, pretty much like the well-known rogue DHCPv4 That was the intent (porting dhcpv4 guard). :-) 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 From nobody Thu Jun 5 07:18:25 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 B00471A01B1; Thu, 5 Jun 2014 07:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f-0ZGk1kusJ; Thu, 5 Jun 2014 07:18:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6551C1A01D4; Thu, 5 Jun 2014 07:18:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140605141804.8007.90220.idtracker@ietfa.amsl.com> Date: Thu, 05 Jun 2014 07:18:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/YU1fmUPPF5F_f3r0zy_AkJev2J8 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-03.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, 05 Jun 2014 14:18:21 -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-03.txt Pages : 16 Date : 2014-06-05 Abstract: This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 6 00:21: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 2C33F1A03FA for ; Fri, 6 Jun 2014 00:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjH9RidjuUye for ; Fri, 6 Jun 2014 00:21:19 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018011A03D4 for ; Fri, 6 Jun 2014 00:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=879; q=dns/txt; s=iport; t=1402039272; x=1403248872; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6VSJE5/WEWheePPXmMyjPNwv3BTLMeDbAHGidLxxtkY=; b=B+dQQAzRY1voC2Ep/P8uIzJiWLSaLteERUcqRyJXSj2NNHoloVUkSCsM 1r17UpCXiYszdzZuLN1+Rb8IVEZEdGfUWjSRCFK3pXLvHEAM5wYiR1rHe Q6aFhfNU8AKZxe9Hgd9m9IRZXWkxRG+YwJwPgKAXbiHnvWHgFztAijEmb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKxrkVOtJA2N/2dsb2JhbABZgw2BK8N8AYEGFnWEAwEBAQR5EAIBCA4KLjIlAgQBDQWIQsxwF45pB4RBAQOJc5Ajk0CDPIIv X-IronPort-AV: E=Sophos;i="4.98,987,1392163200"; d="scan'208";a="50775592" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 06 Jun 2014 07:20:51 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s567KpgI011274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 07:20:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 02:20:51 -0500 From: "Eric Vyncke (evyncke)" To: Fernando Gont , "opsec@ietf.org" , Kiran Kumar Chittimaneni Thread-Topic: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Thread-Index: AQHPbMbYfZxAQufNXkuwA/o7IiWXMps9Yp8AgCWfQwCAAUmYAA== Date: Fri, 6 Jun 2014 07:20:50 +0000 Message-ID: References: <53907376.50503@si6networks.com> In-Reply-To: <53907376.50503@si6networks.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.55.185.77] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <712FEAA58650FF45B2D97ED814D3F1A4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/A3y7L_QmWCQxdvkrYBZRLXnCbxk Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 07:21:21 -0000 Fernando Thanks for your feedback, as you kindly requested my thoughts on some changes, see in-line On 5/06/14 15:41, "Fernando Gont" wrote: > >> * Add a reference to SAVI-DHCP ? > >SAVI-DHCP seems rather orthogonal... but I might be wrong. i.e., >savi-dhcp seems to be about building state on the layer-2 device based >on DHCPv6 exchanges, rather than about preventing malicious DHCPv6 >exchanges. Am I right? > >In any case, I guess one could add an informational reference as follows: >"The security of a site employing DHCPv6 Shield could be further >improved by deploying [SAVI-DHCP], to mitigate IPv6 address spoofing". > >Thoughts? This is indeed mostly orthogonal, each technique can be deployed without the other one. But, you proposed paragraph is correct and will be helpful for the readers/implementers. -=E9ric From nobody Fri Jun 6 02:51:20 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 7C4131A02C1 for ; Fri, 6 Jun 2014 02:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n04UwwnaKy43 for ; Fri, 6 Jun 2014 02:51:16 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706F11A03EA for ; Fri, 6 Jun 2014 02:51:16 -0700 (PDT) Received: from bsn-61-64-160.static.dsl.siol.net ([86.61.64.160] helo=[10.10.76.146]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wsqni-0007wb-9P; Fri, 06 Jun 2014 11:51:06 +0200 Message-ID: <53917E7E.2070103@si6networks.com> Date: Fri, 06 Jun 2014 10:40:30 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" , "opsec@ietf.org" , Kiran Kumar Chittimaneni References: <53907376.50503@si6networks.com> 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/lDEsCLLNnqUPXdpo5bQ5e7yCy-E Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 09:51:18 -0000 On 06/06/2014 09:20 AM, Eric Vyncke (evyncke) wrote: >> >>> * Add a reference to SAVI-DHCP ? >> >> SAVI-DHCP seems rather orthogonal... but I might be wrong. i.e., >> savi-dhcp seems to be about building state on the layer-2 device based >> on DHCPv6 exchanges, rather than about preventing malicious DHCPv6 >> exchanges. Am I right? >> >> In any case, I guess one could add an informational reference as follows: >> "The security of a site employing DHCPv6 Shield could be further >> improved by deploying [SAVI-DHCP], to mitigate IPv6 address spoofing". >> >> Thoughts? > > This is indeed mostly orthogonal, each technique can be deployed without > the other one. But, you proposed paragraph is correct and will be helpful > for the readers/implementers. Perfect. I will add the paragraph above to the next rev. Regarding the only remaining proposed change (about the terminology), I'd like to know if you have any further thoughts. Me, I wouldn't have a problem with removing the definition of those terms, nad pointing to the specific section of RFC7112. However, I think that explicitly including the definitions makes the document more self-contained. Also.. I wonder what would happen if, say, RFC7112 were to be replaced by some other RFC (the DHCPv6 SHield would now have a pointer to e.g. an obsoleted RFC?) -- just me thinking out loud. Thanks so much! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Jun 7 09:54:17 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 D4B481A00DA for ; Sat, 7 Jun 2014 09:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, 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 jYAcAOVLypnO for ; Sat, 7 Jun 2014 09:54:14 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EFE1A00F2 for ; Sat, 7 Jun 2014 09:54:14 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 10so806251ykt.8 for ; Sat, 07 Jun 2014 09:54:07 -0700 (PDT) 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 :content-type; bh=bY72+L4k6PBUHJBrGiydz2P5XOeuXnoE2G6s71IB0DE=; b=OxSXQfF3dVIGLM7WoTgWAi8pVukpyw8/le2Sp3hOHseep5312Gxz7FDlHaAYLkdPpx lCPMG378feDxSwdx76kjYPXMHViV8aGA3OVPlZLuByCQQIw99nq0M+zde0bRdU2wo89g HkQ4TKaDJd1FEKzzpdRGnygnS7PfFKbqaCPuc0czvMMbaaIFJ6nB637BGj0U0l0CgUO6 mzdk35wOy3o1QJxPYSjfmFCKxuo4itudQPHsxn1uKy7pz06ijbxbzO8CEYm3KVcQ5+bY xCVW/MPdtHhm+93opzssFm7oXID6PnmFYIcWKeCM0cXueXXmRkA0+lpJG5rvgKAQ0RTv YuvA== MIME-Version: 1.0 X-Received: by 10.236.36.45 with SMTP id v33mr404262yha.129.1402160046973; Sat, 07 Jun 2014 09:54:06 -0700 (PDT) Received: by 10.170.126.86 with HTTP; Sat, 7 Jun 2014 09:54:06 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 Jun 2014 09:54:06 -0700 Message-ID: From: KK Chittimaneni To: opsec@ietf.org, "draft-ietf-opsec-dhcpv6-shield@tools.ietf.org" Content-Type: multipart/alternative; boundary=089e0160bc6884a6bd04fb41d300 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/wFIZrnK7GNK8UKKM2bHMWq7KCfU Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:54:16 -0000 --089e0160bc6884a6bd04fb41d300 Content-Type: text/plain; charset=UTF-8 Dear Opsec WG, The co-chairs assessed the discussion on the list and now feel that there was sufficient review to move this document forward. Thanks, KK (as Opsec WG co-chair) On Sat, May 10, 2014 at 8:12 PM, KK Chittimaneni wrote: > Dear Opsec WG, > > The WGLC for this draft technically ended last month with just one > response received. Not enough to move forward. > > The co-chairs chatted about this and noted that there was a lot more > support for this doc during earlier stages. Given that, we'd like to give > the WG a bit more time to review this and extend the LC to the 24th of May. > Ideally, we'd like to get at least two volunteers who could do a thorough > review of this doc and post their comments to the list. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ > > > Please read it now and report to the list whether you support publication > or not. Insufficient responses will be taken as an indication of lack of > interest and we'll stop from proceeding further. > > Regards, > KK (as Opsec WG co-chair) > --089e0160bc6884a6bd04fb41d300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Opsec WG,

The co-ch= airs assessed the discussion on the list and now feel that there was suffic= ient review to move this document forward.

Thanks,
KK= (as Opsec WG co-chair)




On Sa= t, May 10, 2014 at 8:12 PM, KK Chittimaneni <kk.chittimaneni@gma= il.com> wrote:
Dear Opsec WG,

=
The WGLC for this draft technically ended last month with just o= ne response received. Not enough to move forward.

The co-chairs chatted about this and noted that there was a lot more su= pport for this doc during earlier stages. Given that, we'd like to give= the WG a bit more time to review this and extend the LC to the 24th of May= . Ideally, we'd like to get at least two volunteers who could do a thor= ough review of this doc and post their comments to the list.

The draft is available here:=C2=A0https://datatracker= .ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/


Please read it now and report to the list whether you support publicat= ion or not. Insufficient responses will be taken as an indication of lack o= f interest and we'll stop from proceeding further.

Regards,
KK (as Opsec WG co-chair)

--089e0160bc6884a6bd04fb41d300-- From nobody Sat Jun 14 16:54:25 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 386BC1B2A49; Sat, 14 Jun 2014 16:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQo7jhGVkNqM; Sat, 14 Jun 2014 16:54:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC11E1B2A41; Sat, 14 Jun 2014 16:54:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140614235413.1154.20100.idtracker@ietfa.amsl.com> Date: Sat, 14 Jun 2014 16:54:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/YCJPjQBe0dRBwoJrN6UX0inEwb8 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 23:54:16 -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 : Network Reconnaissance in IPv6 Networks Authors : Fernando Gont Tim Chown Filename : draft-ietf-opsec-ipv6-host-scanning-04.txt Pages : 31 Date : 2014-06-14 Abstract: IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or less unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore brute-force IPv6 address scanning attacks have been considered unfeasible. This document updates RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address scanning techniques apply to IPv6 networks, and exploring some additional techniques that can be employed for IPv6 network reconnaissance. In doing so, this document formally obsoletes RFC 5157. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-host-scanning-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 20 08:14: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 3376E1A0379; Fri, 20 Jun 2014 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZHofBraddWb; Fri, 20 Jun 2014 08:13:59 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCF41A03A2; Fri, 20 Jun 2014 08:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5375; q=dns/txt; s=iport; t=1403277239; x=1404486839; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zOVIdpkgKF6mM8shiGqmTy+gLiM+xETgJXZXZzIjTzQ=; b=DPefyQnpc++8LVKD6kDQgnKpqQ0IRrOZo7iNJsWr4Inh9bpWRXsrP2C5 kZsZ2n2B0U1VjLCnzwZUBYONNB+SZwiVghrwCpaCSFqJASc9cfZ714Duc /AWnLINV6osRHxfgR27iRtXCtv5MbCSgbkNHgY2HCnvbD2QPNGOH1Ozm6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgLABdPpFOtJV2Z/2dsb2JhbABZDoJ/UlMHqh8BAQEBAQEFAZFrhz8BgQkWdYQEAQEEAQEBawsQAgEIDiABFycLJQIEAQ0FCYg5CAXKZxeFYokUBxIBhDAEigaOAYI9gUOSF4MAQoFwBxci X-IronPort-AV: E=Sophos;i="5.01,514,1400025600"; d="scan'208";a="54749790" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 20 Jun 2014 15:13:58 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5KFDvSP006527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 15:13:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.10]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 20 Jun 2014 10:13:57 -0500 From: "Eric Vyncke (evyncke)" To: Tim Chown , Fernando Gont Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.txt Thread-Index: AQHPiCwRtt82smvvGECcJrApL1Pdv5t6mX0A Date: Fri, 20 Jun 2014 15:13:56 +0000 Message-ID: References: <20140614235413.1154.20100.idtracker@ietfa.amsl.com> In-Reply-To: <20140614235413.1154.20100.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.4.2.140509 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 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/KLgnCU5afwGDOpz1QdAlS-B2ZRQ Cc: "opsec@ietf.org" , "v6ops@ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 15:14:08 -0000 Fernando and Tim [Adding V6OPS in cc], Just re-read your I-D, here are some comments: - in the intro, 'van dijk' scanning via reverse DNS is no more 'recent' IMHO (update also section 4.4) - section 3.1.1 is yet another explanation of SLAAC & Co, I usually prefer avoiding repetition because they may introduce discrepancy or incoherencies =3D> remove those parts from the I-D? What about only talking about EUI-64 for example? - section 3.1.2 about DHCP, probably worth to say that some DHCP servers change the leased address(es) every few hours/days while others keep the same address(es) for years (even if the DHCP client went away for months) - section 3.3 about local mcast probe, a lot of networks (think large wifi) prevent direct WiFi client to WiFi client communication, or isolate hosts to communication to each others (hosting providers for example), so, this method of scanning is not always efficient. My default Mac OS/X configuration also prevents replying to any ICMP echo request... - section 3.4 not sure whether an inventory of existing scanning tools is valuable and this is an every changing world - 3.5 about mitigations, IPFIX can also help a lot with regard to detecting a scan - 3.5 I do not like the idea that error messages should not be generated when destination is a multicast... We need at least packet too big as well as parameter problem if we still dream about mcasted IPv6 video streaming - section 3.5 mitigations is in the middle of scanning techniques? Move it apart? Or build a mitigation section in all other scanning techniques? - section 4.4, should there be a recommendation to optionally change the reply code of reverse DNS servers? More work to be done in DNSEXT? Or DNSOP? - section 8 (ND cache), it is not only by 'login' but also available through SNMP (see also section 5 of draft-ietf-opsec-v6) - section 10 (routing protocols), not sure whether it can really help to scan except by providing the prefixes and in some case some router interface addresses (but trace route is there anyway) - appendix A, not sure whether it brings value May I suggest to add also IPFIX as it can aggregate the flows by source addresses, hence, getting a list of all addresses. See also section 2.5.1.2 of draft-ietf-opsec-v6. While at the beginning the I-D rightfully discusses about the two purposes of scanning (bad guys and good guys doing inventory), the main focus of the document appears to be on mitigation techniques (i.e. Prevent scanning) while very few on helping the good guys to build an inventory. May I also suggest that SAVI RFC 6620 also builds a cache of MAC/IPv6 without actively participating in the NDP exchange, so, it is also another source of information. You may also want to add simple traceroutes as they discover the IP addresses of routers. Lastly, and not sure about that point, should we drop a can full of worms in the document? Telling readers that using ULA and NAT is perhaps worse than the benefit? ;-) (it is Friday after all) -=E9ric On 15/06/14 01:54, "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 : Network Reconnaissance in IPv6 Networks > Authors : Fernando Gont > Tim Chown > Filename : draft-ietf-opsec-ipv6-host-scanning-04.txt > Pages : 31 > Date : 2014-06-14 > >Abstract: > IPv6 offers a much larger address space than that of its IPv4 > counterpart. An IPv6 subnet of size /64 can (in theory) accommodate > approximately 1.844 * 10^19 hosts, thus resulting in a much lower > host density (#hosts/#addresses) than is typical in IPv4 networks, > where a site typically has 65,000 or less unique addresses. As a > result, it is widely assumed that it would take a tremendous effort > to perform address scanning attacks against IPv6 networks, and > therefore brute-force IPv6 address scanning attacks have been > considered unfeasible. This document updates RFC 5157, which first > discussed this assumption, by providing further analysis on how > traditional address scanning techniques apply to IPv6 networks, and > exploring some additional techniques that can be employed for IPv6 > network reconnaissance. In doing so, this document formally > obsoletes RFC 5157. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ipv6-host-scanning-04 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >OPSEC mailing list >OPSEC@ietf.org >https://www.ietf.org/mailman/listinfo/opsec From nobody Sat Jun 21 20:36: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 8079F1B287E for ; Sat, 21 Jun 2014 20:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lcBuVqZ50fa for ; Sat, 21 Jun 2014 20:36:52 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142381B286A for ; Sat, 21 Jun 2014 20:36:49 -0700 (PDT) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s5M3aiew003753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 22 Jun 2014 03:36:46 GMT (envelope-from joelja@bogus.com) Message-ID: <53A64F47.7020602@bogus.com> Date: Sat, 21 Jun 2014 20:36:39 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs , "opsec@ietf.org" X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U0Wb3K26Bfq3KDcatFVWgFIWNevKfCem2" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 22 Jun 2014 03:36:48 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/2XLtb1U6ELinx6uka8uuOJcLLt8 Subject: [OPSEC] draft-ietf-opsec-vpn-leakages proposed IESG note text. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 03:36:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U0Wb3K26Bfq3KDcatFVWgFIWNevKfCem2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks, After some roundabout attempts at clearing the discuss on draft-ietf-opsec-vpn-leakages the following text has been proposed by the IESG as a note on the document. It could proceed to the rfc editor queue with this text in place. We could also adjust the document accordingly, however at this point, the current position is farily hard w= on. Thoughts would be appreciated. joel --- This document describes a problem of information leakage in VPN software and attributes that problem to the software's inability to deal with IPv6. We do not think this is an appropriate characterization of the problem. It is true that when a device supports more than one address family, the inability to apply policy to more than one address family on that device is a defect. Despite that, inadvertent or maliciously-induced information leakage may also occur due to the existence of any unencrypted interface allowed on the system, including the configuration of split tunnels in the VPN software itself. While there are some attacks that are unique to an IPv6 interface, the sort of information leakage described by this document is a general problem that is not unique to the situation of IPv6-unaware VPN software. We do not think this document sufficiently describes the general issue. --- --U0Wb3K26Bfq3KDcatFVWgFIWNevKfCem2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOmT0cACgkQ8AA1q7Z/VrJwWACdHlSmAzwMmdljXr6uBsrhD0+t CSoAnjWzf4L5kUcpUZsAgNgMwxgEwg9S =tvUb -----END PGP SIGNATURE----- --U0Wb3K26Bfq3KDcatFVWgFIWNevKfCem2-- From nobody Sat Jun 21 21:29:05 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 914A31B286A for ; Sat, 21 Jun 2014 21:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 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.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 Lh6fR8c3WUFH for ; Sat, 21 Jun 2014 21:29:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9FF1A0454 for ; Sat, 21 Jun 2014 21:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2701; q=dns/txt; s=iport; t=1403411342; x=1404620942; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eHQVwwoyCwFBBx2GHw5xvn1RSHGsaSdaW4NXq3l7JME=; b=PzFcF1N/tnmwOlE7K0DOrvHeY3U8DbtTnm0xhP3zPuuC67TbLGt88n7G ohDlAYgTzlMjshAD5VZ0A39CV+HquwsDLoprd5N6ULqy+Uq/Pl54Drlve Hv52RTbm8VKa1ICCiKF9N0i9xehl3IMlu0iL9sXpwNFKYLMRKKCX3tx8J o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAG5aplOtJA2D/2dsb2JhbABZgw2BLMNiAYEFFnWEAwEBAQMBeQULAgEIRjIlAgQOBQ4RiBsIxzYXjnwHgy2BFgEDkgaBQYcFk2ODQoIw X-IronPort-AV: E=Sophos;i="5.01,522,1400025600"; d="asc'?scan'208";a="334794394" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jun 2014 04:29:02 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5M4T1Cf022092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Jun 2014 04:29:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Sat, 21 Jun 2014 23:29:01 -0500 From: "Fred Baker (fred)" To: joel jaeggli Thread-Topic: [OPSEC] draft-ietf-opsec-vpn-leakages proposed IESG note text. Thread-Index: AQHPjcs9A9ibq3PdK02zI+GMurVen5t83TSA Date: Sun, 22 Jun 2014 04:29:00 +0000 Message-ID: References: <53A64F47.7020602@bogus.com> In-Reply-To: <53A64F47.7020602@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_95E7D31F-A8F1-4274-823A-A8428C459493"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/J_WVTRg9NNr5htuSgKuDALe7m18 Cc: "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs , "opsec@ietf.org" Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages proposed IESG note text. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 04:29:04 -0000 --Apple-Mail=_95E7D31F-A8F1-4274-823A-A8428C459493 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 21, 2014, at 8:36 PM, joel jaeggli wrote: > Folks, >=20 > After some roundabout attempts at clearing the discuss on > draft-ietf-opsec-vpn-leakages the following text has been proposed by > the IESG as a note on the document. It could proceed to the rfc editor > queue with this text in place. We could also adjust the document > accordingly, however at this point, the current position is farily = hard won. >=20 > Thoughts would be appreciated. >=20 > joel > --- >=20 > This document describes a problem of information leakage in VPN = software > and attributes that problem to the software's inability to deal with > IPv6. We do not think this is an appropriate characterization of the > problem. It is true that when a device supports more than one address > family, the inability to apply policy to more than one address family = on > that device is a defect. Despite that, inadvertent or > maliciously-induced information leakage may also occur due to the > existence of any unencrypted interface allowed on the system, = including > the configuration of split tunnels in the VPN software itself. While > there are some attacks that are unique to an IPv6 interface, the sort = of > information leakage described by this document is a general problem = that > is not unique to the situation of IPv6-unaware VPN software. We do not > think this document sufficiently describes the general issue. I might suggest that this text say who =93we=94 is. Clearly, those who = wrote the draft, who might otherwise be described in the first person = plural, must disagree with that assessment. Personally, if the final sentence is the considered opinion of the IESG, = I would rather not publish as an RFC - a permanent archival document - a = description that the same RFC says is inadequate. I would rather that = the IESG return the document to the working group and request a = replacement that =93sufficiently describes the general issue=94. --Apple-Mail=_95E7D31F-A8F1-4274-823A-A8428C459493 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTpluLbjEdbHIsm0MRAj61AKCsWCNf8Ds7aH/Q5j/n/MRmzQmqmgCgjpXq /cEF68aMRtIV+Y/IFAdP1Gc= =aW9e -----END PGP SIGNATURE----- --Apple-Mail=_95E7D31F-A8F1-4274-823A-A8428C459493-- From nobody Sun Jun 22 14:43:36 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 301061A0331 for ; Sun, 22 Jun 2014 14:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 BqAO8QHM2_rS for ; Sun, 22 Jun 2014 14:43:29 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75A71A02BA for ; Sun, 22 Jun 2014 14:43:28 -0700 (PDT) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WypXY-0001j1-LD; Sun, 22 Jun 2014 23:43:08 +0200 Message-ID: <53A74ABD.3060604@si6networks.com> Date: Sun, 22 Jun 2014 18:29:33 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: joel jaeggli , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs , "opsec@ietf.org" References: <53A64F47.7020602@bogus.com> In-Reply-To: <53A64F47.7020602@bogus.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ufsTFGRfy3jbBweCufVVdVYgZcQ Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages proposed IESG note text. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 21:43:31 -0000 Hi, Joel, Thanks so much for your efforts in this area. Short version of my answer: "This is fine. Please go ahead and push the document forward". Long version of my answer: This note is meant to reflect an IESG opinion, so I respect it as such. I'd note that I don't know of any other case where the VPN supports more than one address family that is not "IPv4 and IPv6" ("IPv4 and OSI"?). Additionally, if the "leak" occurs because of a split tunnel, then that's not a leak, but rather the result of an explicit decision (the split policy established by the administrator). But I'm fine with having different views on the topic. Thanks, Fernando On 06/22/2014 12:36 AM, joel jaeggli wrote: > Thoughts would be appreciated. > > joel --- > > This document describes a problem of information leakage in VPN > software and attributes that problem to the software's inability to > deal with IPv6. We do not think this is an appropriate > characterization of the problem. It is true that when a device > supports more than one address family, the inability to apply > policy to more than one address family on that device is a defect. > Despite that, inadvertent or maliciously-induced information > leakage may also occur due to the existence of any unencrypted > interface allowed on the system, including the configuration of > split tunnels in the VPN software itself. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jun 23 12:09: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 AA6D61B2C56; Mon, 23 Jun 2014 12:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 frX2Mpq1cqRa; Mon, 23 Jun 2014 12:09:32 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5F11B2C33; Mon, 23 Jun 2014 12:09:06 -0700 (PDT) Received: from [190.246.228.61] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wz9bt-00084r-M9; Mon, 23 Jun 2014 21:08:58 +0200 Message-ID: <53A87B38.70000@si6networks.com> Date: Mon, 23 Jun 2014 16:08:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" , Tim Chown References: <20140614235413.1154.20100.idtracker@ietfa.amsl.com> 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/7rJkTf6LCrLw4IeD9djlMWFcpI0 Cc: "opsec@ietf.org" , "v6ops@ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:09:42 -0000 Hi, Eric, Thanks so much fr your feedback! Please find my responses in-line... On 06/20/2014 12:13 PM, Eric Vyncke (evyncke) wrote: > Just re-read your I-D, here are some comments: > - in the intro, 'van dijk' scanning via reverse DNS is no more 'recent' > IMHO (update also section 4.4) Agreed. Will do. > - section 3.1.1 is yet another explanation of SLAAC & Co, I usually prefer > avoiding repetition because they may introduce discrepancy or > incoherencies => remove those parts from the I-D? What about only talking > about EUI-64 for example? FWIW, the reason for which this part is included is that they key to doing host scanning in IPv6 is reducing the search space. -- that's why we essentially describe each of the algorithms that are commonly employed to generate the addresses, and then compute the approximate search space.... > - section 3.1.2 about DHCP, probably worth to say that some DHCP servers > change the leased address(es) every few hours/days while others keep the > same address(es) for years (even if the DHCP client went away for months) Good point. Will do. > - section 3.3 about local mcast probe, a lot of networks (think large > wifi) prevent direct WiFi client to WiFi client communication, or isolate > hosts to communication to each others (hosting providers for example), so, > this method of scanning is not always efficient. Good point, will add. > My default Mac OS/X configuration also prevents replying to any ICMP echo request... Wasn't aware about Mac OS... I expected them to follow FreeBSD in this respect. BTW, what version of Mac OS are you using? 8to check if this was changed for recent versions, or has been the case for a while now). > - section 3.4 not sure whether an inventory of existing scanning tools is > valuable and this is an every changing world IMHO, pointers to tools can be useful for folks willing to play/asses their networks -- particularly when many of the popular tools have little to no IPv6 support. > - 3.5 about mitigations, IPFIX can also help a lot with regard to > detecting a scan Anything better than "IPFIX [RFC7011] could also be of help to detect host scanning attacks"? > - 3.5 I do not like the idea that error messages should not be generated > when destination is a multicast... That's in the specs already (RFC4443) -- the only thing that I had proposed to change at the time was the response to unsupported options of type 10xxxxxx. > We need at least packet too big as well > as parameter problem if we still dream about mcasted IPv6 video streaming That would go against RFC4443. > - section 3.5 mitigations is in the middle of scanning techniques? Move it > apart? Or build a mitigation section in all other scanning techniques? Section 3.5 is a subsection of the "address scanning" section (section 3). It's true that the other sections do not have a mitigations subsections -- mostly becaus they boils down to "'It's impossible' or 'stop using that application'". Three options: 1) Leave as is 2) Have a top-level Section called "Mitigations", which would include the contents of Section 3.5, and also note that for the other vectors there's not much that you can do other than "stop using the orresponing protocol" (which, of course, in virtually all cases is not applicable). 3) Add a "Mitigations" subsection to each of the top-level sections... However, this would mess a bit with the index.. and many of such sections would have not much text. Thoughts? Me, I'd opt for 1 or 3 above. > - section 4.4, should there be a recommendation to optionally change the > reply code of reverse DNS servers? More work to be done in DNSEXT? Or > DNSOP? I had checked this before, and apparently "it was not possible". But please let me re-check again. > - section 8 (ND cache), it is not only by 'login' but also available > through SNMP (see also section 5 of draft-ietf-opsec-v6) Myabe we should ahve said "auth required" instead of "login"? -- The point was that if yu're an attacker, you might need credentials to access the aforementioned info. > - section 10 (routing protocols), not sure whether it can really help to > scan except by providing the prefixes and in some case some router > interface addresses (but trace route is there anyway) We might tweak the text noting that it might be of help for learning subnets rather than IIDs... > - appendix A, not sure whether it brings value FWIW, goal here was to provide some guidance for folks working n e.g. en-testing frameworks. - Most of the popular famewroks are rather clueless regarding how to learn the v6 addresses of potential targets (of couse, for v4 they do brute-forcing). > May I suggest to add also IPFIX as it can aggregate the flows by source > addresses, hence, getting a list of all addresses. See also section > 2.5.1.2 of draft-ietf-opsec-v6. Duble-checking: This would be for *legitimate* audits of *active* nodes, right? > While at the beginning the I-D rightfully discusses about the two purposes > of scanning (bad guys and good guys doing inventory), the main focus of > the document appears to be on mitigation techniques (i.e. Prevent > scanning) while very few on helping the good guys to build an inventory. > > May I also suggest that SAVI RFC 6620 also builds a cache of MAC/IPv6 > without actively participating in the NDP exchange, so, it is also another > source of information. Will do. > You may also want to add simple traceroutes as they discover the IP > addresses of routers. Good pint. > Lastly, and not sure about that point, should we drop a can full of worms > in the document? Telling readers that using ULA and NAT is perhaps worse > than the benefit? ;-) (it is Friday after all) Let's drop the can, but in a separate document. ;-)) (That aside, for scanning purposes, a diode-firewall would mostly do). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jun 23 21:38: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 886C61A03F4 for ; Mon, 23 Jun 2014 21:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTeJ1tO8_weX for ; Mon, 23 Jun 2014 21:38:18 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7DF1B2823 for ; Mon, 23 Jun 2014 21:38:17 -0700 (PDT) Received: (qmail 11498 invoked from network); 23 Jun 2014 21:38:16 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jun 2014 21:38:16 -0700 Date: Mon, 23 Jun 2014 21:38:16 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Fernando Gont In-Reply-To: <53A87B38.70000@si6networks.com> Message-ID: References: <20140614235413.1154.20100.idtracker@ietfa.amsl.com> <53A87B38.70000@si6networks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/tkhrRM_MWL3niq39wenWrYt7qEQ Cc: "opsec@ietf.org" , Tim Chown , "v6ops@ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.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, 24 Jun 2014 04:38:20 -0000 On Mon, 23 Jun 2014, Fernando Gont wrote: > On 06/20/2014 12:13 PM, Eric Vyncke (evyncke) wrote: > > - 3.5 I do not like the idea that error messages should not be generated > > when destination is a multicast... > > That's in the specs already (RFC4443) -- the only thing that I had > proposed to change at the time was the response to unsupported options > of type 10xxxxxx. > > > We need at least packet too big as well > > as parameter problem if we still dream about mcasted IPv6 video streaming > > That would go against RFC4443. That's not what I read. Section 2.4(e) says: (e) An ICMPv6 error message MUST NOT be originated as a result of receiving the following: (e.1) An ICMPv6 error message. (e.2) An ICMPv6 redirect message [IPv6-DISC]. (e.3) A packet destined to an IPv6 multicast address. (There are two exceptions to this rule: (1) the Packet Too Big Message (Section 3.2) to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 (Section 3.4) reporting an unrecognized IPv6 option (see Section 4.2 of [IPv6]) that has the Option Type highest- order two bits set to 10). Seems like PTB is always allowed/required. //cmh From nobody Mon Jun 30 09:32: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 DE9CD1A03C1 for ; Mon, 30 Jun 2014 09:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z89HDqAc0mvM for ; Mon, 30 Jun 2014 09:32:26 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27691A03BF for ; Mon, 30 Jun 2014 09:32:05 -0700 (PDT) Received: from mbp.local (c-67-171-230-191.hsd1.wa.comcast.net [67.171.230.191]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s5UGW0qs067589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 30 Jun 2014 16:32:00 GMT (envelope-from joelja@bogus.com) Message-ID: <53B190FA.40503@bogus.com> Date: Mon, 30 Jun 2014 09:31:54 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <53A64F47.7020602@bogus.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A0EcH4oVqVQbsFLl6c4v0pR2PjtQivCQE" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 30 Jun 2014 16:32:00 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/kg3mLIFz8SeXPsmBmEe7eQZ4M8w Cc: "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs , "opsec@ietf.org" Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages proposed IESG note text. 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, 30 Jun 2014 16:32:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A0EcH4oVqVQbsFLl6c4v0pR2PjtQivCQE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/21/14 9:29 PM, Fred Baker (fred) wrote: > On Jun 21, 2014, at 8:36 PM, joel jaeggli wrote: > >> Folks, >> >> After some roundabout attempts at clearing the discuss on >> draft-ietf-opsec-vpn-leakages the following text has been proposed by >> the IESG as a note on the document. It could proceed to the rfc editor= >> queue with this text in place. We could also adjust the document >> accordingly, however at this point, the current position is farily har= d won. >> >> Thoughts would be appreciated. >> >> joel >> --- >> >> This document describes a problem of information leakage in VPN softwa= re >> and attributes that problem to the software's inability to deal with >> IPv6. We do not think this is an appropriate characterization of the >> problem. It is true that when a device supports more than one address >> family, the inability to apply policy to more than one address family = on >> that device is a defect. Despite that, inadvertent or >> maliciously-induced information leakage may also occur due to the >> existence of any unencrypted interface allowed on the system, includin= g >> the configuration of split tunnels in the VPN software itself. While >> there are some attacks that are unique to an IPv6 interface, the sort = of >> information leakage described by this document is a general problem th= at >> is not unique to the situation of IPv6-unaware VPN software. We do not= >> think this document sufficiently describes the general issue. > I might suggest that this text say who =93we=94 is. Clearly, those who = wrote the draft, who might otherwise be described in the first person plu= ral, must disagree with that assessment. > > Personally, if the final sentence is the considered opinion of the IESG= , I would rather not publish as an RFC - a permanent archival document - = a description that the same RFC says is inadequate. I would rather that t= he IESG return the document to the working group and request a replacemen= t that =93sufficiently describes the general issue=94. I would hold that option out to the w.g. and the authors, Though I don't personally think the effort to produce a document for the purpose satisfying the IESG as a particularly worthy goal. So if the sentiment (which as I interpret it as being the case) is that the document in present form adresses a real problem and that it should be dealt with in a discrete fashion rather than rolled up with the generic problem of split tunneling then I can live with myself. --A0EcH4oVqVQbsFLl6c4v0pR2PjtQivCQE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOxkPoACgkQ8AA1q7Z/VrKH3QCcClS9o6ptwDewIp4LyY/HlTiM MgUAn05HmYA+ItUqurdPQ+stFU+Om/xv =FDG6 -----END PGP SIGNATURE----- --A0EcH4oVqVQbsFLl6c4v0pR2PjtQivCQE-- From nobody Mon Jun 30 19:59:42 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 39E3B1A0452 for ; Mon, 30 Jun 2014 19:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 FRZe8njd5GIv for ; Mon, 30 Jun 2014 19:59:35 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DC81A00DE for ; Mon, 30 Jun 2014 19:59:33 -0700 (PDT) Received: from [2001:1291:2e6:1:9530:47d4:daf9:ac3b] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X1oHr-0003kT-BD; Tue, 01 Jul 2014 04:59:15 +0200 Message-ID: <53B1CC20.7060602@si6networks.com> Date: Mon, 30 Jun 2014 17:44:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: joel jaeggli , "Fred Baker (fred)" References: <53A64F47.7020602@bogus.com> <53B190FA.40503@bogus.com> In-Reply-To: <53B190FA.40503@bogus.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/IJbtvEy8USynohppO_kxGbLHZGs Cc: "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs , "opsec@ietf.org" Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages proposed IESG note text. 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, 01 Jul 2014 02:59:37 -0000 On 06/30/2014 01:31 PM, joel jaeggli wrote: >> >> Personally, if the final sentence is the considered opinion of >> the IESG, I would rather not publish as an RFC - a permanent >> archival document - a description that the same RFC says is >> inadequate. I would rather that the IESG return the document to >> the working group and request a replacement that “sufficiently >> describes the general issue”. > I would hold that option out to the w.g. and the authors, Though I > don't personally think the effort to produce a document for the > purpose satisfying the IESG as a particularly worthy goal. So if > the sentiment (which as I interpret it as being the case) is that > the document in present form adresses a real problem and that it > should be dealt with in a discrete fashion rather than rolled up > with the generic problem of split tunneling then I can live with > myself. Agreed. This point has been made a number of times already on the mailing-list (and off-list too). That aside, the argument of "this being a specific case of split tunelling" has been argued against both on and off-list. This post summarizes the issue pretty well, I think: (and comes with the "extra" of someone working on VPN code). But at this point in time I can live with the IESG note, if that's what it takes. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492