Re: [spring] Secdir last call review of draft-ietf-spring-srv6-network-programming-17

"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com> Tue, 01 September 2020 15:38 UTC

Return-Path: <pcamaril@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA9D3A0B92; Tue, 1 Sep 2020 08:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SZUnxY8U; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nAngNxZu
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 ePqTm4ZGtz5G; Tue, 1 Sep 2020 08:38:05 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A78C3A0B93; Tue, 1 Sep 2020 08:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7324; q=dns/txt; s=iport; t=1598974685; x=1600184285; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VoRwsZwQ3bqvoGIr3Cu45WJ+sGIdDd1TWwT2Uhkr9E8=; b=SZUnxY8UnU/kesANfZ0K61rcTit612dFYB3lvoEAKG0Qpins4rH8jNnj MveSte1pcQ67FooOGPvCkNNPzS1DcoCc4L0Ms+PydAti8qXC2yA4DIk3S NwVtjrQWBNc1aR8VnsLDvYWmkPerqs/a0w4KBdgsqic5OwIHqTAsap7PU g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AZxge6x0l0lHm+hQXsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGuadiiVbIWcPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoPk1cGcK4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAABeE05f/5NdJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTgFAQELAYFRIy4HgUgvLAqELoNGA411mHGBLoElA1ULAQE?= =?us-ascii?q?BDAEBLQIEAQGETAIXggwCJDYHDgIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQE?= =?us-ascii?q?DEhERDAEBNwELBAIBCA4DAQMBAQMCJgICAjAVAgYIAgQBDQUIGoVQAy4BpGY?= =?us-ascii?q?CgTmIYXaBMoMBAQEFhUsYghAJgQ4qAYJwg2WGTxuBQT+BVIIYNT6DdUoFM4J?= =?us-ascii?q?dM4Iti0iEEh8KgxiiS4EICoJllEVthSGDCYlvk16SUZ9XAgQCBAUCDgEBBYF?= =?us-ascii?q?bDCeBV3AVGiGCaVAXAg2OHwwXg06KVnQ3AgYBCQEBAwl8jUmBJAEwYAEB?=
X-IronPort-AV: E=Sophos;i="5.76,379,1592870400"; d="scan'208";a="810177629"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Sep 2020 15:38:04 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 081Fc1M6021890 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2020 15:38:02 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Sep 2020 10:38:01 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Sep 2020 10:38:00 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 1 Sep 2020 11:37:58 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IUM8y0jbgFGB647QhmihiImiX3uejSKMV4f8xO9VvNy5WSgXcc9YFXcxZuFEOGqg9d2RF/YHBWr1+RaDaxi+IIYW1qmXZtmAVk++3Px7CX1VvFUpPzxrI0llIWB4wOtaJNwR4oxiM5RfdPOQBk419D+si2NFDID2EYQFsI/t8NRx8DqSx8HmgWC0+FPew44O8uZYD9PE+BlSOQysEKR4mwjSgWkpoSvhe2gAmu91w90kqAcotLRuczqwXQeR6aVhIpnFnAxggaTCK5KBjNMtBS9chWZl6Iqo92Y9Eb+IsY5qP7ok/1+XwbpHP2Z1aJgJNDJulp8ksrSr77S5K35PDw==
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-SenderADCheck; bh=VoRwsZwQ3bqvoGIr3Cu45WJ+sGIdDd1TWwT2Uhkr9E8=; b=OrIDMss577QEtrWVkaFbi6QXJatot18WfGxVUPI08JVy3ZWHKyDwlgRKaBqUNNyMWiyrQZ2ggoyWzcJqpgYH0zaK8/leZwuaJCM8jD8XzpHL+H5cbJlGWP0nybDEZj1+DPVI/3vr0TepArxW/4caAD2enuM5eIG72Qkerf3lbzjgmYEAfGlGcj8XNdw3RvaTLgrk92GdhkNdFZN56iAVe1rg5nDYgqFtcWIjQmHL7IqKZKqjdiyFsafMqPBDBGXE8DAvCWoX58J0apSIxubtoSx4f0iBg1UAHofuHQi81dPr4TqK9BRj4en44IKKjJBj9hxSlmYJy5oBREXXK/ineQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VoRwsZwQ3bqvoGIr3Cu45WJ+sGIdDd1TWwT2Uhkr9E8=; b=nAngNxZuBEnlOm+pFot79b0cNXVVOusELcTR0ZdoEgyvhd/l6y2E1GRs1nfb/dYrV64RCbzMiZQiCmfYw6YYtIhGkiPHjSQQW+c3s3f4JusMSOGTBrFUzHTTLAKTc3kwu22ToR1keSNVF4rtKcuLayAzzt4dipCNptNLQ2JCe48=
Received: from MWHPR11MB1374.namprd11.prod.outlook.com (2603:10b6:300:24::8) by MWHPR1101MB2191.namprd11.prod.outlook.com (2603:10b6:301:5a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.23; Tue, 1 Sep 2020 15:37:57 +0000
Received: from MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::c0dd:2d6e:c8ef:261e]) by MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::c0dd:2d6e:c8ef:261e%12]) with mapi id 15.20.3326.025; Tue, 1 Sep 2020 15:37:57 +0000
From: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
To: Brian Weis <bew.stds@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-spring-srv6-network-programming.all@ietf.org" <draft-ietf-spring-srv6-network-programming.all@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-spring-srv6-network-programming-17
Thread-Index: AQHWfCAs7si/IaQjAUGLemDRAKxyiKlTzVOQ
Date: Tue, 1 Sep 2020 15:37:56 +0000
Message-ID: <MWHPR11MB1374FC1CD4ED7439FB5ABFB3C92E0@MWHPR11MB1374.namprd11.prod.outlook.com>
References: <159849805983.7699.460089427690333419@ietfa.amsl.com>
In-Reply-To: <159849805983.7699.460089427690333419@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.56]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f0d2aff1-1c07-45a6-6f8c-08d84e8d001d
x-ms-traffictypediagnostic: MWHPR1101MB2191:
x-microsoft-antispam-prvs: <MWHPR1101MB21914DA1FB99852B5AB6B8C8C92E0@MWHPR1101MB2191.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ixeYgFTpyBUIqHY5r6jfR+GMR7rYYR16qEU6rv9D2fvRY1+vqSW19azitLMb0UrpWwZTGj1k825J50P14K8tzzk1ycV+yiOSV48tUWiBpBtHVdoYyNHG6iv6OqbSLFyYjRDL6a5vPq94X4JUZHT0olPRKKh+4163strg9PQbr7+mu6aTvtsrrYjwqWQrzQ1imevBYemwMlNYQHK74jjS6pqZNcwBHmwoxwi+j9lS3I++xOJiUpTbrTq/zQUJSGsfww6PfnH0Oh8OUw5GAZv5bX0UY5B7uAo0GU7Kipd/oRU7FJIo/vQYBquV3cGpRDm7PhFLLiLt+5ouylaifJaA4g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1374.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(39860400002)(366004)(396003)(376002)(7696005)(8676002)(186003)(52536014)(76116006)(4326008)(66946007)(71200400001)(64756008)(66446008)(66556008)(66476007)(26005)(33656002)(2906002)(53546011)(5660300002)(6506007)(8936002)(83380400001)(54906003)(316002)(478600001)(86362001)(66574015)(9686003)(55016002)(110136005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: khPy9l5Ei3g2wRihJ/e3U9eOohpKjTp5wjlPZKjsFIpcCFw6uxZljyDYMZNYGzOjhGHDbrvNIb6+Xrp674qxh1WqECBgy0fV6jQ/DjYhg6OdkB/Y+7WbsrFTTqUP+XOhsWzmw36mQpOTpQ/8zxMEXNQCDwf9YwnP4F3DSDgs432ZkSGgXoplLHDocGSfgvSywqpLBpWuZCWZRbSozX5BUbbBMxmbiTmILhTe21svFo2+9u5gWT5jEKrlQcodiYdF9RfgIwQAGt94Kt9RbetEY8+Q2BOQ/H8DpIAe1HfuhGDl8kZxQSvscpWzeoDWHWz0XyLl7opI98bs2BgGL7NOEY41fvPj7NjDW5t8yc4kCaJrAR+DCsM7koeQ1aS3DNZTwcgAfI/D7JDZt7Z+EOH/gcdkw19oPXgZ8LlFaaEEWAZP3y/6+x/TGIwOfHYIo20hXlW8qNqB7I/U1VeMoX3TA23hgwd6hDZbY7e16KvTIeVKYffCIbszqX8jfcwV5NzKZ8/IItchjzWlBrn+pj592XnJitVg01lMDH7ysNUxUcaTs7zvmuBlprmsmz6ZiOXRRb3yBQ2fdbrCSLxx/eaKWGUjL+OIQkQDdU9n5+vX4aZkJwJak1tvPFMFImxUrnxxsxNY1njqZyImCdhC0NObHA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1374.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f0d2aff1-1c07-45a6-6f8c-08d84e8d001d
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 15:37:57.0010 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: n7nMvbrA5lqqVAJilj0YMx24J+rM7s/QUvC3l8+xkKDbXr66ZNemwEoPJUjRuC8VZ1rXInKiZiiW+s7QqR6UwA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2191
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/mgkn8sOzfZM4tGRKoRomH1cSo2o>
Subject: Re: [spring] Secdir last call review of draft-ietf-spring-srv6-network-programming-17
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2020 15:38:08 -0000

Hi Brian,

Many thanks for the time you took to do a thorough review, please see inline below with [PC].

Cheers,
Pablo.

-----Original Message-----
From: Brian Weis via Datatracker <noreply@ietf.org> 
Sent: jueves, 27 de agosto de 2020 5:14
To: secdir@ietf.org
Cc: draft-ietf-spring-srv6-network-programming.all@ietf.org; spring@ietf.org; last-call@ietf.org
Subject: Secdir last call review of draft-ietf-spring-srv6-network-programming-17

Reviewer: Brian Weis
Review result: Has Nits

This document is titled “SRv6 Network Programming”, which is attention grabbing. It fleshes out how Segment Routing routes IPv6 packets by Segment ID (SID), as well as defining the format of a SID for IPv6. The Introduction states, “An ingress node steers a packet through an ordered list of instructions, called segments.” When one considers this statement along with the document title, it’s apparent that network devices are indeed being given “instructions” in the programming sense, where each “instruction” is encoded in an IPv6 address.

An “instruction” (i.e., SRv6 SID) comprises a locator (which is used to route to a particular network device), and also directs the network device acting as the locator how to process the IPv6 packet. With the help of an IPv6 Segment Routing Header (SRH) header, a series of “instructions” can source route a packet through the network, where each network device acting as a locator learns how to handle the packet before possibly sending it on to the next SID (if any).

The encoding of an IPv6 address as an SRv6 SID includes a locator, a code indicating a certain function, and optionally arguments to that function. An initial set of codes (and their associated algorithms) is defined in this document. Most of the codes describe how the egress router should decapsulate the packet, with might include defining  which routing table the receiving router should look up after decapsulation.

The Security Considerations section points to the Security Considerations of the architecture document and the SRH document. Both documents focus on the fact that SRv6 is intended to be used within a single domain (e.g., provider
network) and discuss routing mitigations such as filtering external traffic appropriately. They seem to assume that the boundaries of the domain itself are inviolate such that the domain boundary devices are not subverted, and that there are no bad actors within the domain. These are common assumptions for service provider networks where Segment Routing is intended to be deployed.

However, it cannot be certain that all networks deploying Service Routing to be free of bad actors, and there will certainly be some benefit to a bad actor changing “instructions” encoded in IPv6 addresses. Perhaps there is opportunity for mischief in changing the routing table argument in an End.DT46, for example. Also, as other SRv6 functions are defined (e.g., packet inspection functions), it would be important to ensure that those SIDs are not modified to avoid or decrease the quality of those inspection functions.

[PC] Indeed, the assumption that a domain is free of bad actors is a common assumption for networks where SRv6 is intended to be deployed. The security section of RFC8754 does talk about these bad actor attacks (7.1) on such networks, and other types of attacks they can launch.

The SRH document does describe an HMAC TLV that is intended to mitigate these kinds of attacks. Since neither of the referenced documents Security Considerations mention it, it would be a good idea to describe here that there are threats to changing SIDs, and point out how to mitigate them with the HMAC TLV.

[PC] The HMAC TLV allows a segment endpoint node to "verify that the SRH applied to a packet was selected by an authorized party and to ensure that the segment list is not modified after generation."  We could call this out specifically in the security section.
<OLD>
Together, they describe the required security mechanisms
   that allow establishment of an SR domain of trust to operate
   SRv6-based services for internal traffic while preventing any
   external traffic from accessing or exploiting the SRv6-based
   services.  
</OLD>
<NEW>
Together, they describe the required security mechanisms
   that allow establishment of an SR domain of trust to operate
   SRv6-based services for internal traffic while preventing any
   external traffic from accessing or exploiting the SRv6-based
   services. Additionally, RFC8754 defines an HMAC TLV permitting nodes in the SR domain to verify that the SRH applied to a packet was selected by an authorized party and to ensure that the segment list is not modified after generation, providing further protection against bad actors within the SR domain.
</NEW>

Also, if I’m not mistaken, when there is just one SID then it is placed in the
IPv6 DA and there is no SRH header or HMAC TLV. 

[PC] The SRH MAY be included when there is just one SID if flags or TLVs are required (RFC8754 section 4.1 paragraph 1) so the HMAC TLV may be used in this case.

This is a general problem with ensuring that the DA on packets are not changed in transit, and one could use IPsec to mitigate that issue. It’s probably worthwhile mentioning something like that.