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

Ron Bonica <rbonica@juniper.net> Thu, 21 October 2021 19:06 UTC

Return-Path: <rbonica@juniper.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 EF5593A08AA for <v6ops@ietfa.amsl.com>; Thu, 21 Oct 2021 12:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=Jg0g1y56; dkim=pass (1024-bit key) header.d=juniper.net header.b=C9Kqxagz
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 MchrNRNgzPyo for <v6ops@ietfa.amsl.com>; Thu, 21 Oct 2021 12:06:26 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 79B413A08AC for <v6ops@ietf.org>; Thu, 21 Oct 2021 12:06:26 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19LHQFKO010712; Thu, 21 Oct 2021 12:06:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=lb/gJecLsooSZYlb8Ni0EwHyrm8e7CTI6SJD9tcoK4s=; b=Jg0g1y56O3e3/ru1f3OOcBIvmI5O4CKi20UJ8LeJWx/ddi4NzSfTzGjAai4yomUlAIZg AifhFX0OfJs3okAvbBAPkAO4z8kDk/cpbfzuDJ7qWaM6U/dlgMRpZq3CiLoMv+BgOLZg s2d+BP0V+lKELvFyeWgseRXYFxPQ9w+rPLXbNUr0SzSUh6xbrjwUIMjUKrapf8PXGS2E dG0HH9rS9gASTIQ9IXb+W/86miUr0IEw0dXrRNcahHxS1Nua8AxMgSd9Axg+bTEokHI6 gtWama2tqU43K6cHpSnyI6fpvwSPlPKXUg7yx6mYjzymBCKkaxKBAevesU8Bq2YFcrvr kA==
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2042.outbound.protection.outlook.com [104.47.66.42]) by mx0a-00273201.pphosted.com with ESMTP id 3bu483s8b2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Oct 2021 12:06:21 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bX1QQgXHPGyRDbFLUXxR2nX7/fj6NkBvnJtsP8N5XdPU1P08CMsxuAzL+D7nm3S+3znCQGvFC7UaPEe4EhncZ1G9clgoo1M7qeyOdz1arNwuwCekB8l/6qY8MZWChNNGAc9Ft/PrtPmPp764HEvXxlEBqt7YqDExHtX87xOmWIdmamVXnRB8VUSf6By2FyEiVZJdzlMyMPX9MdoujrYyNqcuxSzboT4P0nIzYE4il0tTe8yyxBWvccYTqDXfS1mT/gOeJ6wH1xW5YFG+jO+THlq4DMggryeW6OJIn+mdghTwL2Gx9VglIg17sBKuPz8iYhTCCK6LkUppyzHhMsoYaw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lb/gJecLsooSZYlb8Ni0EwHyrm8e7CTI6SJD9tcoK4s=; b=d/jw55Ajg+4BQ0nQAo/+xgPKbw29SfPNI7piU0a/jNP0oYRp9+942rCDx6E4+w8BxGF6TYixcwPrYADCrT5eXu0Vi19YGElzqfUfGPhwfszl9qPAw3R0tudZaUG3DEd7wTR88/AqnC4kiF+Qeijmrv0DLz7lWDIty3kmtamIQ4FnVDpPOc6iFx08xu7iY9mL9OP8d6sLb9DCOsMQfzvv6wonCBiHHHLfKvBsLHkpmWQr0WPPwutI5nku2sID7OOo8K0JKOMjm9sC+ZT0b24BbSbMbs0LM+cqizmzt7vJDEvfq1w8OGDg5Cnd+ykMuWVbt6xAiNEdIj7bFopS58smjA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lb/gJecLsooSZYlb8Ni0EwHyrm8e7CTI6SJD9tcoK4s=; b=C9KqxagzizW3yLWaM/sYQjQurehnpudKhks2DOE6KqRQeN/GRCvPBb8Su6AKcau7w0adWjoTdTeMkH0nlHCr/fgnObGsEYV1aSZ1ZqDynTNLb+A6woA/zvMxuuWNU/fBFETlhmHTujBbCLxmMdwWOE6hEocaoKdvEiUv5qBVvGY=
Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BLAPR05MB7475.namprd05.prod.outlook.com (2603:10b6:208:29a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.8; Thu, 21 Oct 2021 19:06:19 +0000
Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4628.018; Thu, 21 Oct 2021 19:06:19 +0000
From: Ron Bonica <rbonica@juniper.net>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, Andrew Alston <Andrew.Alston=40liquidtelecom.com@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: Security issues in RFC8754 and related/subsequent drafts?
Thread-Index: AQHXxp4zP+qugBEUYEKpNlrZT9uUPqvdspuggAAbavA=
Date: Thu, 21 Oct 2021 19:06:19 +0000
Message-ID: <BL0PR05MB53167D46793116FC1AE23F1CAEBF9@BL0PR05MB5316.namprd05.prod.outlook.com>
References: <CB45220A-ECE6-492A-8A37-D189A71CDA2B@liquidtelecom.com> <dd321b93e3ca40f388eda18fd726bf67@huawei.com>
In-Reply-To: <dd321b93e3ca40f388eda18fd726bf67@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-21T18:58:26Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=fd9d6592-ea47-4fa0-9aef-3c8f506859b2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true
msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2021-10-21T19:06:17Z
msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard
msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755
msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4
msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: cf2cbbe2-e730-4ba0-a9bd-df6338a68c89
msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8ae1ea0a-0940-4a8d-f6b1-08d994c5dd59
x-ms-traffictypediagnostic: BLAPR05MB7475:
x-microsoft-antispam-prvs: <BLAPR05MB747586595EB287A9B6AE3BBBAEBF9@BLAPR05MB7475.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ye0E7jdvlb5HGtHDSZfMtYe7UrPemiWQTt8YEdJJe4DGHq2t0A0PWBjJ8XNjqOZqPvxJKxpRKLOSJeijgdtjXQdfrJrwuq9ksPjGf9zhQ4RmLCkaytXkOT3Y7SJF9lH2jUaDMSOTAydnafuHfZY9+lf0kBpvP/9iP6submrtRL5up5VCf9XIqrNwbeqSnttPtmJmW5ov//kXrziDl7Uo55cy/thFTu64UB5W8y2TfqAX6cSj3BwIPLI+84G6bD+3cuDb7rquBxHOlXaW6PWQyDJvQkU/iu3upf2Ia8N0GchY6dtAbs9/4X3gF4W19XlJYtgFu1/T4HOMRqUR/U2NRwOhO1d2ahhgGeceUpUe5X2m8PGX+x4ScKOnI+Zq5Ipqar2egguf413onskmGjF9/uXt7Ec2LdzoC5t7UaJ0ryhXGVnI8t1VFbe2EyYWSETnwolxM9IA+d5O+FW4VTgZWgk2nQOGtkLW4v3i25Jrij8B54ZxOCtcYT/mllEesR4RUVcOlDnuqqswc2UZ2uNVczHpjEvk/Mj6TzKyFEzofiTiyBHxSBVis50WYGSXseII9WB2e0kg69px8AJ94tMru/csqr9MZyOdUTCUrFAXGS+g+xMVDt27vI7CDCd1fHCPjZ/qMKSI3LXQEmOcejgcP+fKkzr7oHnl9NN82TGN+brxNoqGj+9Y+fA8KSu3gjJ372T45Uo/Jde3685RwANCPA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(76116006)(66556008)(66446008)(66946007)(66476007)(64756008)(33656002)(8936002)(52536014)(38070700005)(508600001)(6506007)(83380400001)(55016002)(9686003)(38100700002)(122000001)(5660300002)(86362001)(66574015)(26005)(186003)(316002)(71200400001)(2906002)(15650500001)(7696005)(110136005)(53546011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?r9WYdnPJBxwA92Tzr6vRnMmZNdlvB71KcWSRMLjTmFz5V4YH40o5e94rnrg4?= =?us-ascii?Q?XVzhlEBkDDN9z57T8XcaAHco95N+w+1oShOSMxnlGAI/8qvRw76j1EqTuLXA?= =?us-ascii?Q?stEWEUaTSPkwil3Gv/cIE1tSWNSDn6B1ygtpvgEto1uDa0vFzTfzKDe7SmBS?= =?us-ascii?Q?tauZVEviNZeyuZrLF5WMw2P3EsJ8fY60hR5CTNAJibVaEYbdNKAAeo6ur7HF?= =?us-ascii?Q?YZKrLVpIP0EVUFiNn5EC6JoMH4ZewKGbOwyfXAvPsp0r5AIfmpcZhtDZG7yc?= =?us-ascii?Q?NTEr7O3UyYl5Q01LSXkkEX1mTqIplwi7IP53Ppqhh4SL5JisJ/R7vTt3jHTP?= =?us-ascii?Q?69gzgQgdutcxitslTdntsDDHRPwnM0rU9+X7ALN4l/ZdiwmMFWF7nMbbHESP?= =?us-ascii?Q?1x+0oXZAqJ0iGP6vl1eeIlS902FLNRih1iavP1oMysg5RTY6ghE23gj4eFiA?= =?us-ascii?Q?TpRki3QhyHlFV6r51trichONLG1sLnBkZXaJ4vxsjw7x84A1+dG1Z9Ah9b9s?= =?us-ascii?Q?NgzaBZTLqhYV1sxmZGB49PuJtrUEGsSIaYYYLEomCzfxV5CUp9sLvZcTnAqK?= =?us-ascii?Q?0foZYyYsumpwEDrEyt2N7T9u96PYqx9pCXEV10fi47vE9Wn5Qua+JB4ZbD5N?= =?us-ascii?Q?4fLzKUHQidzTUKAtXWJYbAWJk17DDlWSG/R5k4CiZmRguifaWu7fpUNNbiTj?= =?us-ascii?Q?/FVqed8kR62Ws+WBsgF+1uCxfQcgqZ5T9q0ysAvxjVxPLEHrJWKHEegx7Pea?= =?us-ascii?Q?t30AGvlY8BNucVDfePGHWicxROczlfoTg0I10HKygNC7wccLhDm/6osN0+FC?= =?us-ascii?Q?4t37lXJSvyN5VFNwMgu3aYyFTzT2AABe/k37qZXQ+bGM0ECVr2rrqJ6cPd8i?= =?us-ascii?Q?PBZX/EBI1aaJ6IXLY0ht7K38GeZBUIchxrEnDnwAHO0QITRvASKu8HQB1hh3?= =?us-ascii?Q?hu0s1bcOkERR72QOwcIH2byybfl2ZFsKBUGpUufVL2SkSNDDlgvVTjRQ2AF8?= =?us-ascii?Q?/Jc/SelkSw1olZvcuIFVzbK6NIwcd2iT4E4cNMbThm/2DA7ffJJ51v4dOelN?= =?us-ascii?Q?Ofbx/7w8ZCu39rs0ONfiJ1T0tcjE77PEivIFANq6Lr3Z1syKcYQILIyeF8zJ?= =?us-ascii?Q?6TtlKGleNIz81WSffWFnCzAYfj2uANWh2W9UWPb7RwHG10KCH6qn0XTfMKol?= =?us-ascii?Q?Ml9/ldkH0cJGKjqUBUmK28ST+PRgrYPj+Qa980LRQhgMI2MO92CNtxrVnvhY?= =?us-ascii?Q?HvUKTj5IqTpLon3hm+esSKlZxgj9VHyVxu9u0Z8TjzLTYg9c2cCUDScVApHT?= =?us-ascii?Q?NBoLRw+MxwTTCg8ECmPTSoaE/Hqw4lB1gEmScB80ZAklR/GVoQ13fz/Un9ob?= =?us-ascii?Q?NmmtXpWB3EFpXi0n4X6AfLd+3uexj2GUUkSVOfDt82PXaPqcv7eRnwIa6B6c?= =?us-ascii?Q?6lygd/syZ64=3D?=
Content-Type: multipart/alternative; boundary="_000_BL0PR05MB53167D46793116FC1AE23F1CAEBF9BL0PR05MB5316namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8ae1ea0a-0940-4a8d-f6b1-08d994c5dd59
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2021 19:06:19.1435 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rbonica@juniper.net
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7475
X-Proofpoint-GUID: TGYdwBzqE1-UbGEAVy70QiYs27EZ0jmX
X-Proofpoint-ORIG-GUID: TGYdwBzqE1-UbGEAVy70QiYs27EZ0jmX
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-21_05,2021-10-21_02,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 adultscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 impostorscore=0 clxscore=1011 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110210096
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8U6GAXTeB5EPlqiDJ5MMpGpCKow>
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: Thu, 21 Oct 2021 19:06:31 -0000

Ed,

Some SRv6 packets do not contain an SRH. The following is an example:


  *   The packet traverses only a few segments
  *   All of these segments are encoded in a single C-SID container
  *   All segments exhibit the NEXT-C-SID behavior.

However, I agree with you on one point. If every SRv6 packet contained a routing header of some sort, this problem wouldn't be so bad.

                                                                                                                         Ron



Juniper Business Use Only
From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Vasilenko Eduard
Sent: Thursday, October 21, 2021 1:23 PM
To: Andrew Alston <Andrew.Alston=40liquidtelecom.com@dmarc.ietf.org>rg>; v6ops@ietf.org
Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?

[External Email. Be cautious of content]

All router's ports should have RH type 4 (SRH) filtered out by default.
Network Admin should activate RH#4 support only for NNI ports.
Problem solved.
Ed/
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Andrew Alston
Sent: Thursday, October 21, 2021 8:08 PM
To: v6ops@ietf.org<mailto:v6ops@ietf.org>
Subject: [v6ops] Security issues in RFC8754 and related/subsequent drafts?

Hi V6Ops,

I thought I would raise the issues that follow here - and perhaps we can look and if these issues are real - and if so - what the solutions are.

During a close review of the compression proposals for SRv6 (CRH/G-Srv6/USID etc etc) I noticed some potential very real vulnerabilities in SRv6 itself - which by extensions would affect srv6, srv6 network programming and all the compression flavors - including CRH on which I am a co-author.  Having raised these issues with my CRH co-authors it was agreed that I raise these issues here so we could discuss them.

So a little background - SRrv6 is typically considered as something that should run in the confines of a  "limited-domain" - the question I started with is - can we actually define and maintain the boundaries of a limited-domain - and if so - how.  The conclusion I came to was that the concept of limited-domain in regards to SRv6 was an extremely fuzzy thing.

Now to understand this - we need first to look at the typical methods of protecting things


  *   In the case of MPLS - we have what I will loosely refer to as a "fail-closed" scenario - that is to say - unless MPLS is enabled explicitly on an interface - ingress packets will not be processed - this works because of a separate ether-type
  *   In the case of SR-MPLS - an identical situation occurs
  *   In the case of dodgy IGP traffic - again, we have a fail-closed scenario
  *   In the case of standard IPv6 - we have the option of utilizing BCP38 and ingress filtering - and the same thing in regards to IPv4.

Now - lets examine SRv6 for a second.

In a scenario of Host A (A linux box) with address 2001:db8:1:1::10/64   utilizing a gateway of 2001:db8:1:1::fefe - packets from 2001:db8:1:1::10 flowing towards that gateway would pass ingress filter checks based on BCP38 since the source address was legitimate, unless we explicitly filtered out where that packet could be destined for based on its DA (More on this in a bit)

Now, lets imagine for a second that Host A gets compromised - and an attack encapsulates a packet that has an entirely different source address - and whatever random DA address inside an SRH.  That SRH has a SID list in it - be it via a direct SID or via compression mechanisms, and a DA towards the SID itself.  The packet then routes - passing the ingress checks - and landing up at the router with the first SID.  Since this was the only SID in the list - the packet outer SRH is removed - and the inner packet is forwarded to the FIB - and you just bypassed BCP38.

In a similar mechanism, if the SRH states that the next protocol header is an IPv4 packet - when the de-encapsulation happens at last SID - the payload (the inner v4 packet) will then be forwarded via the FIB - and off you go.

Now, normally to protect against this as stated - an access list would be placed on the networks borders to prevent encapsulated packets and packets containing SID destinations from entering the network.  However - if we consider the above scenario where the attack is coming from a compromised server inside the traditional borders - we have a problem.  The application of access lists to every port containing a server is also potentially unrealistic and unmaintainable (not to mention could potentially on certain devices overload the TCAMs)

We also have an even more potentially deadly issue - and this is entirely theoretical at this point since I haven't had time to really investigate and test it with real code.  Let us presume in the above that the same host A is compromised.  It encapsulates a packet with an SRH - the internal packet is an Ipv4 packet - and its destined at a broadcast address of an IP subnet that is bound to the same network as the de-encapsulating router.  The source of the internal v4 packet is spoofed - we've now managed to - through a use of the tunneling mechanism, effectively created a version of an old tool called smurf - in a manner that is going to be pretty hard to trace.

Another potential scenario - would be for an attacker in host A to jit some ebpf code - that matches - modifies and re-encapsulates incoming return packets and retransmits then. Each time applying the same SRH.  The inner packet could be pretty much anything - so long as the internal DA is set back to host A that is sending the packet.  The packet would then flow out as an SRH encapsulated packet, the outer header would get popped, the inner packet would flow back towards the original compromised host, which would match it modify it re-encapsulate it and start the loop again.  Doing this with ebpf and a kernel jit - would be pretty difficult to spot if you didn't know what you are doing because you wouldn't potentially see any obvious userland code.

As a final thought - consider a hypervisor based system - that has multiple VM's on it - and the filtering implications of all of the above - and the filtering becomes even more difficult to maintain and more complex.

Again - the filtering per every port that may contains a server or a desktop - that may not be realistic - especially when we could be running multiple ports that are handing out source addresses via RA - so - how do we solve this - or is this a major flaw in srv6 itself - that needs some other solution (give srv6 its own protocol code and acknowledge that it isn't ipv6 at all, allowing for a "fail-closed" scenario maybe?)

As an operator that runs extensive IPv6 - I'd really like to hear thoughts and comments and potentially we can find a way to address these issues.

Thanks

Andrew