Re: [MMUSIC] Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance
"Kyzer Davis (kydavis)" <kydavis@cisco.com> Wed, 06 December 2023 21:04 UTC
Return-Path: <kydavis@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E93AC14F685 for <mmusic@ietfa.amsl.com>; Wed, 6 Dec 2023 13:04:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.605
X-Spam-Level:
X-Spam-Status: No, score=-9.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6H3o44Shbf7 for <mmusic@ietfa.amsl.com>; Wed, 6 Dec 2023 13:04:44 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (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 5813AC09C222 for <mmusic@ietf.org>; Wed, 6 Dec 2023 13:03:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18128; q=dns/txt; s=iport; t=1701896603; x=1703106203; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=trfCHcXPn6rnPtvJH2PhDIacdx5/z9fx5QQ12HY+W+c=; b=Q4WagWKc3JRnZj4JCPmP6BoUbUc781qDl0hXlaQPZ4PQiUSiFHB0aMO/ 19sB/X2TuxkEXKaKhTtD8AzJam7bIP0ZsD4FmQVyymJjp4PhNjoE4TBSq oceV+iFAmERsGwsN3zWbgGQAk7a7GM88ENSSe7dvZIzg+lpvReBGI/FJN g=;
X-CSE-ConnectionGUID: Np/BZA3YRAigkB1EvrDcvg==
X-CSE-MsgGUID: Bnd/4y6sSl2jScauJLIxsA==
X-Files: smime.p7s : 5465
X-IPAS-Result: A0ABAADI4HBlmJJdJa1aGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFlgRYEAQEBAQELAYFmUnkCKy48SAOET4NMA4ROX4hmA51+FIERA1YIBwEBAQoDAQE0EAQBAYUGAocpAiY0CQ4BAgQBAQEBAwIDAQEBAQEBAQIBAQUBAQECAQcEFAEBAQEBAQEBHhkFDhAnhWgNhkUBAQEBAgESEVYFBwQCAQYCEQMBAQEWEgMCAgIwFAkIAgQBDQUIBg0Hgl4BghYlEhEDARAGknuPTgGBQAKKKHqBMoEBghUFgTwCAg4DDy+wWgoGgUgBgVaGHRoBaGiCZ4EJgy+BHycbgUlEgRVCgjcxPoI/IgEBAQEBF38SARIBBxwVCR+DHDmCLwSGCoMNBzKCIYNSgRKBeG6BaQGGBoRPfkdwGwMHA38PKwcELRsHBgkULSMGUQQoIQkTEj4EgV2BUgqBAj8PDhGCPSs2NhlIglsVQARGdRAqBBQXgREEagUWEx43ERIXDQMIdB0CMjwDBQMEMwoSDQshBRRCA0UGSQsDAhoFAwMEgTMFDR4CEBoGDCcDAxJJAhAUAzsDAwYDCzEDMFVEDE8Dax82CTwPDB8CGx4NJyMCLEIDEQUSAhYDJBYENhEJCygDLwY7AhMMBgYJXiYWCQQnAwgEA18DCgNEHUADC2gFDgItNQYOGwUEZFkFoDk7eYFBARAVTCs9DQsXFA4CIAIHPRUdLRoKFAcjBQYBBwEtEoV3jD4Qg2qLUqEwgTgKhA+GT4MpggqVQBeEAZ5ahkdkmEIggjCLGJUohR8CBAIEBQIOAQEGgWM6IgscInBwFRqDCBM/GQ+OLA0JFoIigR6FFIpldgIBBQUuAgcBCgEBAwmKYQEB
IronPort-PHdr: A9a23:Yugk9BUNELIOJM4tKT22RMZ3DpLV8K0xAWYlg6HPw5pHdqClupP6M 1OavLNmjUTCWsPQ7PcXw+bVsqW1QWUb+t7Bq3ENdpVQSgUIwdsbhQ0uAcOJSAX7IffmYjZ8H ZFqX15+9Hb9Ok9QS47lf1OHmnSp9nYJHwnncw98J+D7AInX2sem2+ms+ob7aARTjz37arR3f 126qAzLvZwOiJB5YuYpnwLUq2FBffhXw24gKVOIyhD74MrxtJI2+CVLsPVn/MlFOZg=
IronPort-Data: A9a23:4Fdu/6yumqlmhGiWBrJ6t+e3xirEfRIJ4+MujC+fZmQN5Upzl3Vbl zFOHTDZZODKOTG2fMQ1MdropA5D+8PleuQTC1818HwrVy1RwSauLY2XIxmrNX6ccZySRks44 clFNNPJfZhsEnLR/0v0Pra79CJwifHXGOTwAeKdYn4hHl45QitxhE9txrJh3IA034fR729h1 z/Xi5W31AiNhmIqbwr4kp6+lS6DnMgemRsS51Jvb/lC7Q6PxiVIAplDffnhcXXyToINF7+zS bmSlJi0rzjTl/sP5nxJsVpanmkiGOO60d2m0yIOM0SaqkEf4HR0iuBibKZ0hX5/012hh8p2x MhGqau+QAIoOryksOkGWnG0KQkmVUF90OGBeSTXXfC7lRWcKCK2m6s2VynaAKVBkgpJKTAWn RAnAGhlgiCr34qe3L+9Q+9wscUvROGD0FQ34ywIIZnxVJ7KcLibK0n4zYYwMAQY2qiiKc3ji /8xMlKDWvhvjypnYT/7ALpm9Auha+KWnzdw8Dp5roJvi4TfIZAYPLXFaLLoltK2qcp9uF7fj FDvpFXDKxAVN/bG5CSf3nmyibqa9c/7cNp6+LyQ7PVmhhiYwXYeTUROE1C6uvK+zEW5XrqzK WRNpXFo9vd0pRftF4WjN/G7iCbsUho0WMtcGvM78ymGy7Hf5ECSAW1sojtpMYF76Z9mFGRxv rOPt/nvCXszoeOOcnbH9IyfpC6QHQkFNkZXMEfoSiNevoG8+9ts5v7Vdf5mFbOuj9bdGDzsz XaNtidWulkIpdQA26P+9lfdjnf1/t7CTxU+4UPcWWfNAh5FiJCNQZTvw2rytsd6BYeWTXPYk WYet8OA47VbZX2SrxClTOIIFbCvwv+KNjzAnFJid6XNERzzohZPmqgOuFlDyFdVDyoSRdP+j KbuVe55/pRfOj6harV6JtvpTc8r1qPnU9/iU5g4j+aigLAvLmdrHwk3OSZ8OlwBdmBwyMnT3 r/HK66R4Y4yU/gP8dZPb751PUUX7i4/33jPYpvw0g6q17GTDFbMFu9cYAvRMr9ot/7ZyOkwz zq5H5XQo/m4eLOnChQ7DaZKdDjm0FBiXM+p9ZQPHgJ9ClE/QzlJ5wDtLUMJINE9wP8PyY8kD 1m2W1RTzxLklGbbJACRInFlY/WHYHqMhSxTAMDYBn7xgyJLSd/2tM83LsJrFZF5r7YL5aAvE JE4lzCoX64npsLvoWpNNPEQbeVKKXyWuO55F3H0OGVmIcM8F1OhFx2NVlKHyRTixxGf7KMWi 7ahzQjcB5EEQmxf4Az+MZpDE3vZUaAhpd9P
IronPort-HdrOrdr: A9a23:gjA3Aaqh1inNRbt4PYfMTVgaV5tiLNV00zEX/kB9WHVpm5Oj5q OTdaUgtSMc1gxxZJh5o6H/BEDhex/hHZ4c2/h2AV7QZniWhILIFvAv0WKM+UybJ8STzJ846U 4kSdkANDSSNyk0sS+Z2njELz9I+rDum87Y55a6854ud3AXV0gK1XYBNu/vKDwMeOAwP+tAKH Pz3LshmxOQPV4sQoCQAH4DU+Lfp9vNuq7HTHc9bSIP2U2ltx/tzKT1PSS5834lPg+nx41MzU H11yjCoomzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8k8MFzX+0eVTbUkf4fHkCE+oemp5lpvus LLuQ0cM8N67G6UVn2poCHqxxLr3F8Vmj/fIB6j8DjeSP7CNXcH4vl69MZkm9zimg0dVeRHoe B2NqSixtxq5F377X3ADpPzJmFXfwKP0AkfeKgo/jJiuU90Us4LkWTZl3klSKsoDWb07psqH/ JpC9yZ7PFKcUmCZ3ScpWV3xsewN05DVStub3Jy8/B96QIm1ExR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY/vY1a9DC7kISaXOxDqBasHM3XCp9r+56g0/vijfNgNwIEpkJ rMXVtEvSo5el7oC8eJwJpXmyq9ClmVTHDo0IVT9pJ5srrzSP7iNjCCUkknl4+6r/AWEqTgKo CO0VJtcojexEfVaPJ0NlfFKutvwFElIbgohuo=
X-Talos-CUID: 9a23:VXF1O2jyi2VgtMGit3LOQ5B6pzJuVGWa5kX5eH6CIGdmS5fMZEGK1Kh6nJ87
X-Talos-MUID: 9a23:Gb1vighncegqaXj2IgDJvcMpHsFkpPi/Vls2lc8EgMKNKA5UGieGpWHi
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Dec 2023 21:03:22 +0000
Received: from alln-opgw-1.cisco.com (alln-opgw-1.cisco.com [173.37.147.229]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 3B6L3KtR014129 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <mmusic@ietf.org>; Wed, 6 Dec 2023 21:03:21 GMT
X-CSE-ConnectionGUID: q/uirKqdRtOE62K7ntM8Zg==
X-CSE-MsgGUID: yMWtTdCgTFy1nDY0e+I2Sw==
Authentication-Results: alln-opgw-1.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=kydavis@cisco.com; dmarc=pass (p=quarantine dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.04,256,1695686400"; d="p7s'?scan'208";a="12261868"
Received: from mail-bn7nam10lp2100.outbound.protection.outlook.com (HELO NAM10-BN7-obe.outbound.protection.outlook.com) ([104.47.70.100]) by alln-opgw-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Dec 2023 21:03:19 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gKz46db2uPPsfSTLIaj5zZkfQBpp1U74qtqkUWlSYRInFazE7u4O7iw9yNpfXMPGznzIXNp+viRs4BG7okPYkli20zaox3c2Al39XYauRGIjH+uol1T1hacIAAmf+14ej6hSNylGs+gz41js0Qf/5NpA4PTrpZT60EJRWgDNvi4o/Jk6ptQ2KRe/39B4erfBZVW2Ok2GJTwxp7dC02wnLWvzriDNLyBJ5XVWZJ+CWlh78LPEWPZ5zpJng/ocmMWw5JkDl0SMneoly1yhKIlDoUrXHY+7KMo9DtYIMPohJafaRaUe+U1mEeItu5HfngIx2xKq0ansK3kTYu4/QMM/3Q==
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=EHqrY+CI/+WYOmkD+x/frZBqUABrRlnh1SHoYcu4b4E=; b=F8U0rdlGuMdzoygyovKK9OUF3xwJvWCdSv/I+OOZAQkK6ZZ2SQ9J9dR/QDDYbTKNkdUHAhCfT2bEdYacY05bn9wntHr9CBDArjwDamo+/df0z9LLuuzpMTAYEPu1malC+KS/NT5JUnYVEkfB71WPJ+Wgf79EBy4tgMSBHtRBQqainSuauH6qeO7eM0fjuSemPlx5NMI8wPTzrfpymdvHa7I+/l5EJKGaZq/W8GkQI/y2OKVMZranSmtOIS0kvbOJaimY7NP9qMdozI6rIjn374S+6DrMPLtY9XLTpxnBhQ1a/OD+iXsuEF9p3rbpkxcxBAt4kpmNZld1pWxK10kkNA==
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
Received: from PH0PR11MB5029.namprd11.prod.outlook.com (2603:10b6:510:30::15) by DM4PR11MB5359.namprd11.prod.outlook.com (2603:10b6:5:396::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.37; Wed, 6 Dec 2023 21:03:17 +0000
Received: from PH0PR11MB5029.namprd11.prod.outlook.com ([fe80::bb5e:25e9:92ea:a20]) by PH0PR11MB5029.namprd11.prod.outlook.com ([fe80::bb5e:25e9:92ea:a20%7]) with mapi id 15.20.7068.025; Wed, 6 Dec 2023 21:03:17 +0000
From: "Kyzer Davis (kydavis)" <kydavis@cisco.com>
To: "Kyzer Davis (kydavis)" <kydavis=40cisco.com@dmarc.ietf.org>, Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
CC: "Esteban Valverde (jovalver)" <jovalver@cisco.com>
Thread-Topic: Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance
Thread-Index: AdnLnxa1oeUTBHs9SrOCZ4d9gnl/4AvUikQQACOy1sAAAkWlgABVSEmgAA+T+lAK2pUNoA==
Date: Wed, 06 Dec 2023 21:03:17 +0000
Message-ID: <PH0PR11MB5029FF6E3BF8DA63BECFC33ABB84A@PH0PR11MB5029.namprd11.prod.outlook.com>
References: <PH0PR11MB5029B53E9DF50EC1B420AF1EBB13A@PH0PR11MB5029.namprd11.prod.outlook.com> <PH0PR11MB5029896E1D6202953341CB27BBCEA@PH0PR11MB5029.namprd11.prod.outlook.com> <HE1PR07MB44410065064B77A55A8493C993CDA@HE1PR07MB4441.eurprd07.prod.outlook.com> <PH0PR11MB5029236B1114DE35C53A2BB2BBCDA@PH0PR11MB5029.namprd11.prod.outlook.com> <HE1PR07MB4441EE08225D3CE1C02BDDBA93D3A@HE1PR07MB4441.eurprd07.prod.outlook.com> <PH0PR11MB50293C206BA914CBD36F4BD2BBD3A@PH0PR11MB5029.namprd11.prod.outlook.com>
In-Reply-To: <PH0PR11MB50293C206BA914CBD36F4BD2BBD3A@PH0PR11MB5029.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR11MB5029:EE_|DM4PR11MB5359:EE_
x-ms-office365-filtering-correlation-id: cc5cc9da-b35e-4dea-295d-08dbf69ec4f8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vFbb/GOKQD4oEzHAa/a7XwewwCn7ZREf2NzpZD8XC1AWJG/qBn+6g0v2BLrU9HV83vijqhlt2vKzKLsl+8p+bbz447RnxJiM/N4MUQPjAqla+TTL7e8nZ6lKSKuovaKXrcaGfFUrlr/NbwtlijtWJBWpI7O6K5gMUXwKD9E9Ri0ouZnPOOyb28niM50NCeYYd7Qx3YwGovNVkIiA4WGAnaOanON3Fc4tD/aFcOmbEPS9ZX41VwZRHDIdTRBqe9v2n5ddKfkp7i0Ay4lp4pzCDti87X+MCQCowTG3+3FZRK9XgzhnBBAWZOV7fYZJ7wlu/5dLORGIgXxy7CAyb3UHweSgnfHE9QiBDavZXBOG2Kd23h3OCDQtRxLLUhV8m/yfImIsRYSayi1TD4IND3erjEj3tb4vnSCZaUXrdbUO14JiMJ6E9CDyDKHYuEEGcBHueNzrRY89ldaOtTbgf7iP04Brjn8BE5i1U/J45O4q5NH3WNq7AEoAtZAEDYVczXzxS+bxg3GohjEFoWcJaypltbWDcK2wjdkYpqO1h8K3t92vZn0r3iOG/BqA6CK3y9OHig8bh58Yocg9VbcZ22V0heu05GL5ELZlO1NAR2w2LB0r0WHlD/SH3jAySI2NUSi5d3P9EtyKETQQM50ACIDRVg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5029.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(376002)(396003)(346002)(136003)(39860400002)(230922051799003)(1800799012)(186009)(451199024)(64100799003)(66899024)(38070700009)(41300700001)(5660300002)(86362001)(2906002)(33656002)(99936003)(6506007)(7696005)(53546011)(9686003)(26005)(55016003)(107886003)(966005)(478600001)(83380400001)(71200400001)(8676002)(4326008)(8936002)(66446008)(122000001)(64756008)(66556008)(66946007)(76116006)(66476007)(316002)(38100700002)(110136005)(52536014); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: iMhCxsGEgoBizUcsrX4bU3U9oT1qACHsA8YIvEygbKEC0OJmbhEy3+S4x6BiIskChYVkbI2g1QhdQqj3fC5XiU/znqJsAj8w6YW51RwiW1tJQLfP/IVurJBUZga4GAIJQ1BUhTKHEkDq6e1B/mY0KtOE93Hg8+OyjXPAN3AAyjfR7zs47b/bJxdYf0phmj6ac07JJBvBC9KF7TchxntG3tx4SXqhR15BHBFpZD00WN70t956TeKTIPXLJ84A7ngR7gcDM3oVCJPF9q84nRgid7uBN0whYOGN+rVrV9sXBabpHqDtQSx1122Udo95Cfu87z35qzcFBnR2kcVYh3em/+8zLyxCT0WHIzCbpHQwNkmgwWTZsXRYBo/A1hdZDzPmTnMzL8ZZnOwRwEZNJj9K0J1D9UudereZCviJPbUj/MTbrXzxBzWMmN0xn/UEh54lrT6kxpRR95AMJUFU6Lp25UaIvEuMZZq3HB+pERJbpESKFDEFDl/HXwhE60awQ8Dn1US9aRTQ6zOTA/odVqyq5got9FTzvXZRCZbYNFj6giN4zSXRKppvvJMH40+wYCUm+BKgGvLT1kt4Cp2oZ9RoT9+wvPB8zZw6RyZN0eSvhMr7GAhneqEgKZwms2oxA06PFIHNI1XHM02BW4RYu3oeUrdt0IkIAIL1pIeZGeIawcvL1Fu1JEaQu7ENmkvGu8TDvZwcq4PNX4aRup7+8a7YrtiKFdNX4fAPSBKmqd8S2Y41MqufaODoULW6c2Uq1WbNnN3iQwyRmJKVJU0NBQ7Lc3vX0ywoBIw4Woj0JtfCSQwtV4jpl41RTE36HLA97z2E1AUM+cmD8Wy7qE9VGg7oKYa6viqjKrfQS+hfgMvb3rgFRvVVDUcwDZwbWqupNDpDCZFc3SSqSQylQJ05nzpyBpxE2zrxDoE1E7d+2h1GKzVi8rFPx6a/fXbr64S1Utidya2GAyBnx+8RJCxPJS0+MUcP9zATMD/8N5G23HWk4rx7YDBeRPnhcSt4tphAV67s7pFouSCSdxxTgTH2Hmj/eCQLw9Lb9Zkp8W69hKLmisXdlupkaX5bBJQKI650i+Ba+s56cigD4ZJWPXBmFw3zSSWf8qPcT1HVACm2Eb08hfI4qKQ16CMM4FDSGd40bY2qBbHZdBkaJXLn1Gm0yMD+2WCxf6WWMnfu9uW5wzVZ+XSB1OtpBfh5w4f7h++OIQOREamDg4I/vUyBZ8mj1s9AvQL4eSLXbjdZSH15lTvCnRqwURSq66BW6nYC8EOEAno5goGHhu9hItdDQVJrLo6SlN0esPDAXubB60TevcIVee+YnmGDcqrqfGvPEeYYaD6xUqaMP/iSXwYgPDp1h4Ymsv9LlwgzvgCBR9QheHzPUZ8mOuzEAikJZbg1zsUY3G8d+c+3RtmWuL7BvvWrD5bH13MqdfXvnHoEhIvRAdZJ5v8e24v4ox8ADRWpDhONT+qbCm22EdN+NnOmfZcmiKa4EiQEgvL6UtB74uF3TgfeOlGo2/SEKR9aEcrjzrHNu4IbBJb2fa69sKW23/MCzBcgno3cjcJLwdAszNpcy5OLEMs=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_028D_01DA285D.B8AD0FB0"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5029.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cc5cc9da-b35e-4dea-295d-08dbf69ec4f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2023 21:03:17.2456 (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: csmmu+IdCtlLoFpnQ/xGJ+pCud6lnnRdNuB/p3R+8RajqfLQwWaX+2E8xhCq94B7N6x1SlxlH7+OABRiHPXPXw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5359
X-Outbound-SMTP-Client: 173.37.147.229, alln-opgw-1.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/e93s6ddWlDGcxUrl3EFF-apuCTo>
Subject: Re: [MMUSIC] Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Dec 2023 21:04:48 -0000
Hello Christer, Sorry for the delay on this draft turnaround! I just posted Draft-02 and you can find the diff below: https://author-tools.ietf.org/iddiff?url2=draft-davis-mmusic-srtp-assurance-02 Draft-02 iterates on the points you brought up in the original email. The ABNF has been heavily modified. My testing with ABNFGEN seems to produce results I expect but a second set of eyes would be great. As for the key=unknown, I opted to remove this and instead I have a new section titled "handling unknowns" which should cover this sufficiently. There have been some slight TOC changes to break up the original section 3.1 and promote readability. Thanks, -----Original Message----- From: mmusic <mmusic-bounces@ietf.org> On Behalf Of Kyzer Davis (kydavis) Sent: Thursday, October 12, 2023 11:02 AM To: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>; mmusic@ietf.org Cc: Esteban Valverde (jovalver) <jovalver@cisco.com> Subject: Re: [MMUSIC] Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance > Would you not achieve the same thing by sending a new attribute without the value that has become unknown? Possibly, I cited a few things that come to mind over in the second command as I expanded upon the example below: https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/18#issuecomment-1756076224 Re-posting that comment to this thread: Scenario that comes to mind: - Sent "ssrc=0xABCD" - Something occurs, lost track of SSRC (application failover or something without any shared context info.) - Send "ssrc=unknown" to state that they should fallback to the default application logics. This makes it nice to handle scenarios in programs where simply omitting a value that was signaled before could cause problems. For example in bullet 3 if one sent nothing; how would the other side handle it? This method is a graceful yet explicit callout that this value is now unknown. That being said, in the scenario above all 3 (or more values) are likely unknown and thus the following line comes into play: > Applications SHOULD NOT include SRTP Context attribute if all three values are unknown or would be omitted. For example, starting a new sending session instantiation or for advertising potential cryptographic attributes that are part of a new offer. If we drop "unknown" we would need text to state how to handle a value that was advertised before and then was removed later or relax the text above for all unknown to account for this later-in-session "all unknown" scenario. Thanks, -----Original Message----- From: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org> Sent: Thursday, October 12, 2023 3:45 AM To: Kyzer Davis (kydavis) <kydavis@cisco.com>; mmusic@ietf.org Cc: Esteban Valverde (jovalver) <jovalver@cisco.com> Subject: RE: Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance Hi Kyzer, ... >Q.3 is two questions so I will address both: >A: The answer is value=unknown or no value at all are the same in the grand scheme. >The main difference is that I wanted to ensure an application had a way to explicitly call out that the value was unknown to them. >I could expand the text for one scenario that comes to mind which is: >perhaps there was a scenario where it was known, then later it became unknown and the app would like explicitly to state that as such and force a fallback to the default behavior. Would you not achieve the same thing by sending a new attribute without the value that has become unknown? Regards, Christer -----Original Message----- From: Christer Holmberg <mailto:christer.holmberg=40ericsson.com@dmarc.ietf.org> Sent: Tuesday, October 10, 2023 10:28 AM To: Kyzer Davis (kydavis) <mailto:kydavis@cisco.com>; mailto:mmusic@ietf.org Cc: Esteban Valverde (jovalver) <mailto:jovalver@cisco.com> Subject: RE: Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance Hi, A few questions, more related to the SDP usage than then mechanism itself. --- Q1: Section 3.1 says: srtp-context = srtp-attr srtp-tag [srtp-ssrc";"] [srtp-roc";"] [srtp-seq";"] [srtp-ext";"] I don’t think this is what you want, because you would have to add “;” also after the last field. Instead, you probably want something like: srtp-context = srtp-attr srtp-tag [srtp-param *(“;” srtp-param)] srtp-param = srtp-roc / srtp-seq / srtp-ext --- Q2: Section 3.1 says: srtp-ext = 1*VCHAR "=" (1*VCHAR / "unknown") ... VCHAR = %x21-7E I don't think you want to allow ";" (%x3B), because then one may not know whether it is part of the srtp-ext value or a separator between values. --- Q3: Section 3.1 says: “The value of "unknown" MAY be used in place of any of the fields to indicate default behavior SHOULD be utilized by the receiving application” How is that different from when the field is not included to begin with? Where are the default behaviors for the different fields defined? --- Q4: Section 3.1 says: "The tag for an SRTP Context attribute MUST follow the peer SDP Security a=crypto tag for a given media stream (m=)." It is unclear what "follow the tag" means. I assume you want to say that the SRTP Contect attribute MUST use the same tag value as the crypto attribute it is associated with? --- Regards, Christer From: mmusic <mailto:mmusic-bounces@ietf.org> On Behalf Of Kyzer Davis (kydavis) Sent: Monday, 9 October 2023 23.45 To: mailto:mmusic@ietf.org Cc: Esteban Valverde (jovalver) <mailto:jovalver@cisco.com> Subject: Re: [MMUSIC] Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance Group, I have posted draft 01 which covers the items from my previous email. Name: draft-davis-mmusic-srtp-assurance Revision: 01 Title: Signaling Additional SRTP Context information via SDP Date: 2023-10-09 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/archive/id/draft-davis-mmusic-srtp-assurance-01.txt Status: https://datatracker.ietf.org/doc/draft-davis-mmusic-srtp-assurance/ HTML: https://www.ietf.org/archive/id/draft-davis-mmusic-srtp-assurance-01.html HTMLized: https://datatracker.ietf.org/doc/html/draft-davis-mmusic-srtp-assurance Diff: https://author-tools.ietf.org/iddiff?url2=draft-davis-mmusic-srtp-assurance-01 Thanks, From: mmusic <mailto:mmusic-bounces@ietf.org> On Behalf Of Kyzer Davis (kydavis) Sent: Thursday, August 10, 2023 11:30 AM To: mailto:mmusic@ietf.org Cc: Esteban Valverde (jovalver) <mailto:jovalver@cisco.com> Subject: [MMUSIC] Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance Hello all, I presented draft-davis-valverde-srtp-assurance-00 at Dispatch and the outcome was to dispatch to MMUSIC WG. I have re-submitted draft-davis-valverde-srtp-assurance-00 as draft-davis-mmusic-srtp-assurance-00 with no changes. To view that session and/slides see below: - https://youtu.be/KT3mMX9CMdA?t=3113 - https://datatracker.ietf.org/meeting/117/materials/slides-117-dispatch-sdp-security-assurance-for-secure-real-time-transport-protocol-srtp - A quick slide note, before the dispatch session I was working on a draft-01 which leveraged Solution A in these slides while draft-00 uses Solution B. - Jonathan Lennox brought up a good point after the session which favors solution B: - Paraphrasing: "We know how implementations will handle unknown SDP attributes; we do not know well how well how implementations will handle unknown SDP Security Session Parameters" - I dug into this a bit more and tend to agree. So draft-01 now continues to use solution B (a=srtpctx) new SDP Attribute to convey the required SRTP Context information alongside a=crypto. - I have a full write-up on GitHub with far more details: https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/5 In addition, some other draft-01 actions items that were brought up in chat, at the mic or in person 1:1: - "Why this can't be a RTP Header Extension" from Richard Barnes. (https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/11) - "Discuss sending some update when ROC updates" from Jonathan Rosenberg. (https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/10) - Already text in the draft around this; which covers "99.9% of scenarios". - "Method to Convey Multiple SSRCs for a given stream" from various (https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/1) - Two solutions proposed in the GitHub issue - A statement Cullen Jennings made about focusing on the problem statements. - I want to re-write the problem sections like RFC7744 where each problem in a scenario is cited as Ux.y and then discussed (Section 2.1.1 and 2.1.2) - I took a stab at a rough draft of this in "Discuss why SEQ is signaled in the SDP" via (https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/9) - Overall item is in https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/13 Lastly, the following items are already merged into draft-01 over on GitHub: - Change contact name from IESG to IETF in IANA Considerations #2 - Discuss RFC4568 "Late Joiner" in problem statement: #3 - Split Serial forking scenario into its own section #4 - Add MIKEY considerations to Protocol Design section #6 - Change doc title #7 (new title: "Signaling Additional SRTP Context information via SDP") - Add SEQ abbreviation earlier #8 Thanks, --- Kyzer Davis
- [MMUSIC] Signaling Additional SRTP Context inform… Kyzer Davis (kydavis)
- Re: [MMUSIC] Signaling Additional SRTP Context in… Kyzer Davis (kydavis)
- Re: [MMUSIC] Signaling Additional SRTP Context in… Christer Holmberg
- Re: [MMUSIC] Signaling Additional SRTP Context in… Kyzer Davis (kydavis)
- Re: [MMUSIC] Signaling Additional SRTP Context in… Kyzer Davis (kydavis)
- Re: [MMUSIC] Signaling Additional SRTP Context in… Christer Holmberg
- Re: [MMUSIC] Signaling Additional SRTP Context in… Kyzer Davis (kydavis)
- Re: [MMUSIC] Signaling Additional SRTP Context in… Kyzer Davis (kydavis)