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

Gert Doering <> Mon, 25 October 2021 06:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20AB43A0776 for <>; Sun, 24 Oct 2021 23:22:05 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ul6EziRZApZB for <>; Sun, 24 Oct 2021 23:22:00 -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 978483A0774 for <>; Sun, 24 Oct 2021 23:21:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=esa; t=1635142920; x=1666678920; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=3FeyRhajHXZ9ciABh3SqnPvzY7jjCwxzUH5RTJjkxw0=; b=WDFopqkNrP/50qAqMc85mAQFlozcZ0HM5S1cGkKyt6bgKIYYZ6uOeXut sxgRXeYpbZPot18GuSbDls8u8WyUeQUe+hcW6g8IFHP4akZQvuCFSsW4Q krFw1ylBTRVtXa4GB69o6ZbxdGodDRmH2y7l2j1JgKaQLwyPOjWF+TCCn eIFs0zvEDHGVxoxuxxLJw64d7zh3SjchKUJ+ylBbOBXKSN0cMCNG+I9X/ 4POh2o5bkkSJVET798sXWTN9RQw9VxwWcZsTsOxsq2v/ElpXdFPuYl3vd JQrGKQ6/LxjlDMVs5rss9NTQNx7ftfHlJbVaFoQniv5U977KhKEO+E0+y Q==;
X-SpaceNet-SBRS: None
Received: from ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2021 08:21:50 +0200
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 65DE2436E4 for <>; Mon, 25 Oct 2021 08:21:50 +0200 (CEST)
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 146B6436C5; Mon, 25 Oct 2021 08:21:50 +0200 (CEST)
Received: by (Postfix, from userid 1007) id 0D5E510FB01; Mon, 25 Oct 2021 08:21:50 +0200 (CEST)
Date: Mon, 25 Oct 2021 08:21:50 +0200
From: Gert Doering <>
To: "Eric Vyncke (evyncke)" <>
Cc: Andrew Alston <>, "" <>
Message-ID: <YXZM/gDya6lTjykV@Space.Net>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: Mon, 25 Oct 2021 06:22:05 -0000


On Sun, Oct 24, 2021 at 08:55:17PM +0000, Eric Vyncke (evyncke) wrote:
> But, I fail to understand whether the issue is limited to SRH or
> is actually applicable to any tunnel ? As you described, in any
> encapsulation mechanism, BCP38 will be applied on the outer header
> in the ???underlay??? and the encapsulated packet will indeed
> traverse any network until the endpoint [1]. Therefore, to handle
> the case when one endpoint of the tunnel is compromised, the other
> endpoint should apply BCP38 on the decapsulated traffic based on
> the other side of the tunnel.

It is applicable to any tunnel that will decapsulate packets from
arbitrary (outside) sources.

So, for example, a normal GRE tunnel would only accept packets from (outer) 
sources matching the configured "tunnel destination" peer address, and
you could configure BCP38 for the "inside" addresses (given that GRE
tunnels are usually presented as virtual interface with routes pointing
to it, and ACLs/BCP38 being applicable).

> About the looping attacks, there is no amplification here as the
> compromised host needs to generate N packets to force the non-compromised
> tunnel endpoint to generate N (shorter) packets. The RFC 6324
> describes a related attack by with amplification using ISATAP.

The looping attack is similar to what was described for RH0 - you send
one packet, but that packet traverses the target network multiple times,
pingponging between participating routers.

> It is clear that tunnel endpoints (whether GRE, ISATAP, IPsec,
> or even SRH) should not trust blindly any packets and should only
> decapsulate valid packets (based at the minimum on source address
> and applying BCP38 and infrastructure ACL at their edge ??? if
> applicable). In the case of SRH[2] (or any RH actually even MIPv6
> or RPL), this function should not be enabled by default and must
> be configured correctly.

So, if you turn on SR6 in your network, how would you protect said 
network against malicious hosts *in* your network?

Of course "not using SR6" or "block all EH from hosts" is a viable 
strategy, but might not be how the inventors intended things to be used...

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