On Jan 17, 2015, at 2:36 PM, Charles Winsett <charlestonya74@gmail.com> wrote:

Who's on my opsec accou= nt?

___________________= ____________________________
OPSEC mailing list
<= span>OPSEC@ietf.org
https://www.ietf.o= rg/mailman/listinfo/opsec

--
I don't think the execution is relevant when it was o= bviously a bad idea in the first place.
This is like putting rabid wease= ls in your pants, and later expressing regret at having chosen those partic= ular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf
--047d7b5d8a1184956d050ce36f91-- From nobody Sun Jan 18 23:59:21 2015 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 6D00E1AD17F; Sun, 18 Jan 2015 23:59:20 -0800 (PST) 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 7KQtyw-leGj5; Sun, 18 Jan 2015 23:59:13 -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 9E3661ACEBD; Sun, 18 Jan 2015 23:59:13 -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 1YD7EZ-00006D-Cb; Mon, 19 Jan 2015 08:58:51 +0100 Message-ID: <54BCB88F.9050304@si6networks.com> Date: Mon, 19 Jan 2015 04:55:59 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Smith, Donald" , "ietf@ietf.org" References: <20141117195209.16129.53872.idtracker@ietfa.amsl.com> <68EFACB32CF4464298EA2779B058889D24C2AFA4@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D24C2AFA4@PDDCWMBXEX503.ctl.intranet> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "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: Mon, 19 Jan 2015 07:59:20 -0000 Hi, Donald, Not sure if any of us had responded to this one, but, just in case, here I go (please find my responses in-line): On 11/18/2014 04:04 PM, Smith, Donald wrote: > > 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 should probably > be replaced with "original packet" and rfc reference. Nope. They are different things: The original packet is the packet your host produces but never hits the wire (when you're employing fragmentation). OTOH, the first fragment is a fragment with the FO==0. > pg 3. > > IPv6 Header Chain:... > > Seems mostly correct but again why restate what is described in > rfc2460 section 4? When we did RFC7112 at 6man, the wg asked us to have all these definitions... > 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 dhcp msg header wouldn't it default to allow not drop? ( MUST > drop if see dhcp , MUST allow if not?) > > So wouldn't you be more likely to have false negatives because the > whole header wasn't examined? You're right. Fixed! > > 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? We need a specific action regarding unrecognized Next Header values here.. that's why. > 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 be much good. > > ... The logging mechanism SHOULD include a per port drop counter ... Done. Thanks! > Note here it says DHCPv6 Shield even though above the logging appears > to include "unrecognized Next Header". Would the counter include both > or just DHCPv6 Shield drops? Maybe two counters (but then we are out > of scope for dhcp again?) I guess the "per port drop counter" would be the minimum required... but an implementation can always do better than that. > 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? We've been asked to -- although me, I'd probably agree with you. > SILICON SENSE I think it would make more sense to require dhcpv6 > requests come from a special 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 ports but that is much simpler > from an silicon point of view. It would also require changes to the > dhcpv6 clients but does simplify the solution from a hw pov. But this is not backwards-compatible.... > 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 shared npu? We have that problem today with layer 3 routing an > headers do we want to push this to the next layer down? FWIW, whether a vendor implements this in hw or software is out of scope. As you correctly note, doing this in software has its implications... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 19 00:52:40 2015 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 4DE201AD2D9; Mon, 19 Jan 2015 00:52:37 -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 14w4Aeg4RpF0; Mon, 19 Jan 2015 00:52:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E56A1AD338; Mon, 19 Jan 2015 00:52:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119085235.12376.29135.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 00:52:35 -0800 Archived-At: Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 08:52:37 -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-05.txt Pages : 10 Date : 2015-01-19 Abstract: This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6 Shield. 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 19 21:41:51 2015 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 F0C671AD09A for ; Mon, 19 Jan 2015 21:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxIgolHsC0WP for ; Mon, 19 Jan 2015 21:41:38 -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 DA4861AD094 for ; Mon, 19 Jan 2015 21:41:35 -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 1YDRZ8-0006y9-I7; Tue, 20 Jan 2015 06:41:26 +0100 Message-ID: <54BDEA78.8020403@si6networks.com> Date: Tue, 20 Jan 2015 02:41:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" , Tim Chown References: <20140614235413.1154.20100.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "opsec@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, 20 Jan 2015 05:41:41 -0000 Hi, Eric, [Looks like this was in my "Drafts" folder and never got sent. - shame on me] Some additional notes... On 06/20/2014 12:13 PM, Eric Vyncke (evyncke) wrote: > - 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) So even when the client suggests an address, the server(s) force some other address t be configured? Do you have any references for this behavior? > - section 3.3 about local mcast probe, a lot of networks (think large > wifi) prevent direct WiFi client to WiFi client communication, So there's no way to do e.g. P2P among them?? Is there anything we could reference here? > or isolate > hosts to communication to each others (hosting providers for example), so, Not sure what you mean... > - 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? Last time I checked with DNS folks, I seem to recall them saying that this wasn't possible -- although I wasn't convinced about it. Will poll other folks and re-check mysef (this one left in the TODO queue). > - section 8 (ND cache), it is not only by 'login' but also available > through SNMP (see also section 5 of draft-ietf-opsec-v6) I've tweaked the text and also added a reference to draft-ietf-opsec-v6. However, the relevant section seems to be Section 2.5.1.4 rather than Section 5, right? > - 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) Agreed. Although with traceroute you need a destination address in the first place (to traceroute to). > 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. Yep, added. Thanks! > 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. I'd say that most of the techniques that require some sort of credentials are only of use to the good guys... > 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. Yep. Added to the same section discussing "ND Cache inspecion". Thanks! > You may also want to add simple traceroutes as they discover the IP > addresses of routers. Added. Thanks so much! > 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) My experience seems to indicate that adding "NAT" to any document (particularly if IPv6-related) is asking for trouble. :-)) -- So I'd personally leave that out. :-) 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 Mon Jan 19 22:18:46 2015 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 0FECF1AD0A3; Mon, 19 Jan 2015 22:18:37 -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 NQwVInwIr3CQ; Mon, 19 Jan 2015 22:18:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC9B1ACE6D; Mon, 19 Jan 2015 22:18:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120061835.24466.85116.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 22:18:35 -0800 Archived-At: Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 06:18:37 -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-05.txt Pages : 32 Date : 2015-01-19 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-host-scanning-05 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 Jan 23 02:55:06 2015 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 6ED061A1A98 for ; Fri, 23 Jan 2015 02:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tUbGxtxPzIRo for ; Fri, 23 Jan 2015 02:55:01 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B848E1A0BE8 for ; Fri, 23 Jan 2015 02:55:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 86D16871615; Fri, 23 Jan 2015 11:54:59 +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 cW85HpsdvJuQ; Fri, 23 Jan 2015 11:54:59 +0100 (CET) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:355b:93bf:904e:97d3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 52CBF870009; Fri, 23 Jan 2015 11:54:59 +0100 (CET) Message-ID: <54C2287D.50603@globis.net> Date: Fri, 23 Jan 2015 11:54:53 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: opsec@ietf.org Subject: Re: [OPSEC] I-D Action:, draft-ietf-opsec-ipv6-host-scanning-05.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, 23 Jan 2015 10:55:03 -0000 On the whole, this draft is already in a very good state. I have some additional input for this draft I think it's also useful to distinguish between on-link and on-net attacks. New reconnaissance method: 3.1.2.1 Snooping of DHCPv6 relay packets DHCPv6 deployment in enterprise networks often relies on one or more centrally located DHCPv6 servers that serve the entire enterprise from one or more highly-available sites. Although the end host interacts with local on-link routers, these router may forward the DHCPv6 requests over the WAN to the centrally located DHCPv6 server(s) using DHCPv6 relay [https://tools.ietf.org/html/rfc3315#section-7] The relay packets are not encrypted and thus may be vulnerable to on-net snooping, potentially allowing an attacker to leverage existing on-net access to gain additional knowledge about remote LANs that they do not yet have access to. Obtaining access to a DHCPv6 server would also be a very high value target, and such servers should be tightly secured. Some potential additional text for 3.2.1 > 3.2.1. Reducing the subnet ID search space There are a number of documents available online e.g. [http://www.ietf.org/rfc/rfc5375.txt http://www.ripe.net/ripe/docs/ripe-552 ] that provide recommendations for allocation of address space in the /3 to /64 range, which address various operational considerations, including: RIR assignment policy, ability to delegate reverse DNS zones to different servers, ability to aggregate routes efficiently, address space preservation, ability to delegate address assignment within the organization, ability to add allocate new sites/prefixes to existing entities without updating ACLs, and ability to de-aggregate and advertise sub-spaces via various AS interfaces. Some of the allocation databases may even be publicly searchable. Allocation schemes may also be algorithmic e.g. simple incremental from 1 upwards, but also sparse allocation over a fixed bit range [http://www.ripe.net/ripe/docs/ripe-343#3] The net effect of these administrative policies is that the address space from 2000/3 to the /64 prefix assigned to a LAN may be highly structured, and allocations of individual elements within this structure may be predictable once other elements are known. For example, if an attacker assumes or knows that the address space contains a "region of 6 bits that is sparsely assigned" then region 1 =1 region 2 may be 32, region 3 may be 16). This assumption may be easily tested with just a few probes (e.g. by waiting for an ICMP unreachable reply from an upstream router). Thus the amount of entropy for this portion of the address search space from /3 to /64 may be vastly reduced compared to uniformly random /64 allocations. > 12. Obtaining Network Information with traceroute6 As well as using traceroute6 as a source of information, if an organization allows ICMP unreachable messages from routers, an on-net attacker could probe the subnet search space to gain knowledge of the network structure, and thus the address assignment policy. For example, if a large number of traceroutes, or indeed any other connection probe, consistently generate a response with an ICMP unreachable Type 1 code 0 "no route to destination", all originating from a common router on the path, this could indicate that this router is either a boundary router, or a router that it performs route aggregation. This then gives a hint of how the address space is structured for reducing the subnet ID search space. 11. Gleaning Information from switch MAC tables and other equipment using SNMP If the underlying infrastructure is not properly secured, an attacker can use knowledge gained from the switch TCAM forwarding table to learn network structure, as well as MAC addresses in use in the network, which can in many cases be mapped back to IPv6 addresses and machines. Obviously SNMP and other management access should be secured. -- Regards, RayH From nobody Fri Jan 23 23:20:44 2015 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 D16AF1A0122 for ; Fri, 23 Jan 2015 23:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJRAP9owlNdz for ; Fri, 23 Jan 2015 23:20:38 -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 328151A00E9 for ; Fri, 23 Jan 2015 23:20:38 -0800 (PST) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YEv0v-0005ng-KS; Sat, 24 Jan 2015 08:20:15 +0100 Message-ID: <54C3478C.6040503@si6networks.com> Date: Sat, 24 Jan 2015 04:19:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ray Hunter , draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org References: <54C2287D.50603@globis.net> In-Reply-To: <54C2287D.50603@globis.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: opsec@ietf.org Subject: Re: [OPSEC] I-D Action:, draft-ietf-opsec-ipv6-host-scanning-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 07:20:41 -0000 Hi, Ray, Thanks so much for your usual great feedback! -- Please find my comments in-line.... On 01/23/2015 07:54 AM, Ray Hunter wrote: > On the whole, this draft is already in a very good state. Thanks! > I have some additional input for this draft > > I think it's also useful to distinguish between on-link and on-net attacks. > > New reconnaissance method: > > 3.1.2.1 Snooping of DHCPv6 relay packets > > DHCPv6 deployment in enterprise networks often relies on one or more > centrally located DHCPv6 servers that serve the entire enterprise from > one or more highly-available sites. > > Although the end host interacts with local on-link routers, these router > may forward the DHCPv6 requests over the WAN to the centrally located > DHCPv6 server(s) using DHCPv6 relay > [https://tools.ietf.org/html/rfc3315#section-7] Dumb question: Doesn't this imply that if you have e.g. issues with the WAN link you cannot even bootstrap your local nodes? > The relay packets are not encrypted and thus may be vulnerable to on-net > snooping, potentially allowing an attacker to leverage existing on-net > access to gain additional knowledge about remote LANs that they do not > yet have access to. Obtaining access to a DHCPv6 server would also be a > very high value target, and such servers should be tightly secured. I'm unsure regarding whether to include this as 3.1.2.*, or rather include a more general top-level section of snooping, which mentions DHCPv6 as a particular case -- e.g., ND snooping is another interesting case. Thoughts? > Some potential additional text for 3.2.1 >> 3.2.1. Reducing the subnet ID search space > > There are a number of documents available online e.g. > [http://www.ietf.org/rfc/rfc5375.txt > http://www.ripe.net/ripe/docs/ripe-552 ] that provide recommendations > for allocation of address space in the /3 to /64 range, which address > various operational considerations, including: RIR assignment policy, > ability to delegate reverse DNS zones to different servers, ability to > aggregate routes efficiently, address space preservation, ability to > delegate address assignment within the organization, ability to add > allocate new sites/prefixes to existing entities without updating ACLs, > and ability to de-aggregate and advertise sub-spaces via various AS > interfaces. > > Some of the allocation databases may even be publicly searchable. > Allocation schemes may also be algorithmic e.g. simple incremental from > 1 upwards, but also sparse allocation over a fixed bit range > [http://www.ripe.net/ripe/docs/ripe-343#3] > > The net effect of these administrative policies is that the address > space from 2000/3 to the /64 prefix assigned to a LAN may be highly > structured, and allocations of individual elements within this structure > may be predictable once other elements are known. For example, if an > attacker assumes or knows that the address space contains a "region of 6 > bits that is sparsely assigned" then region 1 =1 region 2 may be 32, > region 3 may be 16). This assumption may be easily tested with just a > few probes (e.g. by waiting for an ICMP unreachable reply from an > upstream router). > > Thus the amount of entropy for this portion of the address search space > from /3 to /64 may be vastly reduced compared to uniformly random /64 > allocations. I like the text you've suggested. My only observation would be: not sure why you mention /3.. Unless the attacker mens to "scan the whole IPv6 Internet (unlikely), he'l probably start with a /32 or /48... > 12. Obtaining Network Information with traceroute6 > > As well as using traceroute6 as a source of information, if an > organization allows ICMP unreachable messages from routers, an on-net > attacker could probe the subnet search space to gain knowledge of the > network structure, and thus the address assignment policy. For example, > if a large number of traceroutes, or indeed any other connection probe, > consistently generate a response with an ICMP unreachable Type 1 code 0 > "no route to destination", all originating from a common router on the > path, this could indicate that this router is either a boundary router, > or a router that it performs route aggregation. This then gives a hint > of how the address space is structured for reducing the subnet ID search > space. I'm not sure I followed the part "This then gives a hint...".. Would you mind elaborating a it? > 11. Gleaning Information from switch MAC tables and other equipment > using SNMP > > If the underlying infrastructure is not properly secured, an attacker > can use knowledge gained from the switch TCAM forwarding table to learn > network structure, as well as MAC addresses in use in the network, which > can in many cases be mapped back to IPv6 addresses and machines. > Obviously SNMP and other management access should be secured. This makes sense. Now, since SNMP is also mentioned for the Neighbor Cache, I wonder how to include this info. -- e.g., keep the document "as is" and just add a top-level section entitled "Gleaning Information from network devices using SNMP" and have that section cover switch TCAM table, Neighbor Cache, routing table and others? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jan 25 05:51:28 2015 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 045C21A1A60 for ; Sun, 25 Jan 2015 05:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.588 X-Spam-Level: X-Spam-Status: No, score=0.588 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AH9dmLtMmAH9 for ; Sun, 25 Jan 2015 05:51:24 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id C43D61A1A55 for ; Sun, 25 Jan 2015 05:51:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 76E26871628; Sun, 25 Jan 2015 14:51:22 +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 zDhPjuSmd1ul; Sun, 25 Jan 2015 14:51:22 +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 552A9870009; Sun, 25 Jan 2015 14:51:22 +0100 (CET) Message-ID: <54C4F4D0.7040301@globis.net> Date: Sun, 25 Jan 2015 14:51:12 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Fernando Gont References: <54C2287D.50603@globis.net> <54C3478C.6040503@si6networks.com> In-Reply-To: <54C3478C.6040503@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: opsec@ietf.org, draft-ietf-opsec-ipv6-host-scanning@tools.ietf.org Subject: Re: [OPSEC] I-D Action:, draft-ietf-opsec-ipv6-host-scanning-05.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: Sun, 25 Jan 2015 13:51:27 -0000 > Fernando Gont > 24 January 2015 08:19 > Hi, Ray, > > Thanks so much for your usual great feedback! -- Please find my comments > in-line.... > > On 01/23/2015 07:54 AM, Ray Hunter wrote: >> On the whole, this draft is already in a very good state. > > Thanks! > > > >> I have some additional input for this draft >> >> I think it's also useful to distinguish between on-link and on-net attacks. >> >> New reconnaissance method: >> >> 3.1.2.1 Snooping of DHCPv6 relay packets >> >> DHCPv6 deployment in enterprise networks often relies on one or more >> centrally located DHCPv6 servers that serve the entire enterprise from >> one or more highly-available sites. >> >> Although the end host interacts with local on-link routers, these router >> may forward the DHCPv6 requests over the WAN to the centrally located >> DHCPv6 server(s) using DHCPv6 relay >> [https://tools.ietf.org/html/rfc3315#section-7] > > Dumb question: Doesn't this imply that if you have e.g. issues with the > WAN link you cannot even bootstrap your local nodes? > That is correct. However, commercial pressure means that many sites do not have any local IT presence at all. They may not have any servers at all on site. IPAM systems are already widely used, but are expensive per appliance, and so are centralised for everything except the largest business critical sites. On the other hand, WAN links have been much cheaper and more reliable over the years. So a "zero server on site" has become a common deployment mode in my experience. People can't work without a WAN link anyway as the biggest corporate apps are concentrated in data centres. > >> The relay packets are not encrypted and thus may be vulnerable to on-net >> snooping, potentially allowing an attacker to leverage existing on-net >> access to gain additional knowledge about remote LANs that they do not >> yet have access to. Obtaining access to a DHCPv6 server would also be a >> very high value target, and such servers should be tightly secured. > > I'm unsure regarding whether to include this as 3.1.2.*, or rather > include a more general top-level section of snooping, which mentions > DHCPv6 as a particular case -- e.g., ND snooping is another interesting > case. > > Thoughts? I think a general section on passive monitoring/snooping is a good way to go. It could include snooping many protocols that be levered up: HTTP to discover proxies or servers, DNS to discover more hosts and DNS servers, DHCPv6 relay to discover more end nodes, ND to discover local neighbours. > > >> Some potential additional text for 3.2.1 >>> 3.2.1. Reducing the subnet ID search space >> There are a number of documents available online e.g. >> [http://www.ietf.org/rfc/rfc5375.txt >> http://www.ripe.net/ripe/docs/ripe-552 ] that provide recommendations >> for allocation of address space in the /3 to /64 range, which address >> various operational considerations, including: RIR assignment policy, >> ability to delegate reverse DNS zones to different servers, ability to >> aggregate routes efficiently, address space preservation, ability to >> delegate address assignment within the organization, ability to add >> allocate new sites/prefixes to existing entities without updating ACLs, >> and ability to de-aggregate and advertise sub-spaces via various AS >> interfaces. >> >> Some of the allocation databases may even be publicly searchable. >> Allocation schemes may also be algorithmic e.g. simple incremental from >> 1 upwards, but also sparse allocation over a fixed bit range >> [http://www.ripe.net/ripe/docs/ripe-343#3] >> >> The net effect of these administrative policies is that the address >> space from 2000/3 to the /64 prefix assigned to a LAN may be highly >> structured, and allocations of individual elements within this structure >> may be predictable once other elements are known. For example, if an >> attacker assumes or knows that the address space contains a "region of 6 >> bits that is sparsely assigned" then region 1 =1 region 2 may be 32, >> region 3 may be 16). This assumption may be easily tested with just a >> few probes (e.g. by waiting for an ICMP unreachable reply from an >> upstream router). >> >> Thus the amount of entropy for this portion of the address search space >> from /3 to /64 may be vastly reduced compared to uniformly random /64 >> allocations. > > I like the text you've suggested. My only observation would be: not sure > why you mention /3.. Unless the attacker mens to "scan the whole IPv6 > Internet (unlikely), he'l probably start with a /32 or /48... > Sure. I'd also start with the local LAN and local site, but the scanner may also want to perform off-LAN/off-site reconnaissance once that is exhausted. The starting assumption I'm making is that the scanning device / code has been dropped onto a network without any further knowledge, expect for it's own address, and that of its default router (learned via RA). Of course if more information is available then the scanning process can be seeded with priority targets. The premise of IPv6 being un-scannable seems to be based on the fact that 2^128 is a big number. However there are some major holes to this premise: 1) the address space has significant structure 2) the address space is administered by people 3) brute-force scans do not have to be exhaustive or run independently of other attacks; they can be successful if they merely provide additional hints/targets to other attack vectors, which can in turn re-seed the scan. so looking at the entire 128 bit space, an attacker can divide and conquer. The first level of hierarchy in the 128 bit space that can be leveraged is that the IETF has allocated all current unicast address space out of 2000::/3. So all scan engines can immediately limit the target space to 2000:/3 space for all practical purposes. Hence the /3 I named. The second assumption is that the /64 boundary is very strong (and has been re-affirmed/explained by the IETF as being important). So a scanning engine can legitimately assume that there are two independent address spaces to scan: the upper 64 bits [LAN ID] and lower 64 bits [IID]. The third assumption is that CIDR is still deployed. So knowledge about a shorter mask can be re-used for all longer masks. In IPv4, address space was rare, and nodes were densely packed, so that when brute-force scanning, a positive response from one node could be leveraged to find surrounding nodes. This can be leveraged up for in IPv6 because the exact opposite is true: address space is large and nodes are sparsely allocated, So an uncertain negative response that a /48 is not routed in the network can be leveraged up to mean that all longer masks are probably not allocated. Almost no one runs flat networks, as slots in the routing table are still expensive. ICMPv6 is a much more engrained part of IPv6 in that PTB and other messages are required for normal operation of the protocol, so at the moment ICMPv6 information is more valuable than ICMP information. The fourth assumption that can be leveraged is that address space that the top level is allocated by an RIR. If a scanning node can either contact an online RIR database, or comes shipped with a copy of the RIR database, the scanning node can learn which prefixes have been allocated to this organisation simply based on it's own IPv6 GUA. The total target scanning space in the upper /64 can then be further safely limited initially to /32 to /64 = 32 bits. Also an attacker can easily look up the local 2001:DB8::/32 and find any other associated entries e.g. /32 allocation from other regions, /48 allocations, routing DB entries..... The fifth assumption is that address space is aggregated, or allocated by humans, and humans are lazy. The address space in the /32 to /64 range is also likely to be allocated on 4 bit nibbled (to allow easy reverse DNS delegation, simple ACLs, route aggregation and de-aggregation, organisational delegation to site/regional IT managers etc.) So you now have 32 bits to scan as top priority [from 2001:DB8::/64 to 2001:DB8:FFFF:FFFF::/64] (after the local /64 LAN). That problem can then be tackled by subdividing the space between /32 and /64 into 8 off 4 bit nibbles. It's irrelevant to the scanner what these nibbles mean, e.g. whether they are a region, or a product division, or a /48 site allocation. What is key to the scanner is to be able to perform a binary search on this space and discover differentiated results. So a Patricia Tree can be used to store results of structured probes, with each branch of the tree keyed on a 4 bit nibble. Such a structure can efficiently store the results of millions of probes and pick out patterns in the /32 to /64 space on nibble boundaries. Using assumption 3, 4, and 5 together, the attacker can send various probes to e.g. HTTP connect 2001:DB8:0:1::node_1/32, telnetconnect 2001:DB8:0:1::node_2/32 , HTTP connect 2001:DB8:1:1::node_1/32 with various hop count limits and various prefix lengths. By examining the results of each probe at each node in the Patrica tree, common patterns at bit/nibble boundaries will emerge. e.g. a Type 3 code 0 response at a common router will show what address space is allocated behind that router. That can be either actively or passively searched using binary prefix length expansion. Or receiving an ICMv6 Type 1 code 0 from regional aggregation routers, or site boundary routers. Given the scarcity of IPv6 allocations, it's pretty likely to be able to obtain many "no route to host" responses for few probes. It will then be possible to reproduce a portion of the routing prefixes used in the network and their prefix length. Once an attacker sees that a site has a /48 boundary, the scanner can then again probe binary variations of the range /32 to /48 to find other site boundary routers, or existence of a second aggregation point e.g. a regional allocation boundary. Especially since the allocations within the bit block will likely be based on one of 3 methods. i) linear allocation 1,2,3.... ii) sparse allocation on a specific block length right justified, enumerated as 0,8,4,6 ..... for a 4 bit field or 0,32,16,38 for a 6 bit field iii) site/LAN/region 0 reserved for infra services (so that these address have long chains of 0:0 that can be easily typed as ::) These assumptions can be easily tested using a relatively small number of probes compared to the address space covered. For example, once the allocation method has been established or guessed as [32 bits from RIR]:[4 bits region][12 bits site ID][16 bits LAN ID]:[64 bit IID] or [32 bits from RIR]:[8 bits region][8 bits site ID][16 bits LAN ID]:[64 bit IID] These individual ranges within the overall structure can be scanned separately using different techniques, and different methods of enumeration. It now becomes relatively easy to independently enumerate regions [4 or 8 bits], sites within a region[12 or 8 bits], and LAN IDs within a site [16 bits], and to test for their existence. Once it is confirmed that a particular region doesn't exist (e.g. using ICMP no route to host), or a site doesn't exist, all further scans of longer prefixes are unnecessary. The [64 bit IID] can also be split into [6 hex nibbles manufacturers OID][4 hex nibbles pad][6 hex nibbles] if stable privacy addresses are not in use. The number of [Manufacturers OID's] per target company is also usually limited. And clusters do occur in IID on machines shipped on a similar date. Also all site LAN routers may be assigned [32 bits from RIR]:[8 bits region][8 bits site ID][16 bits LAN ID]::1, so that they can easily be pinged from a central network management station. An attacker can also effectively hide their own identity by rate limiting probes, and regularly re-assigning multiple privacy addresses. If an attacker can send 1024 probes per second (not unreasonable as noise on large networks) a 6 nibble space MAC space can be scanned in about 5 hours once the upper 64 bits have been discovered. If there are 5-16 or so common manufacturers OID's in place, a /64 could be roughly scanned in a matter of days. This is orders of magnitude different to a full /128 space without structure, and is certainly feasible IMHO. > >> 12. Obtaining Network Information with traceroute6 >> >> As well as using traceroute6 as a source of information, if an >> organization allows ICMP unreachable messages from routers, an on-net >> attacker could probe the subnet search space to gain knowledge of the >> network structure, and thus the address assignment policy. For example, >> if a large number of traceroutes, or indeed any other connection probe, >> consistently generate a response with an ICMP unreachable Type 1 code 0 >> "no route to destination", all originating from a common router on the >> path, this could indicate that this router is either a boundary router, >> or a router that it performs route aggregation. This then gives a hint >> of how the address space is structured for reducing the subnet ID search >> space. > > I'm not sure I followed the part "This then gives a hint...".. Would you > mind elaborating a it? see above > >> 11. Gleaning Information from switch MAC tables and other equipment >> using SNMP >> >> If the underlying infrastructure is not properly secured, an attacker >> can use knowledge gained from the switch TCAM forwarding table to learn >> network structure, as well as MAC addresses in use in the network, which >> can in many cases be mapped back to IPv6 addresses and machines. >> Obviously SNMP and other management access should be secured. > > This makes sense. Now, since SNMP is also mentioned for the Neighbor > Cache, I wonder how to include this info. -- e.g., keep the document "as > is" and just add a top-level section entitled "Gleaning Information from > network devices using SNMP" and have that section cover switch TCAM > table, Neighbor Cache, routing table and others? > > Thanks! Agreed > Best regards, > -- Regards, RayH From nobody Sun Jan 25 09:50:52 2015 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 AB7B71A873D; Sun, 25 Jan 2015 09:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8z4gEp5xQ5G; Sun, 25 Jan 2015 09:50:45 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A3B1A873B; Sun, 25 Jan 2015 09:50:45 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id t0PHohjv015739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2015 11:50:43 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 185381E004F; Sun, 25 Jan 2015 11:50:38 -0600 (CST) Received: from lxomp06u.corp.intranet (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id F248C1E0049; Sun, 25 Jan 2015 11:50:37 -0600 (CST) Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id t0PHobIW056787; Sun, 25 Jan 2015 11:50:37 -0600 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id t0PHoboB056784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Jan 2015 11:50:37 -0600 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; Sun, 25 Jan 2015 10:50:37 -0700 From: "Smith, Donald" To: Fernando Gont , "ietf@ietf.org" Thread-Topic: [OPSEC] Last Call: (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best Current Practice Thread-Index: AQHQAqAggGhUU9glBUeO7HjNO+BtvpxmpelmgGFE6ICACZvX5w== Date: Sun, 25 Jan 2015 17:50:36 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D24C873C1@PDDCWMBXEX503.ctl.intranet> References: <20141117195209.16129.53872.idtracker@ietfa.amsl.com> <68EFACB32CF4464298EA2779B058889D24C2AFA4@PDDCWMBXEX503.ctl.intranet>, <54BCB88F.9050304@si6networks.com> In-Reply-To: <54BCB88F.9050304@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "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: Sun, 25 Jan 2015 17:50:48 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com > Hi, Donald, > > Not sure if any of us had responded to this one, but, just in case,= here > I go (please find my responses in-line): Thank you. > > On 11/18/2014 04:04 PM, Smith, Donald wrote: > > > > 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 sever= al > > instances of "initial fragment with offset of 0" that should prob= ably > > be replaced with "original packet" and rfc reference. > > Nope. They are different things: > > The original packet is the packet your host produces but never hits= the > wire (when you're employing fragmentation). Ahh I missed that distinction but get it now. > > OTOH, the first fragment is a fragment with the FO=3D=3D0. And more fragments flag set to 1? > > > > pg 3. > > > > IPv6 Header Chain:... > > > > Seems mostly correct but again why restate what is described in > > rfc2460 section 4? > > When we did RFC7112 at 6man, the wg asked us to have all these > definitions... > > > > > pg 4. I am not sure I understand this part. "RATIONALE: DHCPv6-Sh= ield > > implementations MUST NOT enforce a limit on the number of bytes t= hey > > can inspect (starting from the beginning of the IPv6 packet), sin= ce > > this could introduce false-positives: legitimate packets could be > > dropped simply because the DHCPv6-Shield device does not parse th= e > > entire IPv6 header chain present in the packet. An implementatio= n > > 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 no= t > > see an dhcp msg header wouldn't it default to allow not drop? ( M= UST > > drop if see dhcp , MUST allow if not?) > > > > So wouldn't you be more likely to have false negatives because th= e > > whole header wasn't examined? > > You're right. Fixed! > > > > > > 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 w= ith > > unrecognized Next Header values are dropped; this configuration k= nob > > MUST default to "drop". > > > > RATIONALE: [RFC7045] requires that nodes be configurable with res= pect > > 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? > > We need a specific action regarding unrecognized Next Header values > here.. that's why. Ok. > > > > > pg 5 section 4. "If a packet is dropped due to this filtering pol= icy, > > 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-Shiel= d > > packet drops." > > > > Doesn't the counter need to include port? A system wide counter > > wouldn't be much good. > > > > ... The logging mechanism SHOULD include a per port drop counter = ... > > Done. Thanks! > > > > > Note here it says DHCPv6 Shield even though above the logging app= ears > > to include "unrecognized Next Header". Would the counter include = both > > or just DHCPv6 Shield drops? Maybe two counters (but then we are = out > > of scope for dhcp again?) > > I guess the "per port drop counter" would be the minimum required..= . but > an implementation can always do better than that. > > > > > > 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-Shiel= d > > 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 firewa= lls, > > and hence are unlikely to survive in real networks. [RFC7112] > > requires that hosts employing fragmentation include the entire IP= v6 > > header chain in the first fragment (the fragment with the Fragmen= t > > Offset set to 0), thus eliminating the aforementioned false > > positives." > > > > It seems like 7112 covers this does it need to be part of this? > > We've been asked to -- although me, I'd probably agree with you. > > > > > SILICON SENSE I think it would make more sense to require dhcpv6 > > requests come from a special 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 ports but that is much simp= ler > > from an silicon point of view. It would also require changes to t= he > > dhcpv6 clients but does simplify the solution from a hw pov. > > But this is not backwards-compatible.... Yea I like this from a hw pov but it isn't compatible with other rfcs so we= can drop my comment. > > > > Moving > > this kind of deep header inspection into layer 2 gives us a new c= pu > > dos vector as most vendors would initially (forever?) do that in = cpu > > or shared npu? We have that problem today with layer 3 routing an > > headers do we want to push this to the next layer down? > > FWIW, whether a vendor implements this in hw or software is out of > scope. As you correctly note, doing this in software has its implic= ations... > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > 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 Tue Jan 27 01:15:12 2015 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 5A9C81A8769 for ; Tue, 27 Jan 2015 01:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BxFbFNvFlEgh for ; Tue, 27 Jan 2015 01:14:58 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3481A8737 for ; Tue, 27 Jan 2015 01:14:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 51CF28716EF; Tue, 27 Jan 2015 10:14:56 +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 plcHU8xkqrQp; Tue, 27 Jan 2015 10:14:56 +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 2F72D871518; Tue, 27 Jan 2015 10:14:56 +0100 (CET) Message-ID: <54C7570E.2090903@globis.net> Date: Tue, 27 Jan 2015 10:14:54 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Smith, Donald" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Fernando Gont , opsec@ietf.org Subject: Re: [OPSEC] Last Call: , (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best, Current Practice (Smith, Donald) 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, 27 Jan 2015 09:15:04 -0000 > I didn't see a reply to this question from Donald Smith, so here goes. >> Hi, Donald, >> >> Not sure if any of us had responded to this one, but, just in case, here >> I go (please find my responses in-line): > >DS Thank you. >> On 11/18/2014 04:04 PM, Smith, Donald wrote: >> > >> > 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 should probably >> > be replaced with "original packet" and rfc reference. >> >> Nope. They are different things: >> >> The original packet is the packet your host produces but never hits the >> wire (when you're employing fragmentation). > >DS Ahh I missed that distinction but get it now. > >> OTOH, the first fragment is a fragment with the FO==0. > >DS And more fragments flag set to 1? First fragment = IPv6 Fragment Extension Header present and Fragment Offset field == 0. I presume you mean any subsequent "more fragments" from the same message i.e. with IPv6 Fragment Extension Header == present AND Fragment Offset field !=0 AND identification == identification contained in the First Fragment These are passed unfiltered to the destination. However, since the First Fragment will never arrive at the destination host, due to the DHCPv6 shield filtering, they are never properly re-assembled into a DHCPv6 message actioned by the destination host. Yes, those incomplete fragmented packets can take up some resources in the affected receiving hosts that could theoretically cause DoS, but it never results in a valid DHCPv6 message being received, and the DoS problem is non-DHCPv6 specific anyway. > >> > pg 3. >> > >> > IPv6 Header Chain:... >> > >> > Seems mostly correct but again why restate what is described in >> > rfc2460 section 4? >> >> When we did RFC7112 at 6man, the wg asked us to have all these >> definitions... >> >> >> >> > 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 dhcp msg header wouldn't it default to allow not drop? ( MUST >> > drop if see dhcp , MUST allow if not?) >> > >> > So wouldn't you be more likely to have false negatives because the >> > whole header wasn't examined? >> >> You're right. Fixed! >> >> >> > >> > 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? >> >> We need a specific action regarding unrecognized Next Header values >> here.. that's why. > >DS Ok. > >> > 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 be much good. >> > >> > ... The logging mechanism SHOULD include a per port drop counter ... >> >> Done. Thanks! >> >> >> >> > Note here it says DHCPv6 Shield even though above the logging appears >> > to include "unrecognized Next Header". Would the counter include both >> > or just DHCPv6 Shield drops? Maybe two counters (but then we are out >> > of scope for dhcp again?) >> >> I guess the "per port drop counter" would be the minimum required... but >> an implementation can always do better than that. >> >> >> >> >> > 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? >> >> We've been asked to -- although me, I'd probably agree with you. >> >> >> >> > SILICON SENSE I think it would make more sense to require dhcpv6 >> > requests come from a special 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 ports but that is much simpler >> > from an silicon point of view. It would also require changes to the >> > dhcpv6 clients but does simplify the solution from a hw pov. >> >> But this is not backwards-compatible.... > >DS yea I like this from a hw pov but it isn't compatible with other rfcs so we can drop my comment. > > >> > 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 shared npu? We have that problem today with layer 3 routing an >> > headers do we want to push this to the next layer down? >> >> FWIW, whether a vendor implements this in hw or software is out of >> scope. As you correctly note, doing this in software has its implications... >> >> Thanks! >> >> Best regards, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> >> > >DS This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. > > -- Regards, RayH