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

Silvia Hagen <silvia.hagen@sunny.ch> Thu, 21 May 2015 14:38 UTC

Return-Path: <silvia.hagen@sunny.ch>
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 5E6641A1BC6 for <v6ops@ietfa.amsl.com>; Thu, 21 May 2015 07:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 zh_nsBhHo5o7 for <v6ops@ietfa.amsl.com>; Thu, 21 May 2015 07:38:54 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3861A1AA8 for <v6ops@ietf.org>; Thu, 21 May 2015 07:38:12 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CA673340817; Thu, 21 May 2015 16:38:09 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/10415.1968); Thu, 21 May 2015 16:38:07 +0200 (CEST)
Received: from owa.hextop.ch (owa.hextop.ch [212.25.0.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 21 May 2015 16:38:07 +0200 (CEST)
Received: from HEX02.hextop.ch ([212.25.0.68]) by hex02 ([212.25.0.68]) with mapi id 14.01.0438.000; Thu, 21 May 2015 16:38:07 +0200
From: Silvia Hagen <silvia.hagen@sunny.ch>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Tim Chown <tjc@ecs.soton.ac.uk>, Joe Touch <touch@isi.edu>
Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices
Thread-Index: AQHQjwOc1Jlz46hQy0yE3Gbhq1u2w52BadSAgAAWQQCAAgsKAIAA30qAgABG/4CAAdb2wA==
Date: Thu, 21 May 2015 14:38:07 +0000
Message-ID: <F1D4404E5E6C614EB9D3083F4D15A7E7C53DA4@hex02>
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> <D1824981.4B3C7%evyncke@cisco.com>
In-Reply-To: <D1824981.4B3C7%evyncke@cisco.com>
Accept-Language: de-CH, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2a02:120b:c3ea:36c0:d4ab:4fca:ffb5:a17f]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/MSYebgrX99VyP9pdQNc94UPYUK8>
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: Thu, 21 May 2015 14:38:56 -0000

So to summarize:

EH such as destination option and fragment is no issue in the Internet and must not be filtered, nor analyzed, simply forwarded in hardware based on the information in the IPv6 header.
And what the administrator does within his administrative domain is up to his choice and the Internet needs not care about it

Is that correct?
If yes, what is the problem?

If that is how it is supposed to work we need to educate people that feel that EHs must be filtered in the Internet.
Now hop-by-hop is obviously diffferent. But is it needed in the Internet? Again, what I do internally, nobody out there cares.

Silvia


-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Eric Vyncke (evyncke)
Gesendet: Mittwoch, 20. Mai 2015 14:29
An: Tim Chown; Joe Touch
Cc: v6ops@ietf.org
Betreff: 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).

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