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

Tim Chown <tjc@ecs.soton.ac.uk> Wed, 27 May 2015 11:35 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 5E3351ACE08 for <v6ops@ietfa.amsl.com>; Wed, 27 May 2015 04:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.231
X-Spam-Level:
X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, 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 I_35Et1BHlcU for <v6ops@ietfa.amsl.com>; Wed, 27 May 2015 04:34:57 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BA31ACE0D for <v6ops@ietf.org>; Wed, 27 May 2015 04:34:57 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t4RBYo9a005446 for <v6ops@ietf.org>; Wed, 27 May 2015 12:34:50 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t4RBYo9a005446
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1432726490; bh=d6AajLCkOgVvCguDyWA+0yagcdY=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=az7qX333sCkMoJ5iUuPk2x3WXmcN+Crjh5dLyy54wWdnZ1y14kQ+5BFUKRLF+Bg5+ 21M5mz+1TaowP6QhdnFrMWOzjEybND2GYFH0sBDGflmSo33EftbMrOrz4eY0BUCbPX bhilMBOcf7MA4/57HCJRAAldiPKZbEnOb9oLMp4E=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id r4QCYo0803206396bs ret-id none; Wed, 27 May 2015 12:34:50 +0100
Received: from [IPv6:2001:630:d0:f111:ed71:8eeb:6cb1:d085] ([IPv6:2001:630:d0:f111:ed71:8eeb:6cb1:d085]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t4RBYoJO014096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <v6ops@ietf.org>; Wed, 27 May 2015 12:34:50 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <5564FC6C.2040604@gmail.com>
Date: Wed, 27 May 2015 12:34:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|4027e1934fee90011217477564c4873br4QCYo03tjc|ecs.soton.ac.uk|8A935D04-5BBB-4B2A-BB44-C9D9BECE514E@ecs.soton.ac.uk>
References: <D1824981.4B3C7%evyncke@cisco.com> <1975702461.1639631.1432618020136.JavaMail.yahoo@mail.yahoo.com> <5564FC6C.2040604@gmail.com> <8A935D04-5BBB-4B2A-BB44-C9D9BECE514E@ecs.soton.ac.uk>
To: "v6ops@ietf.org" <v6ops@ietf.org>
X-Mailer: Apple Mail (2.2098)
X-smtpf-Report: sid=r4QCYo080320639600; tid=r4QCYo0803206396bs; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: t4RBYo9a005446
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/f5Bd3CDOxznSF064h-9KiobrZzg>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Wed, 27 May 2015 11:35:04 -0000

Hi,

> On 27 May 2015, at 00:06, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 26/05/2015 17:27, Mark ZZZ Smith wrote:
>> 
>> ______________________________
>> From: Eric Vyncke (evyncke) <evyncke@cisco.com>
>> To: Tim Chown <tjc@ecs.soton.ac.uk>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.
> 
> I've lost track of who wrote that (Tim?), but it's only true if
> all middleboxes respect RFC 7045, especially the bits about what
> needs to be configurable and what the factory defaults should be.

I think the point is that drops caused by administrative configuration should not be an issue within a domain under your full control. Which is presumably why sfc/spring are limiting their primary use cases in this way. The exposure is presumably then only equipment within their domain that has some limitation in EH handling.

>> 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).
> 
> Again: all these choices need to be configurable, so that providers
> can make their own choices and decide what to break. I assume that
> discussion belongs in opsec.

With the caveat that you can’t control what you can’t control.

Tim

> 
>   Brian
> 
>> 
>> 
>> / +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
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>