IETF Logo Mail Archive

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

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Wed, 20 May 2015 12:28 UTC

Return-Path: <evyncke@cisco.com>
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 2A30C1A0067 for <v6ops@ietfa.amsl.com>; Wed, 20 May 2015 05:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Uty5FVsa0Nan for <v6ops@ietfa.amsl.com>; Wed, 20 May 2015 05:28:35 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C815E1A0055 for <v6ops@ietf.org>; Wed, 20 May 2015 05:28:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1432124913; x=1433334513; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OFJFA7Umekv/TEAuDctuupotfIoBbPID4dMDs+ClKWo=; b=OO0SsdnvfNv0vWfh+tMYtCAi+ucyjzu4jVq8uC4fNMlRJ9u0zbtEK+Jf yJ78/7CoSEfpId/+iKSJS6YO2k8qN6zCxk+wYxwb1jJTnTeaCwIgbsZ0W 3KoWD7cthW64GtEVbYVOrlo5nx7Wg5EPyNJHUOSwIzHWAlThmL7XmkhBc M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BsBADTfFxV/4cNJK1cDoMCgTIGgxjBXQmHUQIcgR04FAEBAQEBAQGBCoQjAQEEIxFFEAIBCA4KAgImAgICMBUQAgQBDQWILKgtpB0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKGYRqGweCaIFFAQSScIsAlxQjgWaBVD5vgUaBAQEBAQ
X-IronPort-AV: E=Sophos;i="5.13,464,1427760000"; d="scan'208";a="151793223"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 May 2015 12:28:32 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4KCSWnC009079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 May 2015 12:28:32 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 20 May 2015 07:28:32 -0500
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Tim Chown <tjc@ecs.soton.ac.uk>, Joe Touch <touch@isi.edu>
Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices
Thread-Index: AQHQjwOUSoUfhjfqOU2VSvc4/QdUh52B3yyAgAAWQQCAAgsLAIAA30qAgABohAA=
Date: Wed, 20 May 2015 12:28:31 +0000
Message-ID: <D1824981.4B3C7%evyncke@cisco.com>
References: <20150515113728.GH3028@ernw.de> <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> <20150518.134312.74662992.sthaug@nethelp.no> <555B8712.9080906@isi.edu> <1A7F7D26-BBFD-4981-BF1C-978115C0B90A@ecs.soton.ac.uk> <EMEW3|c91cdcfda9ced16fe59fdbc4171372c9r4J9EO03tjc|ecs.soton.ac.uk|1A7F7D26-BBFD-4981-BF1C-978115C0B90A@ecs.soton.ac.uk>
In-Reply-To: <EMEW3|c91cdcfda9ced16fe59fdbc4171372c9r4J9EO03tjc|ecs.soton.ac.uk|1A7F7D26-BBFD-4981-BF1C-978115C0B90A@ecs.soton.ac.uk>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [10.55.185.69]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9DDB68C196581545A8BBEB0EE7268DD3@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/BpObDKPMq-Ac5bSdpbj-7wtiXi4>
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
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, 20 May 2015 12:28:36 -0000

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).

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

v2.23.0 | Report a Bug | By Email