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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A30C1A0067 for <>; Wed, 20 May 2015 05:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uty5FVsa0Nan for <>; Wed, 20 May 2015 05:28:35 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C815E1A0055 for <>; Wed, 20 May 2015 05:28:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.13,464,1427760000"; d="scan'208";a="151793223"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 May 2015 12:28:32 +0000
Received: from ( []) by (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 ([]) by ([]) with mapi id 14.03.0195.001; Wed, 20 May 2015 07:28:32 -0500
From: "Eric Vyncke (evyncke)" <>
To: Tim Chown <>, Joe Touch <>
Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices
Thread-Index: AQHQjwOUSoUfhjfqOU2VSvc4/QdUh52B3yyAgAAWQQCAAgsLAIAA30qAgABohAA=
Date: Wed, 20 May 2015 12:28:31 +0000
Message-ID: <>
References: <> <> <> <> <> <EMEW3|c91cdcfda9ced16fe59fdbc4171372c9r4J9EO03tjc||>
In-Reply-To: <EMEW3|c91cdcfda9ced16fe59fdbc4171372c9r4J9EO03tjc||>
Accept-Language: fr-FR, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 May 2015 12:28:36 -0000

On 20/05/15 10:14, "Tim Chown" <> 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