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

Warren Kumari <warren@kumari.net> Mon, 25 October 2021 22:53 UTC

Return-Path: <warren@kumari.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 0BF513A1412 for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 15:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.855
X-Spam-Level:
X-Spam-Status: No, score=-0.855 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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, 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=kumari.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 xC39hdKbA7Gd for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 15:53:35 -0700 (PDT)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9093A13F7 for <v6ops@ietf.org>; Mon, 25 Oct 2021 15:52:21 -0700 (PDT)
Received: by mail-ua1-x933.google.com with SMTP id x3so6151387uar.13 for <v6ops@ietf.org>; Mon, 25 Oct 2021 15:52:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WRtRmpOPLaWLVbzmlLc/wHxjtcSy2DON1cs+g7MfhCU=; b=U5njZZ2CoHWVKwCXG4La6WDvCJ4xVAj4CcxXK8+OT4XWU/0t21vrJNY31jp6HqbapF ZgK7d1uyGdJyowPCgrm+wYc+p3LTKByuNsh+ZtupJ7d5uPlF18pFDeiJZldUAEd3HGQK wTql29KuMbJhUcCxb/yGXuA/36MEpVGy/Xq0X7DHPTrUeQhTF+wJOA0NnQulicfg9s// Q33urZjMS25XPQK5Lo0MlUiGTzIWBhnc6jwkNIUGPVxwhmUz9N13B8Kxuq4HHpuleglG WRjMuWBydpjCRFWVeZRaTDi4FeJFAv7VwXbUYRD3bw1gQWxWkGskFcUzPPOnq2ULTesa NSig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WRtRmpOPLaWLVbzmlLc/wHxjtcSy2DON1cs+g7MfhCU=; b=Cai9OiQ6gHlIvoMWjLigHvXC6GXzQJ2BWpvB5CD7SRLIkDZNawAn8Uo14R0dgK5jcZ eXldF8Vgs3YD8OYzpoNWZoejQtbI8r4v2AWc9aHtuGsVge1qm9Tl6ID94+6yonI9bvPI Gx6vQI2Pn/3RwjVfRxsU3OtJzu7z8puMooj/kt+tgiRa4ccHbyrbi704Tz7QpIVIe7kh ET45XAFJrCOC7t7J/XL2N60aYjd3fuKp2KdPwQMD93e46HLBwi70rAMVpMLd2z8wZVBv SPUw04OuVAF5I1CdyTUZPVE87ZbCfCil7W7bsmvUVKA1fRx6YL2IzF2qJajD8xauSXhw Zxxg==
X-Gm-Message-State: AOAM531n+WVkiMAkZOmFRYwFdIAXdwib6J38uUiqpr2EjOBcrX45sImf h1ccnXqcJZoqhjxr8NK8fkjTpH1O/7j/cc/Ejm6gMQ==
X-Google-Smtp-Source: ABdhPJxr43GUw8HS/SYWToHl7aqHxHNBHsbhLzn7SFIcaZnMpJrBHFexdBN6MbJcpP1Fv6Zzq8SoOwYK+LlaZnpe/WE=
X-Received: by 2002:a05:6102:c54:: with SMTP id y20mr18596359vss.30.1635202338556; Mon, 25 Oct 2021 15:52:18 -0700 (PDT)
MIME-Version: 1.0
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> <64203a14-efb0-22f0-6026-3a88a2142854@gmail.com> <F8ABB54E-A1DC-4D10-9464-58250FF30BC5@liquidtelecom.com>
In-Reply-To: <F8ABB54E-A1DC-4D10-9464-58250FF30BC5@liquidtelecom.com>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 25 Oct 2021 18:51:42 -0400
Message-ID: <CAHw9_iLKkiG=jW2Uw0F9jKwaMzXs8r=xrmD-tFuqcW2QOx=quw@mail.gmail.com>
To: Andrew Alston <Andrew.Alston=40liquidtelecom.com@dmarc.ietf.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Gert Doering <gert@space.net>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000086a9e505cf353636"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bHxi8tdFQJ-_rc_SFqQxxZwZG-0>
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: Mon, 25 Oct 2021 22:53:46 -0000

On Mon, Oct 25, 2021 at 6:32 PM Andrew Alston <Andrew.Alston=
40liquidtelecom.com@dmarc.ietf.org> wrote:

> Except Brian,
>
>
>
> Normally – a single rogue host because of other protections can’t do near
> this level of damage – because they can’t send packets that can get
> decapped in the middle of the network with no way to define what happens
> post decap with the inner packet.  Normally you could apply a whole range
> of measures to ensure that a single host may be able to send a stream of
> packets to some host – at that point – it gets found and stopped.  In this
> case – that rogue host now has the abiity to inject packets practically
> anywhere on the network that cause attacks to happen against external hosts
> – and good luck tracing it.
>
>
>
> The ”magic” prefix lets you filter which hosts can send to SRH SID’s – but
> as I said – it’s far from perfect – because there are still a host of
> issues with that.
>

