[v6ops] So what is or are the problem or problems to be solved? (Re: [ipv6-wg] Extension Headers / Impact on Security Devices)

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Thu, 18 June 2015 04:29 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B069A1B2B99 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 21:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.201
X-Spam-Level: ***
X-Spam-Status: No, score=3.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] 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 7sVyioHro1L0 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 21:29:23 -0700 (PDT)
Received: from nm47-vm7.bullet.mail.bf1.yahoo.com (nm47-vm7.bullet.mail.bf1.yahoo.com [216.109.115.142]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7BE1B2BB3 for <v6ops@ietf.org>; Wed, 17 Jun 2015 21:29:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1434601762; bh=wkHGg38bWu40lvUxndTNktigBBl5wnxS4V/Ztay7ulo=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=DMRcVCOUdjjXLT2CP+Rtgl1jbHV7mo3eQ9qnPAwKSpzpk77MIrj5UaQNsYVK7szgfj46wlmrXy5Pky2mgGOOlr7l9i4TkI4YcwBzqc7DzSrwgECIRMNqiHDx4Z9jEJdT4Rvyf0f5xXltuJtOTfRsiQYUNlrV/nD8KR4xADCcx4/7H8meSop3AV9QwGUGKw8+yT88JSRaRAZB+TyP3psrHVKIzZNZWGppkdEQ0WOwer+YEKS4HgLXbeKY0THRyqLdqLFNe3cMRZLxhwAR7Y0MKfi17Sz7RtYMi9prIti/6lA/kigz4DsdFo3K9j7SL6Ukp8aVdYRLwfav1t9HT2XdCw==
Received: from [66.196.81.172] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 04:29:22 -0000
Received: from [98.139.212.226] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 04:29:22 -0000
Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 04:29:22 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 716871.14771.bm@omp1035.mail.bf1.yahoo.com
X-YMail-OSG: IsKZOxQVM1mB_zKNVwyVkvcY3oVH4GvGGu4d22WDhJX9N3Z39Hr5OVUScr2WUdU WVy5DK5uH2JWlLNy6MTWbSpAz5CzgU7.EEcgSUDUn0bSKQnlqLt0GPGJB8MfYBq9FUpLbjx0s17h GHqCqTobZokPGJp.sO5fLUBU2EJx7H3hIL8oRKmif356f1EfhJPtanFrAZEiGAEOQh3dgIi05K.o yKsZbmH7.zIImFrK9b5a0tIoHwgtb9OZKAmT8F_oA2dicx6W0hATNVoJfitDJBBWqOvF3qvJ2sKz eXT2cBsIKSQbvPK79k6J1ffHJTrRLPCcqy9r8FH9OnaOyoMx6TXbATbHsE9QFclpwJRPV1SOUTlu BEQIx4q7uEHkAZS8DjRUBcbX8VYF2Lb1wWgW1gu4r_C0xIbWPhVaodPLKv.aMCey.OkDcoBkbfLt 6CWSr9jDcQotD0CO52zjHhgjtl0e7CSibMqaRzs43yiQRpy_u_4LtWHgjHu1JKZlU9sSEW5K2ieG Fld9_2Is5zL6DDRHiUJB7V3uwOI1mTCwmX0vy6AzFJx.6oMGl_g--
Received: by 66.196.80.148; Thu, 18 Jun 2015 04:29:22 +0000
Date: Thu, 18 Jun 2015 04:29:21 +0000
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Message-ID: <1011211331.1157047.1434601761591.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <5581B2DF.8040207@innovationslab.net>
References: <5581B2DF.8040207@innovationslab.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/nW_yPK_BRpNIwkLXp-RRQS6Vi9k>
Subject: [v6ops] So what is or are the problem or problems to be solved? (Re: [ipv6-wg] Extension Headers / Impact on Security Devices)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2015 04:29:24 -0000

Hi,


________________________________
From: Brian Haberman <brian@innovationslab.net>
To: v6ops@ietf.org 
Sent: Thursday, 18 June 2015, 3:48
Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices




On 6/17/15 1:43 PM, Enno Rey wrote:

> 
> Let's put it slightly different: the intrusion detector is supposed
> to detect/block certain application layer attacks. Which it does as
> long as those come in/pass by without extension

If the device is trying to inspect application-layer data, it might as
well act like the destination and re-assemble the fragments. Yes, this
is costly processing, but it mitigates this bypass mechanism.


/ Not specifically replying to Brian's email, however I think it is a step towards what I'm going to ask.

/ So I think everybody is making valid points, yet the set of points are inconsistent and sometimes in conflict. I think that is a sign to step back and think a bit more about better identifying and describing the problem or problems.

/ I think there are actually 3 security problems people are trying to solve in this discussion:

/ (1) mitigating network capacity DoS attacks on high speed forwarding devices

/ (2) protecting the in-band control plane of forwarding devices

/ (3) performing host/application security via a proxy device in the network ("firewalling, IDS/IPS", i.e., middleboxes)


/ So for each of these different problems, what are the requirements, the constraints and where are they best solved (in the network, in the hosts, or possibly a mix of both)?

/ A few thoughts I have on the above:

/ (1) I think TCP/UDP port level filtering for this purpose is certainly a nice to have but not a necessary to have, because network capacity DoSs will use some other protocol for their DoS if mitigating DoSs using TCP/UDP traffic becomes too effective. Completely dropping DoS traffic identified just by src and/or dst address, or plonking that traffic into a scavenger QoS class for a while if complete dropping is too severe is a general solution that will work regardless of the type of DoS traffic. Using TCP/UDP ports if they're easily available would allow the dropping to be more granular, but is not required to mitigate the network capacity DoS.

/(2) The control plane is really a host (because it is the final destination for the packets sent to the control plane), so it needs "host style" protection, which I think means stateless methods aren't effective enough - for example, I think spoofed src address fragmented OSPF packets could be used to attack the OSPF instance, yet they'd pass the stateless ACLs, which is why we enable IGP/BGP authentication, validate hopcounts etc.. Ultimately, moving the control plane completely out of band (as the telephony people did, and "SDN"/Openflow does) would place the control plane completely out of reach of malicious in-band traffic sources.

/ (3) I think this is always going to be impractical to do well in fast, fixed or limited function hardware, as it is necessary to do just too much host type processing. We scale solutions to problems on the Internet by using "divide-and-conquer" and achieve that by pushing them towards or onto the actual edge i.e., the hosts. So I think (3) is far more possible to achieved by either doing it in lots of lower throughput but higher inspection software based forwarding devices close to the edge, or leaving the hosts to do it themselves (because they know best what is and isn't legitimate traffic for their own OS and applications, and they might also be multi-homed, so have a security perspective that a single device on one of the upstream links can't.), with perhaps close by devices in the network performing a secondary assisting and more coarse security role (e.g., stateless ACLs that match on no more either basic src/dst address or TCP/UDP ports, following an EH chain to find the TCP/UDP port information if necessary, but not doing any further analysis, leaving that to the receiving host)

/ Regards,
Mark.