Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?
Andrew Alston <Andrew.Alston@liquidtelecom.com> Mon, 25 October 2021 09:12 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 06FD83A087D for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 02:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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_H3=-0.01, 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 Xytam2fE695c for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 02:12:26 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.85.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 2EDE43A083F for <v6ops@ietf.org>; Mon, 25 Oct 2021 02:12:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1635153143; 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=Ec10Z2ZGgPMdrMh3UW8xPxFrE4A1YvPTiOfHcKQSdgk=; b=o5K/muH0Dt5zNSaB4vEduEXghMZPHNnRyBOMXbmPzsfO5V2bmLWZdZS6QSn8jNRpp/0gAP dVci6wiJ18KIvZ/MLerEBt2r270j+shn+dYYHK/gcG67+6amjLbT84oUHwCAH1h0wmayln MqyXpk1DABOeGpVCwcgGw4bTMLTWzZU=
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp2052.outbound.protection.outlook.com [104.47.1.52]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-132-c4f1lTRPM4yp10R6DE-ecg-1; Mon, 25 Oct 2021 10:12:22 +0100
X-MC-Unique: c4f1lTRPM4yp10R6DE-ecg-1
Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB8070.eurprd03.prod.outlook.com (2603:10a6:20b:441::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.15; Mon, 25 Oct 2021 09:12:20 +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 09:12:20 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: "otroan@employees.org" <otroan@employees.org>, Warren Kumari <warren@kumari.net>
CC: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Security issues in RFC8754 and related/subsequent drafts?
Thread-Index: AQHXxp4zP+qugBEUYEKpNlrZT9uUPqvfT9WAgAQhrYCAAACKsA==
Date: Mon, 25 Oct 2021 09:12:20 +0000
Message-ID: <AS8PR03MB7622CBFEE6C16B9230C593A9EE839@AS8PR03MB7622.eurprd03.prod.outlook.com>
References: <CB45220A-ECE6-492A-8A37-D189A71CDA2B@liquidtelecom.com> <CAHw9_iJy_OjSwRDRx5cbB6yhau7XzNUKTi49sHhi0CnmRARQUA@mail.gmail.com> <1F31CC6F-8471-4B50-AE3F-9E5FC76BB447@employees.org>
In-Reply-To: <1F31CC6F-8471-4B50-AE3F-9E5FC76BB447@employees.org>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cbb6c6ef-b692-4f2b-a376-08d997978cba
x-ms-traffictypediagnostic: AS8PR03MB8070:
x-microsoft-antispam-prvs: <AS8PR03MB807099A43E08D7A0B5AAE94CEE839@AS8PR03MB8070.eurprd03.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: sWRmaRbKY9kTG+sS6oK1VeFbdvXxJBK70BBu8teOPD87AVHBeskIj7gSSHtw8MjqwDBcNsPSmtzof1D/SV/OkAbc0CvNN7IZX7U/tKVrZ9GaGYgUgUxemNoYAiTqTH1UiqRYHPlSLpKQGO4Qf4FXAf9RIIOXvD3BixNzsrMPXYSe3IDsX9rnho9F7t54mMjQm7xs/xHms6keOg8eEm7Rzn7w4yGqELWI0qiWdwKlyTz30BFJvONm8cMio81X4PS/2SqwlJtFFh3OAcJxGC3RlSPrVNBJAngxQ2uoH59RqJVXubZs5NAZwZLBvbhb6lZkGZ8h4w2Rk+RafpNTahJggKR1CZq0KDcV+r09IuYeFG9sZTc0N7YdH/wjF2kSWKyJ8bPoWVHAQTYls0ef2l5UX/S1x2vQyAKK4/ScwS7rSx+i2+Gd5V9dPizpVkg7/TN0HUAjfdgthlu4f3zqZJBF1EWXJAkRkKceNX9VCaO/yQl1Eene5o7PSA1GjNxbcEP4qQndwRkkQ2u3LpsyuL/46wy4dQJmWPMBwLwl6dARAxyMiXcRNZl9QNAb6pcjZlQ4sldP2ACorDiZpVY8/qdfMJrpxUbEJ2tKOH6f98R9xC86FEh5/kPNcOAzYbHkn7fHsUKxdF1J/sUk8lCFArOzEyYP7kvtRlvA4GqJj50ePm0mvvS67xVNzoj3PAjEcP4N0Tc61MQY8iY+iiuSRLFHEA==
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)(86362001)(83380400001)(64756008)(6506007)(66556008)(186003)(66446008)(66476007)(66574015)(15650500001)(4326008)(76116006)(66946007)(2906002)(71200400001)(33656002)(53546011)(508600001)(9686003)(8676002)(110136005)(55016002)(122000001)(316002)(38070700005)(8936002)(38100700002)(5660300002)(52536014)(7696005); DIR:OUT; SFP:1102
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: vZk9xYxIz8PZLhNqCJrtEnd67mTfCgF9ml2vj8oBNJ9AqkD/inPTWx4UUy2HmqCZDkif7fQ6/ASP7jAD4A3a3huqsTUbza1b4pmxi0I3rorhyIB6VK5MeV544W1XEqMiK6xCi8T8PNbqREIiuaUajD8utb6lDrP7B0hFGrQ58hmRW9+R25OSic91vaCPO0EeJrtVkvuHBQ3PM019DQdw5at021ZS48ksBMRZbAW+zL9OFIi1VmE3JwcrGKrVtsX4IE+jw92dv+K4cKq17YmqgwqTb+JEvqgY2DK7kIBxumO4eI00yjvklkOAvgtLzgnUs6ZWkAU2+jdAOwln9OLAb9nzSQB3DlMTNQqPJMhf6IWcJKWZl0CQINOoWIBko/MhSSOp4rFRP7thTrGInSDXemp9zxmIY5P/kJyh2LjzHI1MCYlSTmQ5rFifmBTsL52BsLFOEv7CSLLiRKg+kPOSVKi9QlUdIWqjBr0zIQsVgFOiw71K+/0UHA/duneYHLUEZXCqf9pbReX2osCz1AsEbqj9+XrIbI1wwPHsO0HhefVUY9aClQ6DR+tJsNRuOHFWtEv/YfQIRx8Sl/I8gEyAb0rIUYv8P1BzBGlGcy6B8+dqY8tNyPCG9N0myQp3aH5GxmqwZBD77mElGQsVPWgOh9n/2wmpWHV0q8Bb1FRbBHA+z5E3YDWvWTKcywRl6rOVn6DdZdUKoR6P8H82RQfj30sRrY5W6FKCgYED9ZR6zjNQUxRL+E5WoPzjtN+T0KC9HXKzGf+hu9P1V3JDQyI3YJSg06iOyqLz/e3cQUkbdebakEDHJAv2VbkkJnghCTYLAjPn4yBWI56a00jzXU1MsIbnVUNkgkyoCQEsjzfeTauwznErT1FFF7++cBvjAtE+ShOQiE9Omw6RS5xInYkWtvAPJv7O8V35xREQ4n5kPOIw5Q9GlBi3woOob7ORYomwHf/ESVcD8S93gCod+ip5EMfPv1ticHSb3qmkY+plIZ2ik4avjkVE8Ia5X8zQaJxt78tFQbutVFizVM407cA/fiafBZEHXfJtBZMpHUj48fFjGYVX6UWsW2oG02qfHF5elDYGkcsOvy0das/qnP1BvbBEzBjIr6cZZ91yosjrAPmoVsJe8g17QR2AvKPc8oXzidw0rrW5FAtDWeToiMt28YlIf2G5J37Hg96bkI0URVkANBz38+k2TovRu1OfGLdD9xsMQTeLqYh59fwvU86EJ+bKyvHZ88djpL/NSJeVwyzc2JSofF3Ohb4zmdxdBLF5sO2Opl8NsRPvT8Kz45fVETtgiv6NpJkjIT8COpJ9DdM4i46lAhcMDmZqrpusWrlhXWFR6SO3TNf6PmhLZHhbDBwxoOykZJ9K2PRmd2CU2+W2lMIP71f/tQ2FhTBrblnIGtMKpUY+6AR/fj8pi3jPCxP2ytoXtDciDAt1TOyJsjrs3NG18Mlvj/bIuGaAbxGu2M3zv2jWj9tv9IHw+P7u9CvefsxVp+MeHIM2VueGmT7Zi9xICzWGfezWZirRG7bM852HwBcu1jQ2gIAlOE62f3HTtXIf+lx0P/XDiGzOGasR1dOI5oaxKhhVfxFuhO8Qr44CCM9dSP8q3ZbUYVtjBgY992B7B7Pp5UTy9T0R2Hu6kl2VuNgMhpW3UHBrXc3EE1oitSmWHCM0XEZuV3DO980flELZo1DU3xAJr2kHF26Mi9GithJdVUum9Ejb7NwN
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: cbb6c6ef-b692-4f2b-a376-08d997978cba
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 09:12:20.5926 (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: 1WoLrKBCFqf5o0YzHkN5DIpQ1SY5GEcaIeAMuXWfFuPHQ6aaoK84nsQ6oHKL71rD5tgh/StbdJDRUopaRXXov/HISk/VLi53lN6XqACDYEk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8070
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-US
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rKYsq1CZrSk0HwEb7XTfyAQrY-w>
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 09:12:31 -0000
Ole, My problem here is that "limited domain" has become a vague and obscure term used to justify the violation of pretty much anything. Furthermore - I would argue that in the case of srv6 - the concept of domain boundary has become so obscure and so vague as to be meaningless. When limited domain used to have limited edge devices connecting to other networks - you could kinda get away with this - when your limited domain is now extended into a hybrid server/network world - and your domain edge is so vague and fuzzy as to encompass pretty much every port on the network - then the concept of limited domain is, in my view as an operator, meaningless. I actually think it would be interesting to potentially form another working group in the IETF - to specifically look at the operational impact of ideas being proposed but on a "localized" basis - so while GROW is chartered to look at the impact of things on the wider internet - perhaps we need to start thinking about something that can analyze the impact of proposals from the perspective of a "limited domain" - inside that domain - and perhaps this could also be the place where we define what a "limited domain" really means - and what the boundaries of this really mean. Might be something worth considering... Andrew -----Original Message----- From: v6ops <v6ops-bounces@ietf.org> On Behalf Of otroan@employees.org Sent: Monday, October 25, 2021 12:05 PM To: Warren Kumari <warren@kumari.net> Cc: v6ops@ietf.org Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts? Warren, > The way I see this playing out is operators quickly moving along the lines of: > If I'm expected to filter "RH type 4 (SRH)" on all of my external interfaces in case someone else decides to run SRH, what else should I filter? Clearly 5 and 6 (CRH-16/32)... and 7, 8, ... 255. > I need to be ready *before* you enable $insert_new_protocol_here, so the only sensible thing for me to do is filter all RH/43. Oh, and I don't know what sort of new uses there might be for Hop-by-Hop that might affect me, so I should clearly just filter all protocol 0 (perhaps in the future I might allow specific ones... maybe). HIP? I don't use that, but I might in the future, and I certainly don't have time to follow all of the new things being proposed in the IETF/by vendors, so obviously I should filter that everywhere... > Actually, why am I bothering to write this long filter list? I'll just allow TCP and UDP, and call it done... > > (When I started writing the above I thought I would need to add a "Warning: Hyperbole ahead" marker -- but I'm no longer sure that that's the case). Proposal for a principle: "If Internet traffic is carried across a limited domain, the technology used in the limited domain must not hinder end to end transparency." You are welcome to suggest more concise ways of saying that. In the above example, filtering packets with the SRH RH type _and_ destined towards your own limited domain prefix would adhere to that. Cheers, Ole
- [v6ops] Security issues in RFC8754 and related/su… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Vasilenko Eduard
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Vasilenko Eduard
- Re: [v6ops] Security issues in RFC8754 and relate… Ron Bonica
- Re: [v6ops] Security issues in RFC8754 and relate… Alexandre Petrescu
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Gert Doering
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Gert Doering
- Re: [v6ops] Security issues in RFC8754 and relate… Warren Kumari
- Re: [v6ops] Security issues in RFC8754 and relate… Eric Vyncke (evyncke)
- Re: [v6ops] Security issues in RFC8754 and relate… Gert Doering
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… otroan
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Brian Carpenter
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Eric Vyncke (evyncke)
- Re: [v6ops] Security issues in RFC8754 and relate… Warren Kumari
- Re: [v6ops] Security issues in RFC8754 and relate… Gert Doering
- Re: [v6ops] Security issues in RFC8754 and relate… Brian E Carpenter
- Re: [v6ops] Security issues in RFC8754 and relate… Brian E Carpenter
- Re: [v6ops] Security issues in RFC8754 and relate… Gert Doering
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Brian E Carpenter
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Warren Kumari
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Warren Kumari
- Re: [v6ops] Security issues in RFC8754 and relate… Warren Kumari
- Re: [v6ops] Security issues in RFC8754 and relate… Andrew Alston
- Re: [v6ops] Security issues in RFC8754 and relate… Mark Smith
- Re: [v6ops] Security issues in RFC8754 and relate… Gert Doering
- Re: [v6ops] Security issues in RFC8754 and relate… otroan