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

Andrew Alston <Andrew.Alston@liquidtelecom.com> Mon, 25 October 2021 22:14 UTC

Return-Path: <andrew.alston@liquidtelecom.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 7575C3A177F for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 15:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.109
X-Spam-Level:
X-Spam-Status: No, score=-3.109 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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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 (1024-bit key) header.d=liquidtelecom.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 34s5ckfArniF for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 15:14:00 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (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 ACB9B3A122E for <v6ops@ietf.org>; Mon, 25 Oct 2021 15:12:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1635199964; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=W4KqutTU8OrZrj+nVCDVkDvNYTbV0G0egaJJTGeMvG4=; b=b9vQQez8dQAwCNU3ElWYHBZE4VcVdgrMQ3clslyMCyCe8+WJaq2GUxXNJf8JH+Qfe5EV1q a0MEHuA9X/yr8ewxpgpASo0eA98vTHyb/hin1PCYbrvFh7qWTgCBr8Ybt33CVq3SuGadeK MLIRvxeBM70rN7HBK21h4eb8glctSNM=
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2056.outbound.protection.outlook.com [104.47.12.56]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-137-38VkIlLUOpmdKfTZIfvhzQ-1; Mon, 25 Oct 2021 23:12:43 +0100
X-MC-Unique: 38VkIlLUOpmdKfTZIfvhzQ-1
Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7685.eurprd03.prod.outlook.com (2603:10a6:20b:400::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18; Mon, 25 Oct 2021 22:12:41 +0000
Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%6]) with mapi id 15.20.4628.020; Mon, 25 Oct 2021 22:12:41 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: Gert Doering <gert@space.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Security issues in RFC8754 and related/subsequent drafts?
Thread-Index: AQHXxp4zP+qugBEUYEKpNlrZT9uUPqvfT9WAgAQhrYCAAM2ggIAAAuGAgAADvQCAAAC4AIAAOW6A
Date: Mon, 25 Oct 2021 22:12:40 +0000
Message-ID: <0C1C8148-3D59-4C2A-A834-5B11854B3E7C@liquidtelecom.com>
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>
In-Reply-To: <YXcl2iQMvZe8ggLs@Space.Net>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.53.21091200
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b6b5c707-fe36-4564-4114-08d998048fdc
x-ms-traffictypediagnostic: AS8PR03MB7685:
x-microsoft-antispam-prvs: <AS8PR03MB7685CF68B090920147CB39A0EE839@AS8PR03MB7685.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0
x-microsoft-antispam-message-info: T8k0Q6IE3uXWDDWV+xJ73tTln9upT79kA24btkWC/yfBGpZagai8b0a0DyWr/4c0SfG+EcCNONGSYx71OKsSwDP0qNnRy2PiLeDNyT4OBwK6AB4IjCofVdq4HmzRWNRozp7KCykswYLsOWlqt578PAEgj3lLExsZafxoEr5uuJXObLMRdpS9d/Vu0iCSGjNhsTvF3Uinr8FvZV4qqb2GWS1Atatc8RuNiA5K3p//zDO3a68Z/4141BfBftk7WdNpBjD4c/SZhp/wNEB5Y/DhKSItDnOms3murYqDlI4N4BQm/k+wqEanNg1oeIB7dqQLt4YuNHCc8pwIgscaMf0oJV0UdeOl2LhkgXuKFDNR9n7FfitxGI/JFP5wkbqaF+I2fQggf7RykgQg+cSjFwMkWgUQrxaHqGNlUgfJ/p59eS6t/4t2LSflchfozdo5LIrHqHlx1f+zcYyNq8zKbcwsziSkVKCqZY2WaDCX9lgCuwDZ+2MbGTGCIFT6ENIRrZZx1AIxKr08bOWCcmajaiexppb6q6RAHsuSyUv5ODZb2vVFiEsmzaZiyVZCmPEf5EzMbfdb4f6BilIGoFgtQ98+7wRR2Hr1/mOLqo96CXR7JtIwzqZG2Cw072tWO+zcwG4hZ402XAB7xpzU33j+4tNHqTHY43+ncSedHgb/jHHbAvWWb9f/Zju14hNqma+OTczag5abHbmIqJvRkQSC9zRk2263Maf99NF+CkkOFpHfxIbRaIDlzwuBlomlQQRqyOge
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(15650500001)(110136005)(498600001)(8676002)(66574015)(66446008)(53546011)(66946007)(8936002)(36756003)(5660300002)(6512007)(4326008)(83380400001)(6506007)(64756008)(86362001)(38070700005)(122000001)(71200400001)(186003)(6486002)(91956017)(66476007)(38100700002)(33656002)(2906002)(2616005)(66556008)(76116006)(45980500001); DIR:OUT; SFP:1102
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 4+VWS88cQx/VeqOvfiS93GuOoO2xZvQtRtQIOvYkrghY5rmZfs5mNkkaI4iSKqMCrHfEsOcMmoZmONP8k1zF/QCZyb5ZzqI5Ranldwo+AnKtKNH6GIB7qE7/rSkRY/5Vm++EZMSbKSBxATb88rq1v7/8y3wUuR5aPJlAcaSZWI5+107MHHYg/qVTjn8z9TryGsbXL43lQKjHkLTwnkbZzwxIilS14/PRvsSdRVtxRwWKWjYkqHFP+HrCR9ztEOd7i0x6+XEjy13WRYdH3evx3LBRvXFxUXLCaYBsr8zyxpoHfPl9FmqfR4Gr2Dc4gRt7wkXwsqCfiP+WrF/8ewlXMnP7DW9rcdIMBrJx2JaxsteA+h7z5OcCkAi0hkxl8nn1UGn2kUY+I0F86HA8rHbxLEnwgpkD8iXj6+0wvq8A9YLAJpAuzSbod0VE0OmPMXyQTO4E4gdvg4mkAiv0EvW6qXDhgeHl4Ek7xNqYDEa9GgdvG9vAvhSQulvLWuZbAUVThtXfLT5rm716VB+zkYr53pgMWRkepPIAiH+qExv04vhy5aj01qSlS7vsmw4WwqUf989/SHAze6E3757bn4OF+lTOBUYZwceJjIYOixcE0RtX5avQnyEQHX72e4S7acMxec4vJwGGzlgRA1mZEoIon8oGdNM2F2Jv4io9WHHt27HVik8qo956dNM2En2hfWDImpcrfoB+8TRa2mJezfH+a6npZl04oddBTIZ3z4960sZpdwwDoorCYlVx7opnH2NsSdctnpUxLmGPPLPRvPhsLbKNRcBl9O1rC3lsBziACxUXaCZnuTYFwwmSdNrEh7Df2TZdG37RbmwJXYhhAAw/UUqUwd8p7xE8/R6H8B4Sy8e8WMqcAS69kJJvgvJHX/xqJpVX8qYUHbX8W5AUr6fXMTlSUa9MJJYSVukgbubTk83dzQ+ChtVZWmdS6Fm53StFayCdhqVrMnjPkUlF0bmrx+R1hkKTWkzfHOBoSfEiNQVZ+buRWc4Hw8rZXdOHuk6ke3TAlgPWDWPU8xIkXNQeREBZgUOJP2j9/HMx+cv6RrIPcRHsXpIYlaFTvtsLQ2j9G9sP+VcrODrVRTJLIkrAfQVFmnKDwqalJ/GleiHzWe9LEGVRednA/rqWm7RqfSHbWdNpFxLT31J+/L9jVMpiEUCJFFIiRYRvFId/51xGFUza8gGTFMItvRQVTo6k2KHFRw7ZufzUn3pXs8OozTKjRlWmQiS0dh7IVbvpCUfSBcUCTb2n+0G5G4KeMsGXKScWlwK78zOEQAvrOf5poKnzNZTN64jICe2Y8kijbpLK40goTgsW8FQW7HbZJsiYuokjo0//bGP7QeHpvY9f4neccKSvxRXMF8y3RYo82kszFzex865N8loZ/J7zDxnyNNLH67bfvqiPhvBFhWqqJcmI6+mccWM4if2IJGXkNpyRdp0+bWyBx0dkmGAqCvz0TsPQkNu622Ch5hm54070fw/tGsqs/844y5fFtVIcs1AvaW7z90/mlZzldl9IUw+381MdwXVmwS5S/cm1SLKDcmMe7Ss1OrYp2hMBTu/yNVCKJKrC3a/98p+dICy85dejZHm6lkNEDRkYVoWrICX6fpsOHi0n0O3hgixZED0snC4YdEHusjxBpGtGCyzaBypirmd+wMxxMijJq+E+IwpfHzX//mOMcm09516LCAE72nkVOuq5d5OzG2ade0BnOC+qSszeS0ZdeTgutbGQXkCbdjFaNA==
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b6b5c707-fe36-4564-4114-08d998048fdc
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 22:12:40.9189 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5/mcEy4fnG0RBcrsz2VnJ48CBw7OCGn935OsU316nZW6yQLS67rYO343iICLbYZPABQ7qdTBwSfbG6ge/5qkNTzzGBr5WeMftU+4zR5g9/s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7685
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Language: en-GB
Content-Type: text/plain; charset="UTF-8"
Content-ID: <17353CA24C9D644D9FFA086F2AF2777A@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/wECxlKfpX8227XpLJiX2r5trn9g>
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:14:12 -0000

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