Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

Gert Doering <gert@space.net> Tue, 21 April 2015 06:48 UTC

Return-Path: <gert@Space.Net>
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 936E91B3660 for <v6ops@ietfa.amsl.com>; Mon, 20 Apr 2015 23:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 KZYoca_bO8Qt for <v6ops@ietfa.amsl.com>; Mon, 20 Apr 2015 23:48:14 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F23D1B365F for <v6ops@ietf.org>; Mon, 20 Apr 2015 23:48:14 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4A62162BE8 for <v6ops@ietf.org>; Tue, 21 Apr 2015 08:48:12 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id EB2D860788 for <v6ops@ietf.org>; Tue, 21 Apr 2015 08:48:11 +0200 (CEST)
Received: (qmail 58204 invoked by uid 1007); 21 Apr 2015 08:48:11 +0200
Date: Tue, 21 Apr 2015 08:48:11 +0200
From: Gert Doering <gert@space.net>
To: Joe Touch <touch@isi.edu>
Message-ID: <20150421064811.GG54385@Space.Net>
References: <D157BDE1.44CEE%evyncke@cisco.com> <55351EA0.2010700@isi.edu> <20150420212125.GE54385@Space.Net> <55356F68.1020605@isi.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="EAlATg9TatN2jXJk"
Content-Disposition: inline
In-Reply-To: <55356F68.1020605@isi.edu>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/dHubXwl7__kisO4Y9R1YV2ySwto>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, Merike Kaeo <merike@doubleshotsecurity.com>, "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" <draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>, Fernando Gont <fgont@si6networks.com>
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
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: Tue, 21 Apr 2015 06:48:16 -0000

Hi,

On Mon, Apr 20, 2015 at 02:28:08PM -0700, Joe Touch wrote:
> On 4/20/2015 2:21 PM, Gert Doering wrote:
> > On Mon, Apr 20, 2015 at 08:43:28AM -0700, Joe Touch wrote:
> >>> If for some reasons, a router in the middle needs access to layer-4
> >>                                               ^^^^^
> >>> information (IPFIX? DDoS mitigation? ... ?), then the EH chain must be
> >>> parsed which can cause a performance impact.
> > [..]
> >> 	1) this is the router vendor's decision, not a requirement
> >> 	of Internet routers
> > 
> > So, please tell me how you build an Internet router that is able to
> > defend itself against control plane abuse and does not need to look into
> > L4 to do so?
> 
> A router can protect its own control plane by looking at the packet
> contents, but then it is acting as a host at that point and should be
> looking there only for packets addressed to interfaces of that router.
> That's not a forwarding function and thus doesn't limit the forwarding
> plane.

Of course, but real world requires that this filter function needs to be
implemented in the forwarding plane, because otherwise packets would just
saturate the link between forwarding and control plane if you would only 
filter on "the other side".

From a purely academic point of view, I totally agree with you.  

Unfortunately, the Internet is not.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279