Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?

Gert Doering <> Fri, 22 October 2021 07:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93E983A0864 for <>; Fri, 22 Oct 2021 00:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vq0WzNFiOfk9 for <>; Fri, 22 Oct 2021 00:32:54 -0700 (PDT)
Received: from ( [IPv6:2001:608:3:85::38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7FA413A085C for <>; Fri, 22 Oct 2021 00:32:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=esa; t=1634887974; x=1666423974; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=EKJw0yrdXPsQxs9xf8l4+bV+OMD+LDq1vzWLTAfYPJk=; b=cq3jnYSHrtKXtWpbetDaenrRpW/6h8KT3BAmdt8oeo9VNigDpA8qkTUI qcIRftIY9ch9aqnI69U0Z30Lmrh+k0ifRyz60XR1uT6KuI8SwZ/4bOwiz prSFbdSqSvy8g3dP4fLYPEvwQDdtEG+e4vT8cHcFKAuIjjv2reK6bCsd1 75fBSgUmsRrPbJ4sb/hB7udn4B+d8FjR4g9Jn+Rkwp0sANhdZBuTArySj l1Ddzf4J09OIB2MUr2S1k+E9WquZ3KiQ2A8+nx1BrtJmDs3ab7FkApuhU TLKjjgorXv715VFfnJ2UOLcKuSXXfKNRDhOkI9eefgeBbw1lOXHkEgq1T Q==;
X-SpaceNet-SBRS: None
Received: from ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Oct 2021 09:32:49 +0200
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 8DE1F436BF for <>; Fri, 22 Oct 2021 09:32:48 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from ( [IPv6:2001:608:2:2::251]) by (Postfix) with ESMTP id 49F0A41B06; Fri, 22 Oct 2021 09:32:48 +0200 (CEST)
Received: by (Postfix, from userid 1007) id 4595FF0612; Fri, 22 Oct 2021 09:32:48 +0200 (CEST)
Date: Fri, 22 Oct 2021 09:32:48 +0200
From: Gert Doering <>
To: Andrew Alston <>
Cc: Gert Doering <>, Andrew Alston <>, "" <>
Message-ID: <YXJpILncfS+jFXjt@Space.Net>
References: <> <YXJhucp93W5WltX2@Space.Net> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZJxkMXSTt45qYtPB"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Oct 2021 07:32:59 -0000


On Fri, Oct 22, 2021 at 07:14:45AM +0000, Andrew Alston wrote:
> I don't disagree with your sentiments - however - be that as it
> may - if this stuff is going to exist, do we not have a responsibility
> to ensure that its not creating a situation that allows for wholesale
> security issues and the potential creation of some very nasty denial
> of service exploits that could affect us all? (See original email
> in this thread regarding smurf-v2 enabled by SRv6)

I read and fully understood what you've been saying - and I agree that
this sounds like a very real issue (without having tested it).

For the reasons you have listed I'm unsure whether there is a way 
to fix this (= it strengthens my resolve to not go there).

Trying to think up fixes

 - ACLs on ingress from all hosts that deny packets with SR EHs
 - ACLs on ingress from all hosts that deny packets *to* Routers that
   would decapsulate them (which requires that all router IPs come from
   a small number of subnets, nothing else is in there, and that you
   do not care about "ping router" for troubleshooting)
 - putting customer IPv6 into a 6PE VRF, preventing packets to be sent
   to the "real" control plane

none of these can be easily deployed in most networks, and worse, if you
actually want some hosts to participate in SR (which is, I think, the
kool-aid that has been sold to us on why SR is so great...), they all
fall apart.

Or you require RFC3514 adherence on the host, and filter on that.

(Wait, RFC3514 has never been updated to handle IPv6.  So this definitely
needs a -bis revision!)

Short summary: in the short time I spent on thinking through this, I see
no viable way to fix this class of attacks ("unrestricted egress tunnel
endpoints, reachable via an un-ACL-able protocol from malicious hosts").

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

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