[Idr] Is there any issue of using the ID of a pre-established IPsec SA in the BGP UDPATE for SDWAN Edge nodes instead of detailed IPsec SA attributes ?

Linda Dunbar <linda.dunbar@futurewei.com> Thu, 25 February 2021 03:56 UTC

Return-Path: <linda.dunbar@futurewei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B010B3A0EF3; Wed, 24 Feb 2021 19:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 SO8cvvyUzgj8; Wed, 24 Feb 2021 19:56:26 -0800 (PST)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2100.outbound.protection.outlook.com [40.107.220.100]) (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 C33A63A0EF1; Wed, 24 Feb 2021 19:56:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IfFuYobE4l/yA9ebZAjAVtY8X2v3rPcBbIua1cz6eBReV1v9NKEiohNYvjyuZNtdNYpI0JKSRjUfe5bJXnAI+357el3+58JYix2iMXgQ015lnNRA7UhznCrLyKGhPa3u0hbXbROpXr//03gJuOlyjyLxB0Y/hC/oZuwr/6L3vxPiEj/AY0Rs1thnFbj6P6m/FQNH3Hzn27iR6WNkW4r22COcDI4R8fCxD+GetOSCKU27QqByaZc+/ePc9jeOGyddXukCmctRmH5aBeA+pf/V0SMzbwi6v8uvc/dA3xOH9B9cb7UjX0eOCkqNFcBsDaBYtEUosvGq1+54G+wDxBOimA==
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=amqUPogjFzid5VrT2bkgi2OH+FKF42Ub+sNlc4zLjBo=; b=TVPxaVfeCV6IxvgTR96HFdeGgmI2/23NAXt2tNk5vTdLsaNJ/4Rb4+zIyNSCgDVYq4mPzpOb2HNCH9tZQtDGbcD8rKDGHrdkr01y08AsMf+D/bhDqCEuL5MnDTmLRTKg/btcMFBDZbDd11sMPrBz5DLB1GLbqkiE9UQgSTTy3vIjN7uxpE9m2cZ8SILAM0Dcc+6ldHvrAahq8Aa5763QcF3IlR9/M9XPyzHiW0XlIWDePKfWpd4kOCbSwnYVkzGhLbFC7ElyGJtf6qzj0EgOWJzcPLNalo9Pqr0FWfckPCEEntP8kudgOB3YvhjyadnVoP+f4vE647C2KanufRZsng==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=amqUPogjFzid5VrT2bkgi2OH+FKF42Ub+sNlc4zLjBo=; b=d5pvuUYY6GDcYkDejyLXwcubJ6R8QSd+oQwHdYLFA0dwWHcjswluPu87LRiUHpUEeeIOozSFT1zcjWpokimXQVVqMwH2NRmhYlrNAslIZtMibLN+4DJbE6I6Z0OmSscDqLD7qe59hxp5vAblNtOMQ55xmRDx7tB/JBkJsPpOQAc=
Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SA0PR13MB3917.namprd13.prod.outlook.com (2603:10b6:806:99::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.16; Thu, 25 Feb 2021 03:56:19 +0000
Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a%6]) with mapi id 15.20.3868.017; Thu, 25 Feb 2021 03:56:19 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: "idr@ietf.org" <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>
CC: "draft-dunbar-idr-sdwan-edge-discovery@ietf.org" <draft-dunbar-idr-sdwan-edge-discovery@ietf.org>
Thread-Topic: Is there any issue of using the ID of a pre-established IPsec SA in the BGP UDPATE for SDWAN Edge nodes instead of detailed IPsec SA attributes ?
Thread-Index: AdcLKe32YbSZyAnnSLKj+NShgcqqTA==
Date: Thu, 25 Feb 2021 03:56:19 +0000
Message-ID: <SN6PR13MB23343CEBC2A518970FB1FEAB859E9@SN6PR13MB2334.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [72.180.73.64]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7dd8642c-c6fd-43b4-0a2d-08d8d9414f2d
x-ms-traffictypediagnostic: SA0PR13MB3917:
x-microsoft-antispam-prvs: <SA0PR13MB39170ADA5E765D66699D48DA859E9@SA0PR13MB3917.namprd13.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: er5JCzR+bQzOZIFYFMmvpG6OLfsQBR06fyzaSinPxV62LhSb1wEfsXF8NScHczGEToAeHK4fLbanTO+gfO36lhCtR5ldzP981I89waOvW6lx9oiWwceioVt+gHFtakh75cKzHPQEy7/xM8Ulh5S9QEOkN3PQDb7tCvzjpnr9HB40adAih2I4AHz7vY4pgGZew3gnkecn/ZXsbBKMTibCrBLQJK4AFiLJI/cg3mx9mtZp9Deo4MJB/aEpMfXUWUMzBQIWAAKQSXiSNY2RWrkDq/xv/rWYGNX/Hex41XZnqVTxBKamQbjzUhpxh9GPC9IH5kaYiyOX0xdfSosrpjgXddXnhyNwHt+X8uzoL/0s6FUyG0JSo5FeumtV3q8PVcjYNe7RWbagDX5r4MT0YSKid1MJGgtqMIa0Lh0i61yrWCJSe3uk/0FOs/xYoJbKhpv6H9qDlUsD33PTrfq8TLmNiSpfrHbOhkegkTbEIgAdTZEbGBne/4bD7JLpmJy3vnCYzl68FHCgp/Fp4TgqZmwp2RcKT7yMTeYHqrJt8+5qkhYWscWEYTLCvE3uVAthuihfQMLMfRTjE9Fiv3jS43E/Pr49eGadmA50Vc1KRNm5Ojo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(136003)(39850400004)(366004)(83380400001)(33656002)(71200400001)(5660300002)(110136005)(7696005)(6506007)(66446008)(64756008)(316002)(166002)(76116006)(66946007)(66476007)(52536014)(66556008)(86362001)(26005)(186003)(4326008)(966005)(478600001)(8936002)(2906002)(55016002)(450100002)(44832011)(8676002)(9686003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?dLf0XWFdtge1/L3vwjLL/0eMSboE//RaHihiFXsMUqTa8eWcqFQ+o0ocsZ/9?= =?us-ascii?Q?BXwO2bywffv1k0he+EwV5TY53Bl4navyrcGaShuXJxPF7wJm2Nf9NJF+D7S8?= =?us-ascii?Q?BK3n+ApBYkyjZNYc2fxTzXQvJAl81V/mRZDArMWYBBTnv8R9sOAEhgmxHYnX?= =?us-ascii?Q?gPw4RIliPWm36f1wfIrzJwSFkx/S3e81MB7T6TKlSbrVdCkSwthUzX9WEVlw?= =?us-ascii?Q?gdqkWAhInzUZ65+YNqORj3Wy8O1OgZoDMto02UfiIMW5zoertkUuCJ3bRZM8?= =?us-ascii?Q?XkyHiOzgqlZOBI4zaUknAVZ/V80TmAKNjomvXa8SJA+cZADZ1E0D7Ab46dKg?= =?us-ascii?Q?MOD7cFVDtmssVcrZnp9f9hFJtXUkG9ogeqsaj5D9gTE6srh8CiUnVPEA2NWF?= =?us-ascii?Q?fhXrRvJit5mD97kMFO9qkcCkbOYjFZqvv1tznKhHhJH03gVZ7G25++MidvZk?= =?us-ascii?Q?EiavXGP3zavmmFvzHb5rAKCauK5NnwWWN4VYvRuMMxdAvH6vycTyLOcZcqZ5?= =?us-ascii?Q?ztzIIUUDsdFuiciOh+v7JQNCqY5c1W4JmwcAytCYkps0zdHdQLs8f2vtdhQ3?= =?us-ascii?Q?dgE4Jnym1KxdOn+b6gw+/S7iPQTiqb2hvWOLMVrrMzAiTv/p4Oru9mxu/eKt?= =?us-ascii?Q?bynTip4y7PN2/uhrXafeEO27cJ5SHwEiDwEvqbaf5te/TRBMy2ydT6cMWe/H?= =?us-ascii?Q?LU++rKvVFB59POXSYzZO/5Ks3eB7yly2e0cpkswkqG2JzFZBwzAnzIVteyHF?= =?us-ascii?Q?rYGq4sU4q1RnxtiphEJUF/rEkKLQEZBObZwiK7BPPdAkckVdjhayqOz5rqB4?= =?us-ascii?Q?lwR/X+525LwtbDmEj4+HxDOMKE8sbifmSbLQpLu2PZUWK0grY2ta7D3o5xeN?= =?us-ascii?Q?DVvRfY0s0nXBZZ8pWBLC/S/x0QHYo+j6IffOWsqd2Swaw0apgtl+QKj7e63e?= =?us-ascii?Q?rlzNI42KIDLRNknZ/JA2NLtwyVY6TWjWT2OgG6dZuHLTNA1RarbBpfA33cGo?= =?us-ascii?Q?WQigdn2FLJi71lAWHTYb4ghe3VjR9tll6O+MuysJHPZeTJssyFVphVTyazjR?= =?us-ascii?Q?A0opgoCksS/FdOj8svVbrDLpbtoYMSfkO8tEPIOQSkKc7zQJUCGiD918O5Z7?= =?us-ascii?Q?nQosqv1KtJLhCMd/EjaEPAGQWHr6OY+Iz/lCqZQdPIdND3qlI+AjVBaR0gQi?= =?us-ascii?Q?xDmNBCTVy7yf9P3k95FlaQk2O5mJabZT/iCFCWciJ+96b25IyPUGYE/ShaNd?= =?us-ascii?Q?hGrRB5rs+X66JXvn0RsgJ/qy44MR0/lRpFJX7k5w1RvY0xunrm10BxadLTPE?= =?us-ascii?Q?OHE=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SN6PR13MB23343CEBC2A518970FB1FEAB859E9SN6PR13MB2334namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2334.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7dd8642c-c6fd-43b4-0a2d-08d8d9414f2d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2021 03:56:19.6589 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0Deg1c7RwRO/iE3TTbt8nF33cGpsdCRGSHOrWQki8ijtdduKg4+9a7bvyf+9vTkMgp0P9YmrxhNPjwNI65YreA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR13MB3917
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9FdDTMFQFSMwh1m_rP2MHkL-Eyc>
Subject: [Idr] Is there any issue of using the ID of a pre-established IPsec SA in the BGP UDPATE for SDWAN Edge nodes instead of detailed IPsec SA attributes ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2021 03:56:28 -0000

IDR experts:

https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-edge-discovery/ proposes using two separate BGP UPDATE messages for SDWAN Edge Discovery:


  *   UPDATE U1 for advertising the attached client routes,
This UPDATE is exactly the same as the BGP edge client route UDPDATE. It  uses the Encapsulation Extended Community and the Color Extended Community to link with the Underlay Tunnels UPDATE Message.


  *   UPDATE U2 advertises the properties of the various tunnels, including IPsec, terminated at the edge node.

Since there are many parameters associated with an IPsec SA, IPsec SA identifiers are used in the Tunnel Encap Path Attribute, instead  of listing all the detailed attributes of the IPsec SA.

The following is the structure of the IPsec-SA-ID sub-TLV:
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type= IPsec-SA-ID subTLV      |  Length (2 Octets)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      IPsec SA Identifier #1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      IPsec SA Identifier #2                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If the client traffic needs to be encapsulated in a specific type within the IPsec ESP Tunnel, such as GRE or VxLAN, etc., the corresponding Tunnel-Encap Sub-TLV needs to be prepend right before the IPsec-SA-ID Sub-TLV.

Using IPsec-SA-ID Sub-TLV not only greatly reduces the size of BGP UPDATE messages, but also allows the pairwise IPsec rekeying process to be performed independently.

Do people see any issues of this proposed encoding?

Thank you very much.
Linda Dunbar