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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 25 October 2021 22:23 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 34C533A0784 for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 15:23:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.428
X-Spam-Level:
X-Spam-Status: No, score=-5.428 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, 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=gmail.com
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 IPHIWcfjqvH1 for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 15:22:59 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 67B613A0EFC for <v6ops@ietf.org>; Mon, 25 Oct 2021 15:20:53 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id v16so3509426ple.9 for <v6ops@ietf.org>; Mon, 25 Oct 2021 15:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=asHI2inWzu54O1K5vHBIaQA1SQmFsRDB1VhYTmRj8P8=; b=NP2jC6KDsfkhF8bvPK4rfVVlkDM3vWNVXPjXEsxZQLvlEyPl9LeMSdiZOkfu4jAS2f iiLW5tM+X678Up+MVgqYMggK3oHnxC2SUEFpSy2eWG1FfRbau9geCdY2tSwcivzETidi Ot0fCyTTqsiu91sTq9UBXA4NzPtGtdpmogbMOEQZryC5rCYUCHIFfG97ZI7BXiOVv6BP 5BzJVbkrPyYDLpc4mmtH8GLcS81aA0uYjUWwP5b4zRbp8Hta3rIo1/wpBjWtRzln0R+c Pj8fCaXPWecK4LOgAh4ELXG54MyLPOtE6eXTJfnCcZm/ve2DjvwmR9yHUUiA6fdwyUAW BCNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=asHI2inWzu54O1K5vHBIaQA1SQmFsRDB1VhYTmRj8P8=; b=RUC/1EI0fIOvAHRv9j0lFvYTajE18sTFxAaG9GRJ718UhnuRb7TFd9mIRDt1WSuLb/ OZ3kITjhSppr5HAx7xbyuB6WJTD1OD0c1RugZgiBuh+nQYH6AQXXghb9tLjdYbZXPgbr LQhEP6e4mlZRO2goomm1lVt8bXPhvbWUqBpZYSJc/bkdnNXHDd6IbNlhtUETuk+aO0Qk l0iGZ77hlfplavWufuMhpRjS9kk72mZpNnkFBBe/uyay501doTga/qXJe2i96EY1hmh8 ZRSS9LLwAdDsDQe00RLDvyF9mR96qwRzdVPunfvi85dWezBK+TwjV6gp6kW1z988S7Dd CCCQ==
X-Gm-Message-State: AOAM533NRhKTkPsKg6QZ1zCCILMpTI6uAkpQDFgGym54CLh7rYAuik0t R8TOJ3U5eeKSBGTihq+vM+0u6lAO/9K0wA==
X-Google-Smtp-Source: ABdhPJyb1WPlKiIX8iyeItomuAkMz3uG/WcP3j7EfvzPe0ffxADGe4tTYKxRXH/ZbiE6/Pskir8G5g==
X-Received: by 2002:a17:902:ce8a:b0:140:5c8e:1ca6 with SMTP id f10-20020a170902ce8a00b001405c8e1ca6mr6326700plg.22.1635200449481; Mon, 25 Oct 2021 15:20:49 -0700 (PDT)
Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id n2sm4734301pjo.20.2021.10.25.15.20.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 15:20:49 -0700 (PDT)
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>, Gert Doering <gert@space.net>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <64203a14-efb0-22f0-6026-3a88a2142854@gmail.com>
Date: Tue, 26 Oct 2021 11:20:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <0C1C8148-3D59-4C2A-A834-5B11854B3E7C@liquidtelecom.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9TZL8lF6j-Fc8JoE9oiaa3GrgLE>
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:23:04 -0000

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
>