Re: [OPSEC] Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Review

Fernando Gont <fgont@si6networks.com> Tue, 14 August 2012 12:03 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0108621F8678 for <opsec@ietfa.amsl.com>; Tue, 14 Aug 2012 05:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCv11yrO-3jh for <opsec@ietfa.amsl.com>; Tue, 14 Aug 2012 05:03:21 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 58B8021F8674 for <opsec@ietf.org>; Tue, 14 Aug 2012 05:03:21 -0700 (PDT)
Received: from [190.245.182.195] (helo=[192.168.1.128]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <fgont@si6networks.com>) id 1T1Fq8-0007tj-Qj; Tue, 14 Aug 2012 14:03:17 +0200
Message-ID: <502A3E54.1030102@si6networks.com>
Date: Tue, 14 Aug 2012 09:02:28 -0300
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2406BE1F@xmb-aln-x12.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A7504E928@xmb-rcd-x10.cisco.com> <5028F27A.5070404@si6networks.com> <1C9F17D1873AFA47A969C4DD98F98A75051261@xmb-rcd-x10.cisco.com>
In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A75051261@xmb-rcd-x10.cisco.com>
X-Enigmail-Version: 1.5a1pre
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Review
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2012 12:03:22 -0000

Hi, Panos,

While trying to address your feedback, I came up with additional
comments. Please do let me know what you think...

On 08/13/2012 05:52 PM, Panos Kampanakis (pkampana) wrote:
> - I see that you are mentioning RA-Guard for SLAAC-based attacks. Is
> the ND-Shield worth mentioning for L2 attacks?

I ended up referencing DHCPv6-Shield rather than ND-Shield, since the
goal here is to prevent attackers from enabling "global IPv6
connectivity" -- ND-Shield, on the other hand mitigates Neighbor Cache
sppofing attacks, which is not the subject of this section.


> - In 6to4 subsection, a couple of protections state "(embedded in the
> IPv4 payload)". This is not our traditional ACL filtering. It
> requires equipment that can look and inspect the encapsulated packet,
> or match on specific fields of the packet payload, or actually
> understand 6 in 4 encapsulation in order to be able to filter. Maybe
> it would be worth the put a sentence to clarify that to prevent
> readers from think this is traditional ACL filtering.

I've added a clarification about this. Additionally, I added a note
mentioning that an attacker might fragment its 6to4 packets into tiny
fragments such that the filtering device does not really have access to
the embedded IPv6 Addresses.



> - For Teredo, would it be worth mentioning that blocking UDP packets
> with embedded IPv6 addresses 2001::/32 on a device that can
> match/"understand"/inspect Teredo encapsulation is another mitigation
> option (as in 6to4 "(embedded in the IPv4 payload)")? 

The problem here is that, IIRC (and of the top of my head), no specific
UDP port numbers are used for the "data" packets, and hence you cannot
really tell to which UDP packets you should apply these filtering rules.

Does this make sense?

As a result, I have not yet added any text regarding filtering Teredo
packets based on the embedded IPv6 addresses. But please do let me know
if you feel otherwise.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492