IETF Logo Mail Archive

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

Gert Doering <gert@space.net> Tue, 26 October 2021 06:39 UTC

Return-Path: <gert@space.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBCB3A1022 for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 23:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net
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 0NxcdEmSOXSl for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 23:39:00 -0700 (PDT)
Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 B8BEF3A0FF5 for <v6ops@ietf.org>; Mon, 25 Oct 2021 23:38:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1635230339; x=1666766339; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=AREEklAJMK8lY82N+VwK+9VeS5KW0f3kGVDuD6r16xg=; b=PKlxfnxxJUeYHG1hyC75ROXKcV/v/QnyobSi1ldrMxC60uB6PouQg5hk wzaeo7rZgJnWFNMCMxUCi1WSQSywAyOV7Rxdk5riwRdl9ZtEvWVIDvQd6 TWCVg3TdFKY3ajrcvmyHAPem4KQKJBo09amiBg93Q9m7VIMIzl3LBypTj dKD2Gm412wDqkR320AF6pK4Fr8DHLKh9a/uGsZNJoZXDrfReTZvTdbv8o U5whyJOAsa6Y0u4SmBBJbRRbs45Fwus36skRye7wIO0bJr9Z7xojLJc+k 71UwQKLZhqIZsvFgf2HDIls4dcRSF3XTYJgsX3qWShqgZtksmuDGMnEu7 Q==;
X-SpaceNet-SBRS: None
Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Oct 2021 08:38:52 +0200
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CF94A436EB for <v6ops@ietf.org>; Tue, 26 Oct 2021 08:38:51 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9B36D42471; Tue, 26 Oct 2021 08:38:51 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 98B3832E6; Tue, 26 Oct 2021 08:38:51 +0200 (CEST)
Date: Tue, 26 Oct 2021 08:38:51 +0200
From: Gert Doering <gert@space.net>
To: Warren Kumari <warren@kumari.net>
Cc: Andrew Alston <Andrew.Alston=40liquidtelecom.com@dmarc.ietf.org>, Gert Doering <gert@space.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Message-ID: <YXeiezGZIzxTn4Ay@Space.Net>
References: <CB45220A-ECE6-492A-8A37-D189A71CDA2B@liquidtelecom.com> <CAHw9_iJy_OjSwRDRx5cbB6yhau7XzNUKTi49sHhi0CnmRARQUA@mail.gmail.com> <1F31CC6F-8471-4B50-AE3F-9E5FC76BB447@employees.org> <CAHw9_iKU5--mFq3swhSbGJHV9Y5H52cKcgeF=nBf1rqZeBMRJQ@mail.gmail.com> <YXciHYMNa6KJUohp@Space.Net> <ff55bdc4-9274-adc5-ef09-0d398b52342a@gmail.com> <YXcl2iQMvZe8ggLs@Space.Net> <0C1C8148-3D59-4C2A-A834-5B11854B3E7C@liquidtelecom.com> <CAHw9_iLm_T=F_m+Bie5ey6=PU18D610w6HsXY16f118hzmp5Kw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="qYECvILBZIRb+1yO"
Content-Disposition: inline
In-Reply-To: <CAHw9_iLm_T=F_m+Bie5ey6=PU18D610w6HsXY16f118hzmp5Kw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jsyRw0ljCZ-T2M1pTFU_AIWYgYc>
Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 26 Oct 2021 06:39:10 -0000

Hi,

On Mon, Oct 25, 2021 at 06:43:52PM -0400, Warren Kumari wrote:
> On Mon, Oct 25, 2021 at 6:18 PM Andrew Alston <Andrew.Alston=
> 40liquidtelecom.com@dmarc.ietf.org> wrote:
> 
> > It would help to have a dedicated prefix - as a start - does it really
> > solve the issue though.
> 
> That depends on what we are meaning by "the issue" -- I think that it is
> more "issues" :-)
> 
> What it does do is allow me to filter out *your* SRH traffic at my border
> ingress (and also makes it easier for you to filter at egress) - this gets
> us something that looks and behaves much more like an MPLS edge.

Does it?

This would then require that all SRH decapsulating nodes *inside* your 
network understand that they must only ever decap SRH if it's addressed
to ULA addresses ("my limited domain prefix"), and not to any GUA the 
router might also have.

Like, because of IXP, upstream, customer attachment interfaces...

... which can be done, but I think would have to be made very clear in
the standard documents: only ever decapsulate for destination addresses
that have been enabled (empowered?) by admin config.

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

v2.23.0 | Report a Bug | By Email