Re: [v6ops] Extension Headers / Impact on Security Devices

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Tue, 26 May 2015 05:27 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 9DD2C1A7022 for <v6ops@ietfa.amsl.com>; Mon, 25 May 2015 22:27:05 -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 7-S1Fa652kCU for <v6ops@ietfa.amsl.com>; Mon, 25 May 2015 22:27:04 -0700 (PDT)
Received: from nm11-vm1.bullet.mail.bf1.yahoo.com (nm11-vm1.bullet.mail.bf1.yahoo.com [98.139.213.152]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359AF1A6FE9 for <v6ops@ietf.org>; Mon, 25 May 2015 22:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1432618023; bh=Y45c2NWzTVgDewEvFTGg8zop6wf33QWXXz4cyKDBs6s=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=WqC2HGRQg4O21Aa85OFSCZa50JVJivYXRgGo+ulkgU0nLnHWcavEtPq9l4r1KfHqzLe+UMoHgQzivJKKUxKtaVtBbzLk19G7HPLHlnSibqbrrJfFXhdxYkscKkLdZhD51RO3YSvdO2Cy+OIRjX9dv5bf6ePAmBPL4oIqZkPYSbLGWC0o0N5jmw3B06End8PjWiAJSXKh4BK2PfSFJaMYEeB8Zgrni6Xw7ptqdAOKwyIGbAnx1vFrYHy1d+7TllZHuPjaGWGByJcvu80uXlSs0McJeXsErs5/7AjhMpgoj/wKq/k2m6cBRHvsRu7BnDbstJEqg+AhntyWJko/fLWaig==
Received: from [98.139.214.32] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2015 05:27:03 -0000
Received: from [98.139.212.210] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2015 05:27:03 -0000
Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 26 May 2015 05:27:03 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 479974.11340.bm@omp1019.mail.bf1.yahoo.com
X-YMail-OSG: rUc_2i0VM1mPhjhuNu8vINsh5.LsaQ4XKT8d7VV4SXOThugNDDnqvZ9OVo1_cl3 ejPp.6oaLrNTmyq6AjJocuohgNKf0A.CZcHAWD3RqWB4tTOAJFEUBvnehggAM8P4DGWavnZEc_JR SGuyVHywTwt52FcT1nVl0bQ7dwSihh0wUh2kfgWCopclg__OHJifBYS89227pi6T5FMjW5aKhpyI pb9SXRpB7uRvMqIrKo.TnISP81lT6xm5BqAHSqnVWPhbWKu8xXMaEalLA.WpSgcF4nK1pALe_C3I jf673hm.taz6VjRg8FIu31CRTDuQ7P3PS6uyUg5cZXOYrbjsTxcxgLoB29ZbH5PongjcfN134KZm yYE1msWYvpStD_HPispGQ5C341LIU1DSQJMLD938FvuQ1mYqLRuz.eU2H7gY7UWU0_cNt_.X0AMp 8HDrmynriAWGew2gL4HIIwZ21KumWY0HKzGgdZxISB_D66fGOXxFkAv4pvbhifZCVPikeC0HtLHA J_IPLU0.YF9v_SYmTEFiuWmhGZzm6RFqVw3.h1unc570-
Received: by 76.13.26.108; Tue, 26 May 2015 05:27:03 +0000
Date: Tue, 26 May 2015 05:27:00 +0000
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Tim Chown <tjc@ecs.soton.ac.uk>, Joe Touch <touch@isi.edu>
Message-ID: <1975702461.1639631.1432618020136.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <D1824981.4B3C7%evyncke@cisco.com>
References: <D1824981.4B3C7%evyncke@cisco.com>
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/AdqufZFPaLU-2Av-0bwhTQUUnyo>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] 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: Tue, 26 May 2015 05:27:05 -0000




________________________________
From: Eric Vyncke (evyncke) <evyncke@cisco.com>
To: Tim Chown <tjc@ecs.soton.ac.uk>; Joe Touch <touch@isi.edu> 
Cc: "v6ops@ietf.org" <v6ops@ietf.org> 
Sent: Wednesday, 20 May 2015, 22:28
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices


On 20/05/15 10:14, "Tim Chown" <tjc@ecs.soton.ac.uk> wrote:
>
>The other question is what existing work is being done that relies on the
>correct (desired) operation of EHs? The two that would spring out would
>be segment routing and sfc, at least one of which is using the existing
>Routing Header. If such protocols are constrained to specific
>administrative domains then their successful operation I would assume is
>down to specific EH handling in the equipment in that domain, and its
>capabilities, rather than (undesired) operator filtering somewhere
>between sender and receiver.

The primary use case of segment routing is indeed within a single
administrative domain, so, EH does not cause a problem.

OTOH, this whole discussion is pretty close to having a discussion on
whether an ISP should block everything which is neither UDP nor TCP? Or
block currently-unallocated TCP/UDP ports? (and I appreciate that there
are differences of course).


/ +1

/ In my opinion a huge amount of security context is missing from this discussion, to the point where the question has been simplified to a too simplistic and binary EHs or not question, and there is never going to be consensus on that question.

/ There seems to be an underlying and unstated set of assumptions behind the sorts of "block EHs","must be able to look at TCP/UDP headers in the network" questions/statements : 

/ (a) the network is the only place that network, host and application security can and must be done, implying that hosts and applications do nothing to protect themselves
/ (b) that the contents of packets will always remain transparent to the network, allowing them to be inspected in the network
/ and (c) that all traffic to and from a host/application will always traverse a single inspection/choke point in the network and will always use the same Internet protocol.



/ I think all of the above assumptions were true up until about the mid 1990s (if I remember well enough). Since then, they've all become false to varying degrees. Consequently, a choke point in the network may not be the best place to perform all network, host and application security measures, and in some cases persisting with that model will cause security failures. (For example, it seems that hosts aren't the lowest hanging fruit for network delivered malware any more, it is residential CPE itself - the device that is supposed to be so effective at providing "security" (including implicitly via NAT) that theoretically downstream hosts don't need firewalls at all.)

To Enno's original point: it is fair for a destination domain to handle
(permit, drop, log, inspect) incoming (or outgoing BTW) packets based on
layer-4 ports, layer-4 protocols or extension headers. This is their own
responsibility

-éric




_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops