Re: [v6ops] [EXTERNAL] Re: Improving ND security

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 05 August 2020 05:35 UTC

Return-Path: <pthubert@cisco.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 CE6363A1244; Tue, 4 Aug 2020 22:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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_H4=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=N0QgGZ2X; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WqZR5Y/M
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 u8bApZtDH3hl; Tue, 4 Aug 2020 22:35:21 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CFE43A0E17; Tue, 4 Aug 2020 22:35:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24259; q=dns/txt; s=iport; t=1596605721; x=1597815321; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f277bL4o/C/szzXVSIygRbj2qD1SWwvc4Cg6th+9fNc=; b=N0QgGZ2XdBTgztVUw6/Q9Rj5ZFvRzGP5d8MWB+BFUGcquhRWiJkEflRk 1UFC0kci5zSSGrlwn15k6EIdyOFjA3QbMc9a+Y5t0+n4LmKxNshgKJiPY w6BXBP7NKjQ50GxNwDoaDRUfTcJ3BNIgoQd4RFJzyU84HcqOrUmFn36b+ w=;
IronPort-PHdr: =?us-ascii?q?9a23=3A81A6Uh+YsFqeOf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN7/JgjVnGG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iKxNkVUHsm4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDCADEQypf/4gNJK1gHQEBAQEJARI?= =?us-ascii?q?BBQUBggqBUlEHb1gvLIN1QFGCdQOhSIRsglMDVQsBAQEMAQEjCgIEAQGETAI?= =?us-ascii?q?Xgg0CJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAgQMBhEdAQElEgEPAgEGAhI?= =?us-ascii?q?wAgICMBcOAgQOBSKDBAGBfk0DLgEOl0CQaAKBOYhhdoEygwEBAQWBR0GDEBi?= =?us-ascii?q?CDgMGgTiCcINfhj8agUE/gREnHIJNPoJcAgMBgUNFgmozgi2SeYZfi1qQaAq?= =?us-ascii?q?CYohhhkOKZwMegnyJTpMxnFqUdAIEAgQFAg4BAQWBaiOBV3AVOyoBgj5QFwI?= =?us-ascii?q?NHo4BCwEXg06FFIVCdDcCBgEHAQEDCXyPIwUBAQ?=
X-IronPort-AV: E=Sophos;i="5.75,436,1589241600"; d="scan'208,217";a="521899069"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Aug 2020 05:35:20 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0755ZJZA020845 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Aug 2020 05:35:20 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Aug 2020 00:35:19 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 5 Aug 2020 00:35:19 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 5 Aug 2020 00:35:19 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hK1I0BtvDHGFthrhLWaepJ5mpeTHx+f2x5TtLKQz8gby1oxUvwBvGApRZkrbD/Vm5hRqX5gDSBFxIjaEudC0VONjIE3XeFObypTUDj5G1N/UoA+kspQJAEIuw37LfO6FPjkGPs4zBRiJehvsgej80XGk/o3ZlmB5kCHI4xG3EwwW2/mqTtYlmxZstEVL86dBdeTrF3+FSjMURNcxb73q56wBpvUt65YGI/K5/83fh6zQAUvDbHoGHO+1A1WLf+du7rYeR2FiZ7KMQdexahdRAL6rTYYj+SHr+ThNmVSUGR2x4fgjzDOTYGBFkBJBz0Cchxg2/Myqg7mzcXkXZiWXdg==
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=f277bL4o/C/szzXVSIygRbj2qD1SWwvc4Cg6th+9fNc=; b=i5MVLXWzw+e7SXvQh6ivZOuIvAm9nDWOyOOMAiM4dRSrOwa5gDsIjQ9fOucByl02kUQmy2seF+HikKHwXq/ofDW9RjZaKIO8+4BZsinQs/E6zKGVzXgvKfrqJSW6vzXES92LrjHbCM89RbhF8RQuhPMguwO+qb1SSQ5S06qkabF3CGto8fJxxJsTQ5ydeVdIcXI39JilGCHW9+mCTwXBJqcBmJu/Aeb+rXHNorHoAxogaO05nbLyWMw47AleUDTvop5ovZzzJhFGTOx+HSsZk28Akx6uUtyCAD6w5mYL+AkKK4B2Saa4nEh1juqa5xpZZk9/IxizxDDQ595HYjATiQ==
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=f277bL4o/C/szzXVSIygRbj2qD1SWwvc4Cg6th+9fNc=; b=WqZR5Y/Mm/VCsSHrNeOqn7W1AA3Q/cFfg2djsPvfVYa9GOiCevawlPJSeuHVfTB0F+7Kj7XSNRiysK3opQsOo/J2l+UJ5zUs7PX5Vp0+LZC+Cugge+900+tAmMA2rtCs1AL7YUsQLxO+/rPmy++Zf8prYnZsGIGrbQwJDGw4ueg=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3727.namprd11.prod.outlook.com (2603:10b6:208:f0::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Wed, 5 Aug 2020 05:35:18 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::a53e:5801:92cc:3204]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::a53e:5801:92cc:3204%5]) with mapi id 15.20.3239.022; Wed, 5 Aug 2020 05:35:18 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Fernando Gont <fernando@gont.com.ar>
CC: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Thread-Topic: [v6ops] [EXTERNAL] Re: Improving ND security
Thread-Index: AdZnYGykJNK1kk2zSneWe05yLDtm6gAAUmIAAABNVoAACE6vdgAA50eAAIZwnoAAA560AAABYB2AAARvxIAAAjUOgAAFdi0AAEERuEw=
Date: Wed, 5 Aug 2020 05:35:18 +0000
Message-ID: <02D913B5-17C8-43ED-B572-04FD97420F99@cisco.com>
References: <d5c245f216c3409f826f8132e532a882@boeing.com> <860E06E2-2650-4AAE-AD33-D4D12B0290DC@fugue.com> <b66ce3d9c75d4a39b5336dcdf9929411@boeing.com> <0DDEBA6C-3933-40FC-BB9C-33FA59DC9D76@cisco.com> <4907a159683346789bef5c495f03f95d@boeing.com> <b5043a5446914cb5b12ed76401359c7e@boeing.com> <3978163f-8815-1bd4-0fda-d84df9cbe684@gont.com.ar> <6b0d6c0a790b46c893b0ff3051599fb4@boeing.com> <85d89256-a495-d779-2c7c-2573bfae36c5@gont.com.ar> <da17a88b1886451796e45331a2fd75d4@boeing.com>, <a3d8ba55-52f1-f1dc-f75d-ee71a39dd9e3@gont.com.ar>
In-Reply-To: <a3d8ba55-52f1-f1dc-f75d-ee71a39dd9e3@gont.com.ar>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: boeing.com; dkim=none (message not signed) header.d=none;boeing.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb15:25e:cc00:583c:413:57fb:c8a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 27b3d013-5480-4e57-d96c-08d8390156b7
x-ms-traffictypediagnostic: MN2PR11MB3727:
x-microsoft-antispam-prvs: <MN2PR11MB3727EE8FF1827D9A8A5AA4B9D84B0@MN2PR11MB3727.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: CZyAsiYjzdVz6P3OMefEmSgCzbQwEeDXTz1mEaibsSaEFM2ZY663HrauRIev5BT9xkNRmNCMEpt9NGU5HtujjPkiTBvDtMfHwdo4DFUliPAIGyCXl/Inm/6sQnI1qKkUaBsr+LuRW+2eoO7xY/yllTD0Y/5+gGJk6XsRN0+4duVxqfDw9ZcW+qytxJiZJwMuqzGqs3yTyUvrVe6iMWrneD4IXju8hTNJGoWZPm2YV+0p880r6SRgRaAt70uK9l0yX1md7SstGIjxGrJRttXOAHZCoUQeJ4oRFZMYqyXyqDxradpE4ar7sHOdc5meUVTQR9H+g9qI30zbCJ52wxBhBj4+6fjbDtVpuItF3nVCMjDsm3BGuF9KSesDC4ycD9SGk8dhnxDho+05lU5UERqNpQoBQLeJz+oo6139G3mr22c0ZV24KJjOR1cE+Ytb+xgy7dYV/IgBDx5euRJJ8tcw8w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(396003)(136003)(366004)(15650500001)(6916009)(4326008)(5660300002)(83380400001)(66574015)(2906002)(478600001)(166002)(36756003)(71200400001)(33656002)(66946007)(316002)(76116006)(53546011)(6506007)(2616005)(91956017)(66476007)(66446008)(186003)(966005)(6512007)(8936002)(54906003)(86362001)(66556008)(64756008)(6486002)(8676002)(244885003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 97gRpSx8i9IPmOcFIyWQESYK+Pn4GlbBg+qn2zGlgnxQHRXV3UdiwdPvXm2R+5mgWMxm/G0b5uZWXqY3XMf2yRdcTwqMm8wyqrvzKenGEE0b2aCSBCaKTJj2nLGxIZL4L8KprSuFcYS6ilJUjw0As4vUtd6yzyWLqAFo6OIbfgjDIbAj7VGJWiZFMwF3NjNwJJLyFlSYOMMHPaPthP2N2bQ3Kc7vdSdB7IulfV8i/QE1QCYgcPfaAV1eqwlIS1z8Ei/uer/kJ85fAXLjKYEk3RlzJkcfJTdugq3miulOMQDIChdJtKEMLlhWIQwN6ihLVlI8RwFCmTM/a8OYDf3ksseV52kdbyLzaIHHTQNrRiD7HBApVbIK7tynFpkChq+b/708aGwvMvcphIxT/33J4+B/LpTG1szq1qFMSJqWE9PNfER30yyvQuXWKDKWGxoC+C/BquJaP3ObOafNIud7uQbhmMAW2SJPi6fugqDWNHadfol6hh+Xf0N5fiS/v+TYYy8YHYP9MD+KC8Uf6CTwQ/K3QtIZAhL/f/1W+k6bk253IAZ4g2zcoY3eLvwcC7r3JfPLWi7y/bCLEFQBz4PgJjESW2tFa5PPfPF1R9KEH+LC4Qnzm0jEMILdXGMJHZJ2oQrSziX2FPOhvXayV0R/zGSueMmMvixt8LHCpkJJAoUT0RZZAkNlwRJez2IUB7y9TXK4cgDl6oDnK+xtHaAFEQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_02D913B517C843EDB57204FD97420F99ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3565.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 27b3d013-5480-4e57-d96c-08d8390156b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 05:35:18.4295 (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: 34eeGizl68ZrukuZIuI1BIdw/pWEdkKv4xLiz4PwreXCxoW5swxhwCHvf+OjsiD6xFK9Mw6RsvwOJwqkVneSMg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3727
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/XY8sip2VANPJc8e7obo7h0_iZ4A>
Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security
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: Wed, 05 Aug 2020 05:35:25 -0000

I agree that a valuable ND security should not only protect address ownership but also provide SAVi, which send does not.

SeND has to protect distributed stateless address claim so they decided to embed the proof of ownership in the address. This limits the size of the security proof to 64 bits which is far from sufficient. So CGA added those 3 bits that optionally make the computational cost more cumbersome. Nobody uses that so the protection is low. Very powerful devices could potentially do that but smaller devices will be left with little protection and hardship to form new addresses.

In a stateful architecture the proof of ownership can be separated from the address and made bigger. It is stored in the infrastructure together with the address on the first come. A same proof can be used for multiple addresses (and obfuscated with rehashing) so it does not affect privacy addressing.

https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/ Is sitting in the rfc editor queue and soon on the shelf. It does all the above. SAVI. Proof of ownership. But it only works for addresses that are registered through rfc 8505, which makes ND proactive/stateful.

All the best,

Pascal

Le 5 août 2020 à 01:41, Fernando Gont <fernando@gont.com.ar> a écrit :

Hi, Fred,

On 3/8/20 16:55, Templin (US), Fred L wrote:
[....]

That is fine; we can accommodate CGAs in OMNI, cumbersome as they are.
I have this on my TODO list for after the adoption call.

Why "cumbersome"?
I realize the addresses are cryptographically-generated, which implies a security property
which is good. But, they would not be the primary link-local addresses that neighbor
nodes will know each other by - the CGAs will be found in the IPv6 ND message source
and destination addresses, while the primary addresses will be carried in an additional
IPv6 encapsulation header and would be the addresses that the NCEs are indexed by.

Not sure what you mean...



So, all the CGAs really are is placeholders in the IPv6 header to run security checks over.
They need not even be checked for uniqueness on the link, because it is the primary
addresses and not the CGAs which need to be maintained as unique.

The point of CGAs is that in order for you to ND-answer for PREFIX:IID, you need to have the key identified by "IID". So, assuming /64s, you'd need to be lucky to, given a CGA (PREFIX:IID), generate a key-pair where the public key is identified by "IID".



But then, RFC4380 offers a “poor-man’s” alternative to SEND/CGA. It
places a message authentication code in the encapsulation headers of IPv6 ND messages so
that the messages can pass a rudimentary authentication check.

You mean the Teredo spec? If so, I don't think it includes any sort of
poor-man's SEND-CGA.

It provides for message authentication,

But what's special about SEND/CGAs is that they tie the address to a key...
OK, that sounds good. So, we like that property but AFAICT that is about all the
CGA is good for in my application.

The thing is that, while in theory you could *theoretically* extend the use of CGAs as a spoofing mitigation, in the context of SEND CGAs are just employed for mitigating ND attacks... and that's kind a lot of effort for mitigating something that we have learned to live_with/mitigate in IPv4 in simpler ways.

i.e., I find SEND smart... but, in the bigger picture, not very compelling to deploy.


[...]
The usage we have for OMNI is that of an Internet-based Client sending an
authenticated, encapsulated, unicast RS message to an Internet-based Server
which then must authenticate the message.

Depends on what you mean by "authenticated". CGAs prove that the node that sends the packet is the owner of the address. Not more than that.

That's different than authenticating the client.

Similarly, you could authenticate the client, but that wouldn't mean that a client is the owner of a given address.




So someone with
security experience please help me out here – is RFC4380 authentication an acceptably
secure  replacement for SEND/CGA that might be easier to work with and less
cumbersome?

Nope. Tee point of CGAs is that they allow you to prove address
ownership. There's nothing in RFC4380 that provides the same or similar
functionality.

Why do we have to prove address ownership

Well, that's one of the goals of SEND/CGAs. :-)


and use a whacky address format like CGA?

The *address format* is not really whacky. At the end of the day, it's a
random number, with the specific property that it's part of the hash of
a public key.

looking at a CGA, you probably wouldn't be able to tell CGA from RFC7217.
[...]
I think if you look inside the IPv6 ND message and find a CG option you can
infer that the address in the IPv6 header is a CGA.

Yep... but CGA != CGA option.

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1