Yes. I'm **certainly** not disagreeing that it's far from perfect....


> But – lets also be serious – the level of damage a single rogue host could
> do in these scenarios is wayyyyyy beyond what it could do if it couldn’t
> cause the decap and act on <insert random router anywhere in the domain>
>

Yup. Allowing a host to participate in making routing decisions (whether
that is participating in an IGP, or allowing it to steer its own traffic
and encap/decap) makes the host privileged. I'm trying to make it so that
it's harder for unprivileged things to accidentally (or maliciously) become
part of the privileged domain


>
>
> Andrew
>
>
>
>
>
> *From: *Brian E Carpenter <brian.e.carpenter@gmail.com>
> *Date: *Tuesday, 26 October 2021 at 01:20
> *To: *Andrew Alston <Andrew.Alston@liquidtelecom.com>om>, Gert Doering <
> gert@space.net>
> *Cc: *"v6ops@ietf.org" <v6ops@ietf.org>
> *Subject: *Re: [v6ops] Security issues in RFC8754 and related/subsequent
> drafts?
>
>
>
> Yes. Rogue hosts *inside* the domain are always going to be a problem.
> I don't see how a magic prefix can ever help with that.
>
> Regards
> Brian
>
> On 26-Oct-21 11:12, Andrew Alston wrote:
> > It would help to have a dedicated prefix - as a start - does it really
> solve the issue though.
> >
> > Imagine a device with a stack of cloud servers behind it - each server
> terminates on a separate sub-interface - and now you're trying to apply
> what is in effect an LPM filter to each and every interface (as compared to
> host based firewalling or other security mechanisms) - my question is then
> - how far will your tcam go - how practical is this in reality.
> >
> > This is as opposed to if there is a separate ether-type where an
> interface is either configured to process it or drop it on the floor. So
> yes -
> the prefix filtering will help - but I suspect that you're gonna find many
> many scenarios where this actually doesn’t work - and all you need is *one*
> filter miss that has a compromised server behind it to have real problems.
> >
> > Something I haven't got around to fully testing yet - but let me throw
> out an interesting scenario on my list of tests to do.
> >
> > Rogue host A takes an IPv4 packet and encapsulates it in an SRH - the
> First sid in there is any v6 router you like on the path - the packet gets
> there - it get de-encapped - same as everything I've said before. Now -
> the inner packet is a v4 packet - it has a source set to random host
> attacker doesn’t like - and its destination is 255.255.255.255 - which
> thanks to rfc919 will not forward - when that deencap happens - does the
> packet get dropped because it can't be forwarded - or does it get treated
> as a local broadcast. This is a rather undefined scenario - if however it
> DOES get treated as a local broadcast - well - then we have a really big
> problem - that’s called smurf-v2 (and even if 255.255.255.255 doesn’t
> work - more specific broadcasts that are attached may well work). At this
> point - when the broadcast packet hits the hosts behind those broadcasts -
> they will reply to the spoofed source - this will follow stock standard
> routing outbound - and the protections we would normally use aren’t gonna
> work (the source of replies to the broadcast packets would be the hosts -
> they are permitted to send packets to the internet)
> >
> > Another scenario - sending to multicast addresses post de-encap - do we
> have a potential attack vector to poison ND? Again - haven't had the time
> to test this.
> >
> > Same thing applies to a whole long list of other things - effectively -
> if you get one compromised host on the network that can inject a packet
> that will de-encap and act on the inner packet - with absolutely zero
> mechanisms for verification of what is in that inner packet or how to
> handle it - the list of possible problems is - extensive to say the last.
> All I
> am saying is - we need to really step back and think - and I think this
> needs a veryyyyy close look - because in initial tests I have done - and
> without the above additional tests - I can tell you my results are looking
> positively scary (and once I complete the full set I'll publish some
> scenarios and results with more detail)
> >
> > Andrew
> >
> >
> > On 26/10/2021, 00:48, "v6ops on behalf of Gert Doering" <
> v6ops-bounces@ietf.org on behalf of gert@space.net> wrote:
> >
> > Hi,
> >
> > On Tue, Oct 26, 2021 at 10:44:32AM +1300, Brian E Carpenter wrote:
> > > On 26-Oct-21 10:31, Gert Doering wrote:
> > > > On Mon, Oct 25, 2021 at 05:20:51PM -0400, Warren Kumari wrote:
> > > >> I somewhat like the idea of having a well known prefix for "limited
> > > >> domains"
> > >
> > > fc00::/7 works well. RFC8994 is a worked example.
> >
> > So how would that work for an ISP network trying to run SR6, protecting
> > its network from rogue hosts inside? Without having GUAs on the SR6
> > routers that would happily decapsulate incoming SR6 packets, and
> > without violating lots of rules about "do not leak ULAs outside
> > your network" (traceroute and other ICMP errors)?
> >
> > I lack imagination today...
> >
> > 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
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra