From nobody Thu Feb 1 01:26:50 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFA113165C for ; Thu, 1 Feb 2018 01:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=nokia.onmicrosoft.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 hxMpbyII12Od for ; Thu, 1 Feb 2018 01:26:45 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0135.outbound.protection.outlook.com [104.47.1.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B013131583 for ; Thu, 1 Feb 2018 01:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q7vSk1CbV/kPByqJXvnUszH9WHJLfznansnhnVqo7L4=; b=VbWsMWyh6RN9TTOwNUcsvg289Gm3i50lHO9y/Q6u6k5EvU4FIIn91IYAf08uS6hS9voJtrXcixFkJ7P8bboY4dIL5dMx80f2uUHFuKNCUbYxqBdrZa0DprVbNP1d0ioCSzapg62Oty2K2dONuhCUX8GqE7wglJsBAGxnps57pRw= Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com (10.168.36.134) by HE1PR0701MB1994.eurprd07.prod.outlook.com (10.167.189.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Thu, 1 Feb 2018 09:26:41 +0000 Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::9b8:9374:fee3:870c]) by HE1PR0701MB2203.eurprd07.prod.outlook.com ([fe80::9b8:9374:fee3:870c%15]) with mapi id 15.20.0464.012; Thu, 1 Feb 2018 09:26:41 +0000 From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" To: Brian E Carpenter , "Michael H. Behringer" , "anima@ietf.org" Thread-Topic: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 Thread-Index: AdOQOqjZa4fS/rQGRxGAbTN9FDz3cgAUE5KAAhVA0YAAFMr+gABlM5sAABzZYYA= Date: Thu, 1 Feb 2018 09:26:41 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <12959.1516300465@obiwan.sandelman.ca> <5c4c7844-beb8-2562-e3a7-057218d3bc89@gmail.com> <6611b5f4-0690-e6bb-cb54-6faf3f9d0ac2@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=laurent.ciavaglia@nokia-bell-labs.com; x-originating-ip: [86.247.200.44] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB1994; 7:2ZrTrHtY8kUSdVKawjRuqL1xG8CBotzyDTve2ul5CWXHomL+A4uOkqLS6+F33vLJ2tnkW+kz51yvG0OWRXzEdi+gTrfUgzGzuFSgq8PH7ekNRY3nACEmO0nahNNjE/AffMOmb8cDgOdCECIYLCV5hMB6FY/ToYcyeDCZMxY9MVoWAZ4uzZyTVyrMD6b4YLIB9MYVa57gJe7HxogruAsIZRg5WebyOHjFTYGAC9H1MMlEV9mwqmJQO64MaTaMHbIC x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 42a91291-e468-4179-e793-08d56955e6fa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:HE1PR0701MB1994; x-ms-traffictypediagnostic: HE1PR0701MB1994: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(11241501184)(2400082)(944501161)(6055026)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR0701MB1994; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB1994; x-forefront-prvs: 0570F1F193 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(39380400002)(396003)(376002)(346002)(199004)(189003)(13464003)(6436002)(229853002)(2906002)(3280700002)(6306002)(3660700001)(25786009)(2950100002)(6246003)(6116002)(3846002)(55016002)(74316002)(86362001)(7736002)(33656002)(8676002)(305945005)(53936002)(5250100002)(478600001)(102836004)(93886005)(26005)(99286004)(97736004)(14454004)(2501003)(68736007)(106356001)(186003)(966005)(5660300001)(39060400002)(66066001)(316002)(2900100001)(81156014)(81166006)(9686003)(8936002)(76176011)(59450400001)(6506007)(53546011)(105586002)(7696005)(110136005)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB1994; H:HE1PR0701MB2203.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: QiVOnyL9YCyLnCHmc4eOpe0/0vugGdZeo5Z83PyAZ8FHu3iip4QIGLZnwg01PHIyT1AUmiJy00PcLKfxdrQ4NQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42a91291-e468-4179-e793-08d56955e6fa X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 09:26:41.0195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB1994 Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 09:26:49 -0000 Hello, We are currently 8 "co-authors" for this draft. My preferences, in priority order, are: 1) Michael as Editor, all other authors listed as authors, no contributors= . 2) Michael as Editor, all other authors listed as contributors. Given how this document originated and has developed over time, this would = reflect, from my viewpoint, a "fair representation". We may discuss our approach for representation of contributors versus RFC e= ditor guidelines. I think it can be important for the "external readership" that the diversit= y of people that took part in this document is visible, although I understa= nd (and fully support) that IETF is not affiliation-driven. Nevertheless, s= howing industry and academia mix is good, and also several vendors co-signi= ng. But this may not be our only driver for deciding how to list authors. Side question: how are contributors associated with an RFC in the datatrack= er? I mean if I search on the datatracker with someone's name, will the RFC= where he has been contributors appear? Thanks, Laurent. -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, January 31, 2018 8:16 PM To: Michael H. Behringer ; anima@ietf.org Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-referenc= e-model-05 - Respond by January 22nd, 2018 On 30/01/2018 07:58, Brian E Carpenter wrote: ... > On 29/01/2018 22:03, Michael H. Behringer wrote: >> OK, the time for the last call is over. I'll produce a -06 version,=20 >> working through the following issues: >> >> - Sheng's review from 18 Jan (Thanks Sheng) >> - Michael's response to Sheng's mail. >> - the author issue. I think I'll follow Brian's suggestion, listing=20 >> me as editor and all other co-authors under contributors. At least I see= no better way... On looking at that again, please consider that what I actually wrote was: >> To answer to Brian comments on co-authors: if we have one or more Editor= s, should all other "authors" be listed as contributors? >=20 > That is the option suggested by the RFC Editor site, and Michael has been= the editor all along. > Personally I would be quite happy to be listed as a contributor. I think it's perfectly fine to list one or two editors, then three or four = authors of substantial text, to a maximum of 5, and then list the rest as c= ontributors. If you really can't cut the list at 5, we'd need to justify it= to the AD. Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Thu Feb 1 05:42:59 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D6E12AF6E for ; Thu, 1 Feb 2018 05:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 Idvq0zT4TS1J for ; Thu, 1 Feb 2018 05:42:54 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8DD12E87D for ; Thu, 1 Feb 2018 05:42:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=Wyt/qLGNWz9OS8BKXF2x4v1mhQiiDPzNnK39KIttqU2Sl+k5dkL9tx1CmLy9xnE5hBe0ZkEUkvFjdh6aLlIGziWdJYMz4Pft8wMNABFPMEEtMlSPjHkXc+4o43BiAmQTwmuZsC8z7Z/CmtZtgLC8SiRVl0LU5w+X+3/CI3A5qBc=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 19789 invoked from network); 1 Feb 2018 14:42:31 +0100 Received: from mue-88-130-61-026.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.26) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Feb 2018 14:42:31 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> Date: Thu, 1 Feb 2018 14:42:29 +0100 Cc: draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, Michael Richardson , The IESG , anima@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180201134231.19779.99739@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 13:42:57 -0000 HI Toerless, thanks so much for these edits. Unfortunately I have one more question. = And sorry again for the delay. Why does your case 2 need an MPTCP connection instead of just opening a = second separate TCP data plan connection (that of course fails when it = fails..)? Mirja > Am 27.01.2018 um 00:06 schrieb Toerless Eckert : >=20 > On Fri, Jan 26, 2018 at 11:43:08AM +0100, Mirja Kuehlewind (IETF) = wrote: >> Hi Toerless, >>=20 >> sorry for my late reply but I spend only limited time on AD stuff on = the telechat agenda was crowded this week. >=20 > Thanks for all the hard work! >=20 >> Okay that is fine. I mainly wanted to double-check as that was still = not fully clear from the provided text. Can you maybe propose a slight = rewording that explicitly say that there is this backup while using the = word ???only??? above in the cited text seems to indicated differently. >=20 > I wanted to take the full extend of your feedback into account, so > rewrote the paragraph in question maybe a bit more than slightly > (couldn't figure out a sane "slightly" ;-): >=20 > - Moved up the last sentence about per-connection policy up front, > so the examples are more logical scoped. >=20 > - Made the examples into three separate bullet points > and expanded them to hopefully eliminate the misunderstanding > wrt to backup. >=20 > - Not only mentioning the fall back (backup), but also added > desirable behavior under recovery of preferred subflow path.=20 > (important for both 1) and 2). >=20 > - explaining in bullet point 3) how this one is actually a > simple TCP connection (As you pointed out). > (whereas 1) and 2) rely on the MPTCP benefit of two subflows and = address signaling). >=20 > -09 uploaded with this fix as well as fix for Yohi's comment. >=20 > Diff: >=20 > = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools.ietf= .org/id/draft-ietf-anima-stable-connectivity-08.txt&url2=3Dhttps://tools.i= etf.org/id/draft-ietf-anima-stable-connectivity-09.txt >=20 > Here is the changed paragraph: >=20 > The above described behavior/policy for MPTCP must be controllable by=09= > applications or libraries acting on behalf of applications. APIs > and/or data models for this control need to be defined. It should be > sufficient to make these policies work on a per connection=09 > basis, and not change during the lifetime of a connection for=09 > different data items: >=20 > 1) The policy for likely most connections would be to use the = data-plane > subflow and fall back using the ACP subflow when the data-plane = fails. > This could be the default. It reduces load on the ACP but would = continue > to run connection traffic at likely reduced throughput when the > data-plane fails. Ideally such connections would also revert back = to > using a data-plane subflow once its connectivity recovers. >=20 > 2) Connections for non-urgent bulk transers (for example most routine=20= > firmware updates or cached log collection) may use a policy where > the connection is made to fail when the data-plane fails or have > transfers suspend until another data-plane subflow can successfully > be built. This avoids over-taxing the ACP when the data plane fails.=20= >=20 > 3) Connections for critical network configuration change operations=20 > known to impact the data-plane might want to only use the ACP and > could therefore map to a (non-MP)TCP connection. >=20 > Cheers > Toerless >=20 >=20 > m 22.01.2018 um 19:42 schrieb Toerless Eckert : >>>=20 >>>=20 >>> Thanks, Mirja. Inline. >>>=20 >>> On Mon, Jan 22, 2018 at 01:37:58PM +0100, Mirja Kuehlewind (IETF) = wrote: >>>> Hi Toerless, >>>>=20 >>>> thanks a lot for the updated text. I still have one little point I = would like to discuss a bit further on this text: >>>>=20 >>>> "The above described behavior/policy for MPTCP must be controllable = by=09 >>>> applications or libraries acting on behalf of applications. APIs=09= >>>> and/or data models for this control need to be defined. As = outlined=09 >>>> above, applications for example may choose to only perform = transfers=09 >>>> if the data-plane is actually available because of performance=09 >>>> limitations of the GACP, so the application needs to be made aware = if=09 >>>> the setup of the data-plane subflow fails. Or transfers may want = to=09 >>>> only use the GACP because the connection performs configuration=09 >>>> changes that are likely known to bring down the data-plane. It=09 >>>> should be sufficient to make these policies work on a per = connection=09 >>>> basis, and not change during the lifetime of a connection for=09 >>>> different data items.??? >>>>=20 >>>>=20 >>>> When you say that there is a need for an application to send data = only on one path, today that???s not possible with MPTCP as you may = fallback to the other path silently during the transmission. Yes, of = course this could be changed and an extended interface could indicate = this.=20 >>>=20 >>>>=20 >>>> So my question is still what the ???only??? really means in this = text. If you???d like to just indicate a preference that might be okay. = If you really want to rule out the possibility to fallback to the other = path, then I don???t think you need MPTCP and two separate TCP = connections would be the better option. >>>>=20 >>>> Does that make sense to you? >>>=20 >>> Not really, the goal is always to leverage existing MPTCP signaling = of >>> addresses, indicating backup for flows, etc. I think two TCP flows = would >>> never be better: >>=20 >> Okay that is fine. I mainly wanted to double-check as that was still = not fully clear from the provided text. Can you maybe propose a slight = rewording that explicitly say that there is this backup while using the = word ???only??? above in the cited text seems to indicated differently. >>=20 >> Thanks! >>=20 >>>=20 >>> The GACP address is the primary identifier of a device known in DNS. >>> Data-Plane addresses can change over time subject to operator = configuration >>> and could also pose more of a security issue to be in DNS (GACP is = isolated >>> network). >>>=20 >>> GACP performance may be quite low because some network device may = route/forward >>> it in software. data-plane routing/forwarding is expected to be = fast/HW-accelerated. >>>=20 >>> With MPTCP as suggested this gives for example: >>> Initial subflow must use GACP because thats the only "known/stable = address" in DNS >>> Then MPTCP signaling is used to indicate mutually the data-plane = addresses >>> and make GACP subflow backup. >>> Then you transfer lets say a few Gigabyte of data (e.g.: firmware = update) which >>> goes over data-plane. >>> Then some uncorrelated error happens and data-plane fails. This = particular app >>> should then fail because it would just slow down to insufferable = slow across >>> GACP and would overload software forwarding in GACP. >>>=20 >>> In another application connection, fallback to GACP subflow for data = if dat-plane >>> subflow fails is fine, but you would only prefer data-plane for = performance. >>>=20 >>> You could consider the GACP potential software only forwarding like = a very high >>> cost of using it while data-plane is free. >>>=20 >>> If i would just use 2 * TCP instead of MPTCP i would have to = reinvent a lot of >>> MPTCP to get the address signaling etc. Right ? >>>=20 >>> Cheers >>> Toerless >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>=20 >>>>> Am 17.01.2018 um 03:36 schrieb Toerless Eckert : >>>>>=20 >>>>> Mirja, Yoshifumi >>>>>=20 >>>>> I just posted -08: = https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt >>>>>=20 >>>>> I have reworked the MPTCP text based on your threads feedback with >>>>> the intention to fix errors and have it answer the = questions/concerns raised, >>>>> but without otherwise changing the scope of it: >>>>>=20 >>>>> - What are they key features making MPTCP interesting=20 >>>>> - How could it be used to solve the stable-connectivity issue >>>>> - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK >>>>> beyond the scope of this document >>>>> - Describe the areas of specification work required >>>>> - API/policy, control by apps >>>>> - dealing with dual VRF addresses >>>>>=20 >>>>> Please check diff in this URL (not complete diff of -08, just fix = for your discuss/comment): >>>>>=20 >>>>> = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.github= usercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74a= d152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stab= le-connectivity-08.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/a= utonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf= -anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt >>>>>=20 >>>>> I hope this resolves your DISCUSS/comments.=20 >>>>>=20 >>>>> Note that the term ACP was changed in the doc to GACP based on = resolving Alvaros discus. See: >>>>>=20 >>>>> = https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/= draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt >>>>>=20 >>>>> Thank you >>>>> Toerless >>>>>=20 >>>>> On Thu, Jan 11, 2018 at 03:42:53PM +0100, Mirja K?hlewind wrote: >>>>>> Hi Toerless, >>>>>>=20 >>>>>> the point I'm wondering about is your point (b) below. Yes, you = can >>>>>> set the ACP subflow to backup but that would still mean that if = the >>>>>> other link fails, it would automatically switch over to the ACP >>>>>> subflow (without exposing this to the upper layer). Is that what = you >>>>>> want? Because my understanding was rather that there are cases = where >>>>>> you'd probably would like to know over which link the OAM packets >>>>>> where actually sent...? >>>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>> On 08.01.2018 22:06, Toerless Eckert wrote: >>>>>>> Thanks, Mirja >>>>>>>=20 >>>>>>> (a) If the systems socket API does not transparently make TCP = sockets >>>>>>> to use MPTCP, then you would want a shim library. According to >>>>>>> draft-hesmans-mptcp-socket, this is be the case on Apple (iOS). >>>>>>>=20 >>>>>>> (b) Making the ACP subflow not carry traffic after establishing = the >>>>>>> data plane subflow should easily be possible possible by setting = its MP_PRIO >>>>>>> to backup. >>>>>>>=20 >>>>>>> (c) How exactly to specify or implement the desired policy of = only >>>>>>> establishing a subflow between the ACP addresses and the data = plane addresses >>>>>>> (but not full-mesh) seem to be a subject for further spec work. = It could >>>>>>> be defined as a specific in-MPTCP policy, or it could be done = via a shim >>>>>>> library (orthogonal to (a)). draft-hesmans-mptcp-socket might be = sufficient. >>>>>>>=20 >>>>>>> But in general: i would like for this (informational!) draft to = just motivate >>>>>>> the concept and not specify the solution: MPTCP would be a = simple way to >>>>>>> make "TCP" applications automatically "upgrade" from ACP to a = data-plane path >>>>>>> and switch back when data-plane fails... because MP-TCP can = signal the >>>>>>> additional data-plane addresses, establish transparently another = subflow and switch >>>>>>> traffic between the subflows - all by using the right = shim-library+API or >>>>>>> in-MP-TCP address/subflow policies - and the ability to = establish subflows >>>>>>> across two VRFs. >>>>>>>=20 >>>>>>> Cheers >>>>>>> Toerless >>>>>>>=20 >>>>>>> On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind = (IETF) wrote: >>>>>>>>>>> Suggested replacement text last two paragraphs of 2.1.5: >>>>>>>>> A (shim) library for aplications maps TCP connections to MPTCP = without the applications having to be aware of it. >>>>>>>> It???s not the (shim) library/policy framework that opens/maps = the TCP connection. MPTCP itself opens eventually multiple connections = but exposes only one connection to the layer above. That means = everything above MPTCP does not have any real control about which data = is send over which connection. >>>>>>>>=20 >>>>>>>> A policy shim layer could only implement rules about which new = subflows should be established when and what the priority is over which = subflow data should be sent but it generally does not control which data = is send of which flow. You can???t say I want this data to be sent over = subflow one and this data to be sent over sub flow two. >>>>>>>>=20 >>>>>>>> I think what you want is actually a view on the different TCP = connections and you try to use MPTCP only for announcing the other IP = address but that is not what MPTCP meant to be. >>>>>>>>=20 >>>>>>>> Mirja >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Names in DNS use only the ACP IPv6 addresses of network = devices. Thererefore, the initial MPTCP subflow will use the ACP. After = it is operating, the shim libraries on both ends add their data-plane = address (MPTCP ADD_ADDR) and attempt to build a new subflow between = those addresses. If that (data plane) subflow is successfully built, the = shim libraries could shift all traffic over this subflow which should be = forwarded hardware accelerated by the network - and use the ACP subflow = across the ACP solely for signaling - beause it is most resilient = against failure. >>>>>>>>>=20 >>>>>>>>> This MPTCP approach is only an outline and would need to be = fully speficied for interoperable implementations. It may also require = extensions to MP-TCP. This mechanism must not be used without providing = for encryption of subflows not running across the ACP. >>>>>>>>>=20 >>>>>>>>>>> Brian: ... can not use capital MUST NOT in an information = draft (i think) >>>>>>>>>>>=20 >>>>>>>>> Cheers >>>>>>>>> Toerless >>>>>>>>>=20 >>>>>>>>> On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind = (IETF) wrote: >>>>>>>>>> Hi Micheal, >>>>>>>>>>=20 >>>>>>>>>> to clarify one part below: >>>>>>>>>>=20 >>>>>>>>>>> Am 05.01.2018 um 23:30 schrieb Michael Richardson = : >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Mirja K=C3=83=C2=BChlewind wrote: >>>>>>>>>>>> "DNS naming is set up to provide the ACP IPv6 address of = network >>>>>>>>>>>> devices. Unbeknownst to the application, MPTCP is used. = MPTCP >>>>>>>>>>>> mutually discovers between the NOC and network device the = data-plane >>>>>>>>>>>> address and caries all traffic across it when that MPTCP = subflow >>>>>>>>>>>> across the data-plane can be built." >>>>>>>>>>> Section 2.1.5 is discussion, it discusses ways in which the >>>>>>>>>>> anticipated low performance (compared to what the box might = do with its >>>>>>>>>>> hardware accelerated forwarding). >>>>>>>>>>>=20 >>>>>>>>>>> If we have an application that needs the bandwidth of the = native hardware, >>>>>>>>>>> the connection can be initated over the ACP (that's what = would be in DNS). >>>>>>>>>>> One presumes that an MPTCP layer could then enumerate the = available IPs at >>>>>>>>>>> each end and then start off additional flows on the other = destinations. >>>>>>>>>> MPTCP adda an additional TCP flow but for the application = that still looks like one flow. As I said I???m not sure if that is what = you want. >>>>>>>>>>=20 >>>>>>>>>> Mirja >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> The application would have to include application security, = since it would >>>>>>>>>>> not be protected by the ACP. >>>>>>>>>>>=20 >>>>>>>>>>> Perhaps MPTCP doesn't work this way. >>>>>>>>>>>=20 >>>>>>>>>>>> However, I'm actually uncertain how this is supposed to = work and what >>>>>>>>>>>> "Unbeknownst to the application" should mean. If another = address should be >>>>>>>>>>>> signaled to the other host, this needs to be indicated by = the application or at >>>>>>>>>>>> least some kind of policy framework above MPTCP. Also MPTCP = will by default use >>>>>>>>>>>> both paths simultaneously while still looking like one = connection to the >>>>>>>>>>>> application, meaning the application has no control which = path is used for >>>>>>>>>>>> which traffic. I guess you can open a second subflow and = then configure the >>>>>>>>>>>> first subflow as backup path but I'm not sure if that's = what you want (given >>>>>>>>>>>> the application/policy framework will still not know which = path is used)..? >>>>>>>>>>>> Please provide more information about what the expected = usage scenario is here. >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Michael Richardson , Sandelman = Software Works >>>>>>>>>>> -=3D IPv6 IoT consulting =3D- >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Anima mailing list >>>>>>>>>> Anima@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>>>> --=20 >>>>>>>>> --- >>>>>>>>> tte@cs.fau.de >>>>>=20 >>>>> --=20 >>>>> --- >>>>> tte@cs.fau.de >=20 > --=20 > --- > tte@cs.fau.de >=20 From nobody Thu Feb 1 07:32:03 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E188812D849; Thu, 1 Feb 2018 07:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Ctk5DUf_3NX0; Thu, 1 Feb 2018 07:31:59 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB15A12EB30; Thu, 1 Feb 2018 07:31:59 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D45E820093; Thu, 1 Feb 2018 10:38:09 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1AA6180A6A; Thu, 1 Feb 2018 10:31:57 -0500 (EST) From: Michael Richardson To: "Mirja Kuehlewind \(IETF\)" cc: Toerless Eckert , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com In-Reply-To: References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 15:32:03 -0000 --=-=-= Content-Type: text/plain Mirja Kuehlewind (IETF) wrote: > Why does your case 2 need an MPTCP connection instead of just opening a > second separate TCP data plan connection (that of course fails when it > fails..)? I think the idea is that there is some long running connection; for instance a log flow or a mirror port flow. Or maybe even an SDN control connection. I believe (but I could be wrong) that MPTCP would allow a router that has multiple data-plane circuits to (pre-)establish those flows and then quickly switch to them. If all data-plane flows fail, then it might suspend traffic. I think that there is some advantage to starting the connection on the ACP, because: a) no TCP SYN listener on the data-plane interface(s) reduces attack surface (assuming NOC->router initialized connections, but the same argument applies to keeping the NOC devices isolated) b) the IP addresses of the router on the data-plane might be hard to know in advance, being subject to routing algorithms and address assignment ASAs. Also some interfaces might exist only with LL addresses until the need to grow a GUA occurs. The ACP addresses are essentially locked down by being embedded in certificate DNs. (see the ACP draft). That also means that a TLS connection to the router will be validatable by the router's domain certificate, while the (stable? temporary?) address assigned on the dataplane interfaces will not. So that's what MPTCP gets us: the ability to start on the ACP, do security, and then move the bulk traffic to another place. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpzMuwACgkQgItw+93Q 3WWRGAgArbykWtTKcDJ4cjagsV9tRzHMTgDuJgssfkZzHWHf2DiR8hXIiAOUuDPk 4vD+MviYBsObVwUM0vMki18VC8YXxu3qwygjMqhcNi54RmhkirbwAzr04Op30lmA /iLICqnQMyay8cXMA3b9TCYUNeW/2fgukHS4Yj6H9pmOS5EapvcDhS4B0kBxDEc1 lKkX1FtteHpCIQtcHiVDiO6UFg6l035PXNYMoIUhrX91g8AmZPqv3ciEPLwTGjMy 0eQQSli4fM6Qb2ySsew29yjdRSUOpgzahMyNuC8H+Dm2e+BLiLtVDPghzpiof4bU N0qUtVi0FHHvo+gZt6nbD8g1ebNp2A== =WkkI -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 1 08:21:48 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3F012EB4A for ; Thu, 1 Feb 2018 08:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 utRqnp-erWNg for ; Thu, 1 Feb 2018 08:21:45 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293DD12EAA3 for ; Thu, 1 Feb 2018 08:21:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=ndL3VssU9hBSsO0styXPGFZclzoOHyGQ/N/I16D1qH8hDK87nDxLwCfqu5ExegGjhkxZLXoQsI6oLoCzUxxUFl6O9UJ/QefcTmjfBk+czhAsLPNsJAVI6DNnqOUTJzgjYG75m7gnkFxmub4pWlWVcbaSFNbnrcoZK26TTwLV29c=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 26431 invoked from network); 1 Feb 2018 17:15:00 +0100 Received: from mue-88-130-61-026.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.26) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Feb 2018 17:15:00 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <16471.1517499116@obiwan.sandelman.ca> Date: Thu, 1 Feb 2018 17:14:58 +0100 Cc: Toerless Eckert , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180201161500.26421.42694@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 16:21:46 -0000 Hi Michael, see below. > Am 01.02.2018 um 16:31 schrieb Michael Richardson : >=20 >=20 > Mirja Kuehlewind (IETF) wrote: >> Why does your case 2 need an MPTCP connection instead of just opening = a >> second separate TCP data plan connection (that of course fails when = it >> fails..)? >=20 > I think the idea is that there is some long running connection; for = instance > a log flow or a mirror port flow. Or maybe even an SDN control = connection. >=20 The case 2 I=E2=80=99ve been referring to is that: "2) Connections for non-urgent bulk transers (for example most routine=20= firmware updates or cached log collection) may use a policy where the connection is made to fail when the data-plane fails or have transfers suspend until another data-plane subflow can successfully be built. This avoids over-taxing the ACP when the data plane = fails.=E2=80=9C I think for non-urgent bulk transfers it would be no problem to open a = new TCP connection, send the data, and close it again. > I believe (but I could be wrong) that MPTCP would allow a router that = has > multiple data-plane circuits to (pre-)establish those flows and then = quickly > switch to them. =20 You can also pre-establish normal non-MPTCP connections (and send = keep-alives); there is no difference or advantage when using MPTCP. = However, I don=E2=80=99t think you need that for non-urgent bulk = transfers. > If all data-plane flows fail, then it might suspend > traffic. That will not happen with MPTCP; it will fail back to use the ACP = connection (if there is a subflow for it). >=20 > I think that there is some advantage to starting the connection on the = ACP, > because: > a) no TCP SYN listener on the data-plane interface(s) reduces attack > surface (assuming NOC->router initialized connections, but the = same > argument applies to keeping the NOC devices isolated) Also with MPTCP you need a TCP SYN lister on the remote data-plane = interface because creating a MPTCP subflow means sending a TCP SYN with = an MPTCP option. >=20 > b) the IP addresses of the router on the data-plane might be hard to = know > in advance, being subject to routing algorithms and address = assignment > ASAs. Also some interfaces might exist only with LL addresses = until the > need to grow a GUA occurs. >=20 > The ACP addresses are essentially locked down by being embedded in > certificate DNs. (see the ACP draft). That also means that a TLS > connection to the router will be validatable by the router's = domain > certificate, while the (stable? temporary?) address assigned on = the dataplane > interfaces will not. What I=E2=80=99m basically proposing is that you use MPTCP for case 1 = (data that needs a fallback to the ACP connection) but for all other = transmission (that should be done only over one of the paths, either = data plane or ACP), you have additional plain TCP connections to use. = You can still add an interface to MPTCP to extract the IP address = information you need to start these additional connections. Mirja >=20 > So that's what MPTCP gets us: the ability to start on the ACP, do = security, > and then move the bulk traffic to another place. >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | network = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 From nobody Thu Feb 1 10:15:01 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAC612EC37; Thu, 1 Feb 2018 10:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 krerP7SxvpaU; Thu, 1 Feb 2018 10:14:56 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3617D12DA46; Thu, 1 Feb 2018 10:14:56 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id u21so11145549ywc.2; Thu, 01 Feb 2018 10:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=trohh44msQyxM6BshMwnAVWl1oO1UjwCiIMSL/4tMQc=; b=m7vncH2QswZbV+wLz2ZZ49SXrejFZbmdb6G5fTWgkCLbv6a07mPzRnMRimpKzIhx7f zCQE1tZWtnXQK/Z5hevEHOVSd7cumRQucQibIRrYAnFCq13zAxEXdepRr0f+Vw8jtwMV NyVws1pRm7Dif8rPJ34GmgY8y3gQwpSh69gze50WKL5NxyVmi8VDzinE3eoKxSUdlVVz p7bHoJ+ND0qLxNufDWBYiXpOOwsV+rgrvVmffKLKmyfxkJHwNK6UpXe+rL0hzdVMtPVj lEMYeCZFNWt0P3iCdztjwPgqLcp6dbCFTD9DDzhbkypYJPWkF11anXj7LJ24OLbZn8j6 zYoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=trohh44msQyxM6BshMwnAVWl1oO1UjwCiIMSL/4tMQc=; b=Tv/K7PkR5KrPJHY+tsiZ3DlNdeB/2ztXw0drWsdobXXdzHHNDIRVxbZrSd3/YBxqer t8xA4TRJv/U+mNtgOU+0QZfMh/vbev8/14Ojaj1twSOclKogy4MtOOW8ly41xiHuCFAX vxUNKWF7c2zfyJbwyTV3tLKW482sWMfnMzY5ZjnQs+7Bo/l39empK32bk/SCNyt67Vtn Spf3tIR6+1UbR9BbsebGEmli7vSvTh5e797g95vct9GTOJlWXwshTK08nv7ndV+TZj1R Vk1gi3n2sDdylITrWAFd/GBCupQ41Bc/4AxES/hxuMQemP0MH/84whQp3lEnRzQRgGha 2oCw== X-Gm-Message-State: AKwxyteCCNVM358hSWAzXAOfIhNRdNlXxl/gU2u2GNrZaJLBgbtgaKro MO3/n0TNl5Wsecm8KClQwE2XKK6NlkimhHZe1XQ= X-Google-Smtp-Source: AH8x226ISrzyP5Cofm66ZLqSgXn+H4w1qKnhgJ1tev+XMBxnzA4z5JyFEmgPnkXfY5+YVGT0HyPynK7C8IBHdxzRCZw= X-Received: by 10.37.19.6 with SMTP id 6mr13589222ybt.255.1517508895130; Thu, 01 Feb 2018 10:14:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.41.69 with HTTP; Thu, 1 Feb 2018 10:14:54 -0800 (PST) In-Reply-To: <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> From: Spencer Dawkins at IETF Date: Thu, 1 Feb 2018 12:14:54 -0600 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: Michael Richardson , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, Toerless Eckert , The IESG , Anima WG , Sheng Jiang Content-Type: multipart/alternative; boundary="001a113e5346a3489105642a92fe" Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:14:59 -0000 --001a113e5346a3489105642a92fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is Mirja's Discuss thread, and MPTCP is her working group, and she knows MPTCP better than I do, but I'm confused about one thing, as I'm reading this discussion ... On Thu, Feb 1, 2018 at 10:14 AM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Michael, > > see below. > > > Am 01.02.2018 um 16:31 schrieb Michael Richardson : > > > > > > Mirja Kuehlewind (IETF) wrote: > >> Why does your case 2 need an MPTCP connection instead of just opening = a > >> second separate TCP data plan connection (that of course fails when it > >> fails..)? > > > > I think the idea is that there is some long running connection; for > instance > > a log flow or a mirror port flow. Or maybe even an SDN control > connection. > > > > The case 2 I=E2=80=99ve been referring to is that: > > "2) Connections for non-urgent bulk transers (for example most routine > firmware updates or cached log collection) may use a policy where > the connection is made to fail when the data-plane fails or have > transfers suspend until another data-plane subflow can successfully > be built. This avoids over-taxing the ACP when the data plane fails.=E2= =80=9C > > I think for non-urgent bulk transfers it would be no problem to open a ne= w > TCP connection, send the data, and close it again. > > > > I believe (but I could be wrong) that MPTCP would allow a router that h= as > > multiple data-plane circuits to (pre-)establish those flows and then > quickly > > switch to them. > > You can also pre-establish normal non-MPTCP connections (and send > keep-alives); there is no difference or advantage when using MPTCP. > However, I don=E2=80=99t think you need that for non-urgent bulk transfer= s. > If I'm understanding the discussion, the desire is to use MPTCP to handle failover to another pre-established flow quickly, and Mirja's point is that normal MPTCP would just use both flows - so, not actually failing over, but if you provision for each flow to carry all your traffic, which you would have to do in order to handle failover anyway, I'm not sure why it's bad to let MPTCP do what it would do normally, and load-share across overprovisioned paths. Is that the discussion people think they're having? Thanks, Spencer, the irresponsible AD, in this case ... > > If all data-plane flows fail, then it might suspend > > traffic. > > That will not happen with MPTCP; it will fail back to use the ACP > connection (if there is a subflow for it). > > > > > I think that there is some advantage to starting the connection on the > ACP, > > because: > > a) no TCP SYN listener on the data-plane interface(s) reduces attack > > surface (assuming NOC->router initialized connections, but the same > > argument applies to keeping the NOC devices isolated) > > Also with MPTCP you need a TCP SYN lister on the remote data-plane > interface because creating a MPTCP subflow means sending a TCP SYN with a= n > MPTCP option. > > > > > > b) the IP addresses of the router on the data-plane might be hard to > know > > in advance, being subject to routing algorithms and address > assignment > > ASAs. Also some interfaces might exist only with LL addresses until > the > > need to grow a GUA occurs. > > > > The ACP addresses are essentially locked down by being embedded in > > certificate DNs. (see the ACP draft). That also means that a TLS > > connection to the router will be validatable by the router's domain > > certificate, while the (stable? temporary?) address assigned on the > dataplane > > interfaces will not. > > What I=E2=80=99m basically proposing is that you use MPTCP for case 1 (da= ta that > needs a fallback to the ACP connection) but for all other transmission > (that should be done only over one of the paths, either data plane or ACP= ), > you have additional plain TCP connections to use. You can still add an > interface to MPTCP to extract the IP address information you need to star= t > these additional connections. > > Mirja > > > > > So that's what MPTCP gets us: the ability to start on the ACP, do > security, > > and then move the bulk traffic to another place. > > > > > -- > > ] Never tell me the odds! | ipv6 mesh > networks [ > > ] Michael Richardson, Sandelman Software Works | network > architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > --001a113e5346a3489105642a92fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is Mirja's Discuss thread, and MPTCP is her worki= ng group, and she knows MPTCP better than I do, but I'm confused about = one thing, as I'm reading this discussion ...

On Thu, Feb 1, 2018 at 10:14 AM, Mirja Kueh= lewind (IETF) <ietf@kuehlewind.net> wrote:
Hi Michael,

see below.

> Am 01.02.2018 um 16:31 schrieb Michael Richardson <mcr@sandelman.ca>:
>
>
> Mirja Kuehlewind (IETF) <iet= f@kuehlewind.net> wrote:
>> Why does your case 2 need an MPTCP connection instead of just open= ing a
>> second separate TCP data plan connection (that of course fails whe= n it
>> fails..)?
>
> I think the idea is that there is some long running connection; for in= stance
> a log flow or a mirror port flow.=C2=A0 Or maybe even an SDN control c= onnection.
>

The case 2 I=E2=80=99ve been referring to is that:

"2) Connections for non-urgent bulk transers (for example most routine=
=C2=A0 firmware updates or cached log collection) may use a policy where =C2=A0 the connection is made to fail when the data-plane fails or have
=C2=A0 transfers suspend until another data-plane subflow can successfully<= br> =C2=A0 be built. This avoids over-taxing the ACP when the data plane= fails.=E2=80=9C

I think for non-urgent bulk transfers it would be no problem to open a new = TCP connection, send the data, and close it again.


> I believe (but I could be wrong) that MPTCP would allow a router that = has
> multiple data-plane circuits to (pre-)establish those flows and then q= uickly
> switch to them.

You can also pre-establish normal non-MPTCP connections (and send ke= ep-alives); there is no difference or advantage when using MPTCP. However, = I don=E2=80=99t think you need that for non-urgent bulk transfers.

If I'm understanding the discussion, the de= sire is to use MPTCP to handle failover to another pre-established flow qui= ckly, and Mirja's point is that normal MPTCP would just use both flows = - so, not actually failing over, but if you provision for each flow to carr= y all your traffic, which you would have to do in order to handle failover = anyway, I'm not sure why it's bad to let MPTCP do what it would do = normally, and load-share across overprovisioned paths.

=
Is that the discussion people think they're having?=C2=A0

T= hanks,

Spencer, the irresponsible AD, in this case= ...
=C2=A0
= > If all data-plane flows fail, then it might suspend
> traffic.

That will not happen with MPTCP; it will fail back to use the ACP co= nnection (if there is a subflow for it).

>
> I think that there is some advantage to starting the connection on the= ACP,
> because:
>=C2=A0 a) no TCP SYN listener on the data-plane interface(s) reduces at= tack
>=C2=A0 =C2=A0 =C2=A0surface (assuming NOC->router initialized connec= tions, but the same
>=C2=A0 =C2=A0 =C2=A0argument applies to keeping the NOC devices isolate= d)

Also with MPTCP you need a TCP SYN lister on the remote data-plane i= nterface because creating a MPTCP subflow means sending a TCP SYN with an M= PTCP option.


>
>=C2=A0 b) the IP addresses of the router on the data-plane might be har= d to know
>=C2=A0 =C2=A0 =C2=A0in advance, being subject to routing algorithms and= address assignment
>=C2=A0 =C2=A0 =C2=A0ASAs. Also some interfaces might exist only with LL= addresses until the
>=C2=A0 =C2=A0 =C2=A0need to grow a GUA occurs.
>
>=C2=A0 =C2=A0 =C2=A0The ACP addresses are essentially locked down by be= ing embedded in
>=C2=A0 =C2=A0 =C2=A0certificate DNs. (see the ACP draft).=C2=A0 That al= so means that a TLS
>=C2=A0 =C2=A0 =C2=A0connection to the router will be validatable by the= router's domain
>=C2=A0 =C2=A0 =C2=A0certificate, while the (stable? temporary?) address= assigned on the dataplane
>=C2=A0 =C2=A0 =C2=A0interfaces will not.

What I=E2=80=99m basically proposing is that you use MPTCP for case = 1 (data that needs a fallback to the ACP connection) but for all other tran= smission (that should be done only over one of the paths, either data plane= or ACP), you have additional plain TCP connections to use. You can still a= dd an interface to MPTCP to extract the IP address information you need to = start these additional connections.

Mirja

>
> So that's what MPTCP gets us: the ability to start on the ACP, do = security,
> and then move the bulk traffic to another place.

>
> --
> ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me = the odds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ip= v6 mesh networks [
> ]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | network architect=C2=A0 [
> ]=C2=A0 =C2=A0 =C2=A0mcr@sandelman= .ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [
>


--001a113e5346a3489105642a92fe-- From nobody Thu Feb 1 10:22:26 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A714912EC47; Thu, 1 Feb 2018 10:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 c-Jm-XwPWyAm; Thu, 1 Feb 2018 10:22:22 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9E412EC40; Thu, 1 Feb 2018 10:22:20 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C6F1258C4BE; Thu, 1 Feb 2018 19:22:14 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A6040B0D923; Thu, 1 Feb 2018 19:22:14 +0100 (CET) Date: Thu, 1 Feb 2018 19:22:14 +0100 From: Toerless Eckert To: "Mirja Kuehlewind (IETF)" Cc: draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, Michael Richardson , The IESG , anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180201182214.GA2643@faui40p.informatik.uni-erlangen.de> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:22:26 -0000 Inline On Thu, Feb 01, 2018 at 02:42:29PM +0100, Mirja Kuehlewind (IETF) wrote: > HI Toerless, > > thanks so much for these edits. Unfortunately I have one more question. And sorry again for the delay. > > Why does your case 2 need an MPTCP connection instead of just opening a second separate TCP data plan connection (that of course fails when it fails..)? How do the peers know each others data plane address ? => draft text: (Only) the GACP address of GACP devices could to be put into DNS. When MPTCP builds the first subflow across the GACP, it exchanges the data-plane address. Without MPTCP i need to reinvent a good part of it and i can not imagine how i would get anyone interested to do that signaling part in a standardized fashion given how MPTCP does exist. -> Build TCP connection to responder GACP address. -> Signal with responder the data-plane address - in a fashion that would be backward compatible with a legacy responder/initiator that doesn't speak this extension. I wouldn't even know how i could do this via TCP payload. Must be at the transport level. -> Build TCP connection via data-plane addresses. -> Use policy and/or new signaling to decide to prefer using that connection. ... -> Data-plane connection fails. -> need some scheme to figure out how to rebuild. if - if and when available. Including some exponential backoff trying to reconnect. Or more likely in our case the data-plane address was unconfigured and gets reconfigured maybe differently. (some SDN controller doing some change of addressing to the data-plane), So when one side signals to the other side that the data-plane address is gone, then no connection probing is necessary. And when it is available again, maybe different one, gets signalled, and we're building the connection again and using it. Cheers Toerless > > Mirja > > > > Am 27.01.2018 um 00:06 schrieb Toerless Eckert : > > > > On Fri, Jan 26, 2018 at 11:43:08AM +0100, Mirja Kuehlewind (IETF) wrote: > >> Hi Toerless, > >> > >> sorry for my late reply but I spend only limited time on AD stuff on the telechat agenda was crowded this week. > > > > Thanks for all the hard work! > > > >> Okay that is fine. I mainly wanted to double-check as that was still not fully clear from the provided text. Can you maybe propose a slight rewording that explicitly say that there is this backup while using the word ???only??? above in the cited text seems to indicated differently. > > > > I wanted to take the full extend of your feedback into account, so > > rewrote the paragraph in question maybe a bit more than slightly > > (couldn't figure out a sane "slightly" ;-): > > > > - Moved up the last sentence about per-connection policy up front, > > so the examples are more logical scoped. > > > > - Made the examples into three separate bullet points > > and expanded them to hopefully eliminate the misunderstanding > > wrt to backup. > > > > - Not only mentioning the fall back (backup), but also added > > desirable behavior under recovery of preferred subflow path. > > (important for both 1) and 2). > > > > - explaining in bullet point 3) how this one is actually a > > simple TCP connection (As you pointed out). > > (whereas 1) and 2) rely on the MPTCP benefit of two subflows and address signaling). > > > > -09 uploaded with this fix as well as fix for Yohi's comment. > > > > Diff: > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-09.txt > > > > Here is the changed paragraph: > > > > The above described behavior/policy for MPTCP must be controllable by > > applications or libraries acting on behalf of applications. APIs > > and/or data models for this control need to be defined. It should be > > sufficient to make these policies work on a per connection > > basis, and not change during the lifetime of a connection for > > different data items: > > > > 1) The policy for likely most connections would be to use the data-plane > > subflow and fall back using the ACP subflow when the data-plane fails. > > This could be the default. It reduces load on the ACP but would continue > > to run connection traffic at likely reduced throughput when the > > data-plane fails. Ideally such connections would also revert back to > > using a data-plane subflow once its connectivity recovers. > > > > 2) Connections for non-urgent bulk transers (for example most routine > > firmware updates or cached log collection) may use a policy where > > the connection is made to fail when the data-plane fails or have > > transfers suspend until another data-plane subflow can successfully > > be built. This avoids over-taxing the ACP when the data plane fails. > > > > 3) Connections for critical network configuration change operations > > known to impact the data-plane might want to only use the ACP and > > could therefore map to a (non-MP)TCP connection. > > > > Cheers > > Toerless > > > > > > m 22.01.2018 um 19:42 schrieb Toerless Eckert : > >>> > >>> > >>> Thanks, Mirja. Inline. > >>> > >>> On Mon, Jan 22, 2018 at 01:37:58PM +0100, Mirja Kuehlewind (IETF) wrote: > >>>> Hi Toerless, > >>>> > >>>> thanks a lot for the updated text. I still have one little point I would like to discuss a bit further on this text: > >>>> > >>>> "The above described behavior/policy for MPTCP must be controllable by > >>>> applications or libraries acting on behalf of applications. APIs > >>>> and/or data models for this control need to be defined. As outlined > >>>> above, applications for example may choose to only perform transfers > >>>> if the data-plane is actually available because of performance > >>>> limitations of the GACP, so the application needs to be made aware if > >>>> the setup of the data-plane subflow fails. Or transfers may want to > >>>> only use the GACP because the connection performs configuration > >>>> changes that are likely known to bring down the data-plane. It > >>>> should be sufficient to make these policies work on a per connection > >>>> basis, and not change during the lifetime of a connection for > >>>> different data items.??? > >>>> > >>>> > >>>> When you say that there is a need for an application to send data only on one path, today that???s not possible with MPTCP as you may fallback to the other path silently during the transmission. Yes, of course this could be changed and an extended interface could indicate this. > >>> > >>>> > >>>> So my question is still what the ???only??? really means in this text. If you???d like to just indicate a preference that might be okay. If you really want to rule out the possibility to fallback to the other path, then I don???t think you need MPTCP and two separate TCP connections would be the better option. > >>>> > >>>> Does that make sense to you? > >>> > >>> Not really, the goal is always to leverage existing MPTCP signaling of > >>> addresses, indicating backup for flows, etc. I think two TCP flows would > >>> never be better: > >> > >> Okay that is fine. I mainly wanted to double-check as that was still not fully clear from the provided text. Can you maybe propose a slight rewording that explicitly say that there is this backup while using the word ???only??? above in the cited text seems to indicated differently. > >> > >> Thanks! > >> > >>> > >>> The GACP address is the primary identifier of a device known in DNS. > >>> Data-Plane addresses can change over time subject to operator configuration > >>> and could also pose more of a security issue to be in DNS (GACP is isolated > >>> network). > >>> > >>> GACP performance may be quite low because some network device may route/forward > >>> it in software. data-plane routing/forwarding is expected to be fast/HW-accelerated. > >>> > >>> With MPTCP as suggested this gives for example: > >>> Initial subflow must use GACP because thats the only "known/stable address" in DNS > >>> Then MPTCP signaling is used to indicate mutually the data-plane addresses > >>> and make GACP subflow backup. > >>> Then you transfer lets say a few Gigabyte of data (e.g.: firmware update) which > >>> goes over data-plane. > >>> Then some uncorrelated error happens and data-plane fails. This particular app > >>> should then fail because it would just slow down to insufferable slow across > >>> GACP and would overload software forwarding in GACP. > >>> > >>> In another application connection, fallback to GACP subflow for data if dat-plane > >>> subflow fails is fine, but you would only prefer data-plane for performance. > >>> > >>> You could consider the GACP potential software only forwarding like a very high > >>> cost of using it while data-plane is free. > >>> > >>> If i would just use 2 * TCP instead of MPTCP i would have to reinvent a lot of > >>> MPTCP to get the address signaling etc. Right ? > >>> > >>> Cheers > >>> Toerless > >>>> > >>>> Mirja > >>>> > >>>> > >>>> > >>>>> Am 17.01.2018 um 03:36 schrieb Toerless Eckert : > >>>>> > >>>>> Mirja, Yoshifumi > >>>>> > >>>>> I just posted -08: https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt > >>>>> > >>>>> I have reworked the MPTCP text based on your threads feedback with > >>>>> the intention to fix errors and have it answer the questions/concerns raised, > >>>>> but without otherwise changing the scope of it: > >>>>> > >>>>> - What are they key features making MPTCP interesting > >>>>> - How could it be used to solve the stable-connectivity issue > >>>>> - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK > >>>>> beyond the scope of this document > >>>>> - Describe the areas of specification work required > >>>>> - API/policy, control by apps > >>>>> - dealing with dual VRF addresses > >>>>> > >>>>> Please check diff in this URL (not complete diff of -08, just fix for your discuss/comment): > >>>>> > >>>>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt > >>>>> > >>>>> I hope this resolves your DISCUSS/comments. > >>>>> > >>>>> Note that the term ACP was changed in the doc to GACP based on resolving Alvaros discus. See: > >>>>> > >>>>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt > >>>>> > >>>>> Thank you > >>>>> Toerless > >>>>> > >>>>> On Thu, Jan 11, 2018 at 03:42:53PM +0100, Mirja K?hlewind wrote: > >>>>>> Hi Toerless, > >>>>>> > >>>>>> the point I'm wondering about is your point (b) below. Yes, you can > >>>>>> set the ACP subflow to backup but that would still mean that if the > >>>>>> other link fails, it would automatically switch over to the ACP > >>>>>> subflow (without exposing this to the upper layer). Is that what you > >>>>>> want? Because my understanding was rather that there are cases where > >>>>>> you'd probably would like to know over which link the OAM packets > >>>>>> where actually sent...? > >>>>>> > >>>>>> Mirja > >>>>>> > >>>>>> On 08.01.2018 22:06, Toerless Eckert wrote: > >>>>>>> Thanks, Mirja > >>>>>>> > >>>>>>> (a) If the systems socket API does not transparently make TCP sockets > >>>>>>> to use MPTCP, then you would want a shim library. According to > >>>>>>> draft-hesmans-mptcp-socket, this is be the case on Apple (iOS). > >>>>>>> > >>>>>>> (b) Making the ACP subflow not carry traffic after establishing the > >>>>>>> data plane subflow should easily be possible possible by setting its MP_PRIO > >>>>>>> to backup. > >>>>>>> > >>>>>>> (c) How exactly to specify or implement the desired policy of only > >>>>>>> establishing a subflow between the ACP addresses and the data plane addresses > >>>>>>> (but not full-mesh) seem to be a subject for further spec work. It could > >>>>>>> be defined as a specific in-MPTCP policy, or it could be done via a shim > >>>>>>> library (orthogonal to (a)). draft-hesmans-mptcp-socket might be sufficient. > >>>>>>> > >>>>>>> But in general: i would like for this (informational!) draft to just motivate > >>>>>>> the concept and not specify the solution: MPTCP would be a simple way to > >>>>>>> make "TCP" applications automatically "upgrade" from ACP to a data-plane path > >>>>>>> and switch back when data-plane fails... because MP-TCP can signal the > >>>>>>> additional data-plane addresses, establish transparently another subflow and switch > >>>>>>> traffic between the subflows - all by using the right shim-library+API or > >>>>>>> in-MP-TCP address/subflow policies - and the ability to establish subflows > >>>>>>> across two VRFs. > >>>>>>> > >>>>>>> Cheers > >>>>>>> Toerless > >>>>>>> > >>>>>>> On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind (IETF) wrote: > >>>>>>>>>>> Suggested replacement text last two paragraphs of 2.1.5: > >>>>>>>>> A (shim) library for aplications maps TCP connections to MPTCP without the applications having to be aware of it. > >>>>>>>> It???s not the (shim) library/policy framework that opens/maps the TCP connection. MPTCP itself opens eventually multiple connections but exposes only one connection to the layer above. That means everything above MPTCP does not have any real control about which data is send over which connection. > >>>>>>>> > >>>>>>>> A policy shim layer could only implement rules about which new subflows should be established when and what the priority is over which subflow data should be sent but it generally does not control which data is send of which flow. You can???t say I want this data to be sent over subflow one and this data to be sent over sub flow two. > >>>>>>>> > >>>>>>>> I think what you want is actually a view on the different TCP connections and you try to use MPTCP only for announcing the other IP address but that is not what MPTCP meant to be. > >>>>>>>> > >>>>>>>> Mirja > >>>>>>>> > >>>>>>>> > >>>>>>>>> Names in DNS use only the ACP IPv6 addresses of network devices. Thererefore, the initial MPTCP subflow will use the ACP. After it is operating, the shim libraries on both ends add their data-plane address (MPTCP ADD_ADDR) and attempt to build a new subflow between those addresses. If that (data plane) subflow is successfully built, the shim libraries could shift all traffic over this subflow which should be forwarded hardware accelerated by the network - and use the ACP subflow across the ACP solely for signaling - beause it is most resilient against failure. > >>>>>>>>> > >>>>>>>>> This MPTCP approach is only an outline and would need to be fully speficied for interoperable implementations. It may also require extensions to MP-TCP. This mechanism must not be used without providing for encryption of subflows not running across the ACP. > >>>>>>>>> > >>>>>>>>>>> Brian: ... can not use capital MUST NOT in an information draft (i think) > >>>>>>>>>>> > >>>>>>>>> Cheers > >>>>>>>>> Toerless > >>>>>>>>> > >>>>>>>>> On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) wrote: > >>>>>>>>>> Hi Micheal, > >>>>>>>>>> > >>>>>>>>>> to clarify one part below: > >>>>>>>>>> > >>>>>>>>>>> Am 05.01.2018 um 23:30 schrieb Michael Richardson : > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Mirja Kühlewind wrote: > >>>>>>>>>>>> "DNS naming is set up to provide the ACP IPv6 address of network > >>>>>>>>>>>> devices. Unbeknownst to the application, MPTCP is used. MPTCP > >>>>>>>>>>>> mutually discovers between the NOC and network device the data-plane > >>>>>>>>>>>> address and caries all traffic across it when that MPTCP subflow > >>>>>>>>>>>> across the data-plane can be built." > >>>>>>>>>>> Section 2.1.5 is discussion, it discusses ways in which the > >>>>>>>>>>> anticipated low performance (compared to what the box might do with its > >>>>>>>>>>> hardware accelerated forwarding). > >>>>>>>>>>> > >>>>>>>>>>> If we have an application that needs the bandwidth of the native hardware, > >>>>>>>>>>> the connection can be initated over the ACP (that's what would be in DNS). > >>>>>>>>>>> One presumes that an MPTCP layer could then enumerate the available IPs at > >>>>>>>>>>> each end and then start off additional flows on the other destinations. > >>>>>>>>>> MPTCP adda an additional TCP flow but for the application that still looks like one flow. As I said I???m not sure if that is what you want. > >>>>>>>>>> > >>>>>>>>>> Mirja > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> The application would have to include application security, since it would > >>>>>>>>>>> not be protected by the ACP. > >>>>>>>>>>> > >>>>>>>>>>> Perhaps MPTCP doesn't work this way. > >>>>>>>>>>> > >>>>>>>>>>>> However, I'm actually uncertain how this is supposed to work and what > >>>>>>>>>>>> "Unbeknownst to the application" should mean. If another address should be > >>>>>>>>>>>> signaled to the other host, this needs to be indicated by the application or at > >>>>>>>>>>>> least some kind of policy framework above MPTCP. Also MPTCP will by default use > >>>>>>>>>>>> both paths simultaneously while still looking like one connection to the > >>>>>>>>>>>> application, meaning the application has no control which path is used for > >>>>>>>>>>>> which traffic. I guess you can open a second subflow and then configure the > >>>>>>>>>>>> first subflow as backup path but I'm not sure if that's what you want (given > >>>>>>>>>>>> the application/policy framework will still not know which path is used)..? > >>>>>>>>>>>> Please provide more information about what the expected usage scenario is here. > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Michael Richardson , Sandelman Software Works > >>>>>>>>>>> -= IPv6 IoT consulting =- > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Anima mailing list > >>>>>>>>>> Anima@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>>>>>> -- > >>>>>>>>> --- > >>>>>>>>> tte@cs.fau.de > >>>>> > >>>>> -- > >>>>> --- > >>>>> tte@cs.fau.de > > > > -- > > --- > > tte@cs.fau.de > > -- --- tte@cs.fau.de From nobody Thu Feb 1 10:34:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8D912EC40; Thu, 1 Feb 2018 10:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 T8bhZzi140XD; Thu, 1 Feb 2018 10:34:52 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0829212EBD1; Thu, 1 Feb 2018 10:34:52 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A386458C4BB; Thu, 1 Feb 2018 19:34:47 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 89C55B0D923; Thu, 1 Feb 2018 19:34:47 +0100 (CET) Date: Thu, 1 Feb 2018 19:34:47 +0100 From: Toerless Eckert To: Spencer Dawkins at IETF Cc: "Mirja Kuehlewind (IETF)" , Michael Richardson , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , Anima WG , Sheng Jiang Message-ID: <20180201183447.GB2643@faui40p.informatik.uni-erlangen.de> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:34:54 -0000 On Thu, Feb 01, 2018 at 12:14:54PM -0600, Spencer Dawkins at IETF wrote: > This is Mirja's Discuss thread, and MPTCP is her working group, and she > knows MPTCP better than I do, but I'm confused about one thing, as I'm > reading this discussion ... > [...] > If I'm understanding the discussion, the desire is to use MPTCP to handle > failover to another pre-established flow quickly, and Mirja's point is that > normal MPTCP would just use both flows - so, not actually failing over, but > if you provision for each flow to carry all your traffic, which you would > have to do in order to handle failover anyway, I'm not sure why it's bad to > let MPTCP do what it would do normally, and load-share across > overprovisioned paths. I have not seen Mirja rejecting the statement of the draft that we can make one path a backup (not written out in the draft: via MPTCP MP_PRIO). > Is that the discussion people think they're having? I think Mirja is trying to do due diligence that the problem can not be solved with just TCP, and i may not have been doing textually a good enough job highlighting how the need of an MPTCP like signaling for additional addresses (data-plane addresses) is necessary when you only have the GACP address in DNS but actually prefer to use the data-plane (see -09 draft version, MPTCP options 1), 2)). Cheers Toerless > Thanks, > > Spencer, the irresponsible AD, in this case ... > > > > > If all data-plane flows fail, then it might suspend > > > traffic. > > > > That will not happen with MPTCP; it will fail back to use the ACP > > connection (if there is a subflow for it). > > > > > > > > I think that there is some advantage to starting the connection on the > > ACP, > > > because: > > > a) no TCP SYN listener on the data-plane interface(s) reduces attack > > > surface (assuming NOC->router initialized connections, but the same > > > argument applies to keeping the NOC devices isolated) > > > > Also with MPTCP you need a TCP SYN lister on the remote data-plane > > interface because creating a MPTCP subflow means sending a TCP SYN with an > > MPTCP option. > > > > > > > > > > b) the IP addresses of the router on the data-plane might be hard to > > know > > > in advance, being subject to routing algorithms and address > > assignment > > > ASAs. Also some interfaces might exist only with LL addresses until > > the > > > need to grow a GUA occurs. > > > > > > The ACP addresses are essentially locked down by being embedded in > > > certificate DNs. (see the ACP draft). That also means that a TLS > > > connection to the router will be validatable by the router's domain > > > certificate, while the (stable? temporary?) address assigned on the > > dataplane > > > interfaces will not. > > > > What I???m basically proposing is that you use MPTCP for case 1 (data that > > needs a fallback to the ACP connection) but for all other transmission > > (that should be done only over one of the paths, either data plane or ACP), > > you have additional plain TCP connections to use. You can still add an > > interface to MPTCP to extract the IP address information you need to start > > these additional connections. > > > > Mirja > > > > > > > > So that's what MPTCP gets us: the ability to start on the ACP, do > > security, > > > and then move the bulk traffic to another place. > > > > > > > > -- > > > ] Never tell me the odds! | ipv6 mesh > > networks [ > > > ] Michael Richardson, Sandelman Software Works | network > > architect [ > > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > > rails [ > > > > > > > -- --- tte@cs.fau.de From nobody Thu Feb 1 10:46:21 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1858C12025C; Thu, 1 Feb 2018 10:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YGOAt9tEA4z0; Thu, 1 Feb 2018 10:46:16 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D49A12DA4E; Thu, 1 Feb 2018 10:46:16 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id b16so8402247ywh.12; Thu, 01 Feb 2018 10:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YdWXS3wlyazPaza6e5RDlNlUDJ8UhkRI3SbVgYCtttM=; b=CovguGI5JH5/cDFHnWwwu8zQvzso2pWRtvnv6VMqa8MHoC7wm2PGMPZ/B06TFQayZ8 VNW7mSQ3QJ2wcE1TKYw9Ivhw9OIdqazcuYl5LOzE2tGcKsfSQ/e7LlV8GutiO2yueD0a 1qLlDui7VVaVd7s6yg39HjqVg/Q66/jkXJyeUMnQLSvXsdzNNN1hf0Hs74OZuN40opr7 eIJygclLIqsyCKPuVmdvXy/qFXQ2AQMPy9YSltCmJgVVEquD0ElxlzBPBPueuZ1rSqZB EQ01O64sBr1tJ1IgBoEmv0TIGcFtNWK7xZv9KLz+ldxetn87er71EANqgbNV3btR5f+C SuTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YdWXS3wlyazPaza6e5RDlNlUDJ8UhkRI3SbVgYCtttM=; b=YzOhXSTv+l1OrF7C6JmnE4s/mJ5NsZfevkq4iGO9Ok8YR5TdCZMhU6kuVFeEcEa2Ws v1um73+aabQMefnN8jro1YWuTQQo2HCuLBRjLXPOrc0+ZAPmZA8jjpXx9aIxtgyB5JTj k6qZZFAAZ5afPf97F0KatbDGTlOZ7Z5uTAnRzLtaWEeqlJ8RSSirRhM7Q6E/JoF3+V1U WADnE2pHqKzStSh1rbXZFYbEncu0L7rjgFUMs5WZASUwJ2g8aBiPMs+eeoYr2iPCc3JS K28LulAg8jE27TSGaOCgKzzXtOBcxbc6+9r6dR1V6iSJRZgWXPECt7LFGYhyB0J06Ilp arUQ== X-Gm-Message-State: AKwxyteJo3awhn+cnOSwsuzzSlrEwfNv30CHoficCvzZgjBxJlsZAAie jfiY44YgnIk8uQfGWiXkGEuAlfRQtFjV2rNNOPM= X-Google-Smtp-Source: AH8x226HKETb8D82e7XhI9ryeF6lhN5LWZT7CQhicUOyHd7srbGP3A8iG9cm9BOAl9Oz+avQ854+vqV6Xy/+MnbOAEI= X-Received: by 10.129.78.14 with SMTP id c14mr25406153ywb.109.1517510774969; Thu, 01 Feb 2018 10:46:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.41.69 with HTTP; Thu, 1 Feb 2018 10:46:14 -0800 (PST) In-Reply-To: <20180201183447.GB2643@faui40p.informatik.uni-erlangen.de> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> <20180201183447.GB2643@faui40p.informatik.uni-erlangen.de> From: Spencer Dawkins at IETF Date: Thu, 1 Feb 2018 12:46:14 -0600 Message-ID: To: Toerless Eckert Cc: "Mirja Kuehlewind (IETF)" , Michael Richardson , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , Anima WG , Sheng Jiang Content-Type: multipart/alternative; boundary="001a114d7d3eaf5c3705642b02df" Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:46:19 -0000 --001a114d7d3eaf5c3705642b02df Content-Type: text/plain; charset="UTF-8" Hi, Toerless, On Thu, Feb 1, 2018 at 12:34 PM, Toerless Eckert wrote: > On Thu, Feb 01, 2018 at 12:14:54PM -0600, Spencer Dawkins at IETF wrote: > > This is Mirja's Discuss thread, and MPTCP is her working group, and she > > knows MPTCP better than I do, but I'm confused about one thing, as I'm > > reading this discussion ... > > > [...] > > > If I'm understanding the discussion, the desire is to use MPTCP to handle > > failover to another pre-established flow quickly, and Mirja's point is > that > > normal MPTCP would just use both flows - so, not actually failing over, > but > > if you provision for each flow to carry all your traffic, which you would > > have to do in order to handle failover anyway, I'm not sure why it's bad > to > > let MPTCP do what it would do normally, and load-share across > > overprovisioned paths. > > I have not seen Mirja rejecting the statement of the draft that we > can make one path a backup (not written out in the draft: via MPTCP > MP_PRIO). > I'll let her follow up here. What I was asking about, was (see next) > > Is that the discussion people think they're having? > > I think Mirja is trying to do due diligence that the problem can not be > solved with just TCP, and i may not have been doing textually a good enough > job highlighting how the need of an MPTCP like signaling for additional > addresses (data-plane addresses) is necessary when you only have the > GACP address in DNS but actually prefer to use the data-plane (see -09 > draft version, MPTCP options 1), 2)). > Thanks, that's helpful. I do see the due diligence (she's a diligent AD), but I thought Mirja was (also?) concerned that the draft was assuming that MPTCP could be made to handle two paths in failover mode, when it actually doesn't work that way. Perhaps I was misreading (at least some of the conversation happened while I was in and out of China, and that never helps me do e-mail). But I'll let you two keep typing :-) Spencer > Cheers > Toerless > > > Thanks, > > > > Spencer, the irresponsible AD, in this case ... > > > > > > > > If all data-plane flows fail, then it might suspend > > > > traffic. > > > > > > That will not happen with MPTCP; it will fail back to use the ACP > > > connection (if there is a subflow for it). > > > > > > > > > > > I think that there is some advantage to starting the connection on > the > > > ACP, > > > > because: > > > > a) no TCP SYN listener on the data-plane interface(s) reduces attack > > > > surface (assuming NOC->router initialized connections, but the > same > > > > argument applies to keeping the NOC devices isolated) > > > > > > Also with MPTCP you need a TCP SYN lister on the remote data-plane > > > interface because creating a MPTCP subflow means sending a TCP SYN > with an > > > MPTCP option. > > > > > > > > > > > > > > b) the IP addresses of the router on the data-plane might be hard to > > > know > > > > in advance, being subject to routing algorithms and address > > > assignment > > > > ASAs. Also some interfaces might exist only with LL addresses > until > > > the > > > > need to grow a GUA occurs. > > > > > > > > The ACP addresses are essentially locked down by being embedded > in > > > > certificate DNs. (see the ACP draft). That also means that a TLS > > > > connection to the router will be validatable by the router's > domain > > > > certificate, while the (stable? temporary?) address assigned on > the > > > dataplane > > > > interfaces will not. > > > > > > What I???m basically proposing is that you use MPTCP for case 1 (data > that > > > needs a fallback to the ACP connection) but for all other transmission > > > (that should be done only over one of the paths, either data plane or > ACP), > > > you have additional plain TCP connections to use. You can still add an > > > interface to MPTCP to extract the IP address information you need to > start > > > these additional connections. > > > > > > Mirja > > > > > > > > > > > So that's what MPTCP gets us: the ability to start on the ACP, do > > > security, > > > > and then move the bulk traffic to another place. > > > > > > > > > > > -- > > > > ] Never tell me the odds! | ipv6 mesh > > > networks [ > > > > ] Michael Richardson, Sandelman Software Works | network > > > architect [ > > > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > > > rails [ > > > > > > > > > > > > -- > --- > tte@cs.fau.de > --001a114d7d3eaf5c3705642b02df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Toerless,

On Thu, Feb 1, 2018 at 12:34 PM, Toerless Eckert <tte@cs.fau.de> wrote:
On = Thu, Feb 01, 2018 at 12:14:54PM -0600, Spencer Dawkins at IETF wrote:
> This is Mirja's Discuss thread, and MPTCP is her working group, an= d she
> knows MPTCP better than I do, but I'm confused about one thing, as= I'm
> reading this discussion ...
>
[...]

> If I'm understanding the discussion, the desire is to use MPTCP to= handle
> failover to another pre-established flow quickly, and Mirja's poin= t is that
> normal MPTCP would just use both flows - so, not actually failing over= , but
> if you provision for each flow to carry all your traffic, which you wo= uld
> have to do in order to handle failover anyway, I'm not sure why it= 's bad to
> let MPTCP do what it would do normally, and load-share across
> overprovisioned paths.

I have not seen Mirja rejecting the statement of the draft that we can make one path a backup (not written out in the draft: via MPTCP MP_PRIO= ).

I'll let her follow up here. Wha= t I was asking about, was (see next)
=C2=A0
> Is that the discussion people think th= ey're having?

I think Mirja is trying to do due diligence that the problem can not= be
solved with just TCP, and i may not have been doing textually a good enough=
job highlighting how the need of an MPTCP like signaling for additional
addresses (data-plane addresses) is necessary when you only have the
GACP address in DNS but actually prefer to use the data-plane (see -09
draft version, MPTCP options 1), 2)).

T= hanks, that's helpful.=C2=A0

I do see the due = diligence (she's a diligent AD), but I thought Mirja was (also?) concer= ned that the draft was assuming that MPTCP could be made to handle two path= s in failover mode, when it actually doesn't work that way. Perhaps I w= as misreading (at least some of the conversation happened while I was in an= d out of China, and that never helps me do e-mail).

But I'll let you two keep typing :-)

Cheers
=C2=A0 =C2=A0 Toerless

> Thanks,
>
> Spencer, the irresponsible AD, in this case ...
>
>
> > > If all data-plane flows fail, then it might suspend
> > > traffic.
> >
> > That will not happen with MPTCP; it will fail back to use the ACP=
> > connection (if there is a subflow for it).
> >
> > >
> > > I think that there is some advantage to starting the connect= ion on the
> > ACP,
> > > because:
> > >=C2=A0 a) no TCP SYN listener on the data-plane interface(s) = reduces attack
> > >=C2=A0 =C2=A0 =C2=A0surface (assuming NOC->router initiali= zed connections, but the same
> > >=C2=A0 =C2=A0 =C2=A0argument applies to keeping the NOC devic= es isolated)
> >
> > Also with MPTCP you need a TCP SYN lister on the remote data-plan= e
> > interface because creating a MPTCP subflow means sending a TCP SY= N with an
> > MPTCP option.
> >
> >
> > >
> > >=C2=A0 b) the IP addresses of the router on the data-plane mi= ght be hard to
> > know
> > >=C2=A0 =C2=A0 =C2=A0in advance, being subject to routing algo= rithms and address
> > assignment
> > >=C2=A0 =C2=A0 =C2=A0ASAs. Also some interfaces might exist on= ly with LL addresses until
> > the
> > >=C2=A0 =C2=A0 =C2=A0need to grow a GUA occurs.
> > >
> > >=C2=A0 =C2=A0 =C2=A0The ACP addresses are essentially locked = down by being embedded in
> > >=C2=A0 =C2=A0 =C2=A0certificate DNs. (see the ACP draft).=C2= =A0 That also means that a TLS
> > >=C2=A0 =C2=A0 =C2=A0connection to the router will be validata= ble by the router's domain
> > >=C2=A0 =C2=A0 =C2=A0certificate, while the (stable? temporary= ?) address assigned on the
> > dataplane
> > >=C2=A0 =C2=A0 =C2=A0interfaces will not.
> >
> > What I???m basically proposing is that you use MPTCP = for case 1 (data that
> > needs a fallback to the A= CP connection) but for all other transmission
> > (that should be done only over one of the paths, either data plan= e or ACP),
> > you have additional plain TCP connections to use. You can still a= dd an
> > interface to MPTCP to extract the IP address information you need= to start
> > these additional connections.
> >
> > Mirja
> >
> > >
> > > So that's what MPTCP gets us: the ability to start on th= e ACP, do
> > security,
> > > and then move the bulk traffic to another place.
> >
> > >
> > > --
> > > ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Neve= r tell me the odds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| ipv6 mesh
> > networks [
> > > ]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | network
> > architect=C2=A0 [
> > > ]=C2=A0 =C2=A0 =C2=A0mcr= @sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0ruby on
> > rails=C2=A0 =C2=A0 [
> > >
> >
> >

--
---
tte@cs.fau.de

--001a114d7d3eaf5c3705642b02df-- From nobody Thu Feb 1 11:05:43 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF68C12E889; Thu, 1 Feb 2018 11:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8qPiuhVDhV3K; Thu, 1 Feb 2018 11:05:31 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55AC12D967; Thu, 1 Feb 2018 11:05:30 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 98FC558C594; Thu, 1 Feb 2018 20:05:26 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 813D0B0D924; Thu, 1 Feb 2018 20:05:26 +0100 (CET) Date: Thu, 1 Feb 2018 20:05:26 +0100 From: Toerless Eckert To: Spencer Dawkins at IETF Cc: Michael Richardson , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, "Mirja Kuehlewind (IETF)" , The IESG , Anima WG , Sheng Jiang Message-ID: <20180201190526.GC2643@faui40p.informatik.uni-erlangen.de> References: <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> <20180201183447.GB2643@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 19:05:38 -0000 On Thu, Feb 01, 2018 at 12:46:14PM -0600, Spencer Dawkins at IETF wrote: > I do see the due diligence (she's a diligent AD), but I thought Mirja was > (also?) concerned that the draft was assuming that MPTCP could be made to > handle two paths in failover mode, when it actually doesn't work that way. I am not sure if/what would be missing in MP_TCP wrt. to the failover itself, thats what signaling of addresses and and MP_PRIO are about, right ? But the draft itself is an informational use-case validation draft, and the notions about MP-TCP should be understood as requirements. If somethiing is missing in MPTCP or enabllin shim-libraries on top of it, then this should come through standards specs. draft alread says: "Making this idea work requires additional specification work outside the scope of this document. " So i hope the due diligence is mostly around whethere there is something fundamentally wrong as opposed to try to go further down into the potentially necessary additional specification elements (which i think are mostly about policies for MPTCP and/or abstract APIs). Cheers Toerless > But I'll let you two keep typing :-) > > Spencer > > > > Cheers > > Toerless > > > > > Thanks, > > > > > > Spencer, the irresponsible AD, in this case ... > > > > > > > > > > > If all data-plane flows fail, then it might suspend > > > > > traffic. > > > > > > > > That will not happen with MPTCP; it will fail back to use the ACP > > > > connection (if there is a subflow for it). > > > > > > > > > > > > > > I think that there is some advantage to starting the connection on > > the > > > > ACP, > > > > > because: > > > > > a) no TCP SYN listener on the data-plane interface(s) reduces attack > > > > > surface (assuming NOC->router initialized connections, but the > > same > > > > > argument applies to keeping the NOC devices isolated) > > > > > > > > Also with MPTCP you need a TCP SYN lister on the remote data-plane > > > > interface because creating a MPTCP subflow means sending a TCP SYN > > with an > > > > MPTCP option. > > > > > > > > > > > > > > > > > > b) the IP addresses of the router on the data-plane might be hard to > > > > know > > > > > in advance, being subject to routing algorithms and address > > > > assignment > > > > > ASAs. Also some interfaces might exist only with LL addresses > > until > > > > the > > > > > need to grow a GUA occurs. > > > > > > > > > > The ACP addresses are essentially locked down by being embedded > > in > > > > > certificate DNs. (see the ACP draft). That also means that a TLS > > > > > connection to the router will be validatable by the router's > > domain > > > > > certificate, while the (stable? temporary?) address assigned on > > the > > > > dataplane > > > > > interfaces will not. > > > > > > > > What I???m basically proposing is that you use MPTCP for case 1 (data > > that > > > > needs a fallback to the ACP connection) but for all other transmission > > > > (that should be done only over one of the paths, either data plane or > > ACP), > > > > you have additional plain TCP connections to use. You can still add an > > > > interface to MPTCP to extract the IP address information you need to > > start > > > > these additional connections. > > > > > > > > Mirja > > > > > > > > > > > > > > So that's what MPTCP gets us: the ability to start on the ACP, do > > > > security, > > > > > and then move the bulk traffic to another place. > > > > > > > > > > > > > > -- > > > > > ] Never tell me the odds! | ipv6 mesh > > > > networks [ > > > > > ] Michael Richardson, Sandelman Software Works | network > > > > architect [ > > > > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > > > > rails [ > > > > > > > > > > > > > > > > > -- > > --- > > tte@cs.fau.de > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Thu Feb 1 11:30:41 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B8612EB41; Thu, 1 Feb 2018 11:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4xoKe3Tf_ZaR; Thu, 1 Feb 2018 11:30:32 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3122F12EAFF; Thu, 1 Feb 2018 11:30:32 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B08DE58C594; Thu, 1 Feb 2018 20:30:27 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 92D94B0D924; Thu, 1 Feb 2018 20:30:27 +0100 (CET) Date: Thu, 1 Feb 2018 20:30:27 +0100 From: Toerless Eckert To: "Mirja Kuehlewind (IETF)" Cc: Michael Richardson , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180201193027.GD2643@faui40p.informatik.uni-erlangen.de> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 19:30:35 -0000 On Thu, Feb 01, 2018 at 05:14:58PM +0100, Mirja Kuehlewind (IETF) wrote: > > If all data-plane flows fail, then it might suspend traffic. > > That will not happen with MPTCP; it will fail back to use the ACP connection (if there is a subflow for it). Right. This is one of the pieces that i think would require additional spec/extension to MPTCP - or could be handled by a shim library that gets enough notificatations from MPTCP. I was hoping we could move discussions about the "howto to an appropviate draft in the MPTCP WG, eg: the to-be-renewed socket draft i mentione din before. > > I think that there is some advantage to starting the connection on the ACP, > > because: > > a) no TCP SYN listener on the data-plane interface(s) reduces attack > > surface (assuming NOC->router initialized connections, but the same > > argument applies to keeping the NOC devices isolated) > > Also with MPTCP you need a TCP SYN lister on the remote data-plane interface because creating a MPTCP subflow means sending a TCP SYN with an MPTCP option. The data-plane subflow MPTCP SYN/ACK can ony happen after the GACP subflows ADD_ADDR, so one should be able to enable selective filtering of data-plane SYN packets based on the address learned from the ADD_ADDR. Can we somehow move all this discussion as mentioned above over to some good (hopefully standards track) target draft in MPTCP ? Stable connectivity is really just the informative use-case discussion draft and should be read as a requirements draft containing a high level description of the reasons why & how to use & expand MPTCP (and/or shim library). > What I???m basically proposing is that you use MPTCP for case 1 (data that needs a fallback to the ACP connection) but for all other transmission (that should be done only over one of the paths, either data plane or ACP), you have additional plain TCP connections to use. You can still add an interface to MPTCP to extract the IP address information you need to start these additional connections. See my previous reply why i think there is no difference between 1) and 2) re the need to leverage MPTCP. As said above, the main difference IMHO is that "suspending or aborting" the connection upon failure of a subflow is seemingly new and would require additional work for MPTCP. Cheers Toerless > Mirja > > > > > So that's what MPTCP gets us: the ability to start on the ACP, do security, > > and then move the bulk traffic to another place. > > > > > -- > > ] Never tell me the odds! | ipv6 mesh networks [ > > ] Michael Richardson, Sandelman Software Works | network architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Thu Feb 1 12:19:18 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A0C12DA72; Thu, 1 Feb 2018 12:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8OK859T_kw8G; Thu, 1 Feb 2018 12:19:08 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA3D12DA03; Thu, 1 Feb 2018 12:19:07 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 435C020093; Thu, 1 Feb 2018 15:25:20 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CA3FF8064D; Thu, 1 Feb 2018 15:19:06 -0500 (EST) From: Michael Richardson To: "Mirja Kuehlewind \(IETF\)" cc: Toerless Eckert , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com In-Reply-To: <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 20:19:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mirja Kuehlewind (IETF) wrote: > see below. >> Am 01.02.2018 um 16:31 schrieb Michael Richardson : >> >> >> Mirja Kuehlewind (IETF) wrote: >>> Why does your case 2 need an MPTCP connection instead of just openi= ng a >>> second separate TCP data plan connection (that of course fails when= it >>> fails..)? >> >> I think the idea is that there is some long running connection; for = instance >> a log flow or a mirror port flow. Or maybe even an SDN control conn= ection. >> > The case 2 I=E2=80=99ve been referring to is that: > "2) Connections for non-urgent bulk transers (for example most routine > firmware updates or cached log collection) may use a policy where > the connection is made to fail when the data-plane fails or have > transfers suspend until another data-plane subflow can successfully > be built. This avoids over-taxing the ACP when the data plane fails.= =E2=80=9C > I think for non-urgent bulk transfers it would be no problem to open a > new TCP connection, send the data, and close it again. Yes, but to what address does one open the new TCP connection? The dataplane addresses are potentially ephemeral, and don't have any TLS certificates bound to them. >> If all data-plane flows fail, then it might suspend >> traffic. > That will not happen with MPTCP; it will fail back to use the ACP > connection (if there is a subflow for it). okay. >> I think that there is some advantage to starting the connection on t= he ACP, >> because: >> a) no TCP SYN listener on the data-plane interface(s) reduces attack >> surface (assuming NOC->router initialized connections, but the same >> argument applies to keeping the NOC devices isolated) > Also with MPTCP you need a TCP SYN lister on the remote data-plane > interface because creating a MPTCP subflow means sending a TCP SYN wi= th > an MPTCP option. okay, I'm honestly ignorant of such things. But the address of the data-plane interface doesn't have to be known. > What I=E2=80=99m basically proposing is that you use MPTCP for case 1= (data > that needs a fallback to the ACP connection) but for all other > transmission (that should be done only over one of the paths, either > data plane or ACP), you have additional plain TCP connections to > use. You can still add an interface to MPTCP to extract the IP address > information you need to start these additional connections. so, you start TCP on the ACP, do security. Then you add the data-plane interface to get the addresses. Then you close it all and continue using the plain data-plane TCP? Did I understand this correctly? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpzdjoACgkQgItw+93Q 3WVAlgf9GV7DwkYb2hObaZKFQ5x7glgRVVmQskKI13NBICUq5NKNNqTVDkLgDsiM 2p3Extu+5C5NWOJC9Q5luPU88b8XfMhFXNy+E9xNyv+/UL92ksZoxsfZJOP/vNyR zui0SKkYpjMxvdwHly+yZaJeKD7nag/hIFGSXflU96DWzZOMLiJz4Gp05svVFi8D pTZr28TgtMmeJwEa4MY79dWJRzmTn5jrx0HGY6LncDyCX1GDLiPFqF253tq+JeuY hplM7B5EwykUPI5XvURCfnD7HXcsm0gGNrb3XeBw8XvxKJsbtv11UlUmvLjVdWd6 iuux/4YXAkKMIWO02K01Gf4vczl5jQ== =F+2o -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 1 12:21:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8B812EAD1; Thu, 1 Feb 2018 12:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nJ6tnOL_OsHf; Thu, 1 Feb 2018 12:21:19 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB3112E041; Thu, 1 Feb 2018 12:21:19 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A7C9920093; Thu, 1 Feb 2018 15:27:31 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 32D1A8064D; Thu, 1 Feb 2018 15:21:18 -0500 (EST) From: Michael Richardson To: Spencer Dawkins at IETF cc: "Mirja Kuehlewind \(IETF\)" , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, Toerless Eckert , The IESG , Anima WG , Sheng Jiang In-Reply-To: References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 20:21:22 -0000 --=-=-= Content-Type: text/plain Spencer Dawkins at IETF wrote: > This is Mirja's Discuss thread, and MPTCP is her working group, and > she knows MPTCP better than I do, but I'm confused about one thing, as > I'm reading this discussion ... ... > If I'm understanding the discussion, the desire is to use MPTCP to > handle failover to another pre-established flow quickly, and Mirja's > point is that normal MPTCP would just use both flows - so, not > actually failing over, but if you provision for each flow to carry all > your traffic, which you would have to do in order to handle failover > anyway, I'm not sure why it's bad to let MPTCP do what it would do > normally, and load-share across overprovisioned paths. I also don't know why it would be bad. My other question is, what happens in MPTCP is one path is significantly faster (or less lossy) than the other path? Won't the window open up significantly on that path and simply attrack more traffic? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpzdr0ACgkQgItw+93Q 3WWWiAf8Dwfp1+LW3ExhDlyd0EoodLVx3fC4d84OzjOK3IBJNY22J7YXzStj2aLl g/Zqo3xcMgwBVjMKGwYDSvkl9MqbLBD9wi9XJj+wP+lBCWKY3kbTEi7LIXRzS0ok WamJmInFuUMSbR2OBOBkwXXVL1GF0bCepOFAzWoPljNFG+LF3RVDdgL3F4E4GyTM Nz9aRzASyzZ4Wo5wuGVAX1iXNaBKaGGcyLq3DuOk0AW6fa0aZd/70uWnuEHxsvEV gi3+YF+UqxaCMwq5O+9c/bH5V7/ejQ5cuMWDn70ov7WPjcKgJFkaBRLQvxdpxl12 HXg84xsgucHbeDSE5zKe589nJxCT2Q== =PvIC -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 1 13:59:59 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6412EAD2; Thu, 1 Feb 2018 13:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6doqFCKthtFR; Thu, 1 Feb 2018 13:59:54 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7DD12DA43; Thu, 1 Feb 2018 13:59:54 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6166558C5A2; Thu, 1 Feb 2018 22:59:50 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 45DC9B0D926; Thu, 1 Feb 2018 22:59:50 +0100 (CET) Date: Thu, 1 Feb 2018 22:59:50 +0100 From: Toerless Eckert To: Michael Richardson Cc: Spencer Dawkins at IETF , "Mirja Kuehlewind (IETF)" , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , Anima WG , Sheng Jiang Message-ID: <20180201215950.GE2643@faui40p.informatik.uni-erlangen.de> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> <19808.1517516478@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19808.1517516478@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] MP-TCP (was: Re: Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS)) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 21:59:58 -0000 On Thu, Feb 01, 2018 at 03:21:18PM -0500, Michael Richardson wrote: > I also don't know why it would be bad. > > My other question is, what happens in MPTCP is one path is significantly > faster (or less lossy) than the other path? Won't the window open up > significantly on that path and simply attrack more traffic? I am changing subject because i am hoping/claiming, that we do not need this discussion to proceed stable-connectivity draft because it explicitly excludes that option. But of course i am very intersted in this discussion. Maybe better had on MPTCP mailing lists... That said: MPTCP implementations are supposed to use couple rfc6824 does not seem to mandate anything but just suggests to use coupled congstion control according to rfc6356 if the policy goal is to maximize utilization of both paths, see https://www.ietf.org/proceedings/77/slides/mptcp-9.pdf If i correctly understand it though, MPTCP is not really fair, so if you have lets say 5 flows and they all happen to share a single bottleneck link, then i think MPTCP stil gives you as much as 5 separate flows. If for example ACP and data plane where both hardware accelerated then this would be a possible discussion point if we wanted to have the policy of load splitting traffic across both ACP and data plane. SCTP should be "fairer" in such a case if i remember correctly (i may be wrong). In any case, i didn't think we needed to investigate these options and their possible difficulties for the stable-connectivity use case. That drat is solely suited on resilience and avoiding overload of devices due to possible short term limited ACP implementations. Therefore siple policy to always only transfer data across one subflow. Your point of looking into best methods to speed up switchover between sublflows of course is valid for stable connectivity, and maybe one of the enhanced policies to achieve this is to not wait for connection reset of the data-plane flow but to start sharing load on the ACP much faster, eg: jut measuring the congestion window. Cheers toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- --- tte@cs.fau.de From nobody Fri Feb 2 01:00:14 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EB312FA82 for ; Fri, 2 Feb 2018 01:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 RYmtK5_SQVEJ for ; Fri, 2 Feb 2018 01:00:10 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A841012FA83 for ; Fri, 2 Feb 2018 01:00:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=Q1WcFnrrguab/6LCERmDVm771Sbu4AO8WRLugjLUNtRyz86u079e65azyqYdNpKPjIGYVTL2LiB0WRUa02ymiGpZuHVpuQxsHjCBIw3CqPAK0gLFcbQtz3cHK9YSVzcrKzMewSZWdD+U5XyeCv7qcRX0LnUyRJ/S8UelDoWZZnc=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1309 invoked from network); 2 Feb 2018 09:53:23 +0100 Received: from i577bce83.versanet.de (HELO ?192.168.178.33?) (87.123.206.131) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Feb 2018 09:53:23 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20180201182214.GA2643@faui40p.informatik.uni-erlangen.de> Date: Fri, 2 Feb 2018 09:53:21 +0100 Cc: draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, Michael Richardson , The IESG , anima@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <20180201182214.GA2643@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180202085323.1297.3141@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 09:00:12 -0000 Hi Toreless, see below. > Am 01.02.2018 um 19:22 schrieb Toerless Eckert : >=20 > Inline >=20 > On Thu, Feb 01, 2018 at 02:42:29PM +0100, Mirja Kuehlewind (IETF) = wrote: >> HI Toerless, >>=20 >> thanks so much for these edits. Unfortunately I have one more = question. And sorry again for the delay. >>=20 >> Why does your case 2 need an MPTCP connection instead of just opening = a second separate TCP data plan connection (that of course fails when it = fails..)? >=20 > How do the peers know each others data plane address ? >=20 > =3D> draft text: > (Only) the GACP address of GACP devices could to be put into DNS. > When MPTCP builds the first subflow across the GACP, it exchanges the > data-plane address. >=20 > Without MPTCP i need to reinvent a good part of it and i can not = imagine how > i would get anyone interested to do that signaling part in a = standardized > fashion given how MPTCP does exist. No. For what ever you want to do, you at least have to change something = in the MPTCP interface. And you can just expose the address you=E2=80=99ve= got from MPTCP and open a new TCP connection for the build transfer. >=20 > -> Build TCP connection to responder GACP address. > -> Signal with responder the data-plane address - in a fashion that = would > be backward compatible with a legacy responder/initiator that = doesn't > speak this extension. I wouldn't even know how i could do this via > TCP payload. Must be at the transport level. This is not a transport function. So you would need to build a minimal = app protocol on top of TCP. However it you be as minimal as, if you open = a TCP connection to a certain port, the other end with send you an = address in the first payload packet and closes the connection again. Changing the MPTCP interface is also not compatible with legacy systems = that does support that yet. > -> Build TCP connection via data-plane addresses. > -> Use policy and/or new signaling to decide to prefer using that = connection. > =E2=80=A6 This is the part you also need with MPTCP as you need some kind of = framework policy on top of MPTCP that decides when to build with = subflow. > -> Data-plane connection fails.=20 > -> need some scheme to figure out how to rebuild. However, my reading is that is what you want in case of bulk transfers. = Fail instead of fail-over. In MPTCP if one or your subflows fails it = will also not be rebuild automatically; this is again part of the policy = framework what to do in such a case and when and how to try to build up = another subflow.=20 > if - if and when > available. Including some exponential backoff trying to reconnect. = Or > more likely in our case the data-plane address was unconfigured and = gets > reconfigured maybe differently. (some SDN controller doing some = change > of addressing to the data-plane), So when one side signals to the = other > side that the data-plane address is gone, then no connection probing = is > necessary. And when it is available again, maybe different one, = gets > signalled, and we're building the connection again and using it. Again basically what I=E2=80=99m proposing it that you use MPTCP for = connection where the fallback makes sense, and at the same time expose = the address you=E2=80=99ve learned over MPTCP and build up additional = TCP connection for transfers where no fallback is wanted. Using only one = subflow of MPTCP is not MPTCP anymore and therefore a functionality we = probably don=E2=80=99t want to provide with MPTCP. Also see my next mail = in this point please. Mirja >=20 > Cheers > Toerless >=20 >>=20 >> Mirja >>=20 >>=20 >>> Am 27.01.2018 um 00:06 schrieb Toerless Eckert : >>>=20 >>> On Fri, Jan 26, 2018 at 11:43:08AM +0100, Mirja Kuehlewind (IETF) = wrote: >>>> Hi Toerless, >>>>=20 >>>> sorry for my late reply but I spend only limited time on AD stuff = on the telechat agenda was crowded this week. >>>=20 >>> Thanks for all the hard work! >>>=20 >>>> Okay that is fine. I mainly wanted to double-check as that was = still not fully clear from the provided text. Can you maybe propose a = slight rewording that explicitly say that there is this backup while = using the word ???only??? above in the cited text seems to indicated = differently. >>>=20 >>> I wanted to take the full extend of your feedback into account, so >>> rewrote the paragraph in question maybe a bit more than slightly >>> (couldn't figure out a sane "slightly" ;-): >>>=20 >>> - Moved up the last sentence about per-connection policy up front, >>> so the examples are more logical scoped. >>>=20 >>> - Made the examples into three separate bullet points >>> and expanded them to hopefully eliminate the misunderstanding >>> wrt to backup. >>>=20 >>> - Not only mentioning the fall back (backup), but also added >>> desirable behavior under recovery of preferred subflow path.=20 >>> (important for both 1) and 2). >>>=20 >>> - explaining in bullet point 3) how this one is actually a >>> simple TCP connection (As you pointed out). >>> (whereas 1) and 2) rely on the MPTCP benefit of two subflows and = address signaling). >>>=20 >>> -09 uploaded with this fix as well as fix for Yohi's comment. >>>=20 >>> Diff: >>>=20 >>> = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools.ietf= .org/id/draft-ietf-anima-stable-connectivity-08.txt&url2=3Dhttps://tools.i= etf.org/id/draft-ietf-anima-stable-connectivity-09.txt >>>=20 >>> Here is the changed paragraph: >>>=20 >>> The above described behavior/policy for MPTCP must be controllable = by=09 >>> applications or libraries acting on behalf of applications. APIs >>> and/or data models for this control need to be defined. It should be >>> sufficient to make these policies work on a per connection=09 >>> basis, and not change during the lifetime of a connection for=09 >>> different data items: >>>=20 >>> 1) The policy for likely most connections would be to use the = data-plane >>> subflow and fall back using the ACP subflow when the data-plane = fails. >>> This could be the default. It reduces load on the ACP but would = continue >>> to run connection traffic at likely reduced throughput when the >>> data-plane fails. Ideally such connections would also revert back = to >>> using a data-plane subflow once its connectivity recovers. >>>=20 >>> 2) Connections for non-urgent bulk transers (for example most = routine=20 >>> firmware updates or cached log collection) may use a policy where >>> the connection is made to fail when the data-plane fails or have >>> transfers suspend until another data-plane subflow can successfully >>> be built. This avoids over-taxing the ACP when the data plane = fails.=20 >>>=20 >>> 3) Connections for critical network configuration change operations=20= >>> known to impact the data-plane might want to only use the ACP and >>> could therefore map to a (non-MP)TCP connection. >>>=20 >>> Cheers >>> Toerless >>>=20 >>>=20 >>> m 22.01.2018 um 19:42 schrieb Toerless Eckert : >>>>>=20 >>>>>=20 >>>>> Thanks, Mirja. Inline. >>>>>=20 >>>>> On Mon, Jan 22, 2018 at 01:37:58PM +0100, Mirja Kuehlewind (IETF) = wrote: >>>>>> Hi Toerless, >>>>>>=20 >>>>>> thanks a lot for the updated text. I still have one little point = I would like to discuss a bit further on this text: >>>>>>=20 >>>>>> "The above described behavior/policy for MPTCP must be = controllable by=09 >>>>>> applications or libraries acting on behalf of applications. APIs=09= >>>>>> and/or data models for this control need to be defined. As = outlined=09 >>>>>> above, applications for example may choose to only perform = transfers=09 >>>>>> if the data-plane is actually available because of performance=09 >>>>>> limitations of the GACP, so the application needs to be made = aware if=09 >>>>>> the setup of the data-plane subflow fails. Or transfers may want = to=09 >>>>>> only use the GACP because the connection performs configuration=09= >>>>>> changes that are likely known to bring down the data-plane. It=09= >>>>>> should be sufficient to make these policies work on a per = connection=09 >>>>>> basis, and not change during the lifetime of a connection for=09 >>>>>> different data items.??? >>>>>>=20 >>>>>>=20 >>>>>> When you say that there is a need for an application to send data = only on one path, today that???s not possible with MPTCP as you may = fallback to the other path silently during the transmission. Yes, of = course this could be changed and an extended interface could indicate = this.=20 >>>>>=20 >>>>>>=20 >>>>>> So my question is still what the ???only??? really means in this = text. If you???d like to just indicate a preference that might be okay. = If you really want to rule out the possibility to fallback to the other = path, then I don???t think you need MPTCP and two separate TCP = connections would be the better option. >>>>>>=20 >>>>>> Does that make sense to you? >>>>>=20 >>>>> Not really, the goal is always to leverage existing MPTCP = signaling of >>>>> addresses, indicating backup for flows, etc. I think two TCP flows = would >>>>> never be better: >>>>=20 >>>> Okay that is fine. I mainly wanted to double-check as that was = still not fully clear from the provided text. Can you maybe propose a = slight rewording that explicitly say that there is this backup while = using the word ???only??? above in the cited text seems to indicated = differently. >>>>=20 >>>> Thanks! >>>>=20 >>>>>=20 >>>>> The GACP address is the primary identifier of a device known in = DNS. >>>>> Data-Plane addresses can change over time subject to operator = configuration >>>>> and could also pose more of a security issue to be in DNS (GACP is = isolated >>>>> network). >>>>>=20 >>>>> GACP performance may be quite low because some network device may = route/forward >>>>> it in software. data-plane routing/forwarding is expected to be = fast/HW-accelerated. >>>>>=20 >>>>> With MPTCP as suggested this gives for example: >>>>> Initial subflow must use GACP because thats the only "known/stable = address" in DNS >>>>> Then MPTCP signaling is used to indicate mutually the data-plane = addresses >>>>> and make GACP subflow backup. >>>>> Then you transfer lets say a few Gigabyte of data (e.g.: firmware = update) which >>>>> goes over data-plane. >>>>> Then some uncorrelated error happens and data-plane fails. This = particular app >>>>> should then fail because it would just slow down to insufferable = slow across >>>>> GACP and would overload software forwarding in GACP. >>>>>=20 >>>>> In another application connection, fallback to GACP subflow for = data if dat-plane >>>>> subflow fails is fine, but you would only prefer data-plane for = performance. >>>>>=20 >>>>> You could consider the GACP potential software only forwarding = like a very high >>>>> cost of using it while data-plane is free. >>>>>=20 >>>>> If i would just use 2 * TCP instead of MPTCP i would have to = reinvent a lot of >>>>> MPTCP to get the address signaling etc. Right ? >>>>>=20 >>>>> Cheers >>>>> Toerless >>>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Am 17.01.2018 um 03:36 schrieb Toerless Eckert : >>>>>>>=20 >>>>>>> Mirja, Yoshifumi >>>>>>>=20 >>>>>>> I just posted -08: = https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt >>>>>>>=20 >>>>>>> I have reworked the MPTCP text based on your threads feedback = with >>>>>>> the intention to fix errors and have it answer the = questions/concerns raised, >>>>>>> but without otherwise changing the scope of it: >>>>>>>=20 >>>>>>> - What are they key features making MPTCP interesting=20 >>>>>>> - How could it be used to solve the stable-connectivity issue >>>>>>> - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK >>>>>>> beyond the scope of this document >>>>>>> - Describe the areas of specification work required >>>>>>> - API/policy, control by apps >>>>>>> - dealing with dual VRF addresses >>>>>>>=20 >>>>>>> Please check diff in this URL (not complete diff of -08, just = fix for your discuss/comment): >>>>>>>=20 >>>>>>> = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.github= usercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74a= d152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stab= le-connectivity-08.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/a= utonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf= -anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt >>>>>>>=20 >>>>>>> I hope this resolves your DISCUSS/comments.=20 >>>>>>>=20 >>>>>>> Note that the term ACP was changed in the doc to GACP based on = resolving Alvaros discus. See: >>>>>>>=20 >>>>>>> = https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/= draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt >>>>>>>=20 >>>>>>> Thank you >>>>>>> Toerless >>>>>>>=20 >>>>>>> On Thu, Jan 11, 2018 at 03:42:53PM +0100, Mirja K?hlewind wrote: >>>>>>>> Hi Toerless, >>>>>>>>=20 >>>>>>>> the point I'm wondering about is your point (b) below. Yes, you = can >>>>>>>> set the ACP subflow to backup but that would still mean that if = the >>>>>>>> other link fails, it would automatically switch over to the ACP >>>>>>>> subflow (without exposing this to the upper layer). Is that = what you >>>>>>>> want? Because my understanding was rather that there are cases = where >>>>>>>> you'd probably would like to know over which link the OAM = packets >>>>>>>> where actually sent...? >>>>>>>>=20 >>>>>>>> Mirja >>>>>>>>=20 >>>>>>>> On 08.01.2018 22:06, Toerless Eckert wrote: >>>>>>>>> Thanks, Mirja >>>>>>>>>=20 >>>>>>>>> (a) If the systems socket API does not transparently make TCP = sockets >>>>>>>>> to use MPTCP, then you would want a shim library. According to >>>>>>>>> draft-hesmans-mptcp-socket, this is be the case on Apple = (iOS). >>>>>>>>>=20 >>>>>>>>> (b) Making the ACP subflow not carry traffic after = establishing the >>>>>>>>> data plane subflow should easily be possible possible by = setting its MP_PRIO >>>>>>>>> to backup. >>>>>>>>>=20 >>>>>>>>> (c) How exactly to specify or implement the desired policy of = only >>>>>>>>> establishing a subflow between the ACP addresses and the data = plane addresses >>>>>>>>> (but not full-mesh) seem to be a subject for further spec = work. It could >>>>>>>>> be defined as a specific in-MPTCP policy, or it could be done = via a shim >>>>>>>>> library (orthogonal to (a)). draft-hesmans-mptcp-socket might = be sufficient. >>>>>>>>>=20 >>>>>>>>> But in general: i would like for this (informational!) draft = to just motivate >>>>>>>>> the concept and not specify the solution: MPTCP would be a = simple way to >>>>>>>>> make "TCP" applications automatically "upgrade" from ACP to a = data-plane path >>>>>>>>> and switch back when data-plane fails... because MP-TCP can = signal the >>>>>>>>> additional data-plane addresses, establish transparently = another subflow and switch >>>>>>>>> traffic between the subflows - all by using the right = shim-library+API or >>>>>>>>> in-MP-TCP address/subflow policies - and the ability to = establish subflows >>>>>>>>> across two VRFs. >>>>>>>>>=20 >>>>>>>>> Cheers >>>>>>>>> Toerless >>>>>>>>>=20 >>>>>>>>> On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind = (IETF) wrote: >>>>>>>>>>>>> Suggested replacement text last two paragraphs of 2.1.5: >>>>>>>>>>> A (shim) library for aplications maps TCP connections to = MPTCP without the applications having to be aware of it. >>>>>>>>>> It???s not the (shim) library/policy framework that = opens/maps the TCP connection. MPTCP itself opens eventually multiple = connections but exposes only one connection to the layer above. That = means everything above MPTCP does not have any real control about which = data is send over which connection. >>>>>>>>>>=20 >>>>>>>>>> A policy shim layer could only implement rules about which = new subflows should be established when and what the priority is over = which subflow data should be sent but it generally does not control = which data is send of which flow. You can???t say I want this data to be = sent over subflow one and this data to be sent over sub flow two. >>>>>>>>>>=20 >>>>>>>>>> I think what you want is actually a view on the different TCP = connections and you try to use MPTCP only for announcing the other IP = address but that is not what MPTCP meant to be. >>>>>>>>>>=20 >>>>>>>>>> Mirja >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> Names in DNS use only the ACP IPv6 addresses of network = devices. Thererefore, the initial MPTCP subflow will use the ACP. After = it is operating, the shim libraries on both ends add their data-plane = address (MPTCP ADD_ADDR) and attempt to build a new subflow between = those addresses. If that (data plane) subflow is successfully built, the = shim libraries could shift all traffic over this subflow which should be = forwarded hardware accelerated by the network - and use the ACP subflow = across the ACP solely for signaling - beause it is most resilient = against failure. >>>>>>>>>>>=20 >>>>>>>>>>> This MPTCP approach is only an outline and would need to be = fully speficied for interoperable implementations. It may also require = extensions to MP-TCP. This mechanism must not be used without providing = for encryption of subflows not running across the ACP. >>>>>>>>>>>=20 >>>>>>>>>>>>> Brian: ... can not use capital MUST NOT in an information = draft (i think) >>>>>>>>>>>>>=20 >>>>>>>>>>> Cheers >>>>>>>>>>> Toerless >>>>>>>>>>>=20 >>>>>>>>>>> On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind = (IETF) wrote: >>>>>>>>>>>> Hi Micheal, >>>>>>>>>>>>=20 >>>>>>>>>>>> to clarify one part below: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Am 05.01.2018 um 23:30 schrieb Michael Richardson = : >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Mirja K=C3=83=C2=BChlewind wrote: >>>>>>>>>>>>>> "DNS naming is set up to provide the ACP IPv6 address of = network >>>>>>>>>>>>>> devices. Unbeknownst to the application, MPTCP is used. = MPTCP >>>>>>>>>>>>>> mutually discovers between the NOC and network device the = data-plane >>>>>>>>>>>>>> address and caries all traffic across it when that MPTCP = subflow >>>>>>>>>>>>>> across the data-plane can be built." >>>>>>>>>>>>> Section 2.1.5 is discussion, it discusses ways in which = the >>>>>>>>>>>>> anticipated low performance (compared to what the box = might do with its >>>>>>>>>>>>> hardware accelerated forwarding). >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If we have an application that needs the bandwidth of the = native hardware, >>>>>>>>>>>>> the connection can be initated over the ACP (that's what = would be in DNS). >>>>>>>>>>>>> One presumes that an MPTCP layer could then enumerate the = available IPs at >>>>>>>>>>>>> each end and then start off additional flows on the other = destinations. >>>>>>>>>>>> MPTCP adda an additional TCP flow but for the application = that still looks like one flow. As I said I???m not sure if that is what = you want. >>>>>>>>>>>>=20 >>>>>>>>>>>> Mirja >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> The application would have to include application = security, since it would >>>>>>>>>>>>> not be protected by the ACP. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Perhaps MPTCP doesn't work this way. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> However, I'm actually uncertain how this is supposed to = work and what >>>>>>>>>>>>>> "Unbeknownst to the application" should mean. If another = address should be >>>>>>>>>>>>>> signaled to the other host, this needs to be indicated by = the application or at >>>>>>>>>>>>>> least some kind of policy framework above MPTCP. Also = MPTCP will by default use >>>>>>>>>>>>>> both paths simultaneously while still looking like one = connection to the >>>>>>>>>>>>>> application, meaning the application has no control which = path is used for >>>>>>>>>>>>>> which traffic. I guess you can open a second subflow and = then configure the >>>>>>>>>>>>>> first subflow as backup path but I'm not sure if that's = what you want (given >>>>>>>>>>>>>> the application/policy framework will still not know = which path is used)..? >>>>>>>>>>>>>> Please provide more information about what the expected = usage scenario is here. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Michael Richardson , Sandelman = Software Works >>>>>>>>>>>>> -=3D IPv6 IoT consulting =3D- >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Anima mailing list >>>>>>>>>>>> Anima@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>>>>>> --=20 >>>>>>>>>>> --- >>>>>>>>>>> tte@cs.fau.de >>>>>>>=20 >>>>>>> --=20 >>>>>>> --- >>>>>>> tte@cs.fau.de >>>=20 >>> --=20 >>> --- >>> tte@cs.fau.de >>>=20 >=20 > --=20 > --- > tte@cs.fau.de >=20 From nobody Fri Feb 2 01:09:02 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4350612FA87 for ; Fri, 2 Feb 2018 01:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 aetfZIUDeEMP for ; Fri, 2 Feb 2018 01:08:59 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C19127909 for ; Fri, 2 Feb 2018 01:08:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=UxEtAJHaLWDgrWV1ClwKn0uzb9T+mb6HyMCCJ3AhaVEMlxRxvlYHxCk1gv7LlKSjH4Y0RFXjUmXEBVl5ts7NP0aqYUuANqaHH/CbQGGHDxuhhV4nRZ4l+a5CdRrYbNuyNjf2K2CfEa6/416XWD4YOyJf3M6hEe4QdSdUVlxqNFs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1970 invoked from network); 2 Feb 2018 10:08:57 +0100 Received: from i577bce83.versanet.de (HELO ?192.168.178.33?) (87.123.206.131) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Feb 2018 10:08:57 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <19808.1517516478@obiwan.sandelman.ca> Date: Fri, 2 Feb 2018 10:08:56 +0100 Cc: Spencer Dawkins at IETF , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, Toerless Eckert , The IESG , Anima WG , Sheng Jiang Content-Transfer-Encoding: quoted-printable Message-Id: <6DC62A3B-B994-49CF-AECB-F9A707EF0441@kuehlewind.net> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> <19808.1517516478@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180202090857.1959.2756@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 09:09:01 -0000 Hi Spencer, see below > Am 01.02.2018 um 21:21 schrieb Michael Richardson = : >=20 >=20 > Spencer Dawkins at IETF wrote: >> This is Mirja's Discuss thread, and MPTCP is her working group, and >> she knows MPTCP better than I do, but I'm confused about one thing, = as >> I'm reading this discussion ... >=20 > ... >=20 >> If I'm understanding the discussion, the desire is to use MPTCP to >> handle failover to another pre-established flow quickly, and Mirja's >> point is that normal MPTCP would just use both flows No. That was not my point at all. You can use both flow simultaneously = with MPTCP pr configure it to automatically failover but making one or = some of the subflow backup subflows. These are other valid use cases. = However for transmission where you want neither of these two options = (but fails when one specific connection fails), you should not use MPTCP = but a single TCP connection.=20 >> - so, not >> actually failing over, but if you provision for each flow to carry = all >> your traffic, which you would have to do in order to handle failover >> anyway, I'm not sure why it's bad to let MPTCP do what it would do >> normally, and load-share across overprovisioned paths. >=20 > I also don't know why it would be bad. >=20 > My other question is, what happens in MPTCP is one path is = significantly > faster (or less lossy) than the other path? Won't the window open up > significantly on that path and simply attrack more traffic? If you use coupled connection control to would sent more data over the = faster path. But I don=E2=80=99t this was the use case here rather than = automatic failover (with can be done with MPTCP as explained above). Mirja >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Fri Feb 2 01:11:27 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4F312FA8C for ; Fri, 2 Feb 2018 01:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 JlBTvtytxGRE for ; Fri, 2 Feb 2018 01:11:23 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDE312F4C5 for ; Fri, 2 Feb 2018 01:11:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=obIjJRtkt2sX6b3juu4fmYkcXSzO6Kk3E1zg0+kJnJyT82x4i4g/ujBIHb4mFj3esc1eq2BtW7cfeNWEhF56m9Krnmz7lK/nm4txshzmIRUsc7MdSHbuArPUK0hImNhxGChXVitU7Hut/OUl6iDDa95FKBYaJnIpd19h5MNxz3c=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1774 invoked from network); 2 Feb 2018 10:04:40 +0100 Received: from i577bce83.versanet.de (HELO ?192.168.178.33?) (87.123.206.131) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Feb 2018 10:04:40 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <19294.1517516346@obiwan.sandelman.ca> Date: Fri, 2 Feb 2018 10:04:39 +0100 Cc: draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, Toerless Eckert , The IESG , anima@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: <918C5179-CB83-454B-8BCD-661140FD9705@kuehlewind.net> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> <19294.1517516346@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180202090440.1764.34022@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 09:11:25 -0000 Hi Michael, see below. > Am 01.02.2018 um 21:19 schrieb Michael Richardson = : >=20 >=20 > Mirja Kuehlewind (IETF) wrote: >> see below. >=20 >>> Am 01.02.2018 um 16:31 schrieb Michael Richardson = : >>>=20 >>>=20 >>> Mirja Kuehlewind (IETF) wrote: >>>> Why does your case 2 need an MPTCP connection instead of just = opening a >>>> second separate TCP data plan connection (that of course fails when = it >>>> fails..)? >>>=20 >>> I think the idea is that there is some long running connection; for = instance >>> a log flow or a mirror port flow. Or maybe even an SDN control = connection. >>>=20 >=20 >> The case 2 I=E2=80=99ve been referring to is that: >=20 >> "2) Connections for non-urgent bulk transers (for example most = routine >> firmware updates or cached log collection) may use a policy where >> the connection is made to fail when the data-plane fails or have >> transfers suspend until another data-plane subflow can successfully >> be built. This avoids over-taxing the ACP when the data plane = fails.=E2=80=9C >=20 >> I think for non-urgent bulk transfers it would be no problem to open = a >> new TCP connection, send the data, and close it again. >=20 > Yes, but to what address does one open the new TCP connection? > The dataplane addresses are potentially ephemeral, and don't have any > TLS certificates bound to them. see below. >=20 >>> If all data-plane flows fail, then it might suspend >>> traffic. >=20 >> That will not happen with MPTCP; it will fail back to use the ACP >> connection (if there is a subflow for it). >=20 > okay. >=20 >>> I think that there is some advantage to starting the connection on = the ACP, >>> because: >>> a) no TCP SYN listener on the data-plane interface(s) reduces attack >>> surface (assuming NOC->router initialized connections, but the same >>> argument applies to keeping the NOC devices isolated) >=20 >> Also with MPTCP you need a TCP SYN lister on the remote data-plane >> interface because creating a MPTCP subflow means sending a TCP SYN = with >> an MPTCP option. >=20 > okay, I'm honestly ignorant of such things. > But the address of the data-plane interface doesn't have to be known. Of course you need an address. >=20 >> What I=E2=80=99m basically proposing is that you use MPTCP for case 1 = (data >> that needs a fallback to the ACP connection) but for all other >> transmission (that should be done only over one of the paths, either >> data plane or ACP), you have additional plain TCP connections to >> use. You can still add an interface to MPTCP to extract the IP = address >> information you need to start these additional connections. >=20 > so, you start TCP on the ACP, do security. > Then you add the data-plane interface to get the addresses. > Then you close it all and continue using the plain data-plane TCP? > Did I understand this correctly? No. you open the MPTCP connection, get the address and open the subflow. = This connection you can use for any transfer where you want to fallback = to the ACP connection. However, if you also have transfers where you = don=E2=80=99t want to fallback, you expose the address you learnt over = the MPTCP connection and use that to open a second (non-MPTCP) TCP = connection to the same address (which then has automatically the desired = feature to fail when needed). Having multiple TCP connection opens at = once is the right solution here. Mirja >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Fri Feb 2 01:27:24 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8212DA44 for ; Fri, 2 Feb 2018 01:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 vjY3jpMSu2HQ for ; Fri, 2 Feb 2018 01:27:21 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C603E12FA92 for ; Fri, 2 Feb 2018 01:27:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=gz8aCPdH9xgtP9Par142h2lWEhFXtxQfJoz1gikWEFYVL+S9swNfLFPrZUUl7GwE9SJXzlGt1R1Dn9cqqs3Gkli8kxESvozVnG97V7rqPlg+gwHvDBkxEJQmhdBin21whUw15srXYy9W71HCACqhmrAv9DKt2MpyL6K4wfbxDms=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1572 invoked from network); 2 Feb 2018 10:00:37 +0100 Received: from i577bce83.versanet.de (HELO ?192.168.178.33?) (87.123.206.131) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Feb 2018 10:00:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20180201193027.GD2643@faui40p.informatik.uni-erlangen.de> Date: Fri, 2 Feb 2018 10:00:34 +0100 Cc: Michael Richardson , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> <20180201193027.GD2643@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180202090037.1562.77331@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 09:27:23 -0000 Hi Toerless,=20 see below again. > Am 01.02.2018 um 20:30 schrieb Toerless Eckert : >=20 > On Thu, Feb 01, 2018 at 05:14:58PM +0100, Mirja Kuehlewind (IETF) = wrote: >>> If all data-plane flows fail, then it might suspend traffic. >>=20 >> That will not happen with MPTCP; it will fail back to use the ACP = connection (if there is a subflow for it). >=20 > Right. This is one of the pieces that i think would require additional > spec/extension to MPTCP - or could be handled by a shim library > that gets enough notificatations from MPTCP. This is something that should not be done with MPTCP because that = exactly not what MPTCP is meant for. In this case just use a standard = TCP connection. And that=E2=80=99s my whole point. I see that there is a = use case for MPTCP in you setup when fallback is needed but don=E2=80=99t = use MPTCP if not needed and then don=E2=80=99t require changes to MPTCP = that would make it behave like single TCP because that really not the = design goal of MPTCP.=20 >=20 > I was hoping we could move discussions about the "howto to an = appropviate > draft in the MPTCP WG, eg: the to-be-renewed socket draft i mentione = din > before. Yes, we really do not need to design the whole solution here. But I = don=E2=80=99t want to discuss the use of MPTCP when it is not necessary = to use MPTCP and more over I don=E2=80=99t want to phrase requirement = for MPTCP that doesn=E2=80=99t make sense because it would be easier to = just use TCP instead. >=20 >>> I think that there is some advantage to starting the connection on = the ACP, >>> because: >>> a) no TCP SYN listener on the data-plane interface(s) reduces attack >>> surface (assuming NOC->router initialized connections, but the = same >>> argument applies to keeping the NOC devices isolated) >>=20 >> Also with MPTCP you need a TCP SYN lister on the remote data-plane = interface because creating a MPTCP subflow means sending a TCP SYN with = an MPTCP option. >=20 > The data-plane subflow MPTCP SYN/ACK can ony happen after the GACP > subflows ADD_ADDR, so one should be able to enable selective filtering > of data-plane SYN packets based on the address learned from the = ADD_ADDR. >=20 > Can we somehow move all this discussion as mentioned above over to > some good (hopefully standards track) target draft in MPTCP ?=20 > Stable connectivity is really just the informative use-case discussion > draft and should be read as a requirements draft containing a > high level description of the reasons why & how to use & expand MPTCP > (and/or shim library). Yes, those details really don=E2=80=99t need to go in the draft. I was = just replying to something Michael said. >=20 >> What I???m basically proposing is that you use MPTCP for case 1 (data = that needs a fallback to the ACP connection) but for all other = transmission (that should be done only over one of the paths, either = data plane or ACP), you have additional plain TCP connections to use. = You can still add an interface to MPTCP to extract the IP address = information you need to start these additional connections. >=20 > See my previous reply why i think there is no difference between 1) = and > 2) re the need to leverage MPTCP. And this is exactly my point and where we disagree. > As said above, the main difference IMHO > is that "suspending or aborting" the connection upon failure of a = subflow > is seemingly new and would require additional work for MPTCP. I don=E2=80=99t this this should be a requirement for MPTCP and I = don=E2=80=99t think this should be spell out in this draft as such = because you can just use a TCP connection in this case. That=E2=80=99s = the whole point. Mirja >=20 > Cheers > Toerless >=20 >> Mirja >>=20 >>>=20 >>> So that's what MPTCP gets us: the ability to start on the ACP, do = security, >>> and then move the bulk traffic to another place. >>=20 >>>=20 >>> -- >>> ] Never tell me the odds! | ipv6 mesh = networks [ >>> ] Michael Richardson, Sandelman Software Works | network = architect [ >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >>>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > --=20 > --- > tte@cs.fau.de >=20 From nobody Mon Feb 5 18:47:25 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E65124217; Mon, 5 Feb 2018 18:47:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151788523974.25024.13731197404436115247@ietfa.amsl.com> Date: Mon, 05 Feb 2018 18:47:19 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-stable-connectivity-10.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 02:47:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Using Autonomic Control Plane for Stable Connectivity of Network OAM Authors : Toerless Eckert Michael H. Behringer Filename : draft-ietf-anima-stable-connectivity-10.txt Pages : 26 Date : 2018-02-05 Abstract: OAM (Operations, Administration and Maintenance - as per BCP161, (RFC6291) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on, changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to aforementioned circular dependencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-stable-connectivity-10 https://datatracker.ietf.org/doc/html/draft-ietf-anima-stable-connectivity-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-stable-connectivity-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 5 18:53:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0340012DA40; Mon, 5 Feb 2018 18:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 asmuBLDhgZxk; Mon, 5 Feb 2018 18:53:03 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97E0124BFA; Mon, 5 Feb 2018 18:53:03 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DB2F758C4B8; Tue, 6 Feb 2018 03:52:57 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id B4232B0D998; Tue, 6 Feb 2018 03:52:57 +0100 (CET) Date: Tue, 6 Feb 2018 03:52:57 +0100 From: Toerless Eckert To: "Mirja Kuehlewind (IETF)" Cc: Michael Richardson , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180206025257.GG2643@faui40p.informatik.uni-erlangen.de> References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> <20180201193027.GD2643@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 02:53:07 -0000 Thanks Mirja, also for our talk earlier today. -10 just posted. https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-10.txt http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-09.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-10.txt As discussed today, and to summarize for the thread here: As changelog explains, i changed the wording of the multipath text to be a set of requirements and not to suggest specific ways how to use MPTCP. Without changing the scope & goal of the multipath text, this was IMHO the correct approach because through the review from Mirja and Yoshi it became clear that there is more work to be done before there is a mutually agreeable solution. Which i had expected from the beginning, but the text nevertheless became too suggestive of specific ways how to leverage MPTCP that where non-agreeable. Fixed now! [ Working for a vendor, i usually have to tell customers "don't describe the solution, describe the requirements". Takes sometimes longer to recognize when you are the customer. ] Also added the fix about need for end-to-end encryption (as brought up by BrianC earlier). Cheers toerless On Fri, Feb 02, 2018 at 10:00:34AM +0100, Mirja Kuehlewind (IETF) wrote: > Hi Toerless, > > see below again. > > > Am 01.02.2018 um 20:30 schrieb Toerless Eckert : > > > > On Thu, Feb 01, 2018 at 05:14:58PM +0100, Mirja Kuehlewind (IETF) wrote: > >>> If all data-plane flows fail, then it might suspend traffic. > >> > >> That will not happen with MPTCP; it will fail back to use the ACP connection (if there is a subflow for it). > > > > Right. This is one of the pieces that i think would require additional > > spec/extension to MPTCP - or could be handled by a shim library > > that gets enough notificatations from MPTCP. > > This is something that should not be done with MPTCP because that exactly not what MPTCP is meant for. In this case just use a standard TCP connection. And that???s my whole point. I see that there is a use case for MPTCP in you setup when fallback is needed but don???t use MPTCP if not needed and then don???t require changes to MPTCP that would make it behave like single TCP because that really not the design goal of MPTCP. > > > > > I was hoping we could move discussions about the "howto to an appropviate > > draft in the MPTCP WG, eg: the to-be-renewed socket draft i mentione din > > before. > > Yes, we really do not need to design the whole solution here. But I don???t want to discuss the use of MPTCP when it is not necessary to use MPTCP and more over I don???t want to phrase requirement for MPTCP that doesn???t make sense because it would be easier to just use TCP instead. > > > > >>> I think that there is some advantage to starting the connection on the ACP, > >>> because: > >>> a) no TCP SYN listener on the data-plane interface(s) reduces attack > >>> surface (assuming NOC->router initialized connections, but the same > >>> argument applies to keeping the NOC devices isolated) > >> > >> Also with MPTCP you need a TCP SYN lister on the remote data-plane interface because creating a MPTCP subflow means sending a TCP SYN with an MPTCP option. > > > > The data-plane subflow MPTCP SYN/ACK can ony happen after the GACP > > subflows ADD_ADDR, so one should be able to enable selective filtering > > of data-plane SYN packets based on the address learned from the ADD_ADDR. > > > > Can we somehow move all this discussion as mentioned above over to > > some good (hopefully standards track) target draft in MPTCP ? > > Stable connectivity is really just the informative use-case discussion > > draft and should be read as a requirements draft containing a > > high level description of the reasons why & how to use & expand MPTCP > > (and/or shim library). > > Yes, those details really don???t need to go in the draft. I was just replying to something Michael said. > > > > >> What I???m basically proposing is that you use MPTCP for case 1 (data that needs a fallback to the ACP connection) but for all other transmission (that should be done only over one of the paths, either data plane or ACP), you have additional plain TCP connections to use. You can still add an interface to MPTCP to extract the IP address information you need to start these additional connections. > > > > See my previous reply why i think there is no difference between 1) and > > 2) re the need to leverage MPTCP. > > And this is exactly my point and where we disagree. > > > As said above, the main difference IMHO > > is that "suspending or aborting" the connection upon failure of a subflow > > is seemingly new and would require additional work for MPTCP. > > I don???t this this should be a requirement for MPTCP and I don???t think this should be spell out in this draft as such because you can just use a TCP connection in this case. That???s the whole point. > > Mirja > > > > > > > Cheers > > Toerless > > > >> Mirja > >> > >>> > >>> So that's what MPTCP gets us: the ability to start on the ACP, do security, > >>> and then move the bulk traffic to another place. > >> > >>> > >>> -- > >>> ] Never tell me the odds! | ipv6 mesh networks [ > >>> ] Michael Richardson, Sandelman Software Works | network architect [ > >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > >>> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > -- > > --- > > tte@cs.fau.de > > From nobody Tue Feb 6 08:53:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1738612D856; Tue, 6 Feb 2018 08:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 wyLEU4haMGjh; Tue, 6 Feb 2018 08:53:21 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 27C2212702E; Tue, 6 Feb 2018 08:53:18 -0800 (PST) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w16Gn3vC016010; Tue, 6 Feb 2018 08:53:17 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=cVQPjSS6LvalPwbT03o/PYJ1wx9wEzHLCf4vBYlQoic=; b=LsYQPtJxAoLpYVdsotHxFZvoDcAw3MInduqwVMJvG7XYhLN9FgdYcHWDNMXal9K+vDjS ZelxJwOA9qGTuMu+FFKkkJqOZtN1PfwEjAD+qjJXeL1Ywbh15po8Eq3mpzuq49F9f696 LDFiEiiKhbILZCK/CaQIKPxlhHDPzBArQ+0X+c1kJTYj8EeW8SR3RpRLEGBZZV72n+fm C4EVXXAJq4KNDTXYFkN8WyGM3rI8j7QA/SyE7SHxFUDOO+MYdPd95Q9Wbc3DWV/vSeTI 1I8B8Mkva1I0vp+n6YIT/9C6cWcbxqGldF1Nj4y+TI3dMgajQsAkmQH1NTRzGzlIPOEe iQ== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) by mx0a-00273201.pphosted.com with ESMTP id 2fyeuer6ek-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 06 Feb 2018 08:53:16 -0800 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3594.namprd05.prod.outlook.com (10.174.242.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Tue, 6 Feb 2018 16:53:14 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0485.009; Tue, 6 Feb 2018 16:53:14 +0000 From: Kent Watsen To: Russ Housley , "gen-art@ietf.org" CC: "draft-ietf-anima-voucher.all@ietf.org" , "ietf@ietf.org" , "anima@ietf.org" Thread-Topic: Genart last call review of draft-ietf-anima-voucher-05 Thread-Index: AQHTPGi5q/3Pt4VbI0GC5GRZwJfxLKOYCVEA Date: Tue, 6 Feb 2018 16:53:14 +0000 Message-ID: References: <150704985762.30710.15389510349503177651@ietfa.amsl.com> In-Reply-To: <150704985762.30710.15389510349503177651@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3594; 7:D8g+Z1uI2pfHZmOyddx2f6TK7WNqJmKWhiRgP0TISlnjoHxT0jS1z1tXicGKNjcph3qGTnPx1jvRbTQcfkNE/EMC1sAZ5qoNP4mMuDffIorN0mFgsNrbquTAWkFscawczQgd06evTe5Fpj+R3pzWjMSPKdevZ7ypmnTmJXN4bbwmPumqoaGdU8Q+ZzcFWHE5Xcfj0VV7w7zRVUr0lzzKyxugcDhiMG6FjsJF0Lpxw0CYwdzpri2pCQhCF2OKJHqj x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1c47531b-d53c-4686-2afc-08d56d821d59 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3594; x-ms-traffictypediagnostic: DM5PR05MB3594: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(3002001)(6055026)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB3594; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3594; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(346002)(39380400002)(376002)(189003)(199004)(53754006)(51444003)(229853002)(83716003)(2950100002)(8936002)(3280700002)(2900100001)(106356001)(81166006)(14454004)(81156014)(8676002)(99286004)(76176011)(102836004)(26005)(3660700001)(186003)(54906003)(110136005)(6506007)(68736007)(4326008)(5660300001)(316002)(83506002)(478600001)(58126008)(77096007)(3846002)(7736002)(86362001)(305945005)(82746002)(6512007)(6436002)(6486002)(6116002)(105586002)(25786009)(2906002)(33656002)(36756003)(2501003)(53936002)(6246003)(97736004)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3594; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: tKIgsDIYKeZ7eflVo8LYP4NQ3jGbKWCYmFpzM+mHv/nawMPMzG0JBRL+iJ1D7wsGKaJNfnLnAcZYmW6y4PvDfQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 1c47531b-d53c-4686-2afc-08d56d821d59 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 16:53:14.7727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3594 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802060212 Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-voucher-05 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 16:53:23 -0000 SGkgYWxsLA0KDQpSdXNzJ3MgY29tbWVudCBsZWQgdG8gdGhlIGNyZWF0aW9uIG9mIGFuIGVDb250 ZW50VHlwZSBPSUQgY2FsbGVkDQppZC1jdC1hbmltYUpTT05Wb3VjaGVyLiAgR2l2ZW4gdGhhdCBZ QU5HIG1vZGVsZWQgZGF0YSBjYW4gYmUgDQplbmNvZGVkIGluIFhNTCBvciBKU09OLCBJIHRoaW5r IHRoYXQgd2UgbWFkZSBhIG1pc3Rha2UgaW4gb25seQ0KcmVnaXN0ZXJpbmcgdGhlIEpTT04gZW5j b2RpbmcuDQoNCkZXSVcsIHdlIG9yaWdpbmFsbHkgY2hvb3NlIHRvIHN0YW5kYXJkaXplIG9uIGp1 c3QgSlNPTiBiZWNhdXNlDQp3ZSB3ZXJlIHRyeWluZyB0byBhdm9pZCB0aGUgc2lnbmFsaW5nIGNv bXBsZXhpdHksIGV4YWN0bHkgd2hhdA0KdGhpcyBlQ29udGVudFR5cGUgdmFsdWUgcHJvdmlkZXMu ICBJdCBzZWVtcyB0aGF0LCB3aGVuIHdlIGFkZGVkDQp0aGUgT0lELCB3ZSBzaG91bGQndmUgcmVl eGFtaW5lZCB0aGF0IGVhcmxpZXIgZGVjaXNpb24uDQoNCldoaWxlIEknZCBsb3ZlIHRvIHNheSB0 aGF0IHRoZSBmaXggaXMganVzdCBhIG1hdHRlciByZWdpc3RlcmluZw0KYW5vdGhlciBPSUQsIHRo YXQgZHJhZnQgdXNlcyB0aGUgd29yZCAiSlNPTiIgdGhyb3VnaG91dCwgc28gYSANCnNsaWdodGx5 IG1vcmUgaW52b2x2ZWQgZWRpdCB3b3VsZCBiZSBuZWVkZWQuDQoNClRob3VnaHRzPyAgSXMgaXQg dG9vIGxhdGU/DQoNCktlbnQNCg0KDQo= From nobody Tue Feb 6 15:57:02 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706B4127871; Tue, 6 Feb 2018 15:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EAO0wka9I0O6; Tue, 6 Feb 2018 15:56:58 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF13B124BAC; Tue, 6 Feb 2018 15:56:58 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 81CEA58C4B6; Wed, 7 Feb 2018 00:56:54 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5DC18B0D9AB; Wed, 7 Feb 2018 00:56:54 +0100 (CET) Date: Wed, 7 Feb 2018 00:56:54 +0100 From: Toerless Eckert To: Kent Watsen Cc: Russ Housley , "gen-art@ietf.org" , "draft-ietf-anima-voucher.all@ietf.org" , "ietf@ietf.org" , "anima@ietf.org" Message-ID: <20180206235654.GA12332@faui40p.informatik.uni-erlangen.de> References: <150704985762.30710.15389510349503177651@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Genart last call review of draft-ietf-anima-voucher-05 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 23:57:01 -0000 I am voting for "don't". (Is there a vote ?). I can't find in https://datatracker.ietf.org/doc/review-ietf-anima-voucher-05-genart-lc-housley-2017-10-03/ anything suggesting that we should also describe support for XML in the document. Just the need to complete the spec with the necessary signaling elements to support JSON. I think to remember we (authors) didn't only specify JSON to avoid documenting the necessary signaling for XML, but also in an attempt to KISS, because elements like registrars likely would need to implementations all options. I also think we concluded that someone who strongly demanded XML would be given the opportunity to do this in followup work, because that would also give more time and opportunity to discuss/explain the insufficiency of JSON for whatever folks want to use XML for in that followup work. Similar logic to why we outsourced the voucher-request from the voucher draft into BRSKI. Cheers Toerless On Tue, Feb 06, 2018 at 04:53:14PM +0000, Kent Watsen wrote: > Hi all, > > Russ's comment led to the creation of an eContentType OID called > id-ct-animaJSONVoucher. Given that YANG modeled data can be > encoded in XML or JSON, I think that we made a mistake in only > registering the JSON encoding. > > FWIW, we originally choose to standardize on just JSON because > we were trying to avoid the signaling complexity, exactly what > this eContentType value provides. It seems that, when we added > the OID, we should've reexamined that earlier decision. > > While I'd love to say that the fix is just a matter registering > another OID, that draft uses the word "JSON" throughout, so a > slightly more involved edit would be needed. > > Thoughts? Is it too late? > > Kent > > -- --- tte@cs.fau.de From nobody Wed Feb 7 07:59:52 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A54512D7F3 for ; Wed, 7 Feb 2018 07:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 4ji3TqxSKqyD for ; Wed, 7 Feb 2018 07:59:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BB712D7ED for ; Wed, 7 Feb 2018 07:59:47 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B850E200A3 for ; Wed, 7 Feb 2018 11:06:19 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E632080E6E for ; Wed, 7 Feb 2018 10:59:45 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 15:59:50 -0000 --=-=-= Content-Type: text/plain Q1) Is there interest in doing bootstrap of devices/routers/etc. over WIFI? Q2) If there is, should the BRSKI document proscribe an Ad-Hoc (IBSS) ESSID on which bootstrap would be done (perhaps named "BRSKI" or "ANIMA"). Q3) Would you want to use this network as a substrate for the ACP later on? Q4) Should such a network be a) unsecured (cleartext) b) use WPA-PSK with a known "network key" b) use WPA2 enterprise 802.1X using a published username/password. (like we use for ietf network) This is no less secure than unsecured, but unlike (b), each session gets a unique session key. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlp7InAACgkQgItw+93Q 3WXW2gf/dOv4kX3B29NSUeZDaMyC2+xNZwcFNlP1fk6lhoDBR/P+PCnhgDpEz4U2 sqZv0c2TUSvBX92xX+UTLri5hRbR5Q3DJEBYsOUbdzaFhlVwR4a8k37BEp3LHMSe 8eaoL75Ko3muavVzLK93+UTrkYrepwbkqyZeeoYu1daE3Yu2Hu07dNy2zwYYEzo5 WzmM2lihDUxBeKSkGp4Vq8S9urt5lLjAiz+g2ph64DzKrMQ93D38zw8NOoP1WIA7 n0M6DUN3iQnM2whI5Nel3mXGKg+Vk4OFuZcRCpDh0tfCN7sDEakMSlXxAAXLvBph fnufM3NthaujKGel6IQRtt625F66wQ== =ITxr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 7 08:00:28 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CC612D7F2 for ; Wed, 7 Feb 2018 08:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 IUijVag-pwQk for ; Wed, 7 Feb 2018 08:00:23 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8242312E038 for ; Wed, 7 Feb 2018 08:00:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5ABFD200A3 for ; Wed, 7 Feb 2018 11:06:55 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A72BD80E6E for ; Wed, 7 Feb 2018 11:00:21 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:00:27 -0000 <#secure method=pgpmime mode=sign> Q1) Is there interest in doing bootstrap of devices/routers/etc. over WIFI? Q2) If there is, should the BRSKI document proscribe an Ad-Hoc (IBSS) ESSID on which bootstrap would be done (perhaps named "BRSKI" or "ANIMA"). Q3) Would you want to use this network as a substrate for the ACP later on? Q4) Should such a network be a) unsecured (cleartext) b) use WPA-PSK with a known "network key" b) use WPA2 enterprise 802.1X using a published username/password. (like we use for ietf network) This is no less secure than unsecured, but unlike (b), each session gets a unique session key. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Wed Feb 7 09:22:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5703A1270AC for ; Wed, 7 Feb 2018 09:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 b-mtrD0qcPLy for ; Wed, 7 Feb 2018 09:22:05 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 445901242F7 for ; Wed, 7 Feb 2018 09:22:05 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6A6BFA735E19 for ; Wed, 7 Feb 2018 17:22:00 +0000 (GMT) Received: from LHREML501-MBX.china.huawei.com ([10.201.109.49]) by lhreml705-cah.china.huawei.com ([10.201.108.46]) with mapi id 14.03.0361.001; Wed, 7 Feb 2018 17:22:00 +0000 From: Artur Hecker To: "anima@ietf.org" Thread-Topic: [Anima] BRSKI over 802.11 Thread-Index: AQHToCzH9KloDjb5LkykD0MbGTGA66OZKmRw Date: Wed, 7 Feb 2018 17:21:59 +0000 Message-ID: <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> References: <32587.1518019185@obiwan.sandelman.ca> In-Reply-To: <32587.1518019185@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 17:22:07 -0000 Hi Michael, My opinion: Q1: In principle, I believe that it would make sense to do it. However, a d= ifferent question is whether ANIMA WG of the IETF is the right place for it= . For instance, the integration of WPA-Enterprise you mentioned had been do= ne by the WiFi-Alliance, albeit heavily relying on IETF protocols (RADIUS, = PPP, EAP, Microsoft's MPPE, VSAs, etc). Q2: Specifically, the relevant issues would seem to rather fall into the sc= ope of IEEE 802.1 (for the supplicant), IEEE 802.11 (for the wireless clien= t) or of the WiFi Alliance (for integration, etc). We need to consider thei= r way(s) of specifying all that. For instance, one could argue that the boo= tstrapping should be done over the DS, whereas whether the DS itself is wir= eless or not should not play any role. In this case, I believe it would be = wrong to define ESSIDs or modes of operation of 802.11, because it's extrem= ely biased. I am not even talking about OAM, because I do not want troubles= :-) Q3: Sorry, I did not quite understand this one. If you meant the ad-hoc ess= id based network, my first intuition would be to object, as I believe that = we should not prescribe such modes for ACP, but rather use the best availab= le one. Q4: As I believe that Q2 is strongly biased, I believe that so is Q4. The W= iFi Alliance already specifies several ways how to bootstrap wireless acces= s points, including e.g. WPS. We would rather need to see, how to integrate= with such means. And again, I don't believe we have authority on that. Regards artur > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael=20 > Richardson > Sent: 07 February 2018 17:00 > To: anima@ietf.org > Subject: [Anima] BRSKI over 802.11 >=20 >=20 > Q1) Is there interest in doing bootstrap of devices/routers/etc. over WIF= I? >=20 > Q2) If there is, should the BRSKI document proscribe an Ad-Hoc (IBSS) ESS= ID > on which bootstrap would be done (perhaps named "BRSKI" or "ANIMA"). >=20 > Q3) Would you want to use this network as a substrate for the ACP later o= n? >=20 > Q4) Should such a network be > a) unsecured (cleartext) > b) use WPA-PSK with a known "network key" > b) use WPA2 enterprise 802.1X using a published username/password. > (like we use for ietf network) > This is no less secure than unsecured, but unlike (b), each > session gets a unique session key. >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ From nobody Wed Feb 7 10:52:58 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742871270B4; Wed, 7 Feb 2018 10:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 gyZWtB_nduD4; Wed, 7 Feb 2018 10:52:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B42124239; Wed, 7 Feb 2018 10:52:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 68415200A3; Wed, 7 Feb 2018 13:59:16 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5098980E6E; Wed, 7 Feb 2018 13:52:42 -0500 (EST) From: Michael Richardson To: iot-dir CC: anima@ietf.org, 6tisch@ietf.org, ace@ietf.org In-Reply-To: <151802189682.4857.6673059210006508673.idtracker@ietfa.amsl.com> References: <151802189682.4857.6673059210006508673.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] changes to draft-richardson-enrollment-roadmap-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:52:46 -0000 --=-=-= Content-Type: text/plain Htmlized: https://datatracker.ietf.org/doc/html/draft-richardson-enrollment-roadmap-01 diff: https://www.ietf.org/rfcdiff?url2=draft-richardson-enrollment-roadmap-01 I posted an -01 of the enrollment roadmap document. The intro says: There are numerous mechanisms being proposed to solve the problem of securely introducing a new devices into an existing managed network. This document provides an overview of the different mechanisms showing what technologies are common. The document starts with a diagram showing the various components and how they go together to form five enrollment scenarios. The work crosses many groups, but does not fit into any of them. The document might be good as a way to keep track of things, but may not be worth publishing. Yes, could go the wiki way, but I find it significantly less satisfying. In particular I'd like to include guidance on why one process vs another, which I think would be worth preserving. On the other hand, there are sections explaining which documents are of cross-WG interest, and if they have been adopted in any place (or not!!). That's really ephermeral information that doesn't belong in an RFC until it's been resolved. It would also be nice to have a different name than "Transition to Constrained Enrollment" that more accurately reflected the interests of that group of deployers (it includes Lighting/Fairhair, and electricity-AMI/Itron/Cisco.) If there are those who want to review/contribute to it, https://github.com/anima-wg/enrollment-roadmap.git might be the best place to send pull requests. I'm personally not enthralled by using github issues for discussion (I prefer email lists), but I don't object to it. If there is interest in publishing it, my suggestion is to use iot-dir to get some beef into it, and then submit as an AD-sponsored document. Alternatively saag. I think that the document should expand by about 4 pages of discussion, and then sit in stasis for awhile. The most significant change in -01 is that I changed how the boxes around the ascii art diagram are rendered. I hope that it is more readable that way. {If you haven't tried "asciio", I suggest you try it out.} Other than that, more text in the sections. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlp7SvkACgkQgItw+93Q 3WUPQwf/dIn2DMqtwO0/DWFJr1p5ilwkqsDkRPhkvzyQc/O6gzjw205RxZo8JL5W rAgLcx4e1OsRHaZgTSQmcMJVdL6rEDBBJPHuEIR2bmfPnBJjyZOUZGic6D38FZ44 nEhcm2r3Zewxhhu6QMica++TycKQi46Ceq20fkZuqm7qjahAdAvN5JaT5jdcQt0C i27aFqmMOrdu2xKy7Y13ajBkHplOteMBBuOm5ks70lLEhjil91yqeBXt5wg5Smze cOgfADdTHDuiTX77uIAEGMEchQeo+2eU61KrhdslwJ6L06S/AFNLNOLWAwCel/Kw BG9JxjCNRqhH1zPIr6qu/0H6WxOWBA== =SVmQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 7 11:06:36 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F276127275 for ; Wed, 7 Feb 2018 11:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 kLn5H_4CSD5b for ; Wed, 7 Feb 2018 11:06:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22384126C25 for ; Wed, 7 Feb 2018 11:06:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3013E200A3; Wed, 7 Feb 2018 14:13:04 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0CAF580E6E; Wed, 7 Feb 2018 14:06:30 -0500 (EST) From: Michael Richardson To: Artur Hecker cc: "anima\@ietf.org" In-Reply-To: <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 19:06:35 -0000 --=-=-= Content-Type: text/plain Artur Hecker wrote: > Hi Michael, > My opinion: I don't think understood the question :-) 1) It's not about Wireless Access Points, so all of the Wifi Alliance, etc. talk makes no sense to me. There can be no access points until they have been configured. It's possible that there might NEVER been any access points, because the operator actually doesn't want/need any enabled. Think about inside of a cage in a data center. 2) It's about *devices* that have 802.11 interfaces. You can't use WPS or anything else involving 802.1x until you have credentials, which is what BRSKI gets you. So you can't use WPS to *bootstrap* WPS. (and pushing buttons on the front of the AP is by definition not "zero-touch") > Q3: Sorry, I did not quite understand this one. If you meant the ad-hoc > essid based network, my first intuition would be to object, as I > believe that we should not prescribe such modes for ACP, but rather use > the best available one. 3) The ACP is secured inside IPsec over Link-Layer IPv6 (or MACSEC, or a bunch of other possible technologies in the ACP document). It's not about the security of the ACP. Since the point of the ACP is that it's always available, it needs to be available even when the Wifi Access Point is toast or not yet configured. Of course, once there is a non-adhoc/IBSS network available, the ACP would see this as additional interfaces and make additional mesh links across it for the ACP to use. But that's not bootstrap, that's operation. > Q4: As I believe that Q2 is strongly biased, I believe that so is > Q4. The WiFi Alliance already specifies several ways how to bootstrap > wireless access points, including e.g. WPS. We would rather need to > see, how to integrate with such means. And again, I don't believe we > have authority on that. Maybe you could point to specific documents that would permit two devices which have never been touched to communicate over 802.11 without configuration. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlp7TjUACgkQgItw+93Q 3WUxPAf/RwmqKkzp0+LwJJSXRSP2fs+kWObwMTkx2Otk/2WSjCuMEHiE7S/2ygje E4eX6vaUeEp+Lpg+MHmqQa0PRGWfeQFQLXDQ8kJVgyw/eJVwM15aS5reEfrZbfNt RVk3HNlMjiCGhYEbE8FCECRG0VzLEx5xQvVyNj+gAatJBpjugaY4eH2UcUcMqs46 O/IouhDY4hjJm9QshtH5WIBtUnYEm4hFBBOEpwIdw/E5hnK0ZnhxD+hxeCMqCNjb zctSif/wg+wg7oSfaquWEmElUb6nYdpK4rf6IzbT6M8m7yraA5ED+17qssoOOaS5 c8DYv+BJtF0rofYkExKuHl6ufUmIFQ== =my0Y -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 8 01:24:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB5D12D874 for ; Thu, 8 Feb 2018 01:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 imW69HQVYjy9 for ; Thu, 8 Feb 2018 01:24:52 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 9A9EE12D86D for ; Thu, 8 Feb 2018 01:24:52 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 204F0747F456 for ; Thu, 8 Feb 2018 09:24:49 +0000 (GMT) Received: from LHREML501-MBX.china.huawei.com ([10.201.109.49]) by lhreml707-cah.china.huawei.com ([10.201.108.48]) with mapi id 14.03.0361.001; Thu, 8 Feb 2018 09:24:47 +0000 From: Artur Hecker To: "anima@ietf.org" Thread-Topic: [Anima] BRSKI over 802.11 Thread-Index: AQHToCzH9KloDjb5LkykD0MbGTGA66OZKmRwgAAiyACAAOsFkA== Date: Thu, 8 Feb 2018 09:24:47 +0000 Message-ID: <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> In-Reply-To: <11509.1518030390@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 09:24:54 -0000 Hi Michael Sorry, maybe I misunderstood the intention. Is your intention to make it "s= tandard" or just to make a demonstration? If the latter, then it's OK. It's= the first that I simply doubt it will work. I am not claiming that there are better means to do that, let alone that wh= at you proposed makes no sense. I actually said that this makes sense. I ju= st think that we enter the realms of 802.1 and 802.11 at the same time and = have no authority there. It has indeed nothing to do with Wireless access points. Any STA (802.11) a= nd any supplicant (802.1X) is subject to standardization and regulation of = the bodies of IEEE, in any mode of operation. WPS should not be limited to = any Access Point presence, since it supports WiFi Direct. I agree, the supp= orted methods are rudimentary. If I remember correctly, something like PIN,= the push button you mentioned, NFC and USB. I guess, a possibility would be to specify an additional ANIMA/ACP/BRSKI me= thod for WPS, why not. All I am saying is that we probably need to do it th= ere, as any try to do it in the ANIMA WG would require specific 802.11 mode= s and specific 802.1X functions/behaviours, which I am not sure we can dict= ate to have. Regards artur > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: 07 February 2018 20:07 > To: Artur Hecker > Cc: anima@ietf.org > Subject: Re: [Anima] BRSKI over 802.11 >=20 >=20 > Artur Hecker wrote: > > Hi Michael, > > My opinion: >=20 > I don't think understood the question :-) >=20 > 1) It's not about Wireless Access Points, so all of the Wifi Alliance, > etc. talk makes no sense to me. There can be no access points until t= hey > have been configured. It's possible that there might NEVER been any > access points, because the operator actually doesn't want/need any > enabled. > Think about inside of a cage in a data center. >=20 > 2) It's about *devices* that have 802.11 interfaces. > You can't use WPS or anything else involving 802.1x until you have > credentials, which is what BRSKI gets you. > So you can't use WPS to *bootstrap* WPS. > (and pushing buttons on the front of the AP is by definition not "zero= - > touch") >=20 > > Q3: Sorry, I did not quite understand this one. If you meant the ad= -hoc > > essid based network, my first intuition would be to object, as I > > believe that we should not prescribe such modes for ACP, but rather= use > > the best available one. >=20 > 3) The ACP is secured inside IPsec over Link-Layer IPv6 (or MACSEC, or > a bunch of other possible technologies in the ACP document). > It's not about the security of the ACP. >=20 > Since the point of the ACP is that it's always available, it needs to be = available > even when the Wifi Access Point is toast or not yet configured. > Of course, once there is a non-adhoc/IBSS network available, the ACP woul= d > see this as additional interfaces and make additional mesh links across i= t for > the ACP to use. But that's not bootstrap, that's operation. >=20 > > Q4: As I believe that Q2 is strongly biased, I believe that so is > > Q4. The WiFi Alliance already specifies several ways how to bootstr= ap > > wireless access points, including e.g. WPS. We would rather need to > > see, how to integrate with such means. And again, I don't believe w= e > > have authority on that. >=20 > Maybe you could point to specific documents that would permit two devices > which have never been touched to communicate over 802.11 without > configuration. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Feb 8 01:51:32 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ECC12D885 for ; Thu, 8 Feb 2018 01:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 g85x_ES6fZJs for ; Thu, 8 Feb 2018 01:51:18 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CB81200C1 for ; Thu, 8 Feb 2018 01:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5880; q=dns/txt; s=iport; t=1518083478; x=1519293078; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=6Z8tuaPt1M1rKbcdOpcCgFp03hG79mdW1NSZuV3t3W8=; b=E9mu288Q/dnCL9zdUHTMovmMTjqiN7lnUiTTAGlS6PhMLLlOrz4J3fvf EfjdSocLVVrt9Nkp++dstxl6YJqaumSDbOki+P2JSk3tuRJnH0UnzwCmm 4HBeBPDHoxce4lrO4DS80ZkSP6PC1eJByH1C8kBJLrdRNe2c/mPuwSmDu g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQCxHHxa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ3cCiDZYsYjw0nmXAHAxgLgV6DOgKDRhQBAgEBAQEBAQJrKIU?= =?us-ascii?q?jAQEBBAEBIUsXBAsRBAEBAScDAgInHwkIBgEMBgIBAYoxEK9jgieFAIN3ggoBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEOCgWEdYVUKQyBa4EOgy8BAQKBSIM+gmUFpCs?= =?us-ascii?q?JhGaCMo5kjDiIBpgLgTw2IoFQMxoIGxU9gkaCVRyCB0A3izuCSwEBAQ?= X-IronPort-AV: E=Sophos; i="5.46,477,1511827200"; d="asc'?scan'208"; a="1937946" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2018 09:51:15 +0000 Received: from [10.61.225.27] ([10.61.225.27]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w189pFSQ011952; Thu, 8 Feb 2018 09:51:15 GMT To: Artur Hecker , "anima@ietf.org" References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> From: Eliot Lear Message-ID: Date: Thu, 8 Feb 2018 10:51:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lvsSlD2Hv9iaGlQk9rP93JUNTssqG5qL2" Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 09:51:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lvsSlD2Hv9iaGlQk9rP93JUNTssqG5qL2 Content-Type: multipart/mixed; boundary="RurWAPNAIUXLQxdLJa9QIdvnU8tjx82S9"; protected-headers="v1" From: Eliot Lear To: Artur Hecker , "anima@ietf.org" Message-ID: Subject: Re: [Anima] BRSKI over 802.11 References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> In-Reply-To: <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> --RurWAPNAIUXLQxdLJa9QIdvnU8tjx82S9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Artur, I suspect much =E2=80=93 but not all =E2=80=93 of this could be addressed= in EAP. Eliot On 08.02.18 10:24, Artur Hecker wrote: > Hi Michael > > > Sorry, maybe I misunderstood the intention. Is your intention to make i= t "standard" or just to make a demonstration? If the latter, then it's OK= =2E It's the first that I simply doubt it will work. > > I am not claiming that there are better means to do that, let alone tha= t what you proposed makes no sense. I actually said that this makes sense= =2E I just think that we enter the realms of 802.1 and 802.11 at the same= time and have no authority there. > > It has indeed nothing to do with Wireless access points. Any STA (802.1= 1) and any supplicant (802.1X) is subject to standardization and regulati= on of the bodies of IEEE, in any mode of operation. WPS should not be lim= ited to any Access Point presence, since it supports WiFi Direct. I agree= , the supported methods are rudimentary. If I remember correctly, somethi= ng like PIN, the push button you mentioned, NFC and USB. > > I guess, a possibility would be to specify an additional ANIMA/ACP/BRSK= I method for WPS, why not. All I am saying is that we probably need to do= it there, as any try to do it in the ANIMA WG would require specific 802= =2E11 modes and specific 802.1X functions/behaviours, which I am not sure= we can dictate to have. > > > Regards > artur > > > >> -----Original Message----- >> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] >> Sent: 07 February 2018 20:07 >> To: Artur Hecker >> Cc: anima@ietf.org >> Subject: Re: [Anima] BRSKI over 802.11 >> >> >> Artur Hecker wrote: >> > Hi Michael, >> > My opinion: >> >> I don't think understood the question :-) >> >> 1) It's not about Wireless Access Points, so all of the Wifi Alliance,= >> etc. talk makes no sense to me. There can be no access points unti= l they >> have been configured. It's possible that there might NEVER been an= y >> access points, because the operator actually doesn't want/need any >> enabled. >> Think about inside of a cage in a data center. >> >> 2) It's about *devices* that have 802.11 interfaces. >> You can't use WPS or anything else involving 802.1x until you have >> credentials, which is what BRSKI gets you. >> So you can't use WPS to *bootstrap* WPS. >> (and pushing buttons on the front of the AP is by definition not "z= ero- >> touch") >> >> > Q3: Sorry, I did not quite understand this one. If you meant the= ad-hoc >> > essid based network, my first intuition would be to object, as I= >> > believe that we should not prescribe such modes for ACP, but rat= her use >> > the best available one. >> >> 3) The ACP is secured inside IPsec over Link-Layer IPv6 (or MACSEC, or= >> a bunch of other possible technologies in the ACP document). >> It's not about the security of the ACP. >> >> Since the point of the ACP is that it's always available, it needs to = be available >> even when the Wifi Access Point is toast or not yet configured. >> Of course, once there is a non-adhoc/IBSS network available, the ACP w= ould >> see this as additional interfaces and make additional mesh links acros= s it for >> the ACP to use. But that's not bootstrap, that's operation. >> >> > Q4: As I believe that Q2 is strongly biased, I believe that so i= s >> > Q4. The WiFi Alliance already specifies several ways how to boot= strap >> > wireless access points, including e.g. WPS. We would rather need= to >> > see, how to integrate with such means. And again, I don't believ= e we >> > have authority on that. >> >> Maybe you could point to specific documents that would permit two devi= ces >> which have never been touched to communicate over 802.11 without >> configuration. >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --RurWAPNAIUXLQxdLJa9QIdvnU8tjx82S9-- --lvsSlD2Hv9iaGlQk9rP93JUNTssqG5qL2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlp8HZAACgkQh7ZrRtnS ejPW5Af/YBb9BPw/I8xzXpZBM3uQ1kGMlntZQFQEXyGY2D15PrtdhbMv1/OFgemr J3PxZMA8KyqzUcRRW1eMjaZf8puKZXmnp/+BNBMD1TSZiMo1PAEIpgw7/Fcf350s mJ4pgMFFtChoxuW+we1aJDVjJGzcVeVs41ge+Yxr40beKlEg86hfupLb6pT9j7bP /1pdPzK8QilLldrxRVFLPFVl475g9mtFtWN3/JsDGZEvG5l9GAE2jgZqJtGokdEw wEUmDemOCZ+unpdR97DzwrKUIcN4Us1UZRhu9HhNM+HvUqnKHvxh9UicRK6dV2Cd 4Owthy+K2xXMmmx3M741tbv17W/XSw== =Ectx -----END PGP SIGNATURE----- --lvsSlD2Hv9iaGlQk9rP93JUNTssqG5qL2-- From nobody Fri Feb 9 04:43:45 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1243A120727 for ; Fri, 9 Feb 2018 04:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 amzC11tmfFgY for ; Fri, 9 Feb 2018 04:43:36 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB85127775 for ; Fri, 9 Feb 2018 04:43:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=VHODz1AX0bQyjYrxXgmGkREZ/1DCJDJxSznmVch8pziF2UBYXl8Whu91Ig/fltFFO/gAEJeeez0lcJuuKLF0gezad5H3K5xErbmaR/gV22+r94lXmbZCBKEB96tSjuFTDnCWdp52X2rzPBg8ZBz/tAo/xGUjRLWLuzKokqLfVFg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 27274 invoked from network); 9 Feb 2018 13:42:33 +0100 Received: from mue-88-130-61-231.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.231) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 9 Feb 2018 13:42:33 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20180206025257.GG2643@faui40p.informatik.uni-erlangen.de> Date: Fri, 9 Feb 2018 13:42:32 +0100 Cc: Michael Richardson , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180117023655.GA26698@faui40p.informatik.uni-erlangen.de> <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> <20180201193027.GD2643@faui40p.informatik.uni-erlangen.de> <20180206025257.GG2643@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180209124233.27264.28708@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 12:43:40 -0000 Thanks! I think know we really captured everything. Thanks for writing = this up clearly! Will release my discuss now! Mirja > Am 06.02.2018 um 03:52 schrieb Toerless Eckert : >=20 > Thanks Mirja, also for our talk earlier today. >=20 > -10 just posted. >=20 > https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-10.txt >=20 > = http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools.ietf= .org/id/draft-ietf-anima-stable-connectivity-09.txt&url2=3Dhttps://tools.i= etf.org/id/draft-ietf-anima-stable-connectivity-10.txt >=20 > As discussed today, and to summarize for the thread here: >=20 > As changelog explains, i changed the wording of the multipath text to > be a set of requirements and not to suggest specific ways how to use > MPTCP. Without changing the scope & goal of the multipath text, this > was IMHO the correct approach because through the review from Mirja = and > Yoshi it became clear that there is more work to be done before there > is a mutually agreeable solution. Which i had expected from the = beginning, > but the text nevertheless became too suggestive of specific ways how = to=20 > leverage MPTCP that where non-agreeable. Fixed now! >=20 > [ Working for a vendor, i usually have to tell customers > "don't describe the solution, describe the requirements". Takes=20 > sometimes longer to recognize when you are the customer. ] >=20 > Also added the fix about need for end-to-end encryption (as brought up > by BrianC earlier).=20 >=20 > Cheers > toerless >=20 >=20 >=20 > On Fri, Feb 02, 2018 at 10:00:34AM +0100, Mirja Kuehlewind (IETF) = wrote: >> Hi Toerless,=20 >>=20 >> see below again. >>=20 >>> Am 01.02.2018 um 20:30 schrieb Toerless Eckert : >>>=20 >>> On Thu, Feb 01, 2018 at 05:14:58PM +0100, Mirja Kuehlewind (IETF) = wrote: >>>>> If all data-plane flows fail, then it might suspend traffic. >>>>=20 >>>> That will not happen with MPTCP; it will fail back to use the ACP = connection (if there is a subflow for it). >>>=20 >>> Right. This is one of the pieces that i think would require = additional >>> spec/extension to MPTCP - or could be handled by a shim library >>> that gets enough notificatations from MPTCP. >>=20 >> This is something that should not be done with MPTCP because that = exactly not what MPTCP is meant for. In this case just use a standard = TCP connection. And that???s my whole point. I see that there is a use = case for MPTCP in you setup when fallback is needed but don???t use = MPTCP if not needed and then don???t require changes to MPTCP that would = make it behave like single TCP because that really not the design goal = of MPTCP.=20 >>=20 >>>=20 >>> I was hoping we could move discussions about the "howto to an = appropviate >>> draft in the MPTCP WG, eg: the to-be-renewed socket draft i mentione = din >>> before. >>=20 >> Yes, we really do not need to design the whole solution here. But I = don???t want to discuss the use of MPTCP when it is not necessary to use = MPTCP and more over I don???t want to phrase requirement for MPTCP that = doesn???t make sense because it would be easier to just use TCP instead. >>=20 >>>=20 >>>>> I think that there is some advantage to starting the connection on = the ACP, >>>>> because: >>>>> a) no TCP SYN listener on the data-plane interface(s) reduces = attack >>>>> surface (assuming NOC->router initialized connections, but the = same >>>>> argument applies to keeping the NOC devices isolated) >>>>=20 >>>> Also with MPTCP you need a TCP SYN lister on the remote data-plane = interface because creating a MPTCP subflow means sending a TCP SYN with = an MPTCP option. >>>=20 >>> The data-plane subflow MPTCP SYN/ACK can ony happen after the GACP >>> subflows ADD_ADDR, so one should be able to enable selective = filtering >>> of data-plane SYN packets based on the address learned from the = ADD_ADDR. >>>=20 >>> Can we somehow move all this discussion as mentioned above over to >>> some good (hopefully standards track) target draft in MPTCP ?=20 >>> Stable connectivity is really just the informative use-case = discussion >>> draft and should be read as a requirements draft containing a >>> high level description of the reasons why & how to use & expand = MPTCP >>> (and/or shim library). >>=20 >> Yes, those details really don???t need to go in the draft. I was just = replying to something Michael said. >>=20 >>>=20 >>>> What I???m basically proposing is that you use MPTCP for case 1 = (data that needs a fallback to the ACP connection) but for all other = transmission (that should be done only over one of the paths, either = data plane or ACP), you have additional plain TCP connections to use. = You can still add an interface to MPTCP to extract the IP address = information you need to start these additional connections. >>>=20 >>> See my previous reply why i think there is no difference between 1) = and >>> 2) re the need to leverage MPTCP. >>=20 >> And this is exactly my point and where we disagree. >>=20 >>> As said above, the main difference IMHO >>> is that "suspending or aborting" the connection upon failure of a = subflow >>> is seemingly new and would require additional work for MPTCP. >>=20 >> I don???t this this should be a requirement for MPTCP and I don???t = think this should be spell out in this draft as such because you can = just use a TCP connection in this case. That???s the whole point. >>=20 >> Mirja >>=20 >>=20 >>=20 >>>=20 >>> Cheers >>> Toerless >>>=20 >>>> Mirja >>>>=20 >>>>>=20 >>>>> So that's what MPTCP gets us: the ability to start on the ACP, do = security, >>>>> and then move the bulk traffic to another place. >>>>=20 >>>>>=20 >>>>> -- >>>>> ] Never tell me the odds! | ipv6 = mesh networks [ >>>>> ] Michael Richardson, Sandelman Software Works | network = architect [ >>>>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby = on rails [ >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>>=20 >>> --=20 >>> --- >>> tte@cs.fau.de >>>=20 >=20 From nobody Fri Feb 9 04:44:47 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85621120727; Fri, 9 Feb 2018 04:44:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-anima-stable-connectivity@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151818028153.1288.7713702960575393914.idtracker@ietfa.amsl.com> Date: Fri, 09 Feb 2018 04:44:41 -0800 Archived-At: Subject: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-anima-stable-connectivity-10=3A_=28with_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 12:44:41 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-anima-stable-connectivity-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss by rather describing requirements for the transport than scratching out an MPTCP-based solution! I like the new text! Also thanks again to Yoshi for the TSV review! From nobody Fri Feb 9 12:24:43 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701A4127286; Fri, 9 Feb 2018 12:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 LgRXtiUmUiwk; Fri, 9 Feb 2018 12:24:38 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F8B1242F7; Fri, 9 Feb 2018 12:24:38 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7054A58C514; Fri, 9 Feb 2018 21:24:33 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 55170B0D9F1; Fri, 9 Feb 2018 21:24:33 +0100 (CET) Date: Fri, 9 Feb 2018 21:24:33 +0100 From: Toerless Eckert To: "Mirja Kuehlewind (IETF)" Cc: Michael Richardson , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, jiangsheng@huawei.com Message-ID: <20180209202433.GA6162@faui40p.informatik.uni-erlangen.de> References: <20180122184249.GA350@faui40p.informatik.uni-erlangen.de> <9F15790E-16CC-4F25-BA4F-A2727B670749@kuehlewind.net> <20180126230651.GA8651@faui40p.informatik.uni-erlangen.de> <16471.1517499116@obiwan.sandelman.ca> <24448077-F539-4597-B047-C345B8197CA8@kuehlewind.net> <20180201193027.GD2643@faui40p.informatik.uni-erlangen.de> <20180206025257.GG2643@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Mirja Kuehlewind's Discuss on draft-ietf-anima-stable-connectivity-07: (with DISCUSS) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 20:24:41 -0000 Thanks, Mirja On Fri, Feb 09, 2018 at 01:42:32PM +0100, Mirja Kuehlewind (IETF) wrote: > Thanks! I think know we really captured everything. Thanks for writing this up clearly! Will release my discuss now! > > Mirja > > > > > Am 06.02.2018 um 03:52 schrieb Toerless Eckert : > > > > Thanks Mirja, also for our talk earlier today. > > > > -10 just posted. > > > > https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-10.txt > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-09.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-10.txt > > > > As discussed today, and to summarize for the thread here: > > > > As changelog explains, i changed the wording of the multipath text to > > be a set of requirements and not to suggest specific ways how to use > > MPTCP. Without changing the scope & goal of the multipath text, this > > was IMHO the correct approach because through the review from Mirja and > > Yoshi it became clear that there is more work to be done before there > > is a mutually agreeable solution. Which i had expected from the beginning, > > but the text nevertheless became too suggestive of specific ways how to > > leverage MPTCP that where non-agreeable. Fixed now! > > > > [ Working for a vendor, i usually have to tell customers > > "don't describe the solution, describe the requirements". Takes > > sometimes longer to recognize when you are the customer. ] > > > > Also added the fix about need for end-to-end encryption (as brought up > > by BrianC earlier). > > > > Cheers > > toerless > > > > > > > > On Fri, Feb 02, 2018 at 10:00:34AM +0100, Mirja Kuehlewind (IETF) wrote: > >> Hi Toerless, > >> > >> see below again. > >> > >>> Am 01.02.2018 um 20:30 schrieb Toerless Eckert : > >>> > >>> On Thu, Feb 01, 2018 at 05:14:58PM +0100, Mirja Kuehlewind (IETF) wrote: > >>>>> If all data-plane flows fail, then it might suspend traffic. > >>>> > >>>> That will not happen with MPTCP; it will fail back to use the ACP connection (if there is a subflow for it). > >>> > >>> Right. This is one of the pieces that i think would require additional > >>> spec/extension to MPTCP - or could be handled by a shim library > >>> that gets enough notificatations from MPTCP. > >> > >> This is something that should not be done with MPTCP because that exactly not what MPTCP is meant for. In this case just use a standard TCP connection. And that???s my whole point. I see that there is a use case for MPTCP in you setup when fallback is needed but don???t use MPTCP if not needed and then don???t require changes to MPTCP that would make it behave like single TCP because that really not the design goal of MPTCP. > >> > >>> > >>> I was hoping we could move discussions about the "howto to an appropviate > >>> draft in the MPTCP WG, eg: the to-be-renewed socket draft i mentione din > >>> before. > >> > >> Yes, we really do not need to design the whole solution here. But I don???t want to discuss the use of MPTCP when it is not necessary to use MPTCP and more over I don???t want to phrase requirement for MPTCP that doesn???t make sense because it would be easier to just use TCP instead. > >> > >>> > >>>>> I think that there is some advantage to starting the connection on the ACP, > >>>>> because: > >>>>> a) no TCP SYN listener on the data-plane interface(s) reduces attack > >>>>> surface (assuming NOC->router initialized connections, but the same > >>>>> argument applies to keeping the NOC devices isolated) > >>>> > >>>> Also with MPTCP you need a TCP SYN lister on the remote data-plane interface because creating a MPTCP subflow means sending a TCP SYN with an MPTCP option. > >>> > >>> The data-plane subflow MPTCP SYN/ACK can ony happen after the GACP > >>> subflows ADD_ADDR, so one should be able to enable selective filtering > >>> of data-plane SYN packets based on the address learned from the ADD_ADDR. > >>> > >>> Can we somehow move all this discussion as mentioned above over to > >>> some good (hopefully standards track) target draft in MPTCP ? > >>> Stable connectivity is really just the informative use-case discussion > >>> draft and should be read as a requirements draft containing a > >>> high level description of the reasons why & how to use & expand MPTCP > >>> (and/or shim library). > >> > >> Yes, those details really don???t need to go in the draft. I was just replying to something Michael said. > >> > >>> > >>>> What I???m basically proposing is that you use MPTCP for case 1 (data that needs a fallback to the ACP connection) but for all other transmission (that should be done only over one of the paths, either data plane or ACP), you have additional plain TCP connections to use. You can still add an interface to MPTCP to extract the IP address information you need to start these additional connections. > >>> > >>> See my previous reply why i think there is no difference between 1) and > >>> 2) re the need to leverage MPTCP. > >> > >> And this is exactly my point and where we disagree. > >> > >>> As said above, the main difference IMHO > >>> is that "suspending or aborting" the connection upon failure of a subflow > >>> is seemingly new and would require additional work for MPTCP. > >> > >> I don???t this this should be a requirement for MPTCP and I don???t think this should be spell out in this draft as such because you can just use a TCP connection in this case. That???s the whole point. > >> > >> Mirja > >> > >> > >> > >>> > >>> Cheers > >>> Toerless > >>> > >>>> Mirja > >>>> > >>>>> > >>>>> So that's what MPTCP gets us: the ability to start on the ACP, do security, > >>>>> and then move the bulk traffic to another place. > >>>> > >>>>> > >>>>> -- > >>>>> ] Never tell me the odds! | ipv6 mesh networks [ > >>>>> ] Michael Richardson, Sandelman Software Works | network architect [ > >>>>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Anima mailing list > >>>> Anima@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/anima > >>> > >>> -- > >>> --- > >>> tte@cs.fau.de > >>> > > -- --- tte@cs.fau.de From nobody Sat Feb 10 19:04:02 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC41201F8 for ; Sat, 10 Feb 2018 19:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 jAl1Cuyv1ag1 for ; Sat, 10 Feb 2018 19:03:58 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id C83EC124207 for ; Sat, 10 Feb 2018 19:03:58 -0800 (PST) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209] port 57992) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id w1B33vgt030332; Sat, 10 Feb 2018 22:03:58 -0500 To: anima@ietf.org From: William Atwood Organization: Concordia University, Montreal Message-ID: <1051ad5c-1bc7-5fda-2a32-ce65f19a47e3@concordia.ca> Date: Sat, 10 Feb 2018 22:04:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2018-02-10 22:03:58 EST Archived-At: Subject: [Anima] Technical comments on draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2018 03:04:01 -0000 As a result of trying to understand (and then to model) the protocol flow for BRSKI, I have made a review of draft-ietf-anima-bootstrapping-keyinfra-09. The following are my technical comments. A separate list of suggested minor editorial changes has been sent to the authors. Bill Section 1, para 3, lines 4-5. "is a minor extension to the voucher format (see Section 3)." What "voucher format"? I guess that you mean the voucher format defined in draft-ietf-anima-voucher. I suggest some additional precision here. Lines 4-5. Why is this "minor extension" defined here, and not in draft-ietf-anima-voucher? Would it not be better to have all (currently known) voucher formats in one place? Section 2.3, para 2, line 1. "previously defined fields" Where are these defined? Are they previously defined in this document? Are they previously defined in some other document? (If so, give reference.) In general, this paragraph and its two bullets might be understandable by someone who is well familiar with X.509, but they are opaque to someone who is not (i.e., this reviewer). I believe that your message would be much clearer if you first defined (or explained) what is in the X.509 certificate (that you are going to use), and then specified the constraints/extensions that you are going to impose. Here is my (possibly incorrect) understanding: The X.509 certificate contains a "subject" field, which in turn contains a DN encoding. (What is "DN"? Please define the acronym.) For a voucher, this DN encoding MUST include the "serialNumber" attribute. The X.509 certificate also contains a "subject-alt" field. For a voucher, this field SHOULD contain a "HardwareModuleName". Three possible mappings are given to produce the "serial-number" field in the voucher. A new extension for the X.509 IDevID certificate contains a URI pointing to the MASA. IRIs MUST be mapped to URIs in a specific way. However, I had to struggle to come to this understanding. Hopefully, new text can be introduced to ensure that future readers will come to this understanding more quickly. After all, if our goal is to ensure correct implementations of the spec, it would be helpful if the spec were clear and specific. Section 2.3, para 5, line 4. In this document, the string ".well-known" appears variously as ".well-known", "./well-known", and "/.well-known". If these are in fact intentional, then the differences should be explained. Otherwise, a consistent form should be ensured throughout the document. Given that I do not know what is correct, or if they are intended to be different, I have not signaled these cases in my General Comments. You will have to do a search to discover all the instances. Section 2.6, para 1. I find this entire paragraph puzzling. I believe that more text is required here, in the hope that the use cases will be clearer. Perhaps the use cases need to be stated first, followed by the allowed actions. Section 3, para 1, line 6. What is the meaning of '"proximity-registrar-cert" leaf'? What is the leaf a leaf of? If this refers to some YANG module, please cite the YANG module. Section 3.2, Example (2). Does this example illustrate _a_ Registrar voucher-request, or does it illustrate the Registrar voucher-request that would be used to forward Example (1)? If the former, why is the nonce identical? If the latter, it should be explained that certain other fields are carried forward as well. Section 4.1, para 2, bullet 2, line 3. "may" -> "MAY" (This "may" seems to be normative.) Para 7, line 2. "should" -> "SHOULD" Section 5, para 8, bullet 1. The reference to RFC6125 appears to be normative, and so RFC 6125 should be added to the list of (normative) references. Section 5.4, para 9. This paragraph gives a series of actions that are described in the introductory material as "validation checks". However, the first bullet is describing a renewal action, not a validation check. I suggest that the phrase "The MASA validation checks before issuing a voucher are as follows:" be replaced with "The MASA performs the following actions and validation checks before issuing a voucher:" Section 5.8, para 2, line 1. "the following EST" (I have no idea where these "following" items are. The subsequent subsections are clearly not extensions, so I cannot determine what is being referenced here. Since this is a "recommendation", it is important that it be clear to the reader what is intended. Para 2. This paragraph is quite opaque to me. I cannot follow the logic of the sequence of statements. Does the second sentence imply "one-at-a-time" operation, or something else? In the third sentence, requests will "look the same" as what? Each other, something else? -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Sun Feb 11 01:16:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CAF1242EA for ; Sun, 11 Feb 2018 01:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 2-1e7TUjvSw0 for ; Sun, 11 Feb 2018 01:16:48 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 07F77120454 for ; Sun, 11 Feb 2018 01:16:48 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 57A73CD23F5CE for ; Sun, 11 Feb 2018 09:16:44 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 11 Feb 2018 09:16:45 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Sun, 11 Feb 2018 17:16:40 +0800 From: "Liubing (Leo)" To: Eliot Lear , "mcr+ietf@sandelman.ca" , "anima@ietf.org" Thread-Topic: [Anima] BRSKI over 802.11 Thread-Index: AQHToCy/tqw0vORz80OGijuJnmor96OYqdyAgAAdMwCAAO/OgIAAB2EAgAUwnXA= Date: Sun, 11 Feb 2018 09:16:39 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2018 09:16:50 -0000 SGkgTWljaGFlbCwgRWxpb3QgYW5kIGFsbCwNCg0KQSBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uOiBp dCBzb3VuZHMgbGlrZSB0aGVyZSBhcmUgdHdvIGFwcHJvYWNoZXMgcHJvcG9zZWQsIG5vdCBzdXJl IEkgdW5kZXJzdG9vZCBpdCBjb3JyZWN0bHk6DQoNCk1pY2hhZWwncyBwcm9wb3NhbDogdGhlcmUg aXMgYSBkZWRpY2F0ZWQgU1NJRCwgc2F5ICJBbmltYSIsIGl0IGlzIGVuYWJsZWQgYnkgZGVmYXVs dCwgYW5kIHRoZXJlIGlzIG5vIHNlY3VyaXR5LiBBbmQgdGhhdCBTU0lEIGNhbiBvbmx5IGRvIEJS U0tJLCBubyBvdGhlciBzZXJ2aWNlcyBwZXJtaXR0ZWQgKGp1c3QgbGlrZSB0aGUgaHR0cCBwb3J0 YWwgYXV0aGVudGljYXRpb24pLiBBZnRlciBnZXR0aW5nIHRoZSBjZXJ0aWZpY2F0ZSwgdGhlbiBj ZXJ0aWZpY2F0ZS1iYXNlZCBFQVAgY291bGQgYmUgcnVuIHRvIGRvIHRoZSA4MDIuMXggYXV0aGVu dGljYXRpb247IG9yIG1heWJlIHRoZXkganVzdCBuZWdvdGlhdGVkIGEga2V5IGZvciBXUEEyLiBJ biB0aGlzIGNhc2UsIHRoZSBCUlNLSSBqdXN0IHdvcmtzIGFzIHRoZSBib290c3RyYXAgb2YgV2lG aS4NCg0KRWxpb3QncyBwcm9wb3NhbDogd2UnbGwgaGF2ZSBhIG5ldyBFQVAgbWV0aG9kLCBzYXkg IkVBUC1CUlNLSSIsIGp1c3QgdHJlYXQgQlJTS0kgYXMgYW4gb3B0aW9uIGVuY2Fwc3VsYXRlZCBp biBFQVAgcHJvdG9jb2wsIHVuZGVyIHRoZSBXaUZpIGFjY2VzcyBmcmFtZXdvcmsuDQoNCk1pY2hh ZWwgYW5kIEVsaW90OiBkaWQgSSBnZXQgeW91IGNvcnJlY3RseT8NCg0KQi5SLg0KQmluZw0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFuaW1hIFttYWlsdG86YW5pbWEt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVsaW90IExlYXINCj4gU2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDA4LCAyMDE4IDU6NTEgUE0NCj4gVG86IEFydHVyIEhlY2tlciA8QXJ0dXIu SGVja2VyQGh1YXdlaS5jb20+OyBhbmltYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0FuaW1h XSBCUlNLSSBvdmVyIDgwMi4xMQ0KPiANCj4gQXJ0dXIsDQo+IA0KPiBJIHN1c3BlY3QgbXVjaCDi gJMgYnV0IG5vdCBhbGwg4oCTIG9mIHRoaXMgY291bGQgYmUgYWRkcmVzc2VkIGluIEVBUC4NCj4g DQo+IEVsaW90DQo+IA0KPiANCj4gT24gMDguMDIuMTggMTA6MjQsIEFydHVyIEhlY2tlciB3cm90 ZToNCj4gPiBIaSBNaWNoYWVsDQo+ID4NCj4gPg0KPiA+IFNvcnJ5LCBtYXliZSBJIG1pc3VuZGVy c3Rvb2QgdGhlIGludGVudGlvbi4gSXMgeW91ciBpbnRlbnRpb24gdG8gbWFrZSBpdA0KPiAic3Rh bmRhcmQiIG9yIGp1c3QgdG8gbWFrZSBhIGRlbW9uc3RyYXRpb24/IElmIHRoZSBsYXR0ZXIsIHRo ZW4gaXQncyBPSy4gSXQncyB0aGUNCj4gZmlyc3QgdGhhdCBJIHNpbXBseSBkb3VidCBpdCB3aWxs IHdvcmsuDQo+ID4NCj4gPiBJIGFtIG5vdCBjbGFpbWluZyB0aGF0IHRoZXJlIGFyZSBiZXR0ZXIg bWVhbnMgdG8gZG8gdGhhdCwgbGV0IGFsb25lIHRoYXQgd2hhdA0KPiB5b3UgcHJvcG9zZWQgbWFr ZXMgbm8gc2Vuc2UuIEkgYWN0dWFsbHkgc2FpZCB0aGF0IHRoaXMgbWFrZXMgc2Vuc2UuIEkganVz dCB0aGluaw0KPiB0aGF0IHdlIGVudGVyIHRoZSByZWFsbXMgb2YgODAyLjEgYW5kIDgwMi4xMSBh dCB0aGUgc2FtZSB0aW1lIGFuZCBoYXZlIG5vDQo+IGF1dGhvcml0eSB0aGVyZS4NCj4gPg0KPiA+ IEl0IGhhcyBpbmRlZWQgbm90aGluZyB0byBkbyB3aXRoIFdpcmVsZXNzIGFjY2VzcyBwb2ludHMu IEFueSBTVEEgKDgwMi4xMSkgYW5kDQo+IGFueSBzdXBwbGljYW50ICg4MDIuMVgpIGlzIHN1Ympl Y3QgdG8gc3RhbmRhcmRpemF0aW9uIGFuZCByZWd1bGF0aW9uIG9mIHRoZSBib2RpZXMNCj4gb2Yg SUVFRSwgaW4gYW55IG1vZGUgb2Ygb3BlcmF0aW9uLiBXUFMgc2hvdWxkIG5vdCBiZSBsaW1pdGVk IHRvIGFueSBBY2Nlc3MNCj4gUG9pbnQgcHJlc2VuY2UsIHNpbmNlIGl0IHN1cHBvcnRzIFdpRmkg RGlyZWN0LiBJIGFncmVlLCB0aGUgc3VwcG9ydGVkIG1ldGhvZHMgYXJlDQo+IHJ1ZGltZW50YXJ5 LiBJZiBJIHJlbWVtYmVyIGNvcnJlY3RseSwgc29tZXRoaW5nIGxpa2UgUElOLCB0aGUgcHVzaCBi dXR0b24geW91DQo+IG1lbnRpb25lZCwgTkZDIGFuZCBVU0IuDQo+ID4NCj4gPiBJIGd1ZXNzLCBh IHBvc3NpYmlsaXR5IHdvdWxkIGJlIHRvIHNwZWNpZnkgYW4gYWRkaXRpb25hbCBBTklNQS9BQ1Av QlJTS0kNCj4gbWV0aG9kIGZvciBXUFMsIHdoeSBub3QuIEFsbCBJIGFtIHNheWluZyBpcyB0aGF0 IHdlIHByb2JhYmx5IG5lZWQgdG8gZG8gaXQgdGhlcmUsDQo+IGFzIGFueSB0cnkgdG8gZG8gaXQg aW4gdGhlIEFOSU1BIFdHIHdvdWxkIHJlcXVpcmUgc3BlY2lmaWMgODAyLjExIG1vZGVzIGFuZA0K PiBzcGVjaWZpYyA4MDIuMVggZnVuY3Rpb25zL2JlaGF2aW91cnMsIHdoaWNoIEkgYW0gbm90IHN1 cmUgd2UgY2FuIGRpY3RhdGUgdG8NCj4gaGF2ZS4NCj4gPg0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+ IGFydHVyDQo+ID4NCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IE1pY2hhZWwgUmljaGFyZHNvbiBbbWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5j YV0NCj4gPj4gU2VudDogMDcgRmVicnVhcnkgMjAxOCAyMDowNw0KPiA+PiBUbzogQXJ0dXIgSGVj a2VyIDxBcnR1ci5IZWNrZXJAaHVhd2VpLmNvbT4NCj4gPj4gQ2M6IGFuaW1hQGlldGYub3JnDQo+ ID4+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEJSU0tJIG92ZXIgODAyLjExDQo+ID4+DQo+ID4+DQo+ ID4+IEFydHVyIEhlY2tlciA8QXJ0dXIuSGVja2VyQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+PiAg ICAgPiBIaSBNaWNoYWVsLA0KPiA+PiAgICAgPiBNeSBvcGluaW9uOg0KPiA+Pg0KPiA+PiBJIGRv bid0IHRoaW5rIHVuZGVyc3Rvb2QgdGhlIHF1ZXN0aW9uIDotKQ0KPiA+Pg0KPiA+PiAxKSBJdCdz IG5vdCBhYm91dCBXaXJlbGVzcyBBY2Nlc3MgUG9pbnRzLCBzbyBhbGwgb2YgdGhlIFdpZmkgQWxs aWFuY2UsDQo+ID4+ICAgIGV0Yy4gdGFsayBtYWtlcyBubyBzZW5zZSB0byBtZS4gIFRoZXJlIGNh biBiZSBubyBhY2Nlc3MgcG9pbnRzIHVudGlsIHRoZXkNCj4gPj4gICAgaGF2ZSBiZWVuIGNvbmZp Z3VyZWQuICBJdCdzIHBvc3NpYmxlIHRoYXQgdGhlcmUgbWlnaHQgTkVWRVIgYmVlbiBhbnkNCj4g Pj4gICAgYWNjZXNzIHBvaW50cywgYmVjYXVzZSB0aGUgb3BlcmF0b3IgYWN0dWFsbHkgZG9lc24n dCB3YW50L25lZWQgYW55DQo+ID4+IGVuYWJsZWQuDQo+ID4+ICAgIFRoaW5rIGFib3V0IGluc2lk ZSBvZiBhIGNhZ2UgaW4gYSBkYXRhIGNlbnRlci4NCj4gPj4NCj4gPj4gMikgSXQncyBhYm91dCAq ZGV2aWNlcyogdGhhdCBoYXZlIDgwMi4xMSBpbnRlcmZhY2VzLg0KPiA+PiAgICBZb3UgY2FuJ3Qg dXNlIFdQUyBvciBhbnl0aGluZyBlbHNlIGludm9sdmluZyA4MDIuMXggdW50aWwgeW91IGhhdmUN Cj4gPj4gICAgY3JlZGVudGlhbHMsIHdoaWNoIGlzIHdoYXQgQlJTS0kgZ2V0cyB5b3UuDQo+ID4+ ICAgIFNvIHlvdSBjYW4ndCB1c2UgV1BTIHRvICpib290c3RyYXAqIFdQUy4NCj4gPj4gICAgKGFu ZCBwdXNoaW5nIGJ1dHRvbnMgb24gdGhlIGZyb250IG9mIHRoZSBBUCBpcyBieSBkZWZpbml0aW9u IG5vdA0KPiA+PiAiemVyby0NCj4gPj4gdG91Y2giKQ0KPiA+Pg0KPiA+PiAgICAgPiBRMzogU29y cnksIEkgZGlkIG5vdCBxdWl0ZSB1bmRlcnN0YW5kIHRoaXMgb25lLiBJZiB5b3UgbWVhbnQgdGhl IGFkLWhvYw0KPiA+PiAgICAgPiBlc3NpZCBiYXNlZCBuZXR3b3JrLCBteSBmaXJzdCBpbnR1aXRp b24gd291bGQgYmUgdG8gb2JqZWN0LCBhcyBJDQo+ID4+ICAgICA+IGJlbGlldmUgdGhhdCB3ZSBz aG91bGQgbm90IHByZXNjcmliZSBzdWNoIG1vZGVzIGZvciBBQ1AsIGJ1dCByYXRoZXIgdXNlDQo+ ID4+ICAgICA+IHRoZSBiZXN0IGF2YWlsYWJsZSBvbmUuDQo+ID4+DQo+ID4+IDMpIFRoZSBBQ1Ag aXMgc2VjdXJlZCBpbnNpZGUgSVBzZWMgb3ZlciBMaW5rLUxheWVyIElQdjYgKG9yIE1BQ1NFQywg b3INCj4gPj4gICAgYSBidW5jaCBvZiBvdGhlciBwb3NzaWJsZSB0ZWNobm9sb2dpZXMgaW4gdGhl IEFDUCBkb2N1bWVudCkuDQo+ID4+ICAgIEl0J3Mgbm90IGFib3V0IHRoZSBzZWN1cml0eSBvZiB0 aGUgQUNQLg0KPiA+Pg0KPiA+PiBTaW5jZSB0aGUgcG9pbnQgb2YgdGhlIEFDUCBpcyB0aGF0IGl0 J3MgYWx3YXlzIGF2YWlsYWJsZSwgaXQgbmVlZHMgdG8NCj4gPj4gYmUgYXZhaWxhYmxlIGV2ZW4g d2hlbiB0aGUgV2lmaSBBY2Nlc3MgUG9pbnQgaXMgdG9hc3Qgb3Igbm90IHlldCBjb25maWd1cmVk Lg0KPiA+PiBPZiBjb3Vyc2UsIG9uY2UgdGhlcmUgaXMgYSBub24tYWRob2MvSUJTUyBuZXR3b3Jr IGF2YWlsYWJsZSwgdGhlIEFDUA0KPiA+PiB3b3VsZCBzZWUgdGhpcyBhcyBhZGRpdGlvbmFsIGlu dGVyZmFjZXMgYW5kIG1ha2UgYWRkaXRpb25hbCBtZXNoDQo+ID4+IGxpbmtzIGFjcm9zcyBpdCBm b3IgdGhlIEFDUCB0byB1c2UuICBCdXQgdGhhdCdzIG5vdCBib290c3RyYXAsIHRoYXQncyBvcGVy YXRpb24uDQo+ID4+DQo+ID4+ICAgICA+IFE0OiBBcyBJIGJlbGlldmUgdGhhdCBRMiBpcyBzdHJv bmdseSBiaWFzZWQsIEkgYmVsaWV2ZSB0aGF0IHNvIGlzDQo+ID4+ICAgICA+IFE0LiBUaGUgV2lG aSBBbGxpYW5jZSBhbHJlYWR5IHNwZWNpZmllcyBzZXZlcmFsIHdheXMgaG93IHRvIGJvb3RzdHJh cA0KPiA+PiAgICAgPiB3aXJlbGVzcyBhY2Nlc3MgcG9pbnRzLCBpbmNsdWRpbmcgZS5nLiBXUFMu IFdlIHdvdWxkIHJhdGhlciBuZWVkIHRvDQo+ID4+ICAgICA+IHNlZSwgaG93IHRvIGludGVncmF0 ZSB3aXRoIHN1Y2ggbWVhbnMuIEFuZCBhZ2FpbiwgSSBkb24ndCBiZWxpZXZlIHdlDQo+ID4+ICAg ICA+IGhhdmUgYXV0aG9yaXR5IG9uIHRoYXQuDQo+ID4+DQo+ID4+IE1heWJlIHlvdSBjb3VsZCBw b2ludCB0byBzcGVjaWZpYyBkb2N1bWVudHMgdGhhdCB3b3VsZCBwZXJtaXQgdHdvDQo+ID4+IGRl dmljZXMgd2hpY2ggaGF2ZSBuZXZlciBiZWVuIHRvdWNoZWQgdG8gY29tbXVuaWNhdGUgb3ZlciA4 MDIuMTENCj4gPj4gd2l0aG91dCBjb25maWd1cmF0aW9uLg0KPiA+Pg0KPiA+PiAtLQ0KPiA+PiBN aWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0 d2FyZSBXb3Jrcw0KPiA+PiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+ID4+DQo+ID4+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBB bmltYSBtYWlsaW5nIGxpc3QNCj4gPiBBbmltYUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4gPg0KPiANCg0K From nobody Mon Feb 12 01:56:03 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2627A1275C5 for ; Mon, 12 Feb 2018 01:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yVRWpdat31x for ; Mon, 12 Feb 2018 01:55:59 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE28127369 for ; Mon, 12 Feb 2018 01:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8026; q=dns/txt; s=iport; t=1518429358; x=1519638958; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=09AfRrxj7deCGtCz4GFWzTyE+7Klk/QCl0VBeizYNVk=; b=Q08/0HxCBHeok760RnOEXB23DBxCR4CLjLwwTo3GEUZQAuZ+1+r+V8fk xgsKx0daq2IPmXpUYJgL8FJK6P6kZwkCuPqLqLKn/lQpFRZjA52bHCXZJ 1ZZ0Kg7UmtaxkmFyeLjLTJtjg08JsY5TlWkI0SxRh0RBikZkU7PLmShfD A=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAAB0Y4Fa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ4cCiDZYokdI8xl1iCGAcDGAuBXoM6AoMZGAECAQEBAQEBAms?= =?us-ascii?q?ohSMBAQEEAQEhSxcECxEEAQEBJwMCAicfCQgGAQwGAgEBijEQrkCCJ4UBg3OCD?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4KBYR8hVQpgXeBDoMvAQGBSgSDOoJlBaQ?= =?us-ascii?q?uCYRogjKOaow8iAiYGIE8HzkxgR8zGggbFT2CRoJVHIIHQDeJbIJLAQEB?= X-IronPort-AV: E=Sophos; i="5.46,501,1511827200"; d="asc'?scan'208"; a="1967967" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2018 09:55:56 +0000 Received: from [10.61.226.74] ([10.61.226.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1C9ttIh018434; Mon, 12 Feb 2018 09:55:55 GMT To: "Liubing (Leo)" , "mcr+ietf@sandelman.ca" , "anima@ietf.org" References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> From: Eliot Lear Message-ID: Date: Mon, 12 Feb 2018 10:55:52 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iqjoniDtA3J0iBIEThi7WuTjc7CCmm5R0" Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 09:56:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iqjoniDtA3J0iBIEThi7WuTjc7CCmm5R0 Content-Type: multipart/mixed; boundary="E4KQUAOrNnjsALNRHDMHU0x8320nIT0kG"; protected-headers="v1" From: Eliot Lear To: "Liubing (Leo)" , "mcr+ietf@sandelman.ca" , "anima@ietf.org" Message-ID: Subject: Re: [Anima] BRSKI over 802.11 References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> --E4KQUAOrNnjsALNRHDMHU0x8320nIT0kG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Bing, I think you've got it down, but I want to stress that these are early days, and I could, perhaps easily, be convinced to go another way.=C2=A0 = I think Michael is trying to do that ;-)=C2=A0 I think the question is this= : in a WiFi environment how can the device know which network to connect with in the first place, and how does it then send packets to complete the BRSKI flow? As a difficult use case, consider a business in an office building on the 10th floor in New York City or London, where you might hear 2 dozen different networks. Eliot On 11.02.18 10:16, Liubing (Leo) wrote: > Hi Michael, Eliot and all, > > A clarification question: it sounds like there are two approaches propo= sed, not sure I understood it correctly: > > Michael's proposal: there is a dedicated SSID, say "Anima", it is enabl= ed by default, and there is no security. And that SSID can only do BRSKI,= no other services permitted (just like the http portal authentication). = After getting the certificate, then certificate-based EAP could be run to= do the 802.1x authentication; or maybe they just negotiated a key for WP= A2. In this case, the BRSKI just works as the bootstrap of WiFi. > > Eliot's proposal: we'll have a new EAP method, say "EAP-BRSKI", just tr= eat BRSKI as an option encapsulated in EAP protocol, under the WiFi acces= s framework. > > Michael and Eliot: did I get you correctly? > > B.R. > Bing > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Eliot Lear >> Sent: Thursday, February 08, 2018 5:51 PM >> To: Artur Hecker ; anima@ietf.org >> Subject: Re: [Anima] BRSKI over 802.11 >> >> Artur, >> >> I suspect much =E2=80=93 but not all =E2=80=93 of this could be addres= sed in EAP. >> >> Eliot >> >> >> On 08.02.18 10:24, Artur Hecker wrote: >>> Hi Michael >>> >>> >>> Sorry, maybe I misunderstood the intention. Is your intention to make= it >> "standard" or just to make a demonstration? If the latter, then it's O= K. It's the >> first that I simply doubt it will work. >>> I am not claiming that there are better means to do that, let alone t= hat what >> you proposed makes no sense. I actually said that this makes sense. I = just think >> that we enter the realms of 802.1 and 802.11 at the same time and have= no >> authority there. >>> It has indeed nothing to do with Wireless access points. Any STA (802= =2E11) and >> any supplicant (802.1X) is subject to standardization and regulation o= f the bodies >> of IEEE, in any mode of operation. WPS should not be limited to any Ac= cess >> Point presence, since it supports WiFi Direct. I agree, the supported = methods are >> rudimentary. If I remember correctly, something like PIN, the push but= ton you >> mentioned, NFC and USB. >>> I guess, a possibility would be to specify an additional ANIMA/ACP/BR= SKI >> method for WPS, why not. All I am saying is that we probably need to d= o it there, >> as any try to do it in the ANIMA WG would require specific 802.11 mode= s and >> specific 802.1X functions/behaviours, which I am not sure we can dicta= te to >> have. >>> >>> Regards >>> artur >>> >>> >>> >>>> -----Original Message----- >>>> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] >>>> Sent: 07 February 2018 20:07 >>>> To: Artur Hecker >>>> Cc: anima@ietf.org >>>> Subject: Re: [Anima] BRSKI over 802.11 >>>> >>>> >>>> Artur Hecker wrote: >>>> > Hi Michael, >>>> > My opinion: >>>> >>>> I don't think understood the question :-) >>>> >>>> 1) It's not about Wireless Access Points, so all of the Wifi Allianc= e, >>>> etc. talk makes no sense to me. There can be no access points un= til they >>>> have been configured. It's possible that there might NEVER been = any >>>> access points, because the operator actually doesn't want/need an= y >>>> enabled. >>>> Think about inside of a cage in a data center. >>>> >>>> 2) It's about *devices* that have 802.11 interfaces. >>>> You can't use WPS or anything else involving 802.1x until you hav= e >>>> credentials, which is what BRSKI gets you. >>>> So you can't use WPS to *bootstrap* WPS. >>>> (and pushing buttons on the front of the AP is by definition not >>>> "zero- >>>> touch") >>>> >>>> > Q3: Sorry, I did not quite understand this one. If you meant t= he ad-hoc >>>> > essid based network, my first intuition would be to object, as= I >>>> > believe that we should not prescribe such modes for ACP, but r= ather use >>>> > the best available one. >>>> >>>> 3) The ACP is secured inside IPsec over Link-Layer IPv6 (or MACSEC, = or >>>> a bunch of other possible technologies in the ACP document). >>>> It's not about the security of the ACP. >>>> >>>> Since the point of the ACP is that it's always available, it needs t= o >>>> be available even when the Wifi Access Point is toast or not yet con= figured. >>>> Of course, once there is a non-adhoc/IBSS network available, the ACP= >>>> would see this as additional interfaces and make additional mesh >>>> links across it for the ACP to use. But that's not bootstrap, that'= s operation. >>>> >>>> > Q4: As I believe that Q2 is strongly biased, I believe that so= is >>>> > Q4. The WiFi Alliance already specifies several ways how to bo= otstrap >>>> > wireless access points, including e.g. WPS. We would rather ne= ed to >>>> > see, how to integrate with such means. And again, I don't beli= eve we >>>> > have authority on that. >>>> >>>> Maybe you could point to specific documents that would permit two >>>> devices which have never been touched to communicate over 802.11 >>>> without configuration. >>>> >>>> -- >>>> Michael Richardson , Sandelman Software Works= >>>> -=3D IPv6 IoT consulting =3D- >>>> >>>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> --E4KQUAOrNnjsALNRHDMHU0x8320nIT0kG-- --iqjoniDtA3J0iBIEThi7WuTjc7CCmm5R0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlqBZKgACgkQh7ZrRtnS ejMPJgf/Zpjc3Vt6CdfA3vZ7hPPWa1z65zXPOjnHgmEamXH4I9UmHviAB8DKH1U7 RUU9RVBWO8UtataZvRS94UkHoJcRfUUdaM8a4hVFM6WFKlAPCvfDegl6HKmqxMWu ZkL2Hgkaqlho++nfAzl/YVZl/NEvMR3h7HpxWSwLkEmfM9paF6d5bf5Mme1351ky SKKgHY6xtAW8nNFFHB31JlXVX+JR5YDBxHtYGxpgbjBeP+phuIChMRwtgnTOna1X ZH6rHBH2OajH5y9Fzcsk9wycbqcaTH65lTUtkl75o+5rVKuqY06ESrB5IDen7lD7 dd2MfRslXs6dTy6yE0urRjNE2Vpd8Q== =U1yy -----END PGP SIGNATURE----- --iqjoniDtA3J0iBIEThi7WuTjc7CCmm5R0-- From nobody Mon Feb 12 06:12:53 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BAA126BFD; Mon, 12 Feb 2018 06:12:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk CC: anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , terry.manderson@icann.org, anima@ietf.org, jiangsheng@huawei.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151844477242.6010.10665005903514427678.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 06:12:52 -0800 Archived-At: Subject: [Anima] Last Call: (An Autonomic Control Plane (ACP)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 14:12:52 -0000 The IESG has received a request from the Autonomic Networking Integrated Model and Approach WG (anima) to consider the following document: - 'An Autonomic Control Plane (ACP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM (Operations Administration and Management) communications over a network that is secure and reliable even when the network is not configured, or not misconfigured. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2407/ The document contains these normative downward references. See RFC 3967 for additional information: draft-behringer-anima-autonomic-control-plane: An Autonomic Control Plane (None - ) draft-carpenter-anima-ani-objectives: Technical Objective Formats for the Autonomic Network Infrastructure (None - ) draft-behringer-autonomic-control-plane: An Autonomic Control Plane (None - ) draft-ietf-roll-applicability-template: ROLL Applicability Statement Template (None - IETF stream) draft-behringer-anima-autonomic-addressing: An Autonomic IPv6 Addressing Scheme (None - ) From nobody Mon Feb 12 06:27:18 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BFD129C5D; Mon, 12 Feb 2018 06:27:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-anima-voucher@ietf.org, The IESG , anima-chairs@ietf.org, rfc-editor@rfc-editor.org, Sheng Jiang , terry.manderson@icann.org, anima@ietf.org, jiangsheng@huawei.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151844563171.5990.14568936553789860016.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 06:27:11 -0800 Archived-At: Subject: [Anima] Protocol Action: 'Voucher Profile for Bootstrapping Protocols' to Proposed Standard (draft-ietf-anima-voucher-07.txt) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 14:27:12 -0000 The IESG has approved the following document: - 'Voucher Profile for Bootstrapping Protocols' (draft-ietf-anima-voucher-07.txt) as Proposed Standard This document is the product of the Autonomic Networking Integrated Model and Approach Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ Technical Summary This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. Working Group Summary This document was called draft-kwatsen-anima-voucher prior to its adoption. There was unanimous support for it in favor of adoption and none against), so this document was adopted in January, 2017, as a accompanying document along with another ANIMA WG document draft-ietf-anima-bootstrapping-keyinfra, which have been adopted in Auguest 2015. It is worthy to clarifying that this document is actually independent from draft-ietf-anima-bootstrapping-keyinfra. There was interest in this work posts since its adoption. There was never any opposition for this work. This document went through a relevant shorter document development period (3 months for individual document period, 8 month for WG document period). It has been reviewed well. Document Quality This document went through multiple reviews by multiple WGs (ANIMA, 6tisch, NETCONF) participants. And this document went through a cross-group WGLC, which did receive comments to help improving the document. So far, there is no existing implementations. Personnel Sheng Jiang is the document shepherd. Terry Manderson is the responsible AD. IANA Note IANA is asked to registers a URIs in the IETF XML registry: URI: urn:ietf:params:xml:ns:yang:ietf-voucher IANA is requested to registers a YANG module in the YANG Module Names registry: ietf-voucher. All the necessary information is in the IANA considerations document. It is clear enough that the IANA will be able to implement it. From nobody Mon Feb 12 06:44:07 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3F2129511; Mon, 12 Feb 2018 06:44:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-anima-stable-connectivity@ietf.org, anima-chairs@ietf.org, rfc-editor@rfc-editor.org, Sheng Jiang , terry.manderson@icann.org, anima@ietf.org, jiangsheng@huawei.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151844664610.6030.7816037840126706199.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 06:44:06 -0800 Archived-At: Subject: [Anima] Document Action: 'Using Autonomic Control Plane for Stable Connectivity of Network OAM' to Informational RFC (draft-ietf-anima-stable-connectivity-10.txt) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 14:44:06 -0000 The IESG has approved the following document: - 'Using Autonomic Control Plane for Stable Connectivity of Network OAM' (draft-ietf-anima-stable-connectivity-10.txt) as Informational RFC This document is the product of the Autonomic Networking Integrated Model and Approach Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ Technical Summary This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. Working Group Summary This document was called draft-eckert-anima-stable-connectivity prior to its adoption. There was unanimous support for it in favor of adoption and none against, so this document was adopted in December 2015. There was interest in this work posts since its adoption. There was never any opposition for this work. This document went through a relevant long document development period (12 months for individual document period, 22 month for WG document period). It has been reviewed well. Document Quality This document went through multiple reviews by multiple participants. So far, there is no existing implementations. Personnel Sheng Jiang is the document shepherd. Terry Manderson is the responsible AD. From nobody Mon Feb 12 16:10:53 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E478C12DA0A for ; Mon, 12 Feb 2018 16:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 uv-ushocxN9b for ; Mon, 12 Feb 2018 16:10:49 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B4112D944 for ; Mon, 12 Feb 2018 16:10:49 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D9EA520090; Mon, 12 Feb 2018 19:17:40 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9629B80BB3; Mon, 12 Feb 2018 19:10:48 -0500 (EST) From: Michael Richardson To: "Liubing \(Leo\)" cc: Eliot Lear , "anima\@ietf.org" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 00:10:51 -0000 --=-=-= Content-Type: text/plain Liubing (Leo) wrote: > A clarification question: it sounds like there are two approaches > proposed, not sure I understood it correctly: (1) > Michael's proposal: there is a dedicated SSID, say "Anima", it is > enabled by default, and there is no security. And that SSID can only do > BRSKI, no other services permitted (just like the http portal > authentication). (2) > After getting the certificate, then certificate-based > EAP could be run to do the 802.1x authentication; or maybe they just > negotiated a key for WPA2. In this case, the BRSKI just works as the > bootstrap of WiFi. (3) > Eliot's proposal: we'll have a new EAP method, say "EAP-BRSKI", just > treat BRSKI as an option encapsulated in EAP protocol, under the WiFi > access framework. > Michael and Eliot: did I get you correctly? Yes, I think you described that exactly correctly. I've put some numbers in to help split up the thoughts. The decidcated SSID would be in IBSS mode, and it could use WPA2-Enterprise with a known username/password (like we do for the IETF SSID), which would get per-station keying material. There is also "Wifi Direct", defined by the Wi-fi Alliance, which also might make sense and might provide similar L2 keying. There would be no DHCPv4 or DHCPv6 or RAs on the link, as it would all just be LL. The only traffic would be GRASP M_FLOODs (from the DULL). There is a (4) - bring up an ACP across this dedicated SSID. This is not mutually exclusive with (2). If one does (3), then I guessone can do (2) to get connectivity. (3) still has to define some kind of SSID on which this new 1x method will be seen. It could be that we can do something with 802.11 beacons to indicate the capability and not have to pick a particular SSID name on which to "rendezvous" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqCLQgACgkQgItw+93Q 3WUIbAf/XAA17tJ3igN10r9ngQyR1Hkqi4/LRgzykQ+pwxunlmynQ1Bu6M0Hjwsf eJF9qM2ve4qqBVUCXEguinlpQJBylcEjPj5Qe1lrXjzEuHVdjzf1CutUC0XANYXr ZzWS85ztjD/OgoElSffoK2X7Ye7ElJlPFu15PCue57I8nn7D4fC1yfa69YGacmCN rnZ9gmjbf9oS6chs8H5/VuoA/LU09gorBJTo4/bVLAUY4PZoEWlN10u+QvErMDnq qdopdqk0jg60dGvtyqaCS213yhtRqzLtY8mBNBsy7HtRxNhfRMFa+Dyyo2N/6DFH mRyAHp7cfHUR3rVtRQOu2y6iMK1xXg== =OLms -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 12 18:31:42 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F0E12E047 for ; Mon, 12 Feb 2018 18:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 a1PgxPnGhU37 for ; Mon, 12 Feb 2018 18:31:39 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283F412E04B for ; Mon, 12 Feb 2018 18:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10350; q=dns/txt; s=iport; t=1518489099; x=1519698699; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kccmCIZaIUyRw38h9jQnUWzEAQmBLfQLkLIkTA8hFoo=; b=WMaIs4yKFNpT9FH7WGqetEwQXmpTnOatjATe5gtFw19yOyQBw06SVkmH D05d39hcWI29yQ0qsT0X6rcU/q3OgepKCSpyvtqo2PF6jqZcwRDPqmxUj JWxEdnF8TZ2sP22cto4sfP24UAwIGxX7DEryanZ1G1lFWvfetRtIkaVup 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAAARTYJa/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNSZnAoCoNbiiSOJoICgReWQYIYChgLgV6DOgIagjNUGAECAQE?= =?us-ascii?q?BAQEBAmsohSMBAQEEAQEhEToXBAIBCBEEAQEBAgIjAwICAiULFAEICAIEARIbi?= =?us-ascii?q?hoQrkKCJ4h8ghEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPg22CFYM/KYF3gQ6?= =?us-ascii?q?DLwEBgUoEKhAjgl0xgjQFpC4JApYClESXawIRGQGBOwEfOTGBH3AVPSoBghuCV?= =?us-ascii?q?RyCBniJcYE0gRcBAQE?= X-IronPort-AV: E=Sophos;i="5.46,505,1511827200"; d="scan'208";a="70086888" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2018 02:31:38 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w1D2Vb7v018024 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Feb 2018 02:31:37 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 12 Feb 2018 21:31:36 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Mon, 12 Feb 2018 21:31:36 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Eliot Lear , "Liubing (Leo)" , "mcr+ietf@sandelman.ca" , "anima@ietf.org" Thread-Topic: [Anima] BRSKI over 802.11 Thread-Index: AQHToCy0fm9UWSh+wkyWmKO3UlDUE6OZg8qAgAAdMwCAAO/OgIAAB2EAgAStV4CAAZ1KAIAAQMOA Date: Tue, 13 Feb 2018 02:31:36 +0000 Message-ID: <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.87.91] Content-Type: text/plain; charset="utf-8" Content-ID: <5476A0826C39A247BD7E5508C557107B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 02:31:42 -0000 SGksDQpDYXRjaGluZyB1cCBvbiB0aGlzIHRocmVhZC4uLi5pdCBpcyBub3QgY2xlYXIgdG8gbWUg dGhhdCB3ZSBjYW4gcHJlc2NyaWJlIGFuICJTU0lEIiBhcyB0aGVyZSBjYW4gYmUgYSBjb3VwbGUg b2Ygc29sdXRpb25zLi4uLg0KQW5kIGZvciB0aGF0IGxldmVsLCBJIGJlbGlldmUgaXMgb3V0IG9m IHNjb3BlIGZvciBJRVRGOyB0aGF0IHNhaWQsIHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBtZWFucyB0 byBkbyB0aGlzIHcvaW4gODAyLjExIHRoZSBjbGVhbmVzdCBvbmUgaXMgdXNpbmcgdGhlIHNlcnZp Y2UvY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50cyBmcm9tIDgwMi4xMXUuICAgIFRoZSBTU0lEIGlz IHJlYWxseSBub3Qgc3VmZmljaWVudCBvbiB0aGUgODAyLjExIGFzIHdlJ3ZlIGJ1aWxkIGFnaWxp dHkgdGhlcmUgYXMgd2VsbCB0byBkZW5vdGUgdGhlIHR5cGVzIG9mIGF1dGhlbnRpY2F0aW9uIGFu ZCBrZXkgbWFuYWdlbWVudCB0aGF0IHdlIHdvdWxkIGFsc28gd2FudCB0byByZXRhaW4gKGFnaWxp dHkgdG8pIGFzIHdlIGRvIHRoaXMgYWxhIEJSU0tJLiAgQnV0LCBJIGJyZWFrIGl0IGRvd24gdG8g ImRpc2NvdmVyeSIgYXMgcGVyaGFwcyBiZWluZyBhbiA4MDIuMTEgc2NvcGUgYW5kIHRoZXJlYWZ0 ZXIgd2UgY2FuIGRpc2N1c3Mgd29yayByZWxldmFudCBoZXJlLg0KDQpUaGF0IHNhaWQsIGZvciB0 aGUgYWN0dWFsIGVucm9sbG1lbnQgd291bGQgdmVyeSB3ZWxsIGJlIHN1aXRlZCB0byBiZSBpbiB0 aGUgRUFQIHJlYWxtIGFzIDgwMi4xMSBhbHJlYWR5IHByZXNjcmliZXMgdG8gdXNpbmcgdGhhdCBt b2RlbCB3aXRoaW4gODAyLjFYLg0KDQpIb3BlZnVsbHkgdGhhdCBtYWtlcyBzZW5zZSwNCglOYW5j eQ0KDQrvu79PbiAyLzEyLzE4LCAxOjU2IEFNLCAiQW5pbWEgb24gYmVoYWxmIG9mIEVsaW90IExl YXIiIDxhbmltYS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsZWFyQGNpc2NvLmNvbT4g d3JvdGU6DQoNCiAgICBIaSBCaW5nLA0KICAgIA0KICAgIEkgdGhpbmsgeW91J3ZlIGdvdCBpdCBk b3duLCBidXQgSSB3YW50IHRvIHN0cmVzcyB0aGF0IHRoZXNlIGFyZSBlYXJseQ0KICAgIGRheXMs IGFuZCBJIGNvdWxkLCBwZXJoYXBzIGVhc2lseSwgYmUgY29udmluY2VkIHRvIGdvIGFub3RoZXIg d2F5LiAgSQ0KICAgIHRoaW5rIE1pY2hhZWwgaXMgdHJ5aW5nIHRvIGRvIHRoYXQgOy0pICBJIHRo aW5rIHRoZSBxdWVzdGlvbiBpcyB0aGlzOiBpbg0KICAgIGEgV2lGaSBlbnZpcm9ubWVudCBob3cg Y2FuIHRoZSBkZXZpY2Uga25vdyB3aGljaCBuZXR3b3JrIHRvIGNvbm5lY3Qgd2l0aA0KICAgIGlu IHRoZSBmaXJzdCBwbGFjZSwgYW5kIGhvdyBkb2VzIGl0IHRoZW4gc2VuZCBwYWNrZXRzIHRvIGNv bXBsZXRlIHRoZQ0KICAgIEJSU0tJIGZsb3c/DQogICAgDQogICAgQXMgYSBkaWZmaWN1bHQgdXNl IGNhc2UsIGNvbnNpZGVyIGEgYnVzaW5lc3MgaW4gYW4gb2ZmaWNlIGJ1aWxkaW5nIG9uDQogICAg dGhlIDEwdGggZmxvb3IgaW4gTmV3IFlvcmsgQ2l0eSBvciBMb25kb24sIHdoZXJlIHlvdSBtaWdo dCBoZWFyIDIgZG96ZW4NCiAgICBkaWZmZXJlbnQgbmV0d29ya3MuDQogICAgDQogICAgRWxpb3QN CiAgICANCiAgICANCiAgICBPbiAxMS4wMi4xOCAxMDoxNiwgTGl1YmluZyAoTGVvKSB3cm90ZToN CiAgICA+IEhpIE1pY2hhZWwsIEVsaW90IGFuZCBhbGwsDQogICAgPg0KICAgID4gQSBjbGFyaWZp Y2F0aW9uIHF1ZXN0aW9uOiBpdCBzb3VuZHMgbGlrZSB0aGVyZSBhcmUgdHdvIGFwcHJvYWNoZXMg cHJvcG9zZWQsIG5vdCBzdXJlIEkgdW5kZXJzdG9vZCBpdCBjb3JyZWN0bHk6DQogICAgPg0KICAg ID4gTWljaGFlbCdzIHByb3Bvc2FsOiB0aGVyZSBpcyBhIGRlZGljYXRlZCBTU0lELCBzYXkgIkFu aW1hIiwgaXQgaXMgZW5hYmxlZCBieSBkZWZhdWx0LCBhbmQgdGhlcmUgaXMgbm8gc2VjdXJpdHku IEFuZCB0aGF0IFNTSUQgY2FuIG9ubHkgZG8gQlJTS0ksIG5vIG90aGVyIHNlcnZpY2VzIHBlcm1p dHRlZCAoanVzdCBsaWtlIHRoZSBodHRwIHBvcnRhbCBhdXRoZW50aWNhdGlvbikuIEFmdGVyIGdl dHRpbmcgdGhlIGNlcnRpZmljYXRlLCB0aGVuIGNlcnRpZmljYXRlLWJhc2VkIEVBUCBjb3VsZCBi ZSBydW4gdG8gZG8gdGhlIDgwMi4xeCBhdXRoZW50aWNhdGlvbjsgb3IgbWF5YmUgdGhleSBqdXN0 IG5lZ290aWF0ZWQgYSBrZXkgZm9yIFdQQTIuIEluIHRoaXMgY2FzZSwgdGhlIEJSU0tJIGp1c3Qg d29ya3MgYXMgdGhlIGJvb3RzdHJhcCBvZiBXaUZpLg0KICAgID4NCiAgICA+IEVsaW90J3MgcHJv cG9zYWw6IHdlJ2xsIGhhdmUgYSBuZXcgRUFQIG1ldGhvZCwgc2F5ICJFQVAtQlJTS0kiLCBqdXN0 IHRyZWF0IEJSU0tJIGFzIGFuIG9wdGlvbiBlbmNhcHN1bGF0ZWQgaW4gRUFQIHByb3RvY29sLCB1 bmRlciB0aGUgV2lGaSBhY2Nlc3MgZnJhbWV3b3JrLg0KICAgID4NCiAgICA+IE1pY2hhZWwgYW5k IEVsaW90OiBkaWQgSSBnZXQgeW91IGNvcnJlY3RseT8NCiAgICA+DQogICAgPiBCLlIuDQogICAg PiBCaW5nDQogICAgPg0KICAgID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPj4g RnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RWxpb3QgTGVhcg0KICAgID4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwOCwgMjAxOCA1OjUx IFBNDQogICAgPj4gVG86IEFydHVyIEhlY2tlciA8QXJ0dXIuSGVja2VyQGh1YXdlaS5jb20+OyBh bmltYUBpZXRmLm9yZw0KICAgID4+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEJSU0tJIG92ZXIgODAy LjExDQogICAgPj4NCiAgICA+PiBBcnR1ciwNCiAgICA+Pg0KICAgID4+IEkgc3VzcGVjdCBtdWNo IOKAkyBidXQgbm90IGFsbCDigJMgb2YgdGhpcyBjb3VsZCBiZSBhZGRyZXNzZWQgaW4gRUFQLg0K ICAgID4+DQogICAgPj4gRWxpb3QNCiAgICA+Pg0KICAgID4+DQogICAgPj4gT24gMDguMDIuMTgg MTA6MjQsIEFydHVyIEhlY2tlciB3cm90ZToNCiAgICA+Pj4gSGkgTWljaGFlbA0KICAgID4+Pg0K ICAgID4+Pg0KICAgID4+PiBTb3JyeSwgbWF5YmUgSSBtaXN1bmRlcnN0b29kIHRoZSBpbnRlbnRp b24uIElzIHlvdXIgaW50ZW50aW9uIHRvIG1ha2UgaXQNCiAgICA+PiAic3RhbmRhcmQiIG9yIGp1 c3QgdG8gbWFrZSBhIGRlbW9uc3RyYXRpb24/IElmIHRoZSBsYXR0ZXIsIHRoZW4gaXQncyBPSy4g SXQncyB0aGUNCiAgICA+PiBmaXJzdCB0aGF0IEkgc2ltcGx5IGRvdWJ0IGl0IHdpbGwgd29yay4N CiAgICA+Pj4gSSBhbSBub3QgY2xhaW1pbmcgdGhhdCB0aGVyZSBhcmUgYmV0dGVyIG1lYW5zIHRv IGRvIHRoYXQsIGxldCBhbG9uZSB0aGF0IHdoYXQNCiAgICA+PiB5b3UgcHJvcG9zZWQgbWFrZXMg bm8gc2Vuc2UuIEkgYWN0dWFsbHkgc2FpZCB0aGF0IHRoaXMgbWFrZXMgc2Vuc2UuIEkganVzdCB0 aGluaw0KICAgID4+IHRoYXQgd2UgZW50ZXIgdGhlIHJlYWxtcyBvZiA4MDIuMSBhbmQgODAyLjEx IGF0IHRoZSBzYW1lIHRpbWUgYW5kIGhhdmUgbm8NCiAgICA+PiBhdXRob3JpdHkgdGhlcmUuDQog ICAgPj4+IEl0IGhhcyBpbmRlZWQgbm90aGluZyB0byBkbyB3aXRoIFdpcmVsZXNzIGFjY2VzcyBw b2ludHMuIEFueSBTVEEgKDgwMi4xMSkgYW5kDQogICAgPj4gYW55IHN1cHBsaWNhbnQgKDgwMi4x WCkgaXMgc3ViamVjdCB0byBzdGFuZGFyZGl6YXRpb24gYW5kIHJlZ3VsYXRpb24gb2YgdGhlIGJv ZGllcw0KICAgID4+IG9mIElFRUUsIGluIGFueSBtb2RlIG9mIG9wZXJhdGlvbi4gV1BTIHNob3Vs ZCBub3QgYmUgbGltaXRlZCB0byBhbnkgQWNjZXNzDQogICAgPj4gUG9pbnQgcHJlc2VuY2UsIHNp bmNlIGl0IHN1cHBvcnRzIFdpRmkgRGlyZWN0LiBJIGFncmVlLCB0aGUgc3VwcG9ydGVkIG1ldGhv ZHMgYXJlDQogICAgPj4gcnVkaW1lbnRhcnkuIElmIEkgcmVtZW1iZXIgY29ycmVjdGx5LCBzb21l dGhpbmcgbGlrZSBQSU4sIHRoZSBwdXNoIGJ1dHRvbiB5b3UNCiAgICA+PiBtZW50aW9uZWQsIE5G QyBhbmQgVVNCLg0KICAgID4+PiBJIGd1ZXNzLCBhIHBvc3NpYmlsaXR5IHdvdWxkIGJlIHRvIHNw ZWNpZnkgYW4gYWRkaXRpb25hbCBBTklNQS9BQ1AvQlJTS0kNCiAgICA+PiBtZXRob2QgZm9yIFdQ Uywgd2h5IG5vdC4gQWxsIEkgYW0gc2F5aW5nIGlzIHRoYXQgd2UgcHJvYmFibHkgbmVlZCB0byBk byBpdCB0aGVyZSwNCiAgICA+PiBhcyBhbnkgdHJ5IHRvIGRvIGl0IGluIHRoZSBBTklNQSBXRyB3 b3VsZCByZXF1aXJlIHNwZWNpZmljIDgwMi4xMSBtb2RlcyBhbmQNCiAgICA+PiBzcGVjaWZpYyA4 MDIuMVggZnVuY3Rpb25zL2JlaGF2aW91cnMsIHdoaWNoIEkgYW0gbm90IHN1cmUgd2UgY2FuIGRp Y3RhdGUgdG8NCiAgICA+PiBoYXZlLg0KICAgID4+Pg0KICAgID4+PiBSZWdhcmRzDQogICAgPj4+ IGFydHVyDQogICAgPj4+DQogICAgPj4+DQogICAgPj4+DQogICAgPj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KICAgID4+Pj4gRnJvbTogTWljaGFlbCBSaWNoYXJkc29uIFttYWlsdG86 bWNyK2lldGZAc2FuZGVsbWFuLmNhXQ0KICAgID4+Pj4gU2VudDogMDcgRmVicnVhcnkgMjAxOCAy MDowNw0KICAgID4+Pj4gVG86IEFydHVyIEhlY2tlciA8QXJ0dXIuSGVja2VyQGh1YXdlaS5jb20+ DQogICAgPj4+PiBDYzogYW5pbWFAaWV0Zi5vcmcNCiAgICA+Pj4+IFN1YmplY3Q6IFJlOiBbQW5p bWFdIEJSU0tJIG92ZXIgODAyLjExDQogICAgPj4+Pg0KICAgID4+Pj4NCiAgICA+Pj4+IEFydHVy IEhlY2tlciA8QXJ0dXIuSGVja2VyQGh1YXdlaS5jb20+IHdyb3RlOg0KICAgID4+Pj4gICAgID4g SGkgTWljaGFlbCwNCiAgICA+Pj4+ICAgICA+IE15IG9waW5pb246DQogICAgPj4+Pg0KICAgID4+ Pj4gSSBkb24ndCB0aGluayB1bmRlcnN0b29kIHRoZSBxdWVzdGlvbiA6LSkNCiAgICA+Pj4+DQog ICAgPj4+PiAxKSBJdCdzIG5vdCBhYm91dCBXaXJlbGVzcyBBY2Nlc3MgUG9pbnRzLCBzbyBhbGwg b2YgdGhlIFdpZmkgQWxsaWFuY2UsDQogICAgPj4+PiAgICBldGMuIHRhbGsgbWFrZXMgbm8gc2Vu c2UgdG8gbWUuICBUaGVyZSBjYW4gYmUgbm8gYWNjZXNzIHBvaW50cyB1bnRpbCB0aGV5DQogICAg Pj4+PiAgICBoYXZlIGJlZW4gY29uZmlndXJlZC4gIEl0J3MgcG9zc2libGUgdGhhdCB0aGVyZSBt aWdodCBORVZFUiBiZWVuIGFueQ0KICAgID4+Pj4gICAgYWNjZXNzIHBvaW50cywgYmVjYXVzZSB0 aGUgb3BlcmF0b3IgYWN0dWFsbHkgZG9lc24ndCB3YW50L25lZWQgYW55DQogICAgPj4+PiBlbmFi bGVkLg0KICAgID4+Pj4gICAgVGhpbmsgYWJvdXQgaW5zaWRlIG9mIGEgY2FnZSBpbiBhIGRhdGEg Y2VudGVyLg0KICAgID4+Pj4NCiAgICA+Pj4+IDIpIEl0J3MgYWJvdXQgKmRldmljZXMqIHRoYXQg aGF2ZSA4MDIuMTEgaW50ZXJmYWNlcy4NCiAgICA+Pj4+ICAgIFlvdSBjYW4ndCB1c2UgV1BTIG9y IGFueXRoaW5nIGVsc2UgaW52b2x2aW5nIDgwMi4xeCB1bnRpbCB5b3UgaGF2ZQ0KICAgID4+Pj4g ICAgY3JlZGVudGlhbHMsIHdoaWNoIGlzIHdoYXQgQlJTS0kgZ2V0cyB5b3UuDQogICAgPj4+PiAg ICBTbyB5b3UgY2FuJ3QgdXNlIFdQUyB0byAqYm9vdHN0cmFwKiBXUFMuDQogICAgPj4+PiAgICAo YW5kIHB1c2hpbmcgYnV0dG9ucyBvbiB0aGUgZnJvbnQgb2YgdGhlIEFQIGlzIGJ5IGRlZmluaXRp b24gbm90DQogICAgPj4+PiAiemVyby0NCiAgICA+Pj4+IHRvdWNoIikNCiAgICA+Pj4+DQogICAg Pj4+PiAgICAgPiBRMzogU29ycnksIEkgZGlkIG5vdCBxdWl0ZSB1bmRlcnN0YW5kIHRoaXMgb25l LiBJZiB5b3UgbWVhbnQgdGhlIGFkLWhvYw0KICAgID4+Pj4gICAgID4gZXNzaWQgYmFzZWQgbmV0 d29yaywgbXkgZmlyc3QgaW50dWl0aW9uIHdvdWxkIGJlIHRvIG9iamVjdCwgYXMgSQ0KICAgID4+ Pj4gICAgID4gYmVsaWV2ZSB0aGF0IHdlIHNob3VsZCBub3QgcHJlc2NyaWJlIHN1Y2ggbW9kZXMg Zm9yIEFDUCwgYnV0IHJhdGhlciB1c2UNCiAgICA+Pj4+ICAgICA+IHRoZSBiZXN0IGF2YWlsYWJs ZSBvbmUuDQogICAgPj4+Pg0KICAgID4+Pj4gMykgVGhlIEFDUCBpcyBzZWN1cmVkIGluc2lkZSBJ UHNlYyBvdmVyIExpbmstTGF5ZXIgSVB2NiAob3IgTUFDU0VDLCBvcg0KICAgID4+Pj4gICAgYSBi dW5jaCBvZiBvdGhlciBwb3NzaWJsZSB0ZWNobm9sb2dpZXMgaW4gdGhlIEFDUCBkb2N1bWVudCku DQogICAgPj4+PiAgICBJdCdzIG5vdCBhYm91dCB0aGUgc2VjdXJpdHkgb2YgdGhlIEFDUC4NCiAg ICA+Pj4+DQogICAgPj4+PiBTaW5jZSB0aGUgcG9pbnQgb2YgdGhlIEFDUCBpcyB0aGF0IGl0J3Mg YWx3YXlzIGF2YWlsYWJsZSwgaXQgbmVlZHMgdG8NCiAgICA+Pj4+IGJlIGF2YWlsYWJsZSBldmVu IHdoZW4gdGhlIFdpZmkgQWNjZXNzIFBvaW50IGlzIHRvYXN0IG9yIG5vdCB5ZXQgY29uZmlndXJl ZC4NCiAgICA+Pj4+IE9mIGNvdXJzZSwgb25jZSB0aGVyZSBpcyBhIG5vbi1hZGhvYy9JQlNTIG5l dHdvcmsgYXZhaWxhYmxlLCB0aGUgQUNQDQogICAgPj4+PiB3b3VsZCBzZWUgdGhpcyBhcyBhZGRp dGlvbmFsIGludGVyZmFjZXMgYW5kIG1ha2UgYWRkaXRpb25hbCBtZXNoDQogICAgPj4+PiBsaW5r cyBhY3Jvc3MgaXQgZm9yIHRoZSBBQ1AgdG8gdXNlLiAgQnV0IHRoYXQncyBub3QgYm9vdHN0cmFw LCB0aGF0J3Mgb3BlcmF0aW9uLg0KICAgID4+Pj4NCiAgICA+Pj4+ICAgICA+IFE0OiBBcyBJIGJl bGlldmUgdGhhdCBRMiBpcyBzdHJvbmdseSBiaWFzZWQsIEkgYmVsaWV2ZSB0aGF0IHNvIGlzDQog ICAgPj4+PiAgICAgPiBRNC4gVGhlIFdpRmkgQWxsaWFuY2UgYWxyZWFkeSBzcGVjaWZpZXMgc2V2 ZXJhbCB3YXlzIGhvdyB0byBib290c3RyYXANCiAgICA+Pj4+ICAgICA+IHdpcmVsZXNzIGFjY2Vz cyBwb2ludHMsIGluY2x1ZGluZyBlLmcuIFdQUy4gV2Ugd291bGQgcmF0aGVyIG5lZWQgdG8NCiAg ICA+Pj4+ICAgICA+IHNlZSwgaG93IHRvIGludGVncmF0ZSB3aXRoIHN1Y2ggbWVhbnMuIEFuZCBh Z2FpbiwgSSBkb24ndCBiZWxpZXZlIHdlDQogICAgPj4+PiAgICAgPiBoYXZlIGF1dGhvcml0eSBv biB0aGF0Lg0KICAgID4+Pj4NCiAgICA+Pj4+IE1heWJlIHlvdSBjb3VsZCBwb2ludCB0byBzcGVj aWZpYyBkb2N1bWVudHMgdGhhdCB3b3VsZCBwZXJtaXQgdHdvDQogICAgPj4+PiBkZXZpY2VzIHdo aWNoIGhhdmUgbmV2ZXIgYmVlbiB0b3VjaGVkIHRvIGNvbW11bmljYXRlIG92ZXIgODAyLjExDQog ICAgPj4+PiB3aXRob3V0IGNvbmZpZ3VyYXRpb24uDQogICAgPj4+Pg0KICAgID4+Pj4gLS0NCiAg ICA+Pj4+IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVs bWFuIFNvZnR3YXJlIFdvcmtzDQogICAgPj4+PiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQog ICAgPj4+Pg0KICAgID4+Pj4NCiAgICA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICA+Pj4gQW5pbWEgbWFpbGluZyBsaXN0DQogICAgPj4+IEFu aW1hQGlldGYub3JnDQogICAgPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYW5pbWENCiAgICA+Pj4NCiAgICANCiAgICANCiAgICANCg0K From nobody Tue Feb 13 08:25:31 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 586FC12D77E; Tue, 13 Feb 2018 08:25:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151853912930.14349.8912194741189397755@ietfa.amsl.com> Date: Tue, 13 Feb 2018 08:25:29 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-10.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 16:25:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-10.txt Pages : 82 Date : 2018-02-13 Abstract: This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed X.509 certificate, in combination with a vendor's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-10 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 13 13:37:00 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0725C127058 for ; Tue, 13 Feb 2018 13:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 H5J8S1N5RXdN for ; Tue, 13 Feb 2018 13:36:57 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0349126E01 for ; Tue, 13 Feb 2018 13:36:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4461720092 for ; Tue, 13 Feb 2018 16:43:51 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D813780BB3 for ; Tue, 13 Feb 2018 16:36:55 -0500 (EST) From: Michael Richardson To: anima In-Reply-To: <151853912961.14349.6366358483962775318.idtracker@ietfa.amsl.com> References: <151853912961.14349.6366358483962775318.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] New Version Notification for draft-ietf-anima-bootstrapping-keyinfra-10.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 21:36:59 -0000 --=-=-= Content-Type: text/plain WG chairs, after our design team meeting this morning, Max and I believe that -10 is ready for WGLC. (Perhaps we could even complete that before IETF101 and make our outgoing AD happy...) We see the language review from William Atwood, and we'll incorporate that into the document along with any other LC comments. I'm sure that the IESG review will involve two more revisions, but I think we are ready for that step. internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-anima-bootstrapping-keyinfra-10.txt > has been successfully submitted by Michael Richardson and posted to the > IETF repository. > Name: draft-ietf-anima-bootstrapping-keyinfra > Revision: 10 > Title: Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Document date: 2018-02-13 > Group: anima > Pages: 82 > URL: https://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > Htmlized: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-10 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-10 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-10 > Abstract: > This document specifies automated bootstrapping of a remote secure > key infrastructure (BRSKI) using vendor installed X.509 certificate, > in combination with a vendor's authorizing service, both online and > offline. Bootstrapping a new device can occur using a routable > address and a cloud service, or using only link-local connectivity, > or on limited/disconnected networks. Support for lower security > models, including devices with minimal identity, is described for > legacy reasons but not encouraged. Bootstrapping is complete when > the cryptographic identity of the new key infrastructure is > successfully deployed to the device but the established secure > connection can be used to deploy a locally issued certificate to the > device as well. > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > The IETF Secretariat -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqDWncACgkQgItw+93Q 3WUncQf/drUohNh8s8rm+8wz807eBcg2CmpcNNeeqbuofMAQyEZ3WuBA8VJjK0Vl BrElw6/ULRHmEKIz5N4I+aa1CEv9hzuRdDqLmKVctuJAwcjh3FgsmnwCek5mQRe7 dVfiOebOXwa8QQ/F5U4wqCMVi/9J507yJsf8FVzUESqnDJWHLltdCx+qY46cs1zj ZmG7GSWCPousTTQ/q+AZuI/48zR/ZohCzXT/6ShmND09qRcLyCvfcI0g3nddWEFS J/8FzwdbeoAOop2kjDWEP4P2OmAXCL72Of7ezdWGUwz6Bgcl5pX/xasrq1052/1z yVbht/dZ7qev29la8KyFOx6ucgZuRQ== =gQnc -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 13 17:09:28 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD4112DA22; Tue, 13 Feb 2018 17:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 fnUk7EhJfGzh; Tue, 13 Feb 2018 17:09:18 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4722012D944; Tue, 13 Feb 2018 17:09:18 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 75EF358C4FF; Wed, 14 Feb 2018 02:09:10 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 609F1B0DA58; Wed, 14 Feb 2018 02:09:10 +0100 (CET) Date: Wed, 14 Feb 2018 02:09:10 +0100 From: Toerless Eckert To: draft-ietf-anima-bootstrapping-keyinfra@ietf.org Cc: anima@ietf.org Message-ID: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 01:09:27 -0000 Shepherd review against -09. Did just browse through -10, i think it is orthogonal to the comments below. Document is IMHO overall in very good shape! Sorry for length, but i was trying to minimize the number of RTT to resolve comments by trying to explain my comments as good as possible. In many cases this resulted in proposing text to better explain something where i wasn't even sure if i undersstood it correctly. In those cases the texte is always a suggestion, but the ask is to provide appropriate explanation of the subject matter. Let me know if/how i can help getting the comments applied. Cheers Toerless --------------------------------------------------------------------------------------- 1.2) Terminology: a) vendor vs. manufacturer. The document uses 48 times "vendor" and 13 times "manufacturer". Please revisit this: If there is a clear reason when/why to use vendor and when/why to use the term "manufacturer", then please put these explanations into terminology. Otherwise maybe eliminate "vendor". For example: Abstract: "using vendor installed X.509 certificate" ... "vendor's authorizing service". This latter one definitely seems to be wrong (MASA = "manufacturer authorizied..., not vendor). b) Key infrastructure There is no definition/reference for this term. Please describe on first use and in terminology. Is there a difference between "key infrastructure" and "keying material" ? If not, then maybe remove one term otherwise pls. describe difference. c) (terminology) MASA definition: "A third-party Manufacturer...". Why "third-party" ? who are the first two parties ? If this is only slang and we can't explain who the first two parties are, delete "third-party" ? d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because the text mostly uses "Domain Registrar" and very seldom "Join Registar". JRC is used in exactly three places in the draft. I also can not find on www.google.com or wikipedia any example of "The term JRC is used in common with other bootstrap mechanisms" as the Terminology claims. Either provide a non-anima reference for the use of that term or eliminate it in the document. Suggest to use "(Domain Join) Registar (and Coordinator) in 1.2 and say for example that the text uses "Join Registrar" when referring to the mechanics of building the connection (Join Proxy and Join Registrar) and Domain Registrar when discussing authentication and any other aspects of the registrar (where the domain is relevant). e) Voucher - misses ":" after term. - please change "statement" to "artifact" so the terminology aligns with both voucher draft and voucher-request text which also uses artifact. See also section 2.2 where you use "cryptographically protected" instead of "signed" and figure out which term you want to use in all cases (hint: signed). f) IMPORTANT: Please add/define the term "ANI" ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI systems (pledges, proxies, registrar) have specific requirements detailled in the document. Without this term we can not nail down the explicit requirements against ANI Pledges, Proxies, Registrars that we need from the document (and distinguish from requirements against any non-ANI adaptation of BRSKI). I added according comments into other parts of the doc. g) Please replace "MASA server" with "MASA service" everywhere. ----------------------------------------------------------------------------- Overall: a) Requirements about EST: - The introduction says: "Integration with a complete EST enrollment is optional but trivial" - 5.8.3 says "The Pledge MUST request a new client certificate". - 1.4 says "bootstrapped devices have a common trust anchor and a certificate has optionally been issued from a local PKI a) The text needs to be made consistent across all places where requirements are defined. I have in general no strong opinion how "optional" the text should say EST operations are, BUT consider he following points: b) We need a complete list of BRSKI requirements for ANI devices, where EST operation requirements are made stronger. I suggest a separate subsection at an appropriate place so that "ANI requirements" shows up in the table of contents: Section X.Y.Z Requirements for ANI devices: For BRSKI on ANI Devices (ANI = BRSKI + ACP), EST operations is mandator. The ANI pledge MUST perform - "CA Certificates Request", - "CSR Attributes" - "Client Certificate Request" - "Enrollment status Telemetry" The ANI registrar MUST support BRSKI and these EST operations. All ANI devices SHOULD support the BRSKI proxy function. c) If EST operations are optional, how about the following considerations: I) In instances of BRSKI where no EST operations happens after bootstrap, the Pledge only has trust anchors, but no certificate. This may still be useful, but today i think this is not really a considered option at all: After receipt of the voucher, the pledge is willing to do some action on behalf of the BRSKI connection it was previously unwilling to - e.g: receive & apply config. (i thought Max never liked this idea..., so if it is off the table, then _some_ subset of EST seems mandatory because EST operations is the only thing alowed after receiving a voucher that Ma would like.... unless Max has changed his opinion). II) This leaves the option that EST to install trust anchor is mandatory, but enrolment with a certificate is optional (except for ANI case). Aka: would be good to write a sentence/paragraph exactly outlining what is permitted to happen after a voucher and if any, what parts of EST are deemed to be necessary by BRSKI (outside of ANI devices. the requirements for ANI devices are listed above). ----------------------------------------------------------------------------- 1.) Introduction a) The intro of 1. is somehat confusing to the uninitiated. Suggest the followinf replacement text for two paragraps: BRSKI provides a solution for secure zero-touch (automated) bootstrap of virgin (untouched) devices that are called Pledges in this document. These Pledges need to discover (or be discovered by) an element of the network domain to which the Pledge belongs to perform the bootstrap. This element (device) is called the (Domain Join) Registrar. Before any other operation, Pledge and Registrar need to establish mutual trust: Then the four existing bullet points, but number them. Then followed by th following paragraph to replace the existing paragraph after the four bullet poins. This document details protocols and messages to answer the above questions. It uses a TLS connection and an X.509 certificate (LDevID) of the Pledge to answer points 1 and 2. It uses a new artefact called a "voucher" that the registrar receives from a "Manufacturer Authorized Signing Authority" and passes to the Pledge to answer points 3 and 2. b) It would be nice to have a paragraph mentioning the proxy as a mean to provide easier connectivity for Pledges (no need for full network connectivity). ----------------------------------------------------------------------------- 1.1) a) "other Bootstrapping Approaches": "other" -> "prior" or "existing" ? b) "_or_ that domain-specific keying material". Is this not an _and_ ? c) "in a costly and non-scaleable manner". "non-scaleable" may be hard to argue. Whole economies where built on manual labor. Might rather use qualifiers such as "little or not at all automated", "error-prone" and/or referring to physical security (.e.g: trusted pre-staging location). d) "existing mechanisms" -> "existing automated mechanisms". e) Paragraph 2 and following about EST: The first two sentences sound contradictory/conflicting. "...minimize user action..." , "details a set of non-autonomic bootstrapping methods". Suggest text like: "EST does reduce user actions during bootstrap but does not provide solutions for how the following protocol steps can be made autonomic (not involving user actions). (Note: first use of "autonomic" here, so an explanation like "not involving user action" is required (any other definition here what autonomic or non-autonomic means in the context of this document is fine too, "not involving user action" is just a suggestion). ----------------------------------------------------------------------------- 1.3) a) The order of paragraphs is confusing. Even if the mayority of readers (which i don't think) would primarily be interested in class 1 devices, it is irritating in style and context to start with the first two paragraphs. I would suggest to start with existing paragraph 3, change maybe the sentence to "This solution (BRSKI) can support large router platforms..." Then insert the first two paragraphs after current paragraph 5. All the text after paragraph 5 already discusses constrained situations so it would nicely follow on to the first two paragraphs. b) paragraph 5 is confusing: What is a handoff, why would somebody even think to apply BRSKI in a handoff, and why is there a normative, capital letter SHOULD. Here is how i would write it more explanatory (if i understand the implied use case correctly): BRSKI could be used by nomadic or mobile devices to aquire certificates used as credentials to access the network at the new location. This is usually called handoff. Nevertheless, BRSKI is not intended for low-latency handoff which is usually a requirement in mobility solutions (e.g.: seamless handover). For these solutions BRSKI could be used to aquire keying material and re-use that during handover without re-initiating BRSKI during handover later on. (which is also implying that re-using BRSKI in nomadic environments is not off the table, but not saying so explicitly because we really have not thought that trough a lot). c) It would loosen up a very long section to create three subsection headings - supported environments - constrained envionments - network access control ----------------------------------------------------------------------------- Section 2 1) a) ..Each component is logical and may be combined with other components as necessary.. Ok. I always want the pledge to live in the same device as the MASA. Would suggest deleting that sentence. More harm than benefit. b) I suggest to move section 2.4 up to become section 2.1) directly after the picture in section 2., because otherwise there is no explanaction following the picture. c) "The a domain" (delete a) ----------------------------------------------------------------------------- Section 2.1 a) The term "Request Join" is only used here, and its IMHO not very logical (disclaimer: toerless: en.wikipedia.org/wiki/ESL). It sounds to me like the pledge says "i want to join". And also sounds as if the pledge could be disappointed if rejected. I would rather call it "Domain membership inquiry". Or if you're hooked up on the term "joining", then maybe "Join Inquiry". Whatever best makes it clear that rejection is a perfect and important outcome option. b) Please see my issue section 5.1 a). If you agree with that statement, then there should be no "rejected" arrow in Figure 2 coming out of the "Identify" block. I would also suggest that the "Bad Vendor response" arrow does not come out of the "Imprint" block but out of the "Request Join" block. AFAIK, this is an error reply to the Request Voucher, so it happens before imprinting (imprinting happens only when there is a vocker reply. AFAIK). I don't think "Bad Vendor reply" in Figure 2 is a good term. Most logical to me would be "Error or not member". In any case, the text in section 2 below should mention the exact words used on the labels, the text is missing ll the labels on the left: "Factory reset", "Enroll Failure", "Bad Vendor response",... c) Point 1 nicely explains how this is done during TLS. Likewise, Point 2 should mention that this is the "Voucher Request", and Point 3 should mention that it is the "Voucher Reply" - so readers can match up section 2.1 with the rest of the document. remove the "e.g." from "protocol, e.g. Enrollment over". Otherwise some text outlining when something else than EST is to be used. (see next comment). d) I am missing in the initial chapters a succinct summary how EST enrollment is optional and what can be achieved with/without it, there is only some side sentences later in the EST sections. I would suggest to insert such an explanation here. After point 4 insert (unnumbered) paragraph: | After step 4, the pledge has received and authenticated an explicit TA (trust anchor) | (pinned-domain-cert in the Voucher response). In some use cases this may be sufficient | and the bootstrap can be terminated here. The pledge can now use this TA to securely | trust domain members, but it can not securely identify itself to them as a domain member. | Therefore BRSKI usually proceeds with the following steps that support this via EST | enrollment (see also 5.5.1 for the limitations of the trust feasible through the imprint). Also maybe insert some dotted line between imprint and enroll in Figure 2 to highlight this distinction. Maybe with "mandatory" / "optional" (EST enroll part) on the right hand side ----------------------------------------------------------------------------- Section 2.2 a) The core sentence is hard to understand because it does not spell out the implication of the alternatives: At the lowest security levels the MASA server can indiscriminately issue vouchers. At the highest security levels issuance of vouchers can be integrated with complex sales channel integrations that are beyond the scope of this document. Would suggest amending like this: At the lowest security levels the MASA server can indiscriminately issue vouchers AND LOG CLAIMS OF OWNERSHIP BY DOMAINS. At the highest security levels issuance of vouchers can be integrated with complex sales channel integrations that are beyond the scope of this document BUT THAT WOULD INTENT TO VERIFY ACTUAL (LEGAL) OWNERSHIP OF THE PLEDGE BY THE DOMAIN. b) "Vouchers provide a signed but non-encrypted communication channel between the Pledge, the MASA, and the Registrar." Why is this mentioned ? If there is a conclusion of this statement that is relevant to BRSKI it should be spelled out, otherwise its a detail belonging into voucher. I do not see how the following sentence is that relevant conclusion. But maybe i am too confused by the sentence structure. Do you mean something like this: | Vouchers are signed but not encrypted. This allows registars to maintain | better control over pledges attached to the domains network by examining | and filtering Vouchers received from a MASA before sending them to the pledge. If thats the idea, i suggest to use language like i suggested because it's more explicit and simpler (not having to think what the relevance of "communication channel" is etc..). Also may warrant a note that this control does not necessarily apply to the case of a Cloud Registrar (see section 2.6). ----------------------------------------------------------------------------- Section 2.3) a) The first paragraph is too terse and not very explanatory arguing why BRSKI mandates and how it uses the IDevID. I would suggest a bulleted list with explained reasons: - Uniquely identifying the pledge by parameters in the IDevID. The unique identification of a pledge in the voucher objects are derived from those parameters as described below. - Securely authentating the pledges identity via TLS connection to registrar. This provides protection against cloned/fake pledged. - Secure auto-discovery of the pledges MASA by the registrar via the MASA URI in IDevID as explained below. - (Optional) Signing of voucher-request by the pledges IDevID to enable MASA to generate voucher only to a registrar that has a connection to the pledge. - (Optional) authorizing pledge (by registrar) to receive certificate from local CA. I am unclear about the "authenticating the Pledge during subsequent protocol exchanges ...". Does this refer to the TLS exchange or others ? If others, then please list accordingly maybe as a separate bullet point which those are. Please keep the "There is no requirement for a common root PKI hierarchy. Each device vendor can generate their own root certificate." ----------------------------------------------------------------------------- Section 2.3 2) a) Please put the description of identification of the pledge into a subsection 2.3.1 "Identification of the Pledge" b) I am confused about the first MUST (serialNumber) and following SHOULD (HardwareModuleName). The conversion rules make it clear that you want the device to be uniquely identified via the serialNumber, but if that is not in the certificate, then you would use the HardwareModuleName. Therefore the conversion rules contradict the MUST for serialNumber. Or else you wouldn't define a fallback if it does not exist. c) The MUST/SHOULD bullet points are IMHO a duplication of the conversion rules, so maybe just drop them. d) I would start the section with a sentence clearly describing what is done here: In the context of BRSKI, pledges are uniquely identified by a "serial-number". This serial-number is used both in the "serial-number" field of Voucher or Voucher requests (see section 3.) and in local policies on Registrar or MASA (see section 5.). The serial-number is derived from the IDevID as follows: ... then add the three bullet-points. e) I do not see "serialNumber" attribute mentioned in rfc4514 nor rfc4108. You mention "previously defined". Could you provide a reference where "serialNumber" was defined ? f) Please provide example of each of the three fields and how they convert into serial-number. This is especially important because for the average reader who has never seen a certificate (and with no actual reference to e.g.: serialNumber format thats easily readable), it may be hard to understand if or how something called "serialNumber" can unique identify a device - aka: that it includes also the device-type (unless a company only produces one type of device and somehow even the name of the company can be implied). e.g.: if i take the Cisco device IDevID format i used on the anima mailing list before: serialNumber=PID:C819HWD-A-K9 SN:FXXXXFZ That "PID/SN" format makes it clear how a device can be uniquely be identified, so it would be a great example if it was not just a Cisco speciality (hence the ask for any reference for the definition). Could be anonymized accordingly: serialNumber=PID:MEGAROUTER1 SN:12345 I also think the examples would be good to explain what otherwise would likely be hard to figure out from references (assuming there would be references): - To uniquely identify a device, the certificate field choosen needs to contain some form of at least a product identifier and an actual serial number of that product identifier. - Note that the certificate field itself does not need to identify the manufacturer/brand of the product as long as the field is unique within the scope of the IDevIDs root of trust. For example both the EXAMPLE and the ACME manufacturer/brands could have a MEGAROUTER1 product as long as they use different root of trusts for their IDevIDs. - Product that have a unique root of trust may have a certificate field that is only containing an actual serial number but no product identifier. I have no examples of HardwareModuleName. If there is a specific set of devices or industries that prefers/mandated HardwareModuleName instead of serialNumber, then an explanatory sentence would be good. I only have a non-working example of the "common name" , e.g.: in the cisco example it was: cn=C819HWD-A-K9 which would be insufficient. So any explanation of known cases where the common name would actually be used (absence of serialNumber/HardwareModuleName) AND sufficient would be great to describe (not necessarily referring to specific vendor/manufacturers but rather product types if possible). g) Please change the examples "JADA123456789" in the remainder of the document to the example choosen here. h) Probably need to end the section with "Device types whose above mentioned IDevID attributes do not allow for unique identification of devices are outside the scope of this specification. ". Unless you are sure this case can not exist. ----------------------------------------------------------------------------- Section 2.3 2) a) Please put the description of MASA URI into a subsection 2.3.2 "MASA URI" b) If the following statements are correct, i would suggest to integrate them into the section text to make it clearer and more explicit. If not then i did not understand how it is meant to work and the explanations could be approved accordingly to make it clearer: - The type and format of the MASA URI indicates the protocol supported by the MASA. - If a MASA supports multiple protocols, multiple instances of the new MASA URI can be put into the certificate. - This document defines the BRSKI-MASA protocol. It is indicated through a URI of the form MASA URI is "https:// authority "./well-known/est". see section 5 for more explanations. (this would replace the current sentence mentioning section 5). c) We discussed the risk of introducing new certificate fields and potential compatibility issues with existing code parsing such a certificate. Which is why we went for the obfuscated email encoding of the ACP information in the LDevID. It would therefore be good to have an explaining sentence why the new MASA URI extension is a better solution than encoding into existing attributes and safe to deploy into devices. I am not sure about the full extent of the answer, but probably IDevIDs are meant to and actually used in a far smaller and newer set of software than that processing arbitrary LDevIDs. Therefore the risk is smaller and the clean encoding outweights the risk of compatibility issues with badly written old software. ----------------------------------------------------------------------------- Section 2.4.1) 1) "it does has network" -> "it does have network" But better: "it does only require subnet (link) local connectivity to the circuit proxy but no routeable IPv6/IPv6 address (exception: see section 2.6)". ----------------------------------------------------------------------------- Section 2.4.2) 1) "The proxy mechanism" -> "The circuit proxy mechanism" " optional stateless mechanism" -> "optional stateless proxy mechanism" add: The registrar (likely?) also needs manual configuration of per-MASA credentials to contact them (see section 5.3). Q: Any case where unauthenticated BRSKI-MASA connections make sense ? ----------------------------------------------------------------------------- Section 2.4.3) 1) Suggest to clarify roles: separate functions: the MANDATORY ...MASA including audit log, and an ADDITIONAL OPTIONAL Ownership Tracker providing sales channel integration. Aka: reuse same terminology so readers are not confused. Maybe go through text to check only "ownership tracker" and "sales channel integration" are used for that part. ----------------------------------------------------------------------------- Section 2.4.3) 1) a) Expand CMC. "authenticate any pledge" -> "authenticate (the IDevID of) any pledge" b) The document is still very vague on terminology to distinguish between the initial bootstrap and the (optional) EST server role. Please come up with a clear terminology and clearly summarize the functionality required to be supported by the roles. Here is my suggested text. If any explanation to cover this information is felt to be too long for 2.4.3, please find another place but make 2.4.3 refer to that place. | A "Domain Join Registar and CMC" (abbreviated Domain Registrar in most of the document) | serves two roles: BRSKI Bootstrap Service and BRSKI enhanced EST Enrollment Service. | | The "BRSKI Bootstrap Service" role is newly defined in this document. It performs | the bootstrapping of Pledges with a "pinned-domain-cert" called trust anchor. | The BRSKI Bootstrap Service communicates with the Pledge and the MASA. It does | not need to communicate with the Key Infrastructure (as long as it can support | cacerts from locally stored information). As a HTTPS/REST server it supports the | following REST services under /.well-known/est/ newly defined in this document: | /voucher-request, /cacerts, /status-telemetry | As a HTTPS/REST client, it support the following REST service under /.well-known/est | to request vouchers from MASAs: | requestvoucher, requestauditlog | | The "BRSKI enhanced EST Enrollment Service" is an enhanced version of the RFC7030 | defined EST-Server to support automated enrollment of Pledges with certificates. This | role does not need to support certificate renewal or other services not related to initial | enrollment. This role communicates with Pledges and Key Infrastructure. It does not | communicate with MASA. As a HTTPS/REST server it supports (at least) the following | RFC7030 defined servervices under /.well-known/est/: | /cacerts, /fullcmc, /csrattrs, /simpleenroll, /serverkeygen | This document does add new requirements against the details required to be supported | in the /csrattr service. | In addition, it supports the new service under /.well-known/est defined in this document | (which makes it a "BRSKI enhanced" EST Enrollment Service): | /enrollstatus [Here is where i wonder:] | While not recommended, BRSKI Bootstrap Server and BRSKI enhanced EST-Server can |be provided by separate servers. In this case, the BRSKI Bootstrap Server must | support redirection of the Pledge after a successfull requestauditlog to the | URI of a BRSKI enhanced EST-Server. [I am not sure if this is true, or how else it would work, but if that separation is meant to be supported that level of detail needs to be written, otherwise the opposite:] | This document does not cover cases where BRSKI Bootstrap Server and BRSKI enhanced EST | Enrollment Server are separated onto two servers. It also does not define what | (additional) functionality might be required on Pledges to support this. IMHO with the current design decisions, one would even need to write something like this: | The design choosen in BRSKI does not always allow to use common modular design | choices of HTTP(S)/REST servers to separate the Bootstrap Service from the enhanced | EST enrollment service without operating them on separate transport locators: | When using a single transport locator, REST request can only be demultiplexed | by the request path and both Boothstrap Service and EST enrollment service do not | only share the /.well-known/est/ prefix but even the same /cacerts command. c) The document must include a statment such as: | An ANI "Domain Join Registar and CMC" MUST support both BRSKI Bootstrap Service | and BRSKI enhanced EST Enrollment Service roles. [or whatever terms you choose to use] ----------------------------------------------------------------------------- Section 2.4.4) a) It would be IMHO good to move the (mayority of the) initial paragraph of 5.4 into this section to explain what the scope of the MASA functionality is by listing the interface services requestvoucher and requestauditlog here - similar to how i proposed to summarize the interfaces of the Domain Registrar above for section 2.4.3. 5.4 is not a good place to do that because it's only about requestvoucher, and then after another non-maza intermezzo 5.6 requestauditlog is again about the MASA. So no single place summarizing the MASA functionality at this level. More details see comments about 5.4 below. ----------------------------------------------------------------------------- Section 2.4.x) a) Please add subsection "Architectural Component: Key Infrastructure (PKI)" Suggested text (as in: this is the type of information i would like to see explained here, whatever language you use): | The Key Infrastructure (PKI) administers certificates for the domain of concerns, | providing the trust anchor(s) for it and allowing enrollment of Pledges | with domain certificates. | | The Domain Registrar ('s BRSKI Bootstrap service role) uses a Trust Anchor (TE) | from the PKI in the BRSKI Voucher pinned-domain-cert to authenticate itself to the | Pledge with the help of MASA. | | The Domain Registrar ('s BRSKI enhanced EST enrollment service) acts as an | EST Server and request certificates for Pledges from the Key Infrastructure. | | The requirements and expectations against the Key Infrastructure are unchanged | from RFC7030: There are no BRSKI specific features defined or required for | the Key Infrastructure - only for the Domain Registrar. Would especially like to see something like the last paragraph because its IMHO the key part of being able to deploy BRSKI and right now it's hidden in explanations in specific explanation in section 5. b) Figure 1 labels the path to the PKI with "EST" and i remember Max to repeatedly state that CAs could support EST. Nevertheless, i read in RFC7030: "The nature of communication between an EST server and a CA is not described in this document". But then it defines the term "EST CA". So i am confused if there is an actual spec stating the EST profile? of an EST CA. Aka: Can we write here: | It is recommended but not required that the Domain Registrar ('s BRSKI enhanced EST | Enrollment service) also uses RFC7030 to talk to the PKI, e.g.: a CA or subordinate | CA supporting EST. Nevertheless, the Domain Registrar may choose any standardized | or non-standardized protocol to talk to the PKI. If we can not make the first part of that statement here, then also remove "EST" label from picture 2 and replace with something like "Any CMC? protocol" ? ----------------------------------------------------------------------------- Section 2.5) 1) a) If the following sentence is functionally correct, please add text accordingly: Bootstrapping Pledges that have a Realtime Clock (RTC), SHOULD use it to verify certificate validity. b) And from my own experience, it should add: but they MUST be prepared to recognize local time failure and revert to the above described mechanisms. For example when RTC battery failure leads to a well-known default-time (e.g.: Jan 1 1970). ----------------------------------------------------------------------------- Section 2.5) 2) a) Please move the bullet about the registrar behavior out of the bullet list, maybe at the end of the section. Even better: - rename 2.5 to "Certificate Validity" - 2.5.1 "Lack of Realtime Clock in Pledges - 2.5.2 "Infinite Lifetime of IDevID" (move text into 2.5.1) b) Its hard to comprehend what the pargraph means to say. I think its something like: According to RFC5280, IDevIDs are examples of certificates that should have no well-defined expiration date. This is indicated through the GeneralizedTime value of 99991231235959Z". Registrars SHOULD have a configuration option to ignore IDevID lifetime values if they do not conform to this recommendation. As expected, i always like an explicit example to bring it to the point: For example, IDevID may have incorrect lifetime of N <= 3 years, rendering replacement Pledges from storage useless after N years unless registrars support this option. ----------------------------------------------------------------------------- Section 2.6) IMHO, without further text, it is unclear a) what a cloud registrar is, b) why we care and c) how a solution using a cloud registrar would have to be built to work. To resolve a), b) better i suggest to replace first paragraph with something like this: Local Registrars are those for which proxies can be discovered by means under control of the network to which the pledge connects, such as GRASP or mDNS (see ). When a pledge connects to a network connection not under the control of the domain claiming to own the pledge or if the Pledge's target use cases want to simply deployments by avoiding the use of proxies, local Registrars and/or network methods to discover proxies, then the pledge can only connect to a so called Cloud Registrar via a URL well-known to the non-bootstrapped pledge. c) If i understand it correctly, then the explanation for c) would be something like this: When a cloud registrar is used, it must be assumed that it is not operated by the owner of the pledge. Instead, it would be operated by or on behalf of the manufacturer similar to the MASA. Such a Cloud Registrar can provide a Voucher to the Pledge, but that Vouchers pinned-domain-cert could not help the Pledge to authenticate the BRSKI EST connection because the Cloud Registrar does not belong to a domain of the owner which the pinned-domain-cert is used for. Therefore trust for the Cloud Registrar must be provided by the Plede itself: [add existing second paragraph of 2.6 here] [I am not sure exactly how you thought about answering c). Here is what i guess could work:, so this would have to go at the end of 2.6 ] A Cloud Registrar may operate in different ways: III) It can answer the Pledges Voucher request with a redirect response to cloud based BRSKI Registrar oeperarted by or on behalf of the Pledges domain owner. We call this service of a Cloud Registrar the "redirect-only" model. When the Pledge connects to that BRSKI server after the redirect, it would again have to perform delayed authentication of the Registrar after it receives a Voucher from it. II) Alternatively, the Cloud registrar could provide the pledge with a Voucher and respond with a redirect response to a successful Voucher Status Telementry, redirecting the Pledge to a potentially cloud based EST server operated by the owner of the pledge to complete the Pledge enrollment with a domain certificate. When the pledge connects to that EST server, it can authenticate it using the pinned-domain-cert from the Voucher. The pledge would not need to repeat the Voucher request/Status telemetry transactions. II) Finally, the Cloud Registrar could provide Voucher AND EST enrolment to the Pledge directly without any redirect. The mutual trust models for this (between the domain owner and Cloud Registrar operator) are outside the scope of this specification. Finally, most crazy (but i know how customers had to do this with pre-BRSKI methods, so it might make sense): Pledges MAY support a model in which domain operators could redirect URI connections from a cloud registrar to a domain operated Registrar because this can be a lightweight Registrar discovery mechanism - assuming the pledge connects to a network under control of the domain operator. This can be done by overriding the DNS resolution for the URI or transport layer redirection. In this case the above decribed implicit TA check by the client for the TLS connection to the Cloud Registrar fails, but the Pledge falls back to the delayed authentication after receipt of a voucher as it does for non-Cloud Registrars. If you feel this is overall too much, then maybe delete the whole section 2.6 and put it into a followup document. Borderline to me. If its "just" what i sugested above, its fine, if there is more to it to make it work, maybe better in separate document. ----------------------------------------------------------------------------- Section 2.7 1) a) > Note that the Registrar can only select the configured MASA URL based on the > trust anchor -- so vendors can only leverage this approach if they > ensure a single MASA URL works for all Pledge's associated with each > trust anchor. I do not think this is true. A registrar could have configuration policy mapping from IDevID serial-number patterns to MASA URI. Rewrite accordingly ? Let me know if you hate this approach, i had had to brainstorm it for my planned yang model for ANI. b) I also think it might be necessary for Registrars to allow policies that override MASA URIs learned from the IDevID because the longevity of URIs can not always be guaranteed and the MASA may move (merger & aquisitions etc.. ). c) I am unclear from the document whether registrars may require configuration to know what specific options for voucher-requests a MASA supports. - If i understand it correctly, a registrar may use a voucher-request to request a voucher in the absence of the pledge (stage the voucher). This certainly is something not every MASA must support, so that would need to be configured. - It is not clear to me if the REgistrar can correctly fill out all Registrar voucher-requests in the presence of the pledge (aka: after receiving the Pledge voucher-request). See also discussion for Section 3. If this is not fully automatic, but may rquire Registrar configuration, this counfig should be mentionedhere. ----------------------------------------------------------------------------- Setion 3. 1) So... I guess Registrars can request Vouchers for pledges before being in contact with that pledge, right ? If correct, the following would be less confusing to read for me: | Voucher-requests are how vouchers are requested. | | A Pledge send "Pledge voucher-requests" and submit them to the Registrar. | The Registrar in turn submits a voucher-request to the MASA server. The | "proximity-registrar-cert" leaf may be used in these Pledge voucher-requests. | The "prior-signed-voucher-request" leaf may be used in Registrar voucher-requests | that include a Pledge voucher-request. See [XXX] for a description of the | semantics of these leafs. | | An addition, Registrars may retrieve (nonceless) vouchers by sending | Pledge voucher-requests to the MASA. The "prior-signed-voucher-request" leaf | is never used in these voucher-requests. In any case, you need at least a forward reference for those leaf types if you want to mention them without other explanations. ----------------------------------------------------------------------------- Setion 3. 1) a) Even with above concern Section 3. 1) fixed the section still does not provide a good taxonomy of the different type of voucher-requests and how to fully identify them because of the "may be used"... b) There is no text here explaning how a registrar transforms a Pledge Voucher request to a Registrar voucher request. If explained later, insert a forward reference. Else. pls add text to explain. b) I have my doubts that the flow of the document is ideal with all the yang formalisms thrown into section 3. If this is what other documents do as well, fine. I for once would like it better if it was put into a separate section towards the end of the document. "nah, not going to happen" is an acceptable answer ;-) ----------------------------------------------------------------------------- Setion 3.2 1) "provides voucher examples" -> "provides voucher-request examples" ----------------------------------------------------------------------------- Section 4. 1) a.1) Suggest to change title to "Proxying Details (Plege - Proxy - Registrar)" because the section does not only discuss the proxy but also the aspects/reqirements of proxying relevant to Client and Registrar. a.2) paragraph 1: "configured on the Proxy" append: "or automatically discoverded (e.g.: via GRASP, see below). b) Add: This section defines a statefu proxy which is therefore called a "circuit" proxy. c) Simplify whole paragraph with "(In a completely autonomic network...)" - this discussion is not specific to AN. E.g.: Registrars are assumed to have logically a locally integrated Proxy to support directly (subnet) connected Pledges - because Registrars themself does not define any functions for Pledges to discover them. Such a logical local proxy does not need to provide actual TCP proxying (just discovery) as long as the Registrar can operate with subnet (link) local addresses on the interfaces where Pledges may connect to. d) "to discovery the" -> "to discover the" e) Paragraph starting with: "If the Proxy joins an Autonomic Control Plane" Suggest following replacement: In the ANI, the Autonomic Control Plane (ACP) secured instance of GRASP () MUST be used for discovery of ANI Registrar ACP addresses and ports by ANI Proxies. The TCP leg of the proxy connection between ANI Proxy and ANI Registrar therefore also runs across the ACP. (separate because it would apply for any GRASP learning, not only ACP): If GRASP is used by proxies for discovery of Registrars (ACP or not), the proxy can also learn the proxy mechanism (Circuit Proxy vs. IPIP encapsulation or other) (there is no negotiation in GRASP, therefore "agreed" as in current text is not a good choice of word). f) "SHOULD be the same as on the registrar in order for the proxy to remain stateless". Does such a proxy makes sense when it is not stateless ? Aka: should this not be a MUST instead of a SHOULD ? ----------------------------------------------------------------------------- Section 4. 2) "In order to permit the proxy functionality to be implemented on the maximum variety of devices... with available capabilities for the proxy function similar to many class 2 IoT devices" This IMHO is an incorrect assumption. I am not aware of any network device in ANIMAs "well managed network" charter" that would today fall into class 2. I was and am often extremely annoyed how underpowered control plane of multi-terrabit switches are but those too don't get down to that level. Even OpenWRT small home rotuers (outside scope of ANIMA) don't go below 4 MByte these days. Here are statements i could support/recommend: - Registrars must support the proxy method supportable by the type of proxies it needs to support. If pledges could be IoT class 2, then IPIP would be a better solution for them than a CP circuit proxy. Note that in ANI adopted to class 2 IoT or similar "mesh network" solutions, Plege become proxies proxy and therefore IoT class 2 pledges imply also the need to support IoT class 2 proxies. ----------------------------------------------------------------------------- Section 4.1 1) a) "[RFC4941] temporary addresses is encouraged...." Please remove or add text explaining why. Given how a pledge is happy to spill it's IDevID to everyone claiming to be a proxy i am not sure what benefit privacy addresses have, and they are additional implementation work for pledges, whereas link-local (permanent) addresses are always required. And changing addresses makes diagnostics harder. I also am not even sure if RFC4941 is even creating additional link-local (temporary) addresses. I don't even think so. And all the concerns RFC4941 discusses about correlating traffic is hardly applicable to what the link-local address is used for. link local GASP discovery, BRSKI-TCP, maybe later some ACP tunnell.. b) IMHO the text should express the following reuirements: - ANI Plegdes and ANI Proxies MUST , other Pledges/Proxies SHOULD obtain link-local scope IPv6 addresses according to [RFC4862] ... (RFC4862 also specifies global addresses, so text needs to be specifica about just the link-local scope IPv6 addresses). - Pledges MAY use RFC4941... if you can figure out some text explaining why. - ANI Pleges/Proxies MUST, other Pledges/Proxies SHOULD use DULL GRASP announcements of the objective ... ----------------------------------------------------------------------------- Section 4.1 2) > Methods SHOULD be run in parallel to avoid head of queue problems > wherein an attacker running a fake proxy or registrar can operate > protocol actions intentionally slowly. methods == circuit proy, IPIP, ... ? would also be recommended to try different proxies in parallel, right ? > Once a connection to a Registrar is established (e.g. establishment > of a TLS session key) there are expectations of more timely > responses, see Section 5.2. not clear what the pointer to 5.2 is good for. Does not explain how establishment of TLS session key helps. IMHO, you need to finish authentication of TLS connection before you can trust registrar and expect timely responses. But thats not where the problem of trusting the connection ends... Suggested text fixes: | Pleges SHOULD attempt bootstrapping via multiple discovered proxies and/or | methods supported by them (TLS circuit proxy, IPinIP,..) in parallel ... | [continue with existing paragraph text] | | Only once the Pledge has completed authention of the provisional bootstrap TLS | connection (received & authenticated a voucher), can it expect to talk to a | legitimate Registrar, and from then on there SHOULD be an expectation of | more timely responses by the Proxy. | | To achieve this, Registrars need to ensure that only legitimate Proxies can | build connections to them. ANI Registrars for example only permit ANI Proxies to | connect to them because they must use the ACP. In addition deployments of | legitimate Proxies SHOULD | take measures that prohibit fake proxies to become | Men-In-The-Middle attackers between them and Pledges - such as filtering of | (GRASP) discovery | messages from user (fake attacker) ports on access layer 2 switches. ----------------------------------------------------------------------------- Section 4.1 1) a) The requirement to do proxy discovery via GRASP was already written in 4.1. Please remove. Please use term DULL GRASP instead of just GRASP. > proxy-objective = ["AN_Proxy", [ O_IPv6_LOCATOR, ipv6-address, > transport-proto, port-number ] ] > > ipv6-address - the v6 LL of the proxy > transport-proto - 6, for TCP 17 for UDP > port-number - the TCP or UDP port number to find the proxy That text does not use correct GRASP syntax. It is IMHO highly useful to also have an example - to understand where address, port number etc. are. I would also suggest to revisit the name of the objective. The objective name suggested in the following proposed text would be aligned with the mDNS names i would suggest: - It is IMHO counterproductive to have "AN" in the name. BRSKI should be able to be adopted without other ANI/AN components, and whoever adopts it should have to change as little as possible. - bootstrapks for mDNS is IMHO not ideal. The mechanism is known by the name brski. Thats like using "enrollmentst" instead of "est" (luckily "est" was registerd with IANA!). - Want to be able to announce/discover both registrar and proxy, therefore IANA service-names should be (IMHO) brski-proxy, brski-registrar. Here is suggested text: Example: [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 180000, [ ["SRV.brski-proxy", 4, 1, "https" ], [O_IPv6_LOCATOR, h'fe80000000000000c0011001FEEF0000, TCP, 15000] ] , [ ["SRV.brski-proxy", 4, 1, "coap" ], [O_IPv6_LOCATOR, h'fe80000000000000c0011001FEEF0000, UDP, 13000] ] , ... optionally more objectives, such as ACP as described above ] The formal CDDL definition is: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] objective = ["SRV.brski-proxy", objective-flags, loop-count, objective-value] objective-flags = sync-only ; as in the GRASP specification sync-only = 4 ; M_FLOOD only requires synchronization loop-count = 1 ; limit to link-local operation objective-value = method method = "https" ; or future methods ; CoAP not considered yet, see below The objective-flags field is set to indicate synchronization. The loop-count is fixed at 1 since this is a link-local operation. It is recommended to send these M_FLOOD messages every 60 seconds, the TTL in the above example is 180 seconds (18000 msec). The session-id is a random number used for loop prevention, distinguishing a message from a prior instance of the same message. In DULL this field is irrelevant but must still be set according to the GRASP specification. The initiator address MUST be the IPv6 link local address of the originating Proxy node on the sending interface. The method parameter is a string indicating the Proxy method at the specified locator. It only needs to distinguish methods distinguishable by the Pledge: TCP circuit proxy and IPIP (stateless) proxy are indistinguishable to the proxy, so the above example "https" method announcement could come from either a TCP circuit proxy or IPIP proxy. CoAP on the other hand would require a different transport protocol stack also on the Pledge and therefore require a different method. ----------------------------------------------------------------------------- Section 4.2) 1) a) Append: Therefore the "coap" method in the previous section was only used for the example but is not included in the CDDL definition of the GRASP objective above. ----------------------------------------------------------------------------- Section 4.3) 1) a) I would suggest removing this section and putting the requirement into 4.1 together with the rest of the requirments. Wherever the requirements are written into, it must include this sentence for ANI. ANI Proxies MUST support a TLS circuit proxy to support the "https" method, they MAY also support the IPIP proxy method to support the https method. For non-ANI i suggest the following (or we don't even mention them and leave it up to followup work to define non-ANI profiles): Non ANI Proxies are free to choose their proxy option as long as that guarantees interopeability with Pledges and Registrars in their target deployments. ----------------------------------------------------------------------------- Section 4.3) 1) a) Suggest to move the first paragraph with requirements to section 4.1 b) Requirements must include: ANI Registrars MUST announce their Registrar service via the ACP instance of GRASP. They MUST support ANI TLS circuit Proxy and therefore BRSKI across HTTPS/TLS native across the ACP. ANI Registrars MAY support the IPIP proxy method by implementing IPIP tunneling for their HTTPS/TLS traffic across the ACP. ANI Proxies MUST support GRASP discovery of Registrars . c) The following is fixed up text for the remainder of 4.3 to solve the following issues: - change of GRASP objective-name (SRV.brski-registrar) and methods ("https", "https-ipip" as well as coap for examples sake). - changed address of registrar to be an actual ACP address - GRASP example was cut off/incomplete - also modified example to show both methods (circuit, ipip) - Fixed text to not refer to EST server but Registrars. - Fixed text to give timing recommendations only for ANI. - See discussion after following proposed text for the open issues. The registrar announces itself using GRASP M_FLOOD messages. The M_FLOOD is formatted as follows: Example: [M_FLOOD, 12340815, h'fd89b714f3db00000200000064000001, 180000, [ ["SRV.brski-registrar", 4, 255, "https" ], [O_IPv6_LOCATOR, h'fd89b714f3db00000200000064000001, TCP, 15000] ] , [ ["SRV.brski-registrar", 4, 255, "ipip" ], [O_IPv6_LOCATOR, h'fe80::1234, 41, 0] ] , [ ["SRV.brski-registrar", 4, 255, "coap" ], [O_IPv6_LOCATOR, h'fd89b714f3db00000200000064000001, UDP, 13000] ] ] The formal CDDL definition is: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] objective = ["SRV.brski-proxy", objective-flags, loop-count, objective-value] objective-flags = sync-only ; as in the GRASP specification sync-only = 4 ; M_FLOOD only requires synchronization loop-count = 1 ; limit to link-local operation transport-proto /= 41 objective-value = method method = "https" / "ipip" ; or future methods ; CoAP not considered yet The M_FLOOD message MUST be sent periodically. The period is subject to network administrator policy (for example configuration on Registrars). It must be so low that the aggregate amount of periodic M_FLOODs from Registrars is negligible for the network. for ANI Registrars, the recommended defaults are to send messages periodically every 60 seconds and use a TTL of 180000 milliseconds (as in the example). The example shows the type of locators used for each of the discussed methods. For IPIP, the port is always 0, and the IPv6 address of its locator option is not the address used by the registrar but instead the virtual link-local address that IPIP Proxies need to use on their network to receive/send packets from/to Pledges when performing IPIP proxying. The Registrar supports IPIP tunneling for the other methods indicated in the same M_FLOOD. In the example above, the registrar support IPIP for both https and coap. Proxies MUST constrain IPIP tunneled traffic to the protocols and port numbers announced by the Registrar (TCP port 15000 and UDP port 13000 in the above example). Discussion: I would strongly advise to move IPIP out of this document and write it into a separate follow-on standards track rfc. That should be easily adoptable as a WG document within the current charter, but it requires some significant additional work that IMHO could further delay current BRSKI draft: a) The above "transport-proto /= 41" is technically an update to GRASP RFC which allows only UDP / TCP. There is some process around updating another RFC. We could avoid this by just putting "UDP" in there and decribe that "ipip" always means 41 even if the locator says UDP. That would be just like DNS-SD only having _udp for any non-tcp protocol. But thats a longer discussion. b) The use of the virtual link-local address in the locator-option is also not in-line with GRASP AFAIK , so i fear that too would require a GRASP update. We could avoid this by not using the locator-option (which is specified by GRASP) by IPIP, but by putting the info into the objective-value, e.g.: [ ["SRV.brski-registrar", 4, 255, [ "ipip", h'fe80::1234, [ h'fd89b714f3db00000200000064000100, 265] ] ] , This would tell proxies that they can build IPIP tunnels using locally just a single ACP address, but remotely on the registrar they hae 265 addresses available, so they use a different one for every local inerface they have. h'fd89b714f3db00000200000064000100 ... h'fd89b714f3db000002000000640001ff c) I am not sure how we solve the problem of multiple IPIP Proxies on a single LAN fighting to own h'fe80::1234. It seems to me we would have to figure out if/how those proxies could use VRRP to decide which one should be active. (assuming VRRP has the same virtual address mechanisms as HSRP, i've never looked into it in detail. And it would need to support link-local addresses). d) Appendix C discusses some additional GRASP signaling that seems to be mandatory?/desirable? to tell the Registrar upfront which tunnels it should build up. But that GRASP signaling is not specified: "The Join Proxy SHOULD do a GRASP M_NEG_SYN for each interface which they wish to relay traffic, as this allows the Registrar to do any static tunnel configuration that may be required" Please insert implementable GRASP objective specifications for this step here... Let me know how BRSKI authors feel about proceeding on IPIP. If they want to keep it in the current BRSKI spec, i am happy to help, but i have not completely tried to analyze appendix C, so i am not sure if/what other issues than the ones above there might be. ----------------------------------------------------------------------------- Section 5) a) Suggest changing the title to "Protocol Details (Pledge - Registrar - MASA / CA)" to distinguish from Section 4. Might consider also to move up section 5.8 as a new section 6 so that you have a clearer separation between the core of BRSKI (this section 5), and the (optional) EST integration (then of course the titles would be (Plege - Registrar - MASA) for section 5 and (Pledge - Registrar - CA) for new section 6. b) MASA URI is "https:// authority "./well-known/est". ^ missing a " ? MASA URI is "https://" authority "./well-known/est". c) BRSKI-EST connections SHOULD use persistent connections The intention of this guidance is to ensure the provisional TLS authentication occurs only once and is properly managed. This is not clear to me, please rephrase. - What does "properly managed" mean ? - Why would provisional TLS authentication have to occur more than once without persistent connection ? The first connection only retrieves the voucher, but then lets say the Pledge closes the connection and builds a new one for EST enrollment. On that second one it would not need to do provisional authentication. /cacerts after /requestvoucher ? - Btw: 5.8 says "As noted above, use of HTTP 1.1 persistent connections simplifies the Pledge state machine" and only this section 5 mentions persistent connections, but it doesn't mention siplification of pledge state machinery. Is that what section 5. should say instead of "properly managed" ? Not sure though how the state machinery actually does get simplified either. d) Q: How would BRSKI work in the absence of persistent connections or in the presence of failures ? I guess each request from the pledge is a standalone transaction and the pledge would just repeat them until it succeeds or until a return code would indicate that the Registrar does not support this step and the pledge has to terminate. Is this something that each reader is assumed to understand because the magical term "BRSKI REST" is used but not explained ? "Ah, rest, stateless transactions... etc." or should BRSKI readers deserve a written explanation ? Aka: The way i see it, the reason for persistent connections is really just avoiding unnecessary repeated (expensive) TLS connection setup... e) "If the Registrar responds with a redirection to other web origins" A reason for this rule should be written into that paragraph. ... This is to minimize attacks by fake registrars trying to indefinitely redirect a pledge. f) "It should proceed to other discovered Registrars if there are any" Pledes don't discover Registrars, the discover Proxies. the Proxy can see a couple redundant Registrars. Possible solution: - "proceed to other discovered Proxy locators (that are being mapped to different Registrars, see XXXX), if there are more" - And then in an appropriate XXX subsection of section 4: To allow Pledges to avoid stalling on a faulty Registrar (see section 5), proxies MAY announce via GRASP for multiple discovered Registrars the SRV.brski-proxy objective, each with a locator option using a different port and mapping Pledge connection requests for each such port to a different discovered Registar. Pledges MUST treat multiple SRV.brski-proxy announcements from the same proxy address accordingly as representing different Registrars (see section 5). f.1) "If necessary the Pledge calls the EST defined /cacerts method to obtain the domain owners' CA certificate." Please add an explanation when/why this is necessary. This seems to contradict the statement in 5.8.1 about not doing /cacerts,/fullcmc during Bootstrap but only during enrollment: "Although these limitations are acceptable during initial bootstrapping" (aka: "no need for /cacerts during bootstrap"). g) After "This moves the BRSKI-EST TLS connection out of the provisional state." add: - Afterwards the Pledge trusts this and other Registrars using the same trust anchor. It MAY permit more than one redirects, but it MAY still time out the registrar for further REST operations and revert to another one. - Mandatory boostrap steps conclude with Voucher Status Telementry (see XXX) - Move "Optionally, the BRSKI- EST TLS connection can now be used for EST enrollment." out of the bullet list merge wi next sentence ("The extensions..."). h) "In the language of RFC6125 this provides for a SERIALNUM-ID category of identifier.." RFC6125 does not use the term SERIALNUM-ID and BRSKI does not use this term outside of this paragraph either, so it seems redundant. The whole paragraph is also quite dense, so maybe rewrite/simplify the language. Would suggest to also move any details o the whitelist logic desccription to 5.1, 5.0 is just overview. And in 5.1 you mention TLS setup uses RFC7030 mechanisms while in 5.0 it refers to RFC6125, so i think it would become easier to write & read if tht 5.0 whitelisting stuff was moved into 5.1 paragraphs refering to EST TLS setup. ----------------------------------------------------------------------------- Section 5.1) 1) Suggested append if you agree with it (whatever wording you like): A Registrar could recognize from the IDevID presented by the Pledge that it is not interested in it, but it SHOULD not immediately close the connection to the pledge after connection setup but instead wait for the Voucher Request, provide an appropriate error reply to it and then close the BRSKI connection. This allows for better error diagnostics on the Pledge (that could be presented via local interfaces and/or captured in logs). Connection close during TLS setup on the other hand can have various third-party causes (firewall etc. pp.). The approach also allows Registrars to distinguish between actual Pledge connection attempts and other connection attempts which is especially useful when the Registrar also acts as an EST Server. Pled ----------------------------------------------------------------------------- Section 5.2 1) a) "nonce: The Pledge voucher-request MUST contain" ... ..."Doing so ensures Section 2.5 functionality" If one just follows the reference to section 2.5, it looks contradictory: "_If_ the voucher contains a nonce then the Pledge MUST confirm " Please clarify, this is confusing: - If the nonce is a MUST because of section 2.5, then the MUST would only have to apply to RTCless Pledges. But its not clear to me why... (forgot our discussions, and readers where never part of them, so explanation would be nice). - If the nonce MUST is in your opinion valid with/without RTC, don't refer to 2.5, but provide explanation accordingly why MUST. - Add "See section 6.2 for reduced security Pledge options". - fix to "MUST NOT be reused for _MULTIPLE_ bootstrapping attempts IMHO also: (especially not across repeated first bootstrap attempts after power cycling). ----------------------------------------------------------------------------- Section 5.3 1) a) "The Registrar initiates the connection and uses the MASA URL obtained as described in Section 2.7 for RFC6125 authentication of the MASA server." Q: Does this mean: "The Registrar initiates the connection and uses the DNS name of the MASA URL obtained as described in Section 2.7 for (RFC6125) authentication of the MASA server certificate." Aka: for the less PKIX/Websecurity initiated readers like me, writing out what is actually implied could make the sentence easier to parse (instead of having to read more of RFC6125. ----------------------------------------------------------------------------- Section 5.4 a) See comment for section 5.4.4 for where i think the first paragraph description should be. (aka: make this paragrap a summary of what the MASA interface is, mentioning both requestvoucher and requestauditlog and move to 2.4.4). b) The paragraph is difficult to parse and has IMHO wrong pieces. - What does "simplicity" mean ? - "the Registrar is not required to make use of any other EST functionality when communicating with the MASA service"... what does that mean.. ? Not required = but could optionally do it ? - "is defined as an optional EST message" - requestvoucher is NOT optional for MASA, and i don't think its in-profile for other roles supported by EST (Registrar, CA,...). Eg: i would suggest the following for the first paragraph: e.g.: The MASA uses EST (RFC7030) REST calls with the EST prefix "/.well-known/est/" to allow reuse of existing EST server code to implement a MASA service. The MASA service requirs only two new operations: requestvoucher and requestauditlog. If a shared code basis is used for MASA and other EST/BRSKI defined service roles (Domain Registrar, CA,...), the MASA service MUST properly reject any EST functionality requests it does not wish to service; a requirement that holds for any REST interface. "To allow the reuse of existing EST server code basis for MASA functionality," If you where thinking of other types of "simplicity", please refer to the most important one because without any explanation, simplicity is hollow. c) If you agree to above and moved first paragraph out to 2.4.4, just reword second paragraph to something like: Domain Registrars requests vouchers from a MASA with an HTTP POST ... d) An example (in parenthesis is fine) for a "future media type" would be useful to justify to readers more easily the paragraph mentioning a SHOULD against them. e) "request a Voucher when the Pledge is offline" -> "request a Voucher when the Pledge is unable to connect to the Registar" ?? (i hope thats whats meant with "offline"). "when the Registrar is expected to be offline" -> "when the Registrar is expected to be unable to connect to a MASA" Offline can be confusing because it does not explain who is not able to talk with whom, and i think in both cases two of the three are still expected to talk with each other (or at least that part does not matter). I am still confused about the "Pledge is unable to connect to the Registrar" case. Is this a case where BRSKI-EST does not happen but something else (e.g.: sneakernet) between Registrar and Plege ? Please add a sentence explaining what this case means. f) "since the registrar is not known to the MASA server in advance" Given how the HTTPS connection requires authentication, there is some knowledge about the registrar from that, so the above sentence is confusing. Whats the correct statement to be made here thats takes the existance of the HTTPS authentication of the Registrar to the MASA into account ? g) Registrar revocation consistency: Maybe change the lead in in this section to something like: "If the Registrar uses a CA known to the MASA to make certificate revocation information available to the MASA, MASA SHOULD check ... of the Registrar Certificate. MASA MAY limit service to Registrar where this applies to provide owners protection against impacted registrar (e.g.: stolen). In any case a short reasoning why to do this step would be helpfull. h) Pledge proximity assertion: Sentence summarizing one most important attack vector reducet by this. Or pointer to reference where this is explained. ----------------------------------------------------------------------------- Section 5.5 a) "immediately complete authentication of the provisional" This sounds contradictory to the potential need to perform /cacerts first as described in section 5. Add something like (potentially after performing /cacerts, see section 5.) ? ----------------------------------------------------------------------------- Section 5.5.1 a) "which is an additional justification for the recommendation to proceed with EST key management operations. Once a full CA Certificate Response is obtained it is more authoritative for the domain than the limited 'pinned-domain-cert' response." This sounds contradicting to the statement in section 5., where it sounds as if provisional state is completes only after the (optional /cacerts) and cacerts is part of bootstrap, whereas here it sounds as if its part of enrollment only. b) If /cacerts is not required for finish provisional state or voucher telementry, maybe the Pledge would ask for cacerts after voucher telemetry, and then a REgistrar that does not want to be a full EST (enrolment) servdr, would reply with a redirect to an actual enrolment server in the same domain. That would eliminate the "discovery" part discussed in the last paragraph of this section. Still confused why/where cacerts needs to happen and why exactly there in the flow... ----------------------------------------------------------------------------- Section 5.6) a) "The domain is expected to provide indications to the system administrators concerning device lifecycle status. To facilitate this it needs telemetry information concerning the device's status." Nice language. Whats missing is the IMHO quite relevant recommendation to go beyond that and provide diagnostics / suggestions that could go as much as "actionable recommendations in support of expedient resolution of the failure". Aka: (Failure) Reason: "voucher certificate not valid yet". Suggestion: "Replace empty RTC battery " Can we add something like Suggestion to the structure ? Not sure if "suggestion" is the best word, but it would be great if we can put a stake in the ground adding this to the structure. I have seen too many times where it took eternities to find the magic offline manual mapping from a range of crazy error codes (reasons) to the suggestions what to do next. b) Recommendations for how to mitigate the potential security issues of diagnostics would be great: - Reasons could be per-device encoded, requiring vendor for further insight: Reason: "error 23498y354AZRFF" Suggestion: "call manufacturer" - Operations after errors can be slowed down to reduce/eliminate brute force attacks c) "message is being sent" -> "message may be sent" (above example of non-attack issue). ----------------------------------------------------------------------------- Section 5.7) a) Paragraph 1: Did we not discuss the option that the Registrar might want to examine the authorization log before even forwarding the voucher to the Pledge ? I do not remember what the outcome is but it would be good to mention why or why not this should be an option. o b) It is recommended put to put some ^^^^^^^^^^ And not even clear what it would mean if the sentence was fixed. Does it mean something like: Cacheable object name could be large randomn number ? ----------------------------------------------------------------------------- Section 5.7) a) The current described examples of the Audit Log are all somewhat scary, a bit like "The doctor told me something bad... should i ignore it". Or worse: This audit log stuff is made up by Vendors to scare us into buying only manufacturer refurbished gear with a clean history bill. Can we mention some simple positive examples o better sell the value of the audit log, E.g.: Audit logs can not only help to identify candidate security risks, but Audit Logs can also help to identify mislocated devices, for example in office parks connected to the wrong network connector. Audit logs can help tracking history of devices re-deployed in large companies - which department originally bought this equipment,. The biggest concern i think we will see from privacy advocats is that vouchers/audit-logs are a big-brother initiative from vendors. This too might be something to document counter arguments for: The amount of traceability of audit-log information is highly flexible. The PKI for pinned-domain-certs used to identify owners do not have to be public, and if the authentication of Registrars with MASA is set up to be non-traceable (or the MASA is operated by a trusted third party providing privacy protection of authentication data), audit-logs can provide similar privacy options to block-chains - you can only identify another party (in the audit-log) if you can trace the pinned-domain-cert to an owner. ----------------------------------------------------------------------------- Section 5.8) a) "The Pledge is also RECOMMENDED to implement the following EST automation extensions" add: An ANI Pledge MUST implement them. b) Last paragraph: It looks as if this is in answer of my question about enrolling multiple certificates. Thanks! - Please put at the end of 5.8 (eg: new subsection before CoAP - "enrolling multiple certificates). No need to derail the core track what BRSKI does with consideratations of what it can not do. - The text reads as if its a fault of BRSKI/CSR-attributes that its impossible to get multiple certificates and reads in a way as if "RFC7030 alone without BRSKI wouldn't be a problem". Maybe i am overinterpreting. - How about adding a sentence like: Enrolling with additional trust-anchor/certificate pairs for additional services/roles for which the primary TA/certificate are not useable is subject to future specifications. It could for example simply be achieved by performing EST operations for an additional via URIS of the form /.well-known/est//{cacerts,csrattrs,simpleenroll,...} Unless i misunderstood the "arbitrarylabel" examples in RFC7030. ----------------------------------------------------------------------------- Section 5.8.2) a) The wording of the first paragraph makes it somewhat hard to understand what point it is trying to make: | In some deployments its plausible that the Pledge generates a certificate | request containing only identity information known to the Pledge (essentially | the X.509 IDevID information) specific identity information "in other deployments the pledge magically generates a certificate request including information not known to the pledge" ??? First two paragraphs text is somewhat confusing and incomplete. Suggest to reword with the following bullet items as goals to describe: - BRSKI Cert model: - no BRSKI specific CA requirements - Any CA, Registrar<->CA protocol support. - Registrar is policy decision point for what should be in the certificate: - operation model: Registrar in responsibility of department running service and know what needs to be in cert, CA more often simple "security department" - Example service attribute: ACP information field for ANI Pledges. - IDevID attributes specific service case: - Want to have them in LDevID to avoid weakening-of/attacks-against LDevID keying material (can not be renewed on IDevID but can be renewed in LDevID). - For uniformity and better control, Registrar also determines which IDevID attributes are put how into LDevID. ----------------------------------------------------------------------------- Section 5.8.4) a) "The EST protocol assumes an end user" -> "RFC7030 assumes an end user" b) There seems to be text missing after second paragraph (before discussing success/failure): -If the /simpleenroll or other RFC7030 4.2 enrolment fails due to problems locally to the Pledge (and therefore not known without telemetry by the Registrar), the Pledge logs an app FAILURE via enrollment status telemetry. -If enrollment succeeded and once the pledge has managed to re-establish the TLS connection with its LDevID, it logs an /enrollstatus SUCCESS. - If enrollment succeeded, but re-establishment of the TLS connection fails, the Pledge reverts to re-establish a TLS connection with its IDevID and logs an appropriate FAILURE enrollment status telemetry. It then attempts to re-enroll a new certificate with exponentially increasing delay to allow operations to overcome any possible problems in the CA/Registrar setup that could have caused the problem. Or similar if i didn't get it right. c) " This allows for clients that wish to minimize their crypto operations to simply POST this response without renegotiating the TLS session - at the cost of the server not being able to accurately verify that enrollment was truly successful." Bullocks. First you scare off readers with "diagnostics bad" (5.6), and now Pleges SHOULD just do good diagnostics (try new LDevID to see it works) ? Please make the SHOULD re-negotiate a MUST and delete this last paragraph. If a plege can not afford a single validation of a BRSKI certificate, its not worth receiving one. ----------------------------------------------------------------------------- Section 6) a) Suggest Change title to eg: "Additional security options" - Some text (eg. first paragraph mentioning NEA) talks also about additional/higher security, so lower is not necessarily always true. b) Need to be more specific about how text in this section relates to BRSKI compliance: It seems as if the intent of this section targets to be part of the BRSKI standards specification as well and any implementations that match the MUST/SHOULD in this section are still compliant with BRSKI. I hope i understand this correctly. I think this should be written out explicity. E.g.: This section is part of BRSKIs standard specification. Implementations following the MUST/SHOULD in this section will still be compliant with BRSKI. All lowered security options in this section are explicit manufacturer choices and operators MUST be made well aware of of these choices reduced security achievable under those choices through appropriate documentation/labelling (e.g.: "Device with/without IDevID"). ----------------------------------------------------------------------------- Section 6.2) a) fix to "not involved in security considerations in this chapter" Remember text in earlier sections where you claimed that yu do expect fewer attacks after completion of TLS/provisional and how having trusted Plege/Registar-Pledge path achieves this. ----------------------------------------------------------------------------- Section 6.3) a) MASA server -> MASA service (i may have said that in before, but you can ignore me on these stylistics. You'll just get them later from RFC editor, pretty good spotting inconsistent terminology. proxy involved in security cond b) "Trust on first Use" for physical ports: suggest to modify to: "trust on first use" for methods with a strong dependency on physcial posession, such as taking ownership via configuration on a serial console. ----------------------------------------------------------------------------- Section 7) a) This document is extending the .well-known "est" definition. We need to determine how to correctly handle this and have started to inquire. I suggest to add the following text to the IANA section for this: | This document extends the definitions of "est" (so far defined via RFC7030) in | the "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" registry | as follows: | | - add /.well-known/est/requestvoucher (see section 5.4) | - add /.well-known/est/requestauditlog (see section 5.7) We can then let the IETF review, IANA review etc. decide whether / how this will ultimately be handled, e.g.: having to add "updates RFC7030" to the document and/or adding BRSKI RFC to the registry. b) It would be good to create subsections for each registray mentioned so that one can see from the table of content what registries are impacted. c) Probably need a summary of updates this document makes to RFC7030, the easiest way would IMHO be to create a short section "Updates to RFC7030", saying that all REST services introduced in this document are extensions ot RFC7030 ESTE because they use the EST well-known prefix, and then point to section 2.4 which with the text i proposed provides IMHO a good summary of those services as used by each role (Pledge, Registrar, MASA). RFC 7030 has these nice tables with service URIs and properties. Some of those would be nice for BRSKI extension/used-RFC7030, but lots of work... d) Add section to request brksi-proxy and brski-registrar to IANA service name registry. ----------------------------------------------------------------------------- Section 8) a) First paragraph: Unvailable MASA is not a security but an operational consideration. Feel free to add "Operational considerations" section before security considerations and move it there. Might want to add some more considerations around MASA to set context: Suggest something like: - Operationally main novelty of BRSKI is dependency against vendor/cloud operated security service (MASA). Main point of discussion in this section. - Operationally, BRSKI is most easily a fit for solutions in which other part of operations are already in the cloud so that the main operational issues of cloud connectivity for MASA is not novel. For example, SD-WAN equipment, services or in general solutions where already part of a (SDN-) OAM management plane are moved into the cloud (management products as a service, cloud-only managed service equipment, ...). - Even if active OAM/SDN/Management elements of a network are still "on-premises", dependency against cloud/Internet reachability exists more and more on the user/ application side. In this respect too, BRSKI/MASA does not increase the need for cloud/Internet reachability beyond pre-existing requirements in many networks (most Enterprises, Service Providers). - There are nevertheless many evolving areas / industries (such as IoT, industrial OT networks) where cloud dependency is more novel and variations of MASA options as defined in this document (or through future add-on work) need to be explored to match the operational requirements AND provide the required level of security. - A variety of those deployments can be handled through a variety of the Section 7 decscribed altered/reduced security option. [ insert existing paragraph here ] - Not described but an example of modified operational model: Very large customers that already often receive often customer specialized equipment like defense networks/solution may hav unique "offline" requirements. These might simply partner with manufacturers to the extend of being able to run MASA services themselves for the vendor equipment they use or receive custom equipment versions with IDevID using a (potentially secondary) trust anchor of the customer so that registrar co-located MASA can create vouchers. b) Possible lead in to security session: - With the focus of BRSKI on strong security, the main considerations in this section are attack attempts against this security infrastructure, above described (section 7) reduced security options and implementation risks. c) "The MASA authorization log..." Not security consideration either IMHO. Suggest to move into a new "Privacy considerations" section. Cut into two or more paragraps (too long now). Also Point to the text i suggested above for section 5.7. Add note that privacy considertins can equally be mitigated through options mentioned in operational consideration section (what i suggested to add with eg: defense customer example). ----------------------------------------------------------------------------- Appendix A) a) Would change title to non-IPv6 or non-ANI operations: b) Initial explanation: Specification of BRSKI in Section 4. only covered the mechanisms for an IP6 Pledge (link-local IPv6 address) and Proxy options necessary for IPv6 and ANI. It does not cover the options for non-IPv6 Pledge or non-ANI Proxies (IPv4 or IPv6). ----------------------------------------------------------------------------- Appendix A.2) a) Replace with: A.2. Use of DHCP A non-ANI Plege MAY obtain a (non-link-local-scope) IP address via DHCP [RFC2131] IPv4 and/or DHCPv6 [RFC3315] instead of or after proxy discovery via link-local address(es). DHCP needs to be set up to not only provide an IP address, but for DNS information (DNS server, DNS prefix) to make unicast DNS-SD lookups as described in following section B. ----------------------------------------------------------------------------- Appendix B) a) Use suggested service name of "_brski-proxy" in all caes where "_bootstrapks" is used. (see comment for section 4.1.1 for why that name is better). b) After "The Pledge MAY perform DNS-based Service Discovery", new paragraph: A non-ANI Proxy MAY perform DNS-based Service Discovery using unicast DNS to discover Registrars searching for searching for the service "_brski-registrar._tcp.local.". c) "To prevent unaccceptable levels of network traffic" -> add ", when using mDNS" d) "received a useable IPv4 address via DHCPv4 as suggested in Appendix A" -> "received a useable IP address via DHCP/DHCPv6 as suggested in Appendix A.2" e) "If no local bootstrapks service": Add at end of paragraph: See Section 2.6 (Cloud Registrar). ----------------------------------------------------------------------------- Appendix C) a) See discussion for section 4.3 above for the issues i see with current IPIP specification and suggestion to maybe move out of BRSKI to resolve with more time. ----------------------------------------------------------------------------- Appendix E) a) Please add a sentence how to decode Hex Certs (not keys) with utility at the very top of the appendix (right now its further down in the text). b) E.1.4: which element in the cert would become the serial-number ? c) There are no ASN1 decodings of the artefacts, Please fix. If this is subject to IANA assignments, please add RFC editor note to block draft progressing. [RFC-Editor: There is text missing here that can only be inserted after finishing mandator IANA assignment. Do not publish version of this draft before this is resolved.] ----------------------------------------------------------------------------- X) Applicability outside ANIMA If i am not mistaken, BRSKI-MASA should be one option how a bootstrap server in "draft-ietf-netconf-zerotouch" could obtain a voucher from a MASA (if i understand it correctly, the mean by which such a bootstrap server obtains a voucher is left open). If that is correct, then it would be great to mention this in a sentence or two in an appropriate section of BRSKI as a very explicit example how BRSKI can be reused outside the complete ANIMA scope (also add draft-ietf-netconf-zerotouch as an informational reference). From nobody Wed Feb 14 02:27:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A8B12AF83; Wed, 14 Feb 2018 02:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0p68nj3rsksH; Wed, 14 Feb 2018 02:27:50 -0800 (PST) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 749B8128954; Wed, 14 Feb 2018 02:27:50 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:200]) by smtp-cloud7.xs4all.net with ESMTPA id luHzey9293A62luHze4tbu; Wed, 14 Feb 2018 11:27:48 +0100 Received: from AMontpellier-654-1-197-156.w90-0.abo.wanadoo.fr ([90.0.224.156]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 14 Feb 2018 11:27:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Feb 2018 11:27:47 +0100 From: peter van der Stok To: Toerless Eckert Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfAsHWAmKXPFPjncVGlEx5ZEV6DJYxj/o7lbWm8Ddf7G/W2qSyvLV7wWhKPXngWe8URH8UpjZUd5HMcZlRwxWlcEgBnAL+Ir+daIYSbdyEjynhgDqndYd b9iEwxsre71pruQX6WUroPu3VjbEEzXErc3XcAm8MMyjc+nM3tXQcefpBLDchvsZCMdr/HfjDzeHUG4x8nJaeD2GPhve5RqCCGK2ICtpQ9O5NovjCNYsxaJ9 zyXKLkndpjGgyqV8uJCVtw== Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 10:27:53 -0000 Hi Toerless, thanks for this reminder about terminology in keyinfra. I have made several attempts at explaining the authors the possible misunderstandings on terminology. Let's hope your input helps. I will look at your other comments later this week. Peter > > b) Key infrastructure > > There is no definition/reference for this term. Please describe on > first use and in terminology. Is there a difference > between "key infrastructure" and "keying material" ? If not, then > maybe remove one term otherwise pls. describe difference. > > c) (terminology) MASA definition: "A third-party Manufacturer...". Why > "third-party" ? > who are the first two parties ? If this is only slang and we can't > explain who the > first two parties are, delete "third-party" ? > > d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because > the text mostly > uses "Domain Registrar" and very seldom "Join Registar". > > JRC is used in exactly three places in the draft. I also can not find > on www.google.com > or wikipedia any example of "The term JRC is used in common with other > bootstrap > mechanisms" as the Terminology claims. Either provide a non-anima > reference for the > use of that term or eliminate it in the document. > > Suggest to use "(Domain Join) Registar (and Coordinator) in 1.2 and > say for example > that the text uses "Join Registrar" when referring to the mechanics of > building the > connection (Join Proxy and Join Registrar) and Domain Registrar when > discussing > authentication and any other aspects of the registrar (where the > domain is relevant). > > e) Voucher > - misses ":" after term. > - please change "statement" to "artifact" so the terminology aligns > with both voucher > draft and voucher-request text which also uses artifact. See also > section 2.2 > where you use "cryptographically protected" instead of "signed" > and figure out > which term you want to use in all cases (hint: signed). > > f) IMPORTANT: Please add/define the term "ANI" > > ANI - "Autonomic Network Infrastructure". Systems that support both > BRSKI and > Autonomic Control plane - ACP > ([I-D.ietf-anima-autonomic-control-plane]). ANI > systems (pledges, proxies, registrar) have specific requirements > detailled in > the document. > > Without this term we can not nail down the explicit requirements > against > ANI Pledges, Proxies, Registrars that we need from the document (and > distinguish > from requirements against any non-ANI adaptation of BRSKI). I added > according > comments into other parts of the doc. > > g) Please replace "MASA server" with "MASA service" everywhere. > From nobody Wed Feb 14 02:30:56 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB3712DA11 for ; Wed, 14 Feb 2018 02:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy3YZic6C3Re for ; Wed, 14 Feb 2018 02:30:52 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A4712D875 for ; Wed, 14 Feb 2018 02:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33624; q=dns/txt; s=iport; t=1518604251; x=1519813851; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=zwSQ34FNDA0RqJT/ndKAe6N+Rb2zd5uhvT6uHMpTKbo=; b=DQe0Kv9qaUpWRip4+LnaHKDJnZmFLZsN7eLY6IhpNkpe4g6ZOpIVL/QS yKTYLuEiD0ZSdHLRc9Nuh0WAu08ip7Vo3hyYJ63r9Te63nTigbaOtLjdo 6F0nVEIPKd3BD/AwZXMha6ykqbYbggZLcYduEWk+FvR6fKUsc9JTIXc1g Q=; X-Files: dilcnfnlpagpappp.png : 18023 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6BwD4DoRa/xbLJq1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEOHAog2WLGI8PgReBbo55hVuCGAcBAhgBDCQ2gQKDOgKDRhY?= =?us-ascii?q?BAgEBAQEBAQJrKIUkAQEEAQEDHksJEgsYBQEBASICAgIVAQ4BMAYBDAUBAgEBA?= =?us-ascii?q?oovELANgicmhFuDfoITAQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+FAYNsgWgpgwW?= =?us-ascii?q?DLwEBAgEBF4EsA4M+gmUFiwmHRZBFgRwJhxoBgQWNZYIfZ4VDg3OICY4CgX6IG?= =?us-ascii?q?YE8JgsngVAzGggbFRkkgkYJgwGBbkA3AYsYgk0BAQE?= X-IronPort-AV: E=Sophos;i="5.46,511,1511827200"; d="png'150?scan'150,208,217,150";a="2063602" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 10:30:47 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1EAUlU4010409; Wed, 14 Feb 2018 10:30:47 GMT To: Michael Richardson , anima References: <151853912961.14349.6366358483962775318.idtracker@ietfa.amsl.com> <19040.1518557815@obiwan.sandelman.ca> From: Benoit Claise Message-ID: <59f7ea78-fe56-abb3-d141-adf70ee21364@cisco.com> Date: Wed, 14 Feb 2018 11:30:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <19040.1518557815@obiwan.sandelman.ca> Content-Type: multipart/alternative; boundary="------------DDABBB70A11AC1EA393301D6" Content-Language: en-US Archived-At: Subject: Re: [Anima] New Version Notification for draft-ietf-anima-bootstrapping-keyinfra-10.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 10:30:54 -0000 This is a multi-part message in MIME format. --------------DDABBB70A11AC1EA393301D6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Michael, The tooling can't extract the YANG modules. This issue comes from: You should remove "yang/" Also, complete the CODE BEGINS here under: module ietf-mud-brski-masa { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"; prefix ietf-mud-brski-masa; import ietf-mud { prefix ietf-mud; } import ietf-inet-types { prefix inet; } Regards, Benoit > WG chairs, after our design team meeting this morning, Max and I believe that > -10 is ready for WGLC. > > (Perhaps we could even complete that before IETF101 and make our outgoing AD happy...) > > We see the language review from William Atwood, and we'll incorporate that > into the document along with any other LC comments. I'm sure that the IESG > review will involve two more revisions, but I think we are ready for that > step. > > internet-drafts@ietf.org wrote: > > A new version of I-D, draft-ietf-anima-bootstrapping-keyinfra-10.txt > > has been successfully submitted by Michael Richardson and posted to the > > IETF repository. > > > Name: draft-ietf-anima-bootstrapping-keyinfra > > Revision: 10 > > Title: Bootstrapping Remote Secure Key Infrastructures (BRSKI) > > Document date: 2018-02-13 > > Group: anima > > Pages: 82 > > URL: https://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-10.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-10 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-10 > > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-10 > > > Abstract: > > This document specifies automated bootstrapping of a remote secure > > key infrastructure (BRSKI) using vendor installed X.509 certificate, > > in combination with a vendor's authorizing service, both online and > > offline. Bootstrapping a new device can occur using a routable > > address and a cloud service, or using only link-local connectivity, > > or on limited/disconnected networks. Support for lower security > > models, including devices with minimal identity, is described for > > legacy reasons but not encouraged. Bootstrapping is complete when > > the cryptographic identity of the new key infrastructure is > > successfully deployed to the device but the established secure > > connection can be used to deploy a locally issued certificate to the > > device as well. > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > The IETF Secretariat > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --------------DDABBB70A11AC1EA393301D6 Content-Type: multipart/related; boundary="------------22A3D0E48733AA6EF94916CB" --------------22A3D0E48733AA6EF94916CB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Michael,

The tooling can't extract the YANG modules.

This issue comes from:


You should remove "yang/"

Also, complete the CODE BEGINS here under:
   <CODE BEGINS>
   module ietf-mud-brski-masa {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa";
     prefix ietf-mud-brski-masa;
     import ietf-mud {
       prefix ietf-mud;
     }
     import ietf-inet-types {
       prefix inet;
     }

Regards, Benoit
WG chairs, after our design team meeting this morning, Max and I believe that
-10 is ready for WGLC.

(Perhaps we could even complete that before IETF101 and make our outgoing AD happy...)

We see the language review from William Atwood, and we'll incorporate that
into the document along with any other LC comments.  I'm sure that the IESG
review will involve two more revisions, but I think we are ready for that
step.

internet-drafts@ietf.org wrote:
    > A new version of I-D, draft-ietf-anima-bootstrapping-keyinfra-10.txt
    > has been successfully submitted by Michael Richardson and posted to the
    > IETF repository.

    > Name:		draft-ietf-anima-bootstrapping-keyinfra
    > Revision:	10
    > Title:		Bootstrapping Remote Secure Key Infrastructures (BRSKI)
    > Document date:	2018-02-13
    > Group:		anima
    > Pages:		82
    > URL:            https://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-10.txt
    > Status:         https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
    > Htmlized:       https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-10
    > Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-10
    > Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-10

    > Abstract:
    > This document specifies automated bootstrapping of a remote secure
    > key infrastructure (BRSKI) using vendor installed X.509 certificate,
    > in combination with a vendor's authorizing service, both online and
    > offline.  Bootstrapping a new device can occur using a routable
    > address and a cloud service, or using only link-local connectivity,
    > or on limited/disconnected networks.  Support for lower security
    > models, including devices with minimal identity, is described for
    > legacy reasons but not encouraged.  Bootstrapping is complete when
    > the cryptographic identity of the new key infrastructure is
    > successfully deployed to the device but the established secure
    > connection can be used to deploy a locally issued certificate to the
    > device as well.




    > Please note that it may take a couple of minutes from the time of submission
    > until the htmlized version and diff are available at tools.ietf.org.

    > The IETF Secretariat


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-






_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

--------------22A3D0E48733AA6EF94916CB Content-Type: image/png; name="dilcnfnlpagpappp.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="dilcnfnlpagpappp.png" iVBORw0KGgoAAAANSUhEUgAABa8AAADTCAIAAAAJR3jaAAAgAElEQVR4nO2dK6/tRrbv/SVC Im2FTMkgOGiTBJs4rDcNaJaAie42Duh8gQCjA2JywfkCARMceoyvdEnDBkfauqilllpaF/g1 xqiHH9NzlqfX76cCa9qud9mrxt81ytmb4AsAAACchTcAAAAACJDJH6mnbQAAALAbqeYWAAAA AMcHNQQAAOCcpJpbAAAAABwf1BAAAIBzkmpuAQAAAHB8UEMAAADOSaq5BQAAAMDxQQ0BAAA4 J6nmFgAAAADHBzUEAADgnKSaWwAAAAAcH9QQAACAc5JqbgEAAABwfFBDAAAAzkmquQUAAADA 8UENAQAAOCep5hYAAAAAxwc1BAAA4JykmlsAAAAAHB/UEAAAgHOSam4BAAAAcHz8akhdZD1F vWLatTHae6cusiy7XG8LLr1dL10DL7scAADeMwumAW2V9/+586pdPnvYGO2905SLW2xsYRoY AADgQbhqyO16mWztulhqd2+MtoVBdOmzGBSC7ueoF1jJYDjRCzWTcjNeJaMWdV3MVaG/Xio/ nkMLq7SqvVZeDgAA75K5OUBTZlnZdH+3VT7+/ZhoGxglgT6LppQ/h1/iAhXLRBLCwiTmZFnZ NOWc4tBf78lkdd3nM7vncgAAAFjOnKfM7XrZss5jY7TlKD3Aze12vRS1c/h2vVwul0mrkBfc ruJEp2osUBzq4nK5TNfdroX8ubE6u18OAADvknUzgo2G96Pt9bbKheTg5taUedXaw22V57nQ aWQiWsBpq3zR+oumzPN8uq6tSvlzOaghAAAAR2FGDdm4yOOxa0PGPDr1Yvxjopc5rBwyaCRD 2cT5jfpCXVyu1zGq/tWXTSw3MUUUi1PG7JXXTB/b1ZW8pZV54aoEAACr1JCNizweuzZkzKOT BMY/BL1cYFSDtsrLRlwu1JA7RJ9qjKp/dUf8C1XUQhSp2yivmT6225Le0sqlLXjSAAAAbCWk hvSm9VqJYGO0bdyul0tReNZi1EqfuMkIRS20mkkNuV2LTUWui8v1NiRTF0UtclS+Q3rxiV6I YvYN8ZY5VEFxmYmFIAIA8N5ZNBEwfiVL2RhtI02ZlWXpZjapHHoJSf+rKbNRRxmvKzfJB02Z V+2QTFOWjRAq2iqXooRUiLRaZPYN0VKHroH3kiERed1YRwAAAFjH664N+fIl5JBTF9LlpfB4 1PTl86ohwY1HfHSyhPTLGYUKj8AynHNPSXljixoiC836EAAA+PLly2nWhry9vQUXSQhpoymV /8u4t0hetX41RC6xmBUUuvyHNSed1NJH8ggswzn3lKzHJjVELkJhfQgAAMAdzH5h96gbhwRz cYUB3z4hdZFdrrVQQ5yEFvnODBfVxSCdJFND0D4AAECzckpw0I1Dwrk4woDcJnXyjMnyqgms IQkmHcy/KYdskqkhaB8AAAC74Kgh7m6iVhTovGE8ixM2RLuTRSLGtFREXV4X2eUy/XZ2H1ml hviOeHct8ZZ70lL6k/LjPAv3DbHl9+ymAgAA74uZKYD2sZBfiunxfzdlY7Q7cUUAVz2YtAd1 rimzPJ9+N9bjZpUa4jtiSyJ+m1OTltKfHH805dJ9Q+zuKb7dVAAAAGAe39qQGV+RkKyxMdo2 zAoQ5+u6nRIgD1y9J4Vi4E1yWRHc3OwBtUbFnrpcr4W8QH79t75efPXzJKrP8tEZAIB3z/ws ILz359tbRNbYGG0bZgWI/bqu3JS0O1CWub64rXJVHLUL6QI/E3G9SDBwwFbdbHlalfICWY2m ysfCmPRsorpJnrN1CwAAwOmY9ZQBAACAlyTV3AIAAADg+KCGAAAAnJNUcwsAAACA44MaAgAA cE5SzS0AAAAAjg9qCAAAwDlJNbcAAAAAOD6oIQAAAOck1dwCAAAA4PighgAAAJyTVHMLAAAA gOODGgIAAHBOUs0tAAAAAI4PaggAAMA5STW3AAAAADg+qCEAAADnJNXcAgAAAOD4oIYAAACc k1RzCwAAAIDjgxoCAABwTlLNLQAAAACOD2oIAADAOUk1twAAAAA4PqghAAAA5yTV3AIAAADg +KCGAAAAnJNUcwsAAACA44MaAgAAcE5SzS0AAAAAjg9qCAAAwDlJNbcAAAAAOD6oIQAAAOck 1dwCAAAA4PighgAAAJyTVHMLAAAAgOODGgIAAHBOUs0tAAAAAI4PaggAAMA5STW3AAAAADg+ qCEAAADnJNXcAgAAAOD4oIYAAACck1RzCwAAAIDjgxoCAABwTlLNLQAAAACOD2oIAADAOUk1 twAAAAA4PqghAAAA5yTV3AIAAADg+KCGAAAAnJNUcwsAAACA44MaoqmL7HK9nTM3AAAJT6Dz k2pu8RI0ZZZX7TlzAwCQ8AQCCHBkNeR2vWRZlmW++XpddKeyot41T9SQxAyd/th2GYfWiB5H 4/Cy5TAR7egLDsvhxM7DdZauvMtyfdQ9pdrs2Q1givDER8nB8I+ExE+gNcMTNpJqbrGepuxv xbKxp9oq707tPJdHDUnN0Olunz8ilxHdD+PwcsqhI9reC47Y59TKpavIslwjt9t9yDZLNN4T PEoOhn8kpH4CNeXpGx5elWeoIZNpKVg+B6+L4LW364WZ9HZGG7FvRG2yy25Trdyf6HtF2Lrj VSLq5Vqv6iS3S53hI4eDK2uogojTl+ttSvt2LeSYMj/rQlVFlic24m7Xy1A08We0bs9gZa57 F9LfFGk4+qPkwYVIWsdQ5odo+FPz9EmFMC0Fi02utsqD1zYlM+k7GGzEvhGHjup+ym5TrTyc 6HtlsnXHq2TUslnXSc7V7vCRw8GRNXRxxemyEWk3pRpT+mdb5bIqqjyRyohLbazxgmerIetz 3b2QTfl0DSjE4R8ljy1EmvE3l/khGh7A4UlrQ6wZEjFLZuMKmEnfjW5Ct63r4nK9OYfr4nK5 CFlCXqBfN9dFturlr7dL1cHb9RIVKMbf+sJOVPGWxFTP/Lxdr7X4ERxxdTEnm7xXNeQw9+jR HyWoIbA/KeYVdiq8Zl5+eBPmtVFN6LZ1W+Vl4xxuqzzP88nKlRe0lTjRaRl3qSHOQfs+28YY f6sLO1HFWxJTPVvbphKRwiPOUVScUfte1ZDD3KOHf5SghgAchSerIcPU11jP7kt9T1wPgZm0 XDAwxnVcMIYD43IB/2L67vjlei38hZwyK+rh2nmhJ7Z0X5W/uOp1C0HUEoqV5u/YOU5p+sb3 qlli2cR0/l7jZl4NsaUZT/aHpzHmcQtYNMDkdbfrRTanWotiRBNdcM+wXd42/UAqioscWJlV gfwlUWOhqJU6ZIe7O/xCHRCodgx3Udii8vfRilrdW72aVRT99XqF0rIyrnuUmCeGk+HCiiux URzSyXsWOYUayxEbs+I6nl40ElSKj3/eRet2u16m8W0T2zbuQJFiXjFOhfupr7WeB3zz4g0m jFwwMMTVCx/Egf6C0IL5wYquSpuiLX7ZRCxut1LRGk/Fr6pykbGgllCssi/Gl/eet/h943vV LL0WYjh/r3Ezr4bY0gwnh8PjGLMN51+x4Q4wdV1TquZUa1GiGopbj+XWaD+QyjKXA8vJMNTf akXMmKvylehju+3hL2Sw2vO1kBgVK9iSw7XjJXnVzDbJfBlXPkq0e5OvD5ZUXIuN4pBO3l3k ZIa890QXq6zG04tGgkrx8c87z+JAkWZT5lXbBHLbNO4A9uBpasg4wu17fDnJta/9+7ir1JC6 sAbIEH34czJwPfl5c6sLMRe3tvLwY4sPvC83x2ZZZgXc6lq24yrToS6yovBIBdK1xKNHTLWf 6uFqEOuYV0PsVgfaG0YcXqYieftAjtdrUMNQ6squashQhl7WmYbrJD+FRrluHzMoo7JSsJBG RVq314S/0pHyi3J7DPHxDu6uV7JqrRL05rpOWDXF8j6efClFIumHj1vBwOKlSAeodFTmsZEw pfWk511kbUgWLv/2cQcDKeYVYj5s3+ObmbE7t15pwrRVbg2QyaVjkGL6TPUyhlCKxiKWmoFM YM0WDbHcHJtlobrQNKodV64HyMvSIxVI1xKPHjF211RmV4NYyawa4nSa9oYRh5c1QWAVxzRe q5C+o1STXdWQLoG+PuMfSnMK3jeeFTHeNTz+MvoKaVQkz10Tr4ffaShwl0418tv2wSZ5a5tG JrjSVSnQFtYta8HNaG4+E2l6lhidLVSIuRSnx9mbK+QFR0I0x0c87yJrQ7JwbneMO4D7SLQ2 pMdjsQZ8NfzJei03zyte7TlRF5eiuHR/ebYV9FoH2voQc3e7o8b9aoh5tbzUADAvYFfaDd6C qO5RDSv6c2hSVw2ZW/QTqsbKpQl2bYiv8BFmnbYinSoL+wA1ZNqZZRzAffzIKHdORQq5TA3x 7fuzfHgFZIZg+SOxZP3HBRv+RWb+Ibd+mZnZQmZBtT0LIQLLKxauy5nrAB1JVDE6EjzXBw7u 9Lxb6Cmjyn/PuIOBFPMKuzZkwLVYA74agXTdubzHGhdrB7LOhs/LcrDm3W0F55YmiPK4FvAO aoh5Ibp4pYV5ubyuIKEVAVKXKT1t0BtcXjVkbtFPqBoB8yxYM7s2xFP4CLMSRWBFiS3sA9SQ aTuXcXXCKOwF7xvnlFmHtV4N8bzaXzO8/JkE79JIrGiTOOXcQQ3Rnb/QGvftZONfseEmtuB5 4KSoKyVSiI6EaI6PeN4t9JTRud0z7gDuI9G+IT3PVUP6F491MWyo6TNv7rIOVruJzO+fsux9 tPsadQc1JLJ9qfKMyYpaqiFBtWIRc2tD3PYIv1Bf5tSwXQyxa1a8/jsLSjpTsvRqyD026JPU EHdFxi5qyJTuwhtxQSffrpfscnEWhoTjxjsgoRqyZkBvUUPQPvYgxbwiNBV+qhrSmzZNmVdt W+Vl43vVe5d1sM7cDeVm6rPIBHNfo96vhrjWiM+qbsrOjWHywFgkMAWZ6wC30wLpL2uDu8QQ lXXUm2dFiZy0D6CG3GODPkkNcdZP7KKGiHSXfn5lfrg3ZZbluW/RV0gNiaWYUA1ZMzI2qSFo H5COtGrIoun1ak8ZzxYX499ZUYy7S2S+V42rrANtg3mWvs/hX0BgdlFY9kLabCZwtxritq3Q ruTlt+vlcpmyd7x09lVD3BzC6bvfg1m2FEilYN0cpPxh93YoxEjzrrXZSw2JjXJHlcl0mZWn w6L1CbZLnS6OsUyXsL9XqyHWa2mntSHDmck3Zx6rn4W2oXFLaR4tY47RDgiqIfGR4L3Gd3Cn 512kbiGB7q5xBwMp5hULp8Kr36gvuFz+bsqsLMedS7zvj1dZB46vxA6eMtb6XqYlKFtwQ0EW iRiTeaUub8osz3UjG6eHPdUQN4dg+m5TOh0+Y3FZRyXH90AbcpOJv9oYd4kuhIjcN451afbW UK/eF3nKOF26ag3UoqZwcl2rhui+9jiheHOZy3A6Y1yTYthhZ71XxpK5pdTqmtzkJZxiUA2J jwTvNb6DOz3v7Cqe8Hj1jlbvb4AH8vQv7Hosrcx72rfifLIFnVNGDPCeUDqBnsuHc5vOFLX4 5VvPHdliIlppVTd7buH8X0YbtkBcVBavf8F0cDI2TeLmpCzmvMtCtB5BRw2puGRiD5hwU+nG 9K1R8IsWy1L0mJbRXluuhqhBdxt2VlAK3swonwp5VbqfKP+4M2ntpmcT1WcX1iL6beRQ+d17 ozs3Xn+53rof4x/T9ir+Sm9/lIhr1tjhOkP3UVHUX3yPEl0c3ciBDlCtYjKwsWSjPPd5F6yb Sd4p/7ZxB4qnTyrUGgPPYgzZpcaiMQxnfWuojRjgO6HsDz2XD6c4nSkb8UuuVRgjVAvN3Vj5 7bmlSoLak7JavJ2r379AHLStILdslCdFxeddFqL1MNc7ZRkqWzam2l7Xg2hBQg5Cy1KMjOU7 VqvoOpdN/2P8o086eN/YNtFjQbVmvwdn46ZnE9VdurBHI4uLInepW5CyWdIkMsFhE9Bp3Uio bvFHiSzqGjtcZ+jc2l3m40X+VrE6ibeEYpvZ1pNicCQ893nnxnTKr/tYeSe5nQbwBJ60NuSd sNpTBixnbsIz1+3MLHWSeXcwoF+BVHOLdwBru+/nxB/cZHi8KEudZN4bDGg4MaghO8JK7vsZ 3hafrCHVt1XhpeBbJgF43r0EqeYW5ye6xQQsQ3939Cycs1bvg4Vb97w/eN7BmUENuZeo6wQA vCibPu10enjevRqp5hYnRa7lxmYCOAvaS4N7u4PnHbwTUEMAAADOSaq5BQAAAMDxQQ0BAAA4 J6nmFgAAAADHBzUEAADgnKSaWwAAAAAcH9QQAACAc5JqbgEAAABwfFBDAAAAzkmquQUAAADA 8XmPasjtenntryHwyU+4CwYQwHsh1dziMLz8FzObMuPLlrAdBhAAQJRnqiHDFytTKxGPUEPk 1zgfbmiez5iti4e02/A10KO2Vle+598P5xtA+5OqbwD2JdXcYvw2Y2pD7BFqSFNO//AfXr/z GbPd0Nhfohq65aDi16OqPcf5BtADaMoDPKsAIBHPVUNcE0yqCIsN102R7sNXdlUgzKY7ibfw MVPegdv18hJD59CN+CBepW+eC63yYqSaW7y1Ve4YfoNCMrHANtwU6T6aMmYXNeVR7e3XwTc6 jp7yDhy6cIJXKeeuxO/6d8q7HAnwDkmthvSsnmHrCI9/1z2nhrw/U3FvUEMOzaEb8UG8St88 F1rlxUg1t4hOo1fbHSrC431f5tQQrKZ7QQ05NK9Szl3hvvbwLkcCvEPOoYYsTmBcVeK5WK04 0VJLeCnK4Iuxdp1KKLMuvcv1WnhOiuxkLl1aRVH0J/q0p0tUIZcatbUowfS3P9HpqHJ56aPp thY1v1yv05Coi6nosUjm1JTHVCDTuasM+SmVy7WeqjglKYsyHlVuFX0SOlPZXMV1Gq2366Wo ZaahSPqUyGMs0JJaegfQl/i4i94AX0IjYYZwjy4o/Cn7Jhotegur27N/GtSzt2KsB0yLFH0q 7tOONXHHJ9Xc4oFqyOIERocWT0Gks4s8r45nWaaWz7vLVJbVI5RZl15eVaXnpMhO5tLHKcu8 u364aIoZyi3GVLO8aqZa+hMdjyrfjz4J3SKyxcpqGhJtlU9Fj0XSp0QeY4FMF6wz3xrR8tPf U5KyKOPRI1bbi3cAvcXHnTvGzRjyjoSlBVlacp3Rir7RLi99tGAF8qqaniRNmVdt478VIzfV lMdUoAXtEosWbS7VFN2PspmtduyhYEZr2acyOxIAzsNx1RDPzFtMvZ0Ia0xef24yvrO1yIa1 Ia4RKbWEupaKiopeF+JKrxOOk9/teumijH+oa+paiTuqGcONrBtBrb+pCysYyXOmJXV24qSt aKDac30z1CJkmK1d1qBqo3Iz5bfntK1pKmoaXVjcmfqlGtlYr6YedaEH1ZoqBgZscNyFGjE2 EmLEboBowV+6b6LPhGi0YG7OfbnoVozeU7F7lrUhL0equcVaNcRVIaQZYCOsMXk917ZVbgUG Y+CsXhsSLX/bNFJRUdGbUlzpdcJx82vK3jAZ/5CVDOcWLaTaXkI1SVvlVhOS57TRZbIzZra2 98QvVQ5jxpnqd7UI9dDal9m681Vuuvzq3OGqHSM4YIPjLtSIsZEQL0Kj2nGFRre+b0x9VV1M BWwjBJpk7nkxCAcRlWHAJ3eaaLGR4LTBompHyx9rH9aGwHvhuGpInJ3VEJ8qkAUNKIf1bgQm Q6OGaKtumRrSXzWeUmpIEaxYlMnSssqIR00aDkVNsHDWwWizfTM3elb3jqissb4Lm9CUdsTi jhUgHM1jOTum81bvlYAaEhl3gbyiIyFG7AaYi3fivlmqq4r70lEGF6ghc/eUyjH4rIGXINXc 4rFrQ+5TQ3xWShY0bmcLs6gIMiujhmjzcpka0h8Zrze2TzC3uVL2iRhlpLRJTEWKyAKxdgpH 8yg2pgrx9l9vvk2Vtda3R0WbVoQcq9oxAmpIZNwFGjE6EmaKELzZ5uKt7pu4LBDOOhht9nmx VTMI3O7BkeBcb/S0jeVXOd611ArgVTmLGrIqAa8aEo++rxrivOt9pBrivgZe1VJZUTvvvp+t hswUeG81ZKyvWYbybIt7rtivq4bEb4DZuOftm/mOiRbxS6xyq+4plYXqLNSQFyPV3OIInjKh gszO8PdVQ5x3vQ9VQ+K5zZY0r1r77vvZashcgfdWQ8b6mvUYT1ZD7qv26phPVEPcpQnLe2hD 3zxCDZkp8L5qSLBF3evDA29V+VUW6vmBGgLvg5OoIU7SUScCX26uZ0DQXjPOAb7sZwsf8hdx UrtfDXFdY1Y09e16yS5FcZl58y1/y9rVRWb9EIxhNf6OONjM9M0D1JCujwvb0VENTpTqdr2o PrWOFOJ3ZCBbBxLHoSSVGiJvgNhICDJzA8wW/rx9448Wy03rUbotI7di5J5yPfeCnjKOG82c 1xo8n1Rzi0eqIb5XpOE3zr6C2MX6EQnBLMlfX3rXWeWRashMbjM0ZZaVpa1x1FYWTddWufFv slUdf0fUBOtKZH/vr4Z0/gFlmc+sxjDD4lDVjnGfGiKdJxaqJk5WIc+hBWzoG9l0TZlZvyVj 7I+/Iw+ZmefFrmpIdCRoFUjf3pFqR8pvczMNGxoJ05E1S30AjkpqNWSfL+y6sbxqSNxrX68e tymKs9bhXrPIDpDRhq0ri1qdKGrxq8sysMuH2nNx3DmgnhJVm0te+/0yl5pqIp1wW1pLcDpe m+x0HSabWh4w1Y70jdsi616th7n5m8lkaO3v6bhtNq/vgamou8evbuVAam5J4pXyRYyOOxs3 1NuB9p8riboBlkc+Wd/MRAvlZqqtNib+Er0Vg887O0oCD1d/1VBDDkequYV3pu8u2V4wj/as 8/a8F3YPx3ci0alaa1GctQ73q8uvow1bV5aNOlE24leXZWDXARWnHfahaPt9MdtIbksQ6YRq YJMT54bdLpUZ5rayqai72a3uukBqgfbfZpjacnsztGbikartITCA3mbGnZNnqLcXF0TXoKz8 Y2wm8pq+EeeGTYGVaOCpgO4Nt0lCzwu3kRdVbCZaaCSYiGoT2Hi1g887WxKn+KGRICKjhsDL k1oNAXg0jDt4PzDaQZNqbsESa0gC4w7eD3wVGGAXnquGdPIi7w3hOQxvubEP4b2AGgKaVHOL 8Z0js3V4EsNbbNQQeCeghgDswjPVEAAAeAzSwwXFGQZSzS0AAOBBSA8X5D+AO0ENAQAAOCep 5hYAAAAAxwc1BAAA4JykmlsAAAAAHB/UEAAAgHOSam4BAAAAcHxQQwAAAM5JqrkFAAAAwPFB DQEAADgnqeYWAAAAAMcHNQQAAOCcpJpbAAAAABwf1BAAAIBzkmpuAQAAAHB8UEMAAADOSaq5 BQAAAMDxQQ0BAAA4J6nmFgAAAADHBzUEAADgnKSaWwAAAAAcH9QQAACAc5JqbgEAAABwfFBD AAAAzkmquQUAAADA8UENAQAAOCep5hYAAAAAxwc1BAAA4JykmlsAAAAAHB/UEAAAgHOSam4B AAAAcHxQQwAAAM5JqrkFAAAAwPFBDQEAADgnqeYWAAAAAMcHNQQAAOCcpJpbAAAAABwf1BAA AIBzkmpuAQAAAHB8UEMAAADOSaq5BQAAAMDxUWrIn29/RkL2v/7PEUK8kIQnhP/9328EAmGv kPyOJpw4RCcAfyMQ4iF9CQgEwmNC6vwJjwiwBdQQwuqQ3HokEM4Ukt/RhBOH6AQg+byNcPSQ vgQEAuExIXX+hEcE2AJqCGF1SG49EghnCsnvaMKJQ3QCkHzeRjh6SF8CAoHwmJA6f8IjAmwB NeQFQ/Mxyz/9nq4AoxX3y/fZ1z+1yY1JAuGlQ/pHCuG8IToBSD5vI8yHpszy6udUuSev/1/K 7NvGHGy+zfIf2tQdQyC8eEidP+ERAbaAGnLU0H76kI18/CxPedWQ8fr9hJLfqw9Zln2ofh// 6I6PVtwD1JD2x2+man/3a3pLdQq/llmG+rOl0bIsy7Lyl+WnpmGQ//iHk+Yf1dfu2Pij+jrT fN8sL+cv32fZN9VvnlPNd8FCRsI0jN0B89tPuTmV/mmz7MYnvGKITgCSz9sIfWirr6ZnV/kX ecqvhjTfei++JzRllmVZ2Ux/vCVXQ9rqK3/l91ZDIh2QOLQ/5Ecr0guEv0zzi2b5qWkY+ATI n6vc3xHT4Fk3LH+u+snAV1WrT3Wd7j21oOJe9dRXyNS95O2Zb5vpj+RFesUAW5hTQ9pPH7Ls Y/Pnn70a8o//+udw9T//+df//OeX//l/o07x17//e0zqy9//0R//z3/aTe3HKO6pLtkZNeT3 T8NjYqQr4Z9vf34u7Sl5Vl/w4VPz6UP5uTvezfvdWMPxXo+Yoo+ig5AtPlSfPg7Hf68+WBVj Rfj9U/7hU7sh4uePe6shH5s//2w+yma8xzz+7ac8onH89lN+aLnh1/LQxUsT2h+/CSgFf1Rf jyLCr6WSJ8wprTX88v0odjTfyVO95FH+6I6iP6rvZNeYn+Hwy/dZlmVf/1R951FD2h+/GeSY P6qv/XKJG5rvJrGm/fEbLdyIdhirmdxgXnjjE14xRCcAzkSq+VZPvyfDISv/8tZ8K6fZjfhv O5kVo5U+/qscozin+mQXTZElYwlHa8J7VsfNf2iqr4ZyuhG7mfdwvC/VFH2shbCav6qqsUGC htKi0P6Qb7Pu2x/yndWQr6q2q2PfjE+eyLt9v5NJFG+pzR3wnLBrN58mtNP9bMLPVT4+kswQ Mqe0INJ8O97DTSlP9c+FsvJ1hIil/p4LIgtTyL+U41Os/SFfKoh0Tyv5VFJ5jQVrq6+Gv5P3 oacG+Q9t195HviMPHWALYTWkN/Ine76TQv5vOwgT7b/e3iZp469//7cQMv7xX/8Ugsj/+n// V2gcf/37vydBRJ9yfgbXhnwupVjw+aMo5+/VBzl9lz8/l/I95+ePWZYNash00FETfq8+fMg/ TFe2k4Zisv5c6qUZThsuDr9/yrcpKXuqIWxmLkQAACAASURBVH82H7Psw6e2q8jU4PcYz7Nq yLHWg5iAGuIJQTVE92Yj5YZfvleLPtRPI2T42nx2nJj0F4TGo4b8WspcNg5OVf72x+9lLn2m TzaPN9/4hFcM0QmAmEJ1UoWagIo5+aACjNNsObu2ZoW23dTSBmPWLbXyfq5yYSxo07UplbEg fqrydxW01lPjGg4/V/lX+WQxaZtLGTv2LWwvlGywWzdbu7uayW31Va8KNd+OL2b3SXpzgXbz EZpVQ44sNxy8eIlCUA2xDyD1FFAjSv38uSr14881x30d0VbfigeQflRFQvtDGSiJqVdY9AkE z0PNhLFqyftQh0lT1v9fCKsCbMGrhnz+6LPhs/ZfkxQyCiKdrvGf//xiVYx//Nc///UfAY3j P/7n3//1n/pU+68vf//HdjVESACD/NELCpMaolSMUPCrIR8bsVhDptN++qAayidGdJrIYpHC Xd4yiTvz7jBeNUStplmx7n2qnRJ9/rdvtf8UlM+CsnKtL4N87f+rU+0Fng7di/3u4unvyayV fjdTSX75Xvzs89X2vCiMWjXwa/n1T63M1F8Ye6r3tvju16ndVtTu+0Y03VjO0YOjT9mIBVML d3G/qX7r/ujz7VtGdp+I5biNyL77vhpNehXFqdcgSQy9EFxb0fwYkT/+qL522mpOmPBJGzPB E8XmskULM2tDTC69kDT/UOo787N8CPSPheajaH3xLBoeO5+mVcHq6Tethis/W4+YwI1PeMUQ nQD87e1tWJTtzPz1JL87MhinnjegwnawJoMwEIZT/Qx/sxriMXb6Aoy2zyIjwq+GfNsIwUWm I96qhqJb2WguuCtfpppGl+17m9qT5gpLanRAEdXvmliWLLh+RmfWXfZVVY0rgrSVOPkCfNv4 h6BvYcgYy/PiWC34UVau839KlDPWAaEgnQ6aabHQFNG7bqqL1f/sK6Jf+09tkmXlD+a2Cblj KB8fdaqveF79PK3LWvDCvU8w/6GdGse/HMuOy2n111dVq90ehnz7ltF3UbjxZXbfVuMjSTaU G3G4LYeWCa6taKqI/OHTNbz3m9I1/lIuNOLNsyP4KPy5qlaqAnNqyOK1Iab9+q7rGyk4EHo/ uyrk6yPHlPWIGaXzPYXQdxdgC0YN6abd/peBf/37vwYJwwm9lqEO/vXv/x7UE6txqFND7m4K UTVEPgZVgYXPi91uY8GS75AaInbrMKqK3OAjorZ0RstSTSS+NiSyAMRz6nNpfYXu3Aggah9q 14b/br7TWz9sWBviMbmnLLS1+WspTG7psGBLotcOqNUNv/2UZ2oVgzDj9dYhwqHD+vj89lNu 9I6+Fsaw9yhEWtoYfEP04gvhweE0gspaKSCOsiC7z3iyqJaMtU9kbUjXyEPLhBQKO0J2UEPc FOKN7NEpfLmIZJXy1RHQj3RG29SQP3+vPqhni9w5qP38eXz6tZ8+qNv/80ehccjngExw8ou5 45lAOGyI/f/vbQq/9deUQavQKzRMr2Cdib06NT7EV7zvNPasKthkeGpDL1L+KYTUED0vN29q swVV6Eq1dEIfV4Ui1o0n4s9V/pV+V72qqW0Yuy2wkv/t56b5OZD335pS9IqU0GSCgX0xovaQ 5729dm1wdlvZsDbEY3JPWdglT1P7/FzlVovxLzRyli04Spi/iVTLGGHS3VHFs+jrbz4NyAzW we1C6wixRlZZKwXE9pdsbeOjpEeaai7HZySod3Y3zJCyWTwWHCGb1RAlftl7zxlAf1GFnEnZ 3r1K+fI9DT0pvznlmTIK3hBTNwYfJk2jFgA6xRSDV40LuXYPd5hHBNhCcG2IazA/Sg1Ra0OW qyHGU0ZN9OXakKkKQg2RYoo2A8JqyKgjhNeY/F598Ood1oNmPuyohnz+6Dw979xpNWh2/rdv iYezAGFnT5nJbrfKiGejzWnLhpAaEt4Fw6mvKK3a/HX8tyfT2ehn4dMCvOb9oGU4Vr2UOcJq iMe8lyKF6lbjhDKjhgyakU8N+aP62t0n9W41ZL2bjL94h1kb8qfeSOj3T7lvvZjn1vYumvM8 XoxgSjhTiE4Ahtmqz7B/lBoi14Ysnd45a0PEHN2sDfGVX5p+ulJhNWScuMd3J/DZHcF9DINh RzXEZ8Lfs+Z86nK1dcqUojH5Qm5Lqqy2Tb1rjWJrNFw1xGPeZyELfG0HhKIMJTTKSGl7aypt RA0JGe2e4okB0XiqrdOZ95tY2MLxRna0A2MEB/rCZ94HV+6YisyoIcOg8jWs99bdqIZo2c7b buFCxlJ2tjVZGHZbG9IlpjZFUS6KoU4zPSOaxK00asj+AbYQ3Dek0wvkFDkmWNzvKbM4DMXT C1hatR+qf2bffLQSj0fXiKkhf759/ujsvarzsmbG1o8y7KqG7P053ph9OGcxPmDfkMHgVMsZ nq+GzHxzZGc1JOho41j18uKYGrJYQZAboEbrPqQ5OvXoLGw6gdqt3jdkg5tMIFawuzenbNpq zb4hzcd+NYf6pJTxZDE3+1I1JPjMJLx+iE4AxvnT4Naw5M3r2w6eMiuDY5goezD06tce99Qo pob0s3+996pj8dmaOtbokrCvGrKrv73o4EypREMrZ8HFDsvVEKfQcwvlfWpI3K56wL4hvQhi Fs48Ww2ZG237qiHBRna1A3lxTA1ZbPB7FkrE1BBhr+sWCC2XMlVYum+I7oIV+4aE+rTPfcNz ZHGPD2Ve1urdtXaRk9kyaYsaslw7IqwIsIX4N2X6/SbGb8r8x/+8ya1D5H6oy3dRzdSXaCJC yQo1RHp/2Jn9JHk4H2pZrYZ0psgH/SUabY2Yj9TM71TiDXt6yvxefVByjF1OvzpELVXjxOFx IVE+HdoE3WZw/vZTnn1TfveN2cTE2rfS4Jel+uX7TK7jsE4u+usnQfPYeJpYj6Fd1RDtpGNy /+2n0jjRiIKJUv1RfS2X7dhvpkQ+p+Jf4DBmN6YZq7L+joyzqeqMOBVPedNOt14NRW56ulhk 0arcL99nxgVJjn/nmzIxX8XP5YdPrVoHZ+5lZw1aSA3RzwTx4TDC+UJ0AmBmUWZ1vMfvYcMu qmoGHBFKYsFcphdsl4F34c6Lx9VqSFflXH+JRlfNfKRmo0/Knp4yVqBY9ZkLN9hy6I7XQ8R+ kSiohui+cb/HMzssPFaUFVBcFwzlp+Ns2LGhjZpvs+zb0u73aAsf2oZXfrmnPxXaxDh+R9kV DY9bGxJt5Olm6EdhprpYO0ioZ4f1fBM3VXg4uTv6BOVYXS/9BSyzqWrIpykyTvSVZivWWBCr 12KL3/bYRdXdULrLTlYiuIhs3LVGLwzRPkzL1obo3tZjhLBXgC3MfWFXhFHmmBCf1+38ZcYz k2ji+YzusGbE+4Xdt1k1xPOF3VF08H5hN1OfgJGoL9GYSPoLu+PFv3/KM+ly/7GSK9V3+P6C UwW1Qj5QtVibOGneuy3i3EYMaoNPZ7tQcdZsVKFZY9N2aTpms07TaiXT8ebHbzK5ckHvVCI/ BDsV291HVscKpba4am4jWw0idEpvsPqT0lPUBqtdjcazurmmDrUl8fi2eGL9d0RI0iPETVPk aPfdiLVJpz6sc5Nxe8fKTKFaxwWRETv+RccNp8TNFVNDeqeY0Gao3Re+s6y/wScPmn4z6eGa aRuRgY+fWBty3hCdAMzOq2YWqg9n7Kdb9M0tNo7wMKuGRLY48H5hN/xN36B7R2Z3CB0vVhP9 n6v82yq4Z+W24NRO2nRO1eS3QYO1NrW7r5DyR5duaDPULMt/qMqxlFMh+v1yTWlE39gPl85u fODvVLN23w4scdbsgRLogPkQWAtkes6zfKg/3kzN5Y5XZ6+drmDjNdKBQeYW/tj1MlVsZlvZ cCObfTV/UHqK3GC10Zvm6uaKbH/rM/KDjTzdKmHvDidN5/4PRgzuD7JCufDvohTf9Hd2NIZ6 x+suOMaOfw9r/PZ2YJj0T0XfipzxMr0HTn/BD6wNeUCALaxVQ9KH5JNLwnJTk5A+xNxqHh9G XWCL98p7CYtvvc8fH/O9WzxlThyiE4Dk8zbC0YP64Ww8uVNQr9wX+xoQDh3SekG4X8MhuGHh hfZbWrsFPGUeEWALqCGE1SG59UhYEdKqIYQFYeF9Z78ss1twXAgJJwrRCUDyeRvh6EH8sF+W 2S3wOc0zBizd44dlV92xh0k83OfERwgE2AJqCGF1SG49EpYF4VfC0owDh5k7Tn81Zq9FHNLF hoUhJw7RCUDyeRvh6OFvdgX+XuaL9I/AJDpVkAOGZT5HDvHzyj1oN2lLuNgglz0kwBZQQwir Q3LrkUA4U0h+RxNOHKITgOTzNsLRQ/oSEAiEx4TU+RMeEWALqCGE1SG59UggnCkkv6MJJw7R CUDyeRvh6CF9CQgEwmNC6vwJjwiwBaWGfAEAAICzkGpuAQAAAHB8UEMAAADOSaq5BQAAAMDx QQ0BAAA4J6nmFgAAAADH57RqSF1kl+stdSkAAACSkWpu8VzaKs/KJnUpAAAA4NV4iBpyu16y LCvqJdfWRf+ppWWXL+YBakhXrccU9z7WNDgspS5oVAB4bZ4wjWjKLMvyql1waTt8e3PZ5Yt5 gBrSyu/KHktpWdHgsJS2ymlUAID3yKPWhtyulzV25MrLH0O8ELfr5ciLTQ7RgofjnlapiyP3 NwDAAp4zk2jKVXbkyssfQlvlEY2jrfL0RYxwhBY8Hne0Snw4AADAeUENWVqIQxQxzMGLlwjU EAB41zxnJnFGNeTQxvERWvB4oIYAAMBqpBrSXi9Zll2K4tK5ggyeIdKelN4ixlgcfV76uF00 5cTRx3atTL/VKlJc4bIwFtFjzCpnF3FeHXfyU+VYWpgpUlFPf095+luyLsTPPprOTBTmcr2O Fvvtepl6zNY9VG3VI2PCC0SAaLRwbqr4l+ut+1HUs9WOjQSZXXG9FlODbOg1VVLUEAB4ccL/ /Zsyy7KsLMssy7K8arvf2lmgP5ZlmfUWEY4kedWOZqhy4uhju1am12pVrinLrdqxiG42oRTV cSeyrHMo5XApsrKZ/p7ylFlOR+dbSxQmr6qp2Zpy6rFYJHNqymMq0PLa+aOFc1PVLpvuR161 3R/9pf0lssOjI8G0yJCh22vrhBHUEACA94pdG1IXvdE4/iGEivHY+HO0F9U2HWYbCyN1+KxM jxpiPFNu18s6a9aTTV1YE9sqA2vXhnhMblVvkZ/KLdKSpuAq29v1IotcF5OEoNtcNd5MtQet IaxbjOhLgtGCuTltsKja0ZEQax/WhgDAOyc6AWirvDMaxz+EUDEdG38O9qLepsNsY6GlDq+V 6VFDmlJZ0k25zpr1ZDOT4oa1IR4VZcrCaRMtemi5ZVFrmQ5oStHKus1lVY2Pj7ujSl+LsG7h lzaC0YK5OT90a+nOUa0V7jfVXKZdWRsCAAAbcNWQ3gSUizt6g7IuPIpFd8g5ZazZ9WqIT2dY JYe42XjM+ywoPDhsMawn698qI8GWnJEFgkUIN/JctTfb/d5okdyc4hvNJlDtuZGgcjQl2qqG OLIKAMArEp0ATCagWNzR/9FWpatYdOfcU9qa3aCGuK/2173cd7OZS3F/T5nJbrfKiE1KpB5u rWgRgtF8qoYja2yx+xfrQ5kdUlOZl6ghM/2mc3T6fJsa4sgqAADwfjiyGnLfPhg+NSRu4D5g 35BBBDHrMZ6shszZ9fuqIcG03OLLi2NqyCovKePYxdoQAHi/RCcAR1JD7tsHw6eGxFN8wL4h gwhilqE8Ww2ZKfjOakgwLacDIpVrjA/QwjLZ9T6sDQEAgNWsUUMc+zBoct+ul0w7iagX/cv2 DTEuF87vGTzGrP0sjOuCobxcnL03NhjWt+ul24klvhpD/palMh959Rj7YkuWkOQ0U+191ZBo bloFko4+0WpHRoLNzZQp3qVbqgcA8EJEJwAxNcSxD8Mmt/LhUM4TTem+wH/zWq32Iy4rP+ri MWZnUjS2uVmJss04bqs8y8vSJmarK39HWss6ucjfEcnJeJo4v/dUQ6K5adGsrfIs85bSfNs2 1m8mN1sm43CzZr0HaggAwHvF3UW190MY96Ho/ugNQ+0HYexQ6chwlbGks8OwpeiwpsRZEhnc 23SZbRrdycNmaOUNtRFsoGrLiyIj+7SeYIJyp9FaNaStn96ddrhujD/mGqr2pv1hZ6OFG9ls sHpVgkOk2sGRYLvbt1fMqqrJmKghAPDihP/7jy4JedVO+1D0e6s2b2+OH4S1zEfyqirlBXIb 0WbYOtNNzyaqfSSW2aYevwqzsUQ4RXHWajuhBBeWxym7TtNqI/7WensL+YXojWPHa8ZoOlYo tcVVm4kWys1Wu6yU4KA2WDXNFuw32zceBWxLr72hhgAAvF8e9YVdgHkOLTgcunAAAEtINbcA MBxacDh04QAA4IGghkA6ji04GH8dAICXI9XcAsBwbMHB+OsAAMB7ATUEUiA9XBAcAAAeQ6q5 BcCE8HBBcAAAgEOBGgIAAHBOUs0tAAAAAI4PaggAAMA5STW3AAAAADg+qCEAAADnJNXcAgAA AOD4oIYAAACck1RzCwAAAIDjgxoCAABwTlLNLQAAAACOD2rILtRFduRvxQIAwHsk1dzizDQl X0YBAAA4B6ghu/BUNeR2vWz5LG1dZEg2AADviVRzizPzVDWkrfIsK5snRQMAAHhnoIa8Erfr JcuyrLheL2vUkLrIsiy7XK8FaggAwDsi1dwC7qat8izLsrKq8jWyxsZoAAAA7xLUkFfktk4N GahRQwAA3hOp5hawG+02WWNjNAAAgHfFXmpIt/xgcODo1zAM7hzDSXlsuuxyvRaekyKZLCvq 4doZa36KcrnW499jutNpm1h/5nK9TcWdLpDxiuu1mGKOZ7xFkzWf6tYdLa6irOtEir3VkGHx CFIJAMCZeMjEoV9+MPiLNKX8NZyUx96my8pqPG/cTfpksiyv2v7aOWt+jJKVzfT3kG6wJMOZ vGpVrqZ6fXHLKeZ4xuspM5VAFn2u2rPsrYYMi0eQSgAAAPZbG3K7XpSWIXfSuNW1VA+U1a12 s6iLKQ2ZYCc5WDlBMSWq9vBQxZLJ2wtFuo4qoMSH2/Xi0Q08QoO5UDeQ2vvDtsksqCEAADDP g6YOZuuMtson67ppGnmdtLrVbhZtlU9pyASbMihOOGKDytmmIrN2N/voZApHm1AqQlvlHvWi KX2x5IW6WOFqLwE1BAAA4GHs6CkjbXqP6e8TLr4YC11Y+dbgN0rGTEHEqhQlk0REFKcwX9SJ YJxQzJtcQeJcpKu31oUFTxkAAJjnYZMHKTZopUEukTBWt7bQhahg9IU1isGUudZkdCk8qzI8 moYnqu8aN2YrV5A4FwWrvQg8ZQAAAB7GrvuGjIqFFSH0ioxNasgqAaDP36xXmRcDFskFdhVM ICZqCAAApOVxs4dRsVAihNExjEm+VA1ZpRgM+VtNZi6FRXnoRR7BmKghAAAAL8nOu6jWxeV6 q4tMLwwRNrjzmdeQGqLjrf2obF1kWVEUJo71SHE8VPxygevcs9RTJqznPEgNibu8hLJZuCcL AAC8Fo+cP7RVXjbGRUT5pzifeQ3LAipeU67aXaOt8iwvy9zZGyS+3sSvStjLfFf5PWWU9mD9 bR6hhsRdXoLRFu7JAgAA8B7Y+5sydoeP6djgZdJtmVrU6kRR+/YjFf4paz8qGzLwtbdMbCeS oKOP3QxkcUS5f4lIafy1oH5OMRdtfOKW0so0aCEAACfksTMIs8PHdKyn3zu0u0LvVzr+Evtp ZOMF1TrFIGDga28Zu7Gp/5zdpcRsBrI4ouuy46/2bK38ZRE52pRmojXlstwBAADeA7t/Ydfd mnQfNjqHwCxr190AAMCL8NgZhNePZA/Wrp+ApaxcdwMAAHBudlZDvHtq7MHqz67AQh7WZQAA kJiHTiDc77TslzCrFx7Cw7oMAADgJdlJDdG+GHsZ1zJVDHYAAIBVPGTiMPvRlXtTxWAHAACA Z7C7pwwAAAAcglRzCwAAAIDjgxoCAABwTlLNLQAAAACOD2oIAADAOUk1twAAAAA4PqghAAAA 5yTV3AIAAADg+KCGAAAAnJNUcwsAAACA44MaAgAAcE5SzS0AAAAAjg9qCAAAwDlJNbcAAAAA OD6oIQAAAOck1dwCAAAA4PighgAAAJyTVHMLAAAAgOODGgIAAHBOUs0tAAAAAI4PaggAAMA5 STW3AAAAADg+qCEAAADnJNXcAgAAAOD4oIYAAACck1RzCwAAAIDjgxoCAABwTlLNLQAAAACO D2oIAADAOUk1twAAAAA4PqghAAAA5yTV3AIAAADg+KCGAAAAnJNUcwsAAACA44MaAgAAcE5S zS0AAAAAjg9qCAAAwDlJNbcAAAAAOD6oIQAAAOck1dwCAAAA4PighgAAAJyTVHMLAAAAgOOD GgIAAHBOUs0tAAAAAI4PaggAAMA5STW3AAAAADg+qCEAAADnJNXcAgAAAOD4oIYAAACck1Rz CwAAAIDjgxoCAABwTlLNLQAAAACOD2oIAADAOUk1twAAAAA4PvuoIbfrJcuyy/VaZD1FLU7X 42Fxpo9TFJfuaPdbxfTGU1n2p67X4noT5biJmDKejJRdrjdTDRHrcr0W0wUz8QAAAA7II+YN TZllWVZWVd7/V8yrdjrbjoflmT5OWfZHu98ypj+eyrI/VZVlI9JsREwZL5qgk+R0wUw8AAAA OA/7rQ2pCyEU1IVUIW51PQoIt+tlkhPqolcrxj9u10sfUV3YCRJTktNl/SmdZqaFjOnSulZa iyyjSkTVRl/4pS4QRAAA4AV40NShrfIs6zSJt7e2yqVo0DTN9Hc5XvXWVnknLox/vDWjCCEv 7H6KJJtS/ch0muKnjhcqiCzBmOSiggAAAMC52FMNERqBUiv00opMKRf93+P18o/MIbRuRKoT Rrv48uVLXYwHVKwsJK/YirkFQQ4BAIDD86CpQ1vlpZQalBpSqn+XUrno/x6vF3+4/2dD60aM rGHEirYq9XoUTzRdesVMQQAAAOBUPEENcZZWLFVDQvKEg1r/ocqhjrirTRaqIWgfAADwgjxo 6hBUQ4w8Ia+LqyHLJQe5XMPVNYYjkYLE1RC0DwAAgPfD49UQrUEof5qYGuIu8hC/ja5hFBa9 dGNKUSV4u14y6yljtxjx++w4vwEAAI7Ig6YOQTVEOZoof5qoGuIs8pC/jfOKUVgy49kyrTYJ FaT7bZIcfscKAgAAACdjz11UB9+T8dckdQgXk26n1WnX1Cwr6v6S8Q9PRCVxWDca7Skjd3PN gu41xVVm5aYa3gfWeuIAAAAckUfMG0Zvkrxqxa9R6hDOKd1Oq9OuqV2cppR/+CIq7cJ6r2hZ Q+zmmmV2NxC3ICKmP8lIQQAAAOBknO8Luzi2AAAAfPly+i/sRnxeAAAAAOZADQEAADgnqeYW TwI1BAAAAO7gXGqI9HXBnQUAAN43qeYWz0B4tLC1BwAAAGzgXGoIAAAADKSaWwAAAAAcH9QQ AACAc5JqbgEAAABwfFBDAAAAzkmquQUAAADA8UENAQAAOCep5hYAAAAAxwc1BAAA4JykmlsA AAAAHB/UEE1dZHygF47E7XrhA0kAsI1Uc4uXoCn5GA0cirbKM74ZDQDwTJKrId1HcS/X2/hH ilKMPEANkZ/9xawNUxe0kY9HqCFjWx/gltPUxeGKdHS6zizq6Q+AiVRziwDdR3HLZvojcWn2 VkPaKp+erpi1QcZ2Qo5SPEINEV+iPlhzd6OA22QFx3qCApyEg6ghRd1P6l9wKn+7XiKlvl0v 2HYriLcmLKMuYoOuLg59n8UL/14Jt8ooIN2uF5QksKSaWwRoyt4ia6v8aKbZItoqjxggbZW/ YJ0S0pS0193EG7EpD20yx2+o90q4S1/+CQpwRJKrIV/qop/B366Xl5zKz6ohR7Y8DwfttQdz asih77ODFy8R4Va5XS+9jFwXL6knw0NJNbcI0FZ5/z6zKV/yxeasGvKCdUoIasgOzKkhh25i bhkf4U57+ScowBFJr4ZMjgDylfW0ZGT8IaWSfqV/UQs/lNEeyLLiOh51TYiAS86YkMfoUM4u 4rw67rh5SHcErw+Iu7J9OCISVsVRSarURBuNFw1R/cXv8yqK/mgfTeYnIxbXa2Faxrcyf8i8 qEX8MfVobkOWAXvOk9vQldexWbwt3Od0LcxZ70gQZRYp9L9CA2F23Mk+8VQk4OMQcx4KDQV3 1EUH7ALhoRatO/09RZSJTkeVy8t0v/prcLleCzEwp/ERi+RtQ88zYVHt/NHCualqDzfs6PAX fHCFR5CnRYYMo136Rbj3eRei9TmikrxXUs0tQozOKWoZxfjCc/whJ/q9V0VetdOi/7xqhxN5 VY2uAI51MFzS+g77zhhnF3FeHXeyk+4I3rK4K9uHIyJhVRyVpE5taqMp8nCFN1rfDmWZ6zzd 8vTlqEpTfl9LDql0R4f4Q+rx3PosA1afL7e+vaqxxiau7KCyqkqTste1YCqzTKG/KNQBcwWR o9STa8DHYYzlMXHjJZFEB+wCXaQVlWqmBKY8ZZbjUeXyIu5XX7pdy4mBKe+AcCR9KvhMWFQ7 f7RwbqraslPjD67oLRwartEufQs9QU2iqCQAq0ivhgQxdrHzbjQ0y59elX7x2gfxDUo8r2CN Y4HdWmT72hCvDazMKZvdra6lZeu3ptyq1bWylpXmZNbliPqrovtW7gRs+KkDVFfM5DZdtFwN GQ5LhUcJA0ZAW6KGOB2s9u0ItaStrOocmaB/X4zojg+eJjF972wtsmFtiGtyZ3IkhEakaVZz zhQyOJxsJwa6dK7agWeCR7T0SolutGBuzg89zkMPruijJD5cN6+YQQ1556SaW6xG28XuG+PO SHCn/00pjrpeAQE1xJupLwm7tcj2tSFeG9hunKCya5tGWra2qCHDJxhtfJk8/iHLq9rC8945 1JJTB6iumMnNl+mC3KY3406bqNTbk6L3HwAABhZJREFUKg/Ys7YEdqMO2QORDggXRCagjOWZ gviqEczaqCur14a4Jnfmr4HOzTSrPafbMTicbNtl4ZaM3YqhZ0K0btFowdzsD91aoQdXtN/i w3Xzgh7UEIAtvLYa4p3h6+NrjQj3eo+ZaK3lPT1lXJHjNi3KMHadW1R/ZU0VPHbbGNMxyYKZ zdXCiTOXm7loISoJE1s31/J0pdFqLdagTR0cd6aSq3eScZvEZ95n0ZvFVG+1YT21glVGPELN tKYhdJ9EezkYbbbaW/2svNFiuTktaDSbQF/MPEqiwxX/IdhGqrnFaubVEL99oI6vXXbvJuox pbJ4wSSrl/27Ikc7rWkw7/Y9aog3s2C0sbZjTMckm1jZjm6cmdzMRQvRSZjYqu+Wpyv7wLFY l40DURBTptU7ybiN5FmTZBcg7OwpI1rBKCN2vY1IPaKGxIoQjjZ3K27WDJbqQ5kdwKLMC9SQ uX6LDdeDuzcBnA3UEINPDYmnsL8a4tq+rivR8qK6r7gXqyEmmeV6wu16yS6XS0gueJYaYi5c LuiMbWbXAERksKVqyOohGRkRIfbfN2RoCNOKz1ZDZsbGzmpIZCxFHkYxNWR5w9vhihoC20g1 t1jNYdSQuBmyvxri2r7dEedd9TI1JBJtkT4xJbPcHmvKLMvz0Ovtp6kh5sLlgs7YZnYNQLgD lqohd9bQf8Qp/u77hvQNYVrx2WrIXMH3VUNiYynyMIqpIYtHoLtCCTUE4IkcWA2Rxv/N87WE rWrIak8Z+zI/Li+YlLd5ynitKZ2vci4IF95oKI7vSlifsNUOrZrxmMN64wTXmN2khgQ9ZUJq iOvJssxTZrra9ecItaSTftA/wtdvqz1lbN1iQpnrIrTJsL5dL9mlKOz4jkk9cgSZL0ZZbU3+ jjjYzFR7VzUkmttNbaJjxkL4wRV7lMwM13iXRuC7u++cVHOL1cj3rU3pLk7YqIas9pSxL/Pd 5e4hvwFv/jIvz5IL5TSgSqTz1U4okcxi0aL6hLH9F7ekzMJ4Ld2jhoQ9ZQJqiO230LIff/80 Zd7tBqEWhkQ6IFwQ1ZC+flvtKeM4gEUVL3eLmS2GdVNmWVnaxGzh1G9RqtZ878Rqa+J3RESZ uRX3VUOiuTWlLmOW+UtpHlyRfpsZrvEujdZt9cIuADi0GiJXjg/7Nxa1Pt7jrkW/XG/il+s+ 4d+ERKG3Q/CfsGfNrgCBUqoLPO/9r7I0gaX0w96h47KRZaXv076IfSov19u0V8NUJtsknu1I QtuBZrajxEangdxi21YEc5uKqAo8Si3BFpHRw7pYqAy2Jb/MjjvRlmrD0Ejd5ppEd49f8nNO ucN8hZU8t9WrpyBy09XatLbfLyQ4gLy+YqHUfE3iZSZapJH1BqtXpV2EHlxucwWfMQGVcUXV ZLJoIe+YVHOLDch9ChthDIf3J53WopeN+GWd9aPbbdo0nQxdA957yinlImO8rXKxGaeOJUs5 7BQ7ygrhzPzRVFONezWI1rHld7cjcVvStPi0DWg1k9tMBwT6Te97aTYdtUm6Bu+cCBEog6cD ogVR8fKq8m5N4xYkvtuFrp1HF/Odclt5hZUclqOCCYpzZWMr6fULCQ6gxhcrlNryqs1EC9/4 rb5HdaeGHlxOcwU7dHGXLqogWgjAWg6thrxLNr7ehr1Z5Rq0Bnwezsdh71rvUiR4T6SaW8Ai VrvWwINY5Rq0Kl18Hk7HUTvVuxQJAGZBDTkah7Wr3hlrthlZmzAdfDaOetc+bBTDy5BqbgGL QA05Bqu2GVmD+5UjeH0OqoY8StEDOD2oIYdCrJbHiEnD9u/oLEyVjj0XdC0cmlRzC5hHLMzH iEnDHd/RiUDHnhY5YJC5AM4CaggAAMA5STW3AAAAADg+qCEAAADnJNXcAgAAAOD4oIYAAACc k1RzCwAAAIDjgxoCAABwTlLNLQAAAACOD2oIAADAOUk1twAAAAA4Pi+thtyuFz5WCgAA4CfV 3OIB8P1IAAAA2JkXUEPkJ0/1Jyz3VUO6fIp6+uPu1CJf3Nw3NwAAAIdUc4utqE+e6k9Y7qqG dB9BLZvpj7tTixRu39wAAABgL/4/ZF8F9OiFNf8AAAAASUVORK5CYII= --------------22A3D0E48733AA6EF94916CB-- --------------DDABBB70A11AC1EA393301D6-- From nobody Wed Feb 14 04:18:50 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9282127599 for ; Wed, 14 Feb 2018 04:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 JKN9fbw7SvOZ for ; Wed, 14 Feb 2018 04:18:46 -0800 (PST) Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B210A124234 for ; Wed, 14 Feb 2018 04:18:45 -0800 (PST) Received: by mail-lf0-f52.google.com with SMTP id x196so29127179lfd.12 for ; Wed, 14 Feb 2018 04:18:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7DM6jc6HUCFpDEVhouyY3QZ2Yv16UDuNjrzE2Hme+dY=; b=mGy4pLVclZBzwMhzoj7bDdIr6EVbntLNyKv5tpZezHDk70IJXV4+VgpTL/VDyI0I9b 9YmW4g+2ppr5+xcRipqeDoaNOBUDHUaQ6DOBdr3R6J2DeZelLEGqjXaReDLcm31KFKjR 6KBEmMD3u7qqwrpRcxgP3v7KnMlLF1QGBD/ws6pHo1NuDhUVcQjMwm5RUUuVkIXxq1mE CC6s7EnCjJjA8v4uaqPHf02L3NXo2j3qNotfkobr+YXhZYV9FJ0RFDc8bWfIomwPRhe9 bRv65JLWE+vDPWc7ji5x1ruB4hguEshcdNjByZNid7vvOGAIZPr9qA+feK4LTmRDENz2 /kmQ== X-Gm-Message-State: APf1xPDUKBko0TPChSt4d/mLTf1px5o5gG7UHW6sAhHQgGhMG/r5aGQ6 QEDIsK3PMjzZVDK8sqe/hINg3cfMDAvnDYxcVevt X-Google-Smtp-Source: AH8x227ETRt5XphNbVqCDZEYNr2Ru1lN4Q35PBZl7vjbrfGk02ay9vjmIJK0GlglLWFNbiRnf0LzM96AvdWw31m9L5I= X-Received: by 10.46.93.207 with SMTP id v76mr3362446lje.134.1518610723464; Wed, 14 Feb 2018 04:18:43 -0800 (PST) MIME-Version: 1.0 References: <20180214011239.3E6CEB80FB3@rfc-editor.org> In-Reply-To: <20180214011239.3E6CEB80FB3@rfc-editor.org> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Wed, 14 Feb 2018 12:18:32 +0000 Message-ID: To: anima@ietf.org Content-Type: multipart/alternative; boundary="94eb2c06970cb96a5d05652b1c07" Archived-At: Subject: [Anima] Fwd: [nmrg] RFC 8316 on Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 12:18:49 -0000 --94eb2c06970cb96a5d05652b1c07 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: Date: ter, 13 de fev de 2018 23:12 Subject: [nmrg] RFC 8316 on Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations To: , , < irtf-announce@irtf.org> Cc: , , < rfc-editor@rfc-editor.org> A new Request for Comments is now available in online RFC libraries. RFC 8316 Title: Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations Author: J. Nobre, L. Granville, A. Clemm, A. Gonzalez Prieto Status: Informational Stream: IRTF Date: February 2018 Mailbox: jcnobre@unisinos.br, granville@inf.ufrgs.br, ludwig@clemm.org, agonzalezpri@vmware.com Pages: 16 Characters: 40002 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-nmrg-autonomic-sla-violation-detection-13.txt URL: https://www.rfc-editor.org/info/rfc8316 DOI: 10.17487/RFC8316 This document describes an experimental use case that employs autonomic networking for the monitoring of Service Level Agreements (SLAs). The use case is for detecting violations of SLAs in a distributed fashion. It strives to optimize and dynamically adapt the autonomic deployment of active measurement probes in a way that maximizes the likelihood of detecting service-level violations with a given resource budget to perform active measurements. This optimization and adaptation should be done without any outside guidance or intervention. This document is a product of the IRTF Network Management Research Group (NMRG). It is published for informational purposes. This document is a product of the Network Management Research Group of the IRTF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist https://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ nmrg mailing list nmrg@irtf.org https://www.irtf.org/mailman/listinfo/nmrg --94eb2c06970cb96a5d05652b1c07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

---------- Forwarded me= ssage ---------
From: <= rfc-editor@rfc-editor.org>
Date: ter, 13 de fev de 2018 23:12
= Subject: [nmrg] RFC 8316 on Autonomic Networking Use Case for Distributed D= etection of Service Level Agreement (SLA) Violations
To: <ietf-announce@ietf.org>, <rfc-dist@rfc-editor.org>, <= irtf-announce@irtf.org>Cc: <drafts-update-ref@i= ana.org>, <nmrg@irtf.org>= ;, <rfc-editor@rfc-editor.= org>


A new Request f= or Comments is now available in online RFC libraries.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 8316

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 Autonomic Networking= Use Case for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Distr= ibuted Detection of Service Level Agreement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (SLA)= Violations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0J. Nobre,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 L. Gr= anville,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A. Cl= emm,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A. Go= nzalez Prieto
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Informational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IRTF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0February 2018 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 jcnobre@unisinos.br,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 granville@inf.ufrgs.= br,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ludwig@clemm.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 agonzalezpri@vmware= .com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 40002
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates/Obsoletes/SeeAlso:=C2=A0 =C2=A0None

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-irtf-nmrg-autonomic= -sla-violation-detection-13.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc8316

=C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 10.17487/RFC831= 6

This document describes an experimental use case that employs
autonomic networking for the monitoring of Service Level Agreements
(SLAs).=C2=A0 The use case is for detecting violations of SLAs in a
distributed fashion.=C2=A0 It strives to optimize and dynamically adapt
the autonomic deployment of active measurement probes in a way that
maximizes the likelihood of detecting service-level violations with a
given resource budget to perform active measurements.=C2=A0 This
optimization and adaptation should be done without any outside
guidance or intervention.

This document is a product of the IRTF Network Management Research
Group (NMRG).=C2=A0 It is published for informational purposes.

This document is a product of the Network Management Research Group of the = IRTF.


INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce = lists.To subscribe or unsubscribe, see
=C2=A0 https://www.ietf.org/mailman/listinfo/iet= f-announce
=C2=A0 https://mailman.rfc-editor.org/mailma= n/listinfo/rfc-dist
=C2=A0 https://www.irtf.org/mailman/listinfo/irt= f-announce

For searching the RFC series, see https://www.rfc-editor.org/search=
For downloading RFCs, see https://www.rfc-editor.org/retriev= e/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
nmrg mailing list
nmrg@irtf.org
https://www.irtf.org/mailman/listinfo/nmrg
--94eb2c06970cb96a5d05652b1c07-- From nobody Wed Feb 14 08:56:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D139B12D7E2 for ; Wed, 14 Feb 2018 08:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 m7r9T3fJ_RWm for ; Wed, 14 Feb 2018 08:56:07 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890FC126D85 for ; Wed, 14 Feb 2018 08:56:07 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id AD1D458C4FF; Wed, 14 Feb 2018 17:56:01 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8FDCDB0DA63; Wed, 14 Feb 2018 17:56:01 +0100 (CET) Date: Wed, 14 Feb 2018 17:56:01 +0100 From: Toerless Eckert To: "Nancy Cam-Winget (ncamwing)" Cc: Eliot Lear , "Liubing (Leo)" , "mcr+ietf@sandelman.ca" , "anima@ietf.org" Message-ID: <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 16:56:12 -0000 WG-chair: I would prefer for any work in this space to happen in followup document(s), not in BRSKI itself. I think anything done in ANIMA should purely be describing mechanisms to leverage unmodified existing 802.11 mechanisms and ideally we find some existing work that also built some form of layered standards on top of 802.11. The issue we IMHO need to overcome is that there are ways how this could also be done by extending 802.11 and we need to have an argument why that may be an option but it is nonwithstanding for us to do it NOT that way. We had for example also a long discussion in the beginning of ANIMA why not to use EAP in BRSKI. Nancy mentioned other 802.11 options beside SSID, so maybe we should gate a decision to adopt any such work to the WG having sufficient understanding of what the existing options in 802.11 are that we could leverage without having to extend 802.11. Maybe we could draft Nancy or some other 802.11 expert to give a summary to the WG (802.11u eg.). Contributor: An ANIMA standardized method of BRSKI via 802.11 would be great. A single AP may already provide SSIDs under different logical administtrative domains. For example in SP-Wifi, where the AP is logically paid for by a subscriber and residing in the subscribers residence but also providing a managed "community" SSID from the SP. For example with comcast that second SSID is called "xfinity" and if you want to have access to that SSID on any of the other subscribers AP, you also have to permit for xfinity SSID to be enabled on your device (if you have one). Note: all the following is only taking my limited knowledge of 802.11 into account, aka: might change when i learn about 802.11 or other options. But the principles expressed below should stay the same. And of course the impliciation is that you should be able to have multiple SSIDs for BRSKI, one for each administrative domain, because otherwise we would have to figure out how to set up a multi-registrar / multi-operator BRSKI proxy/registrar infra. Aka: I would propose that the SSID (ESSID ?) scheme is something like: BRSKI should be choosen to be least likely already used, e.g.: "-" would be bad, but i am not sure what the most obfuscated, 802.11 permitted char is. "%" ? BRSKI%xfinity BRSKI%tte-home-network The selection rules for equipment would say to just try all the BRSKI%... SSIDs. If we wanted to be fancy, we should try to find a method to signal priority to pledges. Not sure if there are any nicer attributed, but if not, wee could (yuck yuck) do something like BRSKI%1%tte-homenet to indicate first priority for that SSID. We should also have BRSKI The well-known-ssid would be requiring a specification how pledges would select those. For example we could consider some standardized cloud-service offered by multiple SPs for home-automation - acme-aut. Equipment from various vendors (sensors/actors) built against that standardized cloud service would prefer BRSKI%%acme-aut over other SSIDs to enroll. And the service would also hopefully define a mechanism to allow such equipment to be enrolled into the SSID of the subscriber itself, e.g.: by also recognizing any higher priority existing-ssid (BRSKI%1%tte-homenet). Or use a redirect in BRSKI itself.... Ok, i hope i get highscore for overdesigning the solution (kidding). Aka: selecting the best SSID in face of competing offers multiple or single AP is the type of work i think we should give some tthought to. Ideally something extensible where we can in the first spec get away with a most simple start but will have forward compatibility with later updates/extensions. Cheers Toerless On Tue, Feb 13, 2018 at 02:31:36AM +0000, Nancy Cam-Winget (ncamwing) wrote: > Hi, > Catching up on this thread....it is not clear to me that we can prescribe an "SSID" as there can be a couple of solutions.... > And for that level, I believe is out of scope for IETF; that said, there are a couple of means to do this w/in 802.11 the cleanest one is using the service/capability advertisements from 802.11u. The SSID is really not sufficient on the 802.11 as we've build agility there as well to denote the types of authentication and key management that we would also want to retain (agility to) as we do this ala BRSKI. But, I break it down to "discovery" as perhaps being an 802.11 scope and thereafter we can discuss work relevant here. > > That said, for the actual enrollment would very well be suited to be in the EAP realm as 802.11 already prescribes to using that model within 802.1X. > > Hopefully that makes sense, > Nancy > > ???On 2/12/18, 1:56 AM, "Anima on behalf of Eliot Lear" wrote: > > Hi Bing, > > I think you've got it down, but I want to stress that these are early > days, and I could, perhaps easily, be convinced to go another way. I > think Michael is trying to do that ;-) I think the question is this: in > a WiFi environment how can the device know which network to connect with > in the first place, and how does it then send packets to complete the > BRSKI flow? > > As a difficult use case, consider a business in an office building on > the 10th floor in New York City or London, where you might hear 2 dozen > different networks. > > Eliot > > > On 11.02.18 10:16, Liubing (Leo) wrote: > > Hi Michael, Eliot and all, > > > > A clarification question: it sounds like there are two approaches proposed, not sure I understood it correctly: > > > > Michael's proposal: there is a dedicated SSID, say "Anima", it is enabled by default, and there is no security. And that SSID can only do BRSKI, no other services permitted (just like the http portal authentication). After getting the certificate, then certificate-based EAP could be run to do the 802.1x authentication; or maybe they just negotiated a key for WPA2. In this case, the BRSKI just works as the bootstrap of WiFi. > > > > Eliot's proposal: we'll have a new EAP method, say "EAP-BRSKI", just treat BRSKI as an option encapsulated in EAP protocol, under the WiFi access framework. > > > > Michael and Eliot: did I get you correctly? > > > > B.R. > > Bing > > > >> -----Original Message----- > >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Eliot Lear > >> Sent: Thursday, February 08, 2018 5:51 PM > >> To: Artur Hecker ; anima@ietf.org > >> Subject: Re: [Anima] BRSKI over 802.11 > >> > >> Artur, > >> > >> I suspect much ??? but not all ??? of this could be addressed in EAP. > >> > >> Eliot > >> > >> > >> On 08.02.18 10:24, Artur Hecker wrote: > >>> Hi Michael > >>> > >>> > >>> Sorry, maybe I misunderstood the intention. Is your intention to make it > >> "standard" or just to make a demonstration? If the latter, then it's OK. It's the > >> first that I simply doubt it will work. > >>> I am not claiming that there are better means to do that, let alone that what > >> you proposed makes no sense. I actually said that this makes sense. I just think > >> that we enter the realms of 802.1 and 802.11 at the same time and have no > >> authority there. > >>> It has indeed nothing to do with Wireless access points. Any STA (802.11) and > >> any supplicant (802.1X) is subject to standardization and regulation of the bodies > >> of IEEE, in any mode of operation. WPS should not be limited to any Access > >> Point presence, since it supports WiFi Direct. I agree, the supported methods are > >> rudimentary. If I remember correctly, something like PIN, the push button you > >> mentioned, NFC and USB. > >>> I guess, a possibility would be to specify an additional ANIMA/ACP/BRSKI > >> method for WPS, why not. All I am saying is that we probably need to do it there, > >> as any try to do it in the ANIMA WG would require specific 802.11 modes and > >> specific 802.1X functions/behaviours, which I am not sure we can dictate to > >> have. > >>> > >>> Regards > >>> artur > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > >>>> Sent: 07 February 2018 20:07 > >>>> To: Artur Hecker > >>>> Cc: anima@ietf.org > >>>> Subject: Re: [Anima] BRSKI over 802.11 > >>>> > >>>> > >>>> Artur Hecker wrote: > >>>> > Hi Michael, > >>>> > My opinion: > >>>> > >>>> I don't think understood the question :-) > >>>> > >>>> 1) It's not about Wireless Access Points, so all of the Wifi Alliance, > >>>> etc. talk makes no sense to me. There can be no access points until they > >>>> have been configured. It's possible that there might NEVER been any > >>>> access points, because the operator actually doesn't want/need any > >>>> enabled. > >>>> Think about inside of a cage in a data center. > >>>> > >>>> 2) It's about *devices* that have 802.11 interfaces. > >>>> You can't use WPS or anything else involving 802.1x until you have > >>>> credentials, which is what BRSKI gets you. > >>>> So you can't use WPS to *bootstrap* WPS. > >>>> (and pushing buttons on the front of the AP is by definition not > >>>> "zero- > >>>> touch") > >>>> > >>>> > Q3: Sorry, I did not quite understand this one. If you meant the ad-hoc > >>>> > essid based network, my first intuition would be to object, as I > >>>> > believe that we should not prescribe such modes for ACP, but rather use > >>>> > the best available one. > >>>> > >>>> 3) The ACP is secured inside IPsec over Link-Layer IPv6 (or MACSEC, or > >>>> a bunch of other possible technologies in the ACP document). > >>>> It's not about the security of the ACP. > >>>> > >>>> Since the point of the ACP is that it's always available, it needs to > >>>> be available even when the Wifi Access Point is toast or not yet configured. > >>>> Of course, once there is a non-adhoc/IBSS network available, the ACP > >>>> would see this as additional interfaces and make additional mesh > >>>> links across it for the ACP to use. But that's not bootstrap, that's operation. > >>>> > >>>> > Q4: As I believe that Q2 is strongly biased, I believe that so is > >>>> > Q4. The WiFi Alliance already specifies several ways how to bootstrap > >>>> > wireless access points, including e.g. WPS. We would rather need to > >>>> > see, how to integrate with such means. And again, I don't believe we > >>>> > have authority on that. > >>>> > >>>> Maybe you could point to specific documents that would permit two > >>>> devices which have never been touched to communicate over 802.11 > >>>> without configuration. > >>>> > >>>> -- > >>>> Michael Richardson , Sandelman Software Works > >>>> -= IPv6 IoT consulting =- > >>>> > >>>> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >>> > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Feb 14 09:01:21 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E5112D7E4 for ; Wed, 14 Feb 2018 09:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLV90PzCoZkT for ; Wed, 14 Feb 2018 09:01:18 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBA412D7E5 for ; Wed, 14 Feb 2018 09:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2738; q=dns/txt; s=iport; t=1518627662; x=1519837262; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=pC14zQikTM00X7JClFdDsEYoxwkyDGuDpShL3Ijb1ek=; b=UrUwFNGxG900EQsWW5KMHe+UY7bgzdeEOJpyC+w681DFNVaxhaaZNyhy M/uJmoctYJgAF7Yec0ve8joJ9tz526L3ohtKaNZ6bSk2iOj9Akowg2RCx uDAv1/qWlsdnV9pInv1Fhbm7aeUHHogyegAxOe9JSjZt0vY8Pdgk7fpKH Q=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos; i="5.46,513,1511827200"; d="asc'?scan'208"; a="2024966" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 17:00:59 +0000 Received: from [10.61.81.76] (ams3-vpn-dhcp4429.cisco.com [10.61.81.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1EH0uhJ023048; Wed, 14 Feb 2018 17:00:57 GMT To: Toerless Eckert , "Nancy Cam-Winget (ncamwing)" Cc: "Liubing (Leo)" , "mcr+ietf@sandelman.ca" , "anima@ietf.org" References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> From: Eliot Lear Message-ID: Date: Wed, 14 Feb 2018 18:00:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ebKD0rae2uTOhAjk4T10jXdJ1Xafvrfc1" Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 17:01:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ebKD0rae2uTOhAjk4T10jXdJ1Xafvrfc1 Content-Type: multipart/mixed; boundary="qEmt9a9aH8fnVPWqD6NmPHw8LXwx7nCdn"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert , "Nancy Cam-Winget (ncamwing)" Cc: "Liubing (Leo)" , "mcr+ietf@sandelman.ca" , "anima@ietf.org" Message-ID: Subject: Re: [Anima] BRSKI over 802.11 References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> --qEmt9a9aH8fnVPWqD6NmPHw8LXwx7nCdn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Toerless, On this point: On 14.02.18 17:56, Toerless Eckert wrote: > Aka: selecting the best SSID in face of competing offers > multiple or single AP is the type of work i think we should > give some tthought to. Ideally something extensible > where we can in the first spec get away with a most simple > start but will have forward compatibility with later=20 > updates/extensions. +1.=C2=A0 And I think this needs to be a pretty broad discussion.=C2=A0 W= e need to sort, at least in our own minds, at what layer to solve what problem, and how to do that without driving end users and administrators absolutely crazy. Eliot --qEmt9a9aH8fnVPWqD6NmPHw8LXwx7nCdn-- --ebKD0rae2uTOhAjk4T10jXdJ1Xafvrfc1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlqEa0cACgkQh7ZrRtnS ejNIwwf+J9RbyD7475IMT9aL4DSZZmiMAvLz4335ePuvv1Hda2AdSgrhSc6To5cY jGUPXRmxFfQOqO6Y0/2eOgtcbbH72t+7JiLausIOztgyt5RgxZmJKcjiqKFJDhfE LH7SJKkZAd2lH9FZQZhZQJKYtBMvZ6k3Mq+uB8Uq1WlS8VYJcd6GkQrNceFHJ/gK YRczthl3cyAO0l/sD7OjNNANi4hU0tUd0xJo3zkTiCP/ykHGk+Wlso8uG60EulwQ wavI7+U1xv3OGNVxAo9Ywg2H9990SPOMJqJbjW7DP3+R8NS+B8tMhCtyJ120i1z3 Hgq1e/axcJ1dk8VxMh4VJi7DYz/EoA== =kjCH -----END PGP SIGNATURE----- --ebKD0rae2uTOhAjk4T10jXdJ1Xafvrfc1-- From nobody Wed Feb 14 10:24:43 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9216512D80E for ; Wed, 14 Feb 2018 10:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 VcP8GLeDjbcK for ; Wed, 14 Feb 2018 10:24:39 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0A2126D45 for ; Wed, 14 Feb 2018 10:24:39 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A31E920090; Wed, 14 Feb 2018 13:31:36 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 18E1580639; Wed, 14 Feb 2018 13:24:38 -0500 (EST) From: Michael Richardson To: Benoit Claise cc: anima In-Reply-To: <59f7ea78-fe56-abb3-d141-adf70ee21364@cisco.com> References: <151853912961.14349.6366358483962775318.idtracker@ietfa.amsl.com> <19040.1518557815@obiwan.sandelman.ca> <59f7ea78-fe56-abb3-d141-adf70ee21364@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] New Version Notification for draft-ietf-anima-bootstrapping-keyinfra-10.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 18:24:41 -0000 --=-=-= Content-Type: text/plain Benoit Claise wrote: > The tooling can't extract the YANG modules. > This issue comes from: > * > You should remove "yang/" I'll fix that! We moved files around in our repo and didn't realize it would impact here. > Also, complete the CODE BEGINS here under: > > module ietf-mud-brski-masa { > yang-version 1.1; > namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"; > prefix ietf-mud-brski-masa; > import ietf-mud { > prefix ietf-mud; > } > import ietf-inet-types { > prefix inet; > } Ah... fixing to insert file name and make it consistent with our other yang data. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqEfuUACgkQgItw+93Q 3WVkvAgApDuRuyrOi3JM/necyI7C4psW3cJzpRlli2kAoALP1D0Ygn28kUGN1RAX WkJhZHw+JBVW2bg+DET7fkdlPQTnEBOuxuwjCeHuzcI4vCr1vBE7tqeQsfXFTsPh ZuQUdzueKEwe0m7P1txcrtjbJ+JommTSkkK9YWUqQlYHaCuXzkPqFyfbGT1GHqj5 anQlIzapiyWMFf7zMT0SUZ3diaJc3ZyoRX3BFuiBhCdFs+t4i+I7VYYIVGlBh3R9 dut9vMrH3msRdfl0EH5ysnjLO3fLdX+1Sq6C/yAZ5CWmOsyF2b7htuV8H3SGnuGW DySP8/7EEzDOX9q5vhYTRi9QvQSjiQ== =dMzL -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 14 11:08:25 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B16512D84A for ; Wed, 14 Feb 2018 11:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 2uLqE7lksuf8 for ; Wed, 14 Feb 2018 11:08:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585FF127867 for ; Wed, 14 Feb 2018 11:08:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C52620090 for ; Wed, 14 Feb 2018 14:15:19 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EB95980639 for ; Wed, 14 Feb 2018 14:08:20 -0500 (EST) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 19:08:24 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I would prefer for any work in this space to happen in > followup document(s), not in BRSKI itself. I agree completely. I wasn't imagining putting it into the current document. > I think anything done in ANIMA should purely be describing mechanisms > to leverage unmodified existing 802.11 mechanisms and ideally we find > some existing work that also built some form of layered standards > on top of 802.11. > The issue we IMHO need to overcome is that there > are ways how this could also be done by extending 802.11 and we > need to have an argument why that may be an option but it is > nonwithstanding for us to do it NOT that way. We had for example > also a long discussion in the beginning of ANIMA why not to use EAP > in BRSKI. I agree completely. > Nancy mentioned other 802.11 options beside SSID, so maybe we should > gate a decision to adopt any such work to the WG having sufficient > understanding of what the existing options in 802.11 are that > we could leverage without having to extend 802.11. Maybe we could > draft Nancy or some other 802.11 expert to give a summary to the WG > (802.11u eg.). I'm willing to listen to ideas, but I'm afraid of going down the IEEE hole here. > Aka: selecting the best SSID in face of competing offers > multiple or single AP is the type of work i think we should > give some tthought to. Ideally something extensible > where we can in the first spec get away with a most simple > start but will have forward compatibility with later > updates/extensions. your suggestions are inline with what I was thinking. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqEiSQACgkQgItw+93Q 3WXNTQgAgkWBRoXJZO4GR6SCPB7A5DOVDNEmKAk08JjTwNt7e+dzSNMjUIYGk6Ka 7iApVCyDM2t058AejxfGD6H5wxx0krgKjxUwx7GYHsfXBSHDmL3vqZ4weRPqfaxy ehpsZkHSKF3rKG6FyZnisxypNwTiNo7TU9za4eCtLPHjC87HiyU/E7+iB+rkvPus 2WmZmDP/rYyHM8q2a6qLDDP6jh4AwtC5l98wG9c05a9GG1qbKskwBlDYP0He9Cuj cDjDHtmHdzu8DF9ed9scUrFR9IxVg7cgTFLMSZgweu11Upuf2nuZZAZJMlOZQ8Xf bZ5zNND6ehog4zD8yghLXoiRH00EXQ== =SV/p -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 14 11:13:05 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CAB124205 for ; Wed, 14 Feb 2018 11:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 ugRz5Wl4KBa4 for ; Wed, 14 Feb 2018 11:13:02 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F60127867 for ; Wed, 14 Feb 2018 11:13:01 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DE91658C4F8; Wed, 14 Feb 2018 20:12:57 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id C0601B0DA68; Wed, 14 Feb 2018 20:12:57 +0100 (CET) Date: Wed, 14 Feb 2018 20:12:57 +0100 From: Toerless Eckert To: Michael Richardson Cc: "anima@ietf.org" Message-ID: <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> <31460.1518635300@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31460.1518635300@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 19:13:04 -0000 On Wed, Feb 14, 2018 at 02:08:20PM -0500, Michael Richardson wrote: > > Nancy mentioned other 802.11 options beside SSID, so maybe we should > > gate a decision to adopt any such work to the WG having sufficient > > understanding of what the existing options in 802.11 are that > > we could leverage without having to extend 802.11. Maybe we could > > draft Nancy or some other 802.11 expert to give a summary to the WG > > (802.11u eg.). > > I'm willing to listen to ideas, but I'm afraid of going down the IEEE hole here. Maybe i was unclear. I think we should just know the whole slew of tools available from 802.11 that we can use without changing 802.11. I only know SSID/ESSID, so i try to figure out how to abuse oops: well use them. Nancy pointed to more tools. > > Aka: selecting the best SSID in face of competing offers > > multiple or single AP is the type of work i think we should > > give some tthought to. Ideally something extensible > > where we can in the first spec get away with a most simple > > start but will have forward compatibility with later > > updates/extensions. > > your suggestions are inline with what I was thinking. Cheers Toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Wed Feb 14 12:09:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3664127867 for ; Wed, 14 Feb 2018 12:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 3c3AAIWaptHi for ; Wed, 14 Feb 2018 12:09:36 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B3D1243F3 for ; Wed, 14 Feb 2018 12:09:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B02220090; Wed, 14 Feb 2018 15:16:33 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3BDBE80BB3; Wed, 14 Feb 2018 15:09:34 -0500 (EST) From: Michael Richardson To: William Atwood cc: anima@ietf.org In-Reply-To: <1051ad5c-1bc7-5fda-2a32-ce65f19a47e3@concordia.ca> References: <1051ad5c-1bc7-5fda-2a32-ce65f19a47e3@concordia.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Technical comments on draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 20:09:38 -0000 --=-=-= Content-Type: text/plain tl:dr: https://github.com/anima-wg/anima-bootstrap/pull/41 https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-10&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/bill-atwood-comments/dtbootstrap-anima-keyinfra.txt or: https://goo.gl/pXNghv William Atwood wrote: > Section 1, para 3, lines 4-5. "is a minor extension to the voucher > format (see Section 3)." What "voucher format"? I guess that you mean > the voucher format defined in draft-ietf-anima-voucher. I suggest some > additional precision here. Added another reference to anima-voucher document at the end of the paragraph. > Lines 4-5. Why is this "minor extension" defined here, and not in > draft-ietf-anima-voucher? Would it not be better to have all (currently > known) voucher formats in one place? No, because anima-voucher is used by the RESTCONF work in the NETCONF WG, and they have no use for the voucher-request. > Section 2.3, para 2, line 1. "previously defined fields" Where are > these defined? Are they previously defined in this document? Are they > previously defined in some other document? (If so, give reference.) > In general, this paragraph and its two bullets might be understandable > by someone who is well familiar with X.509, but they are opaque to > someone who is not (i.e., this reviewer). I believe that your message so, I think that understanding something about PKIX (X509) and EST is unavoidable, and I don't think we should clutter the document explaining those parts. > Section 2.3, para 5, line 4. In this document, the string ".well-known" > appears variously as ".well-known", "./well-known", and "/.well-known". > If these are in fact intentional, then the differences should be > explained. Otherwise, a consistent form should be ensured throughout > the document. Given that I do not know what is correct, or if they are > intended to be different, I have not signaled these cases in my General > Comments. You will have to do a search to discover all the instances. ./well-known is a typo. I've put / in front of every use. /.well-known refers to rfc5785. RFC7030 (EST) all lives under /.well-known/est. I've added a reference to 5785 at the first use of /.well-known. > Section 2.6, para 1. I find this entire paragraph puzzling. I believe > that more text is required here, in the hope that the use cases will be > clearer. Perhaps the use cases need to be stated first, followed by the > allowed actions. Max, I have added a paragraph to explain the legacy situation that the "Cloud There are transitional situations where devices may be deployed into legacy networks that use proprietary bootstrapping mechanisms based upon the base EST (). The same device may also be deployed into an ANIMA environment. This may be due to incremental replacement of a legacy situation with ANIMA. There are additionally some greenfield situations involving an entirely new installation where a device may have some kind of management uplink that it can use (such as via 3G network for instance). In such a future situation, the device might use this management interface to learn that it should configure itself by to-be-determined mechanism (such as an Intent) to become the local registrar. In order to support this scenario, the Pledge MAY contact a well known URI of a cloud Registrar if a > Section 3, para 1, line 6. What is the meaning of > '"proximity-registrar-cert" leaf'? What is the leaf a leaf of? If this > refers to some YANG module, please cite the YANG module. So the title of the section is "Voucher-Request artifact", and the entire section is about the YANG module ietf-voucher-request. I have added one phrase: "defined in this section" > Section 3.2, Example (2). Does this example illustrate _a_ Registrar > voucher-request, or does it illustrate the Registrar voucher-request > that would be used to forward Example (1)? If the former, why is the > nonce identical? If the latter, it should be explained that certain > other fields are carried forward as well. The nonce, created-on and assertion are carried forward. I have changed the text to say: The 'prior-signed-voucher-request' leaf is populated with the Pledge's voucher-request (such as the prior example). The pledge's voucher-request, if a signed artifact with a CMS format signature is a binary object. In the JSON encoding used here it must be base64 encoded. The nonce, created-on and assertion is carried forward. serial-number is extracted from the pledge's Client Certificate from the TLS connection. See . > Section 4.1, para 2, bullet 2, line 3. "may" -> "MAY" (This "may" > seems to be normative.) Yes, thank you. > Para 7, line 2. "should" -> "SHOULD" done. > Section 5, para 8, bullet 1. The reference to RFC6125 appears to be > normative, and so RFC 6125 should be added to the list of (normative) > references. Added. > Section 5.4, para 9. This paragraph gives a series of actions that are > described in the introductory material as "validation checks". However, > the first bullet is describing a renewal action, not a validation check. > I suggest that the phrase "The MASA validation checks before issuing a > voucher are as follows:" be replaced with "The MASA performs the > following actions and validation checks before issuing a voucher:" changed. > Section 5.8, para 2, line 1. "the following EST" (I have no idea where > these "following" items are. The subsequent subsections are clearly not > extensions, so I cannot determine what is being referenced here. Since > this is a "recommendation", it is important that it be clear to the > reader what is intended. Changed to: The Pledge is also RECOMMENDED to implement the EST automation extensions described below. They Max, I think that this is a "SHOULD" > Para 2. This paragraph is quite opaque to me. I cannot follow the > logic of the sequence of statements. Does the second sentence imply > "one-at-a-time" operation, or something else? In the third sentence, > requests will "look the same" as what? Each other, something else? I think that I don't know which paragraph you are referring to. > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Distinguished Professor Emeritus fax: +1 (514) 848-2830 Onward to your other editorial comments. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqEl30ACgkQgItw+93Q 3WWj1Af/X1J1iB/tOJ9WvgR5ACCR4u+G7tN2Urnq35qawtQdXKGU1kjKF+BdA7rh viFqAQn8SnXMYttJev/Ro5PJ+97glPi5N5WQUldWzrtcYgz1vtEBOkQdd9pMXBpb goaN5cjOYCsHyE2GCxynFGYkBXFsf5X25hv1J2xP43/qIXcsxZ0zpg3PeFdGno+c xYZN8nFQiQ14cQArQr54YHBCFig9fpHOxNtCGOqoO96uPUHjvkUTCTLhW0e4TmZk oQr/5QUWySXCez8afTnf7ZTvaITDVEzjAoM2cueb5ywab2H75B44X9nUjUsW7UB3 1MUpt1IMoqzC/yGzjQ13f/4EeHBcSg== =4N9Z -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 14 14:49:53 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F80B126B6E for ; Wed, 14 Feb 2018 14:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 cHQDuY8xUG5G for ; Wed, 14 Feb 2018 14:49:50 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB611201FA for ; Wed, 14 Feb 2018 14:49:49 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E25920090 for ; Wed, 14 Feb 2018 17:56:48 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1456880C86 for ; Wed, 14 Feb 2018 17:49:49 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: <1051ad5c-1bc7-5fda-2a32-ce65f19a47e3@concordia.ca> References: <1051ad5c-1bc7-5fda-2a32-ce65f19a47e3@concordia.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Technical comments on draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 22:49:51 -0000 --=-=-= Content-Type: text/plain William Atwood wrote: > As a result of trying to understand (and then to model) the protocol > flow for BRSKI, I have made a review of Bill also did an extensive grammar review, which was invaluable. The URL: https://goo.gl/pXNghv now shows all the changes as they are all pushed onto the same pull request. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqEvQwACgkQgItw+93Q 3WUF+wf/UtiYNA3yEKJRWmwXheYNJSBdyBGBX7KDdH7xM9Ri4PDb/Bb7cdV9eIjF nYvwe1nVIgvGyt/8hA/NadLC/AK6Y0wYqmQ4h4344vTKhs6QV8B8sJMOXrwrsYCA esf/7iNiAGAxdGDKvi/t6whHkcvqQ066DimvoEjPB7GP44FLZQapxP07iQL5FchY 7tXt+2pT6Vej21SKaEa1lN8l7X/5pR+sD40ule0DTJ3lNoYuCB1eNNH9v+BKHYp/ q1il5X/0mjMlRBjxx29GuiMj35bw6O+XpnyKCTmy60qJHMRIR5ET/m+8rRjh1pGD obhNETTY6KWXo/ti5nMNM5ZyEtiTow== =Nedn -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 14 15:14:39 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1988D1201FA for ; Wed, 14 Feb 2018 15:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiR3P9UWaund for ; Wed, 14 Feb 2018 15:14:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A8C127077 for ; Wed, 14 Feb 2018 15:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12826; q=dns/txt; s=iport; t=1518650070; x=1519859670; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=w1w6cU19RAet5ILJXMwQTYPAyR+GJMrW1NR40dpllqE=; b=K5SELLOlcOAGbaZTxxYdECs8aF4Pa77Km5lQbyes3nlgmQTEEElehm6O KnJ27zS2i4eNkMAfITVeufvmkTtJymbAVq4Dty4nLvfC1HaWhxvXpOmEE NIKJV3Um/u1x6NB7F8TcHZccQrssyW7AeGQspuiJWTCbGdTazmt253/GH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAwAuwoRa/5JdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDITFmcCgKg1uYKIFbJ3wbmFoKGAaBY4M6AhqCY1gUAQIBAQE?= =?us-ascii?q?BAQECayiFIwEBAQMBAQEhBA0zBQILBQsCAQYCGAICJgICAiULFRACBA4FG4oSC?= =?us-ascii?q?BCSBp10gW06hQGEBoITAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4NzghWDPyk?= =?us-ascii?q?MgkM2gy8BAQIZgUAWFwomglAxgjQFpC8JAogegztNiV2CH4Yqi3yOAolqAhEZA?= =?us-ascii?q?YE7ATYigVBwFRkkKgGCGx+EWHgBAQEVAQGLHSyBBoEZAQEB?= X-IronPort-AV: E=Sophos;i="5.46,514,1511827200"; d="scan'208";a="356196562" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 23:14:29 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w1ENET0r005273 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Feb 2018 23:14:29 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 14 Feb 2018 17:14:28 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Wed, 14 Feb 2018 17:14:28 -0600 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: William Atwood , "anima@ietf.org" Thread-Topic: [Anima] Technical comments on draft-ietf-anima-bootstrapping-keyinfra-09 Thread-Index: AQHTouT7lpq88kWZ3UuFcP4+XxfpX6OkvkEAgAAzqIA= Date: Wed, 14 Feb 2018 23:14:28 +0000 Message-ID: References: <1051ad5c-1bc7-5fda-2a32-ce65f19a47e3@concordia.ca> <14592.1518638974@obiwan.sandelman.ca> In-Reply-To: <14592.1518638974@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.5] Content-Type: text/plain; charset="utf-8" Content-ID: <6655CAACE745D74CA0C8E9A2D997330C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Technical comments on draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 23:14:37 -0000 DQpNdWNoIHRoYW5rcyBmb3IgTWljaGFlbCBSaWNoYXJkc29uIGZvciBwdXR0aW5nIHRoZXNlIGRp ZmZzIHRvZ2V0aGVyLiBDb21tZW50cyBpbmxpbmUsDQoNCg0KPiBPbiBGZWIgMTQsIDIwMTgsIGF0 IDE6MDkgUE0sIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90 ZToNCj4gDQo+IA0KPiB0bDpkcjogaHR0cHM6Ly9naXRodWIuY29tL2FuaW1hLXdnL2FuaW1hLWJv b3RzdHJhcC9wdWxsLzQxDQo+ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs MT1kcmFmdC1pZXRmLWFuaW1hLWJvb3RzdHJhcHBpbmcta2V5aW5mcmEtMTAmdXJsMj1odHRwczov L3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vYW5pbWEtd2cvYW5pbWEtYm9vdHN0cmFwL2JpbGwt YXR3b29kLWNvbW1lbnRzL2R0Ym9vdHN0cmFwLWFuaW1hLWtleWluZnJhLnR4dA0KPiAgICAgICAg b3I6IGh0dHBzOi8vZ29vLmdsL3BYTmdodg0KPiANCj4gDQo+IFdpbGxpYW0gQXR3b29kIDx3aWxs aWFtLmF0d29vZEBjb25jb3JkaWEuY2E+IHdyb3RlOg0KPj4gU2VjdGlvbiAxLCBwYXJhIDMsIGxp bmVzIDQtNS4gICJpcyBhIG1pbm9yIGV4dGVuc2lvbiB0byB0aGUgdm91Y2hlcg0KPj4gZm9ybWF0 IChzZWUgU2VjdGlvbiAzKS4iICBXaGF0ICJ2b3VjaGVyIGZvcm1hdCI/ICBJIGd1ZXNzIHRoYXQg eW91IG1lYW4NCj4+IHRoZSB2b3VjaGVyIGZvcm1hdCBkZWZpbmVkIGluIGRyYWZ0LWlldGYtYW5p bWEtdm91Y2hlci4gIEkgc3VnZ2VzdCBzb21lDQo+PiBhZGRpdGlvbmFsIHByZWNpc2lvbiBoZXJl Lg0KPiANCj4gQWRkZWQgYW5vdGhlciByZWZlcmVuY2UgdG8gYW5pbWEtdm91Y2hlciBkb2N1bWVu dCBhdCB0aGUgZW5kIG9mIHRoZSBwYXJhZ3JhcGguDQo+IA0KPj4gTGluZXMgNC01LiAgV2h5IGlz IHRoaXMgIm1pbm9yIGV4dGVuc2lvbiIgZGVmaW5lZCBoZXJlLCBhbmQgbm90IGluDQo+PiBkcmFm dC1pZXRmLWFuaW1hLXZvdWNoZXI/ICBXb3VsZCBpdCBub3QgYmUgYmV0dGVyIHRvIGhhdmUgYWxs IChjdXJyZW50bHkNCj4+IGtub3duKSB2b3VjaGVyIGZvcm1hdHMgaW4gb25lIHBsYWNlPw0KPiAN Cj4gTm8sIGJlY2F1c2UgYW5pbWEtdm91Y2hlciBpcyB1c2VkIGJ5IHRoZSBSRVNUQ09ORiB3b3Jr IGluIHRoZSBORVRDT05GIFdHLCBhbmQNCj4gdGhleSBoYXZlIG5vIHVzZSBmb3IgdGhlIHZvdWNo ZXItcmVxdWVzdC4NCj4gDQo+PiBTZWN0aW9uIDIuMywgcGFyYSAyLCBsaW5lIDEuICAicHJldmlv dXNseSBkZWZpbmVkIGZpZWxkcyIgIFdoZXJlIGFyZQ0KPj4gdGhlc2UgZGVmaW5lZD8gIEFyZSB0 aGV5IHByZXZpb3VzbHkgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50PyAgQXJlIHRoZXkNCj4+IHBy ZXZpb3VzbHkgZGVmaW5lZCBpbiBzb21lIG90aGVyIGRvY3VtZW50PyAgKElmIHNvLCBnaXZlIHJl ZmVyZW5jZS4pDQo+IA0KPj4gSW4gZ2VuZXJhbCwgdGhpcyBwYXJhZ3JhcGggYW5kIGl0cyB0d28g YnVsbGV0cyBtaWdodCBiZSB1bmRlcnN0YW5kYWJsZQ0KPj4gYnkgc29tZW9uZSB3aG8gaXMgd2Vs bCBmYW1pbGlhciB3aXRoIFguNTA5LCBidXQgdGhleSBhcmUgb3BhcXVlIHRvDQo+PiBzb21lb25l IHdobyBpcyBub3QgKGkuZS4sIHRoaXMgcmV2aWV3ZXIpLiAgSSBiZWxpZXZlIHRoYXQgeW91ciBt ZXNzYWdlDQo+IA0KPiBzbywgSSB0aGluayB0aGF0IHVuZGVyc3RhbmRpbmcgc29tZXRoaW5nIGFi b3V0IFBLSVggKFg1MDkpIGFuZCBFU1QgaXMNCj4gdW5hdm9pZGFibGUsIGFuZCBJIGRvbid0IHRo aW5rIHdlIHNob3VsZCBjbHV0dGVyIHRoZSBkb2N1bWVudCBleHBsYWluaW5nDQo+IHRob3NlIHBh cnRzLg0KPiANCj4+IFNlY3Rpb24gMi4zLCBwYXJhIDUsIGxpbmUgNC4gIEluIHRoaXMgZG9jdW1l bnQsIHRoZSBzdHJpbmcgIi53ZWxsLWtub3duIg0KPj4gYXBwZWFycyB2YXJpb3VzbHkgYXMgIi53 ZWxsLWtub3duIiwgIi4vd2VsbC1rbm93biIsIGFuZCAiLy53ZWxsLWtub3duIi4NCj4+IElmIHRo ZXNlIGFyZSBpbiBmYWN0IGludGVudGlvbmFsLCB0aGVuIHRoZSBkaWZmZXJlbmNlcyBzaG91bGQg YmUNCj4+IGV4cGxhaW5lZC4gIE90aGVyd2lzZSwgYSBjb25zaXN0ZW50IGZvcm0gc2hvdWxkIGJl IGVuc3VyZWQgdGhyb3VnaG91dA0KPj4gdGhlIGRvY3VtZW50LiAgR2l2ZW4gdGhhdCBJIGRvIG5v dCBrbm93IHdoYXQgaXMgY29ycmVjdCwgb3IgaWYgdGhleSBhcmUNCj4+IGludGVuZGVkIHRvIGJl IGRpZmZlcmVudCwgSSBoYXZlIG5vdCBzaWduYWxlZCB0aGVzZSBjYXNlcyBpbiBteSBHZW5lcmFs DQo+PiBDb21tZW50cy4gIFlvdSB3aWxsIGhhdmUgdG8gZG8gYSBzZWFyY2ggdG8gZGlzY292ZXIg YWxsIHRoZSBpbnN0YW5jZXMuDQo+IA0KPiAuL3dlbGwta25vd24gaXMgYSB0eXBvLiAgSSd2ZSBw dXQgLyBpbiBmcm9udCBvZiBldmVyeSB1c2UuDQo+IC8ud2VsbC1rbm93biByZWZlcnMgdG8gcmZj NTc4NS4NCj4gUkZDNzAzMCAoRVNUKSBhbGwgbGl2ZXMgdW5kZXIgLy53ZWxsLWtub3duL2VzdC4N Cj4gSSd2ZSBhZGRlZCBhIHJlZmVyZW5jZSB0byA1Nzg1IGF0IHRoZSBmaXJzdCB1c2Ugb2YgLy53 ZWxsLWtub3duLg0KPiANCj4+IFNlY3Rpb24gMi42LCBwYXJhIDEuICBJIGZpbmQgdGhpcyBlbnRp cmUgcGFyYWdyYXBoIHB1enpsaW5nLiAgSSBiZWxpZXZlDQo+PiB0aGF0IG1vcmUgdGV4dCBpcyBy ZXF1aXJlZCBoZXJlLCBpbiB0aGUgaG9wZSB0aGF0IHRoZSB1c2UgY2FzZXMgd2lsbCBiZQ0KPj4g Y2xlYXJlci4gIFBlcmhhcHMgdGhlIHVzZSBjYXNlcyBuZWVkIHRvIGJlIHN0YXRlZCBmaXJzdCwg Zm9sbG93ZWQgYnkgdGhlDQo+PiBhbGxvd2VkIGFjdGlvbnMuDQo+IA0KPiBNYXgsIEkgaGF2ZSBh ZGRlZCBhIHBhcmFncmFwaCB0byBleHBsYWluIHRoZSBsZWdhY3kgc2l0dWF0aW9uIHRoYXQgdGhl ICJDbG91ZA0KPiAgICAgICAgPHQ+DQo+ICAgICAgICAgIFRoZXJlIGFyZSB0cmFuc2l0aW9uYWwg c2l0dWF0aW9ucyB3aGVyZSBkZXZpY2VzIG1heSBiZQ0KPiAgICAgICAgICBkZXBsb3llZCBpbnRv IGxlZ2FjeSBuZXR3b3JrcyB0aGF0IHVzZSBwcm9wcmlldGFyeQ0KPiAgICAgICAgICBib290c3Ry YXBwaW5nIG1lY2hhbmlzbXMgYmFzZWQgdXBvbiB0aGUgYmFzZSBFU1QgKDx4cmVmDQo+ICAgICAg ICAgIHRhcmdldD0iUkZDNzAzMCIvPikuICBUaGUgc2FtZSBkZXZpY2UgbWF5IGFsc28gYmUgZGVw bG95ZWQNCj4gICAgICAgICAgaW50byBhbiBBTklNQSBlbnZpcm9ubWVudC4gIFRoaXMgbWF5IGJl IGR1ZSB0byBpbmNyZW1lbnRhbA0KPiAgICAgICAgICByZXBsYWNlbWVudCBvZiBhIGxlZ2FjeSBz aXR1YXRpb24gd2l0aCBBTklNQS4NCj4gICAgICAgIDwvdD4NCj4gICAgICAgIDx0Pg0KPiAgICAg ICAgICBUaGVyZSBhcmUgYWRkaXRpb25hbGx5IHNvbWUgZ3JlZW5maWVsZCBzaXR1YXRpb25zIGlu dm9sdmluZyBhbg0KPiAgICAgICAgICBlbnRpcmVseSBuZXcgaW5zdGFsbGF0aW9uIHdoZXJlIGEg ZGV2aWNlIG1heSBoYXZlIHNvbWUga2luZCBvZg0KPiAgICAgICAgICBtYW5hZ2VtZW50IHVwbGlu ayB0aGF0IGl0IGNhbiB1c2UgKHN1Y2ggYXMgdmlhIDNHIG5ldHdvcmsgZm9yDQo+ICAgICAgICAg IGluc3RhbmNlKS4gICBJbiBzdWNoIGEgZnV0dXJlIHNpdHVhdGlvbiwgdGhlIGRldmljZSBtaWdo dCB1c2UNCj4gICAgICAgICAgdGhpcyBtYW5hZ2VtZW50IGludGVyZmFjZSB0byBsZWFybiB0aGF0 IGl0IHNob3VsZA0KPiAgICAgICAgICBjb25maWd1cmUgaXRzZWxmIGJ5IHRvLWJlLWRldGVybWlu ZWQgbWVjaGFuaXNtIChzdWNoIGFzIGFuIEludGVudCkNCj4gICAgICAgICAgdG8gYmVjb21lIHRo ZSBsb2NhbCByZWdpc3RyYXIuDQo+ICAgICAgICA8L3Q+DQo+ICAgICAgICA8dD4NCj4gICAgICAg ICAgSW4gb3JkZXIgdG8gc3VwcG9ydCB0aGlzIHNjZW5hcmlvLCB0aGUgUGxlZGdlIE1BWSBjb250 YWN0IGEgd2VsbA0KPiAgICAgICAgICBrbm93biBVUkkgb2YgYSBjbG91ZCBSZWdpc3RyYXIgaWYg YQ0KDQpBIHNpbXBsZXIgY2FzZSBjb3VsZCBiZSwgDQoNCuKAnFRoZXJlIGV4aXN0IG9wZXJhdGlv bmFsbHkgb3BlbiBuZXR3b3JrIHdoZXJlaW4gZGV2aWNlIGdhaW5zIHVuYXV0aGVudGljYXRlZCBh Y2Nlc3MgdG8gdGhlIGludGVybmV0IGF0IGxhcmdlLiBJbiB0aGVzZSB1c2UgY2FzZXMgdGhlIG1h bmFnZW1lbnQgZG9tYWluIGZvciB0aGUgZGV2aWNlIG5lZWRzIHRvIGJlIGRpc2NvdmVyZWQgd2l0 aGluIHRoZSBsYXJnZXIgaW50ZXJuZXQuIFRoZXNlIGFyZSBsZXNzIGxpa2VseSB3aXRoaW4gdGhl IGFuaW1hIHNjb3BlIGJ1dCBtYXkgYmUgbW9yZSBpbXBvcnRhbnQgaW4gdGhlIGZ1dHVyZS4iDQoN CihJ4oCZdmUgYWRkZWQgdGhpcyBjb21tZW50IHdpdGhpbiBnaXRodWIgYXMgd2VsbCBpbiBwcmVw IGZvciB0aGUgcHVsbCByZXF1ZXN0KQ0KDQo+IA0KPj4gU2VjdGlvbiAzLCBwYXJhIDEsIGxpbmUg Ni4gIFdoYXQgaXMgdGhlIG1lYW5pbmcgb2YNCj4+ICcicHJveGltaXR5LXJlZ2lzdHJhci1jZXJ0 IiBsZWFmJz8gIFdoYXQgaXMgdGhlIGxlYWYgYSBsZWFmIG9mPyAgSWYgdGhpcw0KPj4gcmVmZXJz IHRvIHNvbWUgWUFORyBtb2R1bGUsIHBsZWFzZSBjaXRlIHRoZSBZQU5HIG1vZHVsZS4NCj4gDQo+ IFNvIHRoZSB0aXRsZSBvZiB0aGUgc2VjdGlvbiBpcyAiVm91Y2hlci1SZXF1ZXN0IGFydGlmYWN0 IiwgYW5kIHRoZSBlbnRpcmUNCj4gc2VjdGlvbiBpcyBhYm91dCB0aGUgWUFORyBtb2R1bGUgaWV0 Zi12b3VjaGVyLXJlcXVlc3QuICBJIGhhdmUgYWRkZWQgb25lDQo+IHBocmFzZTogImRlZmluZWQg aW4gdGhpcyBzZWN0aW9uIg0KPiANCj4+IFNlY3Rpb24gMy4yLCBFeGFtcGxlICgyKS4gIERvZXMg dGhpcyBleGFtcGxlIGlsbHVzdHJhdGUgX2FfIFJlZ2lzdHJhcg0KPj4gdm91Y2hlci1yZXF1ZXN0 LCBvciBkb2VzIGl0IGlsbHVzdHJhdGUgdGhlIFJlZ2lzdHJhciB2b3VjaGVyLXJlcXVlc3QNCj4+ IHRoYXQgd291bGQgYmUgdXNlZCB0byBmb3J3YXJkIEV4YW1wbGUgKDEpPyAgSWYgdGhlIGZvcm1l ciwgd2h5IGlzIHRoZQ0KPj4gbm9uY2UgaWRlbnRpY2FsPyAgSWYgdGhlIGxhdHRlciwgaXQgc2hv dWxkIGJlIGV4cGxhaW5lZCB0aGF0IGNlcnRhaW4NCj4+IG90aGVyIGZpZWxkcyBhcmUgY2Fycmll ZCBmb3J3YXJkIGFzIHdlbGwuDQo+IA0KPiBUaGUgbm9uY2UsIGNyZWF0ZWQtb24gYW5kIGFzc2Vy dGlvbiBhcmUgY2FycmllZCBmb3J3YXJkLg0KPiBJIGhhdmUgY2hhbmdlZCB0aGUgdGV4dCB0byBz YXk6DQo+IA0KPiAgICAgICAgICAgICAgICBUaGUgJ3ByaW9yLXNpZ25lZC12b3VjaGVyLXJlcXVl c3QnIGxlYWYgaXMgcG9wdWxhdGVkIHdpdGggdGhlIFBsZWRnZSdzDQo+ICAgICAgICAgICAgICAg IHZvdWNoZXItcmVxdWVzdCAoc3VjaCBhcyB0aGUgcHJpb3IgZXhhbXBsZSkuICBUaGUgcGxlZGdl J3MNCj4gICAgICAgICAgICAgICAgdm91Y2hlci1yZXF1ZXN0LCBpZiBhIHNpZ25lZCBhcnRpZmFj dCB3aXRoIGEgQ01TIGZvcm1hdA0KPiAgICAgICAgICAgICAgICBzaWduYXR1cmUgaXMgYSBiaW5h cnkgb2JqZWN0LiAgSW4gdGhlIEpTT04gZW5jb2RpbmcgdXNlZA0KPiAgICAgICAgICAgICAgICBo ZXJlIGl0IG11c3QgYmUgYmFzZTY0IGVuY29kZWQuIFRoZSBub25jZSwgY3JlYXRlZC1vbiBhbmQN Cj4gICAgICAgICAgICAgICAgYXNzZXJ0aW9uIGlzIGNhcnJpZWQgZm9yd2FyZC4gc2VyaWFsLW51 bWJlciBpcyBleHRyYWN0ZWQgZnJvbQ0KPiAgICAgICAgICAgICAgICB0aGUgcGxlZGdlJ3MgQ2xp ZW50IENlcnRpZmljYXRlIGZyb20gdGhlIFRMUyBjb25uZWN0aW9uLiBTZWUNCj4gICAgICAgICAg ICAgICAgPHhyZWYgdGFyZ2V0PSJSZXF1ZXN0Vm91Y2hlckZyb21NQVNBIi8+LjwvdD48L2xpc3Q+ PC90Pg0KPiANCj4gDQo+PiBTZWN0aW9uIDQuMSwgcGFyYSAyLCBidWxsZXQgMiwgbGluZSAzLiAg Im1heSIgLT4gIk1BWSIgIChUaGlzICJtYXkiDQo+PiBzZWVtcyB0byBiZSBub3JtYXRpdmUuKQ0K PiANCj4gWWVzLCB0aGFuayB5b3UuDQo+IA0KPj4gUGFyYSA3LCBsaW5lIDIuICAic2hvdWxkIiAt PiAiU0hPVUxEIg0KPiANCj4gZG9uZS4NCj4gDQo+PiBTZWN0aW9uIDUsIHBhcmEgOCwgYnVsbGV0 IDEuICBUaGUgcmVmZXJlbmNlIHRvIFJGQzYxMjUgYXBwZWFycyB0byBiZQ0KPj4gbm9ybWF0aXZl LCBhbmQgc28gUkZDIDYxMjUgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBsaXN0IG9mIChub3JtYXRp dmUpDQo+PiByZWZlcmVuY2VzLg0KPiANCj4gQWRkZWQuDQo+IA0KPj4gU2VjdGlvbiA1LjQsIHBh cmEgOS4gIFRoaXMgcGFyYWdyYXBoIGdpdmVzIGEgc2VyaWVzIG9mIGFjdGlvbnMgdGhhdCBhcmUN Cj4+IGRlc2NyaWJlZCBpbiB0aGUgaW50cm9kdWN0b3J5IG1hdGVyaWFsIGFzICJ2YWxpZGF0aW9u IGNoZWNrcyIuICBIb3dldmVyLA0KPj4gdGhlIGZpcnN0IGJ1bGxldCBpcyBkZXNjcmliaW5nIGEg cmVuZXdhbCBhY3Rpb24sIG5vdCBhIHZhbGlkYXRpb24gY2hlY2suDQo+PiBJIHN1Z2dlc3QgdGhh dCB0aGUgcGhyYXNlICJUaGUgTUFTQSB2YWxpZGF0aW9uIGNoZWNrcyBiZWZvcmUgaXNzdWluZyBh DQo+PiB2b3VjaGVyIGFyZSBhcyBmb2xsb3dzOiIgYmUgcmVwbGFjZWQgd2l0aCAiVGhlIE1BU0Eg cGVyZm9ybXMgdGhlDQo+PiBmb2xsb3dpbmcgYWN0aW9ucyBhbmQgdmFsaWRhdGlvbiBjaGVja3Mg YmVmb3JlIGlzc3VpbmcgYSB2b3VjaGVyOiINCj4gDQo+IGNoYW5nZWQuDQo+IA0KPj4gU2VjdGlv biA1LjgsIHBhcmEgMiwgbGluZSAxLiAgInRoZSBmb2xsb3dpbmcgRVNUIiAgKEkgaGF2ZSBubyBp ZGVhIHdoZXJlDQo+PiB0aGVzZSAiZm9sbG93aW5nIiBpdGVtcyBhcmUuICBUaGUgc3Vic2VxdWVu dCBzdWJzZWN0aW9ucyBhcmUgY2xlYXJseSBub3QNCj4+IGV4dGVuc2lvbnMsIHNvIEkgY2Fubm90 IGRldGVybWluZSB3aGF0IGlzIGJlaW5nIHJlZmVyZW5jZWQgaGVyZS4gIFNpbmNlDQo+PiB0aGlz IGlzIGEgInJlY29tbWVuZGF0aW9uIiwgaXQgaXMgaW1wb3J0YW50IHRoYXQgaXQgYmUgY2xlYXIg dG8gdGhlDQo+PiByZWFkZXIgd2hhdCBpcyBpbnRlbmRlZC4NCj4gDQo+IENoYW5nZWQgdG86DQo+ ICAgICAgICA8dD5UaGUgUGxlZGdlIGlzIGFsc28gUkVDT01NRU5ERUQgdG8gaW1wbGVtZW50IHRo ZSBFU1QgYXV0b21hdGlvbg0KPiAgICAgICAgZXh0ZW5zaW9ucyBkZXNjcmliZWQgYmVsb3cuIFRo ZXkNCj4gDQo+IE1heCwgSSB0aGluayB0aGF0IHRoaXMgaXMgYSDigJxTSE9VTEQiDQoNClJGQzIx MTkgaW5kaWNhdGVzIHRoZXNlIGFyZSBlcXVpdmFsZW50LiBJIGJvdyB0byB5b3VyIHNlbnNlIG9m IGdyYW1tYXIgb24gdGhpcy4gVXNlIG9mIFNIT1VMRCBpcyBjbGVhcmVyOg0KIlRoZSBQbGVkZ2Ug U0hPVUxEIGltcGxlbWVudOKApuKAnQ0KDQo+IA0KPj4gUGFyYSAyLiAgVGhpcyBwYXJhZ3JhcGgg aXMgcXVpdGUgb3BhcXVlIHRvIG1lLiAgSSBjYW5ub3QgZm9sbG93IHRoZQ0KPj4gbG9naWMgb2Yg dGhlIHNlcXVlbmNlIG9mIHN0YXRlbWVudHMuICBEb2VzIHRoZSBzZWNvbmQgc2VudGVuY2UgaW1w bHkNCj4+ICJvbmUtYXQtYS10aW1lIiBvcGVyYXRpb24sIG9yIHNvbWV0aGluZyBlbHNlPyAgSW4g dGhlIHRoaXJkIHNlbnRlbmNlLA0KPj4gcmVxdWVzdHMgd2lsbCAibG9vayB0aGUgc2FtZSIgYXMg d2hhdD8gIEVhY2ggb3RoZXIsIHNvbWV0aGluZyBlbHNlPw0KPiANCj4gSSB0aGluayB0aGF0IEkg ZG9uJ3Qga25vdyB3aGljaCBwYXJhZ3JhcGggeW91IGFyZSByZWZlcnJpbmcgdG8uDQoNClRoaXMg aXMgdGhlIHBhcmEgaW4gcXVlc3Rpb246DQogICAgICAgICAgQWx0aG91Z2ggRVNUIGFsbG93cyBj bGllbnRzIHRvIG9idGFpbiBtdWx0aXBsZSBjZXJ0aWZpY2F0ZXMgYnkgc2VuZGluZw0KICAgICAg ICAgIG11bHRpcGxlIENTUiByZXF1ZXN0cyBCUlNLSSBtYW5kYXRlcyB1c2Ugb2YgdGhlIENTUiBB dHRyaWJ1dGVzIHJlcXVlc3QNCiAgICAgICAgICBhbmQgbWFuZGF0ZXMgdGhhdCB0aGUgUmVnaXN0 cmFyIHZhbGlkYXRlIHRoZSBDU1IgYWdhaW5zdCB0aGUgZXhwZWN0ZWQNCiAgICAgICAgICBhdHRy aWJ1dGVzLiBUaGlzIGltcGxpZXMgdGhhdCBjbGllbnQgcmVxdWVzdHMgd2lsbCAibG9vayB0aGUg c2FtZeKAnSDigKYNCg0KVGhlIHBvaW50IGhlcmUgaXMgdGhhdCBpZiB0aGUgY2xpZW50IGRvZXMg Q1NSIEF0dHJpYnV0ZXMgYW5kIHRoZSDigJxSZWdpc3RyYXIgdmFsaWRhdGVbc10gdGhlIENTUiBh Z2FpbnN0IHRoZSBleHBlY3RlZCBhdHRyaWJ1dGVz4oCdIHRoZW4gaXQgaXMgbm90IHBvc3NpYmxl IHRvIGxldmVyYWdlIHRoaXMgc3BlY2lmaWMgY29ubmVjdGlvbiB0byByZXF1ZXN0IG11bHRpcGxl IGRpZmZlcmVudCBjbGllbnQgY2VydGlmaWNhdGVzIChiZWNhdXNlIG9mIHRoZSBhYm92ZSByZXF1 aXJlbWVudHMpLiBBcyBhIHJlc3VsdCBhIEJSU0tJIGluaXRpYXRlZCBFU1QgY29ubmVjdGlvbiB3 aWxsIHJlc3VsdCBpbiBhIHNpbmdsZSBjbGllbnQgY2VydGlmaWNhdGUuIElmIHRoZSBhYm92ZSBp cyBmb2xsb3dlZCBhbmQgZXhwZWN0ZWQgZXZlcnkgcmVxdWVzdCBmcm9tIHRoZSBjbGllbnQgdG8g dGhlIHNlcnZlciDigJh3aWxsIGxvb2sgdGhlIHNhbWXigJkgYW5kIGV2ZXJ5IGNlcnRpZmljYXRl IGlzc3VlZCB3aWxsIGxvb2sgdGhlIHNhbWUuIA0KDQpTb2x1dGlvbnMgd291bGQgaW5jbHVkZTog dGVhcmluZyBkb3duIHRoZSBzZXNzaW9uIGFuZCBzdGFydGluZyBhIG5ldyBFU1Qgc2Vzc2lvbiB0 byBvYnRhaW4gbW9yZSBjb21wbGV4IGNlcnRzIGZvciBvdGhlciwgbm9uLWFuaW1hLCBwdXJwb3Nl cy4gT3IgZXhwYW5kaW5nIG9uIHRoZSBDU1JBdHRyaWJ1dGVzIGFuZCB2YWxpZGF0aW9uIGxvZ2lj IHRvIGFsbG93IGZvciBtdWx0aXBsZSBjZXJ0cy4gTm9uZSBvZiB3aGljaCBhcmUgbmVjZXNzYXJ5 IGZvciBhbmltYS4gDQoNCi0gbWF4DQoNCg0KPiANCj4gDQo+PiBEci4gSi5XLiBBdHdvb2QsIEVu Zy4gICAgICAgICAgICAgdGVsOiAgICsxICg1MTQpIDg0OC0yNDI0IHgzMDQ2DQo+PiBEaXN0aW5n dWlzaGVkIFByb2Zlc3NvciBFbWVyaXR1cyAgZmF4OiAgICsxICg1MTQpIDg0OC0yODMwDQo+IA0K PiBPbndhcmQgdG8geW91ciBvdGhlciBlZGl0b3JpYWwgY29tbWVudHMuDQo+IA0KPiAtLQ0KPiBN aWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0 d2FyZSBXb3Jrcw0KPiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+IA0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFuaW1hIG1h aWxpbmcgbGlzdA0KPiBBbmltYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FuaW1hDQoNCg== From nobody Wed Feb 14 18:45:36 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A117012D867 for ; Wed, 14 Feb 2018 18:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5LVFHLaSl9AO for ; Wed, 14 Feb 2018 18:45:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADD0126C25 for ; Wed, 14 Feb 2018 18:45:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D56AE20090 for ; Wed, 14 Feb 2018 21:52:29 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3A71980A6D for ; Wed, 14 Feb 2018 21:45:30 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 02:45:35 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > 1.2) Terminology: > a) vendor vs. manufacturer. > The document uses 48 times "vendor" and 13 times "manufacturer". Please > revisit this: If there is a clear reason when/why to use vendor and when/why > to use the term "manufacturer", then please put these explanations into > terminology. Otherwise maybe eliminate "vendor". Ha. Good catch. I'm pretty sure we want to say manufacturer consistently. The IETF has often talked about vendors rather than manufacturers, so this might cause some confusion. Let's go ahead with this and see what confusion we cause. There is a distinction between vendor (which generally includes VARs) and OEMs. > For example: Abstract: "using vendor installed X.509 certificate" ... > "vendor's authorizing service". This latter one definitely seems to be > wrong (MASA = "manufacturer authorizied..., not vendor). I've also condensed a number of cases like you noticed: "vendor authorized MASA service" ==> MASA I am concerned that we might lose some subtly between the entity that sold the device to the customer, and the entity that signs the vouchers. We used the term MASA specifically because we were sure that the service would be outsourced by many manufacturers. > b) Key infrastructure > There is no definition/reference for this term. Please describe on > first use and in terminology. Is there a difference > between "key infrastructure" and "keying material" ? If not, then > maybe remove one term otherwise pls. describe difference. The term is in the title and in section 1. And you are right that it does not appear again, nor is it defined. I think it generally refers to the mechanism of PKI, but I'm not sure what to do. > c) (terminology) MASA definition: "A third-party Manufacturer...". Why "third-party" ? > who are the first two parties ? If this is only slang and we can't explain who the > first two parties are, delete "third-party" ? Fixed... The first party is the Pledge and manufacturer. The second party is the Domain Owner. The third party is the entity running the MASA, which may not be the manufacturer. > d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because the text mostly > uses "Domain Registrar" and very seldom "Join Registar". Yes, because we agreed that the term across WGs would be JRC, and we say in the terminology that we shorten it to Registrar. We say "Domain Registrar" because we want to link it to the PKI concept of a Registration Authority (RA). > JRC is used in exactly three places in the draft. I also can not find on www.google.com > or wikipedia any example of "The term JRC is used in common with other bootstrap > mechanisms" as the Terminology claims. Either provide a non-anima reference for the > use of that term or eliminate it in the document. We agreed to use common terms. It was a thread on ANIMA and 6tisch a year ago. I can't get mailarchive to find it for me... Ah, I see because "JRC" was never used contracted in that thread. https://mailarchive.ietf.org/arch/msg/anima/iotBM0-kxsIB66t8hBo4XUtZLag As long as they Informative references. https://tools.ietf.org/html/draft-ietf-6tisch-architecture-13#section-6.1 https://tools.ietf.org/html/draft-ietf-6tisch-terminology-09 (yes, expired, but not forgotten, just not a priority) > e) Voucher > - misses ":" after term. > - please change "statement" to "artifact" so the terminology aligns with both voucher > draft and voucher-request text which also uses artifact. See also section 2.2 > where you use "cryptographically protected" instead of "signed" and figure out > which term you want to use in all cases (hint: signed). I've changed it to: A voucher is a cryptographically protected artifact (a digital signature) to the Pledge I feel that we need to say it's cryptographically signed at least once. > f) IMPORTANT: Please add/define the term "ANI" > ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and > Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI > systems (pledges, proxies, registrar) have specific requirements detailled in > the document. The Autonomic Network Infrastructure as defined by . This document details specific requirements for pledges, proxies and registrars when they are part of an ANI. Does this work for you? > Without this term we can not nail down the explicit requirements against > ANI Pledges, Proxies, Registrars that we need from the document (and distinguish > from requirements against any non-ANI adaptation of BRSKI). I added according > comments into other parts of the doc. > g) Please replace "MASA server" with "MASA service" everywhere. I prefer to just say "MASA" actually. Are you okay with that? Let me wrap up here for the moment so you can see the edits and I'll reply to the rest as Max and I digest it. It's a lot of comments. I'd like to push an -11 (if only to fix email for M. Behringer). https://github.com/anima-wg/anima-bootstrap/pull/42 https://github.com/anima-wg/anima-bootstrap/pull/42/commits/cb7af66344ad709aaf70287a40fa13a67bbf601c -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqE9EkACgkQgItw+93Q 3WVOLQf/V+/J/I+0DQsT0NwnBrhTJRDNRoQwwI+xJOljOy6jQoKTOq82CY9wHUDu VTZJ6Ui2HtlcM8E9/8TWtFHZtYCZEOVMLH0vFdAGYB8FKH8SU5thVjgNQ/vfdjp0 VsYxPviHlWxbSZACD/rGmBrhWiXsUbb43uydqarHubesa2pap7i+7xuWr+q66isy dImvKyPSQzOwZ5jkDIMIokBatLwhHE6BVOlobbhe5nNFqRLv7lgWrmQLgmsXjihf TL31sBvjd2Df2OUJhvejAy7GBxTfXIi6Caw7gtdDfGTsEuM8EndI9SI1qjwOJyVZ i5b5wPpkyWNAXRneCjR0J1ZUdapFog== =CbzD -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 15 08:06:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00663126B7E for ; Thu, 15 Feb 2018 08:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 B6APWZcAPz3o for ; Thu, 15 Feb 2018 08:06:40 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A59E124C27 for ; Thu, 15 Feb 2018 08:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8860; q=dns/txt; s=iport; t=1518710800; x=1519920400; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+cvUlhK7tjQE2J7LtSQ9uDhCROPKxonDGMXFKpGDLGU=; b=dK0VjRzjoqlyHqieTEN8TYYqTc8HDErgewYpDjEZHDdm8+SPQJ8IHmP6 /pfL+lCQam7h5pCRWN1MjDMBl7hrMNixb7u5CzA3TJuWhwRhpz1bfQI9l 3d3UDDcWkwcGmnTODbp8JaBkirtMQXxkQ8l1iZu8tyKKAoFzcr/m0bvkx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAgCxr4Va/4sNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNSZnAoCoNbmCmCAnwblkUVgSQDXAoYDYFcgzoCGoIoVRc?= =?us-ascii?q?BAgEBAQEBAQJrKIUjAQEBAwEBASERFSULBQsCAQgSBgICJgICAiULFQIOAgQ?= =?us-ascii?q?OBYotCBCuN4InhQGDe4ITAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPg3SCJ4M?= =?us-ascii?q?/KYJPNoMvAQECAYE7ARIBCRaDFzGCNAWKZBeJSo9tCQKIHo1lgh+GKot9jgW?= =?us-ascii?q?JagIRGQGBOwEhATYyLnFwFRkkKgGCGwmEbngBCYt1gSWBGQEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,517,1511827200"; d="scan'208";a="356262068" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 16:06:34 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w1FG6Yux016442 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2018 16:06:34 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Feb 2018 10:06:33 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Thu, 15 Feb 2018 10:06:33 -0600 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: "anima@ietf.org" Thread-Topic: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 Thread-Index: AQHTpgcblAy+qFNx50mP05nV7UQFlKOmBmyA Date: Thu, 15 Feb 2018 16:06:33 +0000 Message-ID: <89C98637-ACD2-423A-A8C4-52191C35FA53@cisco.com> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <11878.1518662730@obiwan.sandelman.ca> In-Reply-To: <11878.1518662730@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.5] Content-Type: text/plain; charset="utf-8" Content-ID: <66FD0F982A888F439DFE735FF1DD7347@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 16:06:43 -0000 DQoNCj4gT24gRmViIDE0LCAyMDE4LCBhdCA3OjQ1IFBNLCBNaWNoYWVsIFJpY2hhcmRzb24gPG1j citpZXRmQHNhbmRlbG1hbi5jYT4gd3JvdGU6DQo+IA0KPiANCj4gVG9lcmxlc3MgRWNrZXJ0IDx0 dGVAY3MuZmF1LmRlPiB3cm90ZToNCj4+IDEuMikgVGVybWlub2xvZ3k6DQo+IA0KPj4gYSkgdmVu ZG9yIHZzLiBtYW51ZmFjdHVyZXIuDQo+IA0KPj4gVGhlIGRvY3VtZW50IHVzZXMgNDggdGltZXMg InZlbmRvciIgYW5kIDEzIHRpbWVzICJtYW51ZmFjdHVyZXIiLiBQbGVhc2UNCj4+IHJldmlzaXQg dGhpczogSWYgdGhlcmUgaXMgYSBjbGVhciByZWFzb24gd2hlbi93aHkgdG8gdXNlIHZlbmRvciBh bmQgd2hlbi93aHkNCj4+IHRvIHVzZSB0aGUgdGVybSAibWFudWZhY3R1cmVyIiwgdGhlbiBwbGVh c2UgcHV0IHRoZXNlIGV4cGxhbmF0aW9ucyBpbnRvDQo+PiB0ZXJtaW5vbG9neS4gT3RoZXJ3aXNl IG1heWJlIGVsaW1pbmF0ZSAidmVuZG9yIi4NCj4gDQo+IEhhLiBHb29kIGNhdGNoLg0KPiBJJ20g cHJldHR5IHN1cmUgd2Ugd2FudCB0byBzYXkgbWFudWZhY3R1cmVyIGNvbnNpc3RlbnRseS4NCj4g VGhlIElFVEYgaGFzIG9mdGVuIHRhbGtlZCBhYm91dCB2ZW5kb3JzIHJhdGhlciB0aGFuIG1hbnVm YWN0dXJlcnMsIHNvIHRoaXMNCj4gbWlnaHQgY2F1c2Ugc29tZSBjb25mdXNpb24uICBMZXQncyBn byBhaGVhZCB3aXRoIHRoaXMgYW5kIHNlZSB3aGF0IGNvbmZ1c2lvbg0KPiB3ZSBjYXVzZS4NCj4g DQo+IFRoZXJlIGlzIGEgZGlzdGluY3Rpb24gYmV0d2VlbiB2ZW5kb3IgKHdoaWNoIGdlbmVyYWxs eSBpbmNsdWRlcyBWQVJzKSBhbmQNCj4gT0VNcy4NCj4gDQo+PiBGb3IgZXhhbXBsZTogQWJzdHJh Y3Q6ICJ1c2luZyB2ZW5kb3IgaW5zdGFsbGVkIFguNTA5IGNlcnRpZmljYXRlIiAuLi4NCj4+ICJ2 ZW5kb3IncyBhdXRob3JpemluZyBzZXJ2aWNlIi4gVGhpcyBsYXR0ZXIgb25lIGRlZmluaXRlbHkg c2VlbXMgdG8gYmUNCj4+IHdyb25nIChNQVNBID0gIm1hbnVmYWN0dXJlciBhdXRob3JpemllZC4u Liwgbm90IHZlbmRvcikuDQo+IA0KPiBJJ3ZlIGFsc28gY29uZGVuc2VkIGEgbnVtYmVyIG9mIGNh c2VzIGxpa2UgeW91IG5vdGljZWQ6DQo+ICAgICAidmVuZG9yIGF1dGhvcml6ZWQgTUFTQSBzZXJ2 aWNlIiAgPT0+IE1BU0ENCj4gDQo+IEkgYW0gY29uY2VybmVkIHRoYXQgd2UgbWlnaHQgbG9zZSBz b21lIHN1YnRseSBiZXR3ZWVuIHRoZSBlbnRpdHkgdGhhdCBzb2xkDQo+IHRoZSBkZXZpY2UgdG8g dGhlIGN1c3RvbWVyLCBhbmQgdGhlIGVudGl0eSB0aGF0IHNpZ25zIHRoZSB2b3VjaGVycy4NCj4g V2UgdXNlZCB0aGUgdGVybSBNQVNBIHNwZWNpZmljYWxseSBiZWNhdXNlIHdlIHdlcmUgc3VyZSB0 aGF0IHRoZSBzZXJ2aWNlDQo+IHdvdWxkIGJlIG91dHNvdXJjZWQgYnkgbWFueSBtYW51ZmFjdHVy ZXJzLg0KPiANCj4+IGIpICBLZXkgaW5mcmFzdHJ1Y3R1cmUNCj4gDQo+PiBUaGVyZSAgaXMgbm8g ZGVmaW5pdGlvbi9yZWZlcmVuY2UgZm9yIHRoaXMgdGVybS4gIFBsZWFzZSBkZXNjcmliZSBvbg0K Pj4gZmlyc3QgdXNlIGFuZCBpbiB0ZXJtaW5vbG9neS4gIElzIHRoZXJlIGEgZGlmZmVyZW5jZQ0K Pj4gYmV0d2VlbiAia2V5IGluZnJhc3RydWN0dXJlIiBhbmQgICJrZXlpbmcgbWF0ZXJpYWwiID8g SWYgbm90LCB0aGVuDQo+PiBtYXliZSByZW1vdmUgb25lIHRlcm0gb3RoZXJ3aXNlIHBscy4gZGVz Y3JpYmUgZGlmZmVyZW5jZS4NCj4gDQo+IFRoZSB0ZXJtIGlzIGluIHRoZSB0aXRsZSBhbmQgaW4g c2VjdGlvbiAxLg0KPiBBbmQgeW91IGFyZSByaWdodCB0aGF0IGl0IGRvZXMgbm90IGFwcGVhciBh Z2Fpbiwgbm9yIGlzIGl0IGRlZmluZWQuDQo+IEkgdGhpbmsgaXQgZ2VuZXJhbGx5IHJlZmVycyB0 byB0aGUgbWVjaGFuaXNtIG9mIFBLSSwgYnV0IEknbSBub3Qgc3VyZSB3aGF0IHRvIGRvLg0KDQpB biDigJxpbmZyYXN0cnVjdHVyZeKAnSBpcyB0aGUgYmFzaWMgZW50aXRpZXMgYW5kIHByb3RvY29s cyBuZWNlc3NhcnkgZm9yIHRoZSBvcGVyYXRpb25zIG9mIGtleSBtYW5hZ2VtZW50LiBJIHRoaW5r IGl0IGNvbWVzIGZyb20gdGhlIGNvbW1vbiBsYW5ndWFnZSB0ZXJtIGFuZCBjYW7igJl0IGZpbmQg YSBub3JtYXRpdmUgZGVmaW5pdGlvbiB3aXRoaW4gSUVURiBkb2N1bWVudC4gQXMgYSBuYXRpdmUg ZW5nbGlzaCBzcGVha2VyIHdobyBoYXMgdXNlZCB0aGUgY29uY2VwdCBpbiBJRVRGIGludGVyYWN0 aW9ucyBmb3IgZW9ucyBpdCBmZWVscyBzaWxseSB0byB0cnkgYW5kIGRlZmluZSBpdC4gT2RkLiAN Cg0KS2V5IG1hbmFnZW1lbnQgaXRzZWxmIGlzIGRlZmluZWQgaW4gUkZDNDk0OSwgYWx0aG91Z2gg aXJvbmljYWxseSBhIOKAnHB1YmxpYyBrZXkgaW5mcmFzdHJ1Y3R1cmXigJ0gb3Ig4oCca2V5IGlu ZnJhc3RydWN0dXJl4oCdIGlzIG5vdCBkZWZpbmVkLiANCg0KIktleWluZyBtYXRlcmlhbCIgaXMg ZGVmaW5lZCBpbiBSRkM0OTQ5Lg0KDQotIG1heA0KDQo+IA0KPj4gYykgKHRlcm1pbm9sb2d5KSBN QVNBIGRlZmluaXRpb246ICJBIHRoaXJkLXBhcnR5IE1hbnVmYWN0dXJlci4uLiIuIFdoeSAidGhp cmQtcGFydHkiID8NCj4+IHdobyBhcmUgdGhlIGZpcnN0IHR3byBwYXJ0aWVzID8gSWYgdGhpcyBp cyBvbmx5IHNsYW5nIGFuZCB3ZSBjYW4ndCBleHBsYWluIHdobyB0aGUNCj4+IGZpcnN0IHR3byBw YXJ0aWVzIGFyZSwgZGVsZXRlICJ0aGlyZC1wYXJ0eSIgPw0KPiANCj4gRml4ZWQuLi4gIFRoZSBm aXJzdCBwYXJ0eSBpcyB0aGUgUGxlZGdlIGFuZCBtYW51ZmFjdHVyZXIuDQo+IFRoZSBzZWNvbmQg cGFydHkgaXMgdGhlIERvbWFpbiBPd25lci4NCj4gVGhlIHRoaXJkIHBhcnR5IGlzIHRoZSBlbnRp dHkgcnVubmluZyB0aGUgTUFTQSwgd2hpY2ggbWF5IG5vdCBiZSB0aGUgbWFudWZhY3R1cmVyLg0K PiANCj4+IGQpICJEb21haW4gUmVnaXN0cmFyIiB2cy4gIkpvaW4gUmVnaXN0cmFyIiwgSlJDLiBF c3BlY2lhbGx5IGJlY2F1c2UgdGhlIHRleHQgbW9zdGx5DQo+PiB1c2VzICJEb21haW4gUmVnaXN0 cmFyIiBhbmQgdmVyeSBzZWxkb20gIkpvaW4gUmVnaXN0YXIiLg0KPiANCj4gWWVzLCBiZWNhdXNl IHdlIGFncmVlZCB0aGF0IHRoZSB0ZXJtIGFjcm9zcyBXR3Mgd291bGQgYmUgSlJDLCBhbmQgd2Ug c2F5DQo+IGluIHRoZSB0ZXJtaW5vbG9neSB0aGF0IHdlIHNob3J0ZW4gaXQgdG8gUmVnaXN0cmFy LiAgV2Ugc2F5ICJEb21haW4NCj4gUmVnaXN0cmFyIiBiZWNhdXNlIHdlIHdhbnQgdG8gbGluayBp dCB0byB0aGUgUEtJIGNvbmNlcHQgb2YgYSBSZWdpc3RyYXRpb24NCj4gQXV0aG9yaXR5IChSQSku DQo+IA0KPj4gSlJDIGlzIHVzZWQgaW4gZXhhY3RseSB0aHJlZSBwbGFjZXMgaW4gdGhlIGRyYWZ0 LiBJIGFsc28gY2FuIG5vdCBmaW5kIG9uIHd3dy5nb29nbGUuY29tDQo+PiBvciB3aWtpcGVkaWEg YW55IGV4YW1wbGUgb2YgIlRoZSB0ZXJtIEpSQyBpcyB1c2VkIGluIGNvbW1vbiB3aXRoIG90aGVy IGJvb3RzdHJhcA0KPj4gbWVjaGFuaXNtcyIgYXMgdGhlIFRlcm1pbm9sb2d5IGNsYWltcy4gRWl0 aGVyIHByb3ZpZGUgYSBub24tYW5pbWEgcmVmZXJlbmNlIGZvciB0aGUNCj4+IHVzZSBvZiB0aGF0 IHRlcm0gb3IgZWxpbWluYXRlIGl0IGluIHRoZSBkb2N1bWVudC4NCj4gDQo+IFdlIGFncmVlZCB0 byB1c2UgY29tbW9uIHRlcm1zLg0KPiBJdCB3YXMgYSB0aHJlYWQgb24gQU5JTUEgYW5kIDZ0aXNj aCBhIHllYXIgYWdvLg0KPiBJIGNhbid0IGdldCBtYWlsYXJjaGl2ZSB0byBmaW5kIGl0IGZvciBt ZS4uLg0KPiBBaCwgSSBzZWUgYmVjYXVzZSAiSlJDIiB3YXMgbmV2ZXIgdXNlZCBjb250cmFjdGVk IGluIHRoYXQgdGhyZWFkLg0KPiAgICBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL2FuaW1hL2lvdEJNMC1reHNJQjY2dDhoQm80WFV0WkxhZw0KPiANCj4gQXMgbG9uZyBhcyB0 aGV5IEluZm9ybWF0aXZlIHJlZmVyZW5jZXMuDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLTZ0aXNjaC1hcmNoaXRlY3R1cmUtMTMjc2VjdGlvbi02LjENCj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNnRpc2NoLXRlcm1pbm9sb2d5LTA5DQo+ ICAgICAgICAoeWVzLCBleHBpcmVkLCBidXQgbm90IGZvcmdvdHRlbiwganVzdCBub3QgYSBwcmlv cml0eSkNCj4gDQo+PiBlKSBWb3VjaGVyDQo+PiAtIG1pc3NlcyAiOiIgYWZ0ZXIgdGVybS4NCj4+ IC0gcGxlYXNlIGNoYW5nZSAic3RhdGVtZW50IiB0byAiYXJ0aWZhY3QiIHNvIHRoZSB0ZXJtaW5v bG9neSBhbGlnbnMgd2l0aCBib3RoIHZvdWNoZXINCj4+IGRyYWZ0IGFuZCB2b3VjaGVyLXJlcXVl c3QgdGV4dCB3aGljaCBhbHNvIHVzZXMgYXJ0aWZhY3QuIFNlZSBhbHNvIHNlY3Rpb24gMi4yDQo+ PiB3aGVyZSB5b3UgdXNlICJjcnlwdG9ncmFwaGljYWxseSBwcm90ZWN0ZWQiIGluc3RlYWQgb2Yg InNpZ25lZCIgYW5kIGZpZ3VyZSBvdXQNCj4+IHdoaWNoIHRlcm0geW91IHdhbnQgdG8gdXNlIGlu IGFsbCBjYXNlcyAoaGludDogc2lnbmVkKS4NCj4gDQo+IEkndmUgY2hhbmdlZCBpdCB0bzoNCj4g IDx0PkEgdm91Y2hlciBpcyBhIGNyeXB0b2dyYXBoaWNhbGx5IHByb3RlY3RlZCBhcnRpZmFjdCAo YSBkaWdpdGFsIHNpZ25hdHVyZSkgdG8gdGhlIFBsZWRnZQ0KPiANCj4gSSBmZWVsIHRoYXQgd2Ug bmVlZCB0byBzYXkgaXQncyBjcnlwdG9ncmFwaGljYWxseSBzaWduZWQgYXQgbGVhc3Qgb25jZS4N Cj4gDQo+PiBmKSBJTVBPUlRBTlQ6IFBsZWFzZSBhZGQvZGVmaW5lIHRoZSB0ZXJtICJBTkkiDQo+ IA0KPj4gQU5JIC0gIkF1dG9ub21pYyBOZXR3b3JrIEluZnJhc3RydWN0dXJlIi4gU3lzdGVtcyB0 aGF0IHN1cHBvcnQgYm90aCBCUlNLSSBhbmQNCj4+IEF1dG9ub21pYyBDb250cm9sIHBsYW5lIC0g QUNQIChbSS1ELmlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmVdKS4gQU5JDQo+PiBz eXN0ZW1zIChwbGVkZ2VzLCBwcm94aWVzLCByZWdpc3RyYXIpIGhhdmUgc3BlY2lmaWMgcmVxdWly ZW1lbnRzIGRldGFpbGxlZCBpbg0KPj4gdGhlIGRvY3VtZW50Lg0KPiANCj4gICAgICAgICAgICA8 dCBoYW5nVGV4dD0iQU5JOiI+VGhlIEF1dG9ub21pYyBOZXR3b3JrIEluZnJhc3RydWN0dXJlIGFz DQo+ICAgICAgICAgICAgZGVmaW5lZCBieSA8eHJlZiB0YXJnZXQ9IkktRC5pZXRmLWFuaW1hLWF1 dG9ub21pYy1jb250cm9sLXBsYW5lIg0KPiAgICAgICAgICAgIC8+LiAgVGhpcyBkb2N1bWVudCBk ZXRhaWxzIHNwZWNpZmljIHJlcXVpcmVtZW50cyBmb3IgcGxlZGdlcywNCj4gICAgICAgICAgICBw cm94aWVzIGFuZCByZWdpc3RyYXJzIHdoZW4gdGhleSBhcmUgcGFydCBvZiBhbiBBTkkuPC90Pg0K PiANCj4gRG9lcyB0aGlzIHdvcmsgZm9yIHlvdT8NCj4gDQo+PiBXaXRob3V0IHRoaXMgdGVybSB3 ZSBjYW4gbm90IG5haWwgZG93biB0aGUgZXhwbGljaXQgcmVxdWlyZW1lbnRzIGFnYWluc3QNCj4+ IEFOSSBQbGVkZ2VzLCBQcm94aWVzLCBSZWdpc3RyYXJzIHRoYXQgd2UgbmVlZCBmcm9tIHRoZSBk b2N1bWVudCAoYW5kIGRpc3Rpbmd1aXNoDQo+PiBmcm9tIHJlcXVpcmVtZW50cyBhZ2FpbnN0IGFu eSBub24tQU5JIGFkYXB0YXRpb24gb2YgQlJTS0kpLiBJIGFkZGVkIGFjY29yZGluZw0KPj4gY29t bWVudHMgaW50byBvdGhlciBwYXJ0cyBvZiB0aGUgZG9jLg0KPiANCj4+IGcpIFBsZWFzZSByZXBs YWNlICJNQVNBIHNlcnZlciIgd2l0aCAiTUFTQSBzZXJ2aWNlIiBldmVyeXdoZXJlLg0KPiANCj4g SSBwcmVmZXIgdG8ganVzdCBzYXkgIk1BU0EiIGFjdHVhbGx5Lg0KPiBBcmUgeW91IG9rYXkgd2l0 aCB0aGF0Pw0KPiANCj4gTGV0IG1lIHdyYXAgdXAgaGVyZSBmb3IgdGhlIG1vbWVudCBzbyB5b3Ug Y2FuIHNlZSB0aGUgZWRpdHMgYW5kDQo+IEknbGwgcmVwbHkgdG8gdGhlIHJlc3QgYXMgTWF4IGFu ZCBJIGRpZ2VzdCBpdC4gIEl0J3MgYSBsb3Qgb2YgY29tbWVudHMuDQo+IEknZCBsaWtlIHRvIHB1 c2ggYW4gLTExIChpZiBvbmx5IHRvIGZpeCBlbWFpbCBmb3IgTS4gQmVocmluZ2VyKS4NCj4gDQo+ ICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9hbmltYS13Zy9hbmltYS1ib290c3RyYXAvcHVsbC80Mg0K PiAgICBodHRwczovL2dpdGh1Yi5jb20vYW5pbWEtd2cvYW5pbWEtYm9vdHN0cmFwL3B1bGwvNDIv Y29tbWl0cy9jYjdhZjY2MzQ0YWQ3MDlhYWY3MDI4N2E0MGZhMTNhNjdiYmY2MDFjDQo+IA0KPiAN Cj4gLS0NCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5k ZWxtYW4gU29mdHdhcmUgV29ya3MNCj4gLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KPiANCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQo= From nobody Thu Feb 15 09:14:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FDA129C56 for ; Thu, 15 Feb 2018 09:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 S2z7kfpkdYdj for ; Thu, 15 Feb 2018 09:14:34 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD46712DA41 for ; Thu, 15 Feb 2018 09:14:32 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 642CE58C53C; Thu, 15 Feb 2018 18:14:28 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 46A3DB0DA80; Thu, 15 Feb 2018 18:14:28 +0100 (CET) Date: Thu, 15 Feb 2018 18:14:28 +0100 From: Toerless Eckert To: "Max Pritikin (pritikin)" Cc: Michael Richardson , "anima@ietf.org" Message-ID: <20180215171428.GD27823@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <11878.1518662730@obiwan.sandelman.ca> <89C98637-ACD2-423A-A8C4-52191C35FA53@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89C98637-ACD2-423A-A8C4-52191C35FA53@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 17:14:38 -0000 On Thu, Feb 15, 2018 at 04:06:33PM +0000, Max Pritikin (pritikin) wrote: > >> b) Key infrastructure > > > >> There is no definition/reference for this term. Please describe on > >> first use and in terminology. Is there a difference > >> between "key infrastructure" and "keying material" ? If not, then > >> maybe remove one term otherwise pls. describe difference. > > > > The term is in the title and in section 1. > > And you are right that it does not appear again, nor is it defined. > > I think it generally refers to the mechanism of PKI, but I'm not sure what to do. > "Keying material" is defined in RFC4949. Well... RFC4949: keying material 1. (I) Data that is needed to establish and maintain a cryptographic security association, such as keys, key pairs, and IVs. Can you explain to me how i should deduce from that explanation whether certificates are keying material or not ? IMHO, I need certificates to establish (authenticate) the cryptographic security association when i am using certificates. Likewise would a voucher be keying material because it is required for authentication. But the term itself "keying material" implies to a non-native english speaker that this is more likely something like a generalisation of "keys" in cypto algorithms: output = crypto_algorithm(data,keying_material) and in that sense certificates or vouchers are never keying material because they would always be classified as the data portion of any crypto_algorithm (used for establishment of a crypto association). > An ???infrastructure??? is the basic entities and protocols necessary for the operations of key management. I think it comes from the common language term and can???t find a normative definition within IETF document. As a native english speaker who has used the concept in IETF interactions for eons it feels silly to try and define it. Odd. Is this correct: brski keying material = public/private key pairs of IDevID of Pledge and certs of registrar, CA, MASA. Possible non-crypto speaker confusion: are certs/vouchers part of keying material ? (see above) brski keying entities = pledge + registrar + CA ( + MASA ?) Possible non-crypto speaker confusion: Is MASA part of keying entities ? If keying material is just the public key pairs, then probably not ? But would BRSKI without a following EST part even be "keying entities" ? brski keying protocols = BRSKI+ EST (pledge/registrar), EST (registrar/MASA), BRSKI-EST (registrar/MASA) brski keying infrastructure = brski keying entities + brski keying protocols Or whatever else is correct in the context of BRSKI. Better to just enumerate whats meant like i suggested above instead of trying generic definitions because those can fail on non-native crypto speakers like my above confusion with rfc4949. Also it wold be good if there was a clear understanding if BRSKI claims to expand the scope of any of these terms. Eg: If MASA or vouchers are now considered to be part of any prior existing terms such as keying material or keying infra. I guess that "keying protocols" are definitely expanded by BRSKI... Cheers Toerless > > - max > > > > >> c) (terminology) MASA definition: "A third-party Manufacturer...". Why "third-party" ? > >> who are the first two parties ? If this is only slang and we can't explain who the > >> first two parties are, delete "third-party" ? > > > > Fixed... The first party is the Pledge and manufacturer. > > The second party is the Domain Owner. > > The third party is the entity running the MASA, which may not be the manufacturer. > > > >> d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because the text mostly > >> uses "Domain Registrar" and very seldom "Join Registar". > > > > Yes, because we agreed that the term across WGs would be JRC, and we say > > in the terminology that we shorten it to Registrar. We say "Domain > > Registrar" because we want to link it to the PKI concept of a Registration > > Authority (RA). > > > >> JRC is used in exactly three places in the draft. I also can not find on www.google.com > >> or wikipedia any example of "The term JRC is used in common with other bootstrap > >> mechanisms" as the Terminology claims. Either provide a non-anima reference for the > >> use of that term or eliminate it in the document. > > > > We agreed to use common terms. > > It was a thread on ANIMA and 6tisch a year ago. > > I can't get mailarchive to find it for me... > > Ah, I see because "JRC" was never used contracted in that thread. > > https://mailarchive.ietf.org/arch/msg/anima/iotBM0-kxsIB66t8hBo4XUtZLag > > > > As long as they Informative references. > > https://tools.ietf.org/html/draft-ietf-6tisch-architecture-13#section-6.1 > > https://tools.ietf.org/html/draft-ietf-6tisch-terminology-09 > > (yes, expired, but not forgotten, just not a priority) > > > >> e) Voucher > >> - misses ":" after term. > >> - please change "statement" to "artifact" so the terminology aligns with both voucher > >> draft and voucher-request text which also uses artifact. See also section 2.2 > >> where you use "cryptographically protected" instead of "signed" and figure out > >> which term you want to use in all cases (hint: signed). > > > > I've changed it to: > > A voucher is a cryptographically protected artifact (a digital signature) to the Pledge > > > > I feel that we need to say it's cryptographically signed at least once. > > > >> f) IMPORTANT: Please add/define the term "ANI" > > > >> ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and > >> Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI > >> systems (pledges, proxies, registrar) have specific requirements detailled in > >> the document. > > > > The Autonomic Network Infrastructure as > > defined by > />. This document details specific requirements for pledges, > > proxies and registrars when they are part of an ANI. > > > > Does this work for you? > > > >> Without this term we can not nail down the explicit requirements against > >> ANI Pledges, Proxies, Registrars that we need from the document (and distinguish > >> from requirements against any non-ANI adaptation of BRSKI). I added according > >> comments into other parts of the doc. > > > >> g) Please replace "MASA server" with "MASA service" everywhere. > > > > I prefer to just say "MASA" actually. > > Are you okay with that? > > > > Let me wrap up here for the moment so you can see the edits and > > I'll reply to the rest as Max and I digest it. It's a lot of comments. > > I'd like to push an -11 (if only to fix email for M. Behringer). > > > > https://github.com/anima-wg/anima-bootstrap/pull/42 > > https://github.com/anima-wg/anima-bootstrap/pull/42/commits/cb7af66344ad709aaf70287a40fa13a67bbf601c > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Thu Feb 15 09:32:39 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7530D12D77D for ; Thu, 15 Feb 2018 09:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 LwQ0pxEUJiHG for ; Thu, 15 Feb 2018 09:32:34 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632C612D0C3 for ; Thu, 15 Feb 2018 09:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12954; q=dns/txt; s=iport; t=1518715954; x=1519925554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=f17oXPDPPscY9Hf0BhbHhyKg1QEkwmTl37ogODk7CCk=; b=ISMnagUaJoqIiM+JFUaAxZHUjwU1nsAoBcOkleGThkPO2JrjbCqh2PAV SIsbNkft+st5yjhvNZMNxRjcJaTlqzumsc6TikoD5Nm9fboOS9Q3KtuVB FsVh8xiEZFueyCWHj0c7VOidVXVG7hUr4N+RW2m7Jx6N3JnTzPGgRti1a I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAgD2w4Va/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNSZnAoCoNbmCmBWyd8G5ZFFYEkA1wKGA2BXIM6AhqCKFUXAQI?= =?us-ascii?q?BAQEBAQECayiFIwEBAQMBAQEhERUlCwULAgEIDgQGAgImAgICJQsVAg4CBA4Fi?= =?us-ascii?q?i0IEK5egieFAYN7ghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQ+DdIEOgRmDPyk?= =?us-ascii?q?MgkM2gy8BAQIBgTsBEgEJFoMXMYI0BYpkF4lKj20JAogejWWCH4Yqi32LFoJvi?= =?us-ascii?q?WoCERkBgTsBIAE3Mi5xcBUZJCoBghsJhG54AQmLdYElgRkBAQE?= X-IronPort-AV: E=Sophos;i="5.46,517,1511827200"; d="scan'208";a="138527193" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 17:32:31 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w1FHWVBd025297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2018 17:32:31 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Feb 2018 11:32:30 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Thu, 15 Feb 2018 11:32:30 -0600 From: "Max Pritikin (pritikin)" To: Toerless Eckert CC: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 Thread-Index: AQHTpgcblAy+qFNx50mP05nV7UQFlKOmBmyAgAAS+QCAAAUJgA== Date: Thu, 15 Feb 2018 17:32:30 +0000 Message-ID: <41CDDDDE-1098-4836-8338-738C02ED8F0E@cisco.com> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <11878.1518662730@obiwan.sandelman.ca> <89C98637-ACD2-423A-A8C4-52191C35FA53@cisco.com> <20180215171428.GD27823@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180215171428.GD27823@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.5] Content-Type: text/plain; charset="utf-8" Content-ID: <700094C7663B46428D8C4C6184928A8D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 17:32:38 -0000 DQoNCj4gT24gRmViIDE1LCAyMDE4LCBhdCAxMDoxNCBBTSwgVG9lcmxlc3MgRWNrZXJ0IDx0dGVA Y3MuZmF1LmRlPiB3cm90ZToNCj4gDQo+IE9uIFRodSwgRmViIDE1LCAyMDE4IGF0IDA0OjA2OjMz UE0gKzAwMDAsIE1heCBQcml0aWtpbiAocHJpdGlraW4pIHdyb3RlOg0KPj4+PiBiKSAgS2V5IGlu ZnJhc3RydWN0dXJlDQo+Pj4gDQo+Pj4+IFRoZXJlICBpcyBubyBkZWZpbml0aW9uL3JlZmVyZW5j ZSBmb3IgdGhpcyB0ZXJtLiAgUGxlYXNlIGRlc2NyaWJlIG9uDQo+Pj4+IGZpcnN0IHVzZSBhbmQg aW4gdGVybWlub2xvZ3kuICBJcyB0aGVyZSBhIGRpZmZlcmVuY2UNCj4+Pj4gYmV0d2VlbiAia2V5 IGluZnJhc3RydWN0dXJlIiBhbmQgICJrZXlpbmcgbWF0ZXJpYWwiID8gSWYgbm90LCB0aGVuDQo+ Pj4+IG1heWJlIHJlbW92ZSBvbmUgdGVybSBvdGhlcndpc2UgcGxzLiBkZXNjcmliZSBkaWZmZXJl bmNlLg0KPj4+IA0KPj4+IFRoZSB0ZXJtIGlzIGluIHRoZSB0aXRsZSBhbmQgaW4gc2VjdGlvbiAx Lg0KPj4+IEFuZCB5b3UgYXJlIHJpZ2h0IHRoYXQgaXQgZG9lcyBub3QgYXBwZWFyIGFnYWluLCBu b3IgaXMgaXQgZGVmaW5lZC4NCj4+PiBJIHRoaW5rIGl0IGdlbmVyYWxseSByZWZlcnMgdG8gdGhl IG1lY2hhbmlzbSBvZiBQS0ksIGJ1dCBJJ20gbm90IHN1cmUgd2hhdCB0byBkby4NCj4gDQo+PiAi S2V5aW5nIG1hdGVyaWFsIiBpcyBkZWZpbmVkIGluIFJGQzQ5NDkuDQo+IA0KPiBXZWxsLi4uIFJG QzQ5NDk6IGtleWluZyBtYXRlcmlhbA0KPiAgICAxLiAoSSkgRGF0YSB0aGF0IGlzIG5lZWRlZCB0 byBlc3RhYmxpc2ggYW5kIG1haW50YWluIGENCj4gICAgICAgY3J5cHRvZ3JhcGhpYyBzZWN1cml0 eSBhc3NvY2lhdGlvbiwgc3VjaCBhcyBrZXlzLCBrZXkgcGFpcnMsIGFuZCBJVnMuDQo+IA0KPiBD YW4geW91IGV4cGxhaW4gdG8gbWUgaG93IGkgc2hvdWxkIGRlZHVjZSBmcm9tIHRoYXQgZXhwbGFu YXRpb24gd2hldGhlcg0KPiBjZXJ0aWZpY2F0ZXMgYXJlIGtleWluZyBtYXRlcmlhbCBvciBub3Qg Pw0KDQpDZXJ0aWZpY2F0ZXMgYXJlIGEgZGF0YSBmb3JtYXQgZm9yIGVuY29kaW5nIHB1YmxpYyBr ZXlzIGFuZCBhc3NvY2lhdGVkIGNlcnRpZmljYXRpb25zIChlLmcuIHRoZSBDQSBzaWduYXR1cmUp IGV0Yy4gSSB0aGluayB0aGlzIGNvdWxkIHJlYXNvbmFibHkgYmUgY2FsbGVkIGRhdGEgbmVlZGVk IHRvIGVzdGFibGlzaCBhIGNyeXB0b2dyYXBoaWMgc2VjdXJpdHkgYXNzb2NpYXRpb24uIA0KDQo+ IA0KPiBJTUhPLCBJIG5lZWQgY2VydGlmaWNhdGVzIHRvIGVzdGFibGlzaCAoYXV0aGVudGljYXRl KSB0aGUgY3J5cHRvZ3JhcGhpYyBzZWN1cml0eQ0KPiBhc3NvY2lhdGlvbiB3aGVuIGkgYW0gdXNp bmcgY2VydGlmaWNhdGVzLiAgTGlrZXdpc2Ugd291bGQgYSB2b3VjaGVyDQo+IGJlIGtleWluZyBt YXRlcmlhbCBiZWNhdXNlIGl0IGlzIHJlcXVpcmVkIGZvciBhdXRoZW50aWNhdGlvbi4NCg0KSWYg d2XigJlyZSBzdHJldGNoaW5nIGxpa2UgdGhpcyB0aGVuIHN1cmUuIEEgdm91Y2hlciBpcyBhIGNl cnRpZmljYXRpb24gb2YgYSBwdWJsaWMga2V5ICh0aGUgbmV3IG93bmVyKSBhbG9uZyB3aXRoIGFk ZGl0aW9uYWwgZGF0YSB1c2VkIHRvIGludGVycHJldCB0aGUgY2VydGlmaWNhdGlvbi4gSWYgeW91 IGtlZXAgZ29pbmcgZG93biB0aGF0IHBhdGggeW914oCZcmUgZ29ubmEgZW5kIHVwIGNsYWltaW5n IHdlIHNob3VsZCBoYXZlIHNpbXBseSBoYWQgYW4gWDUwOSBleHRlbnNpb24gaW5zdGVhZCBvZiBh IHZvdWNoZXIgZm9ybWF0LiBUaGVyZSBhcmUgcmVhc29ucyB3ZSBkaWRu4oCZdCBnbyB0aGF0IHdh eSBidXQgSSBjb3VsZCBzZWUgYSB3b3JsZCB3aGVyZSB0aGF0IGhhcHBlbmVkICh0aGFua2Z1bGx5 IG5vdCBvdXIgcmVhbGl0eSB0aG91Z2gpLiANCg0KPiBCdXQgdGhlIHRlcm0gaXRzZWxmICJrZXlp bmcgbWF0ZXJpYWwiIGltcGxpZXMgdG8gYSBub24tbmF0aXZlIGVuZ2xpc2ggc3BlYWtlcg0KPiB0 aGF0IHRoaXMgaXMgbW9yZSBsaWtlbHkgc29tZXRoaW5nIGxpa2UgYSBnZW5lcmFsaXNhdGlvbiBv ZiAia2V5cyIgaW4NCj4gY3lwdG8gYWxnb3JpdGhtczoNCj4gDQo+ICBvdXRwdXQgPSBjcnlwdG9f YWxnb3JpdGhtKGRhdGEsa2V5aW5nX21hdGVyaWFsKQ0KPiANCj4gYW5kIGluIHRoYXQgc2Vuc2Ug Y2VydGlmaWNhdGVzIG9yIHZvdWNoZXJzIGFyZSBuZXZlciBrZXlpbmcgbWF0ZXJpYWwNCj4gYmVj YXVzZSB0aGV5IHdvdWxkIGFsd2F5cyBiZSBjbGFzc2lmaWVkIGFzIHRoZSBkYXRhIHBvcnRpb24g b2YgYW55DQo+IGNyeXB0b19hbGdvcml0aG0gKHVzZWQgZm9yIGVzdGFibGlzaG1lbnQgb2YgYSBj cnlwdG8gYXNzb2NpYXRpb24pLg0KDQpUaGV5IGJvdGggaW5jbHVkZSBwdWJsaWMga2V5IGRhdGEu IFRoYXQga2V5IG1hdGVyaWFsLiANCg0KPiANCj4+IEFuID8/P2luZnJhc3RydWN0dXJlPz8/IGlz IHRoZSBiYXNpYyBlbnRpdGllcyBhbmQgcHJvdG9jb2xzIG5lY2Vzc2FyeSBmb3IgdGhlIG9wZXJh dGlvbnMgb2Yga2V5IG1hbmFnZW1lbnQuIEkgdGhpbmsgaXQgY29tZXMgZnJvbSB0aGUgY29tbW9u IGxhbmd1YWdlIHRlcm0gYW5kIGNhbj8/P3QgZmluZCBhIG5vcm1hdGl2ZSBkZWZpbml0aW9uIHdp dGhpbiBJRVRGIGRvY3VtZW50LiBBcyBhIG5hdGl2ZSBlbmdsaXNoIHNwZWFrZXIgd2hvIGhhcyB1 c2VkIHRoZSBjb25jZXB0IGluIElFVEYgaW50ZXJhY3Rpb25zIGZvciBlb25zIGl0IGZlZWxzIHNp bGx5IHRvIHRyeSBhbmQgZGVmaW5lIGl0LiBPZGQuIA0KPiANCj4gSXMgdGhpcyBjb3JyZWN0Og0K PiANCj4gYnJza2kga2V5aW5nIG1hdGVyaWFsID0gcHVibGljL3ByaXZhdGUga2V5IHBhaXJzIG9m IElEZXZJRCBvZiBQbGVkZ2UgYW5kIGNlcnRzIG9mIHJlZ2lzdHJhciwgQ0EsIE1BU0EuDQo+ICBQ b3NzaWJsZSBub24tY3J5cHRvIHNwZWFrZXIgY29uZnVzaW9uOiBhcmUgY2VydHMvdm91Y2hlcnMg cGFydCBvZiBrZXlpbmcgbWF0ZXJpYWwgPyAoc2VlIGFib3ZlKQ0KDQpJIHRoaW5rIHNvLiBBbnl0 aW1lIHdlIHRhbGsgYWJvdXQgcmF3IHB1YmxpYyBrZXlzLCBjZXJ0aWZpY2F0ZXMsIHZvdWNoZXJz LCBldGMgd2UgaGF2ZSB0byBkaXNjdXNzIGFsbCB0aGUgc2FtZSBrZXkgbWFuYWdlbWVudCBpc3N1 ZXMgKHVwZGF0aW5nIHRoZW0sIGxpZmV0aW1lcywgcmV2b2NhdGlvbnMsIGV0YykuIA0KDQo+IA0K PiBicnNraSBrZXlpbmcgZW50aXRpZXMgPSBwbGVkZ2UgKyByZWdpc3RyYXIgKyBDQSAoICsgTUFT QSA/KQ0KPiAgUG9zc2libGUgbm9uLWNyeXB0byBzcGVha2VyIGNvbmZ1c2lvbjogSXMgTUFTQSBw YXJ0IG9mIGtleWluZyBlbnRpdGllcyA/DQo+ICBJZiBrZXlpbmcgbWF0ZXJpYWwgaXMganVzdCB0 aGUgcHVibGljIGtleSBwYWlycywgdGhlbiBwcm9iYWJseSBub3QgPw0KDQpXaHkgbm90PyBJdHMg YWxsIHBhcnQgb2YgdGhlIGtleSBpbmZyYXN0cnVjdHVyZSBpbiB0aGF0IHRoZXNlIGFyZSB0aGUg ZW50aXRpZXMgKGFuZCBhc3NvY2lhdGVkIHByb3RvY29scyEpIG5lZWRlZCB0byBtYW5hZ2UgYWxs IHRoZSBrZXkgbWF0ZXJpYWwuIA0KDQpUaGVyZSBpcyBzb21ldGhpbmcgZGlmZmVyZW50IGFib3V0 IOKAnGF1dGhlbnRpY2F0aW9uIGtleSBtYXRlcmlhbOKAnSBhbmQg4oCcY2VydGlmaWNhdGlvbiBr ZXkgbWF0ZXJpYWzigJ0gYnV0IGlzIGl0IG5lY2Vzc2FyeSBmb3IgdXMgdG8gZ2V0IGludG8gdGhv c2UgcGVkYW50aWMgYXJlYXM/IEFyZSB5b3UgcHJvcG9zaW5nIGFuIHVwZGF0ZSB0byBSRkM0OTQ5 PyBXaGVyZSBhcmUgd2UgZ29pbmcgd2l0aCB0aGlzPyANCg0KPiAgQnV0IHdvdWxkIEJSU0tJIHdp dGhvdXQgYSBmb2xsb3dpbmcgRVNUIHBhcnQgZXZlbiBiZSAia2V5aW5nIGVudGl0aWVz4oCdID/i gJkNCg0KQlJTS0kgYW5kIEVTVCBhcmUgcHJvdG9jb2xzIG5vdCDigJxlbnRpdGllc+KAnS4gQnV0 IHllcywgQlJTS0kgaXMgYSBwYXJ0IG9mIHRoZSBrZXkgaW5mcmFzdHJ1Y3R1cmUuIEl0IGlzIHRo ZSBwcm90b2NvbCBmb3Ig4oCcYm9vdHN0cmFwcGluZyBbdGhlXSByZW1vdGUgW3BvcnRpb24gb2Yg dGhlXSBzZWN1cmUga2V5IGluZnJhc3RydWN0dXJl4oCdLiANCg0KPiBicnNraSBrZXlpbmcgcHJv dG9jb2xzID0gQlJTS0krIEVTVCAocGxlZGdlL3JlZ2lzdHJhciksIEVTVCAocmVnaXN0cmFyL01B U0EpLCBCUlNLSS1FU1QgKHJlZ2lzdHJhci9NQVNBKQ0KPiANCj4gYnJza2kga2V5aW5nIGluZnJh c3RydWN0dXJlID0gYnJza2kga2V5aW5nIGVudGl0aWVzICsgYnJza2kga2V5aW5nIHByb3RvY29s cw0KPiANCj4gT3Igd2hhdGV2ZXIgZWxzZSBpcyBjb3JyZWN0IGluIHRoZSBjb250ZXh0IG9mIEJS U0tJLiBCZXR0ZXIgdG8ganVzdCBlbnVtZXJhdGUgd2hhdHMNCj4gbWVhbnQgbGlrZSBpIHN1Z2dl c3RlZCBhYm92ZSBpbnN0ZWFkIG9mIHRyeWluZyBnZW5lcmljIGRlZmluaXRpb25zIGJlY2F1c2Ug dGhvc2UNCj4gY2FuIGZhaWwgb24gbm9uLW5hdGl2ZSBjcnlwdG8gc3BlYWtlcnMgbGlrZSBteSBh Ym92ZSBjb25mdXNpb24gd2l0aCByZmM0OTQ5Lg0KPiANCj4gQWxzbyBpdCB3b2xkIGJlIGdvb2Qg aWYgdGhlcmUgd2FzIGEgY2xlYXIgdW5kZXJzdGFuZGluZyBpZiBCUlNLSSBjbGFpbXMgdG8gZXhw YW5kDQo+IHRoZSBzY29wZSBvZiBhbnkgb2YgdGhlc2UgdGVybXMuIEVnOiBJZiBNQVNBIG9yIHZv dWNoZXJzIGFyZSBub3cgY29uc2lkZXJlZCB0bw0KPiBiZSBwYXJ0IG9mIGFueSBwcmlvciBleGlz dGluZyB0ZXJtcyBzdWNoIGFzIGtleWluZyBtYXRlcmlhbCBvciBrZXlpbmcgaW5mcmEuIEkNCj4g Z3Vlc3MgdGhhdCAia2V5aW5nIHByb3RvY29scyIgYXJlIGRlZmluaXRlbHkgZXhwYW5kZWQgYnkg QlJTS0nigKYNCg0KQmFzZWQgb24gdGhlIGFib3ZlIEkgdGhpbmsgaXRzIGZhaXIgdG8gc2F5IHRo YXQ6DQoNClZvdWNoZXLigJlzIGV4cGFuZCBvbiB0aGUgZGVmaW5lZCBrZXkgbWF0ZXJpYWwgZGF0 YSB0eXBlcy4gDQpCUlNLSSBwcm90b2NvbCBhbmQgTUFTQSBlbnRpdHkgZXhwYW5kIG9uIHRoZSBk ZWZpbmVkIHR5cGVzIG9mIGtleSBpbmZyYXN0cnVjdHVyZSBlbGVtZW50cy4gDQoNCi0gbWF4DQoN Cj4gDQo+IENoZWVycw0KPiAgICBUb2VybGVzcw0KPiANCj4+IA0KPj4gLSBtYXgNCj4+IA0KPj4+ IA0KPj4+PiBjKSAodGVybWlub2xvZ3kpIE1BU0EgZGVmaW5pdGlvbjogIkEgdGhpcmQtcGFydHkg TWFudWZhY3R1cmVyLi4uIi4gV2h5ICJ0aGlyZC1wYXJ0eSIgPw0KPj4+PiB3aG8gYXJlIHRoZSBm aXJzdCB0d28gcGFydGllcyA/IElmIHRoaXMgaXMgb25seSBzbGFuZyBhbmQgd2UgY2FuJ3QgZXhw bGFpbiB3aG8gdGhlDQo+Pj4+IGZpcnN0IHR3byBwYXJ0aWVzIGFyZSwgZGVsZXRlICJ0aGlyZC1w YXJ0eSIgPw0KPj4+IA0KPj4+IEZpeGVkLi4uICBUaGUgZmlyc3QgcGFydHkgaXMgdGhlIFBsZWRn ZSBhbmQgbWFudWZhY3R1cmVyLg0KPj4+IFRoZSBzZWNvbmQgcGFydHkgaXMgdGhlIERvbWFpbiBP d25lci4NCj4+PiBUaGUgdGhpcmQgcGFydHkgaXMgdGhlIGVudGl0eSBydW5uaW5nIHRoZSBNQVNB LCB3aGljaCBtYXkgbm90IGJlIHRoZSBtYW51ZmFjdHVyZXIuDQo+Pj4gDQo+Pj4+IGQpICJEb21h aW4gUmVnaXN0cmFyIiB2cy4gIkpvaW4gUmVnaXN0cmFyIiwgSlJDLiBFc3BlY2lhbGx5IGJlY2F1 c2UgdGhlIHRleHQgbW9zdGx5DQo+Pj4+IHVzZXMgIkRvbWFpbiBSZWdpc3RyYXIiIGFuZCB2ZXJ5 IHNlbGRvbSAiSm9pbiBSZWdpc3RhciIuDQo+Pj4gDQo+Pj4gWWVzLCBiZWNhdXNlIHdlIGFncmVl ZCB0aGF0IHRoZSB0ZXJtIGFjcm9zcyBXR3Mgd291bGQgYmUgSlJDLCBhbmQgd2Ugc2F5DQo+Pj4g aW4gdGhlIHRlcm1pbm9sb2d5IHRoYXQgd2Ugc2hvcnRlbiBpdCB0byBSZWdpc3RyYXIuICBXZSBz YXkgIkRvbWFpbg0KPj4+IFJlZ2lzdHJhciIgYmVjYXVzZSB3ZSB3YW50IHRvIGxpbmsgaXQgdG8g dGhlIFBLSSBjb25jZXB0IG9mIGEgUmVnaXN0cmF0aW9uDQo+Pj4gQXV0aG9yaXR5IChSQSkuDQo+ Pj4gDQo+Pj4+IEpSQyBpcyB1c2VkIGluIGV4YWN0bHkgdGhyZWUgcGxhY2VzIGluIHRoZSBkcmFm dC4gSSBhbHNvIGNhbiBub3QgZmluZCBvbiB3d3cuZ29vZ2xlLmNvbQ0KPj4+PiBvciB3aWtpcGVk aWEgYW55IGV4YW1wbGUgb2YgIlRoZSB0ZXJtIEpSQyBpcyB1c2VkIGluIGNvbW1vbiB3aXRoIG90 aGVyIGJvb3RzdHJhcA0KPj4+PiBtZWNoYW5pc21zIiBhcyB0aGUgVGVybWlub2xvZ3kgY2xhaW1z LiBFaXRoZXIgcHJvdmlkZSBhIG5vbi1hbmltYSByZWZlcmVuY2UgZm9yIHRoZQ0KPj4+PiB1c2Ug b2YgdGhhdCB0ZXJtIG9yIGVsaW1pbmF0ZSBpdCBpbiB0aGUgZG9jdW1lbnQuDQo+Pj4gDQo+Pj4g V2UgYWdyZWVkIHRvIHVzZSBjb21tb24gdGVybXMuDQo+Pj4gSXQgd2FzIGEgdGhyZWFkIG9uIEFO SU1BIGFuZCA2dGlzY2ggYSB5ZWFyIGFnby4NCj4+PiBJIGNhbid0IGdldCBtYWlsYXJjaGl2ZSB0 byBmaW5kIGl0IGZvciBtZS4uLg0KPj4+IEFoLCBJIHNlZSBiZWNhdXNlICJKUkMiIHdhcyBuZXZl ciB1c2VkIGNvbnRyYWN0ZWQgaW4gdGhhdCB0aHJlYWQuDQo+Pj4gICBodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL2FuaW1hL2lvdEJNMC1reHNJQjY2dDhoQm80WFV0WkxhZw0K Pj4+IA0KPj4+IEFzIGxvbmcgYXMgdGhleSBJbmZvcm1hdGl2ZSByZWZlcmVuY2VzLg0KPj4+IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZ0aXNjaC1hcmNoaXRlY3R1cmUt MTMjc2VjdGlvbi02LjENCj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi02dGlzY2gtdGVybWlub2xvZ3ktMDkNCj4+PiAgICAgICAoeWVzLCBleHBpcmVkLCBidXQgbm90 IGZvcmdvdHRlbiwganVzdCBub3QgYSBwcmlvcml0eSkNCj4+PiANCj4+Pj4gZSkgVm91Y2hlcg0K Pj4+PiAtIG1pc3NlcyAiOiIgYWZ0ZXIgdGVybS4NCj4+Pj4gLSBwbGVhc2UgY2hhbmdlICJzdGF0 ZW1lbnQiIHRvICJhcnRpZmFjdCIgc28gdGhlIHRlcm1pbm9sb2d5IGFsaWducyB3aXRoIGJvdGgg dm91Y2hlcg0KPj4+PiBkcmFmdCBhbmQgdm91Y2hlci1yZXF1ZXN0IHRleHQgd2hpY2ggYWxzbyB1 c2VzIGFydGlmYWN0LiBTZWUgYWxzbyBzZWN0aW9uIDIuMg0KPj4+PiB3aGVyZSB5b3UgdXNlICJj cnlwdG9ncmFwaGljYWxseSBwcm90ZWN0ZWQiIGluc3RlYWQgb2YgInNpZ25lZCIgYW5kIGZpZ3Vy ZSBvdXQNCj4+Pj4gd2hpY2ggdGVybSB5b3Ugd2FudCB0byB1c2UgaW4gYWxsIGNhc2VzIChoaW50 OiBzaWduZWQpLg0KPj4+IA0KPj4+IEkndmUgY2hhbmdlZCBpdCB0bzoNCj4+PiA8dD5BIHZvdWNo ZXIgaXMgYSBjcnlwdG9ncmFwaGljYWxseSBwcm90ZWN0ZWQgYXJ0aWZhY3QgKGEgZGlnaXRhbCBz aWduYXR1cmUpIHRvIHRoZSBQbGVkZ2UNCj4+PiANCj4+PiBJIGZlZWwgdGhhdCB3ZSBuZWVkIHRv IHNheSBpdCdzIGNyeXB0b2dyYXBoaWNhbGx5IHNpZ25lZCBhdCBsZWFzdCBvbmNlLg0KPj4+IA0K Pj4+PiBmKSBJTVBPUlRBTlQ6IFBsZWFzZSBhZGQvZGVmaW5lIHRoZSB0ZXJtICJBTkkiDQo+Pj4g DQo+Pj4+IEFOSSAtICJBdXRvbm9taWMgTmV0d29yayBJbmZyYXN0cnVjdHVyZSIuIFN5c3RlbXMg dGhhdCBzdXBwb3J0IGJvdGggQlJTS0kgYW5kDQo+Pj4+IEF1dG9ub21pYyBDb250cm9sIHBsYW5l IC0gQUNQIChbSS1ELmlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmVdKS4gQU5JDQo+ Pj4+IHN5c3RlbXMgKHBsZWRnZXMsIHByb3hpZXMsIHJlZ2lzdHJhcikgaGF2ZSBzcGVjaWZpYyBy ZXF1aXJlbWVudHMgZGV0YWlsbGVkIGluDQo+Pj4+IHRoZSBkb2N1bWVudC4NCj4+PiANCj4+PiAg ICAgICAgICAgPHQgaGFuZ1RleHQ9IkFOSToiPlRoZSBBdXRvbm9taWMgTmV0d29yayBJbmZyYXN0 cnVjdHVyZSBhcw0KPj4+ICAgICAgICAgICBkZWZpbmVkIGJ5IDx4cmVmIHRhcmdldD0iSS1ELmll dGYtYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUiDQo+Pj4gICAgICAgICAgIC8+LiAgVGhp cyBkb2N1bWVudCBkZXRhaWxzIHNwZWNpZmljIHJlcXVpcmVtZW50cyBmb3IgcGxlZGdlcywNCj4+ PiAgICAgICAgICAgcHJveGllcyBhbmQgcmVnaXN0cmFycyB3aGVuIHRoZXkgYXJlIHBhcnQgb2Yg YW4gQU5JLjwvdD4NCj4+PiANCj4+PiBEb2VzIHRoaXMgd29yayBmb3IgeW91Pw0KPj4+IA0KPj4+ PiBXaXRob3V0IHRoaXMgdGVybSB3ZSBjYW4gbm90IG5haWwgZG93biB0aGUgZXhwbGljaXQgcmVx dWlyZW1lbnRzIGFnYWluc3QNCj4+Pj4gQU5JIFBsZWRnZXMsIFByb3hpZXMsIFJlZ2lzdHJhcnMg dGhhdCB3ZSBuZWVkIGZyb20gdGhlIGRvY3VtZW50IChhbmQgZGlzdGluZ3Vpc2gNCj4+Pj4gZnJv bSByZXF1aXJlbWVudHMgYWdhaW5zdCBhbnkgbm9uLUFOSSBhZGFwdGF0aW9uIG9mIEJSU0tJKS4g SSBhZGRlZCBhY2NvcmRpbmcNCj4+Pj4gY29tbWVudHMgaW50byBvdGhlciBwYXJ0cyBvZiB0aGUg ZG9jLg0KPj4+IA0KPj4+PiBnKSBQbGVhc2UgcmVwbGFjZSAiTUFTQSBzZXJ2ZXIiIHdpdGggIk1B U0Egc2VydmljZSIgZXZlcnl3aGVyZS4NCj4+PiANCj4+PiBJIHByZWZlciB0byBqdXN0IHNheSAi TUFTQSIgYWN0dWFsbHkuDQo+Pj4gQXJlIHlvdSBva2F5IHdpdGggdGhhdD8NCj4+PiANCj4+PiBM ZXQgbWUgd3JhcCB1cCBoZXJlIGZvciB0aGUgbW9tZW50IHNvIHlvdSBjYW4gc2VlIHRoZSBlZGl0 cyBhbmQNCj4+PiBJJ2xsIHJlcGx5IHRvIHRoZSByZXN0IGFzIE1heCBhbmQgSSBkaWdlc3QgaXQu ICBJdCdzIGEgbG90IG9mIGNvbW1lbnRzLg0KPj4+IEknZCBsaWtlIHRvIHB1c2ggYW4gLTExIChp ZiBvbmx5IHRvIGZpeCBlbWFpbCBmb3IgTS4gQmVocmluZ2VyKS4NCj4+PiANCj4+PiAgIGh0dHBz Oi8vZ2l0aHViLmNvbS9hbmltYS13Zy9hbmltYS1ib290c3RyYXAvcHVsbC80Mg0KPj4+ICAgaHR0 cHM6Ly9naXRodWIuY29tL2FuaW1hLXdnL2FuaW1hLWJvb3RzdHJhcC9wdWxsLzQyL2NvbW1pdHMv Y2I3YWY2NjM0NGFkNzA5YWFmNzAyODdhNDBmYTEzYTY3YmJmNjAxYw0KPj4+IA0KPj4+IA0KPj4+ IC0tDQo+Pj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5k ZWxtYW4gU29mdHdhcmUgV29ya3MNCj4+PiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+Pj4g DQo+Pj4gDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4+PiBBbmltYUBpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4+IA0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEFuaW1hIG1h aWxpbmcgbGlzdA0KPj4gQW5pbWFAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYW5pbWENCj4gDQo+IC0tIA0KPiAtLS0NCj4gdHRlQGNzLmZhdS5kZQ0K DQo= From nobody Thu Feb 15 11:54:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D27124D68 for ; Thu, 15 Feb 2018 11:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 l3-kWQkSFF1q for ; Thu, 15 Feb 2018 11:54:51 -0800 (PST) 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 E1302120227 for ; Thu, 15 Feb 2018 11:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11530; q=dns/txt; s=iport; t=1518724490; x=1519934090; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L8vy4ZuyhGp1lKkp6lU4EuBOJx5IEG7gLjWKs1wu53s=; b=U5dSKDNP/b47OgdJT+173OJTu6mo4E56WUO9p55K36BbJ9L9+GgHfx89 1C4nRWsQVrQZMZXuXIpYA0B/dyAecJXaoVLkxvOhyX7aFnEwlOUUcOm8n kdqSC7avSt74SFgkghPSihzTdsA3yACvJfn14I1V+/N9PkU2hND5vB/Vp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAAAp5IVa/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMlLWZwKAqOAI4DggKBF5ZFghgKGAuBXoM6AoJCVBgBAgEBAQE?= =?us-ascii?q?BAQJrKIUjAQEBAwEBATgxAwsMBAIBCA4DBAEBARgGCQcnCxQJCAIEAQ0FCBOKE?= =?us-ascii?q?ggQsTWBQoc1ghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYUDgieBV4FogiCBDoM?= =?us-ascii?q?vAQGBTnGFLgWKe4dUkWMJApV6lE+UZYMKAhEZAYE7AR85gVFwFT2CRoJVHIEKA?= =?us-ascii?q?QJ5eItJAgUeAgeBBoEZAQEB?= X-IronPort-AV: E=Sophos;i="5.46,517,1511827200"; d="scan'208";a="71398043" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 19:54:50 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w1FJsnWJ032029 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2018 19:54:49 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Feb 2018 13:54:49 -0600 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Thu, 15 Feb 2018 13:54:49 -0600 From: "Owen Friel (ofriel)" To: Toerless Eckert , Michael Richardson CC: "anima@ietf.org" , "Max Pritikin (pritikin)" , "Eliot Lear (elear)" Thread-Topic: [Anima] BRSKI over 802.11 Thread-Index: AQHTpbS80kr8dImS10GyGhws45k3TKOkp4YAgAABSoCAATh3oA== Date: Thu, 15 Feb 2018 19:54:48 +0000 Message-ID: References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> <31460.1518635300@obiwan.sandelman.ca> <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.8.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 19:54:54 -0000 (some context - I've been talking internally to Max and Eliot about this qu= ite a bit) First, a high level summary of 802.11u-2011 (which is incorporated into 802= .11-2016) capabilities. STAs and APs advertise support for 802.11u by setting the Interworking bit = in the Extended Capabilities IE, and by including the Interworking IE in Be= acon, Probe Request and Probe Response frames. The Interworking IE includes info on: - Access Network Type (Private, Free public, Chargeable public, etc.) - internet bit (yes/no) - ASRA (Additional Step required for Access - e.g. this could mean EAP-TLS,= or a BRSKI flow) 802.11u introduced ANQP Access Network Query Protocol which enables STAs to= query APs for info not present in Beacons/Probe Reponses. ANQP defines these key IEs for enabling the STA to determine which network = to connect to: Roaming consortium IE: includes the OI(s) of the roaming consortium(s). The= OI is typically provisioned on cell phones by the SP, so the cell phone c= an automatically detect wifi networks that provide access to its SP's conso= rtium. 3GPP Cellular Network IE: includes the Mobile Country Code (MCC) and Mobile= Network Code (MNC) of the SP the AP provides access to. Network Access Identifier Realm IE: includes RFC4282 realm names that the A= P provides access to (e.g. wifi.service-provider.com). The NAI Realm IE als= o includes info on the EAP type required to access that realm e.g. EAP-TLS. Domain name IE: the domain name(s) of the local AP operator. Its purpose is= to enable a STA to connect to a domain operator that may have a more favou= rable pricing model for backhaul connections to the internet / SP. STAs can use some or all of the above IEs to make a suitable decision on wh= ich SSID to pick. HotSpot 2.0 is an example of a spec built on top of 802.11u and defines 10 = additional ANQP elements using the standard vendor extensions mechanisms de= fined in 802.11. It also defines a HS2.0 Indication element that is includes in Beacons and = Probe Responses so that STAs can immediately tell if an SSID supports HS2.0= . That's the end of the .11u intro, but I'll come back to NAI Realms in a bit= . I agree with Nancy below on splitting this into SSID discovery and connecti= on/authentication steps. There were a few discovery options proposed in thi= s thread, and I'll add to that: 1. define a well-known naming convention for BRSKI capable SSIDs e.g. BRSKI= %xfinity This goes against the grain of .11u whose whole purpose is for STAs to make= a decision on which SSID to use based on advertised capabilities, rather t= han SSID naming convention. Additionally, operators will not want to deploy a new SSID just to enable B= RSKI flows as each SSID eats up air space and wifi channel capacity due to = beacon overheads, etc. It would be better to add the relevant bits to the A= QNP for an existing SSID. From the operator perspective, that's modifying t= he config of an existing SSID rather than deploying a new one. =09 2. Leverage existing 802.11u It appears as if NAI Realm could be a possible mechanism for advertising BR= SKI capability (and Roaming consortium, 3GPP cellular network are not). We = could possibly piggy back on top of NAI Realm and advertise a realm of simp= ly "_bootstrapks". WLCs certainly appear to allow this kind of configuratio= n (although today some WLCs tie .11u configuration to HS2.0 configuration i= .e. you cannot enable advertising 802.11u bits without also advertising HS2= .0 in Beacons - but thats a WLC implementation gap not a standards gap). The key conceptual difference is that we are using this special realm name = more as a logical service advertisement rather than as a backhaul internet = provider advertisement. This would not require any 802.11 IEEE spec changes= , but could fall into the realm of IETF spec definition. i.e. if you config= ure your existing wifi network using existing 802.11u mechanisms to adverti= se this NAI Realm, then IoT devices will know that this SSID offers BRSKI s= ervices. Additionally (or alternatively...) as NAI Realm includes advertising the EA= P mechanism required, if a new EAP-BRSKI were to be defined, then this coul= d be advertised. STAs could just scan for an NAI Realm that enforced EAP-BR= SKI, and ignore the realm name. One big issue with this is Eliot's point about "a business in an office bui= lding on the 10th floor in New York City or London, where you might hear 2 = dozen different networks". The STA ends up scanning a lot of SSIDs, and it = may find multiple SSIDs that advertise EAP-BRSKI or NAI Realm "_bootstrapks= ". It would have to attempt to join all of them in sequence, and rely on th= e operator configuring their network such that the manufacturer IDevID CA o= r the specific IDevID is not trusted and rejects the device. It could also = result in the STA joining the wrong SSID, which would not be ideal. 3. Define new 802.11u extensions Similar to HS2.0, we define a new BRSKI Indication Element that is advertis= ed in Beacons, and then define any additional AQNP elements as are required= . This is likely a standards body quagmire (and would also requires signifi= cant infrastructure / WLC development if that's a consideration...) 4. Use / Extend WPS None of the existing WPS mechanism are really suitable (PIN, push button, N= FC, USB). Extending WPS, similar to defining new 802.11u extensions, seems = like a standards body quagmire. Defining a new EAP-BRSKI mechanism seems mo= re tractable. 5. Use WiFi Device Provisioning Protocol (Eliot suggested this one) Some comments on briefly reviewing this. At a high level, if we have a boot= strapping Thing trying to discover and connect to an AP (with no one doing = supervision/handholding via a mobile app or anything), then the Thing is th= e DPP Enrolee and the AP is the DPP Configurator. Additionally, the AP must= initiate the DPP exchange and not the Thing (the Thing must be the DPP res= ponder) because as per DPP, the Initiator must know in advance and validate= the bootstrapping public key (which would be the public key of the IDevID = I guess)of the Responder. This means that the AP must be continuously polli= ng for Things that it wants to bootstrap (and the Thing must be cycling thr= ough all channels listening for a DPP initiation request, similar to standa= rd SSID passive scanning) . It needs further thought if this has any channe= l capacity implications. The DPP groupId is meant to help with this I think= ... One big advantage of this is that the Thing is not attempting (and potentia= lly failing, or worse - succeeding to connect to the wrong SSID) to connect= to a large number of SSIDs unlike option 2 NAI Realm. It also means that a= n operator should not inadvertently claim someone else's Thing as it should= be unlikely that two Things will have identical bootstrapping public keys. Anyways, once the device somehow knows the SSID, it can begin connection an= d authentication. There have been comments that pre-completing BRSKI, the client must connect= to an unsecure network. That's not entirely true. The network could in fac= t enforce 802.1x and EAP-TLS based on the manufacturer's cert / IDevID. Sim= ilarly, if an EAP-BRSKI mechanism were to be defined, the network could den= y access and not even allow the client to send its /requestvoucher unless i= t successfully completed the initial TLS and presented a trusted IDevID. So= it could be a bootstrapping network segment that allows devices from trust= ed manufacturers. That seems like a better alternative to using WPA-PSK wit= h a known network key or WAP-802.1x with a known username/password (both of= which require somehow provisioning that key into the device). And on defining a new EAP-BRSKI mechanism, it should be possible to achieve= today what EAP-BRSKI would enable, albeit with 2 x 802.1x, 2 x DHCP reques= ts. A flow could be: 1. device discovers SSID 2. network enforces 802.1x EAP-TLS and checks that device has an IDevID sig= ned by a trusted manufacturer CA; if not deny access 3. AAA instructs WLC to put device in a network segment that grants it acce= ss to the Registrar and nothing else 4. device does DHCP, gets and IP, and does the BRSKI dance and uses its IDe= vID to get an LDevID 5. Once device has an LDevID, it does DHCP Release and an EAPOL-Logoff 6. Device restarts 802.1x 7. network enforces 802.1x EAP-TLS and this time checks that device has a t= rusted LDevID 8. AAA instructs WLC to put device in a network segment that grants it acce= ss to all required services 9. device does DHCP and we are done Not saying that that complex flow is desirable, the 2x 802.1x and 2x DHCP w= ill make constrained Things baulk, but its feasible. And if we were to say = use the NAI Realms "_bootstrapks" mechanism, we could in theory build that = solution out now with no infrastructure revs, and with minimal standardisat= ions effort (rfc to define the use of NAI Realm). The EAP-BRSKI flow would be something like: 1. device discovers SSID 2. network enforces 802.1x EAP-BRSKI and checks that device has an IDevID s= igned by a trusted manufacturer CA; if not deny access 3. BRSKI flow takes place at L2, with /requestvoucher being tunnelled insid= e EAP, etc. 4. Once device has completed BRSKI and has an LDevID, it gets its EAP-Succe= ss 5. AAA instructs WLC to put device in a network segment that grants it acce= ss to all required services 6. device does DHCP and we are done This is simpler than the 2 x 802.1x, 2 x DHCP above. Owen -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert Sent: Wednesday 14 February 2018 19:13 To: Michael Richardson Cc: anima@ietf.org Subject: Re: [Anima] BRSKI over 802.11 On Wed, Feb 14, 2018 at 02:08:20PM -0500, Michael Richardson wrote: > > Nancy mentioned other 802.11 options beside SSID, so maybe we shoul= d > > gate a decision to adopt any such work to the WG having sufficient > > understanding of what the existing options in 802.11 are that > > we could leverage without having to extend 802.11. Maybe we could > > draft Nancy or some other 802.11 expert to give a summary to the WG > > (802.11u eg.). >=20 > I'm willing to listen to ideas, but I'm afraid of going down the IEEE hol= e here. Maybe i was unclear. I think we should just know the whole slew of tools av= ailable from 802.11 that we can use without changing 802.11. I only know SS= ID/ESSID, so i try to figure out how to abuse oops: well use them. Nancy po= inted to more tools. > > Aka: selecting the best SSID in face of competing offers > > multiple or single AP is the type of work i think we should > > give some tthought to. Ideally something extensible > > where we can in the first spec get away with a most simple > > start but will have forward compatibility with later > > updates/extensions. >=20 > your suggestions are inline with what I was thinking. Cheers Toerless > -- > Michael Richardson , Sandelman Software Works =20 > -=3D IPv6 IoT consulting =3D- _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Thu Feb 15 12:38:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3649129C59 for ; Thu, 15 Feb 2018 12:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 S2koVRqkjFJo for ; Thu, 15 Feb 2018 12:38:07 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B76D124207 for ; Thu, 15 Feb 2018 12:38:07 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D447D58C559; Thu, 15 Feb 2018 21:38:02 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id BD352B0DA83; Thu, 15 Feb 2018 21:38:02 +0100 (CET) Date: Thu, 15 Feb 2018 21:38:02 +0100 From: Toerless Eckert To: "Max Pritikin (pritikin)" Cc: Michael Richardson , "anima@ietf.org" Message-ID: <20180215203802.GE27823@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <11878.1518662730@obiwan.sandelman.ca> <89C98637-ACD2-423A-A8C4-52191C35FA53@cisco.com> <20180215171428.GD27823@faui40p.informatik.uni-erlangen.de> <41CDDDDE-1098-4836-8338-738C02ED8F0E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41CDDDDE-1098-4836-8338-738C02ED8F0E@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 20:38:11 -0000 On Thu, Feb 15, 2018 at 05:32:30PM +0000, Max Pritikin (pritikin) wrote: > Certificates are a data format for encoding public keys and associated certifications (e.g. the CA signature) etc. I think this could reasonably be called data needed to establish a cryptographic security association. Ok, great. Then i would just love to see a definition stating keying material in the context of BRSKI includes public, private keys, certificates and vouchers. > > IMHO, I need certificates to establish (authenticate) the cryptographic security > > association when i am using certificates. Likewise would a voucher > > be keying material because it is required for authentication. > > If we???re stretching like this then sure. A voucher is a certification of a public key (the new owner) along with additional data used to interpret the certification. If you keep going down that path you???re gonna end up claiming we should have simply had an X509 extension instead of a voucher format. There are reasons we didn???t go that way but I could see a world where that happened (thankfully not our reality though). I am happy with vouchers being clearly distinguished from certificates. I just want well defined names such as what "keying material" is. Any term we can not clearly define (or point to clear definitions) should be avoided in the document. rfc4949 is IMHO not clearly defined for "keying material". > > brski keying entities = pledge + registrar + CA ( + MASA ?) > > Possible non-crypto speaker confusion: Is MASA part of keying entities ? > > If keying material is just the public key pairs, then probably not ? > > Why not? Its all part of the key infrastructure in that these are the entities (and associated protocols!) needed to manage all the key material. Again: I have no strong opinions. But yes, if certificates and vouchers where not keying material we would need yet another work that includes them. > There is something different about ???authentication key material??? and ???certification key material??? but is it necessary for us to get into those pedantic areas? Are you proposing an update to RFC4949? Where are we going with this? For the readers of BRSKI i would like to minimize the need to refer to confusing external documents, especially wrt. terminology. I am declaring myself the the expert to represent the non-native security speaking reader. For IESG security review we need to make sure that the way we're using and probably extending the existing terminology is acceptable. You're the better judge for that, and if not, you'll hear from Eric. > > But would BRSKI without a following EST part even be "keying entities??? ???? > > BRSKI and EST are protocols not ???entities???. But yes, BRSKI is a part of the key infrastructure. It is the protocol for ???bootstrapping [the] remote [portion of the] secure key infrastructure???. Sorry, yes.. > > brski keying protocols = BRSKI+ EST (pledge/registrar), EST (registrar/MASA), BRSKI-EST (registrar/MASA) > > > > brski keying infrastructure = brski keying entities + brski keying protocols > > > > Or whatever else is correct in the context of BRSKI. Better to just enumerate whats > > meant like i suggested above instead of trying generic definitions because those > > can fail on non-native crypto speakers like my above confusion with rfc4949. > > > > Also it wold be good if there was a clear understanding if BRSKI claims to expand > > the scope of any of these terms. Eg: If MASA or vouchers are now considered to > > be part of any prior existing terms such as keying material or keying infra. I > > guess that "keying protocols" are definitely expanded by BRSKI??? > > Based on the above I think its fair to say that: > > Voucher???s expand on the defined key material data types. > BRSKI protocol and MASA entity expand on the defined types of key infrastructure elements. Great. So please put into the terminology section those simple explanations of the terms used/required by BRSKI. Cheers Toerless > - max > > > > > Cheers > > Toerless > > > >> > >> - max > >> > >>> > >>>> c) (terminology) MASA definition: "A third-party Manufacturer...". Why "third-party" ? > >>>> who are the first two parties ? If this is only slang and we can't explain who the > >>>> first two parties are, delete "third-party" ? > >>> > >>> Fixed... The first party is the Pledge and manufacturer. > >>> The second party is the Domain Owner. > >>> The third party is the entity running the MASA, which may not be the manufacturer. > >>> > >>>> d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because the text mostly > >>>> uses "Domain Registrar" and very seldom "Join Registar". > >>> > >>> Yes, because we agreed that the term across WGs would be JRC, and we say > >>> in the terminology that we shorten it to Registrar. We say "Domain > >>> Registrar" because we want to link it to the PKI concept of a Registration > >>> Authority (RA). > >>> > >>>> JRC is used in exactly three places in the draft. I also can not find on www.google.com > >>>> or wikipedia any example of "The term JRC is used in common with other bootstrap > >>>> mechanisms" as the Terminology claims. Either provide a non-anima reference for the > >>>> use of that term or eliminate it in the document. > >>> > >>> We agreed to use common terms. > >>> It was a thread on ANIMA and 6tisch a year ago. > >>> I can't get mailarchive to find it for me... > >>> Ah, I see because "JRC" was never used contracted in that thread. > >>> https://mailarchive.ietf.org/arch/msg/anima/iotBM0-kxsIB66t8hBo4XUtZLag > >>> > >>> As long as they Informative references. > >>> https://tools.ietf.org/html/draft-ietf-6tisch-architecture-13#section-6.1 > >>> https://tools.ietf.org/html/draft-ietf-6tisch-terminology-09 > >>> (yes, expired, but not forgotten, just not a priority) > >>> > >>>> e) Voucher > >>>> - misses ":" after term. > >>>> - please change "statement" to "artifact" so the terminology aligns with both voucher > >>>> draft and voucher-request text which also uses artifact. See also section 2.2 > >>>> where you use "cryptographically protected" instead of "signed" and figure out > >>>> which term you want to use in all cases (hint: signed). > >>> > >>> I've changed it to: > >>> A voucher is a cryptographically protected artifact (a digital signature) to the Pledge > >>> > >>> I feel that we need to say it's cryptographically signed at least once. > >>> > >>>> f) IMPORTANT: Please add/define the term "ANI" > >>> > >>>> ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and > >>>> Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI > >>>> systems (pledges, proxies, registrar) have specific requirements detailled in > >>>> the document. > >>> > >>> The Autonomic Network Infrastructure as > >>> defined by >>> />. This document details specific requirements for pledges, > >>> proxies and registrars when they are part of an ANI. > >>> > >>> Does this work for you? > >>> > >>>> Without this term we can not nail down the explicit requirements against > >>>> ANI Pledges, Proxies, Registrars that we need from the document (and distinguish > >>>> from requirements against any non-ANI adaptation of BRSKI). I added according > >>>> comments into other parts of the doc. > >>> > >>>> g) Please replace "MASA server" with "MASA service" everywhere. > >>> > >>> I prefer to just say "MASA" actually. > >>> Are you okay with that? > >>> > >>> Let me wrap up here for the moment so you can see the edits and > >>> I'll reply to the rest as Max and I digest it. It's a lot of comments. > >>> I'd like to push an -11 (if only to fix email for M. Behringer). > >>> > >>> https://github.com/anima-wg/anima-bootstrap/pull/42 > >>> https://github.com/anima-wg/anima-bootstrap/pull/42/commits/cb7af66344ad709aaf70287a40fa13a67bbf601c > >>> > >>> > >>> -- > >>> Michael Richardson , Sandelman Software Works > >>> -= IPv6 IoT consulting =- > >>> > >>> > >>> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > -- > > --- > > tte@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Thu Feb 15 13:52:30 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A9D12D84D for ; Thu, 15 Feb 2018 13:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UMTWFq99ZNT8 for ; Thu, 15 Feb 2018 13:52:26 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C129D1200F1 for ; Thu, 15 Feb 2018 13:52:26 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C709E20090 for ; Thu, 15 Feb 2018 16:59:27 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4F89B80A5B for ; Thu, 15 Feb 2018 16:52:25 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: <151870964368.7627.3386779535404044958.idtracker@ietfa.amsl.com> References: <151870964368.7627.3386779535404044958.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] request to consider adopting draft-richardson-anima-ace-constrained-voucher-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 21:52:29 -0000 --=-=-= Content-Type: text/plain Peter, Panos and I have been working on this document along with some SID help from Michel Veillett. We'd like the ANIMA WG to consider adopting it. There are some SID issues that we hope to work out with the help of the "yot@ietf.org" list... they are minor technical issues that do not change much. Originally this work was part of draft-ietf-6tisch-zerotouch-join, and was going to be done in 6tisch directly as it had no users outside of 6tisch. That has... changed because there was a request to reuse more things. Reuse is great, but requires more coordination. Please see the diagram and explanation, which was in my enrollment-roadmap draft, but which is now at: https://trac.ietf.org/trac/int/wiki/EnrollmentRoadmap This document represents the box entited "constrained voucher (CBOR) (xxxx?)" It is used by the pink and yellow boxes. This document "inherits" (subclasses if you like), both ietf-anima-voucher (doing it in CBOR, signed by COSE or CMS), and also subclasses ietf-anima-bootstrapping-keyinfra, applying the same "diff" that BRSKI makes to EST, but applying it to ACE's EST-COAPS version of EST. I've illustrated the relationship in the second diagram in the wiki, which is also at: http://www.sandelman.ca/SSW/ietf/anima/diagrams/document-relations.svg The dotted/faded blue represents my request to have ANIMA adopt the document. Chairs: please let me know if this is something we can do sooner (before 101?), or if you think that we need an in-person discussion at 101, or if you think that it's impossible. It's not my goal to have the WG adoption call in this thread! But to determine what I need to do to get to the question being asked. Perhaps the WG will not want to adopt it. internet-drafts@ietf.org wrote: > A new version of I-D, > draft-richardson-anima-ace-constrained-voucher-03.txt has been > successfully submitted by Michael Richardson and posted to the IETF > repository. > Name: draft-richardson-anima-ace-constrained-voucher Revision: 03 > Title: Constrained Voucher Profile for Bootstrapping Protocols Document > date: 2018-02-14 Group: Individual Submission Pages: 20 URL: > https://www.ietf.org/internet-drafts/draft-richardson-anima-ace-constrained-voucher-03.txt > Status: > https://datatracker.ietf.org/doc/draft-richardson-anima-ace-constrained-voucher/ > Htmlized: > https://tools.ietf.org/html/draft-richardson-anima-ace-constrained-voucher-03 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-richardson-anima-ace-constrained-voucher-03 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-richardson-anima-ace-constrained-voucher-03 > Abstract: This document defines a strategy to securely assign a pledge > to an owner, using an artifact signed, directly or indirectly, by the > pledge's manufacturer. This artifact is known as a "voucher". > This document builds upon the work in [I-D.ietf-anima-voucher], > encoding the resulting artifact in CBOR. Use with two signature > technologies are described. > Additionally, this document explains how constrained vouchers may be > transported in the [I-D.vanderstok-ace-coap-est] protocol. > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > The IETF Secretariat -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqGARgACgkQgItw+93Q 3WWHkQf/RaIj2aOmHgTdZKi2gyCT09AsUNLPA2vblsUDHyOoMD3TtBDg9LeYscPA hDGJtevGDNTL85PM0s/Pha6Jam1llUlPSL06PjZMt9Ne5aWUz+09c6U573Ox96Zd aPdSrkFefVBfJivMKe8NK4y3qDym4edbNCImuJ+JSl+appfxtNS67mjIzSupyHyq /5vJs4fLLlxg1m8wFmKIkRU/Qm6ltN9OaYT6s12sZm4m3/DecHPm8LcqnAM+utCu k2q9veGJfhnfrH3ieGI4HIFDN7fBDmo3tIXPnniHUsHaSD6ylSH4v6IzU2Sn6AHt rR1mLk38RgqwfFe7LpEuGYMrYGU0NQ== =dD8l -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 15 14:12:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D37912D861 for ; Thu, 15 Feb 2018 14:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PiaY682Q0gDc for ; Thu, 15 Feb 2018 14:12:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDAD12D853 for ; Thu, 15 Feb 2018 14:12:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4CA7B20090; Thu, 15 Feb 2018 17:19:32 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CBF7D80706; Thu, 15 Feb 2018 17:12:29 -0500 (EST) From: Michael Richardson To: "Owen Friel \(ofriel\)" cc: Toerless Eckert , "anima\@ietf.org" , "Max Pritikin \(pritikin\)" , "Eliot Lear \(elear\)" In-Reply-To: References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> <31460.1518635300@obiwan.sandelman.ca> <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 22:12:32 -0000 --=-=-= Content-Type: text/plain Owen, thanks for the extensive email... I actually read to the end. What's this legacy "DHCP" protocol? Does anyone still use it? :-) I thought IPv4 was an over-the-top service now.. :-) :-) It seems like you have most of an ID already there... perhaps you'd like to write something up... since you seem to have thought through all the possibilities. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqGBc0ACgkQgItw+93Q 3WV3jgf/bd5c12Z7atjZJ2uyL9r4PgzbPCZV4ZzDsU1nYOCzdTCjubTQA+ndia8V fXysO8cncYpxhcCuyRPb84BpK0LTvAUiBZGgWQnlreh3NBAjKR8mhkIPhCpE+5zR qTKimYw5F1zycAUChNVM3UGGr5IRB/6+uyd69rto/sGodO6WBQfEh71IvCfqtY9w GiLZImzBd+JaCu280k3VjW77klZhQrk6M9BdwvX9SQSs6JhvnniscKBUAOnr9xon e5Tb/dJ3xNPGR+MaA7Ppxf1mn1A4MSkYb+XpoDY9QHmTKtQCFsU0Z0E6N9DJV9+n hLOjZGClR0BcfgZIeAXs90sXmukTQw== =1VON -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 15 14:44:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A19712D7EB for ; Thu, 15 Feb 2018 14:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 67M_R6H6eZXZ for ; Thu, 15 Feb 2018 14:44:25 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925C812D837 for ; Thu, 15 Feb 2018 14:44:25 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0B8C058C565; Thu, 15 Feb 2018 23:44:21 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id E4EB6B0DA78; Thu, 15 Feb 2018 23:44:20 +0100 (CET) Date: Thu, 15 Feb 2018 23:44:20 +0100 From: Toerless Eckert To: "Owen Friel (ofriel)" Cc: Michael Richardson , "anima@ietf.org" , "Max Pritikin (pritikin)" , "Eliot Lear (elear)" Message-ID: <20180215224420.GF27823@faui40p.informatik.uni-erlangen.de> References: <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> <31460.1518635300@obiwan.sandelman.ca> <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 22:44:31 -0000 Thanks, Owen, inline On Thu, Feb 15, 2018 at 07:54:48PM +0000, Owen Friel (ofriel) wrote: > (some context - I've been talking internally to Max and Eliot about this quite a bit) > > First, a high level summary of 802.11u-2011 (which is incorporated into 802.11-2016) capabilities. > > STAs and APs advertise support for 802.11u by setting the Interworking bit in the Extended Capabilities IE, and by including the Interworking IE in Beacon, Probe Request and Probe Response frames. > > The Interworking IE includes info on: > - Access Network Type (Private, Free public, Chargeable public, etc.) > - internet bit (yes/no) > - ASRA (Additional Step required for Access - e.g. this could mean EAP-TLS, or a BRSKI flow) > > 802.11u introduced ANQP Access Network Query Protocol which enables STAs to query APs for info not present in Beacons/Probe Reponses. > > ANQP defines these key IEs for enabling the STA to determine which network to connect to: > > Roaming consortium IE: includes the OI(s) of the roaming consortium(s). The OI is typically provisioned on cell phones by the SP, so the cell phone can automatically detect wifi networks that provide access to its SP's consortium. > > 3GPP Cellular Network IE: includes the Mobile Country Code (MCC) and Mobile Network Code (MNC) of the SP the AP provides access to. > > Network Access Identifier Realm IE: includes RFC4282 realm names that the AP provides access to (e.g. wifi.service-provider.com). The NAI Realm IE also includes info on the EAP type required to access that realm e.g. EAP-TLS. > > Domain name IE: the domain name(s) of the local AP operator. Its purpose is to enable a STA to connect to a domain operator that may have a more favourable pricing model for backhaul connections to the internet / SP. > > STAs can use some or all of the above IEs to make a suitable decision on which SSID to pick. > > HotSpot 2.0 is an example of a spec built on top of 802.11u and defines 10 additional ANQP elements using the standard vendor extensions mechanisms defined in 802.11. > It also defines a HS2.0 Indication element that is includes in Beacons and Probe Responses so that STAs can immediately tell if an SSID supports HS2.0. > > That's the end of the .11u intro, but I'll come back to NAI Realms in a bit. Right. I've looked at http://web.mit.edu/freebsd/head/contrib/wpa/hostapd/hostapd.conf where it shows all the parameters you could configure. If we wanted to make this applicable to BRSKI i am mostly worried that we wold need to register somehow new values for parameters that allow only predefined values. Any idea what the process for that is ? > I agree with Nancy below on splitting this into SSID discovery and connection/authentication steps. There were a few discovery options proposed in this thread, and I'll add to that: > > 1. define a well-known naming convention for BRSKI capable SSIDs e.g. BRSKI%xfinity > > This goes against the grain of .11u whose whole purpose is for STAs to make a decision on which SSID to use based on advertised capabilities, rather than SSID naming convention. Sure. But the whole world does not support 802.11u, and there is a lot of pre-existing practice to use well-known SSID names. > Additionally, operators will not want to deploy a new SSID just to enable BRSKI flows as each SSID eats up air space and wifi channel capacity due to beacon overheads, etc. It would be better to add the relevant bits to the AQNP for an existing SSID. From the operator perspective, that's modifying the config of an existing SSID rather than deploying a new one. Yes. The technical argument in favor of separate SSID is that it does not change the security model of existing SSIDs. Ideally, we wold want unencrypted SSID for BRSKI because we rely on the application layer crypto of the TSL level and the voucher. The typical use case would be that you want to allow for devices to use BRSKI to enroll into a service, and the service itself uses some 802.11 crypto for which you need the LDevID that you only get through BRSKI+EST. Can you quantify the overhead of an SSID ? You can exclude the artifical overhead created by vendors like Cisco (could be Huawei too) like "you can only configure N SSID on the AP, if you want more, you have to pay more". > 2. Leverage existing 802.11u > > It appears as if NAI Realm could be a possible mechanism for advertising BRSKI capability (and Roaming consortium, 3GPP cellular network are not). We could possibly piggy back on top of NAI Realm and advertise a realm of simply "_bootstrapks". WLCs certainly appear to allow this kind of configuration (although today some WLCs tie .11u configuration to HS2.0 configuration i.e. you cannot enable advertising 802.11u bits without also advertising HS2.0 in Beacons - but thats a WLC implementation gap not a standards gap). > > The key conceptual difference is that we are using this special realm name more as a logical service advertisement rather than as a backhaul internet provider advertisement. This would not require any 802.11 IEEE spec changes, but could fall into the realm of IETF spec definition. i.e. if you configure your existing wifi network using existing 802.11u mechanisms to advertise this NAI Realm, then IoT devices will know that this SSID offers BRSKI services. Aka; NAI realm is your proposal for a 802.11u atribute that allow values without registration == no IETF process, and it could logically be argued how BRSKI is a NAI realm. Again, see above: My primary concern is how i can combine BRSKI with no 802.11 crypto with a service afterwards that uses 802.11 crypto. Using a single SSID. AFAIK, you can not have multiple crypto options on an SSID, or at least it would considered to be highly problematic to allows non-802.11 crypto based BRSKI on an SSID that otherwise should have 802.11 crypto. > Additionally (or alternatively...) as NAI Realm includes advertising the EAP mechanism required, if a new EAP-BRSKI were to be defined, then this could be advertised. STAs could just scan for an NAI Realm that enforced EAP-BRSKI, and ignore the realm name. > > One big issue with this is Eliot's point about "a business in an office building on the 10th floor in New York City or London, where you might hear 2 dozen different networks". The STA ends up scanning a lot of SSIDs, and it may find multiple SSIDs that advertise EAP-BRSKI or NAI Realm "_bootstrapks". It would have to attempt to join all of them in sequence, and rely on the operator configuring their network such that the manufacturer IDevID CA or the specific IDevID is not trusted and rejects the device. It could also result in the STA joining the wrong SSID, which would not be ideal. Yes. This is a problem independent of 802.11, just most likely to be happening with 802.11. It would be great if we could tackle this problem, but IMHO a draft doing that should not be specific to 802.11 because i feel a lot of what we could/should do here could expand beyond 802.11 > 3. Define new 802.11u extensions > > Similar to HS2.0, we define a new BRSKI Indication Element that is advertised in Beacons, and then define any additional AQNP elements as are required. This is likely a standards body quagmire (and would also requires significant infrastructure / WLC development if that's a consideration...) Right. > 4. Use / Extend WPS > > None of the existing WPS mechanism are really suitable (PIN, push button, NFC, USB). Extending WPS, similar to defining new 802.11u extensions, seems like a standards body quagmire. Defining a new EAP-BRSKI mechanism seems more tractable. Well, not sure if you followed anima mailing list a few years back when we had that discussion, i also had a lot of OOB discussions about that, but i would always try to avoid going down that path if i can find a feasible solution not requireing any IEEE level work. > 5. Use WiFi Device Provisioning Protocol (Eliot suggested this one) > > Some comments on briefly reviewing this. At a high level, if we have a bootstrapping Thing trying to discover and connect to an AP (with no one doing supervision/handholding via a mobile app or anything), then the Thing is the DPP Enrolee and the AP is the DPP Configurator. Additionally, the AP must initiate the DPP exchange and not the Thing (the Thing must be the DPP responder) because as per DPP, the Initiator must know in advance and validate the bootstrapping public key (which would be the public key of the IDevID I guess)of the Responder. This means that the AP must be continuously polling for Things that it wants to bootstrap (and the Thing must be cycling through all channels listening for a DPP initiation request, similar to standard SSID passive scanning) . It needs further thought if this has any channel capacity implications. The DPP groupId is meant to help with this I think... Well. Would be happy to get more of a debrief of the details of DPP to figure out applicability without modification of IEEE level standards. > One big advantage of this is that the Thing is not attempting (and potentially failing, or worse - succeeding to connect to the wrong SSID) to connect to a large number of SSIDs unlike option 2 NAI Realm. It also means that an operator should not inadvertently claim someone else's Thing as it should be unlikely that two Things will have identical bootstrapping public keys. How would that work in the face of multi-operator domains supported by the AP ? Aka: on my home AP i can have xfinity and my own home network service, and we would not want to assume coordination betwen them about which of the two domain should claim a device. > Anyways, once the device somehow knows the SSID, it can begin connection and authentication. > > There have been comments that pre-completing BRSKI, the client must connect to an unsecure network. That's not entirely true. The network could in fact enforce 802.1x and EAP-TLS based on the manufacturer's cert / IDevID. I am somewhat cautious as to how easy it would be to get all the necessary bits implemented in APs to support that approach without impacting the pre-existing SSID security. For example, if this requires to know something about IDevIDs on the radius server, and radius server upgrades, then it IMHO a nogo. > Similarly, if an EAP-BRSKI mechanism were to be defined, the network could deny access and not even allow the client to send its /requestvoucher unless it successfully completed the initial TLS and presented a trusted IDevID. So it could be a bootstrapping network segment that allows devices from trusted manufacturers. That seems like a better alternative to using WPA-PSK with a known network key or WAP-802.1x with a known username/password (both of which require somehow provisioning that key into the device). > > And on defining a new EAP-BRSKI mechanism, it should be possible to achieve today what EAP-BRSKI would enable, albeit with 2 x 802.1x, 2 x DHCP requests. A flow could be: > > 1. device discovers SSID > 2. network enforces 802.1x EAP-TLS and checks that device has an IDevID signed by a trusted manufacturer CA; if not deny access > 3. AAA instructs WLC to put device in a network segment that grants it access to the Registrar and nothing else > 4. device does DHCP, gets and IP, and does the BRSKI dance and uses its IDevID to get an LDevID > 5. Once device has an LDevID, it does DHCP Release and an EAPOL-Logoff > 6. Device restarts 802.1x > 7. network enforces 802.1x EAP-TLS and this time checks that device has a trusted LDevID > 8. AAA instructs WLC to put device in a network segment that grants it access to all required services > 9. device does DHCP and we are done > > Not saying that that complex flow is desirable, the 2x 802.1x and 2x DHCP will make constrained Things baulk, but its feasible. And if we were to say use the NAI Realms "_bootstrapks" mechanism, we could in theory build that solution out now with no infrastructure revs, and with minimal standardisations effort (rfc to define the use of NAI Realm). This is getting back to the discussion i referred to a few years back. > The EAP-BRSKI flow would be something like: > > 1. device discovers SSID > 2. network enforces 802.1x EAP-BRSKI and checks that device has an IDevID signed by a trusted manufacturer CA; if not deny access > 3. BRSKI flow takes place at L2, with /requestvoucher being tunnelled inside EAP, etc. > 4. Once device has completed BRSKI and has an LDevID, it gets its EAP-Success > 5. AAA instructs WLC to put device in a network segment that grants it access to all required services > 6. device does DHCP and we are done > > This is simpler than the 2 x 802.1x, 2 x DHCP above. Cheers toerless > > Owen > > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: Wednesday 14 February 2018 19:13 > To: Michael Richardson > Cc: anima@ietf.org > Subject: Re: [Anima] BRSKI over 802.11 > > On Wed, Feb 14, 2018 at 02:08:20PM -0500, Michael Richardson wrote: > > > Nancy mentioned other 802.11 options beside SSID, so maybe we should > > > gate a decision to adopt any such work to the WG having sufficient > > > understanding of what the existing options in 802.11 are that > > > we could leverage without having to extend 802.11. Maybe we could > > > draft Nancy or some other 802.11 expert to give a summary to the WG > > > (802.11u eg.). > > > > I'm willing to listen to ideas, but I'm afraid of going down the IEEE hole here. > > Maybe i was unclear. I think we should just know the whole slew of tools available from 802.11 that we can use without changing 802.11. I only know SSID/ESSID, so i try to figure out how to abuse oops: well use them. Nancy pointed to more tools. > > > > Aka: selecting the best SSID in face of competing offers > > > multiple or single AP is the type of work i think we should > > > give some tthought to. Ideally something extensible > > > where we can in the first spec get away with a most simple > > > start but will have forward compatibility with later > > > updates/extensions. > > > > your suggestions are inline with what I was thinking. > > Cheers > Toerless > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Feb 16 05:16:59 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB21127286 for ; Fri, 16 Feb 2018 05:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6hUFAmCmVgv for ; Fri, 16 Feb 2018 05:16:54 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EAC127023 for ; Fri, 16 Feb 2018 05:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20688; q=dns/txt; s=iport; t=1518787014; x=1519996614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Fe5ivp+5IUICQa++hCo8xcQ9/tE0CIzIphsNX5fkcjc=; b=coTUA8TcP+rqAdmvQfXrdKBmfzuwJtL9G88D6i0nzK6irGQf6sAcSGYm D7/Ee9XyHyOYNtJZZ5J6WG2w7d3vNr6i/ylxLUpN6O0hnwIbHN2L6MjRH IBzFEU7sbUmPcAtPZ222w2EA/sMYEti4NKZFEkNuvkikTfBp8AF3cT0aI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAQAk2YZa/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMeBC1mcCgKjW+OAoICgReWSYIWChgPgVqDOgKCRVQYAQIBAQE?= =?us-ascii?q?BAQECayhCEAGEUAEBAQEBAQEBATgxAwMIBQcEAgEIDgMEAQEBGAYJBycLFAkIA?= =?us-ascii?q?gQOBQgTiX4IELALgUKHOYITAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYUEgQ6BGoF?= =?us-ascii?q?XgWiCIAGBDYMwAQEBAYFIBA0GAx0+hS4FinyHVodaigkJAogijV2CKYpDh2WOB?= =?us-ascii?q?oZhgwsCERkBgTsBHzmBUXAVOoJDCYJLHIEKAQIKb3gBg22HRAIFHgIHgQaBGQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.46,519,1511827200"; d="scan'208";a="71174850" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2018 13:16:52 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1GDGq2Z027119 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Feb 2018 13:16:52 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 16 Feb 2018 07:16:51 -0600 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Fri, 16 Feb 2018 07:16:51 -0600 From: "Owen Friel (ofriel)" To: Toerless Eckert CC: Michael Richardson , "anima@ietf.org" , "Max Pritikin (pritikin)" , "Eliot Lear (elear)" Thread-Topic: [Anima] BRSKI over 802.11 Thread-Index: AQHTpbS80kr8dImS10GyGhws45k3TKOkp4YAgAABSoCAATh3oIAAlO0AgAB6UIA= Date: Fri, 16 Feb 2018 13:16:51 +0000 Message-ID: References: <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> <31460.1518635300@obiwan.sandelman.ca> <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> <20180215224420.GF27823@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180215224420.GF27823@faui40p.informatik.uni-erlangen.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.8.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 13:16:58 -0000 Inline Toerless. -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de]=20 Sent: Thursday 15 February 2018 22:44 To: Owen Friel (ofriel) Cc: Michael Richardson ; anima@ietf.org; Max Pritiki= n (pritikin) ; Eliot Lear (elear) Subject: Re: [Anima] BRSKI over 802.11 Thanks, Owen, inline On Thu, Feb 15, 2018 at 07:54:48PM +0000, Owen Friel (ofriel) wrote: > (some context - I've been talking internally to Max and Eliot about=20 > this quite a bit) >=20 > First, a high level summary of 802.11u-2011 (which is incorporated into 8= 02.11-2016) capabilities. >=20 > STAs and APs advertise support for 802.11u by setting the Interworking bi= t in the Extended Capabilities IE, and by including the Interworking IE in = Beacon, Probe Request and Probe Response frames. >=20 > The Interworking IE includes info on: > - Access Network Type (Private, Free public, Chargeable public, etc.) > - internet bit (yes/no) > - ASRA (Additional Step required for Access - e.g. this could mean=20 > EAP-TLS, or a BRSKI flow) >=20 > 802.11u introduced ANQP Access Network Query Protocol which enables STAs = to query APs for info not present in Beacons/Probe Reponses. >=20 > ANQP defines these key IEs for enabling the STA to determine which networ= k to connect to: >=20 > Roaming consortium IE: includes the OI(s) of the roaming consortium(s). T= he OI is typically provisioned on cell phones by the SP, so the cell phone= can automatically detect wifi networks that provide access to its SP's con= sortium. >=20 > 3GPP Cellular Network IE: includes the Mobile Country Code (MCC) and Mobi= le Network Code (MNC) of the SP the AP provides access to. >=20 > Network Access Identifier Realm IE: includes RFC4282 realm names that the= AP provides access to (e.g. wifi.service-provider.com). The NAI Realm IE a= lso includes info on the EAP type required to access that realm e.g. EAP-TL= S. >=20 [ofriel] One other comment on NAI Realms, WLCs often place artificial restr= ictions on the numbers of these than can be configured. 802.11 allows 2x oc= tet count of realms, but WLCs could only allow e.g. 32. Additionally, big m= obile SPs often have dozens of roaming partners, and these guys tend to use= a single Roaming consortium OI instead of NAI Realms. > Domain name IE: the domain name(s) of the local AP operator. Its purpose = is to enable a STA to connect to a domain operator that may have a more fav= ourable pricing model for backhaul connections to the internet / SP. >=20 > STAs can use some or all of the above IEs to make a suitable decision on = which SSID to pick. >=20 > HotSpot 2.0 is an example of a spec built on top of 802.11u and defines 1= 0 additional ANQP elements using the standard vendor extensions mechanisms = defined in 802.11. > It also defines a HS2.0 Indication element that is includes in Beacons an= d Probe Responses so that STAs can immediately tell if an SSID supports HS2= .0. >=20 > That's the end of the .11u intro, but I'll come back to NAI Realms in a b= it. Right. I've looked at http://web.mit.edu/freebsd/head/contrib/wpa/hostapd/h= ostapd.conf where it shows all the parameters you could configure. If we wanted to make= this applicable to BRSKI i am mostly worried that we wold need to register= somehow new values for parameters that allow only predefined values. [ofriel] Well, if we went down the path of using NAI Realms for BRSKI, NAI = Realms already allows entry of free-form domains. It doesn't have pre-defin= ed values for NAI Realms. What would be needed is some registry where we de= fine the well-known NAI Realm that should be configured on the WLC. That wo= uldn't require IEEE changes. And that value could be defined in an IETF dra= ft that points to an IANA registry..? [ofriel] That hostapd.conf file has a section " # NAI Realm information " o= utlining how to configure these, it also allows specification of the EAP Me= thod Type, with that value being taken from the IANA registry. It gives exa= mples for 13 (EAP-TLS) and 21 (EAP-TTLS) so if a EAP-BRSKI method were defi= ned, that hostapd.conf already supports that type of config. Any idea what the process for that is ? [ofriel] If we wanted to e.g. advertise a new value for the Access Network = Type bits in the Access Network Options octet in the Interworking IE, that'= s IEEE work I guess. If we wanted to define a new vendor extension IE (simi= lar to HS2.0) then that's.. Wi-Fi alliance work..? > I agree with Nancy below on splitting this into SSID discovery and connec= tion/authentication steps. There were a few discovery options proposed in t= his thread, and I'll add to that: >=20 > 1. define a well-known naming convention for BRSKI capable SSIDs e.g.=20 > BRSKI%xfinity >=20 > This goes against the grain of .11u whose whole purpose is for STAs to ma= ke a decision on which SSID to use based on advertised capabilities, rather= than SSID naming convention. Sure. But the whole world does not support 802.11u, and there is a lot of p= re-existing practice to use well-known SSID names. [ofriel] By pre-existing practice, are you primarily referring to e.g. hote= l 'guest' or 'internet' SSIDs? Are there other use cases defined in specs f= or example? > Additionally, operators will not want to deploy a new SSID just to enable= BRSKI flows as each SSID eats up air space and wifi channel capacity due t= o beacon overheads, etc. It would be better to add the relevant bits to the= AQNP for an existing SSID. From the operator perspective, that's modifying= the config of an existing SSID rather than deploying a new one. Yes. The technical argument in favor of separate SSID is that it does not c= hange the security model of existing SSIDs. Ideally, we wold want unencrypt= ed SSID for BRSKI because we rely on the application layer crypto of the TS= L level and the voucher. The typical use case would be that you want to all= ow for devices to use BRSKI to enroll into a service, and the service itsel= f uses some 802.11 crypto for which you need the LDevID that you only get t= hrough BRSKI+EST. [ofriel] By configuring suitable AAA policy, we could possibly have our cak= e and eat it. Devices/BRSKI Pledges connect to a secure network enforcing s= ome kind of 802.1x password-less authentication such as EAP-TLS, and ignore= the infrastructure cert presented in the initial 802.1x EAP until after th= e BRSKI flow is complete (very similar to what the existing BRSKI draft doe= s). And the AAA can determine based on the LDevID what to do with the boots= trapping device. Can you quantify the overhead of an SSID ? You can exclude the artifical ov= erhead created by vendors like Cisco (could be Huawei too) like "you can on= ly configure N SSID on the AP, if you want more, you have to pay more". [ofriel] Here is an SSID overhead calculator: http://www.revolutionwifi.net= /revolutionwifi/p/ssid-overhead-calculator.html I'll also quote from two WLC recommended best practices as I do not claim b= y any means to be an expert here: https://www.cisco.com/c/en/us/td/docs/wireless/technology/wlc/8-5/82463-wlc= -config-best-practice.html#pgfId-390434 " RF pollution increases as more SSIDs are added. Also, some smaller wirele= ss stations such as PDA, WiFi Phones, and barcode scanners cannot cope with= a high number of basic SSID (BSSID) information. This results in lockups, = reloads, or association failures. Also, the more SSIDs, the more beaconing = needed, which results in less RF time for real data transmits. It is recomm= ended to have one to three SSIDs for an enterprise, and one SSID for high-d= ensity designs. AAA override can be leveraged for per user VLAN/settings on= a single SSID scenario. " http://www.arubanetworks.com/assets/vrd/Aruba_VHD_VRD_Engineering_Configura= tion_Guide.pdf "Airtime is an extremely limited resource. To maximize performance, you mus= t use the absolute minimum number of SSIDs. When SSIDs are created for specific user groups such as st= aff or press or ticketing, they generate significant additional beacon traffic throughout the area, which l= eaves less airtime for actual user traffic." > 2. Leverage existing 802.11u >=20 > It appears as if NAI Realm could be a possible mechanism for advertising = BRSKI capability (and Roaming consortium, 3GPP cellular network are not). W= e could possibly piggy back on top of NAI Realm and advertise a realm of si= mply "_bootstrapks". WLCs certainly appear to allow this kind of configurat= ion (although today some WLCs tie .11u configuration to HS2.0 configuration= i.e. you cannot enable advertising 802.11u bits without also advertising H= S2.0 in Beacons - but thats a WLC implementation gap not a standards gap). >=20 > The key conceptual difference is that we are using this special realm nam= e more as a logical service advertisement rather than as a backhaul interne= t provider advertisement. This would not require any 802.11 IEEE spec chang= es, but could fall into the realm of IETF spec definition. i.e. if you conf= igure your existing wifi network using existing 802.11u mechanisms to adver= tise this NAI Realm, then IoT devices will know that this SSID offers BRSKI= services. Aka; NAI realm is your proposal for a 802.11u atribute that allow values wi= thout registration =3D=3D no IETF process, and it could logically be argued= how BRSKI is a NAI realm. [ofriel] Well, wouldn't it require some formal spec to register "_bootstrap= ks" as the correct value to configure in the NAI Realm? This would need to = be baked into device firmware. Once could possibly see this is a pre-canned= option in WLC config. Again, see above: My primary concern is how i can combine BRSKI with no 802= .11 crypto with a service afterwards that uses 802.11 crypto. Using a singl= e SSID. AFAIK, you can not have multiple crypto options on an SSID, or at l= east it would considered to be highly problematic to allows non-802.11 cryp= to based BRSKI on an SSID that otherwise should have 802.11 crypto. [ofriel] I think this could be possible via backend AAA config policy if yo= u uses 802.11 and 802.1x. I plan on deploying a WLC and AAA to test this th= eory, hopefully before IETF 101... > Additionally (or alternatively...) as NAI Realm includes advertising the = EAP mechanism required, if a new EAP-BRSKI were to be defined, then this co= uld be advertised. STAs could just scan for an NAI Realm that enforced EAP-= BRSKI, and ignore the realm name. >=20 > One big issue with this is Eliot's point about "a business in an office b= uilding on the 10th floor in New York City or London, where you might hear = 2 dozen different networks". The STA ends up scanning a lot of SSIDs, and i= t may find multiple SSIDs that advertise EAP-BRSKI or NAI Realm "_bootstrap= ks". It would have to attempt to join all of them in sequence, and rely on = the operator configuring their network such that the manufacturer IDevID CA= or the specific IDevID is not trusted and rejects the device. It could als= o result in the STA joining the wrong SSID, which would not be ideal. Yes. This is a problem independent of 802.11, just most likely to be happen= ing with 802.11. It would be great if we could tackle this problem, but IMHO a draft doing t= hat should not be specific to 802.11 because i feel a lot of what we could/= should do here could expand beyond 802.11 [ofriel] Right. It would be good to frame the problem by identifying 2 or 3= specific deployment options (802.11 being one of those) and see if a commo= n solution could be found. > 3. Define new 802.11u extensions >=20 > Similar to HS2.0, we define a new BRSKI Indication Element that is=20 > advertised in Beacons, and then define any additional AQNP elements as=20 > are required. This is likely a standards body quagmire (and would also=20 > requires significant infrastructure / WLC development if that's a=20 > consideration...) Right. > 4. Use / Extend WPS >=20 > None of the existing WPS mechanism are really suitable (PIN, push button,= NFC, USB). Extending WPS, similar to defining new 802.11u extensions, seem= s like a standards body quagmire. Defining a new EAP-BRSKI mechanism seems = more tractable. Well, not sure if you followed anima mailing list a few years back when we = had that discussion, i also had a lot of OOB discussions about that, but i = would always try to avoid going down that path if i can find a feasible sol= ution not requireing any IEEE level work. [ofriel] No, not aware of prior discussions on this. Any pointers to the sp= ecific threads on the mailers you could provide so I can brush up would be = appreciated.. > 5. Use WiFi Device Provisioning Protocol (Eliot suggested this one) >=20 > Some comments on briefly reviewing this. At a high level, if we have a bo= otstrapping Thing trying to discover and connect to an AP (with no one doin= g supervision/handholding via a mobile app or anything), then the Thing is = the DPP Enrolee and the AP is the DPP Configurator. Additionally, the AP mu= st initiate the DPP exchange and not the Thing (the Thing must be the DPP r= esponder) because as per DPP, the Initiator must know in advance and valida= te the bootstrapping public key (which would be the public key of the IDevI= D I guess)of the Responder. This means that the AP must be continuously pol= ling for Things that it wants to bootstrap (and the Thing must be cycling t= hrough all channels listening for a DPP initiation request, similar to stan= dard SSID passive scanning) . It needs further thought if this has any chan= nel capacity implications. The DPP groupId is meant to help with this I thi= nk... Well. Would be happy to get more of a debrief of the details of DPP to figu= re out applicability without modification of IEEE level standards. [ofriel] Maybe Eliot can help here. I only read DPP for the first time last= week. > One big advantage of this is that the Thing is not attempting (and potent= ially failing, or worse - succeeding to connect to the wrong SSID) to conne= ct to a large number of SSIDs unlike option 2 NAI Realm. It also means that= an operator should not inadvertently claim someone else's Thing as it shou= ld be unlikely that two Things will have identical bootstrapping public key= s. How would that work in the face of multi-operator domains supported by the = AP ? Aka: on my home AP i can have xfinity and my own home network service,= and we would not want to assume coordination betwen them about which of th= e two domain should claim a device. [ofriel] That is a good question! > Anyways, once the device somehow knows the SSID, it can begin connection = and authentication. >=20 > There have been comments that pre-completing BRSKI, the client must conne= ct to an unsecure network. That's not entirely true. The network could in f= act enforce 802.1x and EAP-TLS based on the manufacturer's cert / IDevID. I am somewhat cautious as to how easy it would be to get all the necessary = bits implemented in APs to support that approach without impacting the pre-= existing SSID security. For example, if this requires to know something abo= ut IDevIDs on the radius server, and radius server upgrades, then it IMHO a= nogo. [ofriel] Is the nogo about having to upgrade the AAA server to support new = functionality, or the nogo about having to reconfigure the AAA using existi= ng functionality? The former should be avoided if at all possible, but I do= n't see how the latter can be avoided... Having the AAA know about the IDev= ID manufacturer signing CA should fall into the realms of reconfiguring the= AAA. > Similarly, if an EAP-BRSKI mechanism were to be defined, the network coul= d deny access and not even allow the client to send its /requestvoucher unl= ess it successfully completed the initial TLS and presented a trusted IDevI= D. So it could be a bootstrapping network segment that allows devices from = trusted manufacturers. That seems like a better alternative to using WPA-PS= K with a known network key or WAP-802.1x with a known username/password (bo= th of which require somehow provisioning that key into the device). >=20 > And on defining a new EAP-BRSKI mechanism, it should be possible to achie= ve today what EAP-BRSKI would enable, albeit with 2 x 802.1x, 2 x DHCP requ= ests. A flow could be: >=20 > 1. device discovers SSID > 2. network enforces 802.1x EAP-TLS and checks that device has an=20 > IDevID signed by a trusted manufacturer CA; if not deny access 3. AAA=20 > instructs WLC to put device in a network segment that grants it access=20 > to the Registrar and nothing else 4. device does DHCP, gets and IP,=20 > and does the BRSKI dance and uses its IDevID to get an LDevID 5. Once=20 > device has an LDevID, it does DHCP Release and an EAPOL-Logoff 6.=20 > Device restarts 802.1x 7. network enforces 802.1x EAP-TLS and this=20 > time checks that device has a trusted LDevID 8. AAA instructs WLC to=20 > put device in a network segment that grants it access to all required=20 > services 9. device does DHCP and we are done >=20 > Not saying that that complex flow is desirable, the 2x 802.1x and 2x DHCP= will make constrained Things baulk, but its feasible. And if we were to sa= y use the NAI Realms "_bootstrapks" mechanism, we could in theory build tha= t solution out now with no infrastructure revs, and with minimal standardis= ations effort (rfc to define the use of NAI Realm). This is getting back to the discussion i referred to a few years back. [ofriel] Well, that flow above about is enabling BRSKI without defining a n= ew EAP-BRSKI mechanism and just leveraging existing EAP-TLS and existing AA= A policy flexibility. The flow below relies on a new EAP-BRSKI mechanism > The EAP-BRSKI flow would be something like: >=20 > 1. device discovers SSID > 2. network enforces 802.1x EAP-BRSKI and checks that device has an=20 > IDevID signed by a trusted manufacturer CA; if not deny access 3. BRSKI f= low takes place at L2, with /requestvoucher being tunnelled inside EAP, etc= . > 4. Once device has completed BRSKI and has an LDevID, it gets its=20 > EAP-Success 5. AAA instructs WLC to put device in a network segment=20 > that grants it access to all required services 6. device does DHCP and=20 > we are done >=20 > This is simpler than the 2 x 802.1x, 2 x DHCP above. Cheers toerless >=20 > Owen >=20 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless=20 > Eckert > Sent: Wednesday 14 February 2018 19:13 > To: Michael Richardson > Cc: anima@ietf.org > Subject: Re: [Anima] BRSKI over 802.11 >=20 > On Wed, Feb 14, 2018 at 02:08:20PM -0500, Michael Richardson wrote: > > > Nancy mentioned other 802.11 options beside SSID, so maybe we sho= uld > > > gate a decision to adopt any such work to the WG having sufficien= t > > > understanding of what the existing options in 802.11 are that > > > we could leverage without having to extend 802.11. Maybe we could > > > draft Nancy or some other 802.11 expert to give a summary to the = WG > > > (802.11u eg.). > >=20 > > I'm willing to listen to ideas, but I'm afraid of going down the IEEE h= ole here. >=20 > Maybe i was unclear. I think we should just know the whole slew of tools = available from 802.11 that we can use without changing 802.11. I only know = SSID/ESSID, so i try to figure out how to abuse oops: well use them. Nancy = pointed to more tools. >=20 > > > Aka: selecting the best SSID in face of competing offers > > > multiple or single AP is the type of work i think we should > > > give some tthought to. Ideally something extensible > > > where we can in the first spec get away with a most simple > > > start but will have forward compatibility with later > > > updates/extensions. > >=20 > > your suggestions are inline with what I was thinking. >=20 > Cheers > Toerless >=20 > > -- > > Michael Richardson , Sandelman Software Works=20 > > -=3D IPv6 IoT consulting =3D- >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Feb 16 05:41:47 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9908126CBF for ; Fri, 16 Feb 2018 05:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRdDNfd5zR9r for ; Fri, 16 Feb 2018 05:41:42 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5A01243F6 for ; Fri, 16 Feb 2018 05:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1369; q=dns/txt; s=iport; t=1518788502; x=1519998102; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vh6/DpwhHRhQ/BAQBLxNIa1SZTGHcNjAohrfWSuGSaw=; b=T5X+fN2RvfdEo8g5EeJlIcMYCa+Ty7gf/Py7nT57mkNbMEhxTf0fpYIR h4+zxpyRWnskZHpWDXxuWYssHS2X5Wg8zbWT8bCu7GS48eqXQzQkOuaX1 b/YMoYgZc6SNFJYDtn82K/Hy0svv2H5+1gF8wAQEE9eo5+BjRqkMnhtkE A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AQBG34Za/40NJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPgVYoCo1vjgKCAoEXlkkUggIKggGDOgKCRlQYAQIBAQE?= =?us-ascii?q?BAQECayiFIwEBAQEDOj8MBAIBCBEEAQEfCQcyFAkIAgQOBQiKGbAbiHuCEwE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAR2FBIIogVeBaIMuhHABEgGGGwWkNQkClX+?= =?us-ascii?q?CKYpDh2WXcgIRGQGBOwEfOWBxcBWCfYJUHIIGeItBgSWBGQEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,519,1511827200"; d="scan'208";a="359794574" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2018 13:41:41 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w1GDffBn012785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Feb 2018 13:41:41 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 16 Feb 2018 07:41:40 -0600 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Fri, 16 Feb 2018 07:41:40 -0600 From: "Owen Friel (ofriel)" To: Michael Richardson CC: Toerless Eckert , "anima@ietf.org" , "Max Pritikin (pritikin)" , "Eliot Lear (elear)" Thread-Topic: [Anima] BRSKI over 802.11 Thread-Index: AQHTpbS80kr8dImS10GyGhws45k3TKOkp4YAgAABSoCAATh3oIAAjAeAgACdrhA= Date: Fri, 16 Feb 2018 13:41:40 +0000 Message-ID: References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> <31460.1518635300@obiwan.sandelman.ca> <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> <7255.1518732749@obiwan.sandelman.ca> In-Reply-To: <7255.1518732749@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.8.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 13:41:44 -0000 -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 Sent: Thursday 15 February 2018 22:12 To: Owen Friel (ofriel) Cc: Toerless Eckert ; anima@ietf.org; Max Pritikin (pritikin= ) ; Eliot Lear (elear) Subject: Re: [Anima] BRSKI over 802.11 Owen, thanks for the extensive email... I actually read to the end. What's this legacy "DHCP" protocol? Does anyone still use it? :-) I though= t IPv4 was an over-the-top service now.. :-) :-) It seems like you have most of an ID already there... perhaps you'd like to= write something up... since you seem to have thought through all the possi= bilities. [ofriel] I think a more comprehensive analysis of the various SSID discover= options (DPP, hardcoded SSID, NAI Realm,..) and how each fits into the two= post-SSID discovery options of (i) a new EAP-BRSKI vs. (ii) reuse of EAP-T= LS (or some suitable EAP method, possibly with 2x 80.1x exchanges) is neede= d before any consensus on the contents of an ID is necessary. Unless you ar= e suggesting than an initial ID merely outlines the multiple options but ma= kes no final recommendation yet. Happy to get started on that... -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Fri Feb 16 08:43:09 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C1D126BF6 for ; Fri, 16 Feb 2018 08:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 cA1UXMPfRM8Q for ; Fri, 16 Feb 2018 08:43:05 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A1C12762F for ; Fri, 16 Feb 2018 08:43:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AE9CB20090; Fri, 16 Feb 2018 11:50:09 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 66D2E80BCA; Fri, 16 Feb 2018 11:43:04 -0500 (EST) From: Michael Richardson To: "Owen Friel \(ofriel\)" cc: Toerless Eckert , "anima\@ietf.org" , "Max Pritikin \(pritikin\)" , "Eliot Lear \(elear\)" In-Reply-To: References: <32587.1518019185@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF4177B@lhreml501-mbx> <11509.1518030390@obiwan.sandelman.ca> <8DA547FB1280754AAC43A3E56DCB7AD20AF418D1@lhreml501-mbx> <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> <31460.1518635300@obiwan.sandelman.ca> <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> <7255.1518732749@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 16:43:07 -0000 --=-=-= Content-Type: text/plain Owen Friel (ofriel) wrote: > [ofriel] I think a more comprehensive analysis of the various SSID > discover options (DPP, hardcoded SSID, NAI Realm,..) and how each fits > into the two post-SSID discovery options of (i) a new EAP-BRSKI > vs. (ii) reuse of EAP-TLS (or some suitable EAP method, possibly with > 2x 80.1x exchanges) is needed before any consensus on the contents of > an ID is necessary. Unless you are suggesting than an initial ID merely > outlines the multiple options but makes no final recommendation > yet. Happy to get started on that... Yes... the point of the ID would be to layout the options.... The options-not-selected would go into an appendix of a final document to explain paths not taken. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqHChcACgkQgItw+93Q 3WUX6ggAqxY664yJUtOpCt1srGLB8Jj3Q5fpwnQyONxsDTT8MPMQKO3DSH0Mvp5u wkAw1Mo2M7WUJ/Fd3B3oSJezqgzBMXc3x0S/Ok9mMGG+KiLW3EsTPlnveV/zqOEC wmNq7PaK32IXFhB47LZ725wb3TyLips+6zQlM4czKNQbbDFSddveRek4tzNZiCaX 6WKr51OLQtYzwSxJjgEGV47/oY6Aeg/hC0zti08zFLNAuGYbsHouiPN27n01ZgTx 3IzkMNk0I93PDX32w+aPf4BNLXcul22wmVuJCnVwmwuwusT7EkAz42J0lZ4bGMrc Jj22Afs/RWLNa3DfqFMcyylGhxw2Lw== =wDJi -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 16 10:00:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF63129C6B for ; Fri, 16 Feb 2018 10:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 9CxlyBi855O6 for ; Fri, 16 Feb 2018 10:00:36 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A535124C27 for ; Fri, 16 Feb 2018 10:00:36 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 129CB58C4B8; Fri, 16 Feb 2018 19:00:32 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id E4CA4B0DA9A; Fri, 16 Feb 2018 19:00:31 +0100 (CET) Date: Fri, 16 Feb 2018 19:00:31 +0100 From: Toerless Eckert To: Michael Richardson Cc: "Owen Friel (ofriel)" , "Max Pritikin (pritikin)" , "Eliot Lear (elear)" , "anima@ietf.org" Message-ID: <20180216180031.GG27823@faui40p.informatik.uni-erlangen.de> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> <31460.1518635300@obiwan.sandelman.ca> <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> <7255.1518732749@obiwan.sandelman.ca> <3188.1518799384@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3188.1518799384@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 18:00:39 -0000 I am not even sure we would need to come up with just one permitted option. The two directions i see now from Owens input: a) "enterprise" Model. Relying on AAA server to be able to authenticate Pledges based on e.g.: EAP-TLS with IDevID as auth. No additional SSID needed. Should try to also announce 802.11u GAS, but need to figure out if/how this would work in the face of multiple SSIDs supported (aka: multi-domain). b) SSID approach - can work without any change to 802.11 infra, just put BRSKI proxy on the BRSKI VLAN. - Work without AAA, e.g.: PSK (home AP). - multi-domain, no 802.11u support needed (unclear how ubiquitous that is). Single domain mode where AP has only one domain offering BRSKI, BRSKI SSID is just called BRSKI%%, no beacon sent (called "hidden" in most UIs). Connects only to BRSKI Proxy, carries only BRKSI traffic therefore. Multiple 's on an AP, each one wanting to offer BRSKI, second and further SSID have to be renamed to BRSKI%. But actual SSID for BRSKI for those 's is BRSKI%. No crypto, just connected to BRSKI Proxy. Cheers Toerless On Fri, Feb 16, 2018 at 11:43:04AM -0500, Michael Richardson wrote: > > Owen Friel (ofriel) wrote: > > [ofriel] I think a more comprehensive analysis of the various SSID > > discover options (DPP, hardcoded SSID, NAI Realm,..) and how each fits > > into the two post-SSID discovery options of (i) a new EAP-BRSKI > > vs. (ii) reuse of EAP-TLS (or some suitable EAP method, possibly with > > 2x 80.1x exchanges) is needed before any consensus on the contents of > > an ID is necessary. Unless you are suggesting than an initial ID merely > > outlines the multiple options but makes no final recommendation > > yet. Happy to get started on that... > > Yes... the point of the ID would be to layout the options.... > > The options-not-selected would go into an appendix of a final document to > explain paths not taken. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Feb 16 17:41:53 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CE41201FA for ; Fri, 16 Feb 2018 17:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 a_dn3HKTjrkc for ; Fri, 16 Feb 2018 17:41:49 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 6C5B31200C1 for ; Fri, 16 Feb 2018 17:41:49 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7C78B81E9DEFD for ; Sat, 17 Feb 2018 01:41:45 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 17 Feb 2018 01:41:40 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Sat, 17 Feb 2018 09:41:29 +0800 From: Sheng Jiang To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] request to consider adopting draft-richardson-anima-ace-constrained-voucher-03.txt Thread-Index: AQHTpqdQgyQNgqkM7kOc3at1NY/DeKOn0nRA Date: Sat, 17 Feb 2018 01:41:28 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9281829939@NKGEML515-MBX.china.huawei.com> References: <151870964368.7627.3386779535404044958.idtracker@ietfa.amsl.com> <2302.1518731545@obiwan.sandelman.ca> In-Reply-To: <2302.1518731545@obiwan.sandelman.ca> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.18.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] request to consider adopting draft-richardson-anima-ace-constrained-voucher-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Feb 2018 01:41:52 -0000 SGksIE1pY2hhZWwsDQoNClRoZSBBTklNQSBncm91cCBkb2VzIG5vdCBoYXZlIG11Y2ggYmFja2dy b3VuZCBvbiB0aGlzIHdvcmsuIFlvdSBzaG91bGQgZ2l2ZSBhbiBpbnRyb2R1Y3Rpb24gb24gdGhp cyBkcmFmdCBvbiBib3RoIGJhY2tncm91bmQgYW5kIHRlY2huaWNhbCBzb2x1dGlvbiwgYWxzbyB0 aGUgcmVsYXRpb25zaGlwIHdpdGggQU5JTUEsIGluIHRoZSBjb21pbmcgSUVURiAxMDEgbWVldGlu ZyBpbiBMb25kb24uIFdlIGNvdWxkIGxpa2UgdG8gYWxsb2NhdGUgYSB0aW1lIHNsb3QgZm9yIHlv dS4gU28gZmFyLCB3ZSBhcmUgb3BlbiwgYnV0IG5vdCBoYXZlIGVub3VnaCBrbm93bGVkZ2UgdG8g bWFrZSBhbnkgZGVjaXNpb24uDQoNClRoYW5rcyBhbmQgcmVnYXJkcywNCg0KU2hlbmcNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwgUmljaGFyZHNvbg0KU2VudDogRnJpZGF5 LCBGZWJydWFyeSAxNiwgMjAxOCA1OjUyIEFNDQpUbzogYW5pbWFAaWV0Zi5vcmcNClN1YmplY3Q6 IFtBbmltYV0gcmVxdWVzdCB0byBjb25zaWRlciBhZG9wdGluZyBkcmFmdC1yaWNoYXJkc29uLWFu aW1hLWFjZS1jb25zdHJhaW5lZC12b3VjaGVyLTAzLnR4dA0KDQoNClBldGVyLCBQYW5vcyBhbmQg SSBoYXZlIGJlZW4gd29ya2luZyBvbiB0aGlzIGRvY3VtZW50IGFsb25nIHdpdGggc29tZSBTSUQg aGVscCBmcm9tIE1pY2hlbCBWZWlsbGV0dC4gIFdlJ2QgbGlrZSB0aGUgQU5JTUEgV0cgdG8gY29u c2lkZXIgYWRvcHRpbmcgaXQuDQpUaGVyZSBhcmUgc29tZSBTSUQgaXNzdWVzIHRoYXQgd2UgaG9w ZSB0byB3b3JrIG91dCB3aXRoIHRoZSBoZWxwIG9mIHRoZSAieW90QGlldGYub3JnIiBsaXN0Li4u IHRoZXkgYXJlIG1pbm9yIHRlY2huaWNhbCBpc3N1ZXMgdGhhdCBkbyBub3QgY2hhbmdlIG11Y2gu DQoNCk9yaWdpbmFsbHkgdGhpcyB3b3JrIHdhcyBwYXJ0IG9mIGRyYWZ0LWlldGYtNnRpc2NoLXpl cm90b3VjaC1qb2luLCBhbmQgd2FzIGdvaW5nIHRvIGJlIGRvbmUgaW4gNnRpc2NoIGRpcmVjdGx5 IGFzIGl0IGhhZCBubyB1c2VycyBvdXRzaWRlIG9mIDZ0aXNjaC4NClRoYXQgaGFzLi4uIGNoYW5n ZWQgYmVjYXVzZSB0aGVyZSB3YXMgYSByZXF1ZXN0IHRvIHJldXNlIG1vcmUgdGhpbmdzLg0KUmV1 c2UgaXMgZ3JlYXQsIGJ1dCByZXF1aXJlcyBtb3JlIGNvb3JkaW5hdGlvbi4gPGluc2VydCBzYWQg c21pbGU+DQoNClBsZWFzZSBzZWUgdGhlIGRpYWdyYW0gYW5kIGV4cGxhbmF0aW9uLCB3aGljaCB3 YXMgaW4gbXkgZW5yb2xsbWVudC1yb2FkbWFwIGRyYWZ0LCBidXQgd2hpY2ggaXMgbm93IGF0Og0K ICAgICAgIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2ludC93aWtpL0Vucm9sbG1lbnRSb2Fk bWFwDQoNClRoaXMgZG9jdW1lbnQgcmVwcmVzZW50cyB0aGUgYm94IGVudGl0ZWQgImNvbnN0cmFp bmVkIHZvdWNoZXIgKENCT1IpICh4eHh4PykiDQpJdCBpcyB1c2VkIGJ5IHRoZSBwaW5rIGFuZCB5 ZWxsb3cgYm94ZXMuDQoNClRoaXMgZG9jdW1lbnQgImluaGVyaXRzIiAoc3ViY2xhc3NlcyBpZiB5 b3UgbGlrZSksIGJvdGggaWV0Zi1hbmltYS12b3VjaGVyIChkb2luZyBpdCBpbiBDQk9SLCBzaWdu ZWQgYnkgQ09TRSBvciBDTVMpLCBhbmQgYWxzbyBzdWJjbGFzc2VzIGlldGYtYW5pbWEtYm9vdHN0 cmFwcGluZy1rZXlpbmZyYSwgYXBwbHlpbmcgdGhlIHNhbWUgImRpZmYiIHRoYXQgQlJTS0kgbWFr ZXMgdG8gRVNULCBidXQgYXBwbHlpbmcgaXQgdG8gQUNFJ3MgRVNULUNPQVBTIHZlcnNpb24gb2Yg RVNULg0KSSd2ZSBpbGx1c3RyYXRlZCB0aGUgcmVsYXRpb25zaGlwIGluIHRoZSBzZWNvbmQgZGlh Z3JhbSBpbiB0aGUgd2lraSwgd2hpY2ggaXMgYWxzbyBhdDoNCiAgICBodHRwOi8vd3d3LnNhbmRl bG1hbi5jYS9TU1cvaWV0Zi9hbmltYS9kaWFncmFtcy9kb2N1bWVudC1yZWxhdGlvbnMuc3ZnDQoN ClRoZSBkb3R0ZWQvZmFkZWQgYmx1ZSByZXByZXNlbnRzIG15IHJlcXVlc3QgdG8gaGF2ZSBBTklN QSBhZG9wdCB0aGUgZG9jdW1lbnQuDQoNCg0KQ2hhaXJzOiBwbGVhc2UgbGV0IG1lIGtub3cgaWYg dGhpcyBpcyBzb21ldGhpbmcgd2UgY2FuIGRvIHNvb25lciAoYmVmb3JlIDEwMT8pLA0KICAgICAg ICBvciBpZiB5b3UgdGhpbmsgdGhhdCB3ZSBuZWVkIGFuIGluLXBlcnNvbiBkaXNjdXNzaW9uIGF0 IDEwMSwNCiAgICAgICAgb3IgaWYgeW91IHRoaW5rIHRoYXQgaXQncyBpbXBvc3NpYmxlLg0KICAg ICAgICBJdCdzIG5vdCBteSBnb2FsIHRvIGhhdmUgdGhlIFdHIGFkb3B0aW9uIGNhbGwgaW4gdGhp cyB0aHJlYWQhDQogICAgICAgIEJ1dCB0byBkZXRlcm1pbmUgd2hhdCBJIG5lZWQgdG8gZG8gdG8g Z2V0IHRvIHRoZSBxdWVzdGlvbiBiZWluZw0KICAgICAgICBhc2tlZC4gIFBlcmhhcHMgdGhlIFdH IHdpbGwgbm90IHdhbnQgdG8gYWRvcHQgaXQuDQoNCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IHdyb3RlOg0KICAgID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsDQogICAgPiBkcmFmdC1yaWNoYXJk c29uLWFuaW1hLWFjZS1jb25zdHJhaW5lZC12b3VjaGVyLTAzLnR4dCBoYXMgYmVlbg0KICAgID4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaWNoYWVsIFJpY2hhcmRzb24gYW5kIHBvc3RlZCB0 byB0aGUgSUVURg0KICAgID4gcmVwb3NpdG9yeS4NCg0KICAgID4gTmFtZTogZHJhZnQtcmljaGFy ZHNvbi1hbmltYS1hY2UtY29uc3RyYWluZWQtdm91Y2hlciBSZXZpc2lvbjogMDMNCiAgICA+IFRp dGxlOiBDb25zdHJhaW5lZCBWb3VjaGVyIFByb2ZpbGUgZm9yIEJvb3RzdHJhcHBpbmcgUHJvdG9j b2xzIERvY3VtZW50DQogICAgPiBkYXRlOiAyMDE4LTAyLTE0IEdyb3VwOiBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24gUGFnZXM6IDIwIFVSTDoNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1yaWNoYXJkc29uLWFuaW1hLWFjZS1jb25zdHJhaW5lZC12b3VjaGVy LTAzLnR4dA0KICAgID4gU3RhdHVzOg0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtcmljaGFyZHNvbi1hbmltYS1hY2UtY29uc3RyYWluZWQtdm91Y2hlci8NCiAg ICA+IEh0bWxpemVkOg0KICAgID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJp Y2hhcmRzb24tYW5pbWEtYWNlLWNvbnN0cmFpbmVkLXZvdWNoZXItMDMNCiAgICA+IEh0bWxpemVk Og0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1yaWNo YXJkc29uLWFuaW1hLWFjZS1jb25zdHJhaW5lZC12b3VjaGVyLTAzDQogICAgPiBEaWZmOg0KICAg ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXJpY2hhcmRzb24tYW5p bWEtYWNlLWNvbnN0cmFpbmVkLXZvdWNoZXItMDMNCg0KICAgID4gQWJzdHJhY3Q6IFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhIHN0cmF0ZWd5IHRvIHNlY3VyZWx5IGFzc2lnbiBhIHBsZWRnZQ0KICAg ID4gdG8gYW4gb3duZXIsIHVzaW5nIGFuIGFydGlmYWN0IHNpZ25lZCwgZGlyZWN0bHkgb3IgaW5k aXJlY3RseSwgYnkgdGhlDQogICAgPiBwbGVkZ2UncyBtYW51ZmFjdHVyZXIuICBUaGlzIGFydGlm YWN0IGlzIGtub3duIGFzIGEgInZvdWNoZXIiLg0KDQogICAgPiAgICBUaGlzIGRvY3VtZW50IGJ1 aWxkcyB1cG9uIHRoZSB3b3JrIGluIFtJLUQuaWV0Zi1hbmltYS12b3VjaGVyXSwNCiAgICA+IGVu Y29kaW5nIHRoZSByZXN1bHRpbmcgYXJ0aWZhY3QgaW4gQ0JPUi4gIFVzZSB3aXRoIHR3byBzaWdu YXR1cmUNCiAgICA+IHRlY2hub2xvZ2llcyBhcmUgZGVzY3JpYmVkLg0KDQogICAgPiAgICBBZGRp dGlvbmFsbHksIHRoaXMgZG9jdW1lbnQgZXhwbGFpbnMgaG93IGNvbnN0cmFpbmVkIHZvdWNoZXJz IG1heSBiZQ0KICAgID4gdHJhbnNwb3J0ZWQgaW4gdGhlIFtJLUQudmFuZGVyc3Rvay1hY2UtY29h cC1lc3RdIHByb3RvY29sLg0KDQoNCg0KDQogICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KICAgID4gc3VibWlzc2lv biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQog ICAgPiB0b29scy5pZXRmLm9yZy4NCg0KICAgID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoN Cg0KLS0NCk1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVs bWFuIFNvZnR3YXJlIFdvcmtzICAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQoNCg0KDQo= From nobody Sat Feb 17 07:34:59 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96010127337 for ; Sat, 17 Feb 2018 07:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3Bq3WgBkoOBC for ; Sat, 17 Feb 2018 07:34:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0AFE1241F5 for ; Sat, 17 Feb 2018 07:34:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C217320090; Sat, 17 Feb 2018 10:42:02 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4D9FA80AFF; Sat, 17 Feb 2018 10:34:54 -0500 (EST) From: Michael Richardson To: Sheng Jiang cc: "anima@ietf.org" In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9281829939@NKGEML515-MBX.china.huawei.com> References: <151870964368.7627.3386779535404044958.idtracker@ietfa.amsl.com> <2302.1518731545@obiwan.sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B9281829939@NKGEML515-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Sat, 17 Feb 2018 10:34:54 -0500 Message-ID: <29924.1518881694@obiwan.sandelman.ca> Archived-At: Subject: Re: [Anima] request to consider adopting draft-richardson-anima-ace-constrained-voucher-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Feb 2018 15:34:57 -0000 Sheng Jiang wrote: > The ANIMA group does not have much background on this work. You should > give an introduction on this draft on both background and technical > solution, also the relationship with ANIMA, in the coming IETF 101 > meeting in London. We could like to allocate a time slot for you. So > far, we are open, but not have enough knowledge to make any decision. Good, I need about 7-10 minutes, maybe less. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sat Feb 17 23:45:21 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A6A12426E for ; Sat, 17 Feb 2018 23:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 BrDwlSFbsNkF for ; Sat, 17 Feb 2018 23:45:18 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 26FE4120726 for ; Sat, 17 Feb 2018 23:45:18 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 446F5F59DBBE for ; Sun, 18 Feb 2018 07:45:14 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 18 Feb 2018 07:45:14 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Sun, 18 Feb 2018 15:45:09 +0800 From: Sheng Jiang To: Michael Richardson CC: "anima@ietf.org" Thread-Topic: Re: [Anima] request to consider adopting draft-richardson-anima-ace-constrained-voucher-03.txt Thread-Index: AQHTqIxlWbPu/Knm30Go/oRwAvLmXw== Date: Sun, 18 Feb 2018 07:45:09 +0000 Message-ID: 23D60B8B-654E-491C-8CE7-7F1A3C98B992 References: <151870964368.7627.3386779535404044958.idtracker@ietfa.amsl.com> <2302.1518731545@obiwan.sandelman.ca> <5D36713D8A4E7348A7E10DF7437A4B9281829939@NKGEML515-MBX.china.huawei.com>, <29924.1518881694@obiwan.sandelman.ca> In-Reply-To: <29924.1518881694@obiwan.sandelman.ca> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_23D60B8B654E491C8CE77F1A3C98B992_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] request to consider adopting draft-richardson-anima-ace-constrained-voucher-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 07:45:21 -0000 --_000_23D60B8B654E491C8CE77F1A3C98B992_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3aWxsIGFsbG9jYXRlIGEgMTUtbWludHVlIHRpbWUgc2xvdCBmb3IgeW91LCBpbmNsdWRpbmcg ZGlzY3Vzc2lvbi4gSSBleHBlY3Qgd2UgaGF2ZSBtdWNoIGxvb3NlIGFnZW5kYSB0aGlzIHRpbWUg d2hpbGUgNiBvdXQgb2YgOCBXRyBkcmFmdHMgaGF2ZSBiZWVuIHdpdGggSUVTRy4gTGV0IHVzIGtu b3cgaWYgeW91IG5lZWQgbW9yZSB0aW1lLg0KDQpSZWdhcmRzLA0KDQpTaGVuZw0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCuiSi+iDnCBTaGVuZyBK aWFuZw0KRTogamlhbmdzaGVuZ0BodWF3ZWkuY29tPG1haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5j b20+DQrljY7kuLotMjAxMjx0ZWw6MjAxMj7lrp7pqozlrqQtTkdJUOe9kee7nOWunumqjOWupA0K TkcgSVAgTmV0d29yayBMYWJvcmF0b3J5LCAyMDEyPHRlbDoyMDEyPkxhYnMsIEh1YXdlaQ0K5Y+R 5Lu25Lq677yaTWljaGFlbCBSaWNoYXJkc29uDQrmlLbku7bkurrvvJpTaGVuZyBKaWFuZywNCuaK hOKAg+mAge+8mmFuaW1hQGlldGYub3JnLA0K5pe26Ze077yaMjAxOC0wMi0xNyAyMzozNToxMA0K 5Li74oCD6aKY77yaUmU6IFtBbmltYV0gcmVxdWVzdCB0byBjb25zaWRlciBhZG9wdGluZyBkcmFm dC1yaWNoYXJkc29uLWFuaW1hLWFjZS1jb25zdHJhaW5lZC12b3VjaGVyLTAzLnR4dA0KDQpTaGVu ZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPiB3cm90ZToNCiAgICA+IFRoZSBBTklNQSBn cm91cCBkb2VzIG5vdCBoYXZlIG11Y2ggYmFja2dyb3VuZCBvbiB0aGlzIHdvcmsuIFlvdSBzaG91 bGQNCiAgICA+IGdpdmUgYW4gaW50cm9kdWN0aW9uIG9uIHRoaXMgZHJhZnQgb24gYm90aCBiYWNr Z3JvdW5kIGFuZCB0ZWNobmljYWwNCiAgICA+IHNvbHV0aW9uLCBhbHNvIHRoZSByZWxhdGlvbnNo aXAgd2l0aCBBTklNQSwgaW4gdGhlIGNvbWluZyBJRVRGIDEwMQ0KICAgID4gbWVldGluZyBpbiBM b25kb24uIFdlIGNvdWxkIGxpa2UgdG8gYWxsb2NhdGUgYSB0aW1lIHNsb3QgZm9yIHlvdS4gU28N CiAgICA+IGZhciwgd2UgYXJlIG9wZW4sIGJ1dCBub3QgaGF2ZSBlbm91Z2gga25vd2xlZGdlIHRv IG1ha2UgYW55IGRlY2lzaW9uLg0KDQpHb29kLCBJIG5lZWQgYWJvdXQgNy0xMCBtaW51dGVzLCBt YXliZSBsZXNzLg0KDQotLQ0KXSAgICAgICAgICAgICAgIE5ldmVyIHRlbGwgbWUgdGhlIG9kZHMh ICAgICAgICAgICAgICAgICB8IGlwdjYgbWVzaCBuZXR3b3JrcyBbDQpdICAgTWljaGFlbCBSaWNo YXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgICAgICAgIHwgbmV0d29yayBhcmNoaXRl Y3QgIFsNCl0gICAgIG1jckBzYW5kZWxtYW4uY2EgIGh0dHA6Ly93d3cuc2FuZGVsbWFuLmNhLyAg ICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMgICAgWw0KDQo= --_000_23D60B8B654E491C8CE77F1A3C98B992_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQo8IS0tDQotLT4NCjwvc3R5 bGU+DQo8ZGl2Pg0KPGRpdj5JIHdpbGwgYWxsb2NhdGUgYSAxNS1taW50dWUgdGltZSBzbG90IGZv ciB5b3UsIGluY2x1ZGluZyBkaXNjdXNzaW9uLiBJIGV4cGVjdCB3ZSBoYXZlIG11Y2ggbG9vc2Ug YWdlbmRhIHRoaXMgdGltZSB3aGlsZSA2IG91dCBvZiA4IFdHIGRyYWZ0cyBoYXZlIGJlZW4gd2l0 aCBJRVNHLiBMZXQgdXMga25vdyBpZiB5b3UgbmVlZCBtb3JlIHRpbWUuPGJyPg0KPGJyPg0KUmVn YXJkcyw8YnI+DQo8YnI+DQpTaGVuZzwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQrokovog5wgU2hl bmcgSmlhbmc8YnI+DQpFOiA8YSBocmVmPSJtYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tIj5q aWFuZ3NoZW5nQGh1YXdlaS5jb208L2E+PGJyPg0K5Y2O5Li6LTxhIGhyZWY9InRlbDoyMDEyIj4y MDEyPC9hPuWunumqjOWupC1OR0lQ572R57uc5a6e6aqM5a6kPGJyPg0KTkcgSVAgTmV0d29yayBM YWJvcmF0b3J5LCA8YSBocmVmPSJ0ZWw6MjAxMiI+MjAxMjwvYT5MYWJzLCBIdWF3ZWk8L2Rpdj4N CjxkaXYgbmFtZT0ieF9BbnlPZmZpY2UtQmFja2dyb3VuZC1JbWFnZSIgc3R5bGU9ImJvcmRlci10 b3A6MXB4IHNvbGlkICNCNUM0REY7IGZvbnQtc2l6ZToxNHB4OyBsaW5lLWhlaWdodDoyMHB4OyBw YWRkaW5nOjhweCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PGI+5Y+R5Lu2 5Lq677yaPC9iPk1pY2hhZWwgUmljaGFyZHNvbjwvZGl2Pg0KPGRpdiBzdHlsZT0id29yZC1icmVh azpicmVhay1hbGwiPjxiPuaUtuS7tuS6uu+8mjwvYj5TaGVuZyBKaWFuZyw8L2Rpdj4NCjxkaXYg c3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7mioTigIPpgIHvvJo8L2I+YW5pbWFAaWV0 Zi5vcmcsPC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PGI+5pe26Ze0 77yaPC9iPjIwMTgtMDItMTcgMjM6MzU6MTA8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6 YnJlYWstYWxsIj48Yj7kuLvigIPpopjvvJo8L2I+UmU6IFtBbmltYV0gcmVxdWVzdCB0byBjb25z aWRlciBhZG9wdGluZyBkcmFmdC1yaWNoYXJkc29uLWFuaW1hLWFjZS1jb25zdHJhaW5lZC12b3Vj aGVyLTAzLnR4dDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8Zm9u dCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4NCjxkaXYgY2xhc3M9IlBs YWluVGV4dCI+U2hlbmcgSmlhbmcgJmx0O2ppYW5nc2hlbmdAaHVhd2VpLmNvbSZndDsgd3JvdGU6 PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgVGhlIEFOSU1BIGdyb3VwIGRvZXMgbm90IGhh dmUgbXVjaCBiYWNrZ3JvdW5kIG9uIHRoaXMgd29yay4gWW91IHNob3VsZDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IGdpdmUgYW4gaW50cm9kdWN0aW9uIG9uIHRoaXMgZHJhZnQgb24gYm90 aCBiYWNrZ3JvdW5kIGFuZCB0ZWNobmljYWw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBz b2x1dGlvbiwgYWxzbyB0aGUgcmVsYXRpb25zaGlwIHdpdGggQU5JTUEsIGluIHRoZSBjb21pbmcg SUVURiAxMDE8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBtZWV0aW5nIGluIExvbmRvbi4g V2UgY291bGQgbGlrZSB0byBhbGxvY2F0ZSBhIHRpbWUgc2xvdCBmb3IgeW91LiBTbzxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGZhciwgd2UgYXJlIG9wZW4sIGJ1dCBub3QgaGF2ZSBlbm91 Z2gga25vd2xlZGdlIHRvIG1ha2UgYW55IGRlY2lzaW9uLjxicj4NCjxicj4NCkdvb2QsIEkgbmVl ZCBhYm91dCA3LTEwIG1pbnV0ZXMsIG1heWJlIGxlc3MuPGJyPg0KPGJyPg0KLS08YnI+DQpdJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5ldmVyIHRlbGwgbWUgdGhlIG9kZHMhJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgaXB2NiBtZXNoIG5ldHdvcmtzIFs8YnI+ DQpdJm5ic3A7Jm5ic3A7IE1pY2hhZWwgUmljaGFyZHNvbiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdv cmtzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgbmV0d29yayBh cmNoaXRlY3QmbmJzcDsgWzxicj4NCl0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWNyQHNhbmRl bG1hbi5jYSZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LnNhbmRlbG1hbi5jYS8iPmh0dHA6Ly93 d3cuc2FuZGVsbWFuLmNhLzwvYT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyBydWJ5IG9uIHJhaWxzJm5ic3A7Jm5ic3A7Jm5ic3A7IFs8YnI+ DQo8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_23D60B8B654E491C8CE77F1A3C98B992_-- From nobody Sun Feb 18 16:27:03 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93372126BF3 for ; Sun, 18 Feb 2018 16:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 yUKfncOJvpD1 for ; Sun, 18 Feb 2018 16:26:59 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D46312008A for ; Sun, 18 Feb 2018 16:26:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E4C5120091; Sun, 18 Feb 2018 19:34:10 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AE19080BCA; Sun, 18 Feb 2018 19:26:57 -0500 (EST) From: Michael Richardson To: anima@ietf.org cc: "Anoop Kumar Pandey" In-Reply-To: <003101d3a570$32e4c510$98ae4f30$@cdac.in> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 00:27:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {sorry if this is a duplicate, my draft folder says it did not go out} Anoop Kumar Pandey wrote directly to the draft authors list, and then gave me permission to share this on the list: Anoop> This is in context to the RFC detailing process of enrolling a p= ledge to a Anoop> domain. The major problem with the procedure is that the registr= ar doesn=E2=80=99t Anoop> verify the manufacturer. It simply verifies the voucher and enro= ls the Anoop> pledge. If pledge send a self-defined URL of manufacturer where = provision for Anoop> issuing fake vouchers is in place, then the registrar can be foo= led into Anoop> enrolment [assuming the registrar can=E2=80=99t know all the man= ufacturers Anoop> exhaustively] and later exploited from inside the domain. Additi= onally pledge Anoop> and a random manufacturer can also collaborate to do the same. You raise a number of issues. So let me name them so that we can discuss them easier, and make sure that I understand you correctly. Probably, we need to add some text to the Security Considerations, and I would welcome your help in crafting that text! Anoop> In the similar way a registrar may collaborate with the manufact= urer to lure Anoop> a device using fake voucher. Anoop> How can these problems be tackled? I agree that the Pledge may point at any Manufacturer (in the form of a MAS= A) that it wishes to. The following identities exist: 1) The Pledge's Identity (PI) in the form an IDevID certificate. (It signs the voucher request to the JRC, and the Client side of the TLS connection from Pledge to JRC) 2) The Manufacturer's Identity (MI) which signs the IDevID certificate. 3) The MASA Identity (MASA) which signs the voucher. 4) The Join Registrar (JRC) which signs the voucher request to the MASA. It also signs the Server side of the TLS connection from Pledge to JRC. 5) The Domain PKI Certificate Authority, which signs the LDevID. (The MI might be the same as the MASA, but in general the MASA may be outsourced. The Pledge SHOULD have a trusted anchor for both, but it can be designed where it has a manufacturer CA which signs both MASA and MI certificate) Each of these in essence represent a private key! I'd like start by ruling out of bounds for this discussion any scenario whe= re the attack requires that the private key be leaked, shared or used incorrectly. It's not that they can't happen, but rather that it is a problem of TPMs, etc. and not protocol design. The Pledge trusts network part works by: a) MASA signs VOUCHER. b) VOUCHER lists JRC in pinned-domain-cert. c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. d) JRC can also audit (verify signatures even) the voucher really comes from MASA, although unless there is a common CA, it may not be able to prove MASA and MI are same entity. The JRC trusts Pledge part works by: e) MI signs IDevID. f) Pledge uses IDevID to identify to JRC. g) JRC validates IDevID using MI certificate. Now, to translate what you said: problem 1. Anoop> The major problem with the procedure is that the registrar doesn= =E2=80=99t Anoop> verify the manufacturer. To translate, the JRC has no obvious way to verify that the "MI" key belongs to the manufacturer that they care about. You actually hit the major reason this is not a problem when you assume: > assuming the registrar can=E2=80=99t know all the manufacturers exhaus= tively We assume that in a managed network that the JRC *can* know all the legitimate manufacturers. The keys can come from sales channel integration (via digital "packing slips" perhaps), can be manually loaded by humans, be scanned from QR codes on the box, etc. We believe that this is out of scop= e. And if the JRC does see a MI that it does not know, then it can ask a human. That's one reason we made sure that failures to enroll do not cause the Pledge to never try again with that JRC. It needs to try again later, because maybe nobody has answered the "Yes/No" Dialog on the management station yet. And of course there is the WebPKI. We aren't saying that MI keys (or MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that they can't be. That's not a panacea... between ComodoGate type situations and certificates for "C1SC0" in a hard to distinguish font, many social engineering attacks could get that "Yes" button pressed. problem 2. Anoop> If pledge send a self-defined URL of manufacturer where provisio= n for Anoop> issuing fake vouchers is in place, then the registrar can be foo= led into Anoop> enrolment [assuming the registrar can=E2=80=99t know all the man= ufacturers Anoop> exhaustively] and later exploited from inside the domain. The URL of the manufacturer is embedded in the IDevID certificate (section 2.3 defines the extension). So the Pledge can't create this lie itself, it requires collaboration with the MI to create an IDevID. Such an MI can point to any MASA it wishes, so long as that device can issue vouchers that the Pledge can validate. What this means is that JRC always knows the MI that created the Pledge. If we can solve problem 1, then it's done. problem 3. Anoop> Additionally pledge Anoop> and a random manufacturer can also collaborate to do the same. I don't see how this is the case. The pledge can only collaborate with the manufacturer whose IDevID it has. problem 4. Anoop> In the similar way a registrar may collaborate with the manufact= urer to lure Anoop> a device using fake voucher. The Pledge will only trust a voucher signed by MASA. Any signature from a different entity will be rejected by the Pledge. So a fake voucher is not possible. Any voucher created by the real MASA is, by definition, not a fake voucher. Can you explain this scenario clearer? Or explain what text we need to change to clear up the mis-understanding? =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqKGdEACgkQgItw+93Q 3WWcrggAlqzuTe2W6yGZosqH0nqgXXC1lSFSJXD1l+PAiy3XI6ui+EL86JZz0X6X tGe/3VlgU33ustSPqpW/WH/8WTRSV82blPfrHTlK0BSO/kesMY0HRtl9VhlJBvhq SijyAXCJbFARV4E7Z823bwidMeeIorSKxaVoQrFmTxSlLlj8tBg2Qt1GEgX4EXYB vRD12iKjeGvFmUOKE2vAKUjI6agC4/1HjlINVTnQ5nrK8fGVD+/qk4WlxyL1H5jo TMdhBiJmUdrvkgK3zT5mLKDiUhohu6m3JCtOjnPN9U/Oy/yMOldATdrik4mjAHko hAVNrkrgUXZXDHE7bKYgv1/G//x/ZQ== =+7EE -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 18 19:11:57 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA511270A3 for ; Sun, 18 Feb 2018 19:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 z0CxL2sULXJP for ; Sun, 18 Feb 2018 19:11:53 -0800 (PST) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3175126CB6 for ; Sun, 18 Feb 2018 19:11:53 -0800 (PST) Received: by mail-pl0-x234.google.com with SMTP id f4so4941477plr.10 for ; Sun, 18 Feb 2018 19:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TS/TGKKNUeQPMSAlH2W+wn2W4Jn0RYcOqHrPgvpkinI=; b=MDw2OHgNgS4m4dnMfE/5OTXfuTlA5aVyUhdTrQbB006yh43yRvvkSEVJPdXDCqe8Ce uWERhgcFVy98IN4HwvQfv29bql3jundkQCMawobaBw2pNm+tYJg8WY5KflON46pMuwJx xepge3Ligr2IyhNyvDzBWx0crNz06GtUJ+jvxf4E8OjkE8JMs+9dxqU8XHlfnMJX5wb4 3heQKDXlLaja+30xeTnayUfmaCZ7rXUYy2yVWW5IHO5nKJzYvG6pESd7qzY6bglSguD9 qDcgKV48hq7MoKCiuDi/5UA1MmKIgeriORKaI8J2G5H2HSePvCwbeVHDF3EyxrZm3vbx FLgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TS/TGKKNUeQPMSAlH2W+wn2W4Jn0RYcOqHrPgvpkinI=; b=Tbk7ETRpbBIq3hA+ndOwk/+AO5GRZDxQQk/E6KurKTJ9QK0CmH3zm5ggoDG0A3wD6s bJJEPgKzU6MXa3TtwPgJQca89bB5BDkFFuQIKsTPlfemViZF7qIdHVX4du7Y5+TTpJeA OF0sCQNVF86VHzl1lBp5fBUgB+l6qAGFkHbDqhqYCnXggLTYTtvbRdAR0IUKAR6Lqm4f /HP3Fb//qfGsOlXmajmEUMFGs/IKcJH+r7u8P1ItbhpW2brZAjNgAEK6QJ9FhPPfiP4z Kxz+/AF6ZYUlXS/V1aYkOagn6outb4j1x7iD7fZ7uog1fLLJIgjGuX2u9EazypGC19Cg sQOg== X-Gm-Message-State: APf1xPAinBCHwa8T8slOQ1uLdfLxmat3xE/WOwSG/DUb2VD58if1pUy8 cfpKG7OyMsEljxlDO657RB38jWES X-Google-Smtp-Source: AH8x225ggh7OfWz+vpLjYptStIF0wK8RQg9s5TfKBkwgxjhQlUe1ARKmwRvHCxCHniiuNImJwnwnfA== X-Received: by 2002:a17:902:347:: with SMTP id 65-v6mr12843822pld.0.1519009913204; Sun, 18 Feb 2018 19:11:53 -0800 (PST) Received: from ?IPv6:2406:e007:7f8b:1:28cc:dc4c:9703:6781? ([2406:e007:7f8b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 64sm25076202pgj.39.2018.02.18.19.11.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 19:11:52 -0800 (PST) Sender: Brian Carpenter To: Michael Richardson , anima@ietf.org Cc: Anoop Kumar Pandey References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> From: Brian E Carpenter Message-ID: Date: Mon, 19 Feb 2018 16:11:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <22127.1519000017@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 03:11:56 -0000 On 19/02/2018 13:26, Michael Richardson wrote: >=20 > {sorry if this is a duplicate, my draft folder says it did not go out} >=20 > Anoop Kumar Pandey wrote directly to the draft authors = list, > and then gave me permission to share this on the list: > Anoop> This is in context to the RFC detailing process of enrolling= a pledge to a > Anoop> domain. The major problem with the procedure is that the reg= istrar doesn=E2=80=99t > Anoop> verify the manufacturer. It simply verifies the voucher and = enrols the > Anoop> pledge. If pledge send a self-defined URL of manufacturer wh= ere provision for > Anoop> issuing fake vouchers is in place, then the registrar can be= fooled into > Anoop> enrolment [assuming the registrar can=E2=80=99t know all the= manufacturers > Anoop> exhaustively] and later exploited from inside the domain. Ad= ditionally pledge > Anoop> and a random manufacturer can also collaborate to do the sam= e. >=20 > You raise a number of issues. >=20 > So let me name them so that we can discuss them easier, and make sure t= hat I > understand you correctly. > Probably, we need to add some text to the Security Considerations, and = I > would welcome your help in crafting that text! >=20 > Anoop> In the similar way a registrar may collaborate with the manu= facturer to lure > Anoop> a device using fake voucher. >=20 > Anoop> How can these problems be tackled? >=20 > I agree that the Pledge may point at any Manufacturer (in the form of a= MASA) > that it wishes to. The following identities exist: >=20 > 1) The Pledge's Identity (PI) in the form an IDevID certificate. > (It signs the voucher request to the JRC, and the Client side of the= TLS > connection from Pledge to JRC) > 2) The Manufacturer's Identity (MI) which signs the IDevID certificate.= > 3) The MASA Identity (MASA) which signs the voucher. > 4) The Join Registrar (JRC) which signs the voucher request to the MASA= =2E > It also signs the Server side of the TLS connection from Pledge to J= RC. > 5) The Domain PKI Certificate Authority, which signs the LDevID. >=20 > (The MI might be the same as the MASA, but in general the MASA > may be outsourced. The Pledge SHOULD have a trusted anchor for both, > but it can be designed where it has a manufacturer CA which signs both = MASA > and MI certificate) >=20 > Each of these in essence represent a private key! > I'd like start by ruling out of bounds for this discussion any scenario= where > the attack requires that the private key be leaked, shared or used > incorrectly. It's not that they can't happen, but rather that it is a > problem of TPMs, etc. and not protocol design. >=20 > The Pledge trusts network part works by: > a) MASA signs VOUCHER. > b) VOUCHER lists JRC in pinned-domain-cert. > c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. > d) JRC can also audit (verify signatures even) the voucher really comes= > from MASA, although unless there is a common CA, it may not be able = to > prove MASA and MI are same entity. >=20 > The JRC trusts Pledge part works by: > e) MI signs IDevID. > f) Pledge uses IDevID to identify to JRC. > g) JRC validates IDevID using MI certificate. >=20 > Now, to translate what you said: >=20 > problem 1. > Anoop> The major problem with the procedure is that the registrar d= oesn=E2=80=99t > Anoop> verify the manufacturer. >=20 > To translate, the JRC has no obvious way to verify that the "MI" key be= longs > to the manufacturer that they care about. >=20 > You actually hit the major reason this is not a problem when you assume= : > > assuming the registrar can=E2=80=99t know all the manufacturers ex= haustively >=20 > We assume that in a managed network that the JRC *can* know all the > legitimate manufacturers. The keys can come from sales channel integra= tion > (via digital "packing slips" perhaps), can be manually loaded by humans= , be > scanned from QR codes on the box, etc. We believe that this is out of = scope. Yes, but please ensure that the draft states this assumption and states that how it is achieved is out of scope. Also note the air-gap case described in section 6.3 bullet 3. That's list= ed as a security reduction, but if your threat model considers rogue MASAs to be a real risk, pre-loading vouchers and then totally disconnecting fr= om the Internet might even be considered a security improvement. Brian =20 > And if the JRC does see a MI that it does not know, then it can ask a h= uman. > That's one reason we made sure that failures to enroll do not cause the= > Pledge to never try again with that JRC. It needs to try again later, > because maybe nobody has answered the "Yes/No" Dialog on the management= > station yet. >=20 > And of course there is the WebPKI. We aren't saying that MI keys > (or MASA server TLS keys) MUST be in the WebPKI, but we aren't saying t= hat > they can't be. That's not a panacea... between ComodoGate type situati= ons > and certificates for "C1SC0" in a hard to distinguish font, many social= > engineering attacks could get that "Yes" button pressed. >=20 >=20 > problem 2. > Anoop> If pledge send a self-defined URL of manufacturer where prov= ision for > Anoop> issuing fake vouchers is in place, then the registrar can be= fooled into > Anoop> enrolment [assuming the registrar can=E2=80=99t know all the= manufacturers > Anoop> exhaustively] and later exploited from inside the domain. >=20 > The URL of the manufacturer is embedded in the IDevID certificate (sect= ion > 2.3 defines the extension). So the Pledge can't create this lie itself= , it > requires collaboration with the MI to create an IDevID. Such an MI can= > point to any MASA it wishes, so long as that device can issue vouchers = that > the Pledge can validate. >=20 > What this means is that JRC always knows the MI that created the Pledge= =2E > If we can solve problem 1, then it's done. >=20 > problem 3. > Anoop> Additionally pledge > Anoop> and a random manufacturer can also collaborate to do the sam= e. >=20 > I don't see how this is the case. The pledge can only collaborate with= > the manufacturer whose IDevID it has. >=20 > problem 4. > Anoop> In the similar way a registrar may collaborate with the manu= facturer to lure > Anoop> a device using fake voucher. >=20 > The Pledge will only trust a voucher signed by MASA. > Any signature from a different entity will be rejected by the Pledge. > So a fake voucher is not possible. > Any voucher created by the real MASA is, by definition, not a fake vouc= her. > Can you explain this scenario clearer? > Or explain what text we need to change to clear up the mis-understandin= g? >=20 > -- > ] Never tell me the odds! | ipv6 mesh net= works [ > ] Michael Richardson, Sandelman Software Works | network archi= tect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [ >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Feb 19 00:53:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E7127077 for ; Mon, 19 Feb 2018 00:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 iSymmegldMUB for ; Mon, 19 Feb 2018 00:53:44 -0800 (PST) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD40C12426E for ; Mon, 19 Feb 2018 00:53:42 -0800 (PST) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w1J8r4sk001351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Feb 2018 14:23:17 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w1J8qH2E004345; Mon, 19 Feb 2018 14:22:18 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w1J8qFRO032094; Mon, 19 Feb 2018 14:22:16 +0530 From: "Anoop Kumar Pandey" To: "'Michael Richardson'" , References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> In-Reply-To: <22127.1519000017@obiwan.sandelman.ca> Date: Mon, 19 Feb 2018 14:22:13 +0530 Message-ID: <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01D3A98D.0A75EDE0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE2I/joFI0/xQRcLlXQFy4X95wT3AJMjcXypNP1LbA= Content-Language: en-in X-CDAC-PUNE-MailScanner-ID: w1J8qH2E004345 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.198, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-2.539, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_20 -0.74, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w1J8r4sk001351 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 08:53:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005C_01D3A98D.0A75EDE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear Author, I am further expanding my query and raising concern over your re= sponse. The Problem Nos. are same as in the trailing reply.: =20 Problem 1:=20 Response: " We assume that in a managed network that the JRC *can* know all= the legitimate manufacturers." May be!! But practically may not be possible. Manufacturers keep adding and= also getting out of business. Tracking each MI is difficult. Response: " The keys can come from sales channel integration (via digital "= packing slips" perhaps), can be manually loaded by humans, be scanned from = QR codes on the box, etc. We believe that this is out of scope. And if the JRC does see a MI that it does not know, then it can ask a human= ." =20 If manual intervention is required, then it is no longer =E2=80=9CAutomated= BRSKI=E2=80=9D. Humans can anyway observer and add/install new device. =20 Problem 2:=20 Response: The URL of the manufacturer is embedded in the IDevID certificate= (section 2.3 defines the extension). So the Pledge can't create this lie = itself, it requires collaboration with the MI to create an IDevID. I had asked the same thing. If pledge collaborates with a rouge MI [given P= roblem 1 is not solved], the domain can easily be invaded. =20 Problem 3:=20 Response: The pledge can only collaborate with the manufacturer whose IDevI= D it has. Agreed. Then this problem reduces to Problem 2 where Pledge and MI can coll= aborate to fool JRC =20 Problem 4:=20 Response: The Pledge will only trust a voucher signed by MASA. Any signatur= e from a different entity will be rejected by the Pledge. So a fake voucher= is not possible. =20 I only raised concern that there is no way to detect if MASA and JRC have c= ollaborated to lure the pledge into a malicious domain unless the MASA cert= ificate and IDevID certificate have common Root Certifying authority. =20 Regards, Anoop =20 =20 -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 Sent: 19 February 2018 05:57 To: anima@ietf.org Cc: Anoop Kumar Pandey Subject: verification of manufacturer in BRSKI =20 =20 {sorry if this is a duplicate, my draft folder says it did not go out} =20 Anoop Kumar Pandey < anoop@cdac.in> wrote directly t= o the draft authors list, and then gave me permission to share this on the = list: Anoop> This is in context to the RFC detailing process of enrolling a p= ledge to a Anoop> domain. The major problem with the procedure is that the registr= ar doesn=E2=80=99t Anoop> verify the manufacturer. It simply verifies the voucher and enro= ls the Anoop> pledge. If pledge send a self-defined URL of manufacturer where = provision for Anoop> issuing fake vouchers is in place, then the registrar can be foo= led into Anoop> enrolment [assuming the registrar can=E2=80=99t know all the man= ufacturers Anoop> exhaustively] and later exploited from inside the domain. Additi= onally pledge Anoop> and a random manufacturer can also collaborate to do the same. =20 You raise a number of issues. =20 So let me name them so that we can discuss them easier, and make sure that = I understand you correctly. Probably, we need to add some text to the Security Considerations, and I wo= uld welcome your help in crafting that text! =20 Anoop> In the similar way a registrar may collaborate with the manufact= urer to lure Anoop> a device using fake voucher. =20 Anoop> How can these problems be tackled? =20 I agree that the Pledge may point at any Manufacturer (in the form of a MAS= A) that it wishes to. The following identities exist: =20 1) The Pledge's Identity (PI) in the form an IDevID certificate. (It signs the voucher request to the JRC, and the Client side of the TLS connection from Pledge to JRC) 2) The Manufacturer's Identity (MI) which signs the IDevID certificate. 3) The MASA Identity (MASA) which signs the voucher. 4) The Join Registrar (JRC) which signs the voucher request to the MASA. It also signs the Server side of the TLS connection from Pledge to JRC. 5) The Domain PKI Certificate Authority, which signs the LDevID. =20 (The MI might be the same as the MASA, but in general the MASA may be outso= urced. The Pledge SHOULD have a trusted anchor for both, but it can be des= igned where it has a manufacturer CA which signs both MASA and MI certifica= te) =20 Each of these in essence represent a private key! I'd like start by ruling out of bounds for this discussion any scenario whe= re the attack requires that the private key be leaked, shared or used incor= rectly. It's not that they can't happen, but rather that it is a problem o= f TPMs, etc. and not protocol design. =20 The Pledge trusts network part works by: a) MASA signs VOUCHER. b) VOUCHER lists JRC in pinned-domain-cert. c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. d) JRC can also audit (verify signatures even) the voucher really comes from MASA, although unless there is a common CA, it may not be able to prove MASA and MI are same entity. =20 The JRC trusts Pledge part works by: e) MI signs IDevID. f) Pledge uses IDevID to identify to JRC. g) JRC validates IDevID using MI certificate. =20 Now, to translate what you said: =20 problem 1. Anoop> The major problem with the procedure is that the registrar doesn= =E2=80=99t Anoop> verify the manufacturer. =20 To translate, the JRC has no obvious way to verify that the "MI" key belongs to the manufacturer that they care about. =20 You actually hit the major reason this is not a problem when you assume: > assuming the registrar can=E2=80=99t know all the manufacturers exhaus= tively =20 We assume that in a managed network that the JRC *can* know all the legitim= ate manufacturers. The keys can come from sales channel integration (via d= igital "packing slips" perhaps), can be manually loaded by humans, be scann= ed from QR codes on the box, etc. We believe that this is out of scope. =20 And if the JRC does see a MI that it does not know, then it can ask a human. That's one reason we made sure that failures to enroll do not cause the Ple= dge to never try again with that JRC. It needs to try again later, because= maybe nobody has answered the "Yes/No" Dialog on the management station ye= t. =20 And of course there is the WebPKI. We aren't saying that MI keys (or MASA = server TLS keys) MUST be in the WebPKI, but we aren't saying that they can'= t be. That's not a panacea... between ComodoGate type situations and certi= ficates for "C1SC0" in a hard to distinguish font, many social engineering = attacks could get that "Yes" button pressed. =20 =20 problem 2. Anoop> If pledge send a self-defined URL of manufacturer where provisio= n for Anoop> issuing fake vouchers is in place, then the registrar can be foo= led into Anoop> enrolment [assuming the registrar can=E2=80=99t know all the man= ufacturers Anoop> exhaustively] and later exploited from inside the domain. =20 The URL of the manufacturer is embedded in the IDevID certificate (section 2.3 defines the extension). So the Pledge can't create this lie itself, it= requires collaboration with the MI to create an IDevID. Such an MI can po= int to any MASA it wishes, so long as that device can issue vouchers that t= he Pledge can validate. =20 What this means is that JRC always knows the MI that created the Pledge. If we can solve problem 1, then it's done. =20 problem 3. Anoop> Additionally pledge Anoop> and a random manufacturer can also collaborate to do the same. =20 I don't see how this is the case. The pledge can only collaborate with the= manufacturer whose IDevID it has. =20 problem 4. Anoop> In the similar way a registrar may collaborate with the manufact= urer to lure Anoop> a device using fake voucher. =20 The Pledge will only trust a voucher signed by MASA. Any signature from a different entity will be rejected by the Pledge. So a fake voucher is not possible. Any voucher created by the real MASA is, by definition, not a fake voucher. Can you explain this scenario clearer? Or explain what text we need to change to clear up the mis-understanding? =20 -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ =20 =20 -- Michael Richardson < mcr+IETF@sandelman.ca>,= Sandelman Software Works -=3D IPv6 IoT consulting =3D- =20 =20 =20 ---------------------------------------------------------------------------= ---------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ---------------------------------------------------------------------------= ---------------------------------------------------- ------=_NextPart_000_005C_01D3A98D.0A75EDE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dear = Author,

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I am further expanding my query and raisi= ng concern over your response. The Problem Nos. are same as in the trailing= reply.:

 

Problem 1:
Response: " We assume that in a man= aged network that the JRC *can* know all the legitimate manufacturers."= ;

May be!! But practicall= y may not be possible. Manufacturers keep adding and also getting out of bu= siness. Tracking each MI is difficult.

Response: " The keys can come from sales channel integrat= ion (via digital "packing slips" perhaps), can be manually loaded= by humans, be scanned from QR codes on the box, etc.=C2=A0 We believe that= this is out of scope.

And if = the JRC does see a MI that it does not know, then it can ask a human."=

 

If manual intervention is required, then it is no longer =E2=80=9CAutomated BRSKI=E2=80=9D. Humans can anyway observer and = add/install new device.

 

Problem 2:

Response: The URL of the manufacturer is embedded in the IDevID c= ertificate (section 2.3 defines the extension).=C2=A0 So the Pledge can't c= reate this lie itself, it requires collaboration with the MI to create an I= DevID.

I had asked the sa= me thing. If pledge collaborates with a rouge MI [given Problem 1 is not so= lved], the domain can easily be invaded.

 

Problem 3:
Response= : The pledge can only collaborate with the manufacturer whose IDevID it has= .


Agreed. Then this pr= oblem reduces to Problem 2 where Pledge and MI can collaborate to fool JRC<= o:p>

 

Problem 4:

Response: The = Pledge will only trust a voucher signed by MASA. Any signature from a diffe= rent entity will be rejected by the Pledge. So a fake voucher is not possib= le.

 

<= p class=3DMsoPlainText>I only raised concern that there is no way to detect= if MASA and JRC have collaborated to lure the pledge into a malicious doma= in unless the MASA certificate and IDevID certificate have common Root Cert= ifying authority.

 

Regards,

An= oop

 

 

-----Original Message-----
From: M= ichael Richardson [mailto:mcr+ietf@sandelman.ca]
Sent: 19 February 2018= 05:57
To: anima@ietf.org
Cc: Anoop Kumar Pandey <anoop@cdac.in>= ;
Subject: verification of manufacturer in BRSKI

 

 

{sorry if this is a duplicate, my draft folder sa= ys it did not go out}

 

Anoop Kumar Pandey <anoop@cdac= .in> wrote directly to the draft authors list, and then gave = me permission to share this on the list:

=C2=A0=C2=A0=C2=A0 Anoop> This is in context to the RFC detailing pr= ocess of enrolling a pledge to a

=C2= =A0=C2=A0=C2=A0 Anoop> domain. The major problem with the procedure is t= hat the registrar doesn=E2=80=99t

=C2= =A0=C2=A0=C2=A0 Anoop> verify the manufacturer. It simply verifies the v= oucher and enrols the

=C2=A0=C2=A0=C2= =A0 Anoop> pledge. If pledge send a self-defined URL of manufacturer whe= re provision for

=C2=A0=C2=A0=C2=A0 A= noop> issuing fake vouchers is in place, then the registrar can be foole= d into

=C2=A0=C2=A0=C2=A0 Anoop> e= nrolment [assuming the registrar can=E2=80=99t know all the manufacturers

=C2=A0=C2=A0=C2=A0 Anoop> exhaustiv= ely] and later exploited from inside the domain. Additionally pledge

=C2=A0=C2=A0=C2=A0 Anoop> and a random m= anufacturer can also collaborate to do the same.

 

You raise a number= of issues.

 

So let me name them so that we can discuss them easier,= and make sure that I understand you correctly.

Probably, we need to add some text to the Security Consideration= s, and I would welcome your help in crafting that text!

 

=C2=A0=C2= =A0=C2=A0 Anoop> In the similar way a registrar may collaborate with the= manufacturer to lure

=C2=A0=C2=A0=C2= =A0 Anoop> a device using fake voucher.

 

=C2=A0=C2=A0=C2=A0 Anoop= > How can these problems be tackled?

 

I agree that the Pledge may= point at any Manufacturer (in the form of a MASA)

that it wishes to.=C2=A0=C2=A0 The following identities exi= st:

 

1) The Pledge's Identity (PI) in the form an IDevID certificate= .

=C2=A0=C2=A0 (It signs the voucher = request to the JRC, and the Client side of the TLS

=C2=A0=C2=A0 connection from Pledge to JRC)

<= p class=3DMsoPlainText>2) The Manufacturer's Identity (MI) which signs the = IDevID certificate.

3) The MASA Ident= ity (MASA) which signs the voucher.

4= ) The Join Registrar (JRC) which signs the voucher request to the MASA.

=C2=A0=C2=A0 It also signs the Server si= de of the TLS connection from Pledge to JRC.

5) The Domain PKI Certificate Authority, which signs the LDevID.

 

(The MI might be the same as the MASA, but in general the MASA may be= outsourced.=C2=A0 The Pledge SHOULD have a trusted anchor for both, but it= can be designed where it has a manufacturer CA which signs both MASA and M= I certificate)

 

<= p class=3DMsoPlainText>Each of these in essence represent a private key!

I'd like start by ruling out of bounds = for this discussion any scenario where the attack requires that the private= key be leaked, shared or used incorrectly.=C2=A0 It's not that they can't = happen, but rather that it is a problem of TPMs, etc. and not protocol desi= gn.

 

The Pledge trusts network part works by:

a) MASA signs VOUCHER.

b) VOUCHER lists JRC in pinned-domain-cert.

c) Pledge uses MASA to validate VOUCHER, and therefore validates J= RC.

d) JRC can also audit (verify sig= natures even) the voucher really comes

=C2=A0=C2=A0 from MASA, although unless there is a common CA, it may not = be able to

=C2=A0=C2=A0 prove MASA an= d MI are same entity.

 

The JRC trusts Pledge part works by:

e) MI signs IDevID.

f) Pledge uses IDevID to identify to JRC.

g) JRC validates IDevID using MI certificate.<= /p>

 

Now= , to translate what you said:

&n= bsp;

problem 1.

=C2=A0=C2=A0=C2=A0 Anoop> The major problem with the procedu= re is that the registrar doesn=E2=80=99t

=C2=A0=C2=A0=C2=A0 Anoop> verify the manufacturer.

 

To transl= ate, the JRC has no obvious way to verify that the "MI" key belon= gs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to the manufacturer that they= care about.

 

You actually hit the major reason this is not a proble= m when you assume:

=C2=A0=C2=A0 > = assuming the registrar can=E2=80=99t know all the manufacturers exhaustivel= y

 

We assume that in a managed network that the JRC *can* know all t= he legitimate manufacturers.=C2=A0 The keys can come from sales channel int= egration (via digital "packing slips" perhaps), can be manually l= oaded by humans, be scanned from QR codes on the box, etc.=C2=A0 We believe= that this is out of scope.

&nbs= p;

And if the JRC does see a MI that it do= es not know, then it can ask a human.

That's one reason we made sure that failures to enroll do not cause the Pl= edge to never try again with that JRC.=C2=A0 It needs to try again later, b= ecause maybe nobody has answered the "Yes/No" Dialog on the manag= ement station yet.

 <= /p>

And of course there is the WebPKI.=C2=A0 We aren= 't saying that MI keys (or MASA server TLS keys) MUST be in the WebPKI, but= we aren't saying that they can't be.=C2=A0 That's not a panacea... between= ComodoGate type situations and certificates for "C1SC0" in a har= d to distinguish font, many social engineering attacks could get that "= ;Yes" button pressed.

 = ;

 

problem 2.

=C2=A0=C2=A0=C2=A0 An= oop> If pledge send a self-defined URL of manufacturer where provision f= or

=C2=A0=C2=A0=C2=A0 Anoop> issui= ng fake vouchers is in place, then the registrar can be fooled into

=C2=A0=C2=A0=C2=A0 Anoop> enrolment [assu= ming the registrar can=E2=80=99t know all the manufacturers

<= p class=3DMsoPlainText>=C2=A0=C2=A0=C2=A0 Anoop> exhaustively] and later= exploited from inside the domain.

 

The URL of the manufacturer is e= mbedded in the IDevID certificate (section

2.3 defines the extension).=C2=A0 So the Pledge can't create this lie= itself, it requires collaboration with the MI to create an IDevID.=C2=A0 S= uch an MI can point to any MASA it wishes, so long as that device can issue= vouchers that the Pledge can validate.

 

What this means is that JRC= always knows the MI that created the Pledge.

If we can solve problem 1, then it's done.

 

problem 3.

=C2=A0=C2=A0=C2=A0 Anoop> Additionall= y pledge

=C2=A0=C2=A0=C2=A0 Anoop>= and a random manufacturer can also collaborate to do the same.<= /p>

 

I d= on't see how this is the case.=C2=A0 The pledge can only collaborate with t= he manufacturer whose IDevID it has.

=  

problem 4.

=C2=A0=C2=A0=C2=A0 Anoop> In the similar way a regist= rar may collaborate with the manufacturer to lure

=C2=A0=C2=A0 =C2=A0Anoop> a device using fake voucher.=

 

The Pledge will only trust a voucher signed by MASA.

Any signature from a different entity will be rejected = by the Pledge.

So a fake voucher is n= ot possible.

Any voucher created by t= he real MASA is, by definition, not a fake voucher.

Can you explain this scenario clearer?

Or explain what text we need to change to clear up the mi= s-understanding?

 

--

]=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Never tell me the odds!=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | ipv6 mesh networks [

]=C2=A0=C2=A0 Michael Richardson, Sandel= man Software Works=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | network arch= itect=C2=A0 [

]=C2=A0=C2=A0=C2=A0=C2= =A0 mcr@sandelman.ca=C2=A0 http:/= /www.sandelman.ca/=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0 ruby on rails=C2=A0=C2=A0=C2=A0 [

 

 

--

Michael R= ichardson <mcr+IETF@sandelman.ca>, San= delman Software Works=C2=A0 -=3D IPv6 IoT consulting =3D-

 

&nbs= p;

 


------= ---------------------------------------------------------------------------= ----------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= ---------------------------------------------------------- ------=_NextPart_000_005C_01D3A98D.0A75EDE0-- From nobody Mon Feb 19 11:16:05 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A23129C6E for ; Mon, 19 Feb 2018 11:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 iupFgmUefOAN for ; Mon, 19 Feb 2018 11:15:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBF8126C0F for ; Mon, 19 Feb 2018 11:15:51 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DEE5420091; Mon, 19 Feb 2018 14:23:05 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E901880C42; Mon, 19 Feb 2018 14:15:49 -0500 (EST) From: Michael Richardson To: anima@ietf.org CC: Anoop Kumar Pandey In-Reply-To: References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:15:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> problem 1. Anoop> The major problem with the procedure is that the registrar doesn= =E2=80=99t Anoop> verify the manufacturer. >>=20 >> To translate, the JRC has no obvious way to verify that the "MI" key= belongs >> to the manufacturer that they care about. >>=20 >> You actually hit the major reason this is not a problem when you ass= ume: >> > assuming the registrar can=E2=80=99t know all the manufacturers ex= haustively >>=20 >> We assume that in a managed network that the JRC *can* know all the >> legitimate manufacturers. The keys can come from sales channel inte= gration >> (via digital "packing slips" perhaps), can be manually loaded by hum= ans, be >> scanned from QR codes on the box, etc. We believe that this is out = of scope. > Yes, but please ensure that the draft states this assumption and stat= es > that how it is achieved is out of scope. > Also note the air-gap case described in section 6.3 bullet 3. That's = listed > as a security reduction, but if your threat model considers rogue MAS= As > to be a real risk, pre-loading vouchers and then totally disconnectin= g from > the Internet might even be considered a security improvement. I agree that there should be another Security Considerations section. Should we also say something in the Introduction? https://github.com/anima-wg/anima-bootstrap/issues/43 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqLImUACgkQgItw+93Q 3WVojwf/bsMI+Ltiz2uUOVNSNv6XxVGnN4OrplncZb9sL1iatH+OEIEHBgEeRhar i51/53+0VVdSxx0dnyFuLOO9qb1Wy4RUlOWHlXUY+XyXMNQUA0Mh9vD0XlbkNCws pzr6LHmtmZt6GqJ2aJRoP2ZEWlt06hF6fqE89LAUu6Y9GIyJcEmkmStXICPPzm9Q umtJWXmLUZW9fsILnpdtLcwRjkmFAg4U+AL4YflfCEUT7qU2UnVyUUI6wY2HMCNZ gxEMNr3hu19m9tb9gc7O4rTME6OXZfUxymxIVFdFhfxHo8EttunYM7/FKcufSI1k Zf1/DiJlc+jLf8UnqkRksZCWzzecmg== =ZnNw -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 19 11:31:01 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C76127137 for ; Mon, 19 Feb 2018 11:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7sei1_1Unu40 for ; Mon, 19 Feb 2018 11:30:32 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041FB1204DA for ; Mon, 19 Feb 2018 11:30:32 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id m1so2136599pgp.13 for ; Mon, 19 Feb 2018 11:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DIG74ohJxdMkECYHsEBLxQxeQEye2DIk3+5zdpMGBjw=; b=J0rfZ2+H1gBSE+nOqsuvf+sUQRdKnPgpOwnF/H4OI4IEh8WWezoVc4IbMZNTW52ag5 jDsUXqT89C+rwnAMPIxhx3ex2I5lt2hRmyyN0lpnwV7P8gSF9T8maTZ95rqTNEBzRg3n xRWkZaUDtzD2bIPMJ50uAxlKcSwagaawoxiWgh8vHpO89xGtJUflDxuRZqcU+sY1nhrj g/UKj2OhP5XD1QRj6srfH01gZ9l5o+6LCpH4MWFBbeFdDbvusmDS6AlRRXILsEHcoklW XRuZjRzRFT0rzpq0/m5oktm2o1T55raIzbB2WXmZ1whrhp76rv+/A+EXLNtWvv4czuE+ nUxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DIG74ohJxdMkECYHsEBLxQxeQEye2DIk3+5zdpMGBjw=; b=OqXsZi7LNLU++pibYAtQCbhvr/kK7kYNkTzlvGU4jL/A0XMXaS6atQGRdACeIIjJDY eNxvyCu1IKXEvJPfJ8dicglJGOl1a2MfI04YnGZqopeDy5ltGitDL32MsLHnvGKNV8Ow oGPASsxtDwpA0YiNpAchOgY6wpPp1b5qOC7/g6NmCPrJt5KDF6x/m6lk3IGv9qpfwbVR +OjTQ/IevzizV8xHJiQutsP9hXCqX7abrRMaG6dNY+I77Y5ZDJSN11b2vCxkHvaYkx46 sb+OVGK02IhZ4wZ0Hu0lgnlPqKbdyt9trc6a5n300MoEtLzk0ZrI1ALj6Khsc/npd7/K iNpA== X-Gm-Message-State: APf1xPD9yVzIy9L0XO3j3taETVhkPecRVTXxHG1jtMXalYbnta2yug98 qFO66BRGzMbyhOPCH75xEIwkayME X-Google-Smtp-Source: AH8x227aeEVnMBwk5iMj/GgcC57u3fzd58JckOjQ6dqVR5HBzXU/Xks+selSRuKxxg8/aibXOgOTbQ== X-Received: by 10.101.100.9 with SMTP id a9mr13055981pgv.102.1519068631298; Mon, 19 Feb 2018 11:30:31 -0800 (PST) Received: from ?IPv6:2406:e007:7f8b:1:28cc:dc4c:9703:6781? ([2406:e007:7f8b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e83sm9592198pfk.148.2018.02.19.11.30.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 11:30:30 -0800 (PST) Sender: Brian Carpenter To: Anoop Kumar Pandey , 'Michael Richardson' , anima@ietf.org References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> From: Brian E Carpenter Message-ID: <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> Date: Tue, 20 Feb 2018 08:30:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:30:45 -0000 On 19/02/2018 21:52, Anoop Kumar Pandey wrote: > Dear Author, >=20 > I am further expanding my query and raising concern over you= r response. The Problem Nos. are same as in the trailing reply.: >=20 > =20 >=20 > Problem 1:=20 > Response: " We assume that in a managed network that the JRC *can* know= all the legitimate manufacturers." >=20 >=20 >=20 > May be!! But practically may not be possible. Manufacturers keep adding= and also getting out of business. Tracking each MI is difficult. ANIMA is scoped to support professionally managed networks. So it seems r= easonable to assume that they have procurement procedures in place to buy from know= n sources and not to buy kit "off the back of a lorry" to use a British idi= om. In other words, tracking each manufacturer is *necessary* as it is in fac= t the origin of the trust for the BRSKI trust model. "Difficult" is not an excuse IMHO. >=20 > Response: " The keys can come from sales channel integration (via digit= al "packing slips" perhaps), can be manually loaded by humans, be scanned= from QR codes on the box, etc. We believe that this is out of scope. >=20 > And if the JRC does see a MI that it does not know, then it can ask a h= uman." >=20 > =20 >=20 > If manual intervention is required, then it is no longer =E2=80=9CAutom= ated BRSKI=E2=80=9D. Humans can anyway observer and add/install new devic= e. Again - a professionally managed network! Our goal in ANIMA is not to eli= minate human operators; it is to avoid them having to perform mindless configura= tion tasks or write obscure scripts. So requiring human action to resolve a se= curity alert is completely acceptable IMHO. In this case the device might have b= een installed by a service technician thousands of kilometres away from the N= OC, and if that technician did install a device from an unknown source, this is exactly a case where the NOC should be alerted. Brian > Problem 2:=20 >=20 > Response: The URL of the manufacturer is embedded in the IDevID certifi= cate (section 2.3 defines the extension). So the Pledge can't create thi= s lie itself, it requires collaboration with the MI to create an IDevID. >=20 >=20 >=20 > I had asked the same thing. If pledge collaborates with a rouge MI [giv= en Problem 1 is not solved], the domain can easily be invaded. >=20 > =20 >=20 > Problem 3:=20 > Response: The pledge can only collaborate with the manufacturer whose I= DevID it has. >=20 >=20 > Agreed. Then this problem reduces to Problem 2 where Pledge and MI can = collaborate to fool JRC >=20 > =20 >=20 > Problem 4:=20 >=20 > Response: The Pledge will only trust a voucher signed by MASA. Any sign= ature from a different entity will be rejected by the Pledge. So a fake v= oucher is not possible. >=20 > =20 >=20 > I only raised concern that there is no way to detect if MASA and JRC ha= ve collaborated to lure the pledge into a malicious domain unless the MAS= A certificate and IDevID certificate have common Root Certifying authorit= y. >=20 > =20 >=20 > Regards, >=20 > Anoop >=20 > =20 >=20 > =20 >=20 > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 > Sent: 19 February 2018 05:57 > To: anima@ietf.org > Cc: Anoop Kumar Pandey > Subject: verification of manufacturer in BRSKI >=20 > =20 >=20 > =20 >=20 > {sorry if this is a duplicate, my draft folder says it did not go out} >=20 > =20 >=20 > Anoop Kumar Pandey < anoop@cdac.in> wrote direct= ly to the draft authors list, and then gave me permission to share this o= n the list: >=20 > Anoop> This is in context to the RFC detailing process of enrolling= a pledge to a >=20 > Anoop> domain. The major problem with the procedure is that the reg= istrar doesn=E2=80=99t >=20 > Anoop> verify the manufacturer. It simply verifies the voucher and = enrols the >=20 > Anoop> pledge. If pledge send a self-defined URL of manufacturer wh= ere provision for >=20 > Anoop> issuing fake vouchers is in place, then the registrar can be= fooled into >=20 > Anoop> enrolment [assuming the registrar can=E2=80=99t know all the= manufacturers >=20 > Anoop> exhaustively] and later exploited from inside the domain. Ad= ditionally pledge >=20 > Anoop> and a random manufacturer can also collaborate to do the sam= e. >=20 > =20 >=20 > You raise a number of issues. >=20 > =20 >=20 > So let me name them so that we can discuss them easier, and make sure t= hat I understand you correctly. >=20 > Probably, we need to add some text to the Security Considerations, and = I would welcome your help in crafting that text! >=20 > =20 >=20 > Anoop> In the similar way a registrar may collaborate with the manu= facturer to lure >=20 > Anoop> a device using fake voucher. >=20 > =20 >=20 > Anoop> How can these problems be tackled? >=20 > =20 >=20 > I agree that the Pledge may point at any Manufacturer (in the form of a= MASA) >=20 > that it wishes to. The following identities exist: >=20 > =20 >=20 > 1) The Pledge's Identity (PI) in the form an IDevID certificate. >=20 > (It signs the voucher request to the JRC, and the Client side of the= TLS >=20 > connection from Pledge to JRC) >=20 > 2) The Manufacturer's Identity (MI) which signs the IDevID certificate.= >=20 > 3) The MASA Identity (MASA) which signs the voucher. >=20 > 4) The Join Registrar (JRC) which signs the voucher request to the MASA= =2E >=20 > It also signs the Server side of the TLS connection from Pledge to J= RC. >=20 > 5) The Domain PKI Certificate Authority, which signs the LDevID. >=20 > =20 >=20 > (The MI might be the same as the MASA, but in general the MASA may be o= utsourced. The Pledge SHOULD have a trusted anchor for both, but it can = be designed where it has a manufacturer CA which signs both MASA and MI c= ertificate) >=20 > =20 >=20 > Each of these in essence represent a private key! >=20 > I'd like start by ruling out of bounds for this discussion any scenario= where the attack requires that the private key be leaked, shared or used= incorrectly. It's not that they can't happen, but rather that it is a p= roblem of TPMs, etc. and not protocol design. >=20 > =20 >=20 > The Pledge trusts network part works by: >=20 > a) MASA signs VOUCHER. >=20 > b) VOUCHER lists JRC in pinned-domain-cert. >=20 > c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. >=20 > d) JRC can also audit (verify signatures even) the voucher really comes= >=20 > from MASA, although unless there is a common CA, it may not be able = to >=20 > prove MASA and MI are same entity. >=20 > =20 >=20 > The JRC trusts Pledge part works by: >=20 > e) MI signs IDevID. >=20 > f) Pledge uses IDevID to identify to JRC. >=20 > g) JRC validates IDevID using MI certificate. >=20 > =20 >=20 > Now, to translate what you said: >=20 > =20 >=20 > problem 1. >=20 > Anoop> The major problem with the procedure is that the registrar d= oesn=E2=80=99t >=20 > Anoop> verify the manufacturer. >=20 > =20 >=20 > To translate, the JRC has no obvious way to verify that the "MI" key be= longs >=20 > to the manufacturer that they care about. >=20 > =20 >=20 > You actually hit the major reason this is not a problem when you assume= : >=20 > > assuming the registrar can=E2=80=99t know all the manufacturers ex= haustively >=20 > =20 >=20 > We assume that in a managed network that the JRC *can* know all the leg= itimate manufacturers. The keys can come from sales channel integration = (via digital "packing slips" perhaps), can be manually loaded by humans, = be scanned from QR codes on the box, etc. We believe that this is out of= scope. >=20 > =20 >=20 > And if the JRC does see a MI that it does not know, then it can ask a h= uman. >=20 > That's one reason we made sure that failures to enroll do not cause the= Pledge to never try again with that JRC. It needs to try again later, b= ecause maybe nobody has answered the "Yes/No" Dialog on the management st= ation yet. >=20 > =20 >=20 > And of course there is the WebPKI. We aren't saying that MI keys (or M= ASA server TLS keys) MUST be in the WebPKI, but we aren't saying that the= y can't be. That's not a panacea... between ComodoGate type situations a= nd certificates for "C1SC0" in a hard to distinguish font, many social en= gineering attacks could get that "Yes" button pressed. >=20 > =20 >=20 > =20 >=20 > problem 2. >=20 > Anoop> If pledge send a self-defined URL of manufacturer where prov= ision for >=20 > Anoop> issuing fake vouchers is in place, then the registrar can be= fooled into >=20 > Anoop> enrolment [assuming the registrar can=E2=80=99t know all the= manufacturers >=20 > Anoop> exhaustively] and later exploited from inside the domain. >=20 > =20 >=20 > The URL of the manufacturer is embedded in the IDevID certificate (sect= ion >=20 > 2.3 defines the extension). So the Pledge can't create this lie itself= , it requires collaboration with the MI to create an IDevID. Such an MI = can point to any MASA it wishes, so long as that device can issue voucher= s that the Pledge can validate. >=20 > =20 >=20 > What this means is that JRC always knows the MI that created the Pledge= =2E >=20 > If we can solve problem 1, then it's done. >=20 > =20 >=20 > problem 3. >=20 > Anoop> Additionally pledge >=20 > Anoop> and a random manufacturer can also collaborate to do the sam= e. >=20 > =20 >=20 > I don't see how this is the case. The pledge can only collaborate with= the manufacturer whose IDevID it has. >=20 > =20 >=20 > problem 4. >=20 > Anoop> In the similar way a registrar may collaborate with the manu= facturer to lure >=20 > Anoop> a device using fake voucher. >=20 > =20 >=20 > The Pledge will only trust a voucher signed by MASA. >=20 > Any signature from a different entity will be rejected by the Pledge. >=20 > So a fake voucher is not possible. >=20 > Any voucher created by the real MASA is, by definition, not a fake vouc= her. >=20 > Can you explain this scenario clearer? >=20 > Or explain what text we need to change to clear up the mis-understandin= g? >=20 > =20 >=20 > -- >=20 > ] Never tell me the odds! | ipv6 mesh net= works [ >=20 > ] Michael Richardson, Sandelman Software Works | network archi= tect [ >=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >=20 > =20 >=20 > =20 >=20 > -- >=20 > Michael Richardson < mcr+IETF@sandelman.= ca>, Sandelman Software Works -=3D IPv6 IoT consulting =3D- >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= -------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] >=20 > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destr= oy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this emai= l > is strictly prohibited and appropriate legal action will be taken. > -----------------------------------------------------------------------= -------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Feb 19 11:46:25 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14B0126CD6 for ; Mon, 19 Feb 2018 11:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 gu679iBhLY8Q for ; Mon, 19 Feb 2018 11:46:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61141126C19 for ; Mon, 19 Feb 2018 11:46:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 26D0720091; Mon, 19 Feb 2018 14:53:37 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1633180766; Mon, 19 Feb 2018 14:46:21 -0500 (EST) From: Michael Richardson To: Anoop Kumar Pandey , anima@ietf.org In-Reply-To: <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:46:24 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> Problem 1:=20 >> Response: " We assume that in a managed network that the JRC *can* >> know all the legitimate manufacturers."=20 >> May be!! But practically may not be possible. Manufacturers keep >> adding and also getting out of business. Tracking each MI is difficu= lt.=20 Also, the MI may be tracked in the NOC: it doesn't have to happen in the field. Once a single MI is added, it is probably good. How can we improve the text to make this clearer? leaving this here: > alert is completely acceptable IMHO. In this case the device might ha= ve been > installed by a service technician thousands of kilometres away from t= he NOC, > and if that technician did install a device from an unknown source, t= his > is exactly a case where the NOC should be alerted. > Brian =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqLKYwACgkQgItw+93Q 3WUgxwf/c0dghTe/IPKctcTOWo+O2cSRiNjeKidlookI6daOF4urRX3p6Eq8l8sY ikOkXVAUdRrRMY1ol40Wrj4UXaxubqRs9PH4J72LjkX7ni1VoeRrU5smU3pUCPfB tpyFhXM4jIJyr6XHzDMGNkQXOS4+niy9dE5ZokBbTLZgVubj4yrnAU7ByVYdKPJI D/5MrNsuTBT2QIdIi0UJGjXpqWMtD7RImB1ThmYM9cHSq/7GNIwTESYgczLml4i4 QfMBfJfL+Z9MGkam6xdU1L1RDNyJ0Liz2FJQjmTvqFYYUc8UxltbocE+VfXiT0Ka d9+Jacq0sdHdmIIx80FgszazXKKfrw== =7xgM -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 19 14:05:10 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B96126DCA for ; Mon, 19 Feb 2018 14:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FO44id_1BLhB for ; Mon, 19 Feb 2018 14:04:58 -0800 (PST) Received: from mail-pl0-x244.google.com (mail-pl0-x244.google.com [IPv6:2607:f8b0:400e:c01::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B669E129BBF for ; Mon, 19 Feb 2018 14:04:49 -0800 (PST) Received: by mail-pl0-x244.google.com with SMTP id 31so6333383ple.9 for ; Mon, 19 Feb 2018 14:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pL1B0Z/JvAXZfplSEfSdxYVcw52c2gy/5tRQfISvIDg=; b=JEke4p7Kfolj2jZoaShBKSDQl6m1LZf+P3SVx7y4FszgY3LMuT3CpkO102gq36iGlR DtltvGjB3br6jvFFAcnnQvwc8dXXdAKTbyGpixjfeiFn3SJPdZRFf7RsIAaIuiSqCL2c LFZwmNsQ58BvyLlKOLX+SngvRZ/Rwuw8V/OCGL4rp8025F5smkkLRekFv6EpN/X17Rh1 c3qmNBAQ1udi14HtrxkHiBBi60qaY4H+oLo1soffFqaTZDKCmj+l+XLkHlC2d9rwklFL cLwk0haAlQYtPee6PtwzRz4N6TaOCCUJg16ZyXuG6nt9hZqHuyfCxON+LRmeB5z/6SML eVOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pL1B0Z/JvAXZfplSEfSdxYVcw52c2gy/5tRQfISvIDg=; b=OlOBfDaPjb/gqG8CH9zfenCnhraqompRbKv2jSov0WitlxoLNKkj69kTRrdkmR0RK9 QfngTm9oBBCMK05Sc0QQNyHrkJt9vrRiUZSvAGkcnOxBmRqrYII8iCz1jKuRUj13jd4x +/GoY3J5K5h6xvyz0GQk7ZljvP6P+7JwukDBLvF2r5zodhRGZPi0fFmQROq1nhdANM3T rY09/bsloQPA4coSI2TGOs9IiXFAEZR1/1B50K2PtH4/g3g922qXKiAnzHqh5CApeFIy EF0Xsncsb2piL5NchlWHWxPXIubEnpW4klJbEy9J04LQgWka8x0TakN9UcUsjZQWUi5B meDQ== X-Gm-Message-State: APf1xPAQ3K0qOIkzNTG+UIHaIuNN8PPh0mMfcVcdnLgEUC74EjngHZit 5Co3BJwxZ+wvt3ucj0Fo6r0EkUgh0MY= X-Google-Smtp-Source: AH8x224SUGHOTBhrcLzCC/2scay0L5A2SwA89lYwHJg3ymIcQvQUPkEgXevuv7tD1F0B2OijOxq+4A== X-Received: by 2002:a17:902:20e5:: with SMTP id v34-v6mr11024698plg.82.1519077889331; Mon, 19 Feb 2018 14:04:49 -0800 (PST) Received: from [130.216.38.100] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.100]) by smtp.gmail.com with ESMTPSA id 7sm21768937pfk.72.2018.02.19.14.04.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 14:04:48 -0800 (PST) Sender: Brian Carpenter To: Michael Richardson , anima@ietf.org Cc: Anoop Kumar Pandey References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <20799.1519067749@obiwan.sandelman.ca> From: Brian E Carpenter Message-ID: <141721e8-08be-0e54-9954-cffb59ff406e@gmail.com> Date: Tue, 20 Feb 2018 11:04:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20799.1519067749@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:05:00 -0000 On 20/02/2018 08:15, Michael Richardson wrote: >=20 > Brian E Carpenter wrote: > >> problem 1. > Anoop> The major problem with the procedure is that the registrar d= oesn=E2=80=99t > Anoop> verify the manufacturer. > >>=20 > >> To translate, the JRC has no obvious way to verify that the "MI"= key belongs > >> to the manufacturer that they care about. > >>=20 > >> You actually hit the major reason this is not a problem when you= assume: > >> > assuming the registrar can=E2=80=99t know all the manufacturer= s exhaustively > >>=20 > >> We assume that in a managed network that the JRC *can* know all = the > >> legitimate manufacturers. The keys can come from sales channel = integration > >> (via digital "packing slips" perhaps), can be manually loaded by= humans, be > >> scanned from QR codes on the box, etc. We believe that this is = out of scope. >=20 > > Yes, but please ensure that the draft states this assumption and = states > > that how it is achieved is out of scope. >=20 > > Also note the air-gap case described in section 6.3 bullet 3. Tha= t's listed > > as a security reduction, but if your threat model considers rogue= MASAs > > to be a real risk, pre-loading vouchers and then totally disconne= cting from > > the Internet might even be considered a security improvement. >=20 >=20 > I agree that there should be another Security Considerations section. > Should we also say something in the Introduction? I think Security Considerations is fine for this point. Brian >=20 > https://github.com/anima-wg/anima-bootstrap/issues/43 >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Feb 19 16:18:47 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D161241FC for ; Mon, 19 Feb 2018 16:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 AWkdhl0SXzOj for ; Mon, 19 Feb 2018 16:18:43 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48F9120227 for ; Mon, 19 Feb 2018 16:18:42 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2F27158C514; Tue, 20 Feb 2018 01:18:38 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0B384B0DAE7; Tue, 20 Feb 2018 01:18:37 +0100 (CET) Date: Tue, 20 Feb 2018 01:18:37 +0100 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org, Anoop Kumar Pandey Message-ID: <20180220001837.GA21510@faui40p.informatik.uni-erlangen.de> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22127.1519000017@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 00:18:45 -0000 Nonwithstanding the more detailled explanations you provided for Anoop, what i wuild think to be helpful to write into the security ection is like this: Domain trusting pledge/manufacturer: BRSKI does not fundamentally change this from RFC7030 EST assuming a pledge used its IDevID with RFC7030 EST. In both cases, domain (registrar) needs to trust the manufacturer and potentially some more detailled set of devices if manufacturer provides such informatio (e.g.: do not trust the following serial numbers, they where stolen from manufacturer warehouse). The domain (registrar) can authenticate and authorize the IDevID of the pledge. Establishing this trust between domain and manufacturer is outside the scope of BRSKI. Worst case, a domain needs to manually provision the trust anchor for every manufacturer. Better yet, third parties may provide signing services for manufacturer trust anchors similar to WebPKI. BRSKI does refine EST in this respect only in demandin that pledges must not excludeproxies/registrars after having been rejected first because the domain may take time / manual action Btw, and i think this may go further than what might fit into BRSKI, especially given how as noted above, this is not specific to BRSKI (but would equally work for just EST): If we could educate the industry more on the use of IDevIDs, then we could end up wih something a lot more useful than WebPKI. There are a lot of organizations that provide all type of certifications and qualifications for devices, ranging from jokes like "CE" over to faily useful securiy behavior certifications such as "FIPS-140". If manufacturers would start to assign for every device-type they produce another sub-trust-anchor with which they sign the IDevIDs of that device-type, then the certification organizations could sign those sub-trust-anchors after the device type passed the certification. That would be a cryptographic equivalent of putting certification stickers onto products. Of course, this would only provide more security to the domains if the label implied comes with a certification agency thats worth anything. CE for example is self-certification by the industry, so completely useless. Cheers toerless On Sun, Feb 18, 2018 at 07:26:57PM -0500, Michael Richardson wrote: > > {sorry if this is a duplicate, my draft folder says it did not go out} > > Anoop Kumar Pandey wrote directly to the draft authors list, > and then gave me permission to share this on the list: > Anoop> This is in context to the RFC detailing process of enrolling a pledge to a > Anoop> domain. The major problem with the procedure is that the registrar doesn???t > Anoop> verify the manufacturer. It simply verifies the voucher and enrols the > Anoop> pledge. If pledge send a self-defined URL of manufacturer where provision for > Anoop> issuing fake vouchers is in place, then the registrar can be fooled into > Anoop> enrolment [assuming the registrar can???t know all the manufacturers > Anoop> exhaustively] and later exploited from inside the domain. Additionally pledge > Anoop> and a random manufacturer can also collaborate to do the same. > > You raise a number of issues. > > So let me name them so that we can discuss them easier, and make sure that I > understand you correctly. > Probably, we need to add some text to the Security Considerations, and I > would welcome your help in crafting that text! > > Anoop> In the similar way a registrar may collaborate with the manufacturer to lure > Anoop> a device using fake voucher. > > Anoop> How can these problems be tackled? > > I agree that the Pledge may point at any Manufacturer (in the form of a MASA) > that it wishes to. The following identities exist: > > 1) The Pledge's Identity (PI) in the form an IDevID certificate. > (It signs the voucher request to the JRC, and the Client side of the TLS > connection from Pledge to JRC) > 2) The Manufacturer's Identity (MI) which signs the IDevID certificate. > 3) The MASA Identity (MASA) which signs the voucher. > 4) The Join Registrar (JRC) which signs the voucher request to the MASA. > It also signs the Server side of the TLS connection from Pledge to JRC. > 5) The Domain PKI Certificate Authority, which signs the LDevID. > > (The MI might be the same as the MASA, but in general the MASA > may be outsourced. The Pledge SHOULD have a trusted anchor for both, > but it can be designed where it has a manufacturer CA which signs both MASA > and MI certificate) > > Each of these in essence represent a private key! > I'd like start by ruling out of bounds for this discussion any scenario where > the attack requires that the private key be leaked, shared or used > incorrectly. It's not that they can't happen, but rather that it is a > problem of TPMs, etc. and not protocol design. > > The Pledge trusts network part works by: > a) MASA signs VOUCHER. > b) VOUCHER lists JRC in pinned-domain-cert. > c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. > d) JRC can also audit (verify signatures even) the voucher really comes > from MASA, although unless there is a common CA, it may not be able to > prove MASA and MI are same entity. > > The JRC trusts Pledge part works by: > e) MI signs IDevID. > f) Pledge uses IDevID to identify to JRC. > g) JRC validates IDevID using MI certificate. > > Now, to translate what you said: > > problem 1. > Anoop> The major problem with the procedure is that the registrar doesn???t > Anoop> verify the manufacturer. > > To translate, the JRC has no obvious way to verify that the "MI" key belongs > to the manufacturer that they care about. > > You actually hit the major reason this is not a problem when you assume: > > assuming the registrar can???t know all the manufacturers exhaustively > > We assume that in a managed network that the JRC *can* know all the > legitimate manufacturers. The keys can come from sales channel integration > (via digital "packing slips" perhaps), can be manually loaded by humans, be > scanned from QR codes on the box, etc. We believe that this is out of scope. > > And if the JRC does see a MI that it does not know, then it can ask a human. > That's one reason we made sure that failures to enroll do not cause the > Pledge to never try again with that JRC. It needs to try again later, > because maybe nobody has answered the "Yes/No" Dialog on the management > station yet. > > And of course there is the WebPKI. We aren't saying that MI keys > (or MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that > they can't be. That's not a panacea... between ComodoGate type situations > and certificates for "C1SC0" in a hard to distinguish font, many social > engineering attacks could get that "Yes" button pressed. > > > problem 2. > Anoop> If pledge send a self-defined URL of manufacturer where provision for > Anoop> issuing fake vouchers is in place, then the registrar can be fooled into > Anoop> enrolment [assuming the registrar can???t know all the manufacturers > Anoop> exhaustively] and later exploited from inside the domain. > > The URL of the manufacturer is embedded in the IDevID certificate (section > 2.3 defines the extension). So the Pledge can't create this lie itself, it > requires collaboration with the MI to create an IDevID. Such an MI can > point to any MASA it wishes, so long as that device can issue vouchers that > the Pledge can validate. > > What this means is that JRC always knows the MI that created the Pledge. > If we can solve problem 1, then it's done. > > problem 3. > Anoop> Additionally pledge > Anoop> and a random manufacturer can also collaborate to do the same. > > I don't see how this is the case. The pledge can only collaborate with > the manufacturer whose IDevID it has. > > problem 4. > Anoop> In the similar way a registrar may collaborate with the manufacturer to lure > Anoop> a device using fake voucher. > > The Pledge will only trust a voucher signed by MASA. > Any signature from a different entity will be rejected by the Pledge. > So a fake voucher is not possible. > Any voucher created by the real MASA is, by definition, not a fake voucher. > Can you explain this scenario clearer? > Or explain what text we need to change to clear up the mis-understanding? > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Feb 19 21:01:16 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3A124235 for ; Mon, 19 Feb 2018 21:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aO4SXnQevwNj for ; Mon, 19 Feb 2018 21:01:12 -0800 (PST) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC5B1200C1 for ; Mon, 19 Feb 2018 21:01:09 -0800 (PST) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w1K50jgq010763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Feb 2018 10:30:50 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w1K4xwGF003125; Tue, 20 Feb 2018 10:29:59 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w1K4xmhj016723; Tue, 20 Feb 2018 10:29:50 +0530 From: "Anoop Kumar Pandey" To: "'Brian E Carpenter'" , "'Michael Richardson'" , References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> In-Reply-To: <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> Date: Tue, 20 Feb 2018 10:29:47 +0530 Message-ID: <003501d3aa07$a37f0560$ea7d1020$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01D3AA35.BD3D82F0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-in Thread-Index: AQE2I/joFI0/xQRcLlXQFy4X95wT3AJMjcXyAfHjFIQBMe5HL6S8P+Xw X-CDAC-PUNE-MailScanner-ID: w1K4xwGF003125 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.198, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.798, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w1K50jgq010763 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 05:01:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0036_01D3AA35.BD3D82F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =E2=80=9CANIMA is scoped to support professionally managed networks. So it = seems reasonable to assume that they have procurement procedures in place t= o buy from known sources and not to buy kit "off the back of a lorry" to us= e a British idiom.=E2=80=9D =20 "Again - a professionally managed network! Our goal in ANIMA is not to elim= inate human operators; it is to avoid them having to perform mindless confi= guration tasks or write obscure scripts. So requiring human action to resol= ve a security alert is completely acceptable IMHO. In this case the device = might have been installed by a service technician thousands of kilometres a= way from the NOC, and if that technician did install a device from an unkno= wn source, this is exactly a case where the NOC should be alerted." =20 So, basically you reduced your scope to a professionally managed network. J= ust for the sake of clarity, if it is just like a trusted world of professi= onally managed network where pledges being added are from trusted manufactu= rers, probably we don=E2=80=99t require this cryptographically maintained l= ong procedure of bootstrapping, since trust is derived from the manufacture= r. A trusted manufacturer gives a trusted device, that=E2=80=99s all. Suppo= se we still want to go with this procedure and having our trust in certific= ates and keys, we don=E2=80=99t require MASA and vouchers. By simply verify= ing if the IDevID certificate has been signed by a trusted MI or a trusted = CA or root-RA should be sufficient for verifying the pledge. Pledge verifyi= ng the domain is anyway overrated. Besides, it can also be done by verifyin= g the certificate of JRC during enrolment. =20 But it is very limited scope. I would work on expanding the scope to any ne= twork, any manufacturer-device pair.=20 =20 I would also like to quote/remind following lines from Section 1.3 [Scope o= f Solution] of the RFC:=20 =20 =E2=80=9CBut this solution is not exclusive to the large, it is intended to= scale to thousands of devices located in hostile environments, such as ISP= provided CPE devices which are drop-shipped to the end user. The situatio= n where an order is fulfilled from distributed warehouse from a common stoc= k and shipped directly to the target location at the request of the domain = owner is explicitly supported. That stock ("SKU") could be provided to a n= umber of potential domain owners, and the eventual domain owner will not kn= ow a-priori which device will go to which location.=E2=80=9D =20 Regards, Anoop =20 =20 =20 =20 -----Original Message----- From: Brian Carpenter [mailto:becarpenter46@gmail.com] On Behalf Of Brian E= Carpenter Sent: 20 February 2018 01:00 To: Anoop Kumar Pandey ; 'Michael Richardson' ; anima@ietf.org Subject: Re: [Anima] verification of manufacturer in BRSKI =20 On 19/02/2018 21:52, Anoop Kumar Pandey wrote: > Dear Author, >=20 > I am further expanding my query and raising concern over your = response. The Problem Nos. are same as in the trailing reply.: >=20 >=20=20 >=20 > Problem 1:=20 > Response: " We assume that in a managed network that the JRC *can* know a= ll the legitimate manufacturers." >=20 >=20 >=20 > May be!! But practically may not be possible. Manufacturers keep adding a= nd also getting out of business. Tracking each MI is difficult. =20 ANIMA is scoped to support professionally managed networks. So it seems rea= sonable to assume that they have procurement procedures in place to buy fro= m known sources and not to buy kit "off the back of a lorry" to use a Briti= sh idiom. =20 In other words, tracking each manufacturer is *necessary* as it is in fact = the origin of the trust for the BRSKI trust model. "Difficult" is not an ex= cuse IMHO. =20 >=20 > Response: " The keys can come from sales channel integration (via digital= "packing slips" perhaps), can be manually loaded by humans, be scanned fro= m QR codes on the box, etc. We believe that this is out of scope. >=20 > And if the JRC does see a MI that it does not know, then it can ask a hum= an." >=20 >=20=20 >=20 > If manual intervention is required, then it is no longer =E2=80=9CAutomat= ed BRSKI=E2=80=9D. Humans can anyway observer and add/install new device. =20 Again - a professionally managed network! Our goal in ANIMA is not to elimi= nate human operators; it is to avoid them having to perform mindless config= uration tasks or write obscure scripts. So requiring human action to resolv= e a security alert is completely acceptable IMHO. In this case the device m= ight have been installed by a service technician thousands of kilometres aw= ay from the NOC, and if that technician did install a device from an unknow= n source, this is exactly a case where the NOC should be alerted. =20 Brian =20 > Problem 2:=20 >=20 > Response: The URL of the manufacturer is embedded in the IDevID certifica= te (section 2.3 defines the extension). So the Pledge can't create this li= e itself, it requires collaboration with the MI to create an IDevID. >=20 >=20 >=20 > I had asked the same thing. If pledge collaborates with a rouge MI [given= Problem 1 is not solved], the domain can easily be invaded. >=20 >=20=20 >=20 > Problem 3:=20 > Response: The pledge can only collaborate with the manufacturer whose IDe= vID it has. >=20 >=20 > Agreed. Then this problem reduces to Problem 2 where Pledge and MI can=20 > collaborate to fool JRC >=20 >=20=20 >=20 > Problem 4:=20 >=20 > Response: The Pledge will only trust a voucher signed by MASA. Any signat= ure from a different entity will be rejected by the Pledge. So a fake vouch= er is not possible. >=20 >=20=20 >=20 > I only raised concern that there is no way to detect if MASA and JRC have= collaborated to lure the pledge into a malicious domain unless the MASA ce= rtificate and IDevID certificate have common Root Certifying authority. >=20 >=20=20 >=20 > Regards, >=20 > Anoop >=20 >=20=20 >=20 >=20=20 >=20 > -----Original Message----- > From: Michael Richardson [ mailto:mcr+ietf= @sandelman.ca] > Sent: 19 February 2018 05:57 > To: anima@ietf.org > Cc: Anoop Kumar Pandey < anoop@cdac.in> > Subject: verification of manufacturer in BRSKI >=20 >=20=20 >=20 >=20=20 >=20 > {sorry if this is a duplicate, my draft folder says it did not go out} >=20 >=20=20 >=20 > Anoop Kumar Pandey < < mailto:anoop@cdac.in> anoop@cdac.in> wrote directly to the draft authors list,= and then gave me permission to share this on the list: >=20 > Anoop> This is in context to the RFC detailing process of=20 > enrolling a pledge to a >=20 > Anoop> domain. The major problem with the procedure is that the=20 > registrar doesn=E2=80=99t >=20 > Anoop> verify the manufacturer. It simply verifies the voucher and=20 > enrols the >=20 > Anoop> pledge. If pledge send a self-defined URL of manufacturer=20 > where provision for >=20 > Anoop> issuing fake vouchers is in place, then the registrar can=20 > be fooled into >=20 > Anoop> enrolment [assuming the registrar can=E2=80=99t know all the= =20 > manufacturers >=20 > Anoop> exhaustively] and later exploited from inside the domain.=20 > Additionally pledge >=20 > Anoop> and a random manufacturer can also collaborate to do the same. >=20 >=20=20 >=20 > You raise a number of issues. >=20 >=20=20 >=20 > So let me name them so that we can discuss them easier, and make sure tha= t I understand you correctly. >=20 > Probably, we need to add some text to the Security Considerations, and I = would welcome your help in crafting that text! >=20 >=20=20 >=20 > Anoop> In the similar way a registrar may collaborate with the=20 > manufacturer to lure >=20 > Anoop> a device using fake voucher. >=20 >=20=20 >=20 > Anoop> How can these problems be tackled? >=20 >=20=20 >=20 > I agree that the Pledge may point at any Manufacturer (in the form of=20 > a MASA) >=20 > that it wishes to. The following identities exist: >=20 >=20=20 >=20 > 1) The Pledge's Identity (PI) in the form an IDevID certificate. >=20 > (It signs the voucher request to the JRC, and the Client side of=20 > the TLS >=20 > connection from Pledge to JRC) >=20 > 2) The Manufacturer's Identity (MI) which signs the IDevID certificate. >=20 > 3) The MASA Identity (MASA) which signs the voucher. >=20 > 4) The Join Registrar (JRC) which signs the voucher request to the MASA. >=20 > It also signs the Server side of the TLS connection from Pledge to JRC. >=20 > 5) The Domain PKI Certificate Authority, which signs the LDevID. >=20 >=20=20 >=20 > (The MI might be the same as the MASA, but in general the MASA may be=20 > outsourced. The Pledge SHOULD have a trusted anchor for both, but it=20 > can be designed where it has a manufacturer CA which signs both MASA=20 > and MI certificate) >=20 >=20=20 >=20 > Each of these in essence represent a private key! >=20 > I'd like start by ruling out of bounds for this discussion any scenario w= here the attack requires that the private key be leaked, shared or used inc= orrectly. It's not that they can't happen, but rather that it is a problem= of TPMs, etc. and not protocol design. >=20 >=20=20 >=20 > The Pledge trusts network part works by: >=20 > a) MASA signs VOUCHER. >=20 > b) VOUCHER lists JRC in pinned-domain-cert. >=20 > c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. >=20 > d) JRC can also audit (verify signatures even) the voucher really=20 > comes >=20 > from MASA, although unless there is a common CA, it may not be able=20 > to >=20 > prove MASA and MI are same entity. >=20 >=20=20 >=20 > The JRC trusts Pledge part works by: >=20 > e) MI signs IDevID. >=20 > f) Pledge uses IDevID to identify to JRC. >=20 > g) JRC validates IDevID using MI certificate. >=20 >=20=20 >=20 > Now, to translate what you said: >=20 >=20=20 >=20 > problem 1. >=20 > Anoop> The major problem with the procedure is that the registrar=20 > doesn=E2=80=99t >=20 > Anoop> verify the manufacturer. >=20 >=20=20 >=20 > To translate, the JRC has no obvious way to verify that the "MI" key=20 > belongs >=20 > to the manufacturer that they care about. >=20 >=20=20 >=20 > You actually hit the major reason this is not a problem when you assume: >=20 > > assuming the registrar can=E2=80=99t know all the manufacturers=20 > exhaustively >=20 >=20=20 >=20 > We assume that in a managed network that the JRC *can* know all the legit= imate manufacturers. The keys can come from sales channel integration (via= digital "packing slips" perhaps), can be manually loaded by humans, be sca= nned from QR codes on the box, etc. We believe that this is out of scope. >=20 >=20=20 >=20 > And if the JRC does see a MI that it does not know, then it can ask a hum= an. >=20 > That's one reason we made sure that failures to enroll do not cause the P= ledge to never try again with that JRC. It needs to try again later, becau= se maybe nobody has answered the "Yes/No" Dialog on the management station = yet. >=20 >=20=20 >=20 > And of course there is the WebPKI. We aren't saying that MI keys (or MAS= A server TLS keys) MUST be in the WebPKI, but we aren't saying that they ca= n't be. That's not a panacea... between ComodoGate type situations and cer= tificates for "C1SC0" in a hard to distinguish font, many social engineerin= g attacks could get that "Yes" button pressed. >=20 >=20=20 >=20 >=20=20 >=20 > problem 2. >=20 > Anoop> If pledge send a self-defined URL of manufacturer where=20 > provision for >=20 > Anoop> issuing fake vouchers is in place, then the registrar can=20 > be fooled into >=20 > Anoop> enrolment [assuming the registrar can=E2=80=99t know all the= =20 > manufacturers >=20 > Anoop> exhaustively] and later exploited from inside the domain. >=20 >=20=20 >=20 > The URL of the manufacturer is embedded in the IDevID certificate=20 > (section >=20 > 2.3 defines the extension). So the Pledge can't create this lie itself, = it requires collaboration with the MI to create an IDevID. Such an MI can = point to any MASA it wishes, so long as that device can issue vouchers that= the Pledge can validate. >=20 >=20=20 >=20 > What this means is that JRC always knows the MI that created the Pledge. >=20 > If we can solve problem 1, then it's done. >=20 >=20=20 >=20 > problem 3. >=20 > Anoop> Additionally pledge >=20 > Anoop> and a random manufacturer can also collaborate to do the same. >=20 >=20=20 >=20 > I don't see how this is the case. The pledge can only collaborate with t= he manufacturer whose IDevID it has. >=20 >=20=20 >=20 > problem 4. >=20 > Anoop> In the similar way a registrar may collaborate with the=20 > manufacturer to lure >=20 > Anoop> a device using fake voucher. >=20 >=20=20 >=20 > The Pledge will only trust a voucher signed by MASA. >=20 > Any signature from a different entity will be rejected by the Pledge. >=20 > So a fake voucher is not possible. >=20 > Any voucher created by the real MASA is, by definition, not a fake vouche= r. >=20 > Can you explain this scenario clearer? >=20 > Or explain what text we need to change to clear up the mis-understanding? >=20 >=20=20 >=20 > -- >=20 > ] Never tell me the odds! | ipv6 mesh netwo= rks [ >=20 > ] Michael Richardson, Sandelman Software Works | network archite= ct [ >=20 > ] < mailto:mcr@sandelman.ca> mcr@sandelman.ca < http://www.sa= ndelman.ca/> http://www.sandelman.ca/ | = ruby on rails [ >=20 >=20=20 >=20 >=20=20 >=20 > -- >=20 > Michael Richardson < < mailto:mcr+IETF@san= delman.ca>=20 > mcr+IETF@sandelman.ca>, Sandelman Softwar= e Works -=3D IPv6 IoT=20 > consulting =3D- >=20 >=20=20 >=20 >=20=20 >=20 >=20=20 >=20 >=20 > ---------------------------------------------------------------------- > --------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/= CDACINDIA & Twitter: @cdacindia ] >=20 > This e-mail is for the sole use of the intended recipient(s) and may=20 > contain confidential and privileged information. If you are not the=20 > intended recipient, please contact the sender by reply e-mail and=20 > destroy all copies and the original message. Any unauthorized review,=20 > use, disclosure, dissemination, forwarding, printing or copying of=20 > this email is strictly prohibited and appropriate legal action will be ta= ken. > ---------------------------------------------------------------------- > --------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailm= an/listinfo/anima >=20 =20 =20 ---------------------------------------------------------------------------= ---------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ---------------------------------------------------------------------------= ---------------------------------------------------- ------=_NextPart_000_0036_01D3AA35.BD3D82F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

=E2=80=9CANIMA is scoped to support professionally managed networks. So it= seems reasonable to assume that they have procurement procedures in place = to buy from known sources and not to buy kit "off the back of a lorry&= quot; to use a British idiom.=E2=80=9D

 

= "Again - a professionally managed network! Our goal in ANIMA is not to= eliminate human operators; it is to avoid them having to perform mindless = configuration tasks or write obscure scripts. So requiring human action to = resolve a security alert is completely acceptable IMHO. In this case the de= vice might have been installed by a service technician thousands of kilomet= res away from the NOC, and if that technician did install a device from an = unknown source, this is exactly a case where the NOC should be alerted.&quo= t;

 

So, basically you reduced your scope to a = professionally managed network. Just for the sake of clarity, if it is just= like a trusted world of professionally managed network where pledges being= added are from trusted manufacturers, probably we don=E2=80=99t require th= is cryptographically maintained long procedure of bootstrapping, since trus= t is derived from the manufacturer. A trusted manufacturer gives a tr= usted device, that=E2=80=99s all. Suppose we still want to go with = this procedure and having our trust in certificates and keys, we don=E2=80= =99t require MASA and vouchers. By simply verifying if the IDevID certifica= te has been signed by a trusted MI or a trusted CA or root-RA should be suf= ficient for verifying the pledge. Pledge verifying the domain is anyway ove= rrated. Besides, it can also be done by verifying the certificate of JRC du= ring enrolment.

 

=

But it is very limited scope. I would work on expan= ding the scope to any network, any manufacturer-device pair.

 

I wou= ld also like to quote/remind following lines from Section 1.3 [Scope of Sol= ution] of the RFC:

 =

=E2=80=9CBut this solution is not exclusi= ve to the large, it is intended to scale to thousands of devices located in= hostile environments= , such as ISP provided CPE devices which are drop-shipped to the end user.= =C2=A0 The situation where an order is fulfilled from distributed warehouse= from a common stock and shipped directly to the target location at the req= uest of the domain owner is explicitly supported.=C2=A0 That stock ("S= KU") could be provided to a number of potential domain owners, and the= eventual domain owner will not know a-priori which device will go to which= location.=E2=80=9D

 

Regards,

Anoop

&nbs= p;

 

 

 

-----Original Message-----
From: Brian Carpenter [mailto:becarpenter46= @gmail.com] On Behalf Of Brian E Carpenter
Sent: 20 February 2018 01:00<= br>To: Anoop Kumar Pandey <anoop@cdac.in>; 'Michael Richardson' <m= cr+ietf@sandelman.ca>; anima@ietf.org
Subject: Re: [Anima] verificati= on of manufacturer in BRSKI

 

On 19/02/2018 21:52, Anoop Kumar Pandey wro= te:

> Dear Author,

<= p class=3DMsoPlainText>>

>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I am furthe= r expanding my query and raising concern over your response. The Problem No= s. are same as in the trailing reply.:

>

>=C2=A0

>

> Probl= em 1:

> Response: " We assum= e that in a managed network that the JRC *can* know all the legitimate manu= facturers."

>

=

>

>

> May be!! But practically may not = be possible. Manufacturers keep adding and also getting out of business. Tr= acking each MI is difficult.

&nb= sp;

ANIMA is scoped to support professiona= lly managed networks. So it seems reasonable to assume that they have procu= rement procedures in place to buy from known sources and not to buy kit &qu= ot;off the back of a lorry" to use a British idiom.

 

In other w= ords, tracking each manufacturer is *necessary* as it is in fact the origin= of the trust for the BRSKI trust model. "Difficult" is not an ex= cuse IMHO.

 

>

> Respons= e: " The keys can come from sales channel integration (via digital &qu= ot;packing slips" perhaps), can be manually loaded by humans, be scann= ed from QR codes on the box, etc.=C2=A0 We believe that this is out of scop= e.

>

> And if the JRC does see a MI that it does not know, then it = can ask a human."

>

>=C2=A0

>

> If manual interventio= n is required, then it is no longer =E2=80=9CAutomated BRSKI=E2=80=9D. Huma= ns can anyway observer and add/install new device.

 

Again - a prof= essionally managed network! Our goal in ANIMA is not to eliminate human ope= rators; it is to avoid them having to perform mindless configuration tasks = or write obscure scripts. So requiring human action to resolve a security a= lert is completely acceptable IMHO. In this case the device might have been= installed by a service technician thousands of kilometres away from the NO= C, and if that technician did install a device from an unknown source, this= is exactly a case where the NOC should be alerted.

 

=C2=A0=C2=A0= =C2=A0 Brian

 

> Problem 2:

>

> Response: The URL of the = manufacturer is embedded in the IDevID certificate (section 2.3 defines the= extension).=C2=A0 So the Pledge can't create this lie itself, it requires = collaboration with the MI to create an IDevID.

>

>

<= p class=3DMsoPlainText>>

> I h= ad asked the same thing. If pledge collaborates with a rouge MI [given Prob= lem 1 is not solved], the domain can easily be invaded.

>

>=C2=A0 <= o:p>

>

> Problem 3:

> Response= : The pledge can only collaborate with the manufacturer whose IDevID it has= .

>

>

> Agreed. Then this= problem reduces to Problem 2 where Pledge and MI can

> collaborate to fool JRC

>

>=C2=A0

>

&g= t; Problem 4:

>

> Response: The Pledge will only trust a voucher s= igned by MASA. Any signature from a different entity will be rejected by th= e Pledge. So a fake voucher is not possible.

>

>=C2=A0 <= /p>

>

>= I only raised concern that there is no way to detect if MASA and JRC have = collaborated to lure the pledge into a malicious domain unless the MASA cer= tificate and IDevID certificate have common Root Certifying authority.=

>

>=C2=A0

>

> Regards,

&= gt;

> Anoop

>

>=C2=A0

>

>=C2=A0

>

=

> -----Original Message-----

> From: Michael Richardson [mailt= o:mcr+ietf@sandelman.ca]

&= gt; Sent: 19 February 2018 05:57

>= To: anima@ietf.org

> Cc: Anoop Kumar Pandey <anoop@cdac.in= >

> Subject: verification of ma= nufacturer in BRSKI

> <= /p>

>=C2=A0

>

>=C2=A0

>

> {sorr= y if this is a duplicate, my draft folder says it did not go out}

>

&g= t;=C2=A0

>

> Anoop Kumar Pandey < <mailto:anoop@= cdac.in> anoop@cdac.in> wrote direc= tly to the draft authors list, and then gave me permission to share this on= the list:

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> This is in context= to the RFC detailing process of

>= ; enrolling a pledge to a

> <= /o:p>

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> dom= ain. The major problem with the procedure is that the

> registrar doesn=E2=80=99t

>

>=C2=A0=C2=A0=C2= =A0=C2=A0 Anoop> verify the manufacturer. It simply verifies the voucher= and

> enrols the

<= p class=3DMsoPlainText>>

>=C2= =A0=C2=A0=C2=A0=C2=A0 Anoop> pledge. If pledge send a self-defined URL o= f manufacturer

> where provision = for

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> issuing fake vouchers is = in place, then the registrar can

>= ; be fooled into

>

=

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> enrolment [a= ssuming the registrar can=E2=80=99t know all the

> manufacturers

> =

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop&g= t; exhaustively] and later exploited from inside the domain.

> Additionally pledge

>

>=C2=A0=C2=A0= =C2=A0=C2=A0 Anoop> and a random manufacturer can also collaborate to do= the same.

>

>=C2=A0

>

> You raise a number of issues.

>

>=C2=A0

>

<= p class=3DMsoPlainText>> So let me name them so that we can discuss them= easier, and make sure that I understand you correctly.

>

> Probabl= y, we need to add some text to the Security Considerations, and I would wel= come your help in crafting that text!

>

>=C2=A0

>

>=C2=A0= =C2=A0=C2=A0=C2=A0 Anoop> In the similar way a registrar may collaborate= with the

> manufacturer to lure<= o:p>

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> a device using fake voucher.<= o:p>

>

>=C2=A0

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> How can th= ese problems be tackled?

>

>=C2=A0

>

> I agree that the Pl= edge may point at any Manufacturer (in the form of

> a MASA)

>

> that it wishes to.=C2=A0=C2=A0 The= following identities exist:

>

>=C2=A0

>

> 1) The Pledge's= Identity (PI) in the form an IDevID certificate.

>

>=C2=A0=C2=A0= =C2=A0 (It signs the voucher request to the JRC, and the Client side of

> the TLS

>

>=C2=A0=C2=A0=C2= =A0 connection from Pledge to JRC)

&g= t;

> 2) The Manufacturer's Identi= ty (MI) which signs the IDevID certificate.

>

> 3) The MASA Identit= y (MASA) which signs the voucher.

>= ;

> 4) The Join Registrar (JRC) w= hich signs the voucher request to the MASA.

>

>=C2=A0=C2=A0=C2=A0 I= t also signs the Server side of the TLS connection from Pledge to JRC.=

>

> 5) The Domain PKI Certificate Authority, which signs the LDevID.

>

>=C2=A0

>

=

> (The MI might be the same as the MASA, but in = general the MASA may be

> outsour= ced.=C2=A0 The Pledge SHOULD have a trusted anchor for both, but it

> can be designed where it has a manufac= turer CA which signs both MASA

> = and MI certificate)

> <= /p>

>=C2=A0

>

> Each of these in essence= represent a private key!

> <= /o:p>

> I'd like start by ruling out of bound= s for this discussion any scenario where the attack requires that the priva= te key be leaked, shared or used incorrectly.=C2=A0 It's not that they can'= t happen, but rather that it is a problem of TPMs, etc. and not protocol de= sign.

>

>=C2=A0

>

> The Pledge trusts network part works b= y:

>

> a) MASA signs VOUCHER.

>

> b) VOUCHER lists JRC in p= inned-domain-cert.

>

> c) Pledge uses MASA to validate VOUCHER, and= therefore validates JRC.

> <= /o:p>

> d) JRC can also audit (verify signatu= res even) the voucher really

> co= mes

>

>=C2=A0=C2=A0=C2=A0 from MASA, although unless there is a com= mon CA, it may not be able

> to

>

>=C2=A0=C2=A0=C2=A0 prove MASA and MI are same entity.<= /p>

>

>= =C2=A0

>

> The JRC trusts Pledge part works by:

>

> e) MI= signs IDevID.

>

> f) Pledge uses IDevID to identify to JRC.

>

> g) JRC validates IDevID using MI certificate.

>

>=C2=A0

>

> Now, to translate what you said:

>

>=C2=A0

=

>

> pr= oblem 1.

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> The major problem wi= th the procedure is that the registrar

> doesn=E2=80=99t

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> verif= y the manufacturer.

> <= /p>

>=C2=A0

>

> To translate, the JRC ha= s no obvious way to verify that the "MI" key

> belongs

> =

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to the manufacturer = that they care about.

>

>=C2=A0

>

> You actually hit the m= ajor reason this is not a problem when you assume:

>

>=C2=A0=C2= =A0=C2=A0 > assuming the registrar can=E2=80=99t know all the manufactur= ers

> exhaustively

=

>

>=C2= =A0

>

> We assume that in a managed network that the JRC *can* kno= w all the legitimate manufacturers.=C2=A0 The keys can come from sales chan= nel integration (via digital "packing slips" perhaps), can be man= ually loaded by humans, be scanned from QR codes on the box, etc.=C2=A0 We = believe that this is out of scope.

&g= t;

>=C2=A0

>

> And if th= e JRC does see a MI that it does not know, then it can ask a human.

>

= > That's one reason we made sure that failures to enroll do not cause th= e Pledge to never try again with that JRC.=C2=A0 It needs to try again late= r, because maybe nobody has answered the "Yes/No" Dialog on the m= anagement station yet.

>

>=C2=A0

>

> And of course there i= s the WebPKI.=C2=A0 We aren't saying that MI keys (or MASA server TLS keys)= MUST be in the WebPKI, but we aren't saying that they can't be.=C2=A0 That= 's not a panacea... between ComodoGate type situations and certificates for= "C1SC0" in a hard to distinguish font, many social engineering a= ttacks could get that "Yes" button pressed.

>

>=C2=A0

>

>=C2=A0

>

=

> problem 2.

>

>=C2=A0=C2=A0=C2=A0=C2=A0= Anoop> If pledge send a self-defined URL of manufacturer where

> provision for

>

>=C2=A0=C2=A0= =C2=A0=C2=A0 Anoop> issuing fake vouchers is in place, then the registra= r can

> be fooled into=

>

>= ;=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> enrolment [assuming the registrar can= =E2=80=99t know all the

> manufac= turers

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> exhaustively] and la= ter exploited from inside the domain.

>

>=C2=A0

>

> The UR= L of the manufacturer is embedded in the IDevID certificate

=

> (section

>

> 2.3 defines the extension= ).=C2=A0 So the Pledge can't create this lie itself, it requires collaborat= ion with the MI to create an IDevID.=C2=A0 Such an MI can point to any MASA= it wishes, so long as that device can issue vouchers that the Pledge can v= alidate.

>

>=C2=A0

>

> What this means is that JRC always = knows the MI that created the Pledge.

>

> If we can solve problem 1= , then it's done.

>

>=C2=A0

= >

> problem 3.

<= p class=3DMsoPlainText>>

>=C2= =A0=C2=A0=C2=A0=C2=A0 Anoop> Additionally pledge

>

>=C2=A0=C2= =A0=C2=A0=C2=A0 Anoop> and a random manufacturer can also collaborate to= do the same.

>

>=C2=A0

>=

> I don't see how this is the ca= se.=C2=A0 The pledge can only collaborate with the manufacturer whose IDevI= D it has.

>

>=C2=A0

>

> problem 4.

>

>=C2=A0=C2= =A0=C2=A0=C2=A0 Anoop> In the similar way a registrar may collaborate wi= th the

> manufacturer to lure

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Anoop> a device using fake voucher.

>

>=C2=A0

>

<= p class=3DMsoPlainText>> The Pledge will only trust a voucher signed by = MASA.

>

> Any signature from a different entity will be rejected by= the Pledge.

>

> So a fake voucher is not possible.

<= p class=3DMsoPlainText>>

> Any= voucher created by the real MASA is, by definition, not a fake voucher.

>

> Can you explain this scenario clearer?

>

> Or explain wha= t text we need to change to clear up the mis-understanding?

<= p class=3DMsoPlainText>>

>=C2= =A0

>

> --

> <= /p>

> ]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Never tell me the odds!=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | ipv6 mesh networks [

&= gt;

> ]=C2=A0=C2=A0 Michael Richa= rdson, Sandelman Software Works=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= network architect =C2=A0[

> =

> ]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= mailto:mcr@sandelman.ca> mcr@sa= ndelman.ca=C2=A0=C2=A0 <= http://www.sandelman.= ca/> http://www.sandelman.ca/=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 ruby on rails=C2=A0= =C2=A0=C2=A0 [

>

>=C2=A0

>= ;

>=C2=A0

>

> --

>

= > Michael Richardson < <<= span style=3D'color:windowtext;text-decoration:none'>mailto:mcr+IETF@sandel= man.ca>

> mcr+IETF@sandelman.ca>, Sandelman Software Works= =C2=A0 -=3D IPv6 IoT

> consulting= =3D-

>

>=C2=A0

>

>=C2=A0

>

>=C2=A0

>

> =

> -------------------------------= ---------------------------------------

> ---------------------------------------------------------

> [ C-DAC is on Social-Media too. Kindly fo= llow us at:

> Facebook: https://www.facebook.com/CDACINDIA & Twitter= : @cdacindia ]

>

> This e-mail is for the sole use of the intended = recipient(s) and may

> contain co= nfidential and privileged information. If you are not the

> intended recipient, please contact the sender by= reply e-mail and

> destroy all c= opies and the original message. Any unauthorized review,

> use, disclosure, dissemination, forwarding, print= ing or copying of

> this email is= strictly prohibited and appropriate legal action will be taken.=

> ------------------------------------------= ----------------------------

> ---= ------------------------------------------------------

>

>

>

= >

> __________________________= _____________________

> Anima mail= ing list

> Anima@ietf= .org

> https://www.ietf.org/mailman/listinfo/anima

>

 

 


------------------------------------------------------------------= -------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= ---------------------------------------------------------- ------=_NextPart_000_0036_01D3AA35.BD3D82F0-- From nobody Mon Feb 19 22:21:42 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62F5126D74 for ; Mon, 19 Feb 2018 22:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uc9f_nyvnEET for ; Mon, 19 Feb 2018 22:21:38 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14A0124235 for ; Mon, 19 Feb 2018 22:21:37 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 13B6158C514; Tue, 20 Feb 2018 07:21:32 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id EA212B0DAEC; Tue, 20 Feb 2018 07:21:31 +0100 (CET) Date: Tue, 20 Feb 2018 07:21:31 +0100 From: Toerless Eckert To: Anoop Kumar Pandey Cc: 'Brian E Carpenter' , 'Michael Richardson' , anima@ietf.org Message-ID: <20180220062131.GA23498@faui40p.informatik.uni-erlangen.de> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003501d3aa07$a37f0560$ea7d1020$@cdac.in> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 06:21:41 -0000 Anoop, > So, basically you reduced your scope to a professionally managed network. The term 'professionally managed' is in the ANIMA charter, see https://datatracker.ietf.org/doc/charter-ietf-anima/ It was just meant to provide a clear delineation of anima vs. Homenet or similar networks, which are meant to operate primarily unmanaged. I think it is a vey broad scope. > Just for the sake of clarity, if it is just like a trusted world of professionally managed network where pledges being added are from trusted manufacturers, probably we don???t require this cryptographically maintained long procedure of bootstrapping, since trust is derived from the manufacturer. A trusted manufacturer gives a trusted device, that???s all. I do not know what a 'trusted world' is, we have not been using that term in ANIMA. Do you mind to elaborate what you think is redundant in the "cryptographically maintained long procedure" ? > Suppose we still want to go with this procedure and having our trust in certificates and keys, we don???t require MASA and vouchers. By simply verifying if the IDevID certificate has been signed by a trusted MI or a trusted CA or root-RA should be sufficient for verifying the pledge. MASA and Voucher are not used to verify the pledge. If you think you read that in BRSKI, please point to the text section that confused you about this. > Pledge verifying the domain is anyway overrated. That is in the eye of the beholder. If you are a buyer of large number of pledges and do not need any protection against theft, misassignment of pledges to other networks or intrusions into pledges that intend to impact your network later, then sure - you may be happy with pledges not requiring vouchers to get enrolled. BRSKI already mentions in the appendix a range of variations mostly with lower security. It does not cover all possible lower security variants such as no-MASA/voucher primarily because we wanted the final BRSKI RFC number to actually mean something wrt to security to buyers of products claiming to support it. If everythng was optional, nothing is really standardized. It would just be like calling a lottery a standard for Millionaires. > Besides, it can also be done by verifying the certificate of JRC during enrolment. That actually is what the voucher does. Feel free to propose alternatives. I have a hard time imagining solutions that either do not achieve the goal, add pre-staging steps or just reinvent what the voucher does under a different name. Cheers Toerless On Tue, Feb 20, 2018 at 10:29:47AM +0530, Anoop Kumar Pandey wrote: > ???ANIMA is scoped to support professionally managed networks. So it seems reasonable to assume that they have procurement procedures in place to buy from known sources and not to buy kit "off the back of a lorry" to use a British idiom.??? > > > > "Again - a professionally managed network! Our goal in ANIMA is not to eliminate human operators; it is to avoid them having to perform mindless configuration tasks or write obscure scripts. So requiring human action to resolve a security alert is completely acceptable IMHO. In this case the device might have been installed by a service technician thousands of kilometres away from the NOC, and if that technician did install a device from an unknown source, this is exactly a case where the NOC should be alerted." > > > > > > > But it is very limited scope. I would work on expanding the scope to any network, any manufacturer-device pair. > > > > I would also like to quote/remind following lines from Section 1.3 [Scope of Solution] of the RFC: > > > > ???But this solution is not exclusive to the large, it is intended to scale to thousands of devices located in hostile environments, such as ISP provided CPE devices which are drop-shipped to the end user. The situation where an order is fulfilled from distributed warehouse from a common stock and shipped directly to the target location at the request of the domain owner is explicitly supported. That stock ("SKU") could be provided to a number of potential domain owners, and the eventual domain owner will not know a-priori which device will go to which location.??? > > > > Regards, > > Anoop > > > > > > > > > > -----Original Message----- > From: Brian Carpenter [mailto:becarpenter46@gmail.com] On Behalf Of Brian E Carpenter > Sent: 20 February 2018 01:00 > To: Anoop Kumar Pandey ; 'Michael Richardson' ; anima@ietf.org > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > On 19/02/2018 21:52, Anoop Kumar Pandey wrote: > > > Dear Author, > > > > > > I am further expanding my query and raising concern over your response. The Problem Nos. are same as in the trailing reply.: > > > > > > > > > > > > Problem 1: > > > Response: " We assume that in a managed network that the JRC *can* know all the legitimate manufacturers." > > > > > > > > > > > > May be!! But practically may not be possible. Manufacturers keep adding and also getting out of business. Tracking each MI is difficult. > > > > ANIMA is scoped to support professionally managed networks. So it seems reasonable to assume that they have procurement procedures in place to buy from known sources and not to buy kit "off the back of a lorry" to use a British idiom. > > > > In other words, tracking each manufacturer is *necessary* as it is in fact the origin of the trust for the BRSKI trust model. "Difficult" is not an excuse IMHO. > > > > > > > > Response: " The keys can come from sales channel integration (via digital "packing slips" perhaps), can be manually loaded by humans, be scanned from QR codes on the box, etc. We believe that this is out of scope. > > > > > > And if the JRC does see a MI that it does not know, then it can ask a human." > > > > > > > > > > > > If manual intervention is required, then it is no longer ???Automated BRSKI???. Humans can anyway observer and add/install new device. > > > > Again - a professionally managed network! Our goal in ANIMA is not to eliminate human operators; it is to avoid them having to perform mindless configuration tasks or write obscure scripts. So requiring human action to resolve a security alert is completely acceptable IMHO. In this case the device might have been installed by a service technician thousands of kilometres away from the NOC, and if that technician did install a device from an unknown source, this is exactly a case where the NOC should be alerted. > > > > Brian > > > > > Problem 2: > > > > > > Response: The URL of the manufacturer is embedded in the IDevID certificate (section 2.3 defines the extension). So the Pledge can't create this lie itself, it requires collaboration with the MI to create an IDevID. > > > > > > > > > > > > I had asked the same thing. If pledge collaborates with a rouge MI [given Problem 1 is not solved], the domain can easily be invaded. > > > > > > > > > > > > Problem 3: > > > Response: The pledge can only collaborate with the manufacturer whose IDevID it has. > > > > > > > > > Agreed. Then this problem reduces to Problem 2 where Pledge and MI can > > > collaborate to fool JRC > > > > > > > > > > > > Problem 4: > > > > > > Response: The Pledge will only trust a voucher signed by MASA. Any signature from a different entity will be rejected by the Pledge. So a fake voucher is not possible. > > > > > > > > > > > > I only raised concern that there is no way to detect if MASA and JRC have collaborated to lure the pledge into a malicious domain unless the MASA certificate and IDevID certificate have common Root Certifying authority. > > > > > > > > > > > > Regards, > > > > > > Anoop > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Michael Richardson [ mailto:mcr+ietf@sandelman.ca] > > > Sent: 19 February 2018 05:57 > > > To: anima@ietf.org > > > Cc: Anoop Kumar Pandey < anoop@cdac.in> > > > Subject: verification of manufacturer in BRSKI > > > > > > > > > > > > > > > > > > {sorry if this is a duplicate, my draft folder says it did not go out} > > > > > > > > > > > > Anoop Kumar Pandey < < mailto:anoop@cdac.in> anoop@cdac.in> wrote directly to the draft authors list, and then gave me permission to share this on the list: > > > > > > Anoop> This is in context to the RFC detailing process of > > > enrolling a pledge to a > > > > > > Anoop> domain. The major problem with the procedure is that the > > > registrar doesn???t > > > > > > Anoop> verify the manufacturer. It simply verifies the voucher and > > > enrols the > > > > > > Anoop> pledge. If pledge send a self-defined URL of manufacturer > > > where provision for > > > > > > Anoop> issuing fake vouchers is in place, then the registrar can > > > be fooled into > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > manufacturers > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > Additionally pledge > > > > > > Anoop> and a random manufacturer can also collaborate to do the same. > > > > > > > > > > > > You raise a number of issues. > > > > > > > > > > > > So let me name them so that we can discuss them easier, and make sure that I understand you correctly. > > > > > > Probably, we need to add some text to the Security Considerations, and I would welcome your help in crafting that text! > > > > > > > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > manufacturer to lure > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > Anoop> How can these problems be tackled? > > > > > > > > > > > > I agree that the Pledge may point at any Manufacturer (in the form of > > > a MASA) > > > > > > that it wishes to. The following identities exist: > > > > > > > > > > > > 1) The Pledge's Identity (PI) in the form an IDevID certificate. > > > > > > (It signs the voucher request to the JRC, and the Client side of > > > the TLS > > > > > > connection from Pledge to JRC) > > > > > > 2) The Manufacturer's Identity (MI) which signs the IDevID certificate. > > > > > > 3) The MASA Identity (MASA) which signs the voucher. > > > > > > 4) The Join Registrar (JRC) which signs the voucher request to the MASA. > > > > > > It also signs the Server side of the TLS connection from Pledge to JRC. > > > > > > 5) The Domain PKI Certificate Authority, which signs the LDevID. > > > > > > > > > > > > (The MI might be the same as the MASA, but in general the MASA may be > > > outsourced. The Pledge SHOULD have a trusted anchor for both, but it > > > can be designed where it has a manufacturer CA which signs both MASA > > > and MI certificate) > > > > > > > > > > > > Each of these in essence represent a private key! > > > > > > I'd like start by ruling out of bounds for this discussion any scenario where the attack requires that the private key be leaked, shared or used incorrectly. It's not that they can't happen, but rather that it is a problem of TPMs, etc. and not protocol design. > > > > > > > > > > > > The Pledge trusts network part works by: > > > > > > a) MASA signs VOUCHER. > > > > > > b) VOUCHER lists JRC in pinned-domain-cert. > > > > > > c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. > > > > > > d) JRC can also audit (verify signatures even) the voucher really > > > comes > > > > > > from MASA, although unless there is a common CA, it may not be able > > > to > > > > > > prove MASA and MI are same entity. > > > > > > > > > > > > The JRC trusts Pledge part works by: > > > > > > e) MI signs IDevID. > > > > > > f) Pledge uses IDevID to identify to JRC. > > > > > > g) JRC validates IDevID using MI certificate. > > > > > > > > > > > > Now, to translate what you said: > > > > > > > > > > > > problem 1. > > > > > > Anoop> The major problem with the procedure is that the registrar > > > doesn???t > > > > > > Anoop> verify the manufacturer. > > > > > > > > > > > > To translate, the JRC has no obvious way to verify that the "MI" key > > > belongs > > > > > > to the manufacturer that they care about. > > > > > > > > > > > > You actually hit the major reason this is not a problem when you assume: > > > > > > > assuming the registrar can???t know all the manufacturers > > > exhaustively > > > > > > > > > > > > We assume that in a managed network that the JRC *can* know all the legitimate manufacturers. The keys can come from sales channel integration (via digital "packing slips" perhaps), can be manually loaded by humans, be scanned from QR codes on the box, etc. We believe that this is out of scope. > > > > > > > > > > > > And if the JRC does see a MI that it does not know, then it can ask a human. > > > > > > That's one reason we made sure that failures to enroll do not cause the Pledge to never try again with that JRC. It needs to try again later, because maybe nobody has answered the "Yes/No" Dialog on the management station yet. > > > > > > > > > > > > And of course there is the WebPKI. We aren't saying that MI keys (or MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that they can't be. That's not a panacea... between ComodoGate type situations and certificates for "C1SC0" in a hard to distinguish font, many social engineering attacks could get that "Yes" button pressed. > > > > > > > > > > > > > > > > > > problem 2. > > > > > > Anoop> If pledge send a self-defined URL of manufacturer where > > > provision for > > > > > > Anoop> issuing fake vouchers is in place, then the registrar can > > > be fooled into > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > manufacturers > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > > > > > > > > > > The URL of the manufacturer is embedded in the IDevID certificate > > > (section > > > > > > 2.3 defines the extension). So the Pledge can't create this lie itself, it requires collaboration with the MI to create an IDevID. Such an MI can point to any MASA it wishes, so long as that device can issue vouchers that the Pledge can validate. > > > > > > > > > > > > What this means is that JRC always knows the MI that created the Pledge. > > > > > > If we can solve problem 1, then it's done. > > > > > > > > > > > > problem 3. > > > > > > Anoop> Additionally pledge > > > > > > Anoop> and a random manufacturer can also collaborate to do the same. > > > > > > > > > > > > I don't see how this is the case. The pledge can only collaborate with the manufacturer whose IDevID it has. > > > > > > > > > > > > problem 4. > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > manufacturer to lure > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > The Pledge will only trust a voucher signed by MASA. > > > > > > Any signature from a different entity will be rejected by the Pledge. > > > > > > So a fake voucher is not possible. > > > > > > Any voucher created by the real MASA is, by definition, not a fake voucher. > > > > > > Can you explain this scenario clearer? > > > > > > Or explain what text we need to change to clear up the mis-understanding? > > > > > > > > > > > > -- > > > > > > ] Never tell me the odds! | ipv6 mesh networks [ > > > > > > ] Michael Richardson, Sandelman Software Works | network architect [ > > > > > > ] < mailto:mcr@sandelman.ca> mcr@sandelman.ca < http://www.sandelman.ca/> http://www.sandelman.ca/ | ruby on rails [ > > > > > > > > > > > > > > > > > > -- > > > > > > Michael Richardson < < mailto:mcr+IETF@sandelman.ca> > > > mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT > > > consulting =- > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > > > > > This e-mail is for the sole use of the intended recipient(s) and may > > > contain confidential and privileged information. If you are not the > > > intended recipient, please contact the sender by reply e-mail and > > > destroy all copies and the original message. Any unauthorized review, > > > use, disclosure, dissemination, forwarding, printing or copying of > > > this email is strictly prohibited and appropriate legal action will be taken. > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > > > > > > > > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > ------------------------------------------------------------------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Feb 20 02:02:11 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79B9124239 for ; Tue, 20 Feb 2018 02:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wzxKkzd90MbL for ; Tue, 20 Feb 2018 02:02:00 -0800 (PST) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19A7126CBF for ; Tue, 20 Feb 2018 02:01:58 -0800 (PST) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w1KA1GVa017910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Feb 2018 15:31:19 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w1KA0KuH020958; Tue, 20 Feb 2018 15:30:20 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w1KA0Hn3011305; Tue, 20 Feb 2018 15:30:19 +0530 From: "Anoop Kumar Pandey" To: "'Toerless Eckert'" Cc: "'Brian E Carpenter'" , "'Michael Richardson'" , References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> <20180220062131.GA23498@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180220062131.GA23498@faui40p.informatik.uni-erlangen.de> Date: Tue, 20 Feb 2018 15:30:14 +0530 Message-ID: <00b701d3aa31$9d13db40$d73b91c0$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B8_01D3AA5F.B6D4A2C0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-in Thread-Index: AQE2I/joFI0/xQRcLlXQFy4X95wT3AJMjcXyAfHjFIQBMe5HLwJpWVH6AdhO8q2kmlW8AA== X-CDAC-PUNE-MailScanner-ID: w1KA0KuH020958 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.198, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.798, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w1KA1GVa017910 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 10:02:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B8_01D3AA5F.B6D4A2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >"I do not know what a 'trusted world' is, we have not been using that term in ANIMA. >Do you mind to elaborate what you think is redundant in the "cryptographically maintained long procedure" ?" Trusted world is something like "every entity in the domain is a trusted entity." Also in this case, trust can be derived. For example, if a pledge is issued by a trusted/enlisted MI, then that pledge can also be trusted. Here the trust is derived from the MI. Michael had mentioned in earlier mail, "JRC trusts pledge by validating IDevID using MI certificate." and you mentioned "MASA and Voucher are not used to verify the pledge."" If so, then I thought that 'JRC verifying audit log and voucher' step is redundant. [Page 16 of RFC] It may not be required unless further investigation into history of pledge is required. For the statement :- Pledge verifying the domain is anyway overrated >". If you are a buyer of large number of pledges and do not need any protection against theft, misassignment of pledges to other networks or intrusions into pledges that intend to impact your network later, then >sure - you may be happy with pledges not requiring vouchers to get enrolled." Theft is anyway physical security breach. It may happen irrespective of BRSKI in place. Misassignment of pledge to other network can be easily detected if pledge is not accessible in the actual network. Intrusion in pledge can't be stopped using BRSKI. That depends on methods of authentication and authorization employed to access the pledge. Pledge is a device. If I buy/add a device, I need to verify if it is compromised or not or if it comes from a trusted MI. Device need not verify me if it wants to work in my environment or not. If pledge doesn't require to validate JRC then "MASA issuing voucher and pledge using that voucher to validate and enroll to JRC" is redundant. That's all from my side. I thought that this system could work in any environment and I was trying to convince myself of the same and ascertain that no loopholes are left so far as my understanding is concerned. Regards, Anoop -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de] Sent: 20 February 2018 11:52 To: Anoop Kumar Pandey Cc: 'Brian E Carpenter' ; 'Michael Richardson' ; anima@ietf.org Subject: Re: [Anima] verification of manufacturer in BRSKI Anoop, > So, basically you reduced your scope to a professionally managed network. The term 'professionally managed' is in the ANIMA charter, see https://datatracker.ietf.org/doc/charter-ietf-anima/ It was just meant to provide a clear delineation of anima vs. Homenet or similar networks, which are meant to operate primarily unmanaged. I think it is a vey broad scope. > Just for the sake of clarity, if it is just like a trusted world of professionally managed network where pledges being added are from trusted manufacturers, probably we don???t require this cryptographically maintained long procedure of bootstrapping, since trust is derived from the manufacturer. A trusted manufacturer gives a trusted device, that???s all. I do not know what a 'trusted world' is, we have not been using that term in ANIMA. Do you mind to elaborate what you think is redundant in the "cryptographically maintained long procedure" ? > Suppose we still want to go with this procedure and having our trust in certificates and keys, we don???t require MASA and vouchers. By simply verifying if the IDevID certificate has been signed by a trusted MI or a trusted CA or root-RA should be sufficient for verifying the pledge. MASA and Voucher are not used to verify the pledge. If you think you read that in BRSKI, please point to the text section that confused you about this. > Pledge verifying the domain is anyway overrated. That is in the eye of the beholder. If you are a buyer of large number of pledges and do not need any protection against theft, misassignment of pledges to other networks or intrusions into pledges that intend to impact your network later, then sure - you may be happy with pledges not requiring vouchers to get enrolled. BRSKI already mentions in the appendix a range of variations mostly with lower security. It does not cover all possible lower security variants such as no-MASA/voucher primarily because we wanted the final BRSKI RFC number to actually mean something wrt to security to buyers of products claiming to support it. If everythng was optional, nothing is really standardized. It would just be like calling a lottery a standard for Millionaires. > Besides, it can also be done by verifying the certificate of JRC during enrolment. That actually is what the voucher does. Feel free to propose alternatives. I have a hard time imagining solutions that either do not achieve the goal, add pre-staging steps or just reinvent what the voucher does under a different name. Cheers Toerless On Tue, Feb 20, 2018 at 10:29:47AM +0530, Anoop Kumar Pandey wrote: > ???ANIMA is scoped to support professionally managed networks. So it seems reasonable to assume that they have procurement procedures in place to buy from known sources and not to buy kit "off the back of a lorry" to use a British idiom.??? > > > > "Again - a professionally managed network! Our goal in ANIMA is not to eliminate human operators; it is to avoid them having to perform mindless configuration tasks or write obscure scripts. So requiring human action to resolve a security alert is completely acceptable IMHO. In this case the device might have been installed by a service technician thousands of kilometres away from the NOC, and if that technician did install a device from an unknown source, this is exactly a case where the NOC should be alerted." > > > > > > > But it is very limited scope. I would work on expanding the scope to any network, any manufacturer-device pair. > > > > I would also like to quote/remind following lines from Section 1.3 [Scope of Solution] of the RFC: > > > > ???But this solution is not exclusive to the large, it is intended to scale to thousands of devices located in hostile environments, such as ISP provided CPE devices which are drop-shipped to the end user. The situation where an order is fulfilled from distributed warehouse from a common stock and shipped directly to the target location at the request of the domain owner is explicitly supported. That stock ("SKU") could be provided to a number of potential domain owners, and the eventual domain owner will not know a-priori which device will go to which location.??? > > > > Regards, > > Anoop > > > > > > > > > > -----Original Message----- > From: Brian Carpenter [ mailto:becarpenter46@gmail.com] On Behalf Of > Brian E Carpenter > Sent: 20 February 2018 01:00 > To: Anoop Kumar Pandey < anoop@cdac.in>; 'Michael Richardson' > < mcr+ietf@sandelman.ca>; anima@ietf.org > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > On 19/02/2018 21:52, Anoop Kumar Pandey wrote: > > > Dear Author, > > > > > > I am further expanding my query and raising concern over your response. The Problem Nos. are same as in the trailing reply.: > > > > > > > > > > > > Problem 1: > > > Response: " We assume that in a managed network that the JRC *can* know all the legitimate manufacturers." > > > > > > > > > > > > May be!! But practically may not be possible. Manufacturers keep adding and also getting out of business. Tracking each MI is difficult. > > > > ANIMA is scoped to support professionally managed networks. So it seems reasonable to assume that they have procurement procedures in place to buy from known sources and not to buy kit "off the back of a lorry" to use a British idiom. > > > > In other words, tracking each manufacturer is *necessary* as it is in fact the origin of the trust for the BRSKI trust model. "Difficult" is not an excuse IMHO. > > > > > > > > Response: " The keys can come from sales channel integration (via digital "packing slips" perhaps), can be manually loaded by humans, be scanned from QR codes on the box, etc. We believe that this is out of scope. > > > > > > And if the JRC does see a MI that it does not know, then it can ask a human." > > > > > > > > > > > > If manual intervention is required, then it is no longer ???Automated BRSKI???. Humans can anyway observer and add/install new device. > > > > Again - a professionally managed network! Our goal in ANIMA is not to eliminate human operators; it is to avoid them having to perform mindless configuration tasks or write obscure scripts. So requiring human action to resolve a security alert is completely acceptable IMHO. In this case the device might have been installed by a service technician thousands of kilometres away from the NOC, and if that technician did install a device from an unknown source, this is exactly a case where the NOC should be alerted. > > > > Brian > > > > > Problem 2: > > > > > > Response: The URL of the manufacturer is embedded in the IDevID certificate (section 2.3 defines the extension). So the Pledge can't create this lie itself, it requires collaboration with the MI to create an IDevID. > > > > > > > > > > > > I had asked the same thing. If pledge collaborates with a rouge MI [given Problem 1 is not solved], the domain can easily be invaded. > > > > > > > > > > > > Problem 3: > > > Response: The pledge can only collaborate with the manufacturer whose IDevID it has. > > > > > > > > > Agreed. Then this problem reduces to Problem 2 where Pledge and MI > > can > > > collaborate to fool JRC > > > > > > > > > > > > Problem 4: > > > > > > Response: The Pledge will only trust a voucher signed by MASA. Any signature from a different entity will be rejected by the Pledge. So a fake voucher is not possible. > > > > > > > > > > > > I only raised concern that there is no way to detect if MASA and JRC have collaborated to lure the pledge into a malicious domain unless the MASA certificate and IDevID certificate have common Root Certifying authority. > > > > > > > > > > > > Regards, > > > > > > Anoop > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Michael Richardson [ < mailto:mcr+ietf@sandelman.ca> > > mailto:mcr+ietf@sandelman.ca] > > > Sent: 19 February 2018 05:57 > > > To: < mailto:anima@ietf.org> anima@ietf.org > > > Cc: Anoop Kumar Pandey < < mailto:anoop@cdac.in> anoop@cdac.in> > > > Subject: verification of manufacturer in BRSKI > > > > > > > > > > > > > > > > > > {sorry if this is a duplicate, my draft folder says it did not go > > out} > > > > > > > > > > > > Anoop Kumar Pandey < < < mailto:anoop@cdac.in> mailto:anoop@cdac.in> < mailto:anoop@cdac.in> anoop@cdac.in> wrote directly to the draft authors list, and then gave me permission to share this on the list: > > > > > > Anoop> This is in context to the RFC detailing process of > > > enrolling a pledge to a > > > > > > Anoop> domain. The major problem with the procedure is that the > > > registrar doesn???t > > > > > > Anoop> verify the manufacturer. It simply verifies the voucher > > and > > > enrols the > > > > > > Anoop> pledge. If pledge send a self-defined URL of manufacturer > > > where provision for > > > > > > Anoop> issuing fake vouchers is in place, then the registrar can > > > be fooled into > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > manufacturers > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > Additionally pledge > > > > > > Anoop> and a random manufacturer can also collaborate to do the same. > > > > > > > > > > > > You raise a number of issues. > > > > > > > > > > > > So let me name them so that we can discuss them easier, and make sure that I understand you correctly. > > > > > > Probably, we need to add some text to the Security Considerations, and I would welcome your help in crafting that text! > > > > > > > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > manufacturer to lure > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > Anoop> How can these problems be tackled? > > > > > > > > > > > > I agree that the Pledge may point at any Manufacturer (in the form > > of > > > a MASA) > > > > > > that it wishes to. The following identities exist: > > > > > > > > > > > > 1) The Pledge's Identity (PI) in the form an IDevID certificate. > > > > > > (It signs the voucher request to the JRC, and the Client side of > > > the TLS > > > > > > connection from Pledge to JRC) > > > > > > 2) The Manufacturer's Identity (MI) which signs the IDevID certificate. > > > > > > 3) The MASA Identity (MASA) which signs the voucher. > > > > > > 4) The Join Registrar (JRC) which signs the voucher request to the MASA. > > > > > > It also signs the Server side of the TLS connection from Pledge to JRC. > > > > > > 5) The Domain PKI Certificate Authority, which signs the LDevID. > > > > > > > > > > > > (The MI might be the same as the MASA, but in general the MASA may > > be > > > outsourced. The Pledge SHOULD have a trusted anchor for both, but > > it > > > can be designed where it has a manufacturer CA which signs both MASA > > > and MI certificate) > > > > > > > > > > > > Each of these in essence represent a private key! > > > > > > I'd like start by ruling out of bounds for this discussion any scenario where the attack requires that the private key be leaked, shared or used incorrectly. It's not that they can't happen, but rather that it is a problem of TPMs, etc. and not protocol design. > > > > > > > > > > > > The Pledge trusts network part works by: > > > > > > a) MASA signs VOUCHER. > > > > > > b) VOUCHER lists JRC in pinned-domain-cert. > > > > > > c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. > > > > > > d) JRC can also audit (verify signatures even) the voucher really > > > comes > > > > > > from MASA, although unless there is a common CA, it may not be > > able > > > to > > > > > > prove MASA and MI are same entity. > > > > > > > > > > > > The JRC trusts Pledge part works by: > > > > > > e) MI signs IDevID. > > > > > > f) Pledge uses IDevID to identify to JRC. > > > > > > g) JRC validates IDevID using MI certificate. > > > > > > > > > > > > Now, to translate what you said: > > > > > > > > > > > > problem 1. > > > > > > Anoop> The major problem with the procedure is that the > > registrar > > > doesn???t > > > > > > Anoop> verify the manufacturer. > > > > > > > > > > > > To translate, the JRC has no obvious way to verify that the "MI" key > > > belongs > > > > > > to the manufacturer that they care about. > > > > > > > > > > > > You actually hit the major reason this is not a problem when you assume: > > > > > > > assuming the registrar can???t know all the manufacturers > > > exhaustively > > > > > > > > > > > > We assume that in a managed network that the JRC *can* know all the legitimate manufacturers. The keys can come from sales channel integration (via digital "packing slips" perhaps), can be manually loaded by humans, be scanned from QR codes on the box, etc. We believe that this is out of scope. > > > > > > > > > > > > And if the JRC does see a MI that it does not know, then it can ask a human. > > > > > > That's one reason we made sure that failures to enroll do not cause the Pledge to never try again with that JRC. It needs to try again later, because maybe nobody has answered the "Yes/No" Dialog on the management station yet. > > > > > > > > > > > > And of course there is the WebPKI. We aren't saying that MI keys (or MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that they can't be. That's not a panacea... between ComodoGate type situations and certificates for "C1SC0" in a hard to distinguish font, many social engineering attacks could get that "Yes" button pressed. > > > > > > > > > > > > > > > > > > problem 2. > > > > > > Anoop> If pledge send a self-defined URL of manufacturer where > > > provision for > > > > > > Anoop> issuing fake vouchers is in place, then the registrar can > > > be fooled into > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > manufacturers > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > > > > > > > > > > The URL of the manufacturer is embedded in the IDevID certificate > > > (section > > > > > > 2.3 defines the extension). So the Pledge can't create this lie itself, it requires collaboration with the MI to create an IDevID. Such an MI can point to any MASA it wishes, so long as that device can issue vouchers that the Pledge can validate. > > > > > > > > > > > > What this means is that JRC always knows the MI that created the Pledge. > > > > > > If we can solve problem 1, then it's done. > > > > > > > > > > > > problem 3. > > > > > > Anoop> Additionally pledge > > > > > > Anoop> and a random manufacturer can also collaborate to do the same. > > > > > > > > > > > > I don't see how this is the case. The pledge can only collaborate with the manufacturer whose IDevID it has. > > > > > > > > > > > > problem 4. > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > manufacturer to lure > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > The Pledge will only trust a voucher signed by MASA. > > > > > > Any signature from a different entity will be rejected by the Pledge. > > > > > > So a fake voucher is not possible. > > > > > > Any voucher created by the real MASA is, by definition, not a fake voucher. > > > > > > Can you explain this scenario clearer? > > > > > > Or explain what text we need to change to clear up the mis-understanding? > > > > > > > > > > > > -- > > > > > > ] Never tell me the odds! | ipv6 mesh networks [ > > > > > > ] Michael Richardson, Sandelman Software Works | network architect [ > > > > > > ] < < mailto:mcr@sandelman.ca> mailto:mcr@sandelman.ca> < mailto:mcr@sandelman.ca> mcr@sandelman.ca < < http://www.sandelman.ca/> http://www.sandelman.ca/> < http://www.sandelman.ca/> http://www.sandelman.ca/ | ruby on rails [ > > > > > > > > > > > > > > > > > > -- > > > > > > Michael Richardson < < < mailto:mcr+IETF@sandelman.ca> > > mailto:mcr+IETF@sandelman.ca> > > > < mailto:mcr+IETF@sandelman.ca> mcr+IETF@sandelman.ca>, Sandelman > > Software Works -= IPv6 IoT > > > consulting =- > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > -- > > > --------------------------------------------------------- > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > Facebook: < https://www.facebook.com/CDACINDIA> > > https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > > > > > This e-mail is for the sole use of the intended recipient(s) and may > > > contain confidential and privileged information. If you are not the > > > intended recipient, please contact the sender by reply e-mail and > > > destroy all copies and the original message. Any unauthorized > > review, > > > use, disclosure, dissemination, forwarding, printing or copying of > > > this email is strictly prohibited and appropriate legal action will be taken. > > > -------------------------------------------------------------------- > > -- > > > --------------------------------------------------------- > > > > > > > > > > > > > > > _______________________________________________ > > > Anima mailing list > > > < mailto:Anima@ietf.org> Anima@ietf.org > > > < https://www.ietf.org/mailman/listinfo/anima> > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > ---------------------------------------------------------------------- > --------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and > destroy all copies and the original message. Any unauthorized review, > use, disclosure, dissemination, forwarding, printing or copying of > this email is strictly prohibited and appropriate legal action will be taken. > ---------------------------------------------------------------------- > --------------------------------------------------------- > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- ------=_NextPart_000_00B8_01D3AA5F.B6D4A2C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>"I do not know what a 'trusted world' is, we have not been using = that term in ANIMA.

&g= t;Do you mind to elaborate what you think is redundant in the "cryptog= raphically maintained long procedure" ?"

 

Trusted world= is something like “every entity in the domain is a trusted entity.&#= 8221; Also in this case, trust can be derived. For example, if a pledge is = issued by a trusted/enlisted MI, then that pledge can also be trusted. Here= the trust is derived from the MI.

 

Michael had mentioned in earlier mail= , “JRC  trusts pledge by validating IDevID using MI certificate.= ”  and you mentioned “MASA and Voucher are not used to ver= ify the pledge.””

If so, = then I thought that ‘JRC verifying audit log and voucher’ step is redundant. [Page 16 of RFC] It may not be required unless further= investigation into history of pledge is required.

 

 

= For the statement :- Pledge verifying the domain is anyway overrated= <= /p>

>“. If you are a buyer of large n= umber of pledges and do not need any protection against theft,  misass= ignment of pledges to other networks or intrusions into pledges that intend= to impact your network later, then >sure - you may be happy with pledge= s not requiring vouchers to get enrolled.”

 

Theft is a= nyway physical security breach. It may happen irrespective of BRSKI in plac= e.

Misassignment of pledge to other n= etwork can be easily detected if pledge is not accessible in the actual net= work.

Intrusion in pledge can’t= be stopped using BRSKI. That depends on methods of authentication and auth= orization employed to access the pledge.

 

Pledge is a device. If I b= uy/add a device, I need to verify if it is compromised or not or if it come= s from a trusted MI. Device need not verify me if it wants to work in my en= vironment or not.

 

If = pledge doesn’t require to validate JRC  then “MASA i= ssuing voucher and pledge using that voucher to validate and enroll to JRC&= #8221; is redundant.

<= span lang=3DEN-US style=3D'mso-fareast-language:EN-IN'> 

 

 

<= p class=3DMsoPlainText> 

That’s all from my side. I thoug= ht that this system could work in any environment and I was trying to convi= nce myself of the same and ascertain that no loopholes are left so far as m= y understanding is concerned.

=  

Regards,

Anoop

 

 

 

-----Original Message-----
From: Toerles= s Eckert [mailto:tte@cs.fau.de]
Sent: 20 February 2018 11:52
To: Ano= op Kumar Pandey <anoop@cdac.in>
Cc: 'Brian E Carpenter' <brian.= e.carpenter@gmail.com>; 'Michael Richardson' <mcr+ietf@sandelman.ca&g= t;; anima@ietf.org
Subject: Re: [Anima] verification of manufacturer in = BRSKI

 

Anoop,

 

> So, basically you reduced your scope to a pr= ofessionally managed network.

&n= bsp;

The term 'professionally managed' is = in the ANIMA charter, see

 =

https://datatracker.ietf.org/doc/charter-ietf-anima/

 

= It was just meant to provide a clear delineation of anima vs. Homenet or si= milar networks, which are meant to operate primarily unmanaged. =

 

I = think it is a vey broad scope.

&= nbsp;

> Just for the sake of clarity, i= f it is just like a trusted world of professionally managed network where p= ledges being added are from trusted manufacturers, probably we don???t requ= ire this cryptographically maintained long procedure of bootstrapping, sinc= e trust is derived from the manufacturer. A trusted manufacturer gives a tr= usted device, that???s all.

&nbs= p;

I do not know what a 'trusted world' is= , we have not been using that term in ANIMA.

 

Do you mind to elabora= te what you think is redundant in the "cryptographically maintained lo= ng procedure" ?

 

> Suppose we still want to go with this pr= ocedure and having our trust in certificates and keys, we don???t require M= ASA and vouchers. By simply verifying if the IDevID certificate has been si= gned by a trusted MI or a trusted CA or root-RA should be sufficient for ve= rifying the pledge.

 =

MASA and Voucher are not used to verify the ple= dge. If you think you read that in BRSKI, please point to the text section = that confused you about this.

&n= bsp;

> Pledge verifying the domain is a= nyway overrated.

 

That is in the eye of the beholder. If you are a b= uyer of large number of pledges and do not need any protection against thef= t,  misassignment of pledges to other networks or intrusions into pled= ges that intend to impact your network later, then sure - you may be happy = with pledges not requiring vouchers to get enrolled.

 

BRSKI already = mentions in the appendix a range of variations mostly with lower security. = It does not cover all possible lower security variants such as no-MASA/vouc= her primarily because we wanted the final BRSKI RFC number to actually mean= something wrt to security to buyers of products claiming to support it. If= everythng was optional, nothing is really standardized. It would just be l= ike calling a lottery a standard for Millionaires.

 

> Besides, = it can also be done by verifying the certificate of JRC during enrolment.

 

That actually is what the voucher does. Feel free to propose alterna= tives. I have a hard time imagining solutions that either do not achieve th= e goal, add pre-staging steps or just reinvent what the voucher does under = a different name.

 

Cheers

&nbs= p;   Toerless

 

On Tue, Feb 20, 2018 at 10:29:47AM +0530, A= noop Kumar Pandey wrote:

> ???ANIM= A is scoped to support professionally managed networks. So it seems reasona= ble to assume that they have procurement procedures in place to buy from kn= own sources and not to buy kit "off the back of a lorry" to use a= British idiom.???

>

> 

>

> "Again - a professio= nally managed network! Our goal in ANIMA is not to eliminate human operator= s; it is to avoid them having to perform mindless configuration tasks or wr= ite obscure scripts. So requiring human action to resolve a security alert = is completely acceptable IMHO. In this case the device might have been inst= alled by a service technician thousands of kilometres away from the NOC, an= d if that technician did install a device from an unknown source, this is e= xactly a case where the NOC should be alerted."

>

> 

>

>

> 

<= p class=3DMsoPlainText>>

> But= it is very limited scope. I would work on expanding the scope to any netwo= rk, any manufacturer-device pair.

&g= t;

> 

>

> I would a= lso like to quote/remind following lines from Section 1.3 [Scope of Solutio= n] of the RFC:

>

<= p class=3DMsoPlainText>> 

&g= t;

> ???But this solution is not = exclusive to the large, it is intended to scale to thousands of devices loc= ated in hostile environments, such as ISP provided CPE devices which are dr= op-shipped to the end user.  The situation where an order is fulfilled= from distributed warehouse from a common stock and shipped directly to the= target location at the request of the domain owner is explicitly supported= .  That stock ("SKU") could be provided to a number of poten= tial domain owners, and the eventual domain owner will not know a-priori wh= ich device will go to which location.???

>

> 

<= p class=3DMsoPlainText>>

> Reg= ards,

>

> Anoop

>

> 

>

> 

>

>&n= bsp;

>

> 

>

> -----Original Message-----<= /p>

> From: Brian Carpenter [mailto:becarpenter46@gmail.com] On Behalf Of

> Brian E Carpenter

> Sent: 20 February 2018 01:00

> To: Anoop Kumar Pandey <anoop@cdac.in&g= t;; 'Michael Richardson'

> <mcr+ietf@sandelman.ca>; anima@= ietf.org

> Subject: Re:= [Anima] verification of manufacturer in BRSKI

>

> 

>

&g= t; On 19/02/2018 21:52, Anoop Kumar Pandey wrote:

>

> > Dear Aut= hor,

>

> >

>

> >      =       I am further expanding my query and raising = concern over your response. The Problem Nos. are same as in the trailing re= ply.:

>

> >

>

> > 

>

> >

>

&g= t; > Problem 1:

> <= /p>

> > Response: " We assume that in a m= anaged network that the JRC *can* know all the legitimate manufacturers.&qu= ot;

>

> >

>

> >

>

> >

>

> > = May be!! But practically may not be possible. Manufacturers keep adding and= also getting out of business. Tracking each MI is difficult.

>

>&n= bsp;

>

> ANIMA is scoped to support professionally managed network= s. So it seems reasonable to assume that they have procurement procedures i= n place to buy from known sources and not to buy kit "off the back of = a lorry" to use a British idiom.

>

> 

>

> In oth= er words, tracking each manufacturer is *necessary* as it is in fact the or= igin of the trust for the BRSKI trust model. "Difficult" is not a= n excuse IMHO.

>

> 

>= ;

> >

>

> > Respo= nse: " The keys can come from sales channel integration (via digital &= quot;packing slips" perhaps), can be manually loaded by humans, be sca= nned from QR codes on the box, etc.  We believe that this is out of sc= ope.

>

> >

>

> > And if the JRC does see a MI that i= t does not know, then it can ask a human."

>

> >

>

&g= t; > 

>

> >

>=

> > If manual intervention is= required, then it is no longer ???Automated BRSKI???. Humans can anyway ob= server and add/install new device.

&g= t;

> 

>

> Again - a= professionally managed network! Our goal in ANIMA is not to eliminate huma= n operators; it is to avoid them having to perform mindless configuration t= asks or write obscure scripts. So requiring human action to resolve a secur= ity alert is completely acceptable IMHO. In this case the device might have= been installed by a service technician thousands of kilometres away from t= he NOC, and if that technician did install a device from an unknown source,= this is exactly a case where the NOC should be alerted.

>

>  =

>

>     Brian

>

> 

>

> &= gt; Problem 2:

>

<= p class=3DMsoPlainText>> >

>= ;

> > Response: The URL of the= manufacturer is embedded in the IDevID certificate (section 2.3 defines th= e extension).  So the Pledge can't create this lie itself, it requires= collaboration with the MI to create an IDevID.

>

> >

>

&g= t; >

>

> >

> =

> > I had asked the same thing. If = pledge collaborates with a rouge MI [given Problem 1 is not solved], the do= main can easily be invaded.

>

> >

>

> >  <= /o:p>

>

> >

>

> > Problem 3:

>

> > Response: The pl= edge can only collaborate with the manufacturer whose IDevID it has.

>

> >

>

> >

>

> > Agreed. Then this problem re= duces to Problem 2 where Pledge and MI

> > can

>

=

> > collaborate to fool JRC

>

> > =

>

> > 

>

> >

>

> > Problem 4:

>

> >

>

> > Response: The Pledge will only trust a vouc= her signed by MASA. Any signature from a different entity will be rejected = by the Pledge. So a fake voucher is not possible.

>

> >

>

= > > 

>

=

> >

&g= t;

> > I only raised concern t= hat there is no way to detect if MASA and JRC have collaborated to lure the= pledge into a malicious domain unless the MASA certificate and IDevID cert= ificate have common Root Certifying authority.

>

> > =

>

>= ; > 

>

> >

> =

> > Regards,

>

> > =

>

> > Anoop

>

> >

>

> > 

>

&g= t; >

>

> > 

>=

> >

>

> > -----= Original Message-----

>

> > From: Michael Richardson [ <mailto:mcr+ietf@sandelman.ca>

<= p class=3DMsoPlainText>> > <= span style=3D'color:windowtext;text-decoration:none'>mailto:mcr+ietf@sandel= man.ca]

>

> > Sent: 19 February 2018 05:57=

>

>= ; > To:  <mailto:anima@ietf.org> anima@ietf.org

&g= t;

> > Cc: Anoop Kumar Pandey = < <mailto:anoop@cdac.in> anoop@= cdac.in>

>

> > Subject: verification of manufactur= er in BRSKI

>

> >

>

> > 

>

> >

>

> > 

> =

> >

>

> > {sorry if this is a= duplicate, my draft folder says it did not go

> > out}

> <= /o:p>

> >

>

> > 

>

= > >

>

> > Anoop Kumar Pandey < < <ma= ilto:anoop@cdac.in> mailto:anoop@cdac.in>  <mailto:anoop@cdac.in> anoop@cdac.in> wrote directly to the draft authors list, an= d then gave me permission to share this on the list:

>

> > =

>

> >     Anoop> This is in context to the RF= C detailing process of

>

> > enrolling a pledge to a<= /p>

>

>= >

>

> >     Anoop> domain. The maj= or problem with the procedure is that the

>

> > registrar doesn?= ??t

>

> >

>

> >     Anoop> ve= rify the manufacturer. It simply verifies the voucher

> > and

> =

> > enrols the

<= p class=3DMsoPlainText>>

> >= ;

>

> >     Anoop> pledge. If pledge sen= d a self-defined URL of manufacturer

= >

> > where provision for

>

> >

>

=

> >     Anoop> issuing= fake vouchers is in place, then the registrar can

>

> > be fo= oled into

>

> >

>

> >     Anoop&= gt; enrolment [assuming the registrar can???t know all the

>

> >= manufacturers

>

> >

>=

> >     A= noop> exhaustively] and later exploited from inside the domain.

>

= > > Additionally pledge

>

> >

>

> >  = ;   Anoop> and a random manufacturer can also collaborate to d= o the same.

>

> >

>

> > 

>

> >

>

> > You raise a number of issues.

>

> >

>

> &= gt; 

>

> >

>

> > So let me name them so that w= e can discuss them easier, and make sure that I understand you correctly.

>

> >

>

=

> > Probably, we need to add some text to the= Security Considerations, and I would welcome your help in crafting that te= xt!

>

> >

>

> > 

>

> > <= /p>

>

>= >     Anoop> In the similar way a registrar may = collaborate with the

> =

> > manufacturer to lure

>

> >=

>

> >     Anoop> a device using fake vo= ucher.

>

> >

> =

> > 

>

> > =

>

> >     Anoop> How can these problems be ta= ckled?

>

> >

> =

> > 

>

> > =

>

> > I agree that the Pledge may point at any Manufacturer (in the = form

> > of

>

> > a= MASA)

>

> >

> =

> > that it wishes to.   = The following identities exist:

> =

> >

>

> > 

>

> >

>

=

> > 1) The Pledge's Identity (PI) in the form= an IDevID certificate.

>

> >

>

> >   = ; (It signs the voucher request to the JRC, and the Client side of

>

&= gt; > the TLS

>

=

> >

&g= t;

> >    conne= ction from Pledge to JRC)

> <= /o:p>

> >

>

> > 2) The Manufac= turer's Identity (MI) which signs the IDevID certificate.

>

> > =

>

> > 3) The MASA Identity (MASA) which signs the voucher.=

>

> >

>

> > 4) The Join Registrar (JRC) which signs the = voucher request to the MASA.

>

> >

>

> >  =   It also signs the Server side of the TLS connection from Pledge to J= RC.

>

> >

>

> > 5) The Domain PKI Certificate Author= ity, which signs the LDevID.

>

> >

>

> >  =

>

> >

>

> > (The MI might be the same as the MASA, but i= n general the MASA may

> > be<= o:p>

>

> > outsourced.  The Pledge SHOULD have a trusted anchor = for both, but

> > it

>

&g= t; > can be designed where it has a manufacturer CA which signs both MAS= A

>

> > and MI certificate)

>

> >

>

> >&n= bsp;

>

> >

>

> > Each of these in essence represent= a private key!

>

<= p class=3DMsoPlainText>> >

>= ;

> > I'd like start by ruling= out of bounds for this discussion any scenario where the attack requires t= hat the private key be leaked, shared or used incorrectly.  It's not t= hat they can't happen, but rather that it is a problem of TPMs, etc. and no= t protocol design.

>

> >

= >

> > 

=

>

> &g= t;

>

> > The Pledge trusts network part works by:

>

> &= gt;

>

> > a) MASA signs VOUCHER.

>

> >

>

> = > b) VOUCHER lists JRC in pinned-domain-cert.

>

> >

>

&= gt; > c) Pledge uses MASA to validate VOUCHER, and therefore validates J= RC.

>

> >

>

> > d) JRC can also audit (verify signat= ures even) the voucher really

>

> > comes

>

> > =

>

> >    from MASA, although unless there is a common= CA, it may not be

> > able

>

> > to

>

> >

&= gt;

> >    prov= e MASA and MI are same entity.

> <= o:p>

> >

>

> > 

>

> >

>

<= p class=3DMsoPlainText>> > The JRC trusts Pledge part works by:<= /o:p>

>

> >

>

> > e) MI signs IDevID.

>

> >

>

= > > f) Pledge uses IDevID to identify to JRC.

>

> > =

>

> > g) JRC validates IDevID using MI certificate.

>

> >=

>

> > 

> <= /o:p>

> >

>

> > Now, to transl= ate what you said:

>

> >

= >

> > 

=

>

> &g= t;

>

> > problem 1.

> =

> >

>

> > &nb= sp;   Anoop> The major problem with the procedure is that the =

> > registrar

>

> >= doesn???t

>

> >

>

> >     Anoop= > verify the manufacturer.

>

> >

>

> > 

>

> >

>

> > To translate, the JRC has no obvious way to= verify that the "MI" key

&= gt;

> > belongs

=

>

> &g= t;

>

> >         &= nbsp;     to the manufacturer that they care about.

>

> >

>

> > 

>

> >

>

> > Y= ou actually hit the major reason this is not a problem when you assume:

>

> >

>

> >    > assuming the registr= ar can???t know all the manufacturers

>

> > exhaustively

>

= > >

>

> > 

&g= t;

> >

>

> > We as= sume that in a managed network that the JRC *can* know all the legitimate m= anufacturers.  The keys can come from sales channel integration (via d= igital "packing slips" perhaps), can be manually loaded by humans= , be scanned from QR codes on the box, etc.  We believe that this is o= ut of scope.

>

> >

> <= o:p>

> > 

>

> >

>

> > And if the JRC does see a MI that it does not know, then it = can ask a human.

>

=

> >

&g= t;

> > That's one reason we ma= de sure that failures to enroll do not cause the Pledge to never try again = with that JRC.  It needs to try again later, because maybe nobody has = answered the "Yes/No" Dialog on the management station yet.<= /o:p>

>

> >

>

> > 

= >

> >

>

> > And= of course there is the WebPKI.  We aren't saying that MI keys (or MAS= A server TLS keys) MUST be in the WebPKI, but we aren't saying that they ca= n't be.  That's not a panacea... between ComodoGate type situations an= d certificates for "C1SC0" in a hard to distinguish font, many so= cial engineering attacks could get that "Yes" button pressed.

>

> >

>

> > 

>

> >

>

> >&n= bsp;

>

> >

>

> > problem 2.

>

> > =

>

> >     Anoop> If pledge send a self-define= d URL of manufacturer where

>

> > provision for

>

> >=

>

> >     Anoop> issuing fake vouchers = is in place, then the registrar can

&= gt;

> > be fooled into

>

= > >

>

> >     Anoop> enrolment [as= suming the registrar can???t know all the

>

> > manufacturers

>

> >

>

<= p class=3DMsoPlainText>> >     Anoop> exhausti= vely] and later exploited from inside the domain.

>

> >

>

= > > 

>

=

> >

&g= t;

> > The URL of the manufact= urer is embedded in the IDevID certificate

>

> > (section

>

> >

>

> > 2.3 defines the extension).  So the Pledg= e can't create this lie itself, it requires collaboration with the MI to cr= eate an IDevID.  Such an MI can point to any MASA it wishes, so long a= s that device can issue vouchers that the Pledge can validate.

>

> = >

>

> > 

>

> >

>

> > What this = means is that JRC always knows the MI that created the Pledge.

>

> = >

>

> > If we can solve problem 1, then it's done.

>

&g= t; >

>

> > 

>=

> >

>

> > probl= em 3.

>

> >

>

> >     Anoop> = Additionally pledge

> <= /p>

> >

>

> >   &nb= sp; Anoop> and a random manufacturer can also collaborate to do the same= .

>

> >

> <= /p>

> > 

>

> >

>

> &= gt; I don't see how this is the case.  The pledge can only collaborate= with the manufacturer whose IDevID it has.

>

> >

>

> &= gt; 

>

> >

>

> > problem 4.

>

> > <= o:p>

>

> >     Anoop> In the similar way a reg= istrar may collaborate with the

> =

> > manufacturer to lure<= /o:p>

>

> >

>

> >     Anoop> a device us= ing fake voucher.

>

> >

&= gt;

> > 

<= p class=3DMsoPlainText>>

> >= ;

>

> > The Pledge will only trust a voucher signed by MASA.

>

> >

>

<= p class=3DMsoPlainText>> > Any signature from a different entity will= be rejected by the Pledge.

>

> >

>

> > So a fake vo= ucher is not possible.

>

> >

>

> > Any voucher creat= ed by the real MASA is, by definition, not a fake voucher.

>

> >=

>

> > Can you explain this scenario clearer?

>

> > =

>

> > Or explain what text we need to change to clear up the mi= s-understanding?

>

=

> >

&g= t;

> > 

>

> >=

>

> > --

>

> >

>

> > ]   = ;            Never t= ell me the odds!          = ;       | ipv6 mesh networks [

=

>

> &g= t;

>

> > ]   Michael Richardson, Sandelman Software W= orks        | network architect  [<= o:p>

>

> >

>

> > ]      < <= ;mailto:mcr@sandelman.ca> mailt= o:mcr@sandelman.ca>  <mailto:mcr@sande= lman.ca> mcr@sandelman.ca &nbs= p; < <http://www.sandelman.ca/> http://www.sandelman.ca/>  <= http://www.sandelman.ca/> http://www.sandelma= n.ca/        |   ru= by on rails    [

> =

> >

>

> > 

>

> >

>

=

> > 

>

> >

>

> >= --

>

> >

>

> > Michael Richardson < < <mailto:mcr+IETF@sandelman.ca>

> > mailto:mcr+IETF@sand= elman.ca>

>

> >  <mail= to:mcr+IETF@sandelman.ca> mcr+IETF@sandel= man.ca>, Sandelman

>= ; > Software Works  -=3D IPv6 IoT

>

> > consulting =3D-<= o:p>

>

> >

>

> > 

>

> >

<= p class=3DMsoPlainText>>

> >= ; 

>

> >

> =

> > 

>

> > =

>

> >

>

> > --------------------------------------------= ------------------------

> > --=

>

> > ---------------------------------------------------------=

>

> > [ C-DAC is on Social-Media too. Kindly follow us at:=

>

> > Facebook:  <https://www.face= book.com/CDACINDIA>

&g= t; > https://www.facebook.com/CDACINDIA= & Twitter: @cdacindia ]

>=

> >

>

> > This = e-mail is for the sole use of the intended recipient(s) and may<= /p>

>

>= > contain confidential and privileged information. If you are not the

>

> > intended recipient, please contact the sender by reply e-ma= il and

>

> > destroy all copies and the original message. Any = unauthorized

> > review,<= /o:p>

>

> > use, disclosure, dissemination, forwarding, printing or copying= of

>

> > this email is strictly prohibited and appropriate lega= l action will be taken.

>

> > ----------------------------------= ----------------------------------

&g= t; > --

>

> > -----------------------------------------------= ----------

>

> >

>

> >

>

> > =

>

>= ; >

>

> > _______________________________________________

>

> > Anima mailing list

&g= t;

> >  <= mailto:Anima@ietf.org> Anima@ietf.org=

>

> >  <https://www.= ietf.org/mailman/listinfo/anima>

> > https://www.ietf.or= g/mailman/listinfo/anima

&= gt;

> >

>

> 

>

>  

>

=

>

> --= --------------------------------------------------------------------

> --------------------------------------= -------------------

> [ C-DAC is o= n Social-Media too. Kindly follow us at:

> Facebook: https://www.facebook.com/CDACI= NDIA & Twitter: @cdacindia ]

>

> This e-mail is for = the sole use of the intended recipient(s) and may

> contain confidential and privileged information. If yo= u are not the

> intended recipien= t, please contact the sender by reply e-mail and

> destroy all copies and the original message. Any unauthor= ized review,

> use, disclosure, d= issemination, forwarding, printing or copying of

> this email is strictly prohibited and appropriate legal a= ction will be taken.

> -----------= -----------------------------------------------------------

<= p class=3DMsoPlainText>> -----------------------------------------------= ----------

>

 

> _______= ________________________________________

> Anima mailing list

> Anima@ietf.org

&g= t; https://www.ietf.org/mailman/listinfo= /anima

 

 

--

---

tte@cs.fau.de


--------= ---------------------------------------------------------------------------= --------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= ---------------------------------------------------------- ------=_NextPart_000_00B8_01D3AA5F.B6D4A2C0-- From nobody Tue Feb 20 07:48:52 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BE3127867 for ; Tue, 20 Feb 2018 07:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WQw9xH7zRCOU for ; Tue, 20 Feb 2018 07:48:46 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B7B12762F for ; Tue, 20 Feb 2018 07:48:46 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9655058C514; Tue, 20 Feb 2018 16:48:40 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 765C2B0DAF8; Tue, 20 Feb 2018 16:48:40 +0100 (CET) Date: Tue, 20 Feb 2018 16:48:40 +0100 From: 'Toerless Eckert' To: Anoop Kumar Pandey Cc: 'Brian E Carpenter' , 'Michael Richardson' , anima@ietf.org Message-ID: <20180220154840.GB23498@faui40p.informatik.uni-erlangen.de> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> <20180220062131.GA23498@faui40p.informatik.uni-erlangen.de> <00b701d3aa31$9d13db40$d73b91c0$@cdac.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b701d3aa31$9d13db40$d73b91c0$@cdac.in> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 15:48:51 -0000 On Tue, Feb 20, 2018 at 03:30:14PM +0530, Anoop Kumar Pandey wrote: > Trusted world is something like "every entity in the domain is a trusted > entity." Also in this case, trust can be derived. For example, if a pledge > is issued by a trusted/enlisted MI, then that pledge can also be trusted. > Here the trust is derived from the MI. "Trusted world" is misleading because the assumption in ANIMA is that the world is actually not-trusted and instead has a lot of bad things happening and the cryptographic procedures of BRSKI/ACP serve to create a "trusted domain/network" in the face of the largely "untrusted world". If you live in a gated community you would also not claim the world is trusted. Very similar. > Michael had mentioned in earlier mail, "JRC trusts pledge by validating > IDevID using MI certificate." and you mentioned "MASA and Voucher are not > used to verify the pledge."" > > If so, then I thought that 'JRC verifying audit log and voucher' step is > redundant. [Page 16 of RFC] It may not be required unless further > investigation into history of pledge is required. As said. MASA and Voucher are not used in BRSKI to make the Domain trust the Pledge, but that does not make them redundant. > >". If you are a buyer of large number of pledges and do not need any > > protection against theft, misassignment of pledges to other networks or > > intrusions into pledges that intend to impact your network later, then >sure > > - you may be happy with pledges not requiring vouchers to get enrolled." > Theft is anyway physical security breach. It may happen irrespective of > BRSKI in place. Theft is not only applied to physical security breach. Illegal use of utility into something (physical or not) also gets classified as theft in many countries. BRSKI protects also against remotely gaining access/utility to the Pledge. Physical theft too is less likely if you can not get utility: If a Pledge does not allow to circumvent secure bootstrap even with physical posession of the Pledge, then those Pledges are less likely subjects to physical theft. > Misassignment of pledge to other network can be easily detected if pledge is > not accessible in the actual network. Depending on use-case it may be expensive to detect, but in even more use cases it will be expensive to fix. > Intrusion in pledge can't be stopped using BRSKI. Yes it can. > That depends on methods of authentication and authorization employed to access the pledge. And those methods are meant to be gated by BRSKI/EST. Think of the most simple case: You will not get any configuration access to the device unless BRSKI was run, and afterwards you need to authenticate yourself on every config connection with the cert enrolled during BRSKI. > Pledge is a device. If I buy/add a device, I need to verify if it is > compromised or not or if it comes from a trusted MI. Well, we agree on one thing. > Device need not verify me if it wants to work in my environment or not. BRSKI devices only want to work for their owner. > If pledge doesn't require to validate JRC then "MASA issuing voucher and > pledge using that voucher to validate and enroll to JRC" is redundant. Probably true in the context of how BRSKI is currently written. Except that for the current charter work on BRSKI we have concluded that the pledge does need to verify the domain for all the reasons documented in BRSKI and repeated by me. And you disagree. Note though, that there can also be other benefits to MASA than "pledge only wants to work for owner", and that is "pledge wants to discover owner". Consider the typical use case of some pledge connecting to a public network, such as Internet, so the network connection has no way to point the pledge to the owner. To support this, you also need a three party system: Pledge, Manufacturer Service, Owner: Pledge can only contact some Manufacturer service, and that would "redirect" Pledge to owner after Owner hass claimed pledge from manufacturer. The BRSKI section about cloud registrar/service hints at this use-case, but i am not sure to what extend we could/should cover this in detail in BRSKI (see my review) because it does require some extension to the signaling IMHO. I would be happy too if this wasn't buried in some section of the BRSKI spec but in separate followup work that focusses on this case. > That's all from my side. I thought that this system could work in any > environment and I was trying to convince myself of the same and ascertain > that no loopholes are left so far as my understanding is concerned. Glad to hear. I thought you where wanting to keepg the biggest loophole in place (pledge will work for anybody). Cheers Toerless > Regards, > > Anoop > > > > > > > > -----Original Message----- > From: Toerless Eckert [mailto:tte@cs.fau.de] > Sent: 20 February 2018 11:52 > To: Anoop Kumar Pandey > Cc: 'Brian E Carpenter' ; 'Michael Richardson' > ; anima@ietf.org > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > Anoop, > > > > > So, basically you reduced your scope to a professionally managed network. > > > > The term 'professionally managed' is in the ANIMA charter, see > > > > > https://datatracker.ietf.org/doc/charter-ietf-anima/ > > > > It was just meant to provide a clear delineation of anima vs. Homenet or > similar networks, which are meant to operate primarily unmanaged. > > > > I think it is a vey broad scope. > > > > > Just for the sake of clarity, if it is just like a trusted world of > professionally managed network where pledges being added are from trusted > manufacturers, probably we don???t require this cryptographically maintained > long procedure of bootstrapping, since trust is derived from the > manufacturer. A trusted manufacturer gives a trusted device, that???s all. > > > > I do not know what a 'trusted world' is, we have not been using that term in > ANIMA. > > > > Do you mind to elaborate what you think is redundant in the > "cryptographically maintained long procedure" ? > > > > > Suppose we still want to go with this procedure and having our trust in > certificates and keys, we don???t require MASA and vouchers. By simply > verifying if the IDevID certificate has been signed by a trusted MI or a > trusted CA or root-RA should be sufficient for verifying the pledge. > > > > MASA and Voucher are not used to verify the pledge. If you think you read > that in BRSKI, please point to the text section that confused you about > this. > > > > > Pledge verifying the domain is anyway overrated. > > > > That is in the eye of the beholder. If you are a buyer of large number of > pledges and do not need any protection against theft, misassignment of > pledges to other networks or intrusions into pledges that intend to impact > your network later, then sure - you may be happy with pledges not requiring > vouchers to get enrolled. > > > > BRSKI already mentions in the appendix a range of variations mostly with > lower security. It does not cover all possible lower security variants such > as no-MASA/voucher primarily because we wanted the final BRSKI RFC number to > actually mean something wrt to security to buyers of products claiming to > support it. If everythng was optional, nothing is really standardized. It > would just be like calling a lottery a standard for Millionaires. > > > > > Besides, it can also be done by verifying the certificate of JRC during > enrolment. > > > > That actually is what the voucher does. Feel free to propose alternatives. I > have a hard time imagining solutions that either do not achieve the goal, > add pre-staging steps or just reinvent what the voucher does under a > different name. > > > > Cheers > > Toerless > > > > On Tue, Feb 20, 2018 at 10:29:47AM +0530, Anoop Kumar Pandey wrote: > > > ???ANIMA is scoped to support professionally managed networks. So it seems > reasonable to assume that they have procurement procedures in place to buy > from known sources and not to buy kit "off the back of a lorry" to use a > British idiom.??? > > > > > > > > > > > > "Again - a professionally managed network! Our goal in ANIMA is not to > eliminate human operators; it is to avoid them having to perform mindless > configuration tasks or write obscure scripts. So requiring human action to > resolve a security alert is completely acceptable IMHO. In this case the > device might have been installed by a service technician thousands of > kilometres away from the NOC, and if that technician did install a device > from an unknown source, this is exactly a case where the NOC should be > alerted." > > > > > > > > > > > > > > > > > > > > > But it is very limited scope. I would work on expanding the scope to any > network, any manufacturer-device pair. > > > > > > > > > > > > I would also like to quote/remind following lines from Section 1.3 [Scope > of Solution] of the RFC: > > > > > > > > > > > > ???But this solution is not exclusive to the large, it is intended to > scale to thousands of devices located in hostile environments, such as ISP > provided CPE devices which are drop-shipped to the end user. The situation > where an order is fulfilled from distributed warehouse from a common stock > and shipped directly to the target location at the request of the domain > owner is explicitly supported. That stock ("SKU") could be provided to a > number of potential domain owners, and the eventual domain owner will not > know a-priori which device will go to which location.??? > > > > > > > > > > > > Regards, > > > > > > Anoop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Brian Carpenter [ > mailto:becarpenter46@gmail.com] On Behalf Of > > > Brian E Carpenter > > > Sent: 20 February 2018 01:00 > > > To: Anoop Kumar Pandey < anoop@cdac.in>; 'Michael > Richardson' > > > < mcr+ietf@sandelman.ca>; > anima@ietf.org > > > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > > > > > > > > > On 19/02/2018 21:52, Anoop Kumar Pandey wrote: > > > > > > > Dear Author, > > > > > > > > > > > > > > I am further expanding my query and raising concern over your > response. The Problem Nos. are same as in the trailing reply.: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 1: > > > > > > > Response: " We assume that in a managed network that the JRC *can* know > all the legitimate manufacturers." > > > > > > > > > > > > > > > > > > > > > > > > > > > > May be!! But practically may not be possible. Manufacturers keep adding > and also getting out of business. Tracking each MI is difficult. > > > > > > > > > > > > ANIMA is scoped to support professionally managed networks. So it seems > reasonable to assume that they have procurement procedures in place to buy > from known sources and not to buy kit "off the back of a lorry" to use a > British idiom. > > > > > > > > > > > > In other words, tracking each manufacturer is *necessary* as it is in fact > the origin of the trust for the BRSKI trust model. "Difficult" is not an > excuse IMHO. > > > > > > > > > > > > > > > > > > > > Response: " The keys can come from sales channel integration (via > digital "packing slips" perhaps), can be manually loaded by humans, be > scanned from QR codes on the box, etc. We believe that this is out of > scope. > > > > > > > > > > > > > > And if the JRC does see a MI that it does not know, then it can ask a > human." > > > > > > > > > > > > > > > > > > > > > > > > > > > > If manual intervention is required, then it is no longer ???Automated > BRSKI???. Humans can anyway observer and add/install new device. > > > > > > > > > > > > Again - a professionally managed network! Our goal in ANIMA is not to > eliminate human operators; it is to avoid them having to perform mindless > configuration tasks or write obscure scripts. So requiring human action to > resolve a security alert is completely acceptable IMHO. In this case the > device might have been installed by a service technician thousands of > kilometres away from the NOC, and if that technician did install a device > from an unknown source, this is exactly a case where the NOC should be > alerted. > > > > > > > > > > > > Brian > > > > > > > > > > > > > Problem 2: > > > > > > > > > > > > > > Response: The URL of the manufacturer is embedded in the IDevID > certificate (section 2.3 defines the extension). So the Pledge can't create > this lie itself, it requires collaboration with the MI to create an IDevID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I had asked the same thing. If pledge collaborates with a rouge MI > [given Problem 1 is not solved], the domain can easily be invaded. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 3: > > > > > > > Response: The pledge can only collaborate with the manufacturer whose > IDevID it has. > > > > > > > > > > > > > > > > > > > > > Agreed. Then this problem reduces to Problem 2 where Pledge and MI > > > > can > > > > > > > collaborate to fool JRC > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 4: > > > > > > > > > > > > > > Response: The Pledge will only trust a voucher signed by MASA. Any > signature from a different entity will be rejected by the Pledge. So a fake > voucher is not possible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I only raised concern that there is no way to detect if MASA and JRC > have collaborated to lure the pledge into a malicious domain unless the MASA > certificate and IDevID certificate have common Root Certifying authority. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Anoop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Richardson [ < > mailto:mcr+ietf@sandelman.ca> > > > > mailto:mcr+ietf@sandelman.ca] > > > > > > > Sent: 19 February 2018 05:57 > > > > > > > To: < mailto:anima@ietf.org> > anima@ietf.org > > > > > > > Cc: Anoop Kumar Pandey < < mailto:anoop@cdac.in> > anoop@cdac.in> > > > > > > > Subject: verification of manufacturer in BRSKI > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > {sorry if this is a duplicate, my draft folder says it did not go > > > > out} > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop Kumar Pandey < < < mailto:anoop@cdac.in> > mailto:anoop@cdac.in> < > mailto:anoop@cdac.in> anoop@cdac.in> wrote directly > to the draft authors list, and then gave me permission to share this on the > list: > > > > > > > > > > > > > > Anoop> This is in context to the RFC detailing process of > > > > > > > enrolling a pledge to a > > > > > > > > > > > > > > Anoop> domain. The major problem with the procedure is that the > > > > > > > registrar doesn???t > > > > > > > > > > > > > > Anoop> verify the manufacturer. It simply verifies the voucher > > > > and > > > > > > > enrols the > > > > > > > > > > > > > > Anoop> pledge. If pledge send a self-defined URL of manufacturer > > > > > > > where provision for > > > > > > > > > > > > > > Anoop> issuing fake vouchers is in place, then the registrar can > > > > > > > be fooled into > > > > > > > > > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > > > > > manufacturers > > > > > > > > > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > > > > > Additionally pledge > > > > > > > > > > > > > > Anoop> and a random manufacturer can also collaborate to do the > same. > > > > > > > > > > > > > > > > > > > > > > > > > > > > You raise a number of issues. > > > > > > > > > > > > > > > > > > > > > > > > > > > > So let me name them so that we can discuss them easier, and make sure > that I understand you correctly. > > > > > > > > > > > > > > Probably, we need to add some text to the Security Considerations, and I > would welcome your help in crafting that text! > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > > > > > manufacturer to lure > > > > > > > > > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> How can these problems be tackled? > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that the Pledge may point at any Manufacturer (in the form > > > > of > > > > > > > a MASA) > > > > > > > > > > > > > > that it wishes to. The following identities exist: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) The Pledge's Identity (PI) in the form an IDevID certificate. > > > > > > > > > > > > > > (It signs the voucher request to the JRC, and the Client side of > > > > > > > the TLS > > > > > > > > > > > > > > connection from Pledge to JRC) > > > > > > > > > > > > > > 2) The Manufacturer's Identity (MI) which signs the IDevID certificate. > > > > > > > > > > > > > > 3) The MASA Identity (MASA) which signs the voucher. > > > > > > > > > > > > > > 4) The Join Registrar (JRC) which signs the voucher request to the MASA. > > > > > > > > > > > > > > It also signs the Server side of the TLS connection from Pledge to > JRC. > > > > > > > > > > > > > > 5) The Domain PKI Certificate Authority, which signs the LDevID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > (The MI might be the same as the MASA, but in general the MASA may > > > > be > > > > > > > outsourced. The Pledge SHOULD have a trusted anchor for both, but > > > > it > > > > > > > can be designed where it has a manufacturer CA which signs both MASA > > > > > > > and MI certificate) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Each of these in essence represent a private key! > > > > > > > > > > > > > > I'd like start by ruling out of bounds for this discussion any scenario > where the attack requires that the private key be leaked, shared or used > incorrectly. It's not that they can't happen, but rather that it is a > problem of TPMs, etc. and not protocol design. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Pledge trusts network part works by: > > > > > > > > > > > > > > a) MASA signs VOUCHER. > > > > > > > > > > > > > > b) VOUCHER lists JRC in pinned-domain-cert. > > > > > > > > > > > > > > c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. > > > > > > > > > > > > > > d) JRC can also audit (verify signatures even) the voucher really > > > > > > > comes > > > > > > > > > > > > > > from MASA, although unless there is a common CA, it may not be > > > > able > > > > > > > to > > > > > > > > > > > > > > prove MASA and MI are same entity. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The JRC trusts Pledge part works by: > > > > > > > > > > > > > > e) MI signs IDevID. > > > > > > > > > > > > > > f) Pledge uses IDevID to identify to JRC. > > > > > > > > > > > > > > g) JRC validates IDevID using MI certificate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, to translate what you said: > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 1. > > > > > > > > > > > > > > Anoop> The major problem with the procedure is that the > > > > registrar > > > > > > > doesn???t > > > > > > > > > > > > > > Anoop> verify the manufacturer. > > > > > > > > > > > > > > > > > > > > > > > > > > > > To translate, the JRC has no obvious way to verify that the "MI" key > > > > > > > belongs > > > > > > > > > > > > > > to the manufacturer that they care about. > > > > > > > > > > > > > > > > > > > > > > > > > > > > You actually hit the major reason this is not a problem when you assume: > > > > > > > > > > > > > > > assuming the registrar can???t know all the manufacturers > > > > > > > exhaustively > > > > > > > > > > > > > > > > > > > > > > > > > > > > We assume that in a managed network that the JRC *can* know all the > legitimate manufacturers. The keys can come from sales channel integration > (via digital "packing slips" perhaps), can be manually loaded by humans, be > scanned from QR codes on the box, etc. We believe that this is out of > scope. > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the JRC does see a MI that it does not know, then it can ask a > human. > > > > > > > > > > > > > > That's one reason we made sure that failures to enroll do not cause the > Pledge to never try again with that JRC. It needs to try again later, > because maybe nobody has answered the "Yes/No" Dialog on the management > station yet. > > > > > > > > > > > > > > > > > > > > > > > > > > > > And of course there is the WebPKI. We aren't saying that MI keys (or > MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that they > can't be. That's not a panacea... between ComodoGate type situations and > certificates for "C1SC0" in a hard to distinguish font, many social > engineering attacks could get that "Yes" button pressed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 2. > > > > > > > > > > > > > > Anoop> If pledge send a self-defined URL of manufacturer where > > > > > > > provision for > > > > > > > > > > > > > > Anoop> issuing fake vouchers is in place, then the registrar can > > > > > > > be fooled into > > > > > > > > > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > > > > > manufacturers > > > > > > > > > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The URL of the manufacturer is embedded in the IDevID certificate > > > > > > > (section > > > > > > > > > > > > > > 2.3 defines the extension). So the Pledge can't create this lie itself, > it requires collaboration with the MI to create an IDevID. Such an MI can > point to any MASA it wishes, so long as that device can issue vouchers that > the Pledge can validate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > What this means is that JRC always knows the MI that created the Pledge. > > > > > > > > > > > > > > If we can solve problem 1, then it's done. > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 3. > > > > > > > > > > > > > > Anoop> Additionally pledge > > > > > > > > > > > > > > Anoop> and a random manufacturer can also collaborate to do the > same. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see how this is the case. The pledge can only collaborate with > the manufacturer whose IDevID it has. > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 4. > > > > > > > > > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > > > > > manufacturer to lure > > > > > > > > > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Pledge will only trust a voucher signed by MASA. > > > > > > > > > > > > > > Any signature from a different entity will be rejected by the Pledge. > > > > > > > > > > > > > > So a fake voucher is not possible. > > > > > > > > > > > > > > Any voucher created by the real MASA is, by definition, not a fake > voucher. > > > > > > > > > > > > > > Can you explain this scenario clearer? > > > > > > > > > > > > > > Or explain what text we need to change to clear up the > mis-understanding? > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > ] Never tell me the odds! | ipv6 mesh > networks [ > > > > > > > > > > > > > > ] Michael Richardson, Sandelman Software Works | network > architect [ > > > > > > > > > > > > > > ] < < mailto:mcr@sandelman.ca> > mailto:mcr@sandelman.ca> < > mailto:mcr@sandelman.ca> > mcr@sandelman.ca < < > http://www.sandelman.ca/> > http://www.sandelman.ca/> < > http://www.sandelman.ca/> > http://www.sandelman.ca/ | ruby on rails [ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Michael Richardson < < < > mailto:mcr+IETF@sandelman.ca> > > > > mailto:mcr+IETF@sandelman.ca> > > > > > > > < mailto:mcr+IETF@sandelman.ca> > mcr+IETF@sandelman.ca>, Sandelman > > > > Software Works -= IPv6 IoT > > > > > > > consulting =- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > --------------------------------------------------------- > > > > > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > > > > > Facebook: < > https://www.facebook.com/CDACINDIA> > > > > https://www.facebook.com/CDACINDIA > & Twitter: @cdacindia ] > > > > > > > > > > > > > > This e-mail is for the sole use of the intended recipient(s) and may > > > > > > > contain confidential and privileged information. If you are not the > > > > > > > intended recipient, please contact the sender by reply e-mail and > > > > > > > destroy all copies and the original message. Any unauthorized > > > > review, > > > > > > > use, disclosure, dissemination, forwarding, printing or copying of > > > > > > > this email is strictly prohibited and appropriate legal action will be > taken. > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > --------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Anima mailing list > > > > > > > < mailto:Anima@ietf.org> > Anima@ietf.org > > > > > > > < > https://www.ietf.org/mailman/listinfo/anima> > > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > Facebook: > https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > > > > > This e-mail is for the sole use of the intended recipient(s) and may > > > contain confidential and privileged information. If you are not the > > > intended recipient, please contact the sender by reply e-mail and > > > destroy all copies and the original message. Any unauthorized review, > > > use, disclosure, dissemination, forwarding, printing or copying of > > > this email is strictly prohibited and appropriate legal action will be > taken. > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > -- > > --- > > tte@cs.fau.de > > > ------------------------------------------------------------------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------------------------------------------------------------------------- > -- --- tte@cs.fau.de From nobody Tue Feb 20 12:27:02 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74237126CD8 for ; Tue, 20 Feb 2018 12:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 I6on9-o37-gs for ; Tue, 20 Feb 2018 12:26:58 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BD21243F6 for ; Tue, 20 Feb 2018 12:26:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E838520091 for ; Tue, 20 Feb 2018 15:34:16 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4DB7580C86 for ; Tue, 20 Feb 2018 15:26:57 -0500 (EST) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <89C98637-ACD2-423A-A8C4-52191C35FA53@cisco.com> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <11878.1518662730@obiwan.sandelman.ca> <89C98637-ACD2-423A-A8C4-52191C35FA53@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 20:27:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max Pritikin (pritikin) wrote: >>> b) Key infrastructure >>=20 >>> There is no definition/reference for this term. Please describe on >>> first use and in terminology. Is there a difference >>> between "key infrastructure" and "keying material" ? If not, then >>> maybe remove one term otherwise pls. describe difference. >>=20 >> The term is in the title and in section 1. >> And you are right that it does not appear again, nor is it defined. >> I think it generally refers to the mechanism of PKI, but I'm not sur= e what to do. > An =E2=80=9Cinfrastructure=E2=80=9D is the basic entities and protoco= ls necessary for > the operations of key management. I think it comes from the common > language term and can=E2=80=99t find a normative definition within IE= TF > document. As a native english speaker who has used the concept in IETF > interactions for eons it feels silly to try and define it. Odd. The words "keying material" is used in the "Other Bootstrapping Approaches" only. In that paragraph, it refers to some "other" stuff... I'm loath to boil the ocean to define what we aren't doing... I suggest the insertion of the marked text: without external help is also an impossibility. Today it is commonly accepted that the initial connections between nodes are insecure, u= ntil key distribution is complete, or that domain-specific keying materi= al *new* (often pre-shared keys, including mechanisms like SIM cards) is pre-provisioned on each new device in a costly and non-scalable manner. Existing mechanisms are known as non-secured 'Trust on Now, to the term Key Infrastructure: The collection of= systems and processes that sustain the activities of a public key system. In an ANIMA Autonomic system, this includes a Domain Certification Authority (CA), (Join) Registrar which acts as an Registrar, as well as appropriate certificate revocation list (CRL) distribution points and/or OC= SP () servers. I note that RFC6960 doesn't bother to define Key Infrastructure at all, or even use the term except in the title... =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqMhJAACgkQgItw+93Q 3WVBzgf/TsOR1otvWbxQGPnDXW3fn6nrdetJNO69dQtpd8fSIn+5u/CE6zZ8ytRU HuL3HiIQqUdI8NbdIWwpCcTKmr1g+JiEKl9d+RhVHMdvKHvxxtoEMtg9Vh9M2Szf sOLdfKNOgJzv5pxvWjWxPSbnqfMbOR7c1oqFdfwoJ+R2QHS+oEuAldjjHUe0sKIy W+nobpnlRspt/aMev2UiGyssipKS2nc4k77cAjqtq7TkQES/7BlYfwh+WT5IRtN+ Hl4ORYDFEraZIZX+99F+ndkFN++7JDabkCD9d5kVRzYs6KJ3WlSJb4AYj6JtIO1S iZ4CjSDysyRd0HDQEFyV0fnfEfEwoA== =8PR8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 20 14:04:35 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472FD12DB71 for ; Tue, 20 Feb 2018 14:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TuTnOFCYweeE for ; Tue, 20 Feb 2018 14:04:31 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CF5120724 for ; Tue, 20 Feb 2018 14:04:30 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A081C58C562; Tue, 20 Feb 2018 23:04:26 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 74BB5B0DB01; Tue, 20 Feb 2018 23:04:26 +0100 (CET) Date: Tue, 20 Feb 2018 23:04:26 +0100 From: Toerless Eckert To: Michael Richardson Cc: "anima@ietf.org" Message-ID: <20180220220426.GC23498@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <11878.1518662730@obiwan.sandelman.ca> <89C98637-ACD2-423A-A8C4-52191C35FA53@cisco.com> <19137.1519158417@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19137.1519158417@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 22:04:33 -0000 I always welcome, support and root for removal, avoidance and rephrasing of redundant, unnecessary, confusing, contradicting or otherwise irritating words, sentences, phrases or other elements of IETF drafts. I just reserve the right to be pretty bad at it myself, given how i was raised with a language that is defective in this regard. See also: https://www.cs.utah.edu/~gback/awfgrmlg.html Cheers Toerless On Tue, Feb 20, 2018 at 03:26:57PM -0500, Michael Richardson wrote: > > Max Pritikin (pritikin) wrote: > >>> b) Key infrastructure > >> > >>> There is no definition/reference for this term. Please describe on > >>> first use and in terminology. Is there a difference > >>> between "key infrastructure" and "keying material" ? If not, then > >>> maybe remove one term otherwise pls. describe difference. > >> > >> The term is in the title and in section 1. > >> And you are right that it does not appear again, nor is it defined. > >> I think it generally refers to the mechanism of PKI, but I'm not sure what to do. > > > An ???infrastructure??? is the basic entities and protocols necessary for > > the operations of key management. I think it comes from the common > > language term and can???t find a normative definition within IETF > > document. As a native english speaker who has used the concept in IETF > > interactions for eons it feels silly to try and define it. Odd. > > The words "keying material" is used in the "Other Bootstrapping Approaches" > only. In that paragraph, it refers to some "other" stuff... I'm loath to > boil the ocean to define what we aren't doing... > > I suggest the insertion of the marked text: > > without external help is also an impossibility. Today it is commonly > accepted that the initial connections between nodes are insecure, until > key distribution is complete, or that domain-specific keying material > *new* (often pre-shared keys, including mechanisms like SIM cards) > is pre-provisioned on each new device in a costly and non-scalable > manner. Existing mechanisms are known as non-secured 'Trust on > > Now, to the term Key Infrastructure: > > The collection of systems and > processes that sustain the activities of a public key system. > In an ANIMA Autonomic system, this includes a Domain > Certification Authority (CA), (Join) Registrar which acts as an > Registrar, as well as appropriate > certificate revocation list (CRL) distribution points and/or OCSP > () servers. > > I note that RFC6960 doesn't bother to define Key Infrastructure at all, or > even use the term except in the title... > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Feb 20 16:54:46 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438DB12E741; Tue, 20 Feb 2018 16:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 rU5mDj8-TyLy; Tue, 20 Feb 2018 16:54:42 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3981F12E050; Tue, 20 Feb 2018 16:54:42 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 017A220091; Tue, 20 Feb 2018 20:02:00 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A0C0D80AE3; Tue, 20 Feb 2018 19:54:40 -0500 (EST) From: Michael Richardson To: Toerless Eckert cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org In-Reply-To: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 00:54:44 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > Overall: > a) Requirements about EST: > - The introduction says: "Integration with a complete EST enrollment is > optional but trivial" > - 5.8.3 says "The Pledge MUST request a new client certificate". > - 1.4 says "bootstrapped devices have a common trust anchor and a certificate > has optionally been issued from a local PKI > a) The text needs to be made consistent across all places where requirements > are defined. I have in general no strong opinion how "optional" the text should > say EST operations are, BUT consider he following points: > b) We need a complete list of BRSKI requirements for ANI devices, where EST > operation requirements are made stronger. I suggest a separate subsection at an > appropriate place so that "ANI requirements" shows up in the table of contents: > Section X.Y.Z Requirements for ANI devices: > For BRSKI on ANI Devices (ANI = BRSKI + ACP), EST operations is mandator. > The ANI pledge MUST perform > - "CA Certificates Request", > - "CSR Attributes" > - "Client Certificate Request" > - "Enrollment status Telemetry" > The ANI registrar MUST support BRSKI and these EST operations. > All ANI devices SHOULD support the BRSKI proxy function. I've done the following: + 1.5. Requirements for Autonomic Network Infrastructure (ANI) + devices . . . . . . . . . . . . . . . . . . . . . . . . . 10 - BRSKI is agile enough to support bootstrapping alternative key - infrastructures, such as a symmetric key solutions, but no such - system is described in this document. + BRSKI is agile enough to support bootstrapping alternative key + infrastructures, such as a symmetric key solutions, but no such + system is described in this document. + 1.1. Other Bootstrapping Approaches To literally "pull yourself up by the bootstraps" is an impossible @@ -233,9 +237,10 @@ Internet-Draft BRSKI February 2018 without external help is also an impossibility. Today it is commonly accepted that the initial connections between nodes are insecure, until key distribution is complete, or that domain-specific keying - material is pre-provisioned on each new device in a costly and non- - scalable manner. Existing mechanisms are known as non-secured 'Trust - on First Use' (TOFU) [RFC7435], 'resurrecting duckling' + material (often pre-shared keys, including mechanisms like SIM cards) + is pre-provisioned on each new device in a costly and non-scalable + manner. Existing mechanisms are known as non-secured 'Trust on First + Use' (TOFU) [RFC7435], 'resurrecting duckling' [Stajano99theresurrecting] or 'pre-staging'. Another approach is to try and minimize user actions during @@ -358,6 +364,13 @@ Internet-Draft BRSKI February 2018 "Registrar". The term JRC is used in common with other bootstrap mechanisms. + (Public) Key Infrastructure: The collection of systems and processes + that sustain the activities of a public key system. In an ANIMA + Autonomic system, this includes a Domain Certification Authority + (CA), (Join) Registrar which acts as an [RFC5280] Registrar, as + well as appropriate certificate revocation list (CRL) distribution + points and/or OCSP ([RFC6960]) servers. + Join Proxy: A domain entity that helps the Pledge join the domain. A Proxy facilitates communication for devices that find themselves in an environment where they are not provided connectivity until +1.5. Requirements for Autonomic Network Infrastructure (ANI) devices + The BRSKI protocol can be used in a number of environments. Some of + the flexibility in this document is the result of users out of the + ANI scope. This section defines the base requirements for ANI + devices. + For devices that intend to become part of an Autonomic Network + Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes + an Autonomic Control Plane + ([I-D.ietf-anima-autonomic-control-plane]), the following actions are + required and MUST be performed by the Pledge: + o BRSKI: Request Voucher + o EST: CA Certificates Request + o EST: CSR Attributes + o EST: Client Certificate Request + o BRSKI: Enrollment status Telemetry + The ANI Registrar (JRC) MUST support all the BRSKI and above listed + EST operations. + All ANI devices SHOULD support the BRSKI proxy function, using + circuit proxies. Other proxy methods are optional, and may be + enabled only if the JRC indicates support for them in it's + announcement. (See Section 4.4) > II) This leaves the option that EST to install trust anchor is mandatory, but > enrolment with a certificate is optional (except for ANI case). > Aka: would be good to write a sentence/paragraph exactly outlining what is > permitted to happen after a voucher and if any, what parts of EST are deemed to > be necessary by BRSKI (outside of ANI devices. the requirements for ANI devices > are listed above). I think that this should be left to other users. I am going to push the -11 with these changes, and the ones from last week. I acknowledge that I still have a bunch of edits from the rest of your message. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqMw08ACgkQgItw+93Q 3WWguQgAtuVWEXSSocZAG4Xvap6xuh+5AyzyVvwXYskDFdW7YNC9sFIXdrf1J/XH 64xafNxTE8X0TptPeSbnyPiHxdgreBqMcIWxGIc9n+CJTkJ6vKcEIcpvcqCI2RR/ PiK4LsX6hUe9ag8S89oJxkwchXUQv5QmzbVWQ8aNPP8D+/8Mb/FFLdyx63fsejH/ NstmfIr2G/LBPWL8jckOKTSVbCwFDALQ4sf6mzyzDB0bylvbcWLcb1dfrTB7mqrE sGONrWFI/OYZE99Y5X2xzRUPYo2qZK9wmExyJ3h3kj4tG+x3NslI3PLNlmjg6WWl aFOKe5R1KHebCdqlKdLr7ILAXnTQqQ== =Nut0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 20 18:38:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BE91241F3; Tue, 20 Feb 2018 18:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 Kp3m01eSH5p2; Tue, 20 Feb 2018 18:38:50 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F64D1204DA; Tue, 20 Feb 2018 18:38:50 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 510D758C565; Wed, 21 Feb 2018 03:38:45 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 309EEB0DB08; Wed, 21 Feb 2018 03:38:45 +0100 (CET) Date: Wed, 21 Feb 2018 03:38:45 +0100 From: Toerless Eckert To: Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org Message-ID: <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <23103.1519174480@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23103.1519174480@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 02:38:53 -0000 Thanks, Michael Can't see a commit on github since 6 dyays ago, maybe in different branch ? Comments for now therefore inline against your email. On Tue, Feb 20, 2018 at 07:54:40PM -0500, Michael Richardson wrote: > > Toerless Eckert wrote: > > Overall: > > > a) Requirements about EST: > > > - The introduction says: "Integration with a complete EST enrollment is > > optional but trivial" > > - 5.8.3 says "The Pledge MUST request a new client certificate". > > - 1.4 says "bootstrapped devices have a common trust anchor and a certificate > > has optionally been issued from a local PKI > > > a) The text needs to be made consistent across all places where requirements > > are defined. I have in general no strong opinion how "optional" the text should > > say EST operations are, BUT consider he following points: > > > b) We need a complete list of BRSKI requirements for ANI devices, where EST > > operation requirements are made stronger. I suggest a separate subsection at an > > appropriate place so that "ANI requirements" shows up in the table of contents: > > > Section X.Y.Z Requirements for ANI devices: > > > For BRSKI on ANI Devices (ANI = BRSKI + ACP), EST operations is mandator. > > The ANI pledge MUST perform > > - "CA Certificates Request", > > - "CSR Attributes" > > - "Client Certificate Request" > > - "Enrollment status Telemetry" > > The ANI registrar MUST support BRSKI and these EST operations. > > All ANI devices SHOULD support the BRSKI proxy function. > > I've done the following: [...]> > 1.1. Other Bootstrapping Approaches > > To literally "pull yourself up by the bootstraps" is an impossible > @@ -233,9 +237,10 @@ Internet-Draft BRSKI February 2018 > without external help is also an impossibility. Today it is commonly > accepted that the initial connections between nodes are insecure, > until key distribution is complete, or that domain-specific keying > - material is pre-provisioned on each new device in a costly and non- > - scalable manner. Existing mechanisms are known as non-secured 'Trust > - on First Use' (TOFU) [RFC7435], 'resurrecting duckling' > + material (often pre-shared keys, including mechanisms like SIM cards) > + is pre-provisioned on each new device in a costly and non-scalable > + manner. Existing mechanisms are known as non-secured 'Trust on First > + Use' (TOFU) [RFC7435], 'resurrecting duckling' > [Stajano99theresurrecting] or 'pre-staging'. Nice. > Another approach is to try and minimize user actions during > > @@ -358,6 +364,13 @@ Internet-Draft BRSKI February 2018 > "Registrar". The term JRC is used in common with other bootstrap > mechanisms. > > + (Public) Key Infrastructure: The collection of systems and processes > + that sustain the activities of a public key system. In an ANIMA > + Autonomic system, this includes a Domain Certification Authority > + (CA), (Join) Registrar which acts as an [RFC5280] Registrar, as > + well as appropriate certificate revocation list (CRL) distribution > + points and/or OCSP ([RFC6960]) servers. I had interpreted Max'es response on the mail discussion to indicate that MASA would also be considered to be part of the PKI. I am fine either way. Just checking. If as you propose above it's not part of the PKI, a simple sentence explaining why not would be great. > + > Join Proxy: A domain entity that helps the Pledge join the domain. > A Proxy facilitates communication for devices that find themselves > in an environment where they are not provided connectivity until > > +1.5. Requirements for Autonomic Network Infrastructure (ANI) devices > > + The BRSKI protocol can be used in a number of environments. Some of > + the flexibility in this document is the result of users out of the > + ANI scope. This section defines the base requirements for ANI > + devices. > > + For devices that intend to become part of an Autonomic Network > + Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes > + an Autonomic Control Plane > + ([I-D.ietf-anima-autonomic-control-plane]), the following actions are > + required and MUST be performed by the Pledge: > > + o BRSKI: Request Voucher > > + o EST: CA Certificates Request > > + o EST: CSR Attributes > > + o EST: Client Certificate Request > > + o BRSKI: Enrollment status Telemetry > > + The ANI Registrar (JRC) MUST support all the BRSKI and above listed > + EST operations. Can't remember conclusion on redundant terminology re. JRC vs. the other terms used. Personal preference would be to eliminate JRC as a term, but i'll wait for the final doc. re. minimum necessary terminology. > + All ANI devices SHOULD support the BRSKI proxy function, using > + circuit proxies. Other proxy methods are optional Overall 1.5 nice.1 > + , and may be > + enabled only if the JRC indicates support for them in it's > + announcement. (See Section 4.4) IMHO: sentence eend after "optional". Followed by "all proxy functionally needs to ... be enabled... Aka: circuit proxy is a no-op too if the proxy does not discover a registrar supporting it. Not specific to advanced options. > > II) This leaves the option that EST to install trust anchor is mandatory, but > > enrolment with a certificate is optional (except for ANI case). > > > Aka: would be good to write a sentence/paragraph exactly outlining what is > > permitted to happen after a voucher and if any, what parts of EST are deemed to > > be necessary by BRSKI (outside of ANI devices. the requirements for ANI devices > > are listed above). > > I think that this should be left to other users. Rephrase ? Don't understand what this means (especially users). "other authors" ? "other docs" ? Maybe just: BRSKI does not mandate EST client certificate enrolment except for ANI devices. Considerations for complete solutions using Pledges that only perform Request Voucher and CA Certificates request, but no EST client certificate enrolment are outside the scope of this document / subject to future work. > I am going to push the -11 with these changes, and the ones from last week. Thanks! Cheers Toerless > I acknowledge that I still have a bunch of edits from the rest of your message. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Feb 20 18:45:18 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10F21241F3; Tue, 20 Feb 2018 18:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcvYLQEyffQX; Tue, 20 Feb 2018 18:45:14 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DA21204DA; Tue, 20 Feb 2018 18:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10682; q=dns/txt; s=iport; t=1519181114; x=1520390714; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EYYJTGMdn94W7H+GWCaIZp0cqN1onMb8Jps2S1EhXJ8=; b=HiwXXpISuRO72wGV/YbFzoposJiJqAhpwTKRRsUOczisKa+qn5WKZ4vE LMGU3x0OHRpHnDSxCYmgcQ3vLzsA5f9L40k7Ae9OjfSv60ONr8f4RhZf7 dBd1aSKLOp+CB07z60VTkDqhfBfmgragcjbLbv8XvwGLYD7M2KwDCB+Ie A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeBQA03Ixa/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMeMWZwKAqDXpgsgVsngReWXS4BgVMKGAuBXoMzAhqCUlgUAQI?= =?us-ascii?q?BAQEBAQECayiFIwEBAQMBAQEhEToLBQsCAQgOCgICJgICAiULFRACBA4FG4oAC?= =?us-ascii?q?BCrIYIniH6CEwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+Df4Ingz4pDIJ5gzA?= =?us-ascii?q?BAYE1CAEBEQIBHoMXMYI0BaQ1CQKWCpRCl3QCERkBgTsBNiJgcXAVOioBghiEd?= =?us-ascii?q?niLYoEZAQEB?= X-IronPort-AV: E=Sophos;i="5.46,542,1511827200"; d="scan'208";a="356718982" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2018 02:45:13 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w1L2jDHM029527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Feb 2018 02:45:13 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 20 Feb 2018 20:45:12 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1320.000; Tue, 20 Feb 2018 20:45:12 -0600 From: "Max Pritikin (pritikin)" To: Toerless Eckert CC: Michael Richardson , "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , "anima@ietf.org" Thread-Topic: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 Thread-Index: AQHTqq6RwUq7VDqbtECHDsh0DZ59mKOuiWeAgAABzgA= Date: Wed, 21 Feb 2018 02:45:12 +0000 Message-ID: References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <23103.1519174480@obiwan.sandelman.ca> <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: text/plain; charset="utf-8" Content-ID: <098A6B2D947A164887625D3210C84DF9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 02:45:17 -0000 DQoNCj4gT24gRmViIDIwLCAyMDE4LCBhdCA3OjM4IFBNLCBUb2VybGVzcyBFY2tlcnQgPHR0ZUBj cy5mYXUuZGU+IHdyb3RlOg0KPiANCj4gVGhhbmtzLCBNaWNoYWVsDQo+IENhbid0IHNlZSBhIGNv bW1pdCBvbiBnaXRodWIgc2luY2UgNiBkeWF5cyBhZ28sIG1heWJlIGluIGRpZmZlcmVudCBicmFu Y2ggPw0KPiBDb21tZW50cyBmb3Igbm93IHRoZXJlZm9yZSBpbmxpbmUgYWdhaW5zdCB5b3VyIGVt YWlsLg0KPiANCj4gT24gVHVlLCBGZWIgMjAsIDIwMTggYXQgMDc6NTQ6NDBQTSAtMDUwMCwgTWlj aGFlbCBSaWNoYXJkc29uIHdyb3RlOg0KPj4gDQo+PiBUb2VybGVzcyBFY2tlcnQgPHR0ZUBjcy5m YXUuZGU+IHdyb3RlOg0KPj4+IE92ZXJhbGw6DQo+PiANCj4+PiBhKSBSZXF1aXJlbWVudHMgYWJv dXQgRVNUOg0KPj4gDQo+Pj4gLSBUaGUgaW50cm9kdWN0aW9uIHNheXM6ICJJbnRlZ3JhdGlvbiB3 aXRoIGEgY29tcGxldGUgRVNUIGVucm9sbG1lbnQgaXMNCj4+PiBvcHRpb25hbCBidXQgdHJpdmlh bCINCj4+PiAtIDUuOC4zIHNheXMgIlRoZSBQbGVkZ2UgTVVTVCByZXF1ZXN0IGEgbmV3IGNsaWVu dCBjZXJ0aWZpY2F0ZSIuDQo+Pj4gLSAxLjQgc2F5cyAiYm9vdHN0cmFwcGVkIGRldmljZXMgaGF2 ZSBhIGNvbW1vbiB0cnVzdCBhbmNob3IgYW5kIGEgY2VydGlmaWNhdGUNCj4+PiBoYXMgb3B0aW9u YWxseSBiZWVuIGlzc3VlZCBmcm9tIGEgbG9jYWwgUEtJDQo+PiANCj4+PiBhKSBUaGUgdGV4dCBu ZWVkcyB0byBiZSBtYWRlIGNvbnNpc3RlbnQgYWNyb3NzIGFsbCBwbGFjZXMgd2hlcmUgcmVxdWly ZW1lbnRzDQo+Pj4gYXJlIGRlZmluZWQuIEkgaGF2ZSBpbiBnZW5lcmFsIG5vIHN0cm9uZyBvcGlu aW9uIGhvdyAib3B0aW9uYWwiIHRoZSB0ZXh0IHNob3VsZA0KPj4+IHNheSBFU1Qgb3BlcmF0aW9u cyBhcmUsIEJVVCBjb25zaWRlciBoZSBmb2xsb3dpbmcgcG9pbnRzOg0KPj4gDQo+Pj4gYikgV2Ug bmVlZCBhIGNvbXBsZXRlIGxpc3Qgb2YgQlJTS0kgcmVxdWlyZW1lbnRzIGZvciBBTkkgZGV2aWNl cywgd2hlcmUgRVNUDQo+Pj4gb3BlcmF0aW9uIHJlcXVpcmVtZW50cyBhcmUgbWFkZSBzdHJvbmdl ci4gSSBzdWdnZXN0IGEgc2VwYXJhdGUgc3Vic2VjdGlvbiBhdCBhbg0KPj4+IGFwcHJvcHJpYXRl IHBsYWNlIHNvIHRoYXQgIkFOSSByZXF1aXJlbWVudHMiIHNob3dzIHVwIGluIHRoZSB0YWJsZSBv ZiBjb250ZW50czoNCj4+IA0KPj4+IFNlY3Rpb24gWC5ZLlogUmVxdWlyZW1lbnRzIGZvciBBTkkg ZGV2aWNlczoNCj4+IA0KPj4+IEZvciBCUlNLSSBvbiBBTkkgRGV2aWNlcyAoQU5JID0gQlJTS0kg KyBBQ1ApLCBFU1Qgb3BlcmF0aW9ucyBpcyBtYW5kYXRvci4NCj4+PiBUaGUgQU5JIHBsZWRnZSBN VVNUIHBlcmZvcm0NCj4+PiAtICJDQSBDZXJ0aWZpY2F0ZXMgUmVxdWVzdCIsDQo+Pj4gLSAiQ1NS IEF0dHJpYnV0ZXMiDQo+Pj4gLSAiQ2xpZW50IENlcnRpZmljYXRlIFJlcXVlc3QiDQo+Pj4gLSAi RW5yb2xsbWVudCBzdGF0dXMgVGVsZW1ldHJ5Ig0KPj4+IFRoZSBBTkkgcmVnaXN0cmFyIE1VU1Qg c3VwcG9ydCBCUlNLSSBhbmQgdGhlc2UgRVNUIG9wZXJhdGlvbnMuDQo+Pj4gQWxsIEFOSSBkZXZp Y2VzIFNIT1VMRCBzdXBwb3J0IHRoZSBCUlNLSSBwcm94eSBmdW5jdGlvbi4NCj4+IA0KPj4gSSd2 ZSBkb25lIHRoZSBmb2xsb3dpbmc6DQo+IFsuLi5dPiANCj4gDQo+PiAxLjEuICBPdGhlciBCb290 c3RyYXBwaW5nIEFwcHJvYWNoZXMNCj4+IA0KPj4gICAgVG8gbGl0ZXJhbGx5ICJwdWxsIHlvdXJz ZWxmIHVwIGJ5IHRoZSBib290c3RyYXBzIiBpcyBhbiBpbXBvc3NpYmxlDQo+PiBAQCAtMjMzLDkg KzIzNywxMCBAQCBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgQlJTS0kgICAgICAg ICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTgNCj4+ICAgIHdpdGhvdXQgZXh0ZXJuYWwgaGVscCBp cyBhbHNvIGFuIGltcG9zc2liaWxpdHkuICBUb2RheSBpdCBpcyBjb21tb25seQ0KPj4gICAgYWNj ZXB0ZWQgdGhhdCB0aGUgaW5pdGlhbCBjb25uZWN0aW9ucyBiZXR3ZWVuIG5vZGVzIGFyZSBpbnNl Y3VyZSwNCj4+ICAgIHVudGlsIGtleSBkaXN0cmlidXRpb24gaXMgY29tcGxldGUsIG9yIHRoYXQg ZG9tYWluLXNwZWNpZmljIGtleWluZw0KPj4gLSAgIG1hdGVyaWFsIGlzIHByZS1wcm92aXNpb25l ZCBvbiBlYWNoIG5ldyBkZXZpY2UgaW4gYSBjb3N0bHkgYW5kIG5vbi0NCj4+IC0gICBzY2FsYWJs ZSBtYW5uZXIuICBFeGlzdGluZyBtZWNoYW5pc21zIGFyZSBrbm93biBhcyBub24tc2VjdXJlZCAn VHJ1c3QNCj4+IC0gICBvbiBGaXJzdCBVc2UnIChUT0ZVKSBbUkZDNzQzNV0sICdyZXN1cnJlY3Rp bmcgZHVja2xpbmcnDQo+PiArICAgbWF0ZXJpYWwgKG9mdGVuIHByZS1zaGFyZWQga2V5cywgaW5j bHVkaW5nIG1lY2hhbmlzbXMgbGlrZSBTSU0gY2FyZHMpDQo+PiArICAgaXMgcHJlLXByb3Zpc2lv bmVkIG9uIGVhY2ggbmV3IGRldmljZSBpbiBhIGNvc3RseSBhbmQgbm9uLXNjYWxhYmxlDQo+PiAr ICAgbWFubmVyLiAgRXhpc3RpbmcgbWVjaGFuaXNtcyBhcmUga25vd24gYXMgbm9uLXNlY3VyZWQg J1RydXN0IG9uIEZpcnN0DQo+PiArICAgVXNlJyAoVE9GVSkgW1JGQzc0MzVdLCAncmVzdXJyZWN0 aW5nIGR1Y2tsaW5nJw0KPj4gICAgW1N0YWphbm85OXRoZXJlc3VycmVjdGluZ10gb3IgJ3ByZS1z dGFnaW5nJy4NCj4gDQo+IE5pY2UuDQo+IA0KPj4gICAgQW5vdGhlciBhcHByb2FjaCBpcyB0byB0 cnkgYW5kIG1pbmltaXplIHVzZXIgYWN0aW9ucyBkdXJpbmcNCj4+IA0KPj4gQEAgLTM1OCw2ICsz NjQsMTMgQEAgSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIEJSU0tJICAgICAgICAg ICAgICAgICAgICBGZWJydWFyeSAyMDE4DQo+PiAgICAgICAiUmVnaXN0cmFyIi4gIFRoZSB0ZXJt IEpSQyBpcyB1c2VkIGluIGNvbW1vbiB3aXRoIG90aGVyIGJvb3RzdHJhcA0KPj4gICAgICAgbWVj aGFuaXNtcy4NCj4+IA0KPj4gKyAgIChQdWJsaWMpIEtleSBJbmZyYXN0cnVjdHVyZTogIFRoZSBj b2xsZWN0aW9uIG9mIHN5c3RlbXMgYW5kIHByb2Nlc3Nlcw0KPj4gKyAgICAgIHRoYXQgc3VzdGFp biB0aGUgYWN0aXZpdGllcyBvZiBhIHB1YmxpYyBrZXkgc3lzdGVtLiAgSW4gYW4gQU5JTUENCj4+ ICsgICAgICBBdXRvbm9taWMgc3lzdGVtLCB0aGlzIGluY2x1ZGVzIGEgRG9tYWluIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5DQo+PiArICAgICAgKENBKSwgKEpvaW4pIFJlZ2lzdHJhciB3aGljaCBh Y3RzIGFzIGFuIFtSRkM1MjgwXSBSZWdpc3RyYXIsIGFzDQo+PiArICAgICAgd2VsbCBhcyBhcHBy b3ByaWF0ZSBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGxpc3QgKENSTCkgZGlzdHJpYnV0aW9uDQo+ PiArICAgICAgcG9pbnRzIGFuZC9vciBPQ1NQIChbUkZDNjk2MF0pIHNlcnZlcnMuDQo+IA0KPiBJ IGhhZCBpbnRlcnByZXRlZCBNYXgnZXMgcmVzcG9uc2Ugb24gdGhlIG1haWwgZGlzY3Vzc2lvbiB0 byBpbmRpY2F0ZSB0aGF0DQo+IE1BU0Egd291bGQgYWxzbyBiZSBjb25zaWRlcmVkIHRvIGJlIHBh cnQgb2YgdGhlIFBLSS4gSSBhbSBmaW5lIGVpdGhlciB3YXkuDQo+IEp1c3QgY2hlY2tpbmcuIElm IGFzIHlvdSBwcm9wb3NlIGFib3ZlIGl0J3Mgbm90IHBhcnQgb2YgdGhlIFBLSSwgYSBzaW1wbGUN Cj4gc2VudGVuY2UgZXhwbGFpbmluZyB3aHkgbm90IHdvdWxkIGJlIGdyZWF0Lg0KDQpUaGUgTUFT QSBpcyBhIGNlcnRpZmllciBvZiB2b3VjaGVycy4gQSB2b3VjaGVyIGlzbuKAmXQgcmVhbGx5IGEg UEtJIGNvbnN0cnVjdCB0b2RheS4gSXRzIG1vcmUgb2YgYSBkaXN0cmlidXRpb24gb2YgdHJ1c3Qt YW5jaG9yIG9yIOKAnHBpbm5lZCBjZXJ04oCdIGNvbnN0cnVjdCB1c2VkIHRvIGJvb3RzdHJhcCBh IFBLSSBiZWNhdXNlIHRoZSBQS0nigJlzIGRvbuKAmXQgaGF2ZSBzdWNoIGEgY29uY2VwdC4gDQoN CkkgdGhpbmsgaXQgY291bGQgYmUgYXJndWVkIGVpdGhlciB3YXkgYnV0IGl0cyBwcm9iYWJseSBt b3N0IGFjY3VyYXRlIGF0IHRoaXMgdGltZSB0byB0YWxrIGFib3V0IHRoZSBNQVNBIGFzIGJlaW5n IGRpc3RpbmN0IGZyb20gdGhlIFBLSSBpZiBvbmx5IGJlY2F1c2UgdGhpcyBpc27igJl0IHRoZSBQ S0lYIHdvcmtpbmcgZ3JvdXAgYW5kIHRoZXJlZm9yZSBpdCBpc27igJl0IGluIG91ciBjaGFydGVy IHRvIGFkZCBhbnl0aGluZyB0byB0aGUgcHVibGljIGtleSBpbmZyYXN0cnVjdHVyZS4gDQoNCldo aWNoIGhpZ2hsaWdodHMgdGhlIGFic3VyZGl0eSBvZiB0cnlpbmcgdG8gZHJhdyB0aGlzIGRpc3Rp bmN0aW9uLiA6KSBJ4oCZbSBnb29kIHdpdGggTWljaGFlbOKAmXMgZXhjZWxsZW50IHRleHQuIA0K DQotIG1heA0KDQo+IA0KPj4gKw0KPj4gICAgSm9pbiBQcm94eTogIEEgZG9tYWluIGVudGl0eSB0 aGF0IGhlbHBzIHRoZSBQbGVkZ2Ugam9pbiB0aGUgZG9tYWluLg0KPj4gICAgICAgQSBQcm94eSBm YWNpbGl0YXRlcyBjb21tdW5pY2F0aW9uIGZvciBkZXZpY2VzIHRoYXQgZmluZCB0aGVtc2VsdmVz DQo+PiAgICAgICBpbiBhbiBlbnZpcm9ubWVudCB3aGVyZSB0aGV5IGFyZSBub3QgcHJvdmlkZWQg Y29ubmVjdGl2aXR5IHVudGlsDQo+PiANCj4+ICsxLjUuICBSZXF1aXJlbWVudHMgZm9yIEF1dG9u b21pYyBOZXR3b3JrIEluZnJhc3RydWN0dXJlIChBTkkpIGRldmljZXMNCj4+IA0KPj4gKyAgIFRo ZSBCUlNLSSBwcm90b2NvbCBjYW4gYmUgdXNlZCBpbiBhIG51bWJlciBvZiBlbnZpcm9ubWVudHMu ICBTb21lIG9mDQo+PiArICAgdGhlIGZsZXhpYmlsaXR5IGluIHRoaXMgZG9jdW1lbnQgaXMgdGhl IHJlc3VsdCBvZiB1c2VycyBvdXQgb2YgdGhlDQo+PiArICAgQU5JIHNjb3BlLiAgVGhpcyBzZWN0 aW9uIGRlZmluZXMgdGhlIGJhc2UgcmVxdWlyZW1lbnRzIGZvciBBTkkNCj4+ICsgICBkZXZpY2Vz Lg0KPj4gDQo+PiArICAgRm9yIGRldmljZXMgdGhhdCBpbnRlbmQgdG8gYmVjb21lIHBhcnQgb2Yg YW4gQXV0b25vbWljIE5ldHdvcmsNCj4+ICsgICBJbmZyYXN0cnVjdHVyZSAoQU5JKSAoW0ktRC5p ZXRmLWFuaW1hLXJlZmVyZW5jZS1tb2RlbF0pIHRoYXQgaW5jbHVkZXMNCj4+ICsgICBhbiBBdXRv bm9taWMgQ29udHJvbCBQbGFuZQ0KPj4gKyAgIChbSS1ELmlldGYtYW5pbWEtYXV0b25vbWljLWNv bnRyb2wtcGxhbmVdKSwgdGhlIGZvbGxvd2luZyBhY3Rpb25zIGFyZQ0KPj4gKyAgIHJlcXVpcmVk IGFuZCBNVVNUIGJlIHBlcmZvcm1lZCBieSB0aGUgUGxlZGdlOg0KPj4gDQo+PiArICAgbyAgQlJT S0k6IFJlcXVlc3QgVm91Y2hlcg0KPj4gDQo+PiArICAgbyAgRVNUOiBDQSBDZXJ0aWZpY2F0ZXMg UmVxdWVzdA0KPj4gDQo+PiArICAgbyAgRVNUOiBDU1IgQXR0cmlidXRlcw0KPj4gDQo+PiArICAg byAgRVNUOiBDbGllbnQgQ2VydGlmaWNhdGUgUmVxdWVzdA0KPj4gDQo+PiArICAgbyAgQlJTS0k6 IEVucm9sbG1lbnQgc3RhdHVzIFRlbGVtZXRyeQ0KPj4gDQo+PiArICAgVGhlIEFOSSBSZWdpc3Ry YXIgKEpSQykgTVVTVCBzdXBwb3J0IGFsbCB0aGUgQlJTS0kgYW5kIGFib3ZlIGxpc3RlZA0KPj4g KyAgIEVTVCBvcGVyYXRpb25zLg0KPiANCj4gDQo+IENhbid0IHJlbWVtYmVyIGNvbmNsdXNpb24g b24gcmVkdW5kYW50IHRlcm1pbm9sb2d5IHJlLiBKUkMgdnMuIHRoZSBvdGhlciB0ZXJtcw0KPiB1 c2VkLiBQZXJzb25hbCBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGVsaW1pbmF0ZSBKUkMgYXMgYSB0 ZXJtLCBidXQgaSdsbCB3YWl0DQo+IGZvciB0aGUgZmluYWwgZG9jLiByZS4gbWluaW11bSBuZWNl c3NhcnkgdGVybWlub2xvZ3kuDQo+IA0KPj4gKyAgIEFsbCBBTkkgZGV2aWNlcyBTSE9VTEQgc3Vw cG9ydCB0aGUgQlJTS0kgcHJveHkgZnVuY3Rpb24sIHVzaW5nDQo+PiArICAgY2lyY3VpdCBwcm94 aWVzLiAgT3RoZXIgcHJveHkgbWV0aG9kcyBhcmUgb3B0aW9uYWwNCj4gDQo+IE92ZXJhbGwgMS41 IG5pY2UuMQ0KPiANCj4+ICsgICAsIGFuZCBtYXkgYmUNCj4+ICsgICBlbmFibGVkIG9ubHkgaWYg dGhlIEpSQyBpbmRpY2F0ZXMgc3VwcG9ydCBmb3IgdGhlbSBpbiBpdCdzDQo+PiArICAgYW5ub3Vu Y2VtZW50LiAgKFNlZSBTZWN0aW9uIDQuNCkNCj4gDQo+IElNSE86IHNlbnRlbmNlIGVlbmQgYWZ0 ZXIgIm9wdGlvbmFsIi4gRm9sbG93ZWQgYnkgImFsbCBwcm94eSBmdW5jdGlvbmFsbHkNCj4gbmVl ZHMgdG8gLi4uIGJlIGVuYWJsZWQuLi4NCj4gDQo+IEFrYTogY2lyY3VpdCBwcm94eSBpcyBhIG5v LW9wIHRvbyBpZiB0aGUgcHJveHkgZG9lcyBub3QgZGlzY292ZXIgYSByZWdpc3RyYXINCj4gc3Vw cG9ydGluZyBpdC4gTm90IHNwZWNpZmljIHRvIGFkdmFuY2VkIG9wdGlvbnMuDQo+IA0KPiANCj4+ PiBJSSkgVGhpcyBsZWF2ZXMgdGhlIG9wdGlvbiB0aGF0IEVTVCB0byBpbnN0YWxsIHRydXN0IGFu Y2hvciBpcyBtYW5kYXRvcnksIGJ1dA0KPj4+IGVucm9sbWVudCB3aXRoIGEgY2VydGlmaWNhdGUg aXMgb3B0aW9uYWwgKGV4Y2VwdCBmb3IgQU5JIGNhc2UpLg0KPj4gDQo+Pj4gQWthOiB3b3VsZCBi ZSBnb29kIHRvIHdyaXRlIGEgc2VudGVuY2UvcGFyYWdyYXBoIGV4YWN0bHkgb3V0bGluaW5nIHdo YXQgaXMNCj4+PiBwZXJtaXR0ZWQgdG8gaGFwcGVuIGFmdGVyIGEgdm91Y2hlciBhbmQgaWYgYW55 LCB3aGF0IHBhcnRzIG9mIEVTVCBhcmUgZGVlbWVkIHRvDQo+Pj4gYmUgbmVjZXNzYXJ5IGJ5IEJS U0tJIChvdXRzaWRlIG9mIEFOSSBkZXZpY2VzLiB0aGUgcmVxdWlyZW1lbnRzIGZvciBBTkkgZGV2 aWNlcw0KPj4+IGFyZSBsaXN0ZWQgYWJvdmUpLg0KPj4gDQo+PiBJIHRoaW5rIHRoYXQgdGhpcyBz aG91bGQgYmUgbGVmdCB0byBvdGhlciB1c2Vycy4NCj4gDQo+IFJlcGhyYXNlID8gRG9uJ3QgdW5k ZXJzdGFuZCB3aGF0IHRoaXMgbWVhbnMgKGVzcGVjaWFsbHkgdXNlcnMpLiAib3RoZXIgYXV0aG9y cyIgPyAib3RoZXIgZG9jcyIgPw0KPiANCj4gTWF5YmUganVzdDogDQo+IA0KPiBCUlNLSSBkb2Vz IG5vdCBtYW5kYXRlIEVTVCBjbGllbnQgY2VydGlmaWNhdGUgZW5yb2xtZW50IGV4Y2VwdCBmb3Ig QU5JIGRldmljZXMuDQo+IENvbnNpZGVyYXRpb25zIGZvciBjb21wbGV0ZSBzb2x1dGlvbnMgdXNp bmcgUGxlZGdlcyB0aGF0IG9ubHkgcGVyZm9ybSBSZXF1ZXN0IFZvdWNoZXINCj4gYW5kIENBIENl cnRpZmljYXRlcyByZXF1ZXN0LCBidXQgbm8gRVNUIGNsaWVudCBjZXJ0aWZpY2F0ZSBlbnJvbG1l bnQgYXJlDQo+IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgLyBzdWJqZWN0IHRv IGZ1dHVyZSB3b3JrLg0KPiANCj4gDQo+PiBJIGFtIGdvaW5nIHRvIHB1c2ggdGhlIC0xMSB3aXRo IHRoZXNlIGNoYW5nZXMsIGFuZCB0aGUgb25lcyBmcm9tIGxhc3Qgd2Vlay4NCj4gDQo+IFRoYW5r cyENCj4gDQo+IENoZWVycw0KPiAgICBUb2VybGVzcw0KPiANCj4+IEkgYWNrbm93bGVkZ2UgdGhh dCBJIHN0aWxsIGhhdmUgYSBidW5jaCBvZiBlZGl0cyBmcm9tIHRoZSByZXN0IG9mIHlvdXIgbWVz c2FnZS4NCj4+IA0KPj4gDQo+PiAtLQ0KPj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBz YW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4+IC09IElQdjYgSW9UIGNv bnN1bHRpbmcgPS0NCj4+IA0KPj4gDQo+PiANCj4gDQo+IA0KPiANCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBbmltYSBtYWlsaW5nIGxpc3QN Cj4+IEFuaW1hQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FuaW1hDQo+IA0KPiANCj4gLS0gDQo+IC0tLQ0KPiB0dGVAY3MuZmF1LmRlDQoNCg== From nobody Tue Feb 20 18:55:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34AA124D68; Tue, 20 Feb 2018 18:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 wJ8FP04Fpm30; Tue, 20 Feb 2018 18:55:10 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671D21204DA; Tue, 20 Feb 2018 18:55:10 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1A4A220091; Tue, 20 Feb 2018 22:02:30 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8886F80CCB; Tue, 20 Feb 2018 21:55:09 -0500 (EST) From: Michael Richardson To: Toerless Eckert cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org In-Reply-To: <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <23103.1519174480@obiwan.sandelman.ca> <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 02:55:12 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > Thanks, Michael > Can't see a commit on github since 6 dyays ago, maybe in different branch ? > Comments for now therefore inline against your email. Yeah, it's on the toerless-terminology-comments branch. About to be in -11. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqM340ACgkQgItw+93Q 3WUqogf+OWnbJblxYd8xvGulN0wv5gyY9BsA1bvuClNTlWgrlXVfZcNjvuFbTbG6 SWGYvM0H2fsQPZ8ZPoQHU4hBw205k6dL7RWuTRbNftS5zOMxGOeAJuHbkAA6wBIk Rab3v0MgvA109+HmqC/1bRS8vcMWNh+wtd8E4plB+chZT5vmMQYahZPxQBZhNxa5 LAgrjSlOxDot2JBU35PJhy6Pdu1Zu4/ZZHM4Kx8M3j/pFwWic6a/uesWts46LdpW HyyOvCJWRgFzSWb9Ov26Hj2w18JJIP709cJqL1ez/QNXSIjxpKGS1Ur9BAbqZ6ao Jzl3B4JTbLVvCo144IesyjBpvumwbg== =gcwq -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 20 18:58:24 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3635124D68; Tue, 20 Feb 2018 18:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 fjBOLq-MkBgE; Tue, 20 Feb 2018 18:58:20 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E20F1204DA; Tue, 20 Feb 2018 18:58:20 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4550058C565; Wed, 21 Feb 2018 03:58:16 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 23B6AB0DB08; Wed, 21 Feb 2018 03:58:16 +0100 (CET) Date: Wed, 21 Feb 2018 03:58:16 +0100 From: Toerless Eckert To: "Max Pritikin (pritikin)" Cc: "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , Michael Richardson , "anima@ietf.org" Message-ID: <20180221025815.GE23498@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <23103.1519174480@obiwan.sandelman.ca> <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 02:58:23 -0000 On Wed, Feb 21, 2018 at 02:45:12AM +0000, Max Pritikin (pritikin) wrote: > > The MASA is a certifier of vouchers. A voucher isn???t really a PKI construct today. Its more of a distribution of trust-anchor or ???pinned cert??? construct used to bootstrap a PKI because the PKI???s don???t have such a concept. Thank. I always hate good explanations go to waste. Sentence like the following would be lovely for readers whose first attempt at survival in a sea of security is to figure out what the terminology means: (at end of PKI def in termonology). Note: The definition of PKI preceeds the MASA and Voucher concepts and any evolution of the definition of the term PKI is outside the scope of this document. Therefore they are not considered to be part of a PKI. Cheers Toerless > I think it could be argued either way but its probably most accurate at this time to talk about the MASA as being distinct from the PKI if only because this isn???t the PKIX working group and therefore it isn???t in our charter to add anything to the public key infrastructure. > > Which highlights the absurdity of trying to draw this distinction. :) I???m good with Michael???s excellent text. > > - max > > > > >> + > >> Join Proxy: A domain entity that helps the Pledge join the domain. > >> A Proxy facilitates communication for devices that find themselves > >> in an environment where they are not provided connectivity until > >> > >> +1.5. Requirements for Autonomic Network Infrastructure (ANI) devices > >> > >> + The BRSKI protocol can be used in a number of environments. Some of > >> + the flexibility in this document is the result of users out of the > >> + ANI scope. This section defines the base requirements for ANI > >> + devices. > >> > >> + For devices that intend to become part of an Autonomic Network > >> + Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes > >> + an Autonomic Control Plane > >> + ([I-D.ietf-anima-autonomic-control-plane]), the following actions are > >> + required and MUST be performed by the Pledge: > >> > >> + o BRSKI: Request Voucher > >> > >> + o EST: CA Certificates Request > >> > >> + o EST: CSR Attributes > >> > >> + o EST: Client Certificate Request > >> > >> + o BRSKI: Enrollment status Telemetry > >> > >> + The ANI Registrar (JRC) MUST support all the BRSKI and above listed > >> + EST operations. > > > > > > Can't remember conclusion on redundant terminology re. JRC vs. the other terms > > used. Personal preference would be to eliminate JRC as a term, but i'll wait > > for the final doc. re. minimum necessary terminology. > > > >> + All ANI devices SHOULD support the BRSKI proxy function, using > >> + circuit proxies. Other proxy methods are optional > > > > Overall 1.5 nice.1 > > > >> + , and may be > >> + enabled only if the JRC indicates support for them in it's > >> + announcement. (See Section 4.4) > > > > IMHO: sentence eend after "optional". Followed by "all proxy functionally > > needs to ... be enabled... > > > > Aka: circuit proxy is a no-op too if the proxy does not discover a registrar > > supporting it. Not specific to advanced options. > > > > > >>> II) This leaves the option that EST to install trust anchor is mandatory, but > >>> enrolment with a certificate is optional (except for ANI case). > >> > >>> Aka: would be good to write a sentence/paragraph exactly outlining what is > >>> permitted to happen after a voucher and if any, what parts of EST are deemed to > >>> be necessary by BRSKI (outside of ANI devices. the requirements for ANI devices > >>> are listed above). > >> > >> I think that this should be left to other users. > > > > Rephrase ? Don't understand what this means (especially users). "other authors" ? "other docs" ? > > > > Maybe just: > > > > BRSKI does not mandate EST client certificate enrolment except for ANI devices. > > Considerations for complete solutions using Pledges that only perform Request Voucher > > and CA Certificates request, but no EST client certificate enrolment are > > outside the scope of this document / subject to future work. > > > > > >> I am going to push the -11 with these changes, and the ones from last week. > > > > Thanks! > > > > Cheers > > Toerless > > > >> I acknowledge that I still have a bunch of edits from the rest of your message. > >> > >> > >> -- > >> Michael Richardson , Sandelman Software Works > >> -= IPv6 IoT consulting =- > >> > >> > >> > > > > > > > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > -- > > --- > > tte@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Feb 20 19:00:14 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF110124D68; Tue, 20 Feb 2018 19:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 jej0vnsgLkx5; Tue, 20 Feb 2018 19:00:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E075B1204DA; Tue, 20 Feb 2018 19:00:10 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B15320091; Tue, 20 Feb 2018 22:07:30 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0BB3B80CCB; Tue, 20 Feb 2018 22:00:10 -0500 (EST) From: Michael Richardson To: Toerless Eckert cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org In-Reply-To: <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <23103.1519174480@obiwan.sandelman.ca> <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 03:00:14 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: >> "Registrar". The term JRC is used in common with other bootstrap >> mechanisms. >> >> + (Public) Key Infrastructure: The collection of systems and processes >> + that sustain the activities of a public key system. In an ANIMA >> + Autonomic system, this includes a Domain Certification Authority >> + (CA), (Join) Registrar which acts as an [RFC5280] Registrar, as >> + well as appropriate certificate revocation list (CRL) distribution >> + points and/or OCSP ([RFC6960]) servers. > I had interpreted Max'es response on the mail discussion to indicate that > MASA would also be considered to be part of the PKI. I am fine either way. > Just checking. If as you propose above it's not part of the PKI, a simple > sentence explaining why not would be great. Huh, good point/question. It might be part of the Manufacturers' PKI, but it's not part of the domain's PKI, and that's the one that we are speaking about in the title. I think that it's worth describing the manufacturer's situation at some point; I would prefer to leave to another document that explained it in terms of a BCP... "MASAOPS" or some such concepts. >> + The ANI Registrar (JRC) MUST support all the BRSKI and above listed >> + EST operations. > Can't remember conclusion on redundant terminology re. JRC vs. the other terms > used. Personal preference would be to eliminate JRC as a term, but i'll wait > for the final doc. re. minimum necessary terminology. Yes, that in the thread, where I referred to a thread back in January 2017, in which you were involved in coming up with the names. >> + , and may be >> + enabled only if the JRC indicates support for them in it's >> + announcement. (See Section 4.4) > IMHO: sentence eend after "optional". Followed by "all proxy functionally > needs to ... be enabled... > Aka: circuit proxy is a no-op too if the proxy does not discover a registrar > supporting it. Not specific to advanced options. Circuit proxy is a MTI for the JRC, and requires *NO* special support in the JRC. If the Registrar doesn't support listening on port 443, then it's not a registrar :-) >> > II) This leaves the option that EST to install trust anchor is mandatory, but >> > enrolment with a certificate is optional (except for ANI case). >> >> > Aka: would be good to write a sentence/paragraph exactly outlining what is >> > permitted to happen after a voucher and if any, what parts of EST are deemed to >> > be necessary by BRSKI (outside of ANI devices. the requirements for ANI devices >> > are listed above). >> >> I think that this should be left to other users. > Rephrase ? Don't understand what this means (especially users). "other > authors" ? "other docs" ? If someone is using BRSKI in a non-ANI situation, then that entity should explain what kinds of things can occur after voucher. So I prefer to remain mute. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqM4LkACgkQgItw+93Q 3WVMbwf/cQ2slDai8feKNs6KQTV9KeyZ9ZwFTwFPpPpgqmUEE9QnF/2xbx7f6xtM +uLrdVWwTKpidWunQaEmqWnjP+ihUTVcxgFCB3KZQDtbeXLk4FGNZE/VrZWV0r2R E4FqeygYaTO8dUz4obpIyOUhsgjYVZTfV7au4Rzt5IwwjW7BwE7tiEekuM6JYvUl Mu9j1QVI4T8tZAVq0J73FGw5c58uqpSpoGUMeEwLoqpw6LctnWCyQFcrSLoJMl7W LcgfXY2pksnPYe5kZ1Xk1V9cO8olt9qmkofkOaMucdCuphf6mLFWXuuUCLbhToDk mSIOYNLdqcS6DOG8XeQsLvfkj7fZ2Q== =9I1w -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 20 19:14:58 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CA4129502; Tue, 20 Feb 2018 19:14:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151918289630.9636.11987007927396133949@ietfa.amsl.com> Date: Tue, 20 Feb 2018 19:14:56 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-11.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 03:14:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-11.txt Pages : 83 Date : 2018-02-20 Abstract: This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-11 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 20 20:47:46 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595D112708C for ; Tue, 20 Feb 2018 20:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 4ueP5QOXXuQh for ; Tue, 20 Feb 2018 20:47:39 -0800 (PST) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C41126C22 for ; Tue, 20 Feb 2018 20:47:36 -0800 (PST) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w1L4kTM2014998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Feb 2018 10:16:35 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w1L4jFVt009084; Wed, 21 Feb 2018 10:15:15 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w1L4jCIM020930; Wed, 21 Feb 2018 10:15:12 +0530 From: "Anoop Kumar Pandey" To: "'Toerless Eckert'" Cc: "'Brian E Carpenter'" , "'Michael Richardson'" , References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> <20180220062131.GA23498@faui40p.informatik.uni-erlangen.de> <00b701d3aa31$9d13db40$d73b91c0$@cdac.in> <20180220154840.GB23498@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180220154840.GB23498@faui40p.informatik.uni-erlangen.de> Date: Wed, 21 Feb 2018 10:15:07 +0530 Message-ID: <007701d3aace$c289ec00$479dc400$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01D3AAFC.DC50F510" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE2I/joFI0/xQRcLlXQFy4X95wT3AJMjcXyAfHjFIQBMe5HLwJpWVH6AdhO8q0CvwS6tAE5icoppHvo0eA= Content-Language: en-in X-CDAC-PUNE-MailScanner-ID: w1L4jFVt009084 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.198, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.798, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w1L4kTM2014998 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 04:47:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0078_01D3AAFC.DC50F510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >the assumption in ANIMA is that the world is actually not-trusted and instead has a lot of bad things happening and the cryptographic procedures of BRSKI/ACP serve to create a "trusted domain/network" in the >face of the largely "untrusted world". As per our previous conversations: 1. We assume that in a managed network that the JRC *can* know all the legitimate manufacturers. The keys can come from sales channel integration (via digital "packing slips" perhaps), can be manually loaded by humans, be scanned from QR codes on the box, etc. - Michael Richardson 2. ANIMA is scoped to support professionally managed networks. So it seems reasonable to assume that they have procurement procedures in place to buy from known sources and not to buy kit "off the back of a lorry" to use a British idiom. - Brian Carpenter So JRS has all legitimate manufacturers and is procuring pledges from known sources (out of these legitimate manufacturers), then where is the hostility? That's what I was trying to say in my initial mail that given an unknown MI or a collaboration between pledge and MI, can security be established using Automated BRSKI? Also the pledge trusts JRC if JRC is able to pass on the voucher from MASA to pledge. MASA only checks JRC's certificate. Therefore any JRC having a valid certificate may pass on the voucher from MASA to pledge and become owner of the pledge [case of theft]. Anoop> Device need not verify me if it wants to work in my environment or not. Toer> BRSKI devices only want to work for their owner. The will of a pledge is immaterial. A device will recognize anyone as owner who enters a valid credential. In case of BRSKI, whoever passes voucher from MASA to pledge. I bought an iPhone and input my icloud credential, it will start working. Someone else gets hand on my iPhone, he will reset, put his icloud account and it will work for him. Toer>Illegal use of utility into something (physical or not) also gets classified as theft in many countries. BRSKI protects also against remotely gaining access/utility to the Pledge. Anoop> Intrusion in pledge can't be stopped using BRSKI. That depends on methods of authentication and authorization employed to access the pledge. Toer> And those methods are meant to be gated by BRSKI/EST. I believe, BRSKI is a one-time imprinting service to a domain through JRC. Once that is done, any unauthorized access (depending on the vulnerability in the pledge) post EST, may not be stopped. Or may be I am missing something. To clarify, please clear my doubt. BRSKI, is it one time process? Or during each access to device will it re-run? When do we require to re-run this, only on domain-transfer? Does it happen automatically whenever a device enters a domain or can it started deliberately? Regards, Anoop -----Original Message----- From: 'Toerless Eckert' [mailto:tte@cs.fau.de] Sent: 20 February 2018 21:19 To: Anoop Kumar Pandey Cc: 'Brian E Carpenter' ; 'Michael Richardson' ; anima@ietf.org Subject: Re: [Anima] verification of manufacturer in BRSKI On Tue, Feb 20, 2018 at 03:30:14PM +0530, Anoop Kumar Pandey wrote: > Trusted world is something like "every entity in the domain is a > trusted entity." Also in this case, trust can be derived. For example, > if a pledge is issued by a trusted/enlisted MI, then that pledge can also be trusted. > Here the trust is derived from the MI. "Trusted world" is misleading because the assumption in ANIMA is that the world is actually not-trusted and instead has a lot of bad things happening and the cryptographic procedures of BRSKI/ACP serve to create a "trusted domain/network" in the face of the largely "untrusted world". If you live in a gated community you would also not claim the world is trusted. Very similar. > Michael had mentioned in earlier mail, "JRC trusts pledge by > validating IDevID using MI certificate." and you mentioned "MASA and > Voucher are not used to verify the pledge."" > > If so, then I thought that 'JRC verifying audit log and voucher' step > is redundant. [Page 16 of RFC] It may not be required unless further > investigation into history of pledge is required. As said. MASA and Voucher are not used in BRSKI to make the Domain trust the Pledge, but that does not make them redundant. > >". If you are a buyer of large number of pledges and do not need any > >protection against theft, misassignment of pledges to other networks > >or intrusions into pledges that intend to impact your network later, > >then >sure > > - you may be happy with pledges not requiring vouchers to get enrolled." > Theft is anyway physical security breach. It may happen irrespective > of BRSKI in place. Theft is not only applied to physical security breach. Illegal use of utility into something (physical or not) also gets classified as theft in many countries. BRSKI protects also against remotely gaining access/utility to the Pledge. Physical theft too is less likely if you can not get utility: If a Pledge does not allow to circumvent secure bootstrap even with physical posession of the Pledge, then those Pledges are less likely subjects to physical theft. > Misassignment of pledge to other network can be easily detected if > pledge is not accessible in the actual network. Depending on use-case it may be expensive to detect, but in even more use cases it will be expensive to fix. > Intrusion in pledge can't be stopped using BRSKI. Yes it can. > That depends on methods of authentication and authorization employed to access the pledge. And those methods are meant to be gated by BRSKI/EST. Think of the most simple case: You will not get any configuration access to the device unless BRSKI was run, and afterwards you need to authenticate yourself on every config connection with the cert enrolled during BRSKI. > Pledge is a device. If I buy/add a device, I need to verify if it is > compromised or not or if it comes from a trusted MI. Well, we agree on one thing. > Device need not verify me if it wants to work in my environment or not. BRSKI devices only want to work for their owner. > If pledge doesn't require to validate JRC then "MASA issuing voucher > and pledge using that voucher to validate and enroll to JRC" is redundant. Probably true in the context of how BRSKI is currently written. Except that for the current charter work on BRSKI we have concluded that the pledge does need to verify the domain for all the reasons documented in BRSKI and repeated by me. And you disagree. Note though, that there can also be other benefits to MASA than "pledge only wants to work for owner", and that is "pledge wants to discover owner". Consider the typical use case of some pledge connecting to a public network, such as Internet, so the network connection has no way to point the pledge to the owner. To support this, you also need a three party system: Pledge, Manufacturer Service, Owner: Pledge can only contact some Manufacturer service, and that would "redirect" Pledge to owner after Owner hass claimed pledge from manufacturer. The BRSKI section about cloud registrar/service hints at this use-case, but i am not sure to what extend we could/should cover this in detail in BRSKI (see my review) because it does require some extension to the signaling IMHO. I would be happy too if this wasn't buried in some section of the BRSKI spec but in separate followup work that focusses on this case. > That's all from my side. I thought that this system could work in any > environment and I was trying to convince myself of the same and > ascertain that no loopholes are left so far as my understanding is concerned. Glad to hear. I thought you where wanting to keepg the biggest loophole in place (pledge will work for anybody). Cheers Toerless > Regards, > > Anoop > > > > > > > > -----Original Message----- > From: Toerless Eckert [ mailto:tte@cs.fau.de] > Sent: 20 February 2018 11:52 > To: Anoop Kumar Pandey < anoop@cdac.in> > Cc: 'Brian E Carpenter' < brian.e.carpenter@gmail.com>; 'Michael Richardson' > < mcr+ietf@sandelman.ca>; anima@ietf.org > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > Anoop, > > > > > So, basically you reduced your scope to a professionally managed network. > > > > The term 'professionally managed' is in the ANIMA charter, see > > > > < https://datatracker.ietf.org/doc/charter-ietf-anima/> > https://datatracker.ietf.org/doc/charter-ietf-anima/ > > > > It was just meant to provide a clear delineation of anima vs. Homenet > or similar networks, which are meant to operate primarily unmanaged. > > > > I think it is a vey broad scope. > > > > > Just for the sake of clarity, if it is just like a trusted world of > professionally managed network where pledges being added are from > trusted manufacturers, probably we don???t require this > cryptographically maintained long procedure of bootstrapping, since > trust is derived from the manufacturer. A trusted manufacturer gives a trusted device, that???s all. > > > > I do not know what a 'trusted world' is, we have not been using that > term in ANIMA. > > > > Do you mind to elaborate what you think is redundant in the > "cryptographically maintained long procedure" ? > > > > > Suppose we still want to go with this procedure and having our trust > > in > certificates and keys, we don???t require MASA and vouchers. By simply > verifying if the IDevID certificate has been signed by a trusted MI or > a trusted CA or root-RA should be sufficient for verifying the pledge. > > > > MASA and Voucher are not used to verify the pledge. If you think you > read that in BRSKI, please point to the text section that confused you > about this. > > > > > Pledge verifying the domain is anyway overrated. > > > > That is in the eye of the beholder. If you are a buyer of large number > of pledges and do not need any protection against theft, > misassignment of pledges to other networks or intrusions into pledges > that intend to impact your network later, then sure - you may be happy > with pledges not requiring vouchers to get enrolled. > > > > BRSKI already mentions in the appendix a range of variations mostly > with lower security. It does not cover all possible lower security > variants such as no-MASA/voucher primarily because we wanted the final > BRSKI RFC number to actually mean something wrt to security to buyers > of products claiming to support it. If everythng was optional, nothing > is really standardized. It would just be like calling a lottery a standard for Millionaires. > > > > > Besides, it can also be done by verifying the certificate of JRC > > during > enrolment. > > > > That actually is what the voucher does. Feel free to propose > alternatives. I have a hard time imagining solutions that either do > not achieve the goal, add pre-staging steps or just reinvent what the > voucher does under a different name. > > > > Cheers > > Toerless > > > > On Tue, Feb 20, 2018 at 10:29:47AM +0530, Anoop Kumar Pandey wrote: > > > ???ANIMA is scoped to support professionally managed networks. So it > > seems > reasonable to assume that they have procurement procedures in place to > buy from known sources and not to buy kit "off the back of a lorry" to > use a British idiom.??? > > > > > > > > > > > > "Again - a professionally managed network! Our goal in ANIMA is not > > to > eliminate human operators; it is to avoid them having to perform > mindless configuration tasks or write obscure scripts. So requiring > human action to resolve a security alert is completely acceptable > IMHO. In this case the device might have been installed by a service > technician thousands of kilometres away from the NOC, and if that > technician did install a device from an unknown source, this is > exactly a case where the NOC should be alerted." > > > > > > > > > > > > > > > > > > > > > But it is very limited scope. I would work on expanding the scope to > > any > network, any manufacturer-device pair. > > > > > > > > > > > > I would also like to quote/remind following lines from Section 1.3 > > [Scope > of Solution] of the RFC: > > > > > > > > > > > > ???But this solution is not exclusive to the large, it is intended > > to > scale to thousands of devices located in hostile environments, such as > ISP provided CPE devices which are drop-shipped to the end user. The > situation where an order is fulfilled from distributed warehouse from > a common stock and shipped directly to the target location at the > request of the domain owner is explicitly supported. That stock > ("SKU") could be provided to a number of potential domain owners, and > the eventual domain owner will not know a-priori which device will go to which location.??? > > > > > > > > > > > > Regards, > > > > > > Anoop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Brian Carpenter [ < mailto:becarpenter46@gmail.com> > mailto:becarpenter46@gmail.com] On Behalf Of > > > Brian E Carpenter > > > Sent: 20 February 2018 01:00 > > > To: Anoop Kumar Pandey < < mailto:anoop@cdac.in> anoop@cdac.in>; > > 'Michael > Richardson' > > > < < mailto:mcr+ietf@sandelman.ca> mcr+ietf@sandelman.ca>; > < mailto:anima@ietf.org> anima@ietf.org > > > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > > > > > > > > > On 19/02/2018 21:52, Anoop Kumar Pandey wrote: > > > > > > > Dear Author, > > > > > > > > > > > > > > I am further expanding my query and raising concern > > > over your > response. The Problem Nos. are same as in the trailing reply.: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 1: > > > > > > > Response: " We assume that in a managed network that the JRC *can* > > > know > all the legitimate manufacturers." > > > > > > > > > > > > > > > > > > > > > > > > > > > > May be!! But practically may not be possible. Manufacturers keep > > > adding > and also getting out of business. Tracking each MI is difficult. > > > > > > > > > > > > ANIMA is scoped to support professionally managed networks. So it > > seems > reasonable to assume that they have procurement procedures in place to > buy from known sources and not to buy kit "off the back of a lorry" to > use a British idiom. > > > > > > > > > > > > In other words, tracking each manufacturer is *necessary* as it is > > in fact > the origin of the trust for the BRSKI trust model. "Difficult" is not > an excuse IMHO. > > > > > > > > > > > > > > > > > > > > Response: " The keys can come from sales channel integration (via > digital "packing slips" perhaps), can be manually loaded by humans, be > scanned from QR codes on the box, etc. We believe that this is out of > scope. > > > > > > > > > > > > > > And if the JRC does see a MI that it does not know, then it can > > > ask a > human." > > > > > > > > > > > > > > > > > > > > > > > > > > > > If manual intervention is required, then it is no longer > > > ???Automated > BRSKI???. Humans can anyway observer and add/install new device. > > > > > > > > > > > > Again - a professionally managed network! Our goal in ANIMA is not > > to > eliminate human operators; it is to avoid them having to perform > mindless configuration tasks or write obscure scripts. So requiring > human action to resolve a security alert is completely acceptable > IMHO. In this case the device might have been installed by a service > technician thousands of kilometres away from the NOC, and if that > technician did install a device from an unknown source, this is > exactly a case where the NOC should be alerted. > > > > > > > > > > > > Brian > > > > > > > > > > > > > Problem 2: > > > > > > > > > > > > > > Response: The URL of the manufacturer is embedded in the IDevID > certificate (section 2.3 defines the extension). So the Pledge can't > create this lie itself, it requires collaboration with the MI to create an IDevID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I had asked the same thing. If pledge collaborates with a rouge MI > [given Problem 1 is not solved], the domain can easily be invaded. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 3: > > > > > > > Response: The pledge can only collaborate with the manufacturer > > > whose > IDevID it has. > > > > > > > > > > > > > > > > > > > > > Agreed. Then this problem reduces to Problem 2 where Pledge and MI > > > > can > > > > > > > collaborate to fool JRC > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 4: > > > > > > > > > > > > > > Response: The Pledge will only trust a voucher signed by MASA. Any > signature from a different entity will be rejected by the Pledge. So a > fake voucher is not possible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I only raised concern that there is no way to detect if MASA and > > > JRC > have collaborated to lure the pledge into a malicious domain unless > the MASA certificate and IDevID certificate have common Root Certifying authority. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Anoop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Richardson [ < < mailto:mcr+ietf@sandelman.ca> > mailto:mcr+ietf@sandelman.ca> > > > > < mailto:mcr+ietf@sandelman.ca> mailto:mcr+ietf@sandelman.ca] > > > > > > > Sent: 19 February 2018 05:57 > > > > > > > To: < < mailto:anima@ietf.org> mailto:anima@ietf.org> > < mailto:anima@ietf.org> anima@ietf.org > > > > > > > Cc: Anoop Kumar Pandey < < < mailto:anoop@cdac.in> > > > mailto:anoop@cdac.in> > < mailto:anoop@cdac.in> anoop@cdac.in> > > > > > > > Subject: verification of manufacturer in BRSKI > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > {sorry if this is a duplicate, my draft folder says it did not go > > > > out} > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop Kumar Pandey < < < < mailto:anoop@cdac.in> > > > mailto:anoop@cdac.in> > < mailto:anoop@cdac.in> mailto:anoop@cdac.in> < < mailto:anoop@cdac.in> > mailto:anoop@cdac.in> < mailto:anoop@cdac.in> anoop@cdac.in> wrote > directly to the draft authors list, and then gave me permission to > share this on the > list: > > > > > > > > > > > > > > Anoop> This is in context to the RFC detailing process of > > > > > > > enrolling a pledge to a > > > > > > > > > > > > > > Anoop> domain. The major problem with the procedure is that > > > the > > > > > > > registrar doesn???t > > > > > > > > > > > > > > Anoop> verify the manufacturer. It simply verifies the voucher > > > > and > > > > > > > enrols the > > > > > > > > > > > > > > Anoop> pledge. If pledge send a self-defined URL of > > > manufacturer > > > > > > > where provision for > > > > > > > > > > > > > > Anoop> issuing fake vouchers is in place, then the registrar > > > can > > > > > > > be fooled into > > > > > > > > > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > > > > > manufacturers > > > > > > > > > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > > > > > Additionally pledge > > > > > > > > > > > > > > Anoop> and a random manufacturer can also collaborate to do > > > the > same. > > > > > > > > > > > > > > > > > > > > > > > > > > > > You raise a number of issues. > > > > > > > > > > > > > > > > > > > > > > > > > > > > So let me name them so that we can discuss them easier, and make > > > sure > that I understand you correctly. > > > > > > > > > > > > > > Probably, we need to add some text to the Security Considerations, > > > and I > would welcome your help in crafting that text! > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > > > > > manufacturer to lure > > > > > > > > > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> How can these problems be tackled? > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that the Pledge may point at any Manufacturer (in the form > > > > of > > > > > > > a MASA) > > > > > > > > > > > > > > that it wishes to. The following identities exist: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) The Pledge's Identity (PI) in the form an IDevID certificate. > > > > > > > > > > > > > > (It signs the voucher request to the JRC, and the Client side > > > of > > > > > > > the TLS > > > > > > > > > > > > > > connection from Pledge to JRC) > > > > > > > > > > > > > > 2) The Manufacturer's Identity (MI) which signs the IDevID certificate. > > > > > > > > > > > > > > 3) The MASA Identity (MASA) which signs the voucher. > > > > > > > > > > > > > > 4) The Join Registrar (JRC) which signs the voucher request to the MASA. > > > > > > > > > > > > > > It also signs the Server side of the TLS connection from Pledge > > > to > JRC. > > > > > > > > > > > > > > 5) The Domain PKI Certificate Authority, which signs the LDevID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > (The MI might be the same as the MASA, but in general the MASA may > > > > be > > > > > > > outsourced. The Pledge SHOULD have a trusted anchor for both, but > > > > it > > > > > > > can be designed where it has a manufacturer CA which signs both > > > MASA > > > > > > > and MI certificate) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Each of these in essence represent a private key! > > > > > > > > > > > > > > I'd like start by ruling out of bounds for this discussion any > > > scenario > where the attack requires that the private key be leaked, shared or > used incorrectly. It's not that they can't happen, but rather that it > is a problem of TPMs, etc. and not protocol design. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Pledge trusts network part works by: > > > > > > > > > > > > > > a) MASA signs VOUCHER. > > > > > > > > > > > > > > b) VOUCHER lists JRC in pinned-domain-cert. > > > > > > > > > > > > > > c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. > > > > > > > > > > > > > > d) JRC can also audit (verify signatures even) the voucher really > > > > > > > comes > > > > > > > > > > > > > > from MASA, although unless there is a common CA, it may not be > > > > able > > > > > > > to > > > > > > > > > > > > > > prove MASA and MI are same entity. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The JRC trusts Pledge part works by: > > > > > > > > > > > > > > e) MI signs IDevID. > > > > > > > > > > > > > > f) Pledge uses IDevID to identify to JRC. > > > > > > > > > > > > > > g) JRC validates IDevID using MI certificate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, to translate what you said: > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 1. > > > > > > > > > > > > > > Anoop> The major problem with the procedure is that the > > > > registrar > > > > > > > doesn???t > > > > > > > > > > > > > > Anoop> verify the manufacturer. > > > > > > > > > > > > > > > > > > > > > > > > > > > > To translate, the JRC has no obvious way to verify that the "MI" > > > key > > > > > > > belongs > > > > > > > > > > > > > > to the manufacturer that they care about. > > > > > > > > > > > > > > > > > > > > > > > > > > > > You actually hit the major reason this is not a problem when you assume: > > > > > > > > > > > > > > > assuming the registrar can???t know all the manufacturers > > > > > > > exhaustively > > > > > > > > > > > > > > > > > > > > > > > > > > > > We assume that in a managed network that the JRC *can* know all > > > the > legitimate manufacturers. The keys can come from sales channel > integration (via digital "packing slips" perhaps), can be manually > loaded by humans, be scanned from QR codes on the box, etc. We > believe that this is out of scope. > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the JRC does see a MI that it does not know, then it can > > > ask a > human. > > > > > > > > > > > > > > That's one reason we made sure that failures to enroll do not > > > cause the > Pledge to never try again with that JRC. It needs to try again later, > because maybe nobody has answered the "Yes/No" Dialog on the > management station yet. > > > > > > > > > > > > > > > > > > > > > > > > > > > > And of course there is the WebPKI. We aren't saying that MI keys > > > (or > MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that > they can't be. That's not a panacea... between ComodoGate type > situations and certificates for "C1SC0" in a hard to distinguish font, > many social engineering attacks could get that "Yes" button pressed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 2. > > > > > > > > > > > > > > Anoop> If pledge send a self-defined URL of manufacturer where > > > > > > > provision for > > > > > > > > > > > > > > Anoop> issuing fake vouchers is in place, then the registrar > > > can > > > > > > > be fooled into > > > > > > > > > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > > > > > manufacturers > > > > > > > > > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The URL of the manufacturer is embedded in the IDevID certificate > > > > > > > (section > > > > > > > > > > > > > > 2.3 defines the extension). So the Pledge can't create this lie > > > itself, > it requires collaboration with the MI to create an IDevID. Such an MI > can point to any MASA it wishes, so long as that device can issue > vouchers that the Pledge can validate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > What this means is that JRC always knows the MI that created the Pledge. > > > > > > > > > > > > > > If we can solve problem 1, then it's done. > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 3. > > > > > > > > > > > > > > Anoop> Additionally pledge > > > > > > > > > > > > > > Anoop> and a random manufacturer can also collaborate to do > > > the > same. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see how this is the case. The pledge can only collaborate > > > with > the manufacturer whose IDevID it has. > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 4. > > > > > > > > > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > > > > > manufacturer to lure > > > > > > > > > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Pledge will only trust a voucher signed by MASA. > > > > > > > > > > > > > > Any signature from a different entity will be rejected by the Pledge. > > > > > > > > > > > > > > So a fake voucher is not possible. > > > > > > > > > > > > > > Any voucher created by the real MASA is, by definition, not a fake > voucher. > > > > > > > > > > > > > > Can you explain this scenario clearer? > > > > > > > > > > > > > > Or explain what text we need to change to clear up the > mis-understanding? > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > ] Never tell me the odds! | ipv6 mesh > networks [ > > > > > > > > > > > > > > ] Michael Richardson, Sandelman Software Works | network > architect [ > > > > > > > > > > > > > > ] < < < mailto:mcr@sandelman.ca> mailto:mcr@sandelman.ca> > < mailto:mcr@sandelman.ca> mailto:mcr@sandelman.ca> < > < mailto:mcr@sandelman.ca> mailto:mcr@sandelman.ca> > < mailto:mcr@sandelman.ca> mcr@sandelman.ca < < < http://www.sandelman.ca/> > http://www.sandelman.ca/> < http://www.sandelman.ca/> > http://www.sandelman.ca/> < < http://www.sandelman.ca/> > http://www.sandelman.ca/> < http://www.sandelman.ca/> > http://www.sandelman.ca/ | ruby on rails [ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Michael Richardson < < < < mailto:mcr+IETF@sandelman.ca> > mailto:mcr+IETF@sandelman.ca> > > > > < mailto:mcr+IETF@sandelman.ca> mailto:mcr+IETF@sandelman.ca> > > > > > > > < < mailto:mcr+IETF@sandelman.ca> mailto:mcr+IETF@sandelman.ca> > < mailto:mcr+IETF@sandelman.ca> mcr+IETF@sandelman.ca>, Sandelman > > > > Software Works -= IPv6 IoT > > > > > > > consulting =- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > > -- > > > > > > > --------------------------------------------------------- > > > > > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > > > > > Facebook: < < https://www.facebook.com/CDACINDIA> > https://www.facebook.com/CDACINDIA> > > > > < https://www.facebook.com/CDACINDIA> > > > https://www.facebook.com/CDACINDIA > & Twitter: @cdacindia ] > > > > > > > > > > > > > > This e-mail is for the sole use of the intended recipient(s) and > > > may > > > > > > > contain confidential and privileged information. If you are not > > > the > > > > > > > intended recipient, please contact the sender by reply e-mail and > > > > > > > destroy all copies and the original message. Any unauthorized > > > > review, > > > > > > > use, disclosure, dissemination, forwarding, printing or copying of > > > > > > > this email is strictly prohibited and appropriate legal action > > > will be > taken. > > > > > > > ------------------------------------------------------------------ > > > -- > > > > -- > > > > > > > --------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Anima mailing list > > > > > > > < < mailto:Anima@ietf.org> mailto:Anima@ietf.org> > < mailto:Anima@ietf.org> Anima@ietf.org > > > > > > > < < https://www.ietf.org/mailman/listinfo/anima> > https://www.ietf.org/mailman/listinfo/anima> > > > > < https://www.ietf.org/mailman/listinfo/anima> > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > -- > > > --------------------------------------------------------- > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > Facebook: < https://www.facebook.com/CDACINDIA> > https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > > > > > This e-mail is for the sole use of the intended recipient(s) and may > > > contain confidential and privileged information. If you are not the > > > intended recipient, please contact the sender by reply e-mail and > > > destroy all copies and the original message. Any unauthorized > > review, > > > use, disclosure, dissemination, forwarding, printing or copying of > > > this email is strictly prohibited and appropriate legal action will > > be > taken. > > > -------------------------------------------------------------------- > > -- > > > --------------------------------------------------------- > > > > > > > > _______________________________________________ > > > Anima mailing list > > > < mailto:Anima@ietf.org> Anima@ietf.org > > > < https://www.ietf.org/mailman/listinfo/anima> > https://www.ietf.org/mailman/listinfo/anima > > > > > > -- > > --- > > < mailto:tte@cs.fau.de> tte@cs.fau.de > > > ---------------------------------------------------------------------- > --------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and > destroy all copies and the original message. Any unauthorized review, > use, disclosure, dissemination, forwarding, printing or copying of > this email is strictly prohibited and appropriate legal action will be taken. > ---------------------------------------------------------------------- > --------------------------------------------------------- > -- --- tte@cs.fau.de ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- ------=_NextPart_000_0078_01D3AAFC.DC50F510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>the assumption in ANIMA is that the world is actually not-trusted and = instead has a lot of bad things happening and the cryptographic procedures = of BRSKI/ACP serve to create a "trusted domain/network" in the &g= t;face of the largely "untrusted world".

 

As per o= ur previous conversations:
1. We assume that in a managed network that = the JRC *can* know all the legitimate manufacturers.  The keys can com= e from sales channel integration (via digital "packing slips" per= haps), can be manually loaded by humans, be scanned from QR codes on the bo= x, etc.   – Michael Richardson

2. ANIMA is scoped to support professionally managed netwo= rks. So it seems reasonable to assume that they have procurement procedures= in place to buy from known sources and not to buy kit "off the back o= f a lorry" to use a British idiom. – Brian Carpenter

 

So JRS has all legitimate manufacturers and is procuring pledges= from known sources (out of these legitimate manufacturers), then where is = the hostility?

 

<= p class=3DMsoPlainText>That’s what I was trying to say in my initial = mail that given an unknown MI or a collaboration between pledge and MI, can= security be established using Automated BRSKI?

Also the pledge trus= ts JRC if JRC is able to pass on the voucher from MASA to pledge. MASA only= checks JRC’s certificate. Therefore any JRC having a valid certifica= te may pass on the voucher from MASA to pledge and become owner of the pled= ge [case of theft].

&nb= sp;

Anoop> Device need not verify me= if it wants to work in my environment or not.

Toer> BRSKI devices only want to work for their owner= .

 

The will of a pledge is immaterial. A device will recognize= anyone as owner who enters a valid credential. In case of BRSKI, whoever p= asses voucher from MASA to pledge.

I = bought an iPhone and input my icloud credential, it will start working. Som= eone else gets hand on my iPhone, he will reset, put his icloud account and= it will work for him.

=  

Toer>Illegal use of utilit= y into something (physical or not) also gets classified as theft in many co= untries. BRSKI protects also against remotely gaining access/utility to the= Pledge.

 

Anoop> Intrusion in pledge = can't be stopped using BRSKI. That depends on methods of authentication and= authorization employed to access the pledge.

Toer> And those methods are meant to be gated by = BRSKI/EST.

 =

I believe, BRSKI is a one-time imprinting servi= ce to a domain through JRC. Once that is done, any unauthorized access (dep= ending on the vulnerability in the pledge) post EST, may not be stopped.

Or may be I am missing something. To c= larify, please clear my doubt.

&= nbsp;

BRSKI, is it one time process? =

Or during each access to device will it r= e-run?

When do we require to re-run = this, only on domain-transfer?

Does = it happen automatically whenever a device enters a domain or can it started= deliberately?

 

<= p class=3DMsoPlainText> 

Regards= ,

Anoop

 

-----Original Message-----
From: 'Toe= rless Eckert' [mailto:tte@cs.fau.de]
Sent: 20 February 2018 21:19
To= : Anoop Kumar Pandey <anoop@cdac.in>
Cc: 'Brian E Carpenter' <b= rian.e.carpenter@gmail.com>; 'Michael Richardson' <mcr+ietf@sandelman= .ca>; anima@ietf.org
Subject: Re: [Anima] verification of manufacture= r in BRSKI

 

On Tue, Feb 20, 2018 at 03:30:14PM +0530, Anoop Kumar Pande= y wrote:

> Trusted world is someth= ing like "every entity in the domain is a

> trusted entity." Also in this case, trust can be deriv= ed. For example,

> if a pledge is= issued by a trusted/enlisted MI, then that pledge can also be trusted.

> Here the trust is derived from the = MI.

 

"Trusted world" is misleading because the assumption = in ANIMA is that the world is actually not-trusted and instead has a lot of= bad things happening and the cryptographic procedures of BRSKI/ACP serve t= o create a "trusted domain/network"

in the face of the largely "untrusted world".=

 

If= you live in a gated community you would also not claim the world is truste= d.

Very similar.

 

> Michael= had mentioned in earlier mail, "JRC  trusts pledge by

> validating IDevID using MI certificate.&q= uot;  and you mentioned "MASA and

> Voucher are not used to verify the pledge.""

>

= > If so, then I thought that 'JRC verifying audit log and voucher' step =

> is redundant. [Page 16 of RFC] = It may not be required unless further

> investigation into history of pledge is required.

 

As said. M= ASA and Voucher are not used in BRSKI to make the Domain trust the Pledge, = but that does not make them redundant.

 

> >". If you are = a buyer of large number of pledges and do not need any 

> >protection against theft,  misassign= ment of pledges to other networks

&g= t; >or  intrusions into pledges that intend to impact your network = later,

> >then >sure

> > - you may be happy with pledges n= ot requiring vouchers to get enrolled."

 

> Theft is anyway p= hysical security breach. It may happen irrespective

> of BRSKI in place.

 

Theft is not only applied t= o physical security breach. Illegal use of utility into something (physical= or not) also gets classified as theft in many countries. BRSKI protects al= so against remotely gaining access/utility to the Pledge.

 

Physical = theft too is less likely if you can not get utility:

If a Pledge does not allow to circumvent secure bootstrap e= ven with physical posession of the Pledge, then those Pledges are less like= ly subjects to physical theft.

&= nbsp;

> Misassignment of pledge to othe= r network can be easily detected if

= > pledge is not accessible in the actual network.

 

Depending on u= se-case it may be expensive to detect, but in even more use cases it will b= e expensive to fix.

 =

> Intrusion in pledge can't be stopped using= BRSKI.

 

Yes it can.

&nbs= p;

> That depends on methods of authent= ication and authorization employed to access the pledge.

 

And those = methods are meant to be gated by BRSKI/EST.

 

Think of the most simpl= e case:  You will not get any configuration access to the device unles= s BRSKI was run, and afterwards you need to authenticate yourself on every = config connection with the cert enrolled during BRSKI.

 

> Pledge = is a device. If I buy/add a device, I need to verify if it is

> compromised or not or if it comes from a tru= sted MI.

 

Well, we agree on one thing.

 

> Device need not= verify me if it wants to work in my environment or not.

 

BRSKI devi= ces only want to work for their owner.

 

> If pledge doesn't requi= re to validate JRC  then "MASA issuing voucher

> and pledge using that voucher to validate and enr= oll to JRC" is redundant.

&= nbsp;

Probably true in the context of how = BRSKI is currently written. Except that for the current charter work on BRS= KI we have concluded that the pledge does need to verify the domain for all= the reasons documented in BRSKI and repeated by me.

And you disagree.

 

Note though, that there can also = be other benefits to MASA than "pledge only wants to work for owner&qu= ot;, and that is "pledge wants to discover owner".

=

 

Consid= er the typical use case of some pledge connecting to a public network, such= as Internet, so the network connection has no way to point the pledge to t= he owner. To support this, you also need a three party system: <= /p>

Pledge, Manufacturer Service, Owner: Pledge can = only contact some Manufacturer service, and that would "redirect"= Pledge to owner after Owner hass claimed pledge from manufacturer.

 

The BRSKI section about cloud registrar/service hints at this use-case, bu= t i am not sure to what extend we could/should cover this in detail in BRSK= I (see my review) because it does require some extension to the signaling I= MHO. I would be happy too if this wasn't buried in some section of the BRSK= I spec but in separate followup work that focusses on this case.

 

&= gt; That's all from my side. I thought that this system could work in any <= o:p>

> environment and I was trying to = convince myself of the same and

>= ascertain that no loopholes are left so far as my understanding is concern= ed.

 

Glad to hear. I thought you where wanting to keepg the biggest = loophole in place (pledge will work for anybody).

 

Cheers=

    Toerless

 

> Regard= s,

>

> Anoop

> =

> 

>

> 

>

> = ;

>

> -----Original Message-----

> From: Toerless Eckert [mailto:tte@cs.fau.de]

> Sent: 20 February 2018 11:52<= o:p>

> To: Anoop Kumar Pandey <anoop@cdac.in>

&= gt; Cc: 'Brian E Carpenter' <brian.e.carpenter= @gmail.com>; 'Michael Richardson'

> <mcr+ietf@sandelman.ca>= ;; anima@ietf.org

> Subject: Re: [Anima] verification of manufacturer in BRSKI

>

> 

>

> Anoop,

> =

> 

>

> > So, b= asically you reduced your scope to a professionally managed network.

>

> 

>

> The term 'professionally managed' is in the ANIMA = charter, see

>

> 

> =

>  <https://datatracker.ietf.org/doc/charter-ietf-anima/= >

> https://datatracker.ietf.org/doc/charter-ietf-a= nima/

>

=

> 

&= gt;

> It was just meant to provid= e a clear delineation of anima vs. Homenet

> or similar networks, which are meant to operate primarily unman= aged.

>

> 

>

> I think it is a vey broad scope.<= /o:p>

>

> 

>

> > Just for the sake of clarity, if it is just = like a trusted world of

> professi= onally managed network where pledges being added are from

> trusted manufacturers, probably we don???t requi= re this

> cryptographically maint= ained long procedure of bootstrapping, since

> trust is derived from the manufacturer. A trusted manufacture= r gives a trusted device, that???s all.

>

> 

>

> I do= not know what a 'trusted world' is, we have not been using that

> term in ANIMA.

>

> 

>

= > Do you mind to elaborate what you think is redundant in the

> "cryptographically maintained long p= rocedure" ?

>

=

> 

&= gt;

> > Suppose we still want = to go with this procedure and having our trust

> > in

> certific= ates and keys, we don???t require MASA and vouchers. By simply <= /p>

> verifying if the IDevID certificate has bee= n signed by a trusted MI or

> a t= rusted CA or root-RA should be sufficient for verifying the pledge.

>

= > 

>

> MASA and Voucher are not used to verify the pledge.= If you think you

> read that in = BRSKI, please point to the text section that confused you

> about this.

>

> 

>

> > = Pledge verifying the domain is anyway overrated.

>

> 

>

= > That is in the eye of the beholder. If you are a buyer of large number=

> of pledges and do not need any= protection against theft, 

>= ; misassignment of pledges to other networks or intrusions into pledges

> that intend to impact your network= later, then sure - you may be happy

> with pledges not requiring vouchers to get enrolled.

>

> = ;

>

> BRSKI already mentions in the appendix a range of variations= mostly

> with lower security. It= does not cover all possible lower security

> variants such as no-MASA/voucher primarily because we wanted t= he final

> BRSKI RFC number to ac= tually mean something wrt to security to buyers

> of products claiming to support it. If everythng was optio= nal, nothing

> is really standard= ized. It would just be like calling a lottery a standard for Millionaires.<= o:p>

>

> 

>

> > Besides, it can also be done by verifyi= ng the certificate of JRC

> > = during

> enrolment.

=

>

>&nb= sp;

>

> That actually is what the voucher does. Feel free to propo= se

> alternatives. I have a hard = time imagining solutions that either do

> not achieve the goal, add pre-staging steps or just reinvent what = the

> voucher does under a differ= ent name.

>

> 

>

> Cheers

>

>  &nbs= p;  Toerless

>

> 

= >

> On Tue, Feb 20, 2018 at 10= :29:47AM +0530, Anoop Kumar Pandey wrote:

>

> > ???ANIMA is scop= ed to support professionally managed networks. So it

> > seems

>= reasonable to assume that they have procurement procedures in place to

> buy from known sources and not to = buy kit "off the back of a lorry" to

> use a British idiom.???

>

> >

>

> >&= nbsp;

>

> >

> =

> > "Again - a professionally = managed network! Our goal in ANIMA is not

> > to

> eliminate hum= an operators; it is to avoid them having to perform

> mindless configuration tasks or write obscure scripts.= So requiring

> human action to r= esolve a security alert is completely acceptable

> IMHO. In this case the device might have been installed b= y a service

> technician thousand= s of kilometres away from the NOC, and if that

> technician did install a device from an unknown source, thi= s is

> exactly a case where the N= OC should be alerted."

>

> >

>

> >  <= /o:p>

>

> >

>

> >

> <= o:p>

> > 

>

> >

>

> > But it is very limited scope. I would work on expanding the = scope to

> > any

> network, any manufacturer-device pair. <= /o:p>

>

> >

>

> > 

= >

> >

>

> > I w= ould also like to quote/remind following lines from Section 1.3 =

> > [Scope

> of Solution] of the RFC:

>

> >

>

> >&n= bsp;

>

> >

>

> > ???But this solution is not exclus= ive to the large, it is intended

>= ; > to

> scale to thousands of = devices located in hostile environments, such as

> ISP provided CPE devices which are drop-shipped to the en= d user.  The

> situation whe= re an order is fulfilled from distributed warehouse from

> a common stock and shipped directly to the target= location at the

> request of the= domain owner is explicitly supported.  That stock

> ("SKU") could be provided to a number of= potential domain owners, and

> t= he eventual domain owner will not know a-priori which device will go to whi= ch location.???

>

<= p class=3DMsoPlainText>> >

>= ;

> > 

>

> > =

>

> > Regards,

> =

> >

>

> > Anoop

>

= > >

>

> > 

&g= t;

> >

>

> > =

>

> >

> <= /p>

> > 

>

> >

>

> &= gt; 

>

> >

>

> > -----Original Message-----

>

> > From: Brian Carpenter [ <mailto:bec= arpenter46@gmail.com>

&= gt; mailto:becarpenter46@gmail.com] On Beh= alf Of

>

> > Brian E Carpenter

>

> > Sent: 20 Febru= ary 2018 01:00

>

> > To: Anoop Kumar Pandey < <mailto:anoop@cdac.in> anoop@cdac.in&g= t;;

> > 'Michael

> Richardson'

>

> > < <mailto:mcr+ietf@sandelman.ca> mcr+ietf@sandelman.ca>;

> <mailto:anima@ietf.org> anima@ietf.org

> =

> > Subject: Re: [Anima] verificati= on of manufacturer in BRSKI

>

> >

>

> >  <= /o:p>

>

> >

>

> > On 19/02/2018 21:52, Anoop Kumar Pandey wrote= :

>

> >

> <= /p>

> > > Dear Author,

>

> >

>

> > >

> =

> >

>

> > >  &nb= sp;         I am further expanding = my query and raising concern

> &g= t; > over your

> response. The = Problem Nos. are same as in the trailing reply.:

>

> >

>

&= gt; > >

>

> >

>=

> > > 

>

> &= gt;

>

> > >

>

> >

>

> > > Problem= 1:

>

> >

>

> > > Response: " We assume tha= t in a managed network that the JRC *can*

> > > know

> all th= e legitimate manufacturers."

>= ;

> >

>

> > > =

>

> >

>

> > >

>

> >

<= p class=3DMsoPlainText>>

> >= ; >

>

> >

> =

> > > May be!! But practically m= ay not be possible. Manufacturers keep

> > > adding

> and als= o getting out of business. Tracking each MI is difficult.

>

> > =

>

> > 

>

> >

>

> > ANIMA is scoped= to support professionally managed networks. So it

> > seems

> = reasonable to assume that they have procurement procedures in place to

> buy from known sources and not to b= uy kit "off the back of a lorry" to

> use a British idiom.

&= gt;

> >

>

> > = ;

>

> >

> =

> > In other words, tracking each manufac= turer is *necessary* as it is

> &= gt; in fact

> the origin of the tr= ust for the BRSKI trust model. "Difficult" is not

=

> an excuse IMHO.

>

> >

>

> = > 

>

> >

>

> > >

>

> > =

>

> > > Response: " The keys can come from sales channel int= egration (via

> digital "pack= ing slips" perhaps), can be manually loaded by humans, be <= /p>

> scanned from QR codes on the box, etc. = ; We believe that this is out of

>= ; scope.

>

> >

> =

> > >

>

> >

>

= > > > And if the JRC does see a MI that it does not know, then it = can

> > > ask a<= /p>

> human."

>

> >

>

> = > >

>

> >

>

> > > 

>

> > =

>

> > >

>

> >

>

> > > If manual i= ntervention is required, then it is no longer

> > > ???Automated

> BRSKI???. Humans can anyway observer and add/install new device.=

>

> >

>

> > 

>

> >

>

> > Ag= ain - a professionally managed network! Our goal in ANIMA is not

> > to

> eliminate human operators; it is to avoid them having to perform =

> mindless configuration tasks or= write obscure scripts. So requiring

> human action to resolve a security alert is completely acceptable

> IMHO. In this case the device migh= t have been installed by a service

&= gt; technician thousands of kilometres away from the NOC, and if that =

> technician did install a device from= an unknown source, this is

> exa= ctly a case where the NOC should be alerted.

>

> >

>

> = > 

>

> >

>

> >     Bria= n

>

> >

> <= /p>

> > 

>

> >

>

> &= gt; > Problem 2:

> =

> >

>

> > >

>

> &= gt;

>

> > > Response: The URL of the manufacturer is embedde= d in the IDevID

> certificate (sec= tion 2.3 defines the extension).  So the Pledge can't

<= p class=3DMsoPlainText>> create this lie itself, it requires collaborati= on with the MI to create an IDevID.

&= gt;

> >

>

> > >=

>

> >

> <= /p>

> > >

>

> >

=

>

> &g= t; >

>

> >

> =

> > > I had asked the same thing= . If pledge collaborates with a rouge MI

> [given Problem 1 is not solved], the domain can easily be invaded.=

>

> >

>

> > >

>

> >

<= p class=3DMsoPlainText>>

> >= ; > 

>

> >

> =

> > >

>

> >

>

> > > Problem 3:

> =

> >

>

> > > Res= ponse: The pledge can only collaborate with the manufacturer

> > > whose

> IDevID it has.

>

> >

>

> > > <= /o:p>

>

> >

>

> > >

&= gt;

> >

>

> > >= Agreed. Then this problem reduces to Problem 2 where Pledge and MI

>

= > > > can

>

> >

= >

> > > collaborate to f= ool JRC

>

> >

> =

> > >

>

> >

>

= > > > 

>

> >

>

> > >

>

> = >

>

> > > Problem 4:

>

> >

>

> > = >

>

> >

>

> > > Response: The Pledge will onl= y trust a voucher signed by MASA. Any

> signature from a different entity will be rejected by the Pledge. So = a

> fake voucher is not possible.=

>

> >

>

> > >

>

> >

<= p class=3DMsoPlainText>>

> >= ; > 

>

> >

> =

> > >

>

> >

>

> > > I only raised concern that there is no way to detect if= MASA and

> > > JRC

> have collaborated to lure the pledge in= to a malicious domain unless

> th= e MASA certificate and IDevID certificate have common Root Certifying autho= rity.

>

> >

>

> > >

>

> > =

>

>= ; > > 

>

> >

= >

> > >

<= p class=3DMsoPlainText>>

> >= ;

>

> > > Regards,

>= ;

> >

>

> > > =

>

> >

>

> > > Anoop

>

> > =

>

>= ; > >

>

> >

> <= o:p>

> > > 

<= p class=3DMsoPlainText>>

> >= ;

>

> > >

> <= /o:p>

> >

>

> > > 

>

> >

>

<= p class=3DMsoPlainText>> > >

>

> >

>

> > &= gt; -----Original Message-----

> <= o:p>

> >

>

> > > From= : Michael Richardson [ < <mailto:mcr+ietf@sandelm= an.ca>

> mailto:mcr+ietf@sandelman.ca>

>

> > >&= nbsp; <mailto:mcr+ietf@sandelman.ca> <= a href=3D"mailto:mcr+ietf@sandelman.ca">mailto:mcr+ietf@sandelman.ca]

<= p class=3DMsoPlainText>>

> >= ;

>

> > > Sent: 19 February 2018 05:57

>

> >

>

> > > To:  < <mailto:anima@ietf.org> mailto:anima@ietf.org>

> <mailto:anima@ietf.org> anima@ietf.org

>

> >

>

&= gt; > > Cc: Anoop Kumar Pandey < < <mailto:anoop= @cdac.in>

> > &g= t; mailto:anoop@cdac.in>

> <mailto:anoop@cdac.in> anoop@cdac.in>

>

> >

>

> > &= gt; Subject: verification of manufacturer in BRSKI

>

> > =

>

> > >

>

> >

= >

> > > 

>

&g= t; >

>

> > >

> =

> >

>

> > >&nbs= p;

>

> >

>

> > >

>

> >

>

> = > > {sorry if this is a duplicate, my draft folder says it did not go=

>

> > > out}

>

> >

>

> > >

>

> >

>

> > > 

>

> >

>

> >= >

>

> >

> =

> > > Anoop Kumar Pandey < &l= t; < <mailto:anoop@cdac.in>

=

> > > mailto:anoop@cdac.in>

> <mail= to:anoop@cdac.in> mailto:anoop@cdac.in= >  < <mailto:anoop@cdac.in>

> mailto:anoop@cdac.in>  <mailto:anoop@cdac.in> anoop@cdac.in> wrote

> directly to the draft authors list, and then gave me permission to=

> share this on the

> list:

= >

> >

>

> > >= ;

>

> >

> =

> > >     Anoop>= ; This is in context to the RFC detailing process of

>

> > =

>

> > > enrolling a pledge to a

>

> >

<= p class=3DMsoPlainText>>

> >= ; >

>

> >

> =

> > >     An= oop> domain. The major problem with the procedure is that

> > > the

>

> >

>

> &= gt; > registrar doesn???t

>

> >

>

> > > <= /o:p>

>

> >

>

> > >     Anoop> verify= the manufacturer. It simply verifies the voucher

>

> > > and=

>

> >

>

> > > enrols the

>

> > =

>

> > >

>

> >

= >

> > >   = ;  Anoop> pledge. If pledge send a self-defined URL of <= /p>

> > > manufacturer

>

> >

>

> > > where provision for

>

> >

>

> > = >

>

> >

>

> > >     Anoop= > issuing fake vouchers is in place, then the registrar

<= p class=3DMsoPlainText>> > > can

>

> >

<= p class=3DMsoPlainText>>

> >= ; > be fooled into

>

> >

>

> > >

>

> = >

>

> > >     Anoop> enrolment [as= suming the registrar can???t know all the

>

> >

<= p class=3DMsoPlainText>>

> >= ; > manufacturers

> =

> >

>

> > >

>

> &= gt;

>

> > >     Anoop> exhaustively] = and later exploited from inside the domain.

>

> >

>

> = > > Additionally pledge

>

> >

>

> > > =

>

> >

>

> > >     Anoop> and a= random manufacturer can also collaborate to do

> > > the

> s= ame.

>

> >

>

> > >

>

> > <= /p>

>

>= > > 

>

> >

&= gt;

> > >

>

> >=

>

> > > You raise a number of issues.

>

> >

>

> > >

> <= /p>

> >

>

> > > 

>

&= gt; >

>

> > >

>=

> >

>

> > > = So let me name them so that we can discuss them easier, and make

> > > sure

> that I understand you correctly.

>

> >

>

= > > >

>

<= p class=3DMsoPlainText>> >

>= ;

> > > Probably, we need t= o add some text to the Security Considerations,

> > > and I

>= would welcome your help in crafting that text!

>

> >

>

&g= t; > >

>

> >

> =

> > > 

=

>

> &g= t;

>

> > >

> =

> >

>

> > > &nb= sp;   Anoop> In the similar way a registrar may collaborate wi= th the

>

> >

> =

> > > manufacturer to lure<= /o:p>

>

> >

>

> > >

&= gt;

> >

>

> > >=      Anoop> a device using fake voucher.<= /p>

>

>= >

>

> > >

> =

> >

>

> > >&nbs= p;

>

> >

>

> > >

>

> >

>

> = > >     Anoop> How can these problems be tackl= ed?

>

> >

>

> > >

>

> >

>

> = > > 

>

=

> >

&g= t;

> > >

>

> > =

>

> > > I agree that the Pledge may point at any Manufacture= r (in the form

>

> > > of

>

> >

>

> > = > a MASA)

>

> >

> <= o:p>

> > >

>

> >

>

> > > that it wishes to.   The following identities = exist:

>

> >

> =

> > >

>

> >

>

= > > > 

>

> >

>

> > >

>

> = >

>

> > > 1) The Pledge's Identity (PI) in the form an ID= evID certificate.

>

> >

&= gt;

> > >

>

> >=

>

> > >    (It signs the voucher request to = the JRC, and the Client side

> &g= t; > of

>

> >

>

> > > the TLS

>

> >=

>

> > >

>

> >

>

> > >  = ;  connection from Pledge to JRC)

>

> >

>

> > &= gt;

>

> >

>

> > > 2) The Manufacturer's Identity= (MI) which signs the IDevID certificate.

>

> >

<= p class=3DMsoPlainText>>

> >= ; >

>

> >

> =

> > > 3) The MASA Identity (MASA= ) which signs the voucher.

> =

> >

>

> > >

>

= > >

>

> > > 4) The Join Registrar (JRC) which signs th= e voucher request to the MASA.

> <= o:p>

> >

>

> > >

>

> >

>

> > >    It also signs the Se= rver side of the TLS connection from Pledge

> > > to

> JRC.

>

> >

>

=

> > >

>

> >

>

> > = > 5) The Domain PKI Certificate Authority, which signs the LDevID.<= /o:p>

>

> >

>

> > >

&= gt;

> >

>

> > >=  

>

> >

> =

> > >

>

> >

>

= > > > (The MI might be the same as the MASA, but in general the MA= SA may

>

> > > be

>= ;

> >

>

> > > = outsourced.  The Pledge SHOULD have a trusted anchor for both, but

>

> > > it

>

> >

>

> > > can be design= ed where it has a manufacturer CA which signs both

> > > MASA

&= gt;

> >

>

> > >= and MI certificate)

> =

> >

>

> > >

>

> &= gt;

>

> > > 

>= ;

> >

>

> > > =

>

> >

>

> > > Each of these in essence represent= a private key!

>

<= p class=3DMsoPlainText>> >

>= ;

> > >

>

> > <= o:p>

>

> > > I'd like start by ruling out of bounds for this discu= ssion any

> > > scenario

> where the attack requires that the= private key be leaked, shared or

&g= t; used incorrectly.  It's not that they can't happen, but rather that= it

> is a problem of TPMs, etc. = and not protocol design.

>

> >

>

> > >

>

&g= t; >

>

> > > 

>

> >

>

> > &g= t;

>

> >

>

> > > The Pledge trusts network part = works by:

>

> >

>

> > >

>

> > =

>

> > > a) MASA signs VOUCHER.

>

> >

>

> >= >

>

> >

> =

> > > b) VOUCHER lists JRC in pi= nned-domain-cert.

>

> >

&= gt;

> > >

>

> >=

>

> > > c) Pledge uses MASA to validate VOUCHER, and theref= ore validates JRC.

>

> >

= >

> > >

<= p class=3DMsoPlainText>>

> >= ;

>

> > > d) JRC can also audit (verify signatures even) the= voucher really

>

<= p class=3DMsoPlainText>> >

>= ;

> > > comes

>

> &= gt;

>

> > >

>

> >

>

> > > &n= bsp;  from MASA, although unless there is a common CA, it may not be

>

> > > able

> <= /o:p>

> >

>

> > > to

>

> >

>

> > >

&g= t;

> >

>

> > >&= nbsp;   prove MASA and MI are same entity.

>

> > =

>

> > >

>

> >

= >

> > > 

>

&g= t; >

>

> > >

> =

> >

>

> > > The= JRC trusts Pledge part works by:

>= ;

> >

>

> > > =

>

> >

>

> > > e) MI signs IDevID.

=

>

> &g= t;

>

> > >

> =

> >

>

> > > f) Pledg= e uses IDevID to identify to JRC.

>= ;

> >

>

> > > =

>

> >

>

> > > g) JRC validates IDevID using MI c= ertificate.

>

> >

>

> > >

>

> > =

>

> > > 

>

> >

>

> > >

>

&g= t; >

>

> > > Now, to translate what you said:<= /p>

>

>= >

>

> > >

> =

> >

>

> > >&nbs= p;

>

> >

>

> > >

>

> >

>

> = > > problem 1.

> =

> >

>

> > >

>

> &= gt;

>

> > >     Anoop> The major prob= lem with the procedure is that the

&g= t;

> > > registrar

>

&= gt; >

>

> > > doesn???t

>

> >

<= p class=3DMsoPlainText>>

> >= ; >

>

> >

> =

> > >     An= oop> verify the manufacturer.

>=

> >

>

> > > =

>

> >

>

> > > 

>

> >

>

&g= t; > >

>

> >

> =

> > > To translate, the JRC= has no obvious way to verify that the "MI"

> > > key

= >

> >

>

> > >= ; belongs

>

> >

>

> > >

>

> > =

>

> > >         &nbs= p;     to the manufacturer that they care about.

>

> >

>

> > >

&g= t;

> >

>

> > >&= nbsp;

>

> >

> =

> > >

>

> >

>

= > > > You actually hit the major reason this is not a problem when= you assume:

>

> >

> <= o:p>

> > >

>

> >

>

> > >    > assuming the registrar can???t kn= ow all the manufacturers

>

> >

>

> > > exhaustive= ly

>

> >

> =

> > >

>

> >

>

> &= gt; > 

>

<= p class=3DMsoPlainText>> >

>= ;

> > >

>

> > <= o:p>

>

> > > We assume that in a managed network that the JRC *can= * know all

> > > the

> legitimate manufacturers.  The ke= ys can come from sales channel

> = integration (via digital "packing slips" perhaps), can be manuall= y

> loaded by humans, be scanned = from QR codes on the box, etc.  We

> believe that this is out of scope.

>

> >

>

> &= gt; >

>

> >

>

> > > 

>

> > <= o:p>

>

> > >

>

> >

>

> > > And if the J= RC does see a MI that it does not know, then it can

> > > ask a

= > human.

>

> >

>

> > >

>

> > =

>

> > > That's one reason we made sure that failures to enroll do= not

> > > cause the

> Pledge to never try again with that JR= C.  It needs to try again later,

> because maybe nobody has answered the "Yes/No" Dialog on t= he

> management station yet.=

>

> >

>

> > >

= >

> >

>

> > >= ; 

>

> >

> =

> > >

>

> >

>

= > > > And of course there is the WebPKI.  We aren't saying th= at MI keys

> > > (or

> MASA server TLS keys) MUST be in the W= ebPKI, but we aren't saying that

>= ; they can't be.  That's not a panacea... between ComodoGate type

> situations and certificates for &qu= ot;C1SC0" in a hard to distinguish font,

> many social engineering attacks could get that "Yes&quo= t; button pressed.

>

> >

= >

> > >

<= p class=3DMsoPlainText>>

> >= ;

>

> > > 

> =

> >

>

> > >

>

> >

>

<= p class=3DMsoPlainText>> > > 

>

> >

>

> = > >

>

> >

>

> > > problem 2.

>

> &= gt;

>

> > >

>

> >

>

> > > &n= bsp;   Anoop> If pledge send a self-defined URL of manufacture= r where

>

> >

> =

> > > provision for

>

> = >

>

> > >

>

> >

>

> > > &= nbsp;   Anoop> issuing fake vouchers is in place, then the reg= istrar

> > > can=

>

>= ; >

>

> > > be fooled into

>

> > <= /p>

>

>= > >

>

> >

>

> > >    = Anoop> enrolment [assuming the registrar can???t know all the

>

&g= t; >

>

> > > manufacturers

>

> >

>

> = > >

>

> >

>

> > >     = Anoop> exhaustively] and later exploited from inside the domain.

>

= > >

>

> > >

>= ;

> >

>

> > >&= nbsp;

>

> >

> =

> > >

>

> >

>

= > > > The URL of the manufacturer is embedded in the IDevID certif= icate

>

> >

>

> > > (section

>

> >

>

> > >

> =

> >

>

> > > 2.3 defines th= e extension).  So the Pledge can't create this lie

> > > itself,

> it requires collaboration with the MI to create an IDevID. = Such an MI

> can point to any MA= SA it wishes, so long as that device can issue

> vouchers that the Pledge can validate.

>

> >

>

> > >

> =

> >

>

> > > 

>

= > >

>

> > >

>= ;

> >

>

> > > = What this means is that JRC always knows the MI that created the Pledge.

>

> >

>

<= p class=3DMsoPlainText>> > >

>

> >

>

> > &= gt; If we can solve problem 1, then it's done.

>

> > =

>

>= ; > >

>

> >

> <= o:p>

> > > 

<= p class=3DMsoPlainText>>

> >= ;

>

> > >

> <= /o:p>

> >

>

> > > problem 3= .

>

> >

> <= /p>

> > >

>

> >

=

>

> &g= t; >     Anoop> Additionally pledge

>

> &= gt;

>

> > >

>

> >

>

> > > &n= bsp;   Anoop> and a random manufacturer can also collaborate t= o do

> > > the

> same.

= >

> >

>

> > >= ;

>

> >

> =

> > > 

>

> >

>

= > > >

>

<= p class=3DMsoPlainText>> >

>= ;

> > > I don't see how thi= s is the case.  The pledge can only collaborate

> > > with

= > the manufacturer whose IDevID it has.

>

> >

=

>

> &g= t; >

>

> >

> =

> > > 

>

> >

>

> > >

>

> >

>

> > > problem 4.

>

> >

>

<= p class=3DMsoPlainText>> > >

>

> >

>

> > &= gt;     Anoop> In the similar way a registrar may co= llaborate with the

>

> >

= >

> > > manufacturer to = lure

>

> >

>

> > >

>

> > <= /p>

>

>= > >     Anoop> a device using fake voucher.

>

> >

>

=

> > >

>

> >

>

> > = > 

>

> >

>

> > >

>

> > =

>

> > > The Pledge will only trust a voucher signed by MASA.=

>

> >

>

> > >

= >

> >

>

> > >= ; Any signature from a different entity will be rejected by the Pledge.

>

> >

>

> > >

>

> >

>

> > &g= t; So a fake voucher is not possible.

>

> >

>

> > &g= t;

>

> >

>

> > > Any voucher created by the real= MASA is, by definition, not a fake

&= gt; voucher.

>

> >

> <= o:p>

> > >

>

> >

>

> > > Can you explain this scenario clearer?

>

> > =

>

> > >

>

> >

>

> > > Or explain = what text we need to change to clear up the

> mis-understanding?

> <= o:p>

> >

>

> > >

>

> >

>

> > > 

>

> >

>

> &= gt; >

>

> >

>

> > > --

>

> > =

>

> > >

>

> >

= >

> > > ]  &nb= sp;            Never= tell me the odds!         &nb= sp;       | ipv6 mesh

> networks [

> =

> >

>

> > >

>

> >

>

<= p class=3DMsoPlainText>> > > ]   Michael Richardson, San= delman Software Works        | network

> architect  [

<= p class=3DMsoPlainText>>

> >= ;

>

> > >

> <= /o:p>

> >

>

> > > ] &n= bsp;    < < <mailto:mcr@sandelman.ca= > mailto:mcr@sandelman.ca><= /o:p>

> <mailto:mcr@sandelm= an.ca> mailto:mcr@sandelman.ca>&= nbsp; <

> <m= ailto:mcr@sandelman.ca> <= span style=3D'color:windowtext;text-decoration:none'>mailto:mcr@sandelman.c= a>

> <mailto:mcr@sandelman.ca> mcr@sandelman.ca<= /span>   < < <<= span style=3D'color:windowtext;text-decoration:none'>http://www.sandelman.c= a/>

> http://www.sandelman.ca/>  <http://= www.sandelman.ca/>

>= ; http://www.sandelman.ca/>  < <http://www.sandelman.ca/>

> http://www.sandelman.ca/&= gt;  <http://www.sandelman.ca/><= /o:p>

> = http://www.sandelman.= ca/        |   ruby= on rails    [

>

> >

>

> > > =

>

> >

>

> > > 

>

> >

=

>

> &g= t; >

>

> >

> =

> > > 

>

> >

>

> > >

>

> >

>

> > > --=

>

>= ; >

>

> > >

> =

> >

>

> > > Mic= hael Richardson < < < <mailto:mcr+IETF@sand= elman.ca>

> mailto:mcr+IETF@sandelman.ca>

>

> > &= gt;  <mailto:mcr+IETF@sandelman.ca&g= t; mailto:mcr+IETF@sandelman.ca>

>

&= gt; >

>

> > >  < <mailto:m= cr+IETF@sandelman.ca> mailto:mcr+IETF@san= delman.ca>

> <mailto:mcr+IETF@sandelman.ca> mcr+IETF@sandelman.ca>, Sandelman

>

> > >= Software Works  -=3D IPv6 IoT

&= gt;

> >

>

> > >= consulting =3D-

>

=

> >

&g= t;

> > >

>

> > =

>

> > > 

>

> >

>

> > > =

>

> >

>

> > > 

>

> >

=

>

> &g= t; >

>

> >

> =

> > > 

>

> >

>

> > >

>

> >

>

> > >

>

> = >

>

> > > -----------------------------------------------= -------------------

> > > --=

>

> > > --

> <= /o:p>

> >

>

> > > ---------= ------------------------------------------------

>

> >

>

&= gt; > > [ C-DAC is on Social-Media too. Kindly follow us at:

>

&= gt; >

>

> > > Facebook:  < <https://www.facebook.com/CDACINDIA>

> https://www.facebook.co= m/CDACINDIA>

> =

> > >  <https://www.facebook.com/CDACINDIA>

=

> > > https://ww= w.facebook.com/CDACINDIA

&= gt; & Twitter: @cdacindia ]

> =

> >

>

> > >

>

> >

>

<= p class=3DMsoPlainText>> > > This e-mail is for the sole use of th= e intended recipient(s) and

> >= ; > may

>

> >

>

> > > contain confidential and= privileged information. If you are not

> > > the

>

> >

>

> > > intended rec= ipient, please contact the sender by reply e-mail and

>

> >

>

> > > destroy all copies and the original message. Any unautho= rized

>

> > > review,

&= gt;

> >

>

> > >= use, disclosure, dissemination, forwarding, printing or copying of

>

= > >

>

> > > this email is strictly prohibited and appr= opriate legal action

> > > = will be

> taken.

>

> > =

>

> > > ----------------------------------------------------= --------------

> > > --=

>

> > > --

> =

> >

>

> > > --------------= -------------------------------------------

>

> >

>

> &= gt; >

>

> >

>

> > >

>

> > =

>

> > >

>

> >

= >

> > >

<= p class=3DMsoPlainText>>

> >= ;

>

> > > _______________________________________________

>

> >

>

<= p class=3DMsoPlainText>> > > Anima mailing list

>

> > <= o:p>

>

> > >  < <mailto:Anima@ietf.org> mailto:Anima@ietf.org>

> <mailto:Anima@ietf.org= > Anima@ietf.org

>

> >

>

&g= t; > >  < <https://www.= ietf.org/mailman/listinfo/anima>

> https://www.ietf.org/mail= man/listinfo/anima>

>= ;

> > >  <https://www.ietf.org/mailman/listinfo/anima>

> https://www.ietf.org/mailman/listinfo/anima<= /o:p>

>

> >

>

> > >

&= gt;

> >

>

> > = ;

>

> >

> =

> > 

>

> >

>

> = >

>

> > ----------------------------------------------------= ----------------

> > --

>

= > > ---------------------------------------------------------

>

= > > [ C-DAC is on Social-Media too. Kindly follow us at:

>

> = > Facebook:  <https://www.facebook.com= /CDACINDIA>

> https://www.facebook.com/CDACINDIA & Twi= tter: @cdacindia ]

>

> >

= >

> > This e-mail is for th= e sole use of the intended recipient(s) and may

>

> > contain co= nfidential and privileged information. If you are not the

>

> > = intended recipient, please contact the sender by reply e-mail and

>

&g= t; > destroy all copies and the original message. Any unauthorized =

> > review,

>

> > use, = disclosure, dissemination, forwarding, printing or copying of

>

> &= gt; this email is strictly prohibited and appropriate legal action will

> > be

> taken.

>

> > ----------------------------------= ----------------------------------

&g= t; > --

>

> > -----------------------------------------------= ----------

>

> >

>

> 

>

> > __________= _____________________________________

>

> > Anima mailing list

>

> >  <mailto:Anima@ietf.org>= Anima@ietf.org

>

> >  <https://www.ietf.org/mailman/listinfo/anima>

> https://www.ietf.org/mailman/listinfo/anima<= /o:p>

>

> 

>

> 

>=

> --

>

> ---<= /p>

>

>=   <mailto:tte@cs.fau.de> tte@= cs.fau.de

> =

>

>= ; ----------------------------------------------------------------------

> ----------------------------------= -----------------------

> [ C-DAC = is on Social-Media too. Kindly follow us at:

> Facebook: https://www.facebook.com/C= DACINDIA & Twitter: @cdacindia ]

>

> This e-mail is = for the sole use of the intended recipient(s) and may

> contain confidential and privileged information. If = you are not the

> intended recipi= ent, please contact the sender by reply e-mail and

> destroy all copies and the original message. Any unaut= horized review,

> use, disclosure= , dissemination, forwarding, printing or copying of

> this email is strictly prohibited and appropriate lega= l action will be taken.

> --------= --------------------------------------------------------------

> --------------------------------------------= -------------

>

 

--

---

<= a href=3D"mailto:tte@cs.fau.de">tte@cs.fau.de


-------------= ---------------------------------------------------------------------------= ---------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= ---------------------------------------------------------- ------=_NextPart_000_0078_01D3AAFC.DC50F510-- From nobody Wed Feb 21 07:15:38 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7366912D7E5; Wed, 21 Feb 2018 07:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 GVA-RfVQKvt6; Wed, 21 Feb 2018 07:15:34 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E7C1270AB; Wed, 21 Feb 2018 07:15:34 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9B4FE58C51A; Wed, 21 Feb 2018 16:15:29 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7FA0AB0DB17; Wed, 21 Feb 2018 16:15:29 +0100 (CET) Date: Wed, 21 Feb 2018 16:15:29 +0100 From: Toerless Eckert To: Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org Message-ID: <20180221151529.GF23498@faui40p.informatik.uni-erlangen.de> References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <23103.1519174480@obiwan.sandelman.ca> <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> <22048.1519182010@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22048.1519182010@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:15:36 -0000 On Tue, Feb 20, 2018 at 10:00:10PM -0500, Michael Richardson wrote: > > Yes, that in the thread, where I referred to a thread back in January 2017, > in which you were involved in coming up with the names. > > >> + , and may be > >> + enabled only if the JRC indicates support for them in it's > >> + announcement. (See Section 4.4) > > > IMHO: sentence eend after "optional". Followed by "all proxy functionally > > needs to ... be enabled... > > > Aka: circuit proxy is a no-op too if the proxy does not discover a registrar > > supporting it. Not specific to advanced options. > > Circuit proxy is a MTI for the JRC, and requires *NO* special support in the JRC. > If the Registrar doesn't support listening on port 443, then it's not a registrar :-) Maybe i just have an english language problems: "may (be only enabled) if" implies to me "could also (be enabled) even if not", but that would not be correct: No version of a proxy can be enabled unless a registrar has been discovered by the proxy AND that proxy is announcing support for the proxy method. And that applies to all proxy methods. correct language: "can be only enabled if" ? ^^^ If i misunderstand english: what is the difference between may/can in this sentence ? circuit-proxy is only MTI for ANI registrars, these sentences are not constrained to ANI. I would assume in some derived solutions like 6tisch or the like, registrar may only have non-circuit proxies.. ?! Sorry if this is too much nitpicking. > > Rephrase ? Don't understand what this means (especially users). "other > > authors" ? "other docs" ? > > If someone is using BRSKI in a non-ANI situation, then that entity should > explain what kinds of things can occur after voucher. So I prefer to remain mute. ah! "user" = "author of followup work". Thanks! Toerles > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > From nobody Wed Feb 21 10:12:23 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80449126DED for ; Wed, 21 Feb 2018 10:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 4v-095ifQaYb for ; Wed, 21 Feb 2018 10:12:16 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496801205F0 for ; Wed, 21 Feb 2018 10:12:16 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3A56958C574; Wed, 21 Feb 2018 19:12:10 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1CC67B0DB1A; Wed, 21 Feb 2018 19:12:09 +0100 (CET) Date: Wed, 21 Feb 2018 19:12:09 +0100 From: 'Toerless Eckert' To: Anoop Kumar Pandey Cc: 'Brian E Carpenter' , 'Michael Richardson' , anima@ietf.org Message-ID: <20180221181209.GG23498@faui40p.informatik.uni-erlangen.de> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> <20180220062131.GA23498@faui40p.informatik.uni-erlangen.de> <00b701d3aa31$9d13db40$d73b91c0$@cdac.in> <20180220154840.GB23498@faui40p.informatik.uni-erlangen.de> <007701d3aace$c289ec00$479dc400$@cdac.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007701d3aace$c289ec00$479dc400$@cdac.in> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 18:12:21 -0000 Inline On Wed, Feb 21, 2018 at 10:15:07AM +0530, Anoop Kumar Pandey wrote: > >the assumption in ANIMA is that the world is actually not-trusted and > instead has a lot of bad things happening and the cryptographic procedures > of BRSKI/ACP serve to create a "trusted domain/network" in the >face of the > largely "untrusted world". > > > > As per our previous conversations: > 1. We assume that in a managed network that the JRC *can* know all the > legitimate manufacturers. The keys can come from sales channel integration > (via digital "packing slips" perhaps), can be manually loaded by humans, be > scanned from QR codes on the box, etc. - Michael Richardson > > 2. ANIMA is scoped to support professionally managed networks. So it seems > reasonable to assume that they have procurement procedures in place to buy > from known sources and not to buy kit "off the back of a lorry" to use a > British idiom. - Brian Carpenter > > > > So JRS has all legitimate manufacturers and is procuring pledges from known > sources (out of these legitimate manufacturers), then where is the > hostility? Well, given how Brian mentioned it: One example is literally buying off the back of a lorry and have IDevID/MASA be able to help know that this was a legitimate refurbisher of old equipment as opposed to the idiomatic thief Brian is referring to. But the prime purpose of BRSKI/Voucher/MASA is really all those man-in-the-middle attacks. E.g: attacker trying to look like proxy/registrar to pledge and/or pledge to proxy/registrar. Remember how the core purpose of ANIMA/BRSKI is to enable zero-touch, pre-staging free deployment of pledges - anywhere on a network. Today, pretty much all pre-existing bootstrap mechanisms require you to have trusted physical connections in a pre-staging location and humans checking Pledge devices are what they claim to be to be able to have a legitimate pledge bootstrapped and secured. Just look at the security you get (none) if instead you take an average pledge and connects it to some network. They can be remotely recognized, and be overtaken from remote with default passwords. Think of the voucher as just a password given to the owner by the MASA so it can log into the pledge, but men-in-the-middle can't. That's the core of BRSKI. Not really that difficult a concept. Then we added IDevID for owners to verify pledges, a dash of TLS and PKI plus a dollop of EST to it to make it cryptosec compliant, proxy to make it easier to deploy and less attackable, and MASA logs to simplify sales channels. So the overall BRSKI recipe is a bit more involved. > That's what I was trying to say in my initial mail that given an unknown MI > or a collaboration between pledge and MI, can security be established using > Automated BRSKI? s/collaboration/collusion/ ?! Without BRSKI, an evil Pledge with evil software from an evil manufacturer that you the owner trusts can do all sort of evil things in the network. Before and after BRSKI. BRSKI does not help against this but will just be subject to attacks from such an evil trusted pledge like any other protocol the pledge may later run to attack the network. A Plegde with IDevID will more likely have also secure boot and/or other security measures that in a court of law could be used as indications that the evil software was really from the evil manufacturer instead of a third party attacker. But thats really only correlated with BRSKI but otherwise has nothing to do with it. But see Ken Thomspons Hack of 1984 (thanks Hesham). With BRSKI compliant pledges, the MI is never really unknown because the IDevID points to it. It just may not yet be trusted by the owner. But we already declared on this thread that the means to make owners trusts MI is outside the scope of BRSKI. And i gave examples on this thread of how IMHO this could nicely be done by PKI'ification of control institution that could make statements about the trustworthyness of manufacturer via certificates. And maybe actually do it better than with WebPKI, where you can't trust those certification organizations. > Also the pledge trusts JRC if JRC is able to pass on the voucher from MASA > to pledge. MASA only checks JRC's certificate. MASA may require proximity of Pledge to Registrar, in which case it would know that Registrar is actually connected to Pledge. > Therefore any JRC having a valid certificate may pass on the voucher > from MASA to pledge and become owner of the pledge [case of theft]. See above. > Anoop> Device need not verify me if it wants to work in my environment or > not. > > Toer> BRSKI devices only want to work for their owner. > > The will of a pledge is immaterial. Sure. Like our discussion here. But that does not make it irrelevant. Did you mean irrelevant ? > A device will recognize anyone as owner who enters a valid credential. > In case of BRSKI, whoever passes voucher from MASA to pledge. Right. Which is BRSKIs way to express ownership. Which is what the pledge checks so it will only work for its owner. > I bought an iPhone and input my icloud credential, it will start working. > Someone else gets hand on my iPhone, he will reset, put his icloud account > and it will work for him. Then you go to the police and report your phone / serial number stolen, the police gets the icloud account information from Apple to support finding and prosecuting the thief. I don't have an iPhone. Is it mandatory to use an iCloud account to activate a reset iPhone ? How easy is it to create an untraceable iCloud account ? Similar considerations would apply to operationalizing BRSKI/MASA interactions when you do sales integreation. If you want to use MASA log to protect against theft, you better have traceable identities for the owners. > Toer>Illegal use of utility into something (physical or not) also gets > classified as theft in many countries. BRSKI protects also against remotely > gaining access/utility to the Pledge. > > Anoop> Intrusion in pledge can't be stopped using BRSKI. That depends on > methods of authentication and authorization employed to access the pledge. > > Toer> And those methods are meant to be gated by BRSKI/EST. > > I believe, BRSKI is a one-time imprinting service to a domain through JRC. > Once that is done, any unauthorized access (depending on the vulnerability > in the pledge) post EST, may not be stopped. True, but you need the BRSKI/voucher mechanism before EST/config. Just like a default password. > BRSKI, is it one time process? If you're always loosing your pledges like your iPhones... ;-) > Or during each access to device will it re-run? In general once after you bought/installed. But think for example about valid cases for factory reset of devices without owner change. Typical in large organizations when devices are re-deployed into different locations/purposes. BRSKI aware factory resets should IMHO have an option for reset everything except voucher installed trust-anchors to avoid having to redo BRSKI. > When do we require to re-run this, only on domain-transfer? I think the doc says unoconfigured pledge. So after a reset, see example above. In a more flexible implementation it might simply be triggered by the absence of the BRSKI result config, eg: configured trust-anchor and potentially EST enrolled cert. > Does it happen automatically whenever a device enters a domain or can it > started deliberately? see above. Cheers Toerless > Regards, > > Anoop > > > > -----Original Message----- > From: 'Toerless Eckert' [mailto:tte@cs.fau.de] > Sent: 20 February 2018 21:19 > To: Anoop Kumar Pandey > Cc: 'Brian E Carpenter' ; 'Michael Richardson' > ; anima@ietf.org > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > On Tue, Feb 20, 2018 at 03:30:14PM +0530, Anoop Kumar Pandey wrote: > > > Trusted world is something like "every entity in the domain is a > > > trusted entity." Also in this case, trust can be derived. For example, > > > if a pledge is issued by a trusted/enlisted MI, then that pledge can also > be trusted. > > > Here the trust is derived from the MI. > > > > "Trusted world" is misleading because the assumption in ANIMA is that the > world is actually not-trusted and instead has a lot of bad things happening > and the cryptographic procedures of BRSKI/ACP serve to create a "trusted > domain/network" > > in the face of the largely "untrusted world". > > > > If you live in a gated community you would also not claim the world is > trusted. > > Very similar. > > > > > Michael had mentioned in earlier mail, "JRC trusts pledge by > > > validating IDevID using MI certificate." and you mentioned "MASA and > > > Voucher are not used to verify the pledge."" > > > > > > If so, then I thought that 'JRC verifying audit log and voucher' step > > > is redundant. [Page 16 of RFC] It may not be required unless further > > > investigation into history of pledge is required. > > > > As said. MASA and Voucher are not used in BRSKI to make the Domain trust the > Pledge, but that does not make them redundant. > > > > > >". If you are a buyer of large number of pledges and do not need any > > > >protection against theft, misassignment of pledges to other networks > > > >or intrusions into pledges that intend to impact your network later, > > > >then >sure > > > > - you may be happy with pledges not requiring vouchers to get enrolled." > > > > > Theft is anyway physical security breach. It may happen irrespective > > > of BRSKI in place. > > > > Theft is not only applied to physical security breach. Illegal use of > utility into something (physical or not) also gets classified as theft in > many countries. BRSKI protects also against remotely gaining access/utility > to the Pledge. > > > > Physical theft too is less likely if you can not get utility: > > If a Pledge does not allow to circumvent secure bootstrap even with physical > posession of the Pledge, then those Pledges are less likely subjects to > physical theft. > > > > > Misassignment of pledge to other network can be easily detected if > > > pledge is not accessible in the actual network. > > > > Depending on use-case it may be expensive to detect, but in even more use > cases it will be expensive to fix. > > > > > Intrusion in pledge can't be stopped using BRSKI. > > > > Yes it can. > > > > > That depends on methods of authentication and authorization employed to > access the pledge. > > > > And those methods are meant to be gated by BRSKI/EST. > > > > Think of the most simple case: You will not get any configuration access to > the device unless BRSKI was run, and afterwards you need to authenticate > yourself on every config connection with the cert enrolled during BRSKI. > > > > > Pledge is a device. If I buy/add a device, I need to verify if it is > > > compromised or not or if it comes from a trusted MI. > > > > Well, we agree on one thing. > > > > > Device need not verify me if it wants to work in my environment or not. > > > > BRSKI devices only want to work for their owner. > > > > > If pledge doesn't require to validate JRC then "MASA issuing voucher > > > and pledge using that voucher to validate and enroll to JRC" is redundant. > > > > Probably true in the context of how BRSKI is currently written. Except that > for the current charter work on BRSKI we have concluded that the pledge does > need to verify the domain for all the reasons documented in BRSKI and > repeated by me. > > And you disagree. > > > > Note though, that there can also be other benefits to MASA than "pledge only > wants to work for owner", and that is "pledge wants to discover owner". > > > > Consider the typical use case of some pledge connecting to a public network, > such as Internet, so the network connection has no way to point the pledge > to the owner. To support this, you also need a three party system: > > Pledge, Manufacturer Service, Owner: Pledge can only contact some > Manufacturer service, and that would "redirect" Pledge to owner after Owner > hass claimed pledge from manufacturer. > > > > The BRSKI section about cloud registrar/service hints at this use-case, but > i am not sure to what extend we could/should cover this in detail in BRSKI > (see my review) because it does require some extension to the signaling > IMHO. I would be happy too if this wasn't buried in some section of the > BRSKI spec but in separate followup work that focusses on this case. > > > > > That's all from my side. I thought that this system could work in any > > > environment and I was trying to convince myself of the same and > > > ascertain that no loopholes are left so far as my understanding is > concerned. > > > > Glad to hear. I thought you where wanting to keepg the biggest loophole in > place (pledge will work for anybody). > > > > Cheers > > Toerless > > > > > Regards, > > > > > > Anoop > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Toerless Eckert [ mailto:tte@cs.fau.de] > > > Sent: 20 February 2018 11:52 > > > To: Anoop Kumar Pandey < anoop@cdac.in> > > > Cc: 'Brian E Carpenter' < > brian.e.carpenter@gmail.com>; 'Michael Richardson' > > > < mcr+ietf@sandelman.ca>; > anima@ietf.org > > > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > > > > > > > > > Anoop, > > > > > > > > > > > > > So, basically you reduced your scope to a professionally managed > network. > > > > > > > > > > > > The term 'professionally managed' is in the ANIMA charter, see > > > > > > > > > > > > < > https://datatracker.ietf.org/doc/charter-ietf-anima/> > > > > https://datatracker.ietf.org/doc/charter-ietf-anima/ > > > > > > > > > > > > It was just meant to provide a clear delineation of anima vs. Homenet > > > or similar networks, which are meant to operate primarily unmanaged. > > > > > > > > > > > > I think it is a vey broad scope. > > > > > > > > > > > > > Just for the sake of clarity, if it is just like a trusted world of > > > professionally managed network where pledges being added are from > > > trusted manufacturers, probably we don???t require this > > > cryptographically maintained long procedure of bootstrapping, since > > > trust is derived from the manufacturer. A trusted manufacturer gives a > trusted device, that???s all. > > > > > > > > > > > > I do not know what a 'trusted world' is, we have not been using that > > > term in ANIMA. > > > > > > > > > > > > Do you mind to elaborate what you think is redundant in the > > > "cryptographically maintained long procedure" ? > > > > > > > > > > > > > Suppose we still want to go with this procedure and having our trust > > > > in > > > certificates and keys, we don???t require MASA and vouchers. By simply > > > verifying if the IDevID certificate has been signed by a trusted MI or > > > a trusted CA or root-RA should be sufficient for verifying the pledge. > > > > > > > > > > > > MASA and Voucher are not used to verify the pledge. If you think you > > > read that in BRSKI, please point to the text section that confused you > > > about this. > > > > > > > > > > > > > Pledge verifying the domain is anyway overrated. > > > > > > > > > > > > That is in the eye of the beholder. If you are a buyer of large number > > > of pledges and do not need any protection against theft, > > > misassignment of pledges to other networks or intrusions into pledges > > > that intend to impact your network later, then sure - you may be happy > > > with pledges not requiring vouchers to get enrolled. > > > > > > > > > > > > BRSKI already mentions in the appendix a range of variations mostly > > > with lower security. It does not cover all possible lower security > > > variants such as no-MASA/voucher primarily because we wanted the final > > > BRSKI RFC number to actually mean something wrt to security to buyers > > > of products claiming to support it. If everythng was optional, nothing > > > is really standardized. It would just be like calling a lottery a standard > for Millionaires. > > > > > > > > > > > > > Besides, it can also be done by verifying the certificate of JRC > > > > during > > > enrolment. > > > > > > > > > > > > That actually is what the voucher does. Feel free to propose > > > alternatives. I have a hard time imagining solutions that either do > > > not achieve the goal, add pre-staging steps or just reinvent what the > > > voucher does under a different name. > > > > > > > > > > > > Cheers > > > > > > Toerless > > > > > > > > > > > > On Tue, Feb 20, 2018 at 10:29:47AM +0530, Anoop Kumar Pandey wrote: > > > > > > > ???ANIMA is scoped to support professionally managed networks. So it > > > > seems > > > reasonable to assume that they have procurement procedures in place to > > > buy from known sources and not to buy kit "off the back of a lorry" to > > > use a British idiom.??? > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Again - a professionally managed network! Our goal in ANIMA is not > > > > to > > > eliminate human operators; it is to avoid them having to perform > > > mindless configuration tasks or write obscure scripts. So requiring > > > human action to resolve a security alert is completely acceptable > > > IMHO. In this case the device might have been installed by a service > > > technician thousands of kilometres away from the NOC, and if that > > > technician did install a device from an unknown source, this is > > > exactly a case where the NOC should be alerted." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But it is very limited scope. I would work on expanding the scope to > > > > any > > > network, any manufacturer-device pair. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would also like to quote/remind following lines from Section 1.3 > > > > [Scope > > > of Solution] of the RFC: > > > > > > > > > > > > > > > > > > > > > > > > > > > > ???But this solution is not exclusive to the large, it is intended > > > > to > > > scale to thousands of devices located in hostile environments, such as > > > ISP provided CPE devices which are drop-shipped to the end user. The > > > situation where an order is fulfilled from distributed warehouse from > > > a common stock and shipped directly to the target location at the > > > request of the domain owner is explicitly supported. That stock > > > ("SKU") could be provided to a number of potential domain owners, and > > > the eventual domain owner will not know a-priori which device will go to > which location.??? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Anoop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Carpenter [ < > mailto:becarpenter46@gmail.com> > > > mailto:becarpenter46@gmail.com] On > Behalf Of > > > > > > > Brian E Carpenter > > > > > > > Sent: 20 February 2018 01:00 > > > > > > > To: Anoop Kumar Pandey < < mailto:anoop@cdac.in> > anoop@cdac.in>; > > > > 'Michael > > > Richardson' > > > > > > > < < mailto:mcr+ietf@sandelman.ca> > mcr+ietf@sandelman.ca>; > > > < mailto:anima@ietf.org> > anima@ietf.org > > > > > > > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 19/02/2018 21:52, Anoop Kumar Pandey wrote: > > > > > > > > > > > > > > > Dear Author, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am further expanding my query and raising concern > > > > > over your > > > response. The Problem Nos. are same as in the trailing reply.: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 1: > > > > > > > > > > > > > > > Response: " We assume that in a managed network that the JRC *can* > > > > > know > > > all the legitimate manufacturers." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > May be!! But practically may not be possible. Manufacturers keep > > > > > adding > > > and also getting out of business. Tracking each MI is difficult. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ANIMA is scoped to support professionally managed networks. So it > > > > seems > > > reasonable to assume that they have procurement procedures in place to > > > buy from known sources and not to buy kit "off the back of a lorry" to > > > use a British idiom. > > > > > > > > > > > > > > > > > > > > > > > > > > > > In other words, tracking each manufacturer is *necessary* as it is > > > > in fact > > > the origin of the trust for the BRSKI trust model. "Difficult" is not > > > an excuse IMHO. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Response: " The keys can come from sales channel integration (via > > > digital "packing slips" perhaps), can be manually loaded by humans, be > > > scanned from QR codes on the box, etc. We believe that this is out of > > > scope. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the JRC does see a MI that it does not know, then it can > > > > > ask a > > > human." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If manual intervention is required, then it is no longer > > > > > ???Automated > > > BRSKI???. Humans can anyway observer and add/install new device. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Again - a professionally managed network! Our goal in ANIMA is not > > > > to > > > eliminate human operators; it is to avoid them having to perform > > > mindless configuration tasks or write obscure scripts. So requiring > > > human action to resolve a security alert is completely acceptable > > > IMHO. In this case the device might have been installed by a service > > > technician thousands of kilometres away from the NOC, and if that > > > technician did install a device from an unknown source, this is > > > exactly a case where the NOC should be alerted. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 2: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Response: The URL of the manufacturer is embedded in the IDevID > > > certificate (section 2.3 defines the extension). So the Pledge can't > > > create this lie itself, it requires collaboration with the MI to create an > IDevID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I had asked the same thing. If pledge collaborates with a rouge MI > > > [given Problem 1 is not solved], the domain can easily be invaded. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 3: > > > > > > > > > > > > > > > Response: The pledge can only collaborate with the manufacturer > > > > > whose > > > IDevID it has. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Agreed. Then this problem reduces to Problem 2 where Pledge and MI > > > > > > > > can > > > > > > > > > > > > > > > collaborate to fool JRC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem 4: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Response: The Pledge will only trust a voucher signed by MASA. Any > > > signature from a different entity will be rejected by the Pledge. So a > > > fake voucher is not possible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I only raised concern that there is no way to detect if MASA and > > > > > JRC > > > have collaborated to lure the pledge into a malicious domain unless > > > the MASA certificate and IDevID certificate have common Root Certifying > authority. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Michael Richardson [ < < > mailto:mcr+ietf@sandelman.ca> > > > mailto:mcr+ietf@sandelman.ca> > > > > > > > > < mailto:mcr+ietf@sandelman.ca> > mailto:mcr+ietf@sandelman.ca] > > > > > > > > > > > > > > > Sent: 19 February 2018 05:57 > > > > > > > > > > > > > > > To: < < mailto:anima@ietf.org> > mailto:anima@ietf.org> > > > < mailto:anima@ietf.org> > anima@ietf.org > > > > > > > > > > > > > > > Cc: Anoop Kumar Pandey < < < > mailto:anoop@cdac.in> > > > > > mailto:anoop@cdac.in> > > > < mailto:anoop@cdac.in> > anoop@cdac.in> > > > > > > > > > > > > > > > Subject: verification of manufacturer in BRSKI > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > {sorry if this is a duplicate, my draft folder says it did not go > > > > > > > > out} > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop Kumar Pandey < < < < > mailto:anoop@cdac.in> > > > > > mailto:anoop@cdac.in> > > > < mailto:anoop@cdac.in> > mailto:anoop@cdac.in> < < mailto:anoop@cdac.in> > > > mailto:anoop@cdac.in> < > mailto:anoop@cdac.in> anoop@cdac.in> wrote > > > directly to the draft authors list, and then gave me permission to > > > share this on the > > > list: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> This is in context to the RFC detailing process of > > > > > > > > > > > > > > > enrolling a pledge to a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> domain. The major problem with the procedure is that > > > > > the > > > > > > > > > > > > > > > registrar doesn???t > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> verify the manufacturer. It simply verifies the voucher > > > > > > > > and > > > > > > > > > > > > > > > enrols the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> pledge. If pledge send a self-defined URL of > > > > > manufacturer > > > > > > > > > > > > > > > where provision for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> issuing fake vouchers is in place, then the registrar > > > > > can > > > > > > > > > > > > > > > be fooled into > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > > > > > > > > > > > > > manufacturers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > > > > > > > > > > > > > Additionally pledge > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> and a random manufacturer can also collaborate to do > > > > > the > > > same. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You raise a number of issues. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So let me name them so that we can discuss them easier, and make > > > > > sure > > > that I understand you correctly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Probably, we need to add some text to the Security Considerations, > > > > > and I > > > would welcome your help in crafting that text! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > > > > > > > > > > > > > manufacturer to lure > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> How can these problems be tackled? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that the Pledge may point at any Manufacturer (in the form > > > > > > > > of > > > > > > > > > > > > > > > a MASA) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > that it wishes to. The following identities exist: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) The Pledge's Identity (PI) in the form an IDevID certificate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (It signs the voucher request to the JRC, and the Client side > > > > > of > > > > > > > > > > > > > > > the TLS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > connection from Pledge to JRC) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) The Manufacturer's Identity (MI) which signs the IDevID > certificate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3) The MASA Identity (MASA) which signs the voucher. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4) The Join Registrar (JRC) which signs the voucher request to the > MASA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It also signs the Server side of the TLS connection from Pledge > > > > > to > > > JRC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5) The Domain PKI Certificate Authority, which signs the LDevID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (The MI might be the same as the MASA, but in general the MASA may > > > > > > > > be > > > > > > > > > > > > > > > outsourced. The Pledge SHOULD have a trusted anchor for both, but > > > > > > > > it > > > > > > > > > > > > > > > can be designed where it has a manufacturer CA which signs both > > > > > MASA > > > > > > > > > > > > > > > and MI certificate) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Each of these in essence represent a private key! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like start by ruling out of bounds for this discussion any > > > > > scenario > > > where the attack requires that the private key be leaked, shared or > > > used incorrectly. It's not that they can't happen, but rather that it > > > is a problem of TPMs, etc. and not protocol design. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Pledge trusts network part works by: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > a) MASA signs VOUCHER. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > b) VOUCHER lists JRC in pinned-domain-cert. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > d) JRC can also audit (verify signatures even) the voucher really > > > > > > > > > > > > > > > comes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > from MASA, although unless there is a common CA, it may not be > > > > > > > > able > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > prove MASA and MI are same entity. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The JRC trusts Pledge part works by: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > e) MI signs IDevID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > f) Pledge uses IDevID to identify to JRC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > g) JRC validates IDevID using MI certificate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, to translate what you said: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> The major problem with the procedure is that the > > > > > > > > registrar > > > > > > > > > > > > > > > doesn???t > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> verify the manufacturer. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To translate, the JRC has no obvious way to verify that the "MI" > > > > > key > > > > > > > > > > > > > > > belongs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to the manufacturer that they care about. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You actually hit the major reason this is not a problem when you > assume: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > assuming the registrar can???t know all the manufacturers > > > > > > > > > > > > > > > exhaustively > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We assume that in a managed network that the JRC *can* know all > > > > > the > > > legitimate manufacturers. The keys can come from sales channel > > > integration (via digital "packing slips" perhaps), can be manually > > > loaded by humans, be scanned from QR codes on the box, etc. We > > > believe that this is out of scope. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the JRC does see a MI that it does not know, then it can > > > > > ask a > > > human. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That's one reason we made sure that failures to enroll do not > > > > > cause the > > > Pledge to never try again with that JRC. It needs to try again later, > > > because maybe nobody has answered the "Yes/No" Dialog on the > > > management station yet. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And of course there is the WebPKI. We aren't saying that MI keys > > > > > (or > > > MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that > > > they can't be. That's not a panacea... between ComodoGate type > > > situations and certificates for "C1SC0" in a hard to distinguish font, > > > many social engineering attacks could get that "Yes" button pressed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 2. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> If pledge send a self-defined URL of manufacturer where > > > > > > > > > > > > > > > provision for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> issuing fake vouchers is in place, then the registrar > > > > > can > > > > > > > > > > > > > > > be fooled into > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> enrolment [assuming the registrar can???t know all the > > > > > > > > > > > > > > > manufacturers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> exhaustively] and later exploited from inside the domain. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The URL of the manufacturer is embedded in the IDevID certificate > > > > > > > > > > > > > > > (section > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.3 defines the extension). So the Pledge can't create this lie > > > > > itself, > > > it requires collaboration with the MI to create an IDevID. Such an MI > > > can point to any MASA it wishes, so long as that device can issue > > > vouchers that the Pledge can validate. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What this means is that JRC always knows the MI that created the > Pledge. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If we can solve problem 1, then it's done. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> Additionally pledge > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> and a random manufacturer can also collaborate to do > > > > > the > > > same. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see how this is the case. The pledge can only collaborate > > > > > with > > > the manufacturer whose IDevID it has. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > problem 4. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> In the similar way a registrar may collaborate with the > > > > > > > > > > > > > > > manufacturer to lure > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anoop> a device using fake voucher. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Pledge will only trust a voucher signed by MASA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any signature from a different entity will be rejected by the Pledge. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So a fake voucher is not possible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any voucher created by the real MASA is, by definition, not a fake > > > voucher. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can you explain this scenario clearer? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or explain what text we need to change to clear up the > > > mis-understanding? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ] Never tell me the odds! | ipv6 mesh > > > networks [ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ] Michael Richardson, Sandelman Software Works | network > > > architect [ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ] < < < mailto:mcr@sandelman.ca> > mailto:mcr@sandelman.ca> > > > < mailto:mcr@sandelman.ca> > mailto:mcr@sandelman.ca> < > > > < mailto:mcr@sandelman.ca> > mailto:mcr@sandelman.ca> > > > < mailto:mcr@sandelman.ca> > mcr@sandelman.ca < < < > http://www.sandelman.ca/> > > > http://www.sandelman.ca/> < > http://www.sandelman.ca/> > > > http://www.sandelman.ca/> < < > http://www.sandelman.ca/> > > > http://www.sandelman.ca/> < > http://www.sandelman.ca/> > > > http://www.sandelman.ca/ | ruby on > rails [ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Michael Richardson < < < < > mailto:mcr+IETF@sandelman.ca> > > > mailto:mcr+IETF@sandelman.ca> > > > > > > > > < mailto:mcr+IETF@sandelman.ca> > mailto:mcr+IETF@sandelman.ca> > > > > > > > > > > > > > > > < < mailto:mcr+IETF@sandelman.ca> > mailto:mcr+IETF@sandelman.ca> > > > < mailto:mcr+IETF@sandelman.ca> > mcr+IETF@sandelman.ca>, Sandelman > > > > > > > > Software Works -= IPv6 IoT > > > > > > > > > > > > > > > consulting =- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > > -- > > > > > > > > -- > > > > > > > > > > > > > > > --------------------------------------------------------- > > > > > > > > > > > > > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > > > > > > > > > > > > > Facebook: < < > https://www.facebook.com/CDACINDIA> > > > https://www.facebook.com/CDACINDIA> > > > > > > > > < > https://www.facebook.com/CDACINDIA> > > > > > > https://www.facebook.com/CDACINDIA > > > & Twitter: @cdacindia ] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This e-mail is for the sole use of the intended recipient(s) and > > > > > may > > > > > > > > > > > > > > > contain confidential and privileged information. If you are not > > > > > the > > > > > > > > > > > > > > > intended recipient, please contact the sender by reply e-mail and > > > > > > > > > > > > > > > destroy all copies and the original message. Any unauthorized > > > > > > > > review, > > > > > > > > > > > > > > > use, disclosure, dissemination, forwarding, printing or copying of > > > > > > > > > > > > > > > this email is strictly prohibited and appropriate legal action > > > > > will be > > > taken. > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > > -- > > > > > > > > -- > > > > > > > > > > > > > > > --------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > Anima mailing list > > > > > > > > > > > > > > > < < mailto:Anima@ietf.org> > mailto:Anima@ietf.org> > > > < mailto:Anima@ietf.org> > Anima@ietf.org > > > > > > > > > > > > > > > < < > https://www.ietf.org/mailman/listinfo/anima> > > > > https://www.ietf.org/mailman/listinfo/anima> > > > > > > > > < > https://www.ietf.org/mailman/listinfo/anima> > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > --------------------------------------------------------- > > > > > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > > > > > Facebook: < > https://www.facebook.com/CDACINDIA> > > > https://www.facebook.com/CDACINDIA & > Twitter: @cdacindia ] > > > > > > > > > > > > > > This e-mail is for the sole use of the intended recipient(s) and may > > > > > > > contain confidential and privileged information. If you are not the > > > > > > > intended recipient, please contact the sender by reply e-mail and > > > > > > > destroy all copies and the original message. Any unauthorized > > > > review, > > > > > > > use, disclosure, dissemination, forwarding, printing or copying of > > > > > > > this email is strictly prohibited and appropriate legal action will > > > > be > > > taken. > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > --------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Anima mailing list > > > > > > > < mailto:Anima@ietf.org> > Anima@ietf.org > > > > > > > < > https://www.ietf.org/mailman/listinfo/anima> > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > > > > > > > > -- > > > > > > --- > > > > > > < mailto:tte@cs.fau.de> > tte@cs.fau.de > > > > > > > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > Facebook: > https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > > > > > This e-mail is for the sole use of the intended recipient(s) and may > > > contain confidential and privileged information. If you are not the > > > intended recipient, please contact the sender by reply e-mail and > > > destroy all copies and the original message. Any unauthorized review, > > > use, disclosure, dissemination, forwarding, printing or copying of > > > this email is strictly prohibited and appropriate legal action will be > taken. > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > > > > > -- > > --- > > tte@cs.fau.de > > > ------------------------------------------------------------------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------------------------------------------------------------------------- > -- --- tte@cs.fau.de From nobody Wed Feb 21 13:54:57 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEC0124C27 for ; Wed, 21 Feb 2018 13:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 RdHILhLq-Ejl for ; Wed, 21 Feb 2018 13:54:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B491120725 for ; Wed, 21 Feb 2018 13:54:54 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 20C3F20091 for ; Wed, 21 Feb 2018 17:02:17 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C5940806C2 for ; Wed, 21 Feb 2018 16:54:53 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: References: <23627.1519182392@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] reserving SRV.* for GRASP Object Names --- (was Re: [IANA #1050768] expert review for draft-ietf-anima-autonomic-control-plane) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 21:54:57 -0000 --=-=-= Content-Type: text/plain Hi, WG. I'm the designated expert reviewer for GRASP Object Names. IANA asked me to look at autonomic-control-plane. What fun! I had NO problems with AN_ACP or SRV.est, but the following paragraph surprised me: > Note that the objective format "SRV." is intended to be > used for any that is an [RFC6335] registered service > name. This is a proposed update to the GRASP registry subject to > future work and only mentioned here for informational purposed to > explain the unique format of the objective name. I think that if we want to reserve SRV.* for RFC6335 services, then we should do exactly that. The ship hasn't quite sailed on GRASP-15, because it's in gonna be in MISREF on a bunch of other documents. It could be done in GRASP-15, or in ACP; I don't think that IANA cares, but it would less surprising to have it in GRASP-15. I don't know if it's been through AUTH48, I suspect not? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqN6q0ACgkQgItw+93Q 3WV//Af8C19Co+bLF5e6TPIJ7b9eUEScKPSrHnai5Lrt4Xho6NYdPhFR+t3LIplj uy2kh/02kN9smpFjPLZ9GOWFBDGQbuHT0kj1sQoB2+fTHRYEYOhSWSpmPO/HAFm8 S64DH7ksKlCEKm/hgFN760RQJMLiIvyCsZVWUjgBNtM+QqUXkGVisbq9dQZ30PFI FUAGKGX3L2i1NzylGxb4i8kTwYS06KKliqz5lvIVzrKvX/XKmT6EyN7tw0gcwf/D fmWbDJVtieavxhcwZtmdShPcIDsff6PWobqFvHN6kRQ7zfdyGimknnZQP4ax20Xe W1G9S7YU7LrXkR/2IQyUOsPfRzUnZg== =mH7O -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 21 17:43:36 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E884412E048 for ; Wed, 21 Feb 2018 17:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qm4NLVTGWKOv for ; Wed, 21 Feb 2018 17:43:31 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7286D12E039 for ; Wed, 21 Feb 2018 17:43:31 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B5F1A58C4BA; Thu, 22 Feb 2018 02:43:26 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 98EAEB0DB23; Thu, 22 Feb 2018 02:43:26 +0100 (CET) Date: Thu, 22 Feb 2018 02:43:26 +0100 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20180222014326.GH23498@faui40p.informatik.uni-erlangen.de> References: <23627.1519182392@obiwan.sandelman.ca> <26183.1519250093@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26183.1519250093@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] reserving SRV.* for GRASP Object Names --- (was Re: [IANA #1050768] expert review for draft-ietf-anima-autonomic-control-plane) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 01:43:35 -0000 Hi Michael, I did not want to reopen the bottle on GRASP, and i did not want to delay ACP spec either with discussions about this naming strategy either. Therefore my idea was to simply use SRV.est in ACP without having to decide whether or not this should or should not become a generic scheme. The whole explanation of the idea and ask for reserving of the whole SRV.est is in draft-eckert-anima-grasp-dnssd. Once we would adopt this and it goes to RFC, that would be an update to GRASP RFC asking for the IANA update to the registry. This should give us more time to decide whether this should be the strategy or if not, it will just be a one-off name for the ACP GRASP objective. No harm done. just a strange name then. I also think technically its most logical to have this scheme in GRASP-DNS RFC: it has the context explaining what these services are, how they can be mapped to GRASP and thats all the context justifying the naming scheme. If we tried to move this back into GRASP, this might be more text for explanation than we want to have this late in the process. And in ACP it's even more a one-off. Site Note: i started GRASP-DNS primarily to cut down on the complexity of the GRASP service-discovery options that we would have to document in ACP/BRSKI - and that feedback came from you too (remember i had one rev with TTL and service priority etc of ACP and removed that - out of acp into grasp-dns after your feedback).. Cheers Toerless On Wed, Feb 21, 2018 at 04:54:53PM -0500, Michael Richardson wrote: > > Hi, WG. > > I'm the designated expert reviewer for GRASP Object Names. > IANA asked me to look at autonomic-control-plane. What fun! > > I had NO problems with AN_ACP or SRV.est, but the following paragraph surprised me: > > > Note that the objective format "SRV." is intended to be > > used for any that is an [RFC6335] registered service > > name. This is a proposed update to the GRASP registry subject to > > future work and only mentioned here for informational purposed to > > explain the unique format of the objective name. > > I think that if we want to reserve SRV.* for RFC6335 services, then we should > do exactly that. > > The ship hasn't quite sailed on GRASP-15, because it's in gonna be in MISREF > on a bunch of other documents. It could be done in GRASP-15, or in ACP; I > don't think that IANA cares, but it would less surprising to have it in > GRASP-15. I don't know if it's been through AUTH48, I suspect not? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Thu Feb 22 08:29:41 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B9612D7F4 for ; Thu, 22 Feb 2018 08:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 F-8Gw4DA8xlf for ; Thu, 22 Feb 2018 08:29:38 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1A412D7F2 for ; Thu, 22 Feb 2018 08:29:37 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5709820091; Thu, 22 Feb 2018 11:37:02 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 51C65806C2; Thu, 22 Feb 2018 11:29:36 -0500 (EST) From: Michael Richardson To: Toerless Eckert cc: anima@ietf.org In-Reply-To: <20180222014326.GH23498@faui40p.informatik.uni-erlangen.de> References: <23627.1519182392@obiwan.sandelman.ca> <26183.1519250093@obiwan.sandelman.ca> <20180222014326.GH23498@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] reserving SRV.* for GRASP Object Names --- (was Re: [IANA #1050768] expert review for draft-ietf-anima-autonomic-control-plane) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 16:29:40 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I did not want to reopen the bottle on GRASP, and i did not want to > delay ACP spec either with discussions about this naming strategy > either. I understand. The problem is that I don't know how to read the paragraph I quoted. It *seems* to instruct IANA to reserve more names, yet doesn't actually go as far as saying that. If it is not doing that, then maybe it should be removed and let draft-eckert-anima-grasp-dnssd do it's thing. The problem is that once the document is adopted, the WG could decide that we want to name it "SERVICE.", or maybe some other scheme, but your text, in attempting to anticipate things, constraints what the WG can do. > The whole explanation of the idea and ask for reserving of the whole > SRV.est is in draft-eckert-anima-grasp-dnssd. Once we would adopt this > and it goes to RFC, that would be an update to GRASP RFC asking for the > IANA update to the registry. >> Note that the objective format "SRV." is intended to >> be used for any that is an [RFC6335] registered >> service name. This is a proposed update to the GRASP registry >> subject to future work and only mentioned here for informational >> purposed to explain the unique format of the objective name. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqO7+8ACgkQgItw+93Q 3WUfLgf/f3R6EdsY2XDniCeT5Pm8i8lMTwErHqYt2vUGFEjJ/PEWm9j1njBtJBXO CM7KadtL6tcnNKnM/kSqNLsDXyvMx4IDRaEkoG+p7EQNLi30pLuBslIQhWFQscwv V+hjy4u0mtF3DDUrFz2yUnkFzx1gj+2wtn6kmUkKsKIBvikmL9JZk7LWtv8Fd1pi sY31nsDjwZQSL3Zh+SNzEcCplNv/6K6OereL++7Wtgsrg7Cvlp8f8SDMTi5Gib5l 1nmPXAFBTIPxuRD3sCesEl+LQfkBfAB3BJkUWtb0X5H08/3f5F5AaCv7gfwapZAS u9k/OZHOc0VObtMhMtU5jbOt3Us1Mg== =4l1t -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 22 17:55:11 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B867126DD9 for ; Thu, 22 Feb 2018 17:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 idRZYCWW3DPk for ; Thu, 22 Feb 2018 17:55:08 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D1E126BF6 for ; Thu, 22 Feb 2018 17:55:08 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EE8620091; Thu, 22 Feb 2018 21:02:33 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0F09C80706; Thu, 22 Feb 2018 20:55:06 -0500 (EST) From: Michael Richardson To: "Anoop Kumar Pandey" cc: "'Brian E Carpenter'" , anima@ietf.org In-Reply-To: <003501d3aa07$a37f0560$ea7d1020$@cdac.in> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 01:55:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Anoop Kumar Pandey wrote: > Pledge verifying the > domain is anyway overrated. So, I think you are saying that you do not subscribe to the problem stateme= nt. > Besides, it can also be done by verifying > the certificate of JRC during enrolment. Please explain. It would be great to simplify the protocol. > I would also like to quote/remind following lines from Section 1.3 > [Scope of Solution] of the RFC: > =E2=80=9CBut this solution is not exclusive to the large, it is inten= ded to > scale to thousands of devices located in hostile environments, such as > ISP provided CPE devices which are drop-shipped to the end user. The > situation where an order is fulfilled from distributed warehouse from > a common stock and shipped directly to the target location at the > request of the domain owner is explicitly supported. That stock > ("SKU") could be provided to a number of potential domain owners, and > the eventual domain owner will not know a-priori which device will go > to which location.=E2=80=9D Yes, it's designed exactly to deal with situation. Are you saying that it fails in some way? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqPdHkACgkQgItw+93Q 3WVxmwgAg9/lJygh6tJLj53L756EcYAhb2IrldM0B+MMM8Ad0EOuvCK+wu22p1/0 PcWY6Kf/WDn0+BGV3mfm5g0WyOp94Gsys/YFn4A61MqLRe/iIaByHhCWidBqbiGw S7d82csxoP1kEqKegZgjd0PHosIOoTNVCLHA0QUxOxgSULiZJ/303jYUyyoSgiKD t0F8tpu29NkB/ccpZzgGWUOP0Zvkd1tiiQKgx2FVymIcloQLizXADwyTE4ynXPJe /fVaC2TYMC+RGQdnXc4qaUdcfUbCd1x9962d55IStYctr3Jr7kPX0QRMNjmrbJAD kOGBcN6VifUwmlPw0kC73+FJNdy7Zw== =z8NO -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 22 17:58:04 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1F0126DD9 for ; Thu, 22 Feb 2018 17:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FcOXDH96nymy for ; Thu, 22 Feb 2018 17:58:01 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCE8126BF6 for ; Thu, 22 Feb 2018 17:58:00 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id q27so1169160pgn.8 for ; Thu, 22 Feb 2018 17:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IK/4H7ZtYznZzd6y6WUhL/K3MTz3UuIuVG+fu2dLMII=; b=UffeMGgMue6sZy4wkcZf7lEY6LS4V0lE8iVOMDQNtnZdvTo0nOayD63ZiyFv18GwAi Vwsp+qXBOba+3OnzyApc08pocwMaRXEfon0rdYPcSgNja3qttmqxZhSHCzYs3nQXuqaP 8la6YUc9Do4QZE62aqUoIJa767hamMH2m/emVdSD2PbZaczOngVt9PkZTsihgZxKeojI 0knN9D1DKeliQc/G4Bk6ozHgRoTZmSWQsp0FKrLoynnhaf4ubFJGbwTLGkfhih6hZQeC gMiXevMBWlnOQroHLDf4NNmblz6CEL8Hu80vf+WaNZQIKDBGCfJI8+wdHYzLt6FX4KvO ZEgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IK/4H7ZtYznZzd6y6WUhL/K3MTz3UuIuVG+fu2dLMII=; b=sonIwrI/JI0MFr2JcmfKHVwScVOcfwnwGVut4N7pGNyPfMHvhJr9FgmqNhV8HgU/DY IGjmUJPBiVrRLxwpLWecM0K2GoB2U2p4RmaYhMUQe0ZZqzlWWp6+cg2SfX+lbLebYGaI bcERV5/0dQpodRsJg/yrjgwaAA0aRvv2EqWBYDOIytNY/D8PfDhzf/FakepH6JDf5X1s jmp6WtO4zfn5cVIh9YtQyhoJ+XaYg6JlS5CxC5H8EqgmapeWVv7YfhObcR5Z1faHGDOM l9L34/UX/9idwIyHbR70H8CEGkBttFLhbthy/pXp6c2QAznzSSo3R0j9eY9TJEPrWf+e Ivkg== X-Gm-Message-State: APf1xPDdrBaJw+hkh6S+0r50zpNgmiAAlYOKzv+g67insIBVCH2WvMGu tUbWW0LE5n1AsGvs7rXA/YxW4JWg X-Google-Smtp-Source: AH8x2271B1ppn0jTpeILQYSsGjWSAbr8b7w176sT14Q2J6oKbn8DmLYUOz3Vysztn1RXYKywmo3G5w== X-Received: by 10.99.103.133 with SMTP id b127mr43497pgc.155.1519351080312; Thu, 22 Feb 2018 17:58:00 -0800 (PST) Received: from [192.168.183.200] ([114.23.138.211]) by smtp.gmail.com with ESMTPSA id w71sm1908898pfd.184.2018.02.22.17.57.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Feb 2018 17:57:59 -0800 (PST) Sender: Brian Carpenter To: anima@ietf.org References: <23627.1519182392@obiwan.sandelman.ca> <26183.1519250093@obiwan.sandelman.ca> <20180222014326.GH23498@faui40p.informatik.uni-erlangen.de> <22195.1519316976@obiwan.sandelman.ca> From: Brian E Carpenter Message-ID: <1cdd7723-8faf-d20b-5141-bac0730ee11f@gmail.com> Date: Fri, 23 Feb 2018 14:36:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <22195.1519316976@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] reserving SRV.* for GRASP Object Names --- (was Re: [IANA #1050768] expert review for draft-ietf-anima-autonomic-control-plane) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 01:58:03 -0000 On 23/02/2018 05:29, Michael Richardson wrote: > > Toerless Eckert wrote: > > I did not want to reopen the bottle on GRASP, and i did not want to > > delay ACP spec either with discussions about this naming strategy > > either. > > I understand. > > The problem is that I don't know how to read the paragraph I quoted. > It *seems* to instruct IANA to reserve more names, yet doesn't actually go as > far as saying that. > > If it is not doing that, then maybe it should be removed and > let draft-eckert-anima-grasp-dnssd do it's thing. At the moment I think that's best. I've already verified by writing proof-of-concept code that what Toerless proposes is perfectly possible and works with the DNS-SD examples at dns-sd.org, but if we reserve SRV.est now and the designated expert (i.e. Michael R) blocks any other SRV. registrations, we can go through a normal WG process. For those interested the code is at https://github.com/becarpenter/graspy (AskDNSSD2.py and GetDNSSD2.py) Brian > > The problem is that once the document is adopted, the WG could decide that > we want to name it "SERVICE.", or maybe some other scheme, but your > text, in attempting to anticipate things, constraints what the WG can do. > > > The whole explanation of the idea and ask for reserving of the whole > > SRV.est is in draft-eckert-anima-grasp-dnssd. Once we would adopt this > > and it goes to RFC, that would be an update to GRASP RFC asking for the > > IANA update to the registry. > > >> Note that the objective format "SRV." is intended to > >> be used for any that is an [RFC6335] registered > >> service name. This is a proposed update to the GRASP registry > >> subject to future work and only mentioned here for informational > >> purposed to explain the unique format of the objective name. > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Feb 22 18:19:47 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64CF126DD9 for ; Thu, 22 Feb 2018 18:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 SoKkhW7e5sfF for ; Thu, 22 Feb 2018 18:19:43 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427E4126BFD for ; Thu, 22 Feb 2018 18:19:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B5F8420091; Thu, 22 Feb 2018 21:27:09 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4D18C80B01; Thu, 22 Feb 2018 21:19:42 -0500 (EST) From: Michael Richardson To: "Anoop Kumar Pandey" cc: "'Toerless Eckert'" , anima@ietf.org In-Reply-To: <007701d3aace$c289ec00$479dc400$@cdac.in> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> <20180220062131.GA23498@faui40p.informatik.uni-erlangen.de> <00b701d3aa31$9d13db40$d73b91c0$@cdac.in> <20180220154840.GB23498@faui40p.informatik.uni-erlangen.de> <007701d3aace$c289ec00$479dc400$@cdac.in> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 02:19:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Anoop Kumar Pandey wrote: > So JRS has all legitimate manufacturers and is procuring pledges from > known sources (out of these legitimate manufacturers), then where is > the hostility? There are hostile devices on the network, and there are hostile networks th= at might attempt to take over the pledge. The IDevID protects the network against hostile pledges, and the voucher protects the pledge against hostile networks. There is also the non-malicious situatoin where a pledge simply has multiple (usually wireless!) networks to which it may join. The voucher lets the pledge decide which network will have it. However, we haven't decided how = to do this for 802.11; in 6tisch we are doing this for 802.15.4. > That=E2=80=99s what I was trying to say in my initial mail that given= an > unknown MI or a collaboration between pledge and MI, can security be > established using Automated BRSKI? If your network's policy is to accept devices from unknown MIs, and the MI is willing to issue vouchers to unknown domains, then you can be sure that the connection is good. By definition the pledge, being built by the MI, is *always* in collaboration with it. In ANIMA we do not go into home user situations, but that's due to charter restrictions, not technology. We do think that BRSKI can be used to bootstrap Homenet. In that situation, one can imagine buying lightbulbs From=20Home Depot, and bring them home. A JRC could run on a phone (or more likely an app that speaks to a JRC via an API). Unknown MIs might be accepted, but why do that when a QR code could be scanned by the phone to introduce the MI. > Also the pledge trusts JRC if JRC is able to pass on the voucher from > MASA to pledge. MASA only checks JRC=E2=80=99s certificate. Therefore= any JRC > having a valid certificate may pass on the voucher from MASA to pledge > and become owner of the pledge [case of theft]. Yes, that's the case if the manufacturer does not know (or care) who bought what. That's reasonable for quite a number of cases. Routers are usually spared by manufacturers by geography, and given <4hr replacement SLAs, there just isn't time on a Sunday morning at 4am to do any sales paperwork. What might matter is that the JRC is *a* customer, but it doesn't matter wh= ich. {Such a thing would have really helped me out in quite a number of times, as I would get woken up at 5am, when the field operative guys can't figure out why the router with the "export" firmware won't run securely, because it needs the "cryptographic" firmware, but that license key is not valid for that device} > I believe, BRSKI is a one-time imprinting service to a domain through > JRC. Once that is done, any unauthorized access (depending on the > vulnerability in the pledge) post EST, may not be stopped. That's true. That's not entirely our problem; we do however, by providing the pledge with an LDevID and certificate trust anchors via EST, support doing very secure authorization processes later on. No default passwords, etc. because no passwords are needed if both ends have certificates they can use. > BRSKI, is it one time process? > Or during each access to device will it re-run? One time process. > When do we require to re-run this, only on domain-transfer? On resale, the device should be put through a factory reset to clear things. The MASA will have to be willing to issue a new voucher to the new domain owner. > Does it happen automatically whenever a device enters a domain or can > it started deliberately? It is not automatic. It needs to be deliberate. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqPej4ACgkQgItw+93Q 3WXzAAf+Oo18reEp1fw6EwNA0b+rOptdxEDhqJsx4NRTROA1STicYEB3qv3Wg0ty mtNfoz7Y+pEw4OYuovIstMF+ad1ek5WnyqO75yFOk/Ns4VzrS+I440ZjHXclGkUz K3YpyBiY86UrCjcb+v+dQmRm29qF1OvybPKo+dWxu9Ks3VNrb3W7hfDm6oL8WsEm 7tC/mzy79cgbhdEcbgL6XooBF/dKeDR0qok+wOduSOVfu8BtV0iMye4YsXUsHRP6 Z1BmunDULI9wsJOvD73eLJPHQkpRv5TdtAFs5HBvnGXYEGkN4IIl69IQW5+9/1pq RyiU68admV1TYxNypQDPPJc6pWmc2w== =6396 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 22 20:48:48 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB87F1200F1 for ; Thu, 22 Feb 2018 20:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 UBNaK1r8LKlk for ; Thu, 22 Feb 2018 20:48:44 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AE312008A for ; Thu, 22 Feb 2018 20:48:44 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7911058C4BF; Fri, 23 Feb 2018 05:48:40 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5813FB0DB3E; Fri, 23 Feb 2018 05:48:40 +0100 (CET) Date: Fri, 23 Feb 2018 05:48:40 +0100 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20180223044840.GA7254@faui40p.informatik.uni-erlangen.de> References: <23627.1519182392@obiwan.sandelman.ca> <26183.1519250093@obiwan.sandelman.ca> <20180222014326.GH23498@faui40p.informatik.uni-erlangen.de> <22195.1519316976@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22195.1519316976@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] reserving SRV.* for GRASP Object Names --- (was Re: [IANA #1050768] expert review for draft-ietf-anima-autonomic-control-plane) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 04:48:47 -0000 On Thu, Feb 22, 2018 at 11:29:36AM -0500, Michael Richardson wrote: > The problem is that I don't know how to read the paragraph I quoted. > It *seems* to instruct IANA to reserve more names, yet doesn't actually go as > far as saying that. Sorry for my language being difficult to understand. The paragraph was explicitly meant to NOT give instructions to IANA (hence the "mentioned here for information purposes"). Just to explain the choice of the name "SRV.est". > If it is not doing that, then maybe it should be removed and > let draft-eckert-anima-grasp-dnssd do it's thing. Sure, i can remove that explanatory paragraph. Was just meant for a reviewer like you anyhow. > The problem is that once the document is adopted, the WG could decide that > we want to name it "SERVICE.", or maybe some other scheme, but your > text, in attempting to anticipate things, constraints what the WG can do. The WG is completely free to do what it wants, adopt/not-adopt grasp-dnssd, and if adopted choose the naming scheme. As an author of both drafts i was just trying to make a good guess at a name to minimize the chance of having to update it later. That's all. Wrt. good ideas that turned out not to be so good: check out the redundant _udp, _tcp in DNS-SD names. Aka: There are worse things than picking aspirational naming schemes even if they don't work out later. So, lets see if i understand your guidance: I will remove the explanatory paragraph, but wait for the next rev i need to do for IANA/IESG review anyhow. I will keep the suggested name SRV.est. Let me know if thats not ok. Cheers Toerless > > > The whole explanation of the idea and ask for reserving of the whole > > SRV.est is in draft-eckert-anima-grasp-dnssd. Once we would adopt this > > and it goes to RFC, that would be an update to GRASP RFC asking for the > > IANA update to the registry. > > >> Note that the objective format "SRV." is intended to > >> be used for any that is an [RFC6335] registered > >> service name. This is a proposed update to the GRASP registry > >> subject to future work and only mentioned here for informational > >> purposed to explain the unique format of the objective name. > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- --- tte@cs.fau.de From nobody Thu Feb 22 23:09:16 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5808A1243FE for ; Thu, 22 Feb 2018 23:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 tIx0iLZXhJPU for ; Thu, 22 Feb 2018 23:09:12 -0800 (PST) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2264124234 for ; Thu, 22 Feb 2018 23:09:10 -0800 (PST) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w1N78Udo006139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Feb 2018 12:38:31 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w1N77wMu022534; Fri, 23 Feb 2018 12:37:58 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w1N77oT0027718; Fri, 23 Feb 2018 12:37:52 +0530 From: "Anoop Kumar Pandey" To: "'Michael Richardson'" Cc: "'Brian E Carpenter'" , , "'Toerless Eckert'" References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> <3963.1519350905@obiwan.sandelman.ca> In-Reply-To: <3963.1519350905@obiwan.sandelman.ca> Date: Fri, 23 Feb 2018 12:37:47 +0530 Message-ID: <013e01d3ac75$0773ff70$165bfe50$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013F_01D3ACA3.212F48B0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE2I/joFI0/xQRcLlXQFy4X95wT3AJMjcXyAfHjFIQBMe5HLwJpWVH6AVGG/r+kozTpYA== Content-Language: en-in X-CDAC-PUNE-MailScanner-ID: w1N77wMu022534 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.198, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.984, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_40 -0.18, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w1N78Udo006139 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 07:09:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013F_01D3ACA3.212F48B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Anoop> Pledge verifying the Anoop> domain is anyway overrated. Michael>So, I think you are saying that you do not subscribe to the problem= statement. =20 I think that is not necessary. When a pledge/device is bought, it is manual= ly added to a network of buyer [usually intranet], where it can discover a = JRC. Therefore it is not the choice/privilege of pledge to verify the doma= in. On the other side, JRC should validate if the pledge has come from genu= ine manufacturer and is clean. =20 Alternatively, If a pledge is put on internet, then considering there may b= e countless number of JRCs on internet, and trying to connect to each JRC u= ntil the pledge finds actual owner is practically impossible; the pledge wi= ll have to be configured to discover a particular JRC while buying. So agai= n the pledge doesn=E2=80=99t have much choice. =20 =20 Also Quoting Toer advocating pledge requiring to verify JRC: =E2=80=9C. If = you are a buyer of large number of pledges and do not need any protection a= gainst theft, misassignment of pledges to other networks or intrusions int= o pledges that intend to impact your network later, then sure - you may be = happy with pledges not requiring vouchers to get enrolled.=E2=80=9D =20 In a parallel mail, you have mentioned that BRSKI is one time process and n= eed to be deliberately re-run/started. So once BRSKI is completed and pledg= e is enrolled; intrude in it or steal and put it in some other network, it = won=E2=80=99t matter.=20 =20 But the case where BRSKI runs automatically if pledge is disconnected and a= dded to anywhere else, at least theft won=E2=80=99t work because pledge won= =E2=80=99t work without re-verifying the voucher with new network/JRC. I t= hink this can be made mandatory in pledge to re-run BRSKI if it detects net= work change. =20 =20 Anoop> Besides, it can also be done by verifying Anoop> the certificate of JRC during enrolment. Michael>Please explain. Michael>It would be great to simplify the protocol. =20 I still believe that Pledge need not verify JRC, But if necessary, the easy= way will be following: =20 When pledge verifies a JRC, these steps are there [your first mail to me]: 1. Pledge issues voucher request to JRC 2. JRC passes voucher request to MASA.=20 3. MASA verifies request and issues voucher to JRC 4. JRC passes voucher to Pledge 5. Pledge verifies the voucher and send voucher status telemetry and = trusts JRC.=20 =20 These steps require MASA to be online, else they will fail. =20 What I propose is, when we buy the device, MI can issue a digitally signed = invoice issued to domain/JRC. =20 Now when a pledge wants to validate the JRC, he simply needs to verify the = signature of MI on the invoice. No communication with MASA or even MASA its= elf is not required.=20 It is just like the way, JRC verifies the pledge using the IDevID certifica= te issued by MI. =20 =20 Anoop> I would also like to quote/remind following lines from Section 1.3 Anoop> [Scope of Solution] of the RFC: Anoop> =E2=80=9CBut this solution is not exclusive to the large, it is inte= nded to Anoop> scale to thousands of devices located in hostile environments, such = as Anoop> ISP provided CPE devices which are drop-shipped to the end user. The Anoop> situation where an order is fulfilled from distributed warehouse from Anoop> a common stock and shipped directly to the target location at the Anoop> request of the domain owner is explicitly supported. That stock Anoop> ("SKU") could be provided to a number of potential domain owners, and Anoop> the eventual domain owner will not know a-priori which device will go Anoop> to which location.=E2=80=9D Michael>Yes, it's designed exactly to deal with situation. Michael>Are you saying that it fails in some way? =20 You said =E2=80=9CWe assume that in a managed network that the JRC *can* kn= ow all the legitimate manufacturers.=E2=80=9D.=20 Brian said =E2=80=9CANIMA is scoped to support professionally managed netwo= rks. So it seems reasonable to assume that they have procurement procedures= in place to buy from known sources and not to buy kit "off the back of a l= orry" to use a British idiom.=E2=80=9D =20 Basically you have known manufacturers and you are buying from known source= . Therefore there is no hostility. Further it=E2=80=99s not a cloud environ= ment where you don=E2=80=99t know, where your device is placed. Installatio= n of pledge will be manual [barely any chance of error, until you consider = humans are hostile]. =20 If there were hostility, like unknown manufacturer which could give you mal= icious pledge, BRSKI anyway can=E2=80=99t detect that, since it simply chec= ks IDevID which is anyway signed by unknown manufacturer and will check ou= t. You mentioned in earlier mail also that manual intervention is required = for such case. [You quoted =E2=80=9Cif the JRC does see a MI that it does n= ot know, then it can ask a human.=E2=80=9D] =20 There are hostile networks and pledges, but you have only whitelist of manu= facturers [your assumption only =E2=80=9Cthe JRC *can* know all the legitim= ate manufacturers=E2=80=9D] which only talks about known manufacturers. But= it doesn=E2=80=99t provide security in case of unknown or known turned rog= ue MI/pledge. For that manual intervention is required. =20 =20 Regards, Anoop =20 =20 =20 =20 =20 =20 =20 =20 -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 Sent: 23 February 2018 07:25 To: Anoop Kumar Pandey Cc: 'Brian E Carpenter' ; anima@ietf.org Subject: Re: [Anima] verification of manufacturer in BRSKI =20 =20 Anoop Kumar Pandey < anoop@cdac.in> wrote: =20 > Besides, it can also be done by verifying > the certificate of JRC during enrolment. =20 Please explain. It would be great to simplify the protocol. =20 =20 > I would also like to quote/remind following lines from Section 1.3 > [Scope of Solution] of the RFC: =20 > =E2=80=9CBut this solution is not exclusive to the large, it is inten= ded to > scale to thousands of devices located in hostile environments, such as > ISP provided CPE devices which are drop-shipped to the end user. The > situation where an order is fulfilled from distributed warehouse from > a common stock and shipped directly to the target location at the > request of the domain owner is explicitly supported. That stock > ("SKU") could be provided to a number of potential domain owners, and > the eventual domain owner will not know a-priori which device will go > to which location.=E2=80=9D =20 Yes, it's designed exactly to deal with situation. Are you saying that it fails in some way? =20 -- Michael Richardson < mcr+IETF@sandelman.ca>,= Sandelman Software Works -=3D IPv6 IoT consulting =3D- =20 =20 =20 ---------------------------------------------------------------------------= ---------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ---------------------------------------------------------------------------= ---------------------------------------------------- ------=_NextPart_000_013F_01D3ACA3.212F48B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Anoop> Pledge verifying the

Anoop> domain is anyway overrated.

Michael>So, I think you are saying that you do n= ot subscribe to the problem statement.

 

I thin= k that is not necessary. When a pledge/device is bought, it is manually add= ed to a network of buyer [usually intranet], where it can discover a JRC. = =C2=A0Therefore it is not the choice/privilege of pledge to verify the doma= in. On the other side, JRC should validate if the pledge has come from genu= ine manufacturer and is clean.

&= nbsp;

Alternatively, If a pledge is put on= internet, then considering there may be countless number of JRCs on intern= et, and trying to connect to each JRC until the pledge finds actual owner i= s practically impossible; the pledge will have to be configured to discover= a particular JRC while buying. So again the pledge doesn=E2=80=99t have mu= ch choice.

 

 

Also Quoting Toer advocating pledge requiring to verify JR= C: =E2=80=9C. If you are a buyer of large number of pledges and do not n= eed any protection against theft,=C2=A0 misassignment of pledges to other n= etworks or intrusions into pledges that intend to impact your network later= , then sure - you may be happy with pledges not requiring vouchers to get e= nrolled.=E2=80=9D

 <= /o:p>

In a parallel mail, you have mentioned= that BRSKI is one time process and need to be deliberately re-run/started.= So once BRSKI is completed and pledge is enrolled; intrude in it or steal = and put it in some other network, it won=E2=80=99t matter.

<= p class=3DMsoPlainText> 

But the= case where BRSKI runs automatically if pledge is disconnected and added to= anywhere else, at least theft won=E2=80=99t work because pledge won=E2=80= =99t work without re-verifying the voucher with new network/JRC. =C2=A0I th= ink this can be made mandatory in pledge to re-run BRSKI if it detects netw= ork change.

 <= /p>

 

Anoop> Besides, it can also be done by verifying

Anoop> the certificate of = JRC during enrolment.

M= ichael>Please explain.

= Michael>It would be great to simplify the protocol.

 

I= still believe that Pledge need not verify JRC, But if necessary, the easy = way will be following:

 

When pledge verifies a JRC, these steps are = there [your first mail to me]:

1.       Pledge issues voucher request to JRC

2.       JRC passes voucher request to MASA.

3.       MASA verifies request and issues voucher to JRC<= /o:p>

4.   &= nbsp;   JRC passes voucher to Pledge=

5.   =     Pledge verifies the voucher and = send voucher status telemetry and trusts JRC.

 

These steps require MASA to be online, else they will fail.

 

What I propose is, when we buy the device, MI can issue a digitally signe= d invoice issued to domain/JRC.

=  

Now when a pledge wants to validate= the JRC, he simply needs to verify the signature of MI on the invoice. No = communication with MASA or even MASA itself is not required.

It is just like the way, JRC verifies the pledge u= sing the IDevID certificate issued by MI.

 

 

Anoop> I would also like to quote/remind follo= wing lines from Section 1.3

<= b>Anoop> [Scope of Solution] of the RFC:

Anoop> =E2=80=9CBut this solution is not exclusi= ve to the large, it is intended to

Anoop> scale to thousands of devices located in hostile envi= ronments, such as

Anoop= > ISP provided CPE devices which are drop-shipped to the end user. The

Anoop> situation wher= e an order is fulfilled from distributed warehouse from<= /p>

Anoop> a common stock and shipped direc= tly to the target location at the

Anoop> request of the domain owner is explicitly supported. T= hat stock

Anoop> (&q= uot;SKU") could be provided to a number of potential domain owners, an= d

Anoop> the eventua= l domain owner will not know a-priori which device will go

Anoop> to which location.=E2=80=9D

Michael>Yes, it's des= igned exactly to deal with situation.

Michael>Are you saying that it fails in some way?

 

You said =E2=80=9CWe assume that in a managed network that the JRC= *can* know all the legitimate manufacturers.=E2=80=9D.

Brian said =E2=80=9CANIMA is scoped to support professi= onally managed networks. So it seems reasonable to assume that they have pr= ocurement procedures in place to buy from known sources and not to buy kit = "off the back of a lorry" to use a British idiom.=E2=80=9D

 

Basically you have known manufacturers and you are buying from known sour= ce. Therefore there is no hostility. Further it=E2=80=99s not a cloud envir= onment where you don=E2=80=99t know, where your device is placed. Installat= ion of pledge will be manual [barely any chance of error, until you conside= r humans are hostile].

 

If there were hostility, like unknown manufa= cturer which could give you malicious pledge, BRSKI anyway can=E2=80=99t de= tect that, since it simply checks IDevID =C2=A0which is anyway signed by un= known manufacturer and will check out. You mentioned in earlier mail also t= hat manual intervention is required for such case. [You quoted =E2=80=9Cif = the JRC does see a MI that it does not know, then it can ask a human.=E2=80= =9D]

 

There are hostile networks and pledges, but you have only whit= elist of manufacturers [your assumption only =E2=80=9Cthe JRC *can* know al= l the legitimate manufacturers=E2=80=9D] which only talks about known manuf= acturers. But it doesn=E2=80=99t provide security in case of unknown or kno= wn turned rogue MI/pledge. For that manual intervention is required.

 

 

Regards,

Anoop

 <= /o:p>

 

 

 

 

 <= /o:p>

 

 

-----Original Message-----
From: Michael Ri= chardson [mailto:mcr+ietf@sandelman.ca]
Sent: 23 February 2018 07:25To: Anoop Kumar Pandey <anoop@cdac.in>
Cc: 'Brian E Carpenter' &l= t;brian.e.carpenter@gmail.com>; anima@ietf.org
Subject: Re: [Anima] v= erification of manufacturer in BRSKI

 

 

Anoop Kumar Pandey <anoop@cdac.in> = wrote:

 

=C2=A0=C2=A0=C2=A0 > Besides, it can also be done by ver= ifying

=C2=A0=C2=A0=C2=A0 > the ce= rtificate of JRC during enrolment.

 

Please explain.

It would be great to simplify the protocol.

 <= /span>

 

=C2=A0=C2=A0=C2=A0 > I would also like to quote/remind following lin= es from Section 1.3

=C2=A0=C2=A0=C2= =A0 > [Scope of Solution] of the RFC:

 

=C2=A0=C2=A0=C2=A0 > = =E2=80=9CBut this solution is not exclusive to the large, it is intended to=

=C2=A0=C2=A0=C2=A0 > scale to tho= usands of devices located in hostile environments, such as

=C2=A0=C2=A0=C2=A0 > ISP provided CPE devices whic= h are drop-shipped to the end user. The

=C2=A0=C2=A0=C2=A0 > situation where an order is fulfilled from distr= ibuted warehouse from

=C2=A0=C2=A0=C2= =A0 > a common stock and shipped directly to the target location at the<= o:p>

=C2=A0=C2=A0=C2=A0 > request of th= e domain owner is explicitly supported. That stock

=C2=A0=C2=A0=C2=A0 > ("SKU") could be provided= to a number of potential domain owners, and

=C2=A0=C2=A0=C2=A0 > the eventual domain owner will not know a-p= riori which device will go

=C2=A0=C2= =A0=C2=A0 > to which location.=E2=80=9D

 

Yes, it's designed exact= ly to deal with situation.

Are you sa= ying that it fails in some way?

=  

--

Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works=C2=A0 -=3D IPv6 IoT consulting =3D-

 

 

 


------------------------------------------------------------------= -------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= ---------------------------------------------------------- ------=_NextPart_000_013F_01D3ACA3.212F48B0-- From nobody Fri Feb 23 05:09:55 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D790F126C2F; Fri, 23 Feb 2018 05:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ka-HYZRUsmnA; Fri, 23 Feb 2018 05:09:51 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0937B124239; Fri, 23 Feb 2018 05:09:51 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id 188so3996045wme.1; Fri, 23 Feb 2018 05:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=EwzBrUzEnHeO9n4HLEMLK4J098z+lj0f5jBHlZSsKb4=; b=B8f/JK9Sg2y6jMK4W//UKT9n7zbEPSXw1sWKDb9bEdEWN9BGi3+TITIPItowNb4BFw aPlr5C33fGb42TP8Emv2aXpYskYtHJXb/uWuNRf3eCjwHDMxgY2OY5CdG0qQm2dZT6nl d1f3/lpqC70IK4Qpq5z77gqk6xcAdCt2/edePXGwCygc/arQV92yg7X2+VGb9gNNWE1C c6+uxrREL/EdcJlxK2U6J7RcD17swm0gOJ0zTs6eS2kzgvrNGJ1+OmOZks1MF1p/+I0b oOSwHWYYceCTC9jA/ZHX8Z2MIBKNFBBIHSYTjuFPIm2kapgmssON/eO42PfRqbGAcgj/ OtzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=EwzBrUzEnHeO9n4HLEMLK4J098z+lj0f5jBHlZSsKb4=; b=LV2x6a59pNKmMNfzTsSzxH2LCOhe3kSI8DUqXzrQLIQTFGib6DKWs0D+HVWZpYgR7E Zwnfsg2pscXRnpRHToFJMJbaiEs/xbo7GKQky0IcLAdUPcR0sp63JfAbrSPGRVAFD/ww V9W4MkcdfDrcxc4i+Ecu+eMMZwx+tyMRq7hQd47UFxzSwixLFQ7HiGbqKU7sPQM+QvfO l7ojTR0uv0wF8HmueIS161Jf5152rSDGqcxecgkI9kqn1RY36yOsU/YWbO8aTsGaMvin chjKVaWdBGN1gBFGBj0IjqDL9eHEPkONw6XPS6VxUeP1aJmdtiXYR60ZuYyee1YIxzN+ 6jHA== X-Gm-Message-State: APf1xPBPFcZY/hw0aVbAy/4NiRCbdcgFnD1Y6ALGNSdEe0yv+bMp/Aab 2zdSJfjTiOn8e9eqGFFMttG030ju X-Google-Smtp-Source: AG47ELui0z9q9sgL7j3aTojqYSwRCtQe8FSFzOYpMx1/Wga8zZyL1WNSxndUKrtKLhspdJHToeZdSQ== X-Received: by 10.28.15.10 with SMTP id 10mr1690555wmp.75.1519391389185; Fri, 23 Feb 2018 05:09:49 -0800 (PST) Received: from [192.168.1.25] (ANice-652-1-47-117.w86-219.abo.wanadoo.fr. [86.219.98.117]) by smtp.gmail.com with ESMTPSA id q77sm1911726wme.41.2018.02.23.05.09.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 05:09:48 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> Message-ID: <22a65bfa-8954-304d-5a65-38d9e6d98b3f@gmail.com> Date: Fri, 23 Feb 2018 14:09:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr-classic Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 13:09:54 -0000 On 18/01/18 09:59, Sheng Jiang wrote: > > Hi, authors of anima-reference-model, > > I have reviewed the draft as the document shepherd, see below > comments. Overall, I feel this document is very useful and it is > almost ready for be published. Please properly address my comments > together with other WGLC comments you may receive. Another revised > version of the document is needed to process the document further if > it passed the WGLC. > Hi Sheng, First of all thanks for the thorough review. I am now finished with working your comments into the draft. I am just publishing version -06. This version should address all your comments. I am not aware of any other outstanding comments, and believe we have addressed all open issues now. Details below in line. Michael > General issues: > > 1. In section 3.1, it says “The Autonomic Control Plane (ACP) is the > summary of all interactions of the Autonomic Networking Infrastructure > with other nodes and services.†I’m a bit confused by this statement. > In my understanding, the ACP itself is mostly a “channelâ€, although > some ANI functions (signaling, aggregated reporting etc.) are running > within the channel, they should be parallel with ACP function in the > architecture view. > > At the same time, there are indeed some functions considered as > sub-functions of the ACP, e.g. the addressing and routing, which are > necessary to make the ACP runnable. > > So, my questions to the co-authors: > > 1) Do you see ACP as an individual function as I understood (mostly a > channel), or a summary of a suite of functions running inside the ACP? > > 2) What functions are sub-functions of ACP, and what are in parallel > with ACP? > There are really two meanings to the term "ACP". This has caused quite some confusion, and I agree it needs to be nailed once and for all. Thanks for raising it here. 1) The general term "control plane" refers to the sum of all protocols that control network behaviour. Like, in a traditional network, routing protocols, etc. Consequently, an "Autonomic Control Plane" is the sum of all protocols that controls the behaviour of an autonomic network. In draft-ietf-anima-stable-connectivity we now use the term "Generalized ACP" for this abstract concept. 2) In the ANIMA context, we use the term "ACP" also to describe a very specific implementation of the generic concept of an "Autonomic Control Plane". I now cleared up the naming in the reference draft. Where we mean the abstract concept (3.1 for example), I now use "GACP", where we mean the implementation, I now use "ACP" and refer to the ACP draft. Specifically, I changed in 3.1 from ACP to GACP. And re-worded section 4.6, which is all about the implementation of the ACP. > 2. I’m confused by the whole purpose of Section 3. The first > sub-clause is describing the architecture of an Autonomic Network > Element, while the rest sub-clauses (adjacency table, state machine > etc.) seems more like “implementation considerations†or “proceduresâ€. > I think both are useful content, but they are in two different > dimensions, maybe separate them into different sections? > Well, the section is about the network element. I find it quite logic that you first discuss the architecture of the element, then how it behaves in a network. However, I added an explanatory intro at the beginning of that section to make it clearer. Thanks for pointing out that this wasn't clear! > 3. Some texts (e.g. paragraph 4 of Section 1) are directly bind to the > WG’s charter, I’m not sure it is a good approach that an RFC > normatively refer the WG charter which is dynamically changed along > with the work going on in the WG. Maybe just simply re-phrase the > “chartered work†as “Phase 1/near term workâ€, and “non-chartered†as > “Phase 2 long-termâ€? > Agree that needs to be fixed. Did some editorial changes for that. The sections with an (*) now start with a sentence like this:     ... is not covered in the current implementation specifications. This section is for informational purposes, for following phases of standardization. As part of that fix, I also re-worded the abstract. It now reads: This document describes a reference model for Autonomic Networking. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. Now, the word "charter" is no longer in the text at all. Comments? > 4. The whole Section 7 seems too theoretical and abstract. The > described concepts are valuable, I’d suggest to have more texts > mapping these concepts into the ANI/AN. > I made the changes described above, to point out very explicitly that these sections are essentially for future study. I would prefer NOT to do any more editing beyond that. That should be done in a subsequent document, I think. > Specific comments: > > Section 1 Introduction > > - Paragraph 3 claims “This reference model allows for this hybrid > approach.†I think it would be better to explain in what degree the > “hybrid†could be. For example, the ANI actually doesn’t support > non-autonomic nodes to join in the same domain with the autonomic > nodes; thus, in this deployment level, it is not “hybridâ€. > Good point. I added an example to explain the concept. I thought of adding more, but then I think the intro would become too long. > - As said in the general issues, paragraph 4 seems binding with the WG > charter too much. > That is resolved. > > Section 2 The Network View > > - In the figure, it seems the ASAs are hierarchical, but there is no > relevant texts. My understanding is that, it is reasonable to > distinguish layered ASAs, e.g., some ASAs might be very fundamental, > and should be the future work of the Anima WG; while most of the > specific ASAs are service/scenario relevant, that might not be > suitable to do them case by case in Anima. > Oh, it was not the intention to imply a hierarchy. Thanks for pointing this out. ASAs may or may not be hierarchical. I added a sentence to clarify: "ASAs may be standalone, or use other ASAs in a hierarchical way." > - “The current charter of the ANIMA WG is to specify the ANI, using a > few autonomic functions as use cases.†Again, I’m not sure it is good > to bind the RFC to the WG charter. > Fixed. > Section 3 The Autonomic Network Element > > - If Figure 1 means to make the ASAs hierarchical, then it is better > to be consistent in Figure 2. > I think this is fixed with the above text. Let me know if it is not clear enough. > - Nits in Figure 2 > > Synchronization -> synchronization > The RFC editor will fix all the UK vs US English issues. I'll leave it to them, since I'm not a native English speaker. > In the ANI part, the “Discovery, negotiation and synchronisation > functions†looks like a sub-item of “Autonomic Node Addressingâ€, I > guess it should be typo? > Good catch. Fixed. > - Section 3.1 “The Autonomic Networking Infrastructure (ANI) is > normally built on a hop-by-hop basis.†It is true for ACP, but I don’t > think it applies for all the other ANI functions, e.g. > negotiation/sync signaling. > Note the "built". I think the sentence is correct. However, to clarify, I changed "built" to "constructed". And, we're really talking ACP here. I changed that as well. > - Section 3.2, the first bullet point of paragraph 3 “link local > discoveryâ€, it is ambiguous that what kind information is gathered > through GRASP. I think there should be some basic information gathered > through ND protocol. > Yes, this section is a bit ambiguous, I agree. But if we want to make it precise, it's going to explode the section and make it unreadable. Hmmm... I think the issue is really the phrase "This is described in [GRASP]". I re-phrase that to "The related standards track documents (GRASP, ACP, BRSKI) describe in detail how link local discovery is used." > - Section 3.2, the third bullet point: “Once the node is part of the > ACP of a domain, it will use GRASP discovery [I-D.ietf-anima-grasp] to > find Registrar(s) of its domain and potentially other services.†The > later version of BRSKI changed to use a GRASP Flood message to > actively broadcast the registrar service by the proxies in their > link-local scope. > I removed "discovery". "It will use GRASP" is correct. > - Section 3.3.2, I think it would be good to briefly discuss the > situation that if an enrolled node re-boot from power cut or be > attached to another network, how the transition state would be? Is it > the same with “Factory resetâ€? > This discussion is not specific to 3.3.2. A node can reboot at any point in time. The important part is if it keeps its LDevID or not. But you're right. This is not mentioned anywhere... Hmmm... Thinking more, this is just another transition in the state machine, for each state. I'll add that, I think it makes sense.     "Powercycle event: The device loses all state tables, but not its domain identity (LDevID). Next state: 2." I hope I'm not opening a can of worms here... It is possible to conceive a model where a device also loses its LDevID... I think that's going to be an extreme corner case, and would prefer to not even mention it here. Thoughts? > Section 4 The Autonomic Networking Infrastructure > > - Section 4.2 Addressing, there are a list of comprehensive > requirements of addressing, which are good content. It might be better > if Section 4.1 Naming also include such a requirement list? > I think the requirements are in the section, just not in a bulleted list. Frankly, I prefer not to change this at this stage of the document. Let me know if we're missing a requirement. > - Section 4.5 “All autonomic nodes in a domain must be able to > communicate with each other, and with autonomic nodes outside their > own domain.†The cross-domain mechanism hasn’t be covered yet, maybe > it’s better to note this feature is for “long term†work rather than > “phase 1â€. > OK, changed that to "in later phases also with ..." > - Section 4.6 “The totality of autonomic interactions forms the > "Autonomic Control Plane". Again, it is the same as No.1 general issue > as described above. > Changed to "The "Autonomic Control Plane" carries the control protocols in an autonomic network." > Section 5 Security and Trust Infrastructure > > - Section 5.2 describes domain certificate; I think the device > certificate, which is pre-set by the manufacture also needs to be > mentioned. > Done. > Section 6 Autonomic Service Agents (ASA) > > - It might be good to reference draft-carpenter-anima-asa-guidelines? > Good point. Included. > - Section 6.3 is interesting, it actually unveils the ANI functions > (except GRASP) are yet ASAs. It is no problem for me, but I have a bit > concern that new readers might be confused about the “overlap/mixture†> between ANI and ASAs? > I thought we were quite clear about that. In section 6.1 we say: o A few 'infrastructure ASAs' that use basic ANI features in support of the ANI itself, which must run in all autonomic nodes. These are outlined in the following sections. I suggest we leave it at that. > Section 7 Managing a (Partially) Autonomic Network > > - Section 7.6 APIs: this section are too abstract for me, I just > couldn’t really get the point. It seems like a general design pattern > rather than specific mechanisms related to autonomic networks. > I agree with you, it is fairly generic. At the same time it provides some context to the APIs we use, and it's clearly marked with a (*) as being phase 2. I suggest we leave it in. If folks feel strongly, I think we could take out the entire section. For now I leave it. > - Section 7.7 Data Model has the similar issue as above. It explains > the concept but lacks essential content related to ANI. > Dito. I suggest to leave it for now. [end of reply] > Thanks and regards, > > Sheng > > *From:*Anima [mailto:anima-bounces@ietf.org] *On Behalf Of *Sheng Jiang > *Sent:* Tuesday, January 09, 2018 2:26 PM > *To:* anima@ietf.org > *Cc:* anima-chairs@ietf.org > *Subject:* [Anima] WGLC on draft-ietf-anima-reference-model-05 - > Respond by January 22nd, 2018 > > Hi all, > > This message starts the two-week ANIMA Working Group Last Call to > advance draft-ietf-anima-reference-model-05, A Reference Model for > Autonomic Networking. This document's intended status is > Informational. At present, there is no IPR file against this document. > > Please send your comments by January 22nd, 2018. If you do not feel > this document should advance, please state your reasons why. > > Sheng JIANG is the assigned document shepherd. > > Regards, > > Sheng (co-chair, Toerless who as a co-author stayed neutral on the > content side) > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Feb 23 05:16:41 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3680126CF9; Fri, 23 Feb 2018 05:16:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151939179981.22656.16130195813472360933@ietfa.amsl.com> Date: Fri, 23 Feb 2018 05:16:39 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-reference-model-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 13:16:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : A Reference Model for Autonomic Networking Authors : Michael H. Behringer Brian Carpenter Toerless Eckert Laurent Ciavaglia Jeferson Campos Nobre Filename : draft-ietf-anima-reference-model-06.txt Pages : 30 Date : 2018-02-23 Abstract: This document describes a reference model for Autonomic Networking. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-reference-model-06 https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 23 07:48:58 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1051273E2 for ; Fri, 23 Feb 2018 07:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 5pyeHMcBqmGn for ; Fri, 23 Feb 2018 07:48:52 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523341271DF for ; Fri, 23 Feb 2018 07:48:52 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BD6C658C4BF; Fri, 23 Feb 2018 16:48:47 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9E5CFB0DB42; Fri, 23 Feb 2018 16:48:47 +0100 (CET) Date: Fri, 23 Feb 2018 16:48:47 +0100 From: 'Toerless Eckert' To: Anoop Kumar Pandey Cc: 'Michael Richardson' , 'Brian E Carpenter' , anima@ietf.org Message-ID: <20180223154847.GB7254@faui40p.informatik.uni-erlangen.de> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> <3963.1519350905@obiwan.sandelman.ca> <013e01d3ac75$0773ff70$165bfe50$@cdac.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013e01d3ac75$0773ff70$165bfe50$@cdac.in> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 15:48:56 -0000 On Fri, Feb 23, 2018 at 12:37:47PM +0530, Anoop Kumar Pandey wrote: > I think that is not necessary. When a pledge/device is bought, it is manually added to a network of buyer [usually intranet], where it can discover a JRC. Therefore it is not the choice/privilege of pledge to verify the domain. On the other side, JRC should validate if the pledge has come from genuine manufacturer and is clean. I did explain to you in my prior email, that one primary purpose of Voucher/MASA is to prohibit man-in-the-middle attacks. > Alternatively, If a pledge is put on internet, then considering there may be countless number of JRCs on internet, and trying to connect to each JRC until the pledge finds actual owner is practically impossible; the pledge will have to be configured to discover a particular JRC while buying. So again the pledge doesn???t have much choice. I did explain to you in another email in this thread that piece as well. > Also Quoting Toer advocating pledge requiring to verify JRC: ???. If you are a buyer of large number of pledges and do not need any protection against theft, misassignment of pledges to other networks or intrusions into pledges that intend to impact your network later, then sure - you may be happy with pledges not requiring vouchers to get enrolled.??? That was purely respective to theft protectin, not men in the middle attacks. > In a parallel mail, you have mentioned that BRSKI is one time process and need to be deliberately re-run/started. So once BRSKI is completed and pledge is enrolled; intrude in it or steal and put it in some other network, it won???t matter. I did explain to you that BRSKI is meant to be be run every time pledge is in factory reset state. > But the case where BRSKI runs automatically if pledge is disconnected and added to anywhere else, at least theft won???t work because pledge won???t work without re-verifying the voucher with new network/JRC. I think this can be made mandatory in pledge to re-run BRSKI if it detects network change. That is explcitly mentioned as a nogo in BRSKI already. Change of network you're connecting to does not imply change of ownership. > I still believe that Pledge need not verify JRC We did provide a lot of answers/reasons to your questions re. why/where/how BRSKI/MASA/Voucher are necessary/beneficial. You did not provide any technical or use-case reasoning why those arguments are incorrect in your opinion. You are just repeating you initial opinion and think you can ignore the answers provided to you. > But if necessary, the easy way will be following: > > > > When pledge verifies a JRC, these steps are there [your first mail to me]: > > 1. Pledge issues voucher request to JRC > > 2. JRC passes voucher request to MASA. > > 3. MASA verifies request and issues voucher to JRC > > 4. JRC passes voucher to Pledge > > 5. Pledge verifies the voucher and send voucher status telemetry and trusts JRC. > > > > These steps require MASA to be online, else they will fail. That is the preferred, standard method, yes. There are mentionings of offline MASA/voucher options, i think i the appendix. > What I propose is, when we buy the device, MI can issue a digitally signed invoice issued to domain/JRC. Yes, this would be one instantiation option of what we call an offline voucher, which is covered by BRSKI. I think BRSKI also outlines the issues/limitations that can come with offline vouchers. For example if you buy from a shop that bought from a reseller that bought from a distributor that bought from the manufacturer, the whole sales integration to be able to generate such a voucher may be cost prohibitive. A key contribution of BRSKI is the concept of the logging of voucher requests as a way to generate the hopefully most cost-reduced optoin to generate vouchers. Which can also be applied to offline vouchers. The various means and processes how to provide most easily vouchers in various situations are definitely a good and long term discussion topic, even offering opportunity to write additional draft/RFCs. > Now when a pledge wants to validate the JRC, he simply needs to verify the signature of MI on the invoice. No communication with MASA or even MASA itself is not required. Yes. I have this picture in my head of a guy (called Scotty ;-) holding a printed sales receipt with QR-code and trying to show it to his new router/equipment. The classicial representation of an offline voucher is a USB stick and a pair of sneakers to represent the physcial media and transport channel, but i like the QR-code too to represent the potential complexities of offline vouchers. > It is just like the way, JRC verifies the pledge using the IDevID certificate issued by MI. If you have a side-channel to get the voucher into the pledge, yes. But very often in "professionally managed networks" (ANIMA charter), the guy who gets the sales receipt could be (hundreds of) miles away from the pledge, so in those environments its much more likely that any type of offline voucher can easily be injected into the Registrar first than through a side channel physcially into the pledge. > > Basically you have known manufacturers and you are buying from known source. Therefore there is no hostility Repeated incorrect conclusion. Asked and answered. > Further it???s not a cloud environment where you don???t know, where your device is placed. Installation of pledge will be manual [barely any chance of error, until you consider humans are hostile]. Repeated incorrect conclusion. Asked and answered. > If there were hostility, like unknown manufacturer which could give you malicious pledge, BRSKI anyway can???t detect that, since it simply checks IDevID which is anyway signed by unknown manufacturer and will check out. You mentioned in earlier mail also that manual intervention is required for such case. [You quoted ???if the JRC does see a MI that it does not know, then it can ask a human.???] Repeated incorrect conclusion. Asked and answered. > There are hostile networks and pledges, but you have only whitelist of manufacturers [your assumption only ???the JRC *can* know all the legitimate manufacturers???] which only talks about known manufacturers. But it doesn???t provide security in case of unknown or known turned rogue MI/pledge. For that manual intervention is required. Repeated incorrect conclusion. Asked and answered. Cheers Toerless > Regards, > > Anoop > > > > > > > > > > > > > > > > > > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: 23 February 2018 07:25 > To: Anoop Kumar Pandey > Cc: 'Brian E Carpenter' ; anima@ietf.org > Subject: Re: [Anima] verification of manufacturer in BRSKI > > > > > > Anoop Kumar Pandey < anoop@cdac.in> wrote: > > > > > Besides, it can also be done by verifying > > > the certificate of JRC during enrolment. > > > > Please explain. > > It would be great to simplify the protocol. > > > > > > > I would also like to quote/remind following lines from Section 1.3 > > > [Scope of Solution] of the RFC: > > > > > ???But this solution is not exclusive to the large, it is intended to > > > scale to thousands of devices located in hostile environments, such as > > > ISP provided CPE devices which are drop-shipped to the end user. The > > > situation where an order is fulfilled from distributed warehouse from > > > a common stock and shipped directly to the target location at the > > > request of the domain owner is explicitly supported. That stock > > > ("SKU") could be provided to a number of potential domain owners, and > > > the eventual domain owner will not know a-priori which device will go > > > to which location.??? > > > > Yes, it's designed exactly to deal with situation. > > Are you saying that it fails in some way? > > > > -- > > Michael Richardson < mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- > > > > > > > > > ------------------------------------------------------------------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------------------------------------------------------------------------- > -- --- tte@cs.fau.de From nobody Fri Feb 23 08:45:10 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB53127136 for ; Fri, 23 Feb 2018 08:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 HT6pmo-7zKI4 for ; Fri, 23 Feb 2018 08:45:07 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD1B12E039 for ; Fri, 23 Feb 2018 08:45:07 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3AE7F20090; Fri, 23 Feb 2018 11:52:36 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AE18F80B14; Fri, 23 Feb 2018 11:45:06 -0500 (EST) From: Michael Richardson To: Toerless Eckert cc: anima@ietf.org In-Reply-To: <20180223044840.GA7254@faui40p.informatik.uni-erlangen.de> References: <23627.1519182392@obiwan.sandelman.ca> <26183.1519250093@obiwan.sandelman.ca> <20180222014326.GH23498@faui40p.informatik.uni-erlangen.de> <22195.1519316976@obiwan.sandelman.ca> <20180223044840.GA7254@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Feb 2018 11:45:06 -0500 Message-ID: <15086.1519404306@obiwan.sandelman.ca> Archived-At: Subject: Re: [Anima] reserving SRV.* for GRASP Object Names --- (was Re: [IANA #1050768] expert review for draft-ietf-anima-autonomic-control-plane) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 16:45:09 -0000 Toerless Eckert wrote: > So, lets see if i understand your guidance: > I will remove the explanatory paragraph, but wait for the next rev i= need to do > for IANA/IESG review anyhow. I will keep the suggested name SRV.est. check! -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | network architec= t [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Fri Feb 23 08:49:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DE612E892 for ; Fri, 23 Feb 2018 08:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 AL1AU2XsHaxg for ; Fri, 23 Feb 2018 08:49:02 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B6012E891 for ; Fri, 23 Feb 2018 08:49:02 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9C81858C4BF; Fri, 23 Feb 2018 17:48:58 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7997CB0DB45; Fri, 23 Feb 2018 17:48:58 +0100 (CET) Date: Fri, 23 Feb 2018 17:48:58 +0100 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20180223164858.GC7254@faui40p.informatik.uni-erlangen.de> References: <23627.1519182392@obiwan.sandelman.ca> <26183.1519250093@obiwan.sandelman.ca> <20180222014326.GH23498@faui40p.informatik.uni-erlangen.de> <22195.1519316976@obiwan.sandelman.ca> <20180223044840.GA7254@faui40p.informatik.uni-erlangen.de> <15086.1519404306@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15086.1519404306@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] reserving SRV.* for GRASP Object Names --- (was Re: [IANA #1050768] expert review for draft-ietf-anima-autonomic-control-plane) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 16:49:05 -0000 On Fri, Feb 23, 2018 at 11:45:06AM -0500, Michael Richardson wrote: > Toerless Eckert wrote: > > So, lets see if i understand your guidance: > > > I will remove the explanatory paragraph, but wait for the next rev i need to do > > for IANA/IESG review anyhow. I will keep the suggested name SRV.est. > > check! ack! > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- --- tte@cs.fau.de From nobody Fri Feb 23 15:02:10 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6994126BF7 for ; Fri, 23 Feb 2018 15:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 tnzAhCE0N26v for ; Fri, 23 Feb 2018 15:01:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573C8120725 for ; Fri, 23 Feb 2018 15:01:54 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B810A20090 for ; Fri, 23 Feb 2018 18:09:22 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 43E3180BE3 for ; Fri, 23 Feb 2018 18:01:52 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: <20180223154847.GB7254@faui40p.informatik.uni-erlangen.de> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <005b01d3a95e$f0ba5680$d22f0380$@cdac.in> <18734556-d4a9-560f-724c-09287d4e0f20@gmail.com> <003501d3aa07$a37f0560$ea7d1020$@cdac.in> <3963.1519350905@obiwan.sandelman.ca> <013e01d3ac75$0773ff70$165bfe50$@cdac.in> <20180223154847.GB7254@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 23:01:57 -0000 --=-=-= Content-Type: text/plain 'Toerless Eckert' wrote: >> Now when a pledge wants to validate the JRC, he simply needs to verify >> the signature of MI on the invoice. No communication with MASA or even >> MASA itself is not required. > Yes. I have this picture in my head of a guy (called Scotty ;-) holding > a printed sales receipt with QR-code and trying to show it to his new > router/equipment. ("But, Dr. McCoy how do ya know this guy isn't the guy who invented secure enrollment?") > The classicial representation of an offline voucher is a USB stick and a > pair of sneakers to represent the physcial media and transport channel, > but i like the QR-code too to represent the potential complexities of > offline vouchers. The voucher-on-USB-stick case is represented in the NETCONF work. >> It is just like the way, JRC verifies the pledge using the IDevID certificate issued by MI. > If you have a side-channel to get the voucher into the pledge, yes. But > very often in "professionally managed networks" (ANIMA charter), the guy who > gets the sales receipt could be (hundreds of) miles away from the pledge, > so in those environments its much more likely that any type of offline > voucher can easily be injected into the Registrar first than through a side > channel physcially into the pledge. Additionally, equipement is often shipped directly to the data center where it will be installed. Upon arrival, the *data center* staff can be paid to remove it from the box and physically install it. This is called "remote hands". http://searchdatacenter.techtarget.com/definition/remote-hands http://www.365datacenters.com/services/remote-hands-services/ Remote hands can often be instructed to do things, but it requires a very senior engineer to guide them, because they have to know PRECISELY what should appear and all the situations that could go wrong. I've worked this kind of thing. Too often an operational engineer flies there and does it directly. That's the kind of thing we are working to deal with. Usually all one has the remote hands do is to configure some kind of connectivity. This means today: a) a "lights out" (iLO, iDRAC, etc.) network connection if it's a server. b) a craft (serial) console if it's a router. The ACP document goes into this at length... the point is that BRSKI can bootstrap that equipment even if it's the core routing equipment, as long as the long-haul fiber goes into a compatible optical module. (And the right lambda is used... I'd like to write a specification for auto-detecting that part. I suspect it doesn't need standardization) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqQnV8ACgkQgItw+93Q 3WV4Zgf+P78fTG6w1C1bZhUExfHZYFaLzSOzfT/lfDMf7Y0cn3MZfLdy4lys/4yL m30NoMAytK2UiiWl1WAHTz+05Jr4RVohfc2AhtiRpUzQ1KyD/0ca8J+ZRJn2VeoP NBsomqljlDxHCQe0qHrXne1N9aSKA/kItahJaNs3KdyRGeWb/4nIkYOvOCQbaxov 57D/y/9jvEL+7evx3W3FAolldGV1x7954SIbboNgbUuxBWgmVVzweZbjBO8URnXP LKpXxwsAQ2NW395nyLXKsFvYxoXa9O5kNBW34A8a7n7Pmjvhl2a6vyikq7OCqFTo GjfoMmnjPA5rD56DOzVSLle3ygS8CA== =wb17 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 23 19:28:17 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E7812895E; Fri, 23 Feb 2018 19:28:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia To: Cc: anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151944288538.13853.12008661353663855742@ietfa.amsl.com> Date: Fri, 23 Feb 2018 19:28:05 -0800 Archived-At: Subject: [Anima] Secdir early review of draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 03:28:05 -0000 Reviewer: Liang Xia Review result: Has Issues In general, this document is well-written and considers security issues carefully throughout the whole architecture. nits: Abstract: /or not misconfigured/or misconfigured/ the fifth paragraph of section 6.1: the last ")" is redundant, therefore can be deleted some section titles don't comply the rule of starting from a capital letter section 6.5 /("IP security", see [RFC4301] and "Internet Key Exchange protocol version 2", see [RFC7296]/("IP security", see [RFC4301] and "Internet Key Exchange protocol version 2", see [RFC7296])/ suggestion: all the Figures (e.g., Figure 1,2...) should have a title for explanation section 2, please update the last paragraph to reference RFC8174 to indicate that lowercase versions of the keywords are not normative Section 11 (Security Considerations) Since section 9.2 has described the self-protection properties of ACP well, it may be useful in this section to mention them as a whole. From nobody Fri Feb 23 19:55:29 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC236126BF6 for ; Fri, 23 Feb 2018 19:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hCuiChhMLEoi for ; Fri, 23 Feb 2018 19:55:26 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1931267BB for ; Fri, 23 Feb 2018 19:55:25 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 248EB20090; Fri, 23 Feb 2018 23:02:55 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F40AE80766; Fri, 23 Feb 2018 22:55:23 -0500 (EST) From: Michael Richardson To: Toerless Eckert , anima@ietf.org In-Reply-To: <20180220001837.GA21510@faui40p.informatik.uni-erlangen.de> References: <003101d3a570$32e4c510$98ae4f30$@cdac.in> <22127.1519000017@obiwan.sandelman.ca> <20180220001837.GA21510@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] verification of manufacturer in BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 03:55:28 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > Nonwithstanding the more detailled explanations you provided for Anoop, > what i wuild think to be helpful to write into the security ection is like this: > Domain trusting pledge/manufacturer: I tried to use your text directly, but after some editing it looked completely different. This is what it turned into. Edits welcome, and better references are sought. +8.2. Trusting manufacturers + + The BRSKI extensions to EST permit a new pledge to be completely + configured with domain specific trust anchors. The link from built- + in manufacturer-provided trust anchors to domain-specific trust + anchors is mediated by the signed voucher artifact. + + If the manufacturer's IDevID signing key is not properly validated, + then there is a risk that the network will accept a pledge that + should not be a member of the network. As the address of the + manufacturer's MASA is provided in the IDevID using the extension + from Section 2.3, the malicious pledge will have no problem + collaborating with it's MASA to produce a completely valid voucher. + + BRSKI does not, however, fundamentally change the trust model from + domain owner to manufacturer. Assuming that the pledge used its + IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs + to trust the manufacturer. + + Establishing this trust between domain and manufacturer is outside + the scope of BRSKI. There are a number of mechanisms that can + adopted including: + + o Manually configuring each manufacturer's trust anchor. + + o A Trust-On-First-Use (TOFU) mechanism. A human would be queried + upon seeing a manufacturer's trust anchor for the first time, and + then the trust anchor would be installed to the trusted store. + There are risks with this; even if the key to name is validated + using something like the WebPKI, there remains the possibility + that the name is a look alike: e.g, c1sco.com, .. + + o scanning the trust anchor from a QR code that came with the + packaging (this is really a manual TOFU mechanism) + + o some sales integration process where trust anchors are provided as + part of the sales process, probably included in a digital + packing "slip", or a sales invoice. + + o consortium membership, where all manufacturers of a particular + device category (e.g, a light bulb, or a cable-modem) are signed + by an certificate authority specifically for this. This is done + by CableLabs today. It is used for authentication and + authorization as part of TR-79: [docsisroot] and [TR069]. + + The existing WebPKI provides a reasonable anchor between manufacturer + name and public key. It authenticates the key. It does not provide + a reasonable authorization for the manufacturer, so it is not + directly useable on it's own. + ... Perhaps there are better references, but I'm not particularly clued into them. If there is someone more involved in the CMTS specifications, perhaps you can tell me how to cite this better. + [docsisroot] + CableLabs, , "CableLabs Digital Certificate Issuance + Service", February 2018, + . + [TR069] Broadband Forum, , "TR-69: CPE WAN Management Protocol", + February 2018, . -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqQ4isACgkQgItw+93Q 3WUvHwf/V4NWV00bQA77Hg8oKRNw54/Pr2S3oPh2Z9QPT6rrwJ7/H+nN5/zdEVRj 08ru6KMC9UFGnZZuS7GGzk6PeMJNjz2lSO+2ZiltaEW8fzmWkMz1tVYyUjS0MDGs WkCT8zHasr4xhuhAYtG2E621UKcHWxqkz60Gh3oizZebrKf0kv16SIVuLeQDJ7DA NmAZ5I5Tyqf1RH8z18oCJcNSl3LHlhefTOtq2eQNaYNxkQEi9KDPwsnDmJ+S2AUf L01Q7wHD9Kje7SRomIWC6Swer0wTV/Hevm0Rp+6DoMhk+72xBpCUz5v2VR/RMOSz 0L+bghVa9V9eZ7InVLmDe8ywV82YtA== =eloY -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 25 14:45:50 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8A3124BAC for ; Sun, 25 Feb 2018 14:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kOvt5VpCuWtL for ; Sun, 25 Feb 2018 14:45:46 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9C9124207 for ; Sun, 25 Feb 2018 14:45:46 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id q27so3876401pgn.8 for ; Sun, 25 Feb 2018 14:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KMB87EFL93OvFY4grHuVMZqC2QZH7yoFwWDlXk9RJH8=; b=StnS21lxB4ZnP1RLxNYCWes1LkI9chRdKN4Wf74LtVUQkWHkt0K3Uh4bZVpNU2acvL N3Hf6USNEr8ElxY3fdbHoKn9Rw3w41K8xTrojP1XenkBwwqu51Rliu8kJ38ZsruA/4rL MRyLpryQPyePjlfuTzgymqx9G2QLro6l7xAFkethbnXxEm5lCh3ImYhfT4xiuuQuHO7z Y3wO6LaQUEH3AXf+2qmxeRpWGLKNFJmNSYG3iOu0lGY4Gsw50WUErbAK3PazLY9v+Ufa ah6V/+ceAse92gDU6eUz9OAPvEZpGL8VMxHExV+7VlUqlgNm8E2YvB4faOtXDtW/m1X8 8HSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KMB87EFL93OvFY4grHuVMZqC2QZH7yoFwWDlXk9RJH8=; b=Sn63tHNknXO+vpry2YOjjBdAds15yPaNWY43ZGSQQDwPMaRTjf1mIasEAkoLnAmNBT xBaX3O13m9nnY+atbx5X/N+UHS+eb6WjWqxkt+UjnhrscqeKcXsE8Cf026kpsh5LyIUP sRL8/WGn8fX4VXInIKupik5NLAmCJTwlLKBO0xtkz7L1fI34KUDdO793Mh8nWGxxOH57 C18BCSaBSks1vLiHzesmE7zvsQ9n6abgaBCDo6j5LSaIqVfSY4U85HJh1sOM0yoEbo/S q7RAlIXgHqRG9nxpQKoZcS1DKIkpEfgY0viR3qzQnZ9jDOnagqe/lxkmtqC/TkEmpOuO G5zw== X-Gm-Message-State: APf1xPDb10b7GfYoErsCfc3ejjCh7gOjhAhl6zJC6DK6R25CgHQca1iy 1POJVBYv8Jn4zuvBfnJ0XCM9CylU X-Google-Smtp-Source: AH8x227GRxVK1v2xb+6m9HbK+38NM1xH+UKvxFdSsiMNx3XTJ6BONLVw0j2d6ORADz5RpMJqyB387A== X-Received: by 10.99.188.2 with SMTP id q2mr6958705pge.101.1519598745639; Sun, 25 Feb 2018 14:45:45 -0800 (PST) Received: from [192.168.183.200] ([114.23.138.211]) by smtp.gmail.com with ESMTPSA id c21sm4663814pfi.91.2018.02.25.14.45.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Feb 2018 14:45:45 -0800 (PST) Sender: Brian Carpenter To: anima@ietf.org References: <20180214010910.GA27823@faui40p.informatik.uni-erlangen.de> <23103.1519174480@obiwan.sandelman.ca> <20180221023844.GD23498@faui40p.informatik.uni-erlangen.de> <22048.1519182010@obiwan.sandelman.ca> <20180221151529.GF23498@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <825bb3aa-337b-cc1b-bcc0-8c5706bc2757@gmail.com> Date: Mon, 26 Feb 2018 11:45:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180221151529.GF23498@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 22:45:49 -0000 "may" is an ambiguous word in English, and is probably the main reason we have RFC2119. "It may rain today." == "Rain is possible today." "You may shake my hand." == either (a) "I permit you to shake my hand." or (b) "It is physically possible that you will shake my hand." "You may not shake my hand." == "I forbid you to shake my hand." "It may not rain today." == "Rain is possible today." (In fact the last two are also ambiguous, strictly speaking, but I think most people would interpret them as I suggest. This is why "MAY NOT" is not allowed by RFC 2119.) So lower case non-RFC2119 "may" is a tricky word in an RFC. Sometimes it means "might" or "is possible", sometimes it means "is allowed". I definitely recommend replacing lower-case "may" in a case like the one below. Perhaps: >> , and MUST NOT be >> enabled unless the JRC indicates support for them Regards Brian On 22/02/2018 04:15, Toerless Eckert wrote: > On Tue, Feb 20, 2018 at 10:00:10PM -0500, Michael Richardson wrote: >> >> Yes, that in the thread, where I referred to a thread back in January 2017, >> in which you were involved in coming up with the names. >> >> >> + , and may be >> >> + enabled only if the JRC indicates support for them in it's >> >> + announcement. (See Section 4.4) >> >> > IMHO: sentence eend after "optional". Followed by "all proxy functionally >> > needs to ... be enabled... >> >> > Aka: circuit proxy is a no-op too if the proxy does not discover a registrar >> > supporting it. Not specific to advanced options. >> >> Circuit proxy is a MTI for the JRC, and requires *NO* special support in the JRC. >> If the Registrar doesn't support listening on port 443, then it's not a registrar :-) > > Maybe i just have an english language problems: > > "may (be only enabled) if" implies to me "could also (be enabled) even if not", > but that would not be correct: No version of a proxy can be enabled unless > a registrar has been discovered by the proxy AND that proxy is announcing support for the > proxy method. And that applies to all proxy methods. > > correct language: "can be only enabled if" ? > ^^^ > > If i misunderstand english: what is the difference between may/can in this sentence ? > > circuit-proxy is only MTI for ANI registrars, these sentences are not > constrained to ANI. I would assume in some derived solutions like > 6tisch or the like, registrar may only have non-circuit proxies.. ?! > > Sorry if this is too much nitpicking. > >> > Rephrase ? Don't understand what this means (especially users). "other >> > authors" ? "other docs" ? >> >> If someone is using BRSKI in a non-ANI situation, then that entity should >> explain what kinds of things can occur after voucher. So I prefer to remain mute. > > ah! "user" = "author of followup work". > > Thanks! > Toerles > >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Feb 26 09:26:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C54C12025C; Mon, 26 Feb 2018 09:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRhONc5wkzgf; Mon, 26 Feb 2018 09:26:02 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAFC12D77D; Mon, 26 Feb 2018 09:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57301; q=dns/txt; s=iport; t=1519665961; x=1520875561; h=from:to:cc:subject:date:message-id:mime-version; bh=tFZ0xaeUeP7ECzpRSVbK9+qDkHj8Jj483zpVFmrzrvo=; b=cmLs+/AYf1Hao8tz0lJPsbShtMHJVG+mPgCOgIOmzqGGJndekm/BO/kd yNOCN6oW+2hYyjCh5gmUoIqMSwoMutUagxRtrY1LxgN7/wpwlxZUxW58R ZJkNBuRJ+U5mcjIc/N2uKznTVNWVFw0OuOzVKoklpXA79GPH+qUVPvLDq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQARQpRa/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJadWZwMo1sjX6DGJYFFIICCQEjhRCCR1QYAQIBAQEBAQECayi?= =?us-ascii?q?FRA0GTBIBQAE/JgEEAQ0NE4QRZBCtJDqIbYIUAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGAWGKIEagVeBZoIfhDwBAQOBUgSGCgWKIggPhnWBW45YCQKHN4EZi0WCD4V?= =?us-ascii?q?mg2WHD4xRiHcCERkBgS4BHjiBUXAVGSGCMwEQgkEBHIF7jDuBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.47,397,1515456000"; d="scan'208,217";a="142865849" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 17:25:59 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w1QHPxmY024780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Feb 2018 17:25:59 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 26 Feb 2018 11:25:58 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Mon, 26 Feb 2018 11:25:58 -0600 From: "Pascal Thubert (pthubert)" To: iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" CC: "anima@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" Thread-Topic: An IOT DIR review of draft-ietf-anima-autonomic-control-plane Thread-Index: AdOnCBzSJMKw+zXyQYGzXbZB1Jtadg== Date: Mon, 26 Feb 2018 17:25:58 +0000 Deferred-Delivery: Mon, 26 Feb 2018 17:25:22 +0000 Message-ID: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.212.148] Content-Type: multipart/alternative; boundary="_000_449b7e2f10094531b325919710696754XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 17:26:08 -0000 --_000_449b7e2f10094531b325919710696754XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reviewer: Pascal Thubert on behalf of IOT-DIR; I am an assigned IoT directorate reviewer for draft-ietf-anima-autonomic-co= ntrol-plane-13. These comments were written primarily for the benefit of the INT and OPS Ar= eas Directors from the IoT perspective. Document editors and shepherd(s) sh= ould treat these comments just like they would treat comments from any othe= r IETF contributors and resolve them along with any other Last Call comment= s that have been received. For more details on the IoT Directorate, please = see https://datatracker.ietf.org/group/iotdir/about/ and for Directorates i= n general please see https://www.ietf.org/about/groups/directorates/. I'll be away for the next 2 weeks and could not finish the review in time = for this heavy document, but at least I made it through till the RPL sectio= n. In the interest of time, let me share what I already have. Summary ------------- The summary of the review is that the document is Ready for Publication, wi= th comments. Major comments ------------------------ - " in-band" and "out of band network " should be defined since it is fundamental to understand that the ACP takes = place in the same physical links as the data plane, as opposed to dedicated= management ports (correct?); - Section 3; the IOT certainly could use an ACP. It would be usefu= l to scope the feature that is proposed in this document, whether it is com= patible of not with constrained environments, whether it needs adaptations,= point on Michael's enrollment draft. It would also be useful to indicate w= hether the ACP works between L3 bridges, IOW whether ACP operates the same = (over IP) regardless of the packet forwarding layer in the data plane; - " Inside the ACP VRF, each node sets up a loopback interface with= its ULA IPv6 address" This is the first time, IPv6 is discussed; would have been nice to introduc= e that the Node has IPv6, that it needs a ULA and that ACP assigns it. This= discussion could be done in conjunction with the comment above; - About "The ttl parameter SHOULD be 3.5 times the period so that up to three consecutive messages can be dropped before considering an - announcement expired. " This is the only discussion on the ttl field of the M_FLOOD. Though its mea= ning is quite obvious, the behavior associated to it should be defined. - "In the above (recommended) example the period of sending of the" Is this RECOMMENDED IOW normative?? - Text P 25 says "At this time in the lifecycle of ACP nodes, it is= unclear whether it is feasible to even decide on a single MTI (mandatory to implement) security association protocol across all ACP nodes" but then P27 "It MUST support ESP with AES256 for encryption and SHA256 hash and MUST NOT permit weaker crypto options." and then " A baseline ACP node MUST support IPsec natively and MAY suppor= t IPsec via GRE. A constrained ACP node MUST support dTLS. ACP nodes connecting constrained areas with baseline areas MUST therefore support IPsec and dTLS." Seems that text P25 should go? - "Use-ULA: For loopback interfaces of ACP nodes, we use Unique L= ocal Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193] with L=3D1]." This needs to be more crisp. ULA is defined in RFC 4193 but the term ULA-Ra= ndom is not. I think you mean that 3.2.2. of RFC 4193 is the way addresses= are formed, if so please say so. The best practice RFC 8064 recommends us= e of RFC 7217. I understand that privacy is not a concern but does it hurt?= Anyway please point at section 6.10 and 6.11.1.11 - " RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with multi= cast support". Implementations should support also other modes. Note: Root indicates mode in DIO flow" Why "should" ? there is no much point supporting the other modes is there? = Section 6.11.1.13 says that SRH is not used so this is inconsistent. You on= ly need MOP 2 or 3, 3 is you do multicast which at the moment does not appe= ar to be the case. SO I would MUST a MOP of 2 and MAY a MOP of 3 which is a= superset of MOP 2, and that's it (see 6.3.1 of RFC 6550). - "The lack of a RPI (the header defined by [RFC6553]), means tha= t the data-plane will have no rank value that can be used to detect loops. As a result, traffic may loop until the TTL of the packet reaches zero. " Since we have reliable links and no stretch (section 6.11.1.7), loops shoul= d be exceedingly rare. It could be recommended to send the DIOs 2-3 times t= o inform children when losing the last parent. Note that the technique in s= ection "8.2.2.6. Detaching" of RFC 6550 should be favored over that in sec= tion "8.2.2.5. Poisoning" because it allows local connectivity. Also, It s= hould be said that a node should select more than one parent, at least 3 if= possible, and send DAOs to all of then in parallel. This provides multi - "ACP nodes MUST perform standard IPv6 operations across ACP vir= tual interfaces including SLAAC (Stateless Address Auto-Configuration - RFC4862])" They may actually prefer Optimistic DAD RFC 4429 since address duplication = is highly improbable as long as you . Minor comments ------------------------ - About "[RFC7575] defines the fundamental ... " for readability, it may be nicer to indicate the title of an RFC when it is= referenced first; e.g. the text above would become " Autonomic Networking: Definitions and Design Goals" [RFC7575] defines the= fundamental ... - about "or network plane (there is no well-established name for t= his)" The term network plane is not used again in the document. This text may go = away. You may consider using "security and transport substrate" instead, si= nce it is used elsewhere in the document. Also, please be consistent on whe= ther you use hyphen or not and use that globally, e.g. for the above, and p= ane like in "forwarding plane" or "out of band network "; - "data-plen" Typo? - "OAM applications ("Operations Administration and Management)" Consider using "Operations Administration and Management (OAM) applications= " instead; same goes for SDN, ASA, VRF, etc... - " MIC: "Manufacturer Installed Certificate". Another word no= t used in this document to describe an IDevID." MIC is not used in the document, maybe inform of this equivalence in the ID= evID definition instead; same goes for SUDI. Note that UDI is use just once= and may not need an entry here. - "RPL: \"IPv6 Routing Protocol for Low-Power and Lossy Netw= orks\". The routing protocol used in the ACP." Maybe point on [RFC6550]? - "Connecting over non-ACP Layer-3 clouds initially requires a tunn= el between ACP nodes." I understands that it is one tunnel between each pair of adjacent ACP nodes= , correct? I read "a tunnel" as an end-to-end tunnel, which sounds differen= t - "ACP relies on group security" Add "The" - "An ACP node MUST have keying material consisting of a certificate (LDevID), with which it can cryptographically assert its membership in the ACP domain and trust anchor(s) associated with that certificate with which it can verify the membership of other nodes (see Section 6.1.2)." This is convoluted. Could you make it 2 sentences? - " Note: LDevID ("Local Device IDentification") is the term used = to indicate a certificate that was provisioned by the owner of a node as opposed to IDevID ("Initial Device IDentifier") that may has been loaded on the node during manufacturing time. Those IDevID do not include owner and deployment specific information to allows autonomic establishment of trust for the operations of an ACP domain (e.g.: between two ACP nodes without relying on any third party)." LDevID was already defined in the terminology. This text may move there or = go away. - " This document uses the term ACP in many places where its ref= erence document use the word autonomic." Add [RFC7575] after "reference document" - " "routing-subdomain" is the autonomic subdomain that is used = to calculate the hash for the ULA prefix of the ACP address of the node." Do you mean ULA suffix? - " o If the node certificates indicate a CDP (or OCSP) then th= e peer's certificate must be valid according to those criteria. e.g.: OCSP check across the ACP or not listed in the CRL retrieved from the CDP." Please define CDP and OSCP, and/or reference a RFC is possible. Helper: Online Certificate Status Protocol (OCSP) Certificate Revocation L= ist (CRL) Distribution Point (CDP) - "enrolment" Typo - "This can use a single GRASP M_FLOOD message as shown in above example." Actually the example is now below. Please reference the figure. - "The protocol could for example could have been" Typo - "if the IPsec connecting" Typo? - "ACP wide service discovery" ACP-wide - "if the IPsec connecting In most other solution designs such distributed discovery does not exist at all or was added as an afterthought and relied upon inconsistently" Consider removing or rephrasing : ) - Maybe consider moving the discussion on multicast P29 -30 to anne= x? Why Multicast is not used is an interesting discussion but not critical = for the protocol operation. - "it is not quite clear yet what exactly the implications are to make GRASP flooding depend on RPL DODAG convergence and how difficult it would be to let GRASP flooding access the DODAG information" Let's chat then. There's work on reliable multicast for RPL using BIER. - "In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is= the security and transport substrate for the GRASP instance run inside the ACP ("ACP GRASP"). " "running" inside the ACP? Maybe rephrase more globally? - - "OAM protocols no not require IPv4: The ACP may carry OAM " Typo no->do - "Consider a network that has multiple NOCs in different locatio= ns. Only one NOC will become the DODAG root. Other NOCs will have to send traffic through the DODAG (tree) rooted in the primary NOC." A figure would help. I remember all the discussions we had about setting th= e prf bits in remote NOCs - "RPPL." Typo - "Administrative Preference ([RFC6552], 3.2.6 " The section is correct but that is RFC 6550. - "This is a standard issue with tunneling, not specific to running the ACP across it." Do you really mean Standard or would Classical work better? - "Even though loopback interfaces where originally d" Typo Where -> were - Section 3, 4, 9 and 10 may move to Annex (by moving the section a= fter the tag) since they are not normative and do not contrib= ute to the understanding of the protocol. This way there should not be a ne= ed to indicate normative in other sections. - Well Noted that Section 14 Will be removed/. Sorry for being interrupted here, Pascal --_000_449b7e2f10094531b325919710696754XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reviewer: Pascal Thubert on behalf of IOT-DIR;

 

I am an assigned IoT directorate reviewer for dra= ft-ietf-anima-autonomic-control-plane-13.

 

These comments were written primarily for the ben= efit of the INT and OPS Areas Directors from the IoT perspective. Document = editors and shepherd(s) should treat these comments just like they would tr= eat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been re= ceived. For more details on the IoT Directorate, please see https://datatr= acker.ietf.org/group/iotdir/about/ and for Directorates in general plea= se see https://www.iet= f.org/about/groups/directorates/.

 

I’ll be away for  the next 2 weeks and= could not finish the review in time for this heavy document, but at least = I made it through till the RPL section. In the interest of time, let me sha= re what I already have.

 

Summary

-------------

 

The summary of the review is that the document is= Ready for Publication, with comments.

 

 

Major comments

------------------------

 

-       = ;   “ in-band” and “out of band = network “

should be defined since it is fundamental to unde= rstand that the ACP takes place in the same physical links as the data plan= e, as opposed to dedicated management ports (correct?);

 

-       = ;   Section 3; the IOT certainly could use an ACP= . It would be useful to scope the feature that is proposed in this document= , whether it is compatible of not with constrained environments, whether it= needs adaptations, point on Michael’s enrollment draft. It would also be useful to indicate whether the ACP work= s between L3 bridges, IOW whether ACP operates the same (over IP) regardles= s of the packet forwarding layer in the data plane;

 

-       = ;  “ Inside the ACP VRF, each node sets up a loopback interface with it= s ULA IPv6 address”

This is the first time, IPv6 is discussed; would hav= e been nice to introduce that the Node has IPv6, that it needs a ULA and th= at ACP assigns it. This discussion could be done in conjunction with the co= mment above;

 

-       = ;  About  “The ttl

parameter SHOULD be 3.5 times the period so= that up to three

consecutive messages can be dropped before = considering an

-       = ;    announcement expired. “

This is the only discussion on the ttl field of t= he M_FLOOD. Though its meaning is quite obvious, the behavior associated to= it should be defined. 

 

-       = ;  “In the above (recommended) example the period of sending of the”

Is this RECOMMENDED IOW normative??

 

-       = ;  Text P 25 says “At this time in the lifecycle of ACP nodes, it is un= clear whether it

is feasible to even decide on a single MTI = (mandatory to implement)

security association protocol across all AC= P nodes”

but then P27 “= It MUST support ESP

with AES256 for encryption and SHA256 hash = and MUST NOT permit weaker

crypto options.”

and then “&nbs= p;  A baseline ACP node MUST support IPsec natively and MAY support IPsec<= /o:p>

via GRE. A constrained ACP node MUST suppor= t dTLS.  ACP nodes

connecting constrained areas with baseline = areas MUST therefore

support IPsec and dTLS.”<= /o:p>

Seems that text P25 should go?

 

 

-       = ;    “Use-ULA: For loopback interfaces of ACP nodes, we use U= nique Local

Addresses (ULA), specifically ULA-Random, a= s defined in [[RFC4193]

with L=3D1].”

This needs to be more crisp. ULA is defined in RF= C 4193 but the term ULA-Random is not. I think you mean that 3.2.2.  o= f RFC 4193 is the way addresses are formed, if so please say so.  The = best practice RFC 8064 recommends use of RFC 7217. I understand that privacy is not a concern but does it hurt? Anyway = please point at section 6.10 and 6.11.1.11

 

 

-       = ;    “

RPL Mode of Operations (MOP): mode 3 "= Storing Mode of Operations with multicast support".  Implementati= ons should support also other modes.

Note: Root indicates mode in DIO flow”= ;

Why “should” ? there is no much point= supporting the other modes is there? Section 6.11.1.13 says that SRH is no= t used so this is inconsistent. You only need MOP 2 or 3, 3 is you do multi= cast which at the moment does not appear to be the case. SO I would MUST a MOP of 2 and MAY a MOP of 3 which is a superse= t of MOP 2, and that’s it (see 6.3.1 of RFC 6550).

 

 

-       = ;    “The lack of a RPI (the header defined by [RFC6553]), me= ans that the

data-plane will have no rank value that can= be used to detect loops.

As a result, traffic may loop until the TTL= of the packet reaches

zero. ”

Since we have reliable links and no stretch (sect= ion 6.11.1.7), loops should be exceedingly rare. It could be recommended to= send the DIOs 2-3 times to inform children when losing the last parent. No= te that the technique in section “8.2.2.6.  Detaching” of RFC 6550 should be favored over that in section “= ;8.2.2.5.  Poisoning” because it allows local connectivity. Also= , It should be said that a node should select more than one parent, at leas= t 3 if possible, and send DAOs to all of then in parallel. This provides multi

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  

 

-       = ;    “ACP nodes MUST perform standard IPv6 operations across = ACP virtual

interfaces including SLAAC (Stateless Addre= ss Auto-Configuration -

RFC4862])”

They may actually prefer Optimistic DAD RFC 4429 = since address duplication is highly improbable as long as you .<= /p>

 

 

Minor comments

------------------------

 

 

-       = ;  About “[RFC7575] defines the fundamental ...  “

for readability, it may be nicer to indicate the = title of an RFC when it is referenced first; e.g. the text above would beco= me

" Autonomic Networking: Definitions and Desi= gn Goals" [RFC7575] defines the fundamental ...  

 

-       = ;  about “or network plane (there is no well-established name  for= this)”

The term network plane is not used again in the d= ocument. This text may go away. You may consider using "security and transport substrate" instead, since it is used elsewhere in the document. Also, please be consistent on whether you use hyphen or not and use that g= lobally, e.g. for the above, and pane like in “forwarding plane” or “out of band netw= ork “;

 
-         "data-plen” 
Typo? 
 

-       = ;  “OAM applications ("Operations Administration and Management)"

Consider using “Operations Administration a= nd Management (OAM) applications “ instead; same goes for SDN, ASA, V= RF, etc…

 

-       = ;   “   MIC:  "Manufacturer Installed Certific= ate".  Another word not used in this document to describe an IDev= ID.”

MIC is not used in the document, maybe inform of = this equivalence in the IDevID definition instead; same goes for SUDI. Note= that UDI is use just once and may not need an entry here.

 

-       = ;        “RPL:  \"IPv6 Routing = Protocol for Low-Power and Lossy Networks\".  The routing protoco= l used in the ACP.”

Maybe point on [RFC6550]?

 

-       = ;  “Connecting over non-ACP Layer-3 clouds initially requires a tunnel = between ACP nodes.”

I understands that it is one tunnel between each = pair of adjacent ACP nodes, correct? I read “a tunnel” as an en= d-to-end tunnel, which sounds different

 

-       = ;   “ACP relies on group security”

Add “The”

 

-       = ;   “An ACP node MUST have keying

   material consisting of a certi= ficate (LDevID), with which it can

     cryptographically assert its membership in the ACP d= omain and trust

     anchor(s) associated with that certificate with whic= h it can verify

     the membership of other nodes (see Section 6.1.2).&#= 8221;

This is convoluted. Could you make it 2 sentences= ?

 

-       = ;  “  Note: LDevID ("Local Device IDentification") is th= e term used to

     indicate a certificate that was provisioned by the o= wner of a node as

opposed to IDevID ("Initial Device IDe= ntifier") that may has been

loaded on the node during manufacturing tim= e.  Those IDevID do not

include owner and deployment specific infor= mation to allows autonomic

establishment of trust for the operations o= f an ACP domain (e.g.:

between two ACP nodes without relying on an= y third party).”

LDevID was already defined in the terminology. Th= is text may move there or go away.

 

-       = ;   “   This document uses the term ACP in many places w= here its reference

document use the word autonomic.R= 21;

Add [RFC7575] after “reference documentR= 21;

 

 

-       = ;   “   "routing-subdomain" is the autonomic s= ubdomain that is used to

calculate the hash for the ULA prefix of th= e ACP address of the node.”

Do you mean ULA suffix?

 

-       = ;   “   o  If the node certificates indicate a CDP = (or OCSP) then the peer's

certificate must be valid according to thos= e criteria. e.g.: OCSP

check across the ACP or not listed in the C= RL retrieved from the

CDP.”

Please define CDP and OSCP, and/or reference a RF= C is possible. 

Helper: Online Certificate Status Protocol (OCSP)=   Certificate Revocation List (CRL) Distribution Point (CDP)

 

-       = ;   “enrolment”

Typo

 

-       = ;   “This can

use a single GRASP M_FLOOD message as shown= in above example.”

Actually the example is now below. Please referen= ce the figure.

 

-       = ;    “The protocol could for example could have been&#= 8221;

Typo

 

 

-       = ;    “if the IPsec connecting”

Typo?

 

-       = ;    “ACP wide service discovery”

ACP-wide 

 

-       = ;    “if the IPsec connecting In most other solution<= o:p>

designs such distributed discovery does not= exist at all or was added

as an afterthought and relied upon inconsis= tently”

Consider removing or rephrasing : )

 

-       = ;  Maybe consider moving the discussion on multicast P= 29 -30 to annex? Why Multicast is not used is an interesting discussion but= not critical for the protocol operation.

 

-       = ;    “it is not quite clear yet what exactly the implications= are

to make GRASP flooding depend on RPL DODAG = convergence and how

difficult it would be to let GRASP flooding= access the DODAG

information”

Let’s chat then. There’s work on reli= able multicast for RPL using BIER.

 

-       = ;  “In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is th= e

security and transport substrate for the GR= ASP instance run inside

the ACP ("ACP GRASP"). ”

“running” inside the ACP? Maybe rephr= ase more globally?

-       = ;   

 

 

-       = ;    “OAM protocols no not require IPv4: The ACP may carry OA= M ”

Typo no->do

 

 

-       = ;    “Consider a network that has multiple NOCs in different = locations.

Only one NOC will become the DODAG root.&nb= sp; Other NOCs will have to

send traffic through the DODAG (tree) roote= d in the primary NOC.”

A figure would help. I remember all the discussio= ns we had about setting the prf bits in remote NOCs

 

 

-       = ;    “RPPL.”

Typo

 

 

-       = ;    “Administrative Preference ([RFC6552], 3.2.6  ̶= 1;

The section is correct but that is RFC 6550.=

 

 

-       = ;    “This is a standard issue

with tunneling, not specific to running the= ACP across it.”

Do you really mean Standard or would Classical wo= rk better?

 

 

-       = ;    “Even though loopback interfaces where originally d”

Typo Where -> were

 

 

 

-       = ;  Section 3, 4, 9 and 10 may move to Annex (by moving= the section after the </references> tag) since they are not normativ= e and do not contribute to the understanding of the protocol. This way ther= e should not be a need to indicate normative in other sections.

 

-       = ;  Well Noted that Section 14 Will be removed/.

 

 

Sorry for being interrupted here,

 

Pascal

 

--_000_449b7e2f10094531b325919710696754XCHRCD001ciscocom_-- From nobody Mon Feb 26 13:17:48 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADC3129C6C; Mon, 26 Feb 2018 13:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WxzgtefgSHyl; Mon, 26 Feb 2018 13:17:14 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202A212711E; Mon, 26 Feb 2018 13:17:06 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id w17so6670904pgv.6; Mon, 26 Feb 2018 13:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YdLq5XxcOEgM7PPKW3A1TfpJ8E5WCyqDkqRhaGsXeZo=; b=dKv2DFcmSfk8Y9sbVK4uP05jACVpnmwB5gJRg6lcGTWkPgW+fCqDsokCDtOiwljnky /g9XWU6Sn7F1gvQdBOl/m9BrpKFP61kEnG1Cl+Jg08E+svw8lHr1ks8F1Q9IuAhgURqf aFHrVyc6ifhCo/or/oVFgYS0NkpNC4RCIKF0t5jDJHqCRt9RNo8hDz1nO7S10bcvyuly GUrFxqPGqwe/oNxVRlnXYAuBuh0FePgtbO0csz2aLdDjn6Q/PEWbQXDc8xczLvhw/Cuq KVH6JPCwkEWToBeZKoIX7K/l2TAV1mVHSJGGnh2/uC5CCtwOZ/xMCmtru9WXaVW7pINu TyFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YdLq5XxcOEgM7PPKW3A1TfpJ8E5WCyqDkqRhaGsXeZo=; b=kCJ6OpHU0gRdJfAWRqeNARhWf985u2hDzIT0FNlfj7M1y3i6pu1xe1bMQiUPGZQwDv MIt5zEv4fE47PEmXjHi9QDhB/ie75FK6KHqxs35yytS1TumYsk63xSoZUWZxQzOARvZR XxyjnpTFB9pINUsUTKOPQQJRiopRMryBnsX1shIci61RJB3JR6zs1g8WwFdMxwtsSWSy cljHo0obVVf/P5qn69fbuVyGM+ZcMI6VPc4/LImf0n1Lmh9qQ35ZtNp3BN97M7fJ6wjr 79vYDhbsGXuIHwdvFvs0nwxQXDTTcaYsKyrfvGiiMl07XgxVjHnVhy9ilBlknvDGlDMq cH1A== X-Gm-Message-State: APf1xPB3QLl1/voU0T+GHjK5iWGmkBGxNGL5Zv4jjp0nnfnu+og+iUeE 8QZSNnivCHFLmHa3qJAx8sPepuw/1KM= X-Google-Smtp-Source: AG47ELtbsC91WHyjvhl8Htb6q6nVR08nSWhszD33gzwsVFrHXW6H9EIkzC7yFQD57ZEfFm8sQPGy/Q== X-Received: by 10.98.178.17 with SMTP id x17mr2510001pfe.2.1519679825361; Mon, 26 Feb 2018 13:17:05 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id x86sm20974282pfa.164.2018.02.26.13.17.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 13:17:04 -0800 (PST) Sender: Brian Carpenter To: "Pascal Thubert (pthubert)" , iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" Cc: "draft-ietf-anima-autonomic-control-plane@ietf.org" , "anima@ietf.org" References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> From: Brian E Carpenter Message-ID: Date: Tue, 27 Feb 2018 10:17:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 21:17:34 -0000 Pascal, Great review! > - Section 3; the IOT certainly could use an ACP. It would be useful to scope the feature that is proposed in this document, whether it is compatible of not with constrained environments, whether it needs adaptations, point on Michael's enrollment draft. It would also be useful to indicate whether the ACP works between L3 bridges, IOW whether ACP operates the same (over IP) regardless of the packet forwarding layer in the data plane; Perhaps this point belongs in draft-ietf-anima-reference-model. ANIMA is chartered for "professionally managed" networks, and the reference model says: "At a later stage ANIMA may define a scope for constrained nodes with a reduced ANI [autonomic infrastructure] and well-defined minimal functionality. They are currently out of scope." So while your point is very valid, it's been considered out of scope so far. I'll leave the rest of your excellent comments to the ACP authors. Thanks Brian From nobody Mon Feb 26 13:22:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFAC12D877 for ; Mon, 26 Feb 2018 13:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sgwNDp5GCp-W for ; Mon, 26 Feb 2018 13:22:05 -0800 (PST) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFCD12711E for ; Mon, 26 Feb 2018 13:22:00 -0800 (PST) Received: by mail-pl0-x231.google.com with SMTP id d4so10029323pll.5 for ; Mon, 26 Feb 2018 13:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=mrjvsGfCon4v1jduI/h7Y3MMi5abb9bR/dIuvzwcP5g=; b=IwoXOb9sGAFaVjeB53y40tTWV8LpvmMRwv703lHHlLOIS3qcGjZKVzGcUE5x+0Vr+f /jO0S3erVotJg/nic1WBp7/g7bEs3Vy+dKADCyR6vDtSvgovJPKf8fD9eEMK5T1p+Buw HWiHqSg0YsjGz/omMjurz1ucaet1ZqOxFKELXEUg83BQ6xb+/XkEV1/lbT5tTz9VC8IT NYvecW+QePhvYOOklScyXvHTwhuWnvhcwdtqtvzCSiBM2BfSAIDhFVPwWDHFIa5ZUQeL T5ihrXLNXpc77fY2HRSC+fDLpkT2gRYcyhHCr6iuC84i+OrfL7EEeWcFq4KWdvDnZHVe YrVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=mrjvsGfCon4v1jduI/h7Y3MMi5abb9bR/dIuvzwcP5g=; b=RanPyARJuytYaLQ6OoPV6cXjpA3JweWSx/j6mVi4pSv8IzPNfFs6k0SeP7POKUSDEU DgllVULeubSaWoThtZTS6VvxZ5agoKa1ywIX6yjPwqttneE0IsaNtrI5/Xao4BPHKnMS 62MOKNHO7g7zpYMneiGsGwuErzWXzWz8fqy1APTm7PhvbNmB/sdLQ/qWYwQ1nmARvJVo pyXlmzjyHok675/UmfEshT+e+FQasGFMDtmhr2kWZXvYZwWAVTbKS1JcYHDk6moCcMaY H5XMUQ508ZZqo4lWRetJs02kfyspqcvPEjXV2hFAQswCTr5itEfKW5rfo2xN6u685FAB xYUA== X-Gm-Message-State: APf1xPDEGvatqyCVnHyv5ndxjHEskxtoFj0IVTLvL1AC0Zy7twbfrFU8 WUSvIM/lomdAguJezTn/bmffYQmq X-Google-Smtp-Source: AH8x227dxkVKhEts1cBkjONPupPPP8W68hcFrdLSJHgawcquAac66xwLNt88hhIaU0CTc18SZWk1rQ== X-Received: by 2002:a17:902:b185:: with SMTP id s5-v6mr11842639plr.109.1519680119423; Mon, 26 Feb 2018 13:21:59 -0800 (PST) Received: from [130.216.38.97] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.97]) by smtp.gmail.com with ESMTPSA id r30sm12637790pff.7.2018.02.26.13.21.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 13:21:58 -0800 (PST) Sender: Brian Carpenter To: Anima WG From: Brian E Carpenter Message-ID: Date: Tue, 27 Feb 2018 10:21:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] "professionally managed" and the reference model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 21:22:07 -0000 While looking at Pascal's ACP review, I noticed that although ANIMA scope is limited by charter to "professionally managed" networks, we do not mention that scope in draft-ietf-anima-reference-model. It seems like something to be added to the Introduction. Comments? Regards Brian Carpenter From nobody Mon Feb 26 14:14:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6358126C2F for ; Mon, 26 Feb 2018 14:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.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 pidS15iDJnRz for ; Mon, 26 Feb 2018 14:14:22 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id B97801272E1 for ; Mon, 26 Feb 2018 14:14:22 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 448896C0064; Mon, 26 Feb 2018 17:14:22 -0500 (EST) Received: from imshyb01.MITRE.ORG (unknown [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 368C66C005F; Mon, 26 Feb 2018 17:14:22 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 26 Feb 2018 17:14:21 -0500 Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Mon, 26 Feb 2018 17:14:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=58Vz1mglKS4IlqjQHqj7Dkn9Zk1IlEkpmh/cv9xkQ+Y=; b=aWM+K6KdnSD2qKz851AV/qjKfDqfWPUbFwmZDVmDh9iPPPwm21MqL2FbJw7b0g3GToKL/DfMKruH45ryF3JdH1BIP2in2ZUFyTm6yAHWtTIKHir4JO15f2ynNnfO9+6byeZkVSJfh/gCk9wg6cL8YFwmKWNaRSgjISiQSZBaztA= Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0921.namprd09.prod.outlook.com (10.163.89.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 26 Feb 2018 22:14:20 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.20.0506.028; Mon, 26 Feb 2018 22:14:20 +0000 From: "Natale, Bob" To: Brian E Carpenter CC: Anima WG Thread-Topic: [Anima] "professionally managed" and the reference model Thread-Index: AQHTr0fdswPRdDChdUOKTxSaMCBMZ6O3PnSg Importance: low X-Priority: 5 Date: Mon, 26 Feb 2018 22:14:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=RNATALE@mitre.org; x-originating-ip: [192.80.55.88] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR09MB0921; 7:zh9LO9niTFkWtr60pMjqB9I7cCP0x1Np0EzxGsD7CO7GDC0dfvlN6YbHGG4Gxl29/ryOkxIQaAo9kZx2tOeA4plymzQGKN/370X4eKlncbCnO4b26mlTfMiZAo4uEVe+jW1VfFqFCSw5ZO3G5zxrey78FfMmk2lJKcWnmZDvACE960vGs2ROx4ZQEy3olZh+ceUeAK1ouAYxUCxZRZN2T+N6cpmo6fFgysJwrSBVwGh4r2P1RJ1fOcxHKxTayQNV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 84a9e1df-6f17-43eb-4755-08d57d6648ce x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:CY1PR09MB0921; x-ms-traffictypediagnostic: CY1PR09MB0921: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231220)(944501161)(52105095)(93006095)(93001095)(3002001)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY1PR09MB0921; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0921; x-forefront-prvs: 05954A7C45 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(366004)(346002)(39860400002)(376002)(13464003)(189003)(199004)(68736007)(59450400001)(229853002)(6306002)(6916009)(14454004)(6436002)(6506007)(2950100002)(53936002)(966005)(2900100001)(8936002)(9686003)(6246003)(72206003)(81686011)(97736004)(74316002)(55016002)(5660300001)(2906002)(6116002)(186003)(3846002)(76176011)(53546011)(39060400002)(7696005)(102836004)(4326008)(105586002)(25786009)(86362001)(26005)(77096007)(316002)(66066001)(81166006)(478600001)(305945005)(3660700001)(33656002)(7736002)(99286004)(3280700002)(8676002)(81156014)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0921; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) x-microsoft-antispam-message-info: lxdeq3hUehLMBohtfFlSui28xG8zxAecKY0c3fmo9OVYLu+Cf6HrBsKi+6wQbBrf5JJpzYZZD4s0E2h3lDux3g2uBdCNY5MgpKT71CDV3D2+9DHVkq9WgQpotpC3YdZNjQvb2iK7ABJrdPKMAxrsVmTFBFJdpI1wYsI4QB6TBWc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 84a9e1df-6f17-43eb-4755-08d57d6648ce X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2018 22:14:20.3000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0921 X-OriginatorOrg: mitre.org X-MITRE: 8GQsMWxq66rxk57w Archived-At: Subject: Re: [Anima] "professionally managed" and the reference model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 22:14:25 -0000 THVya2VyIHF1ZXN0aW9uIChhbmQgYSBwcmVkaWN0YWJsZSBvbmUgYXQgdGhhdCk6IFdoYXQgZG9l cyBpdCBtZWFuIHRvIGJlICJwcm9mZXNzaW9uYWxseSBtYW5hZ2VkIj8gSSBhbSBzdXJlIHdlIGNh biBhbGwgdGhpbmsgb2YgbXVsdGlwbGUgcmVhc29uYWJsZSBkZWZpbml0aW9ucywgYnV0IGl0IHNl ZW1zIHdlIG5lZWQgdG8gaGF2ZSBhbiBleHBsaWNpdCBzdGF0ZW1lbnQgb2YgdGhlIG9uZSB3ZSdy ZSB1c2luZyB0byBjb25zdHJhaW4gdGhlIHNjb3BlIG9mIEFOSU1BLg0KDQpNb3JlIGltcG9ydGFu dCBwZXJoYXBzIChhbmQgZG9uJ3QgZm9yZ2V0IHRoZSBsdXJrZXIgc3RhdHVzISksIG9uZSB2YWx1 ZSBvZiB0ZWNobm9sb2dpZXMgbGlrZSBBTklNQSBtaWdodCB3ZWxsIGJlIHRvIGJldHRlciBtYW5h Z2UgbmV0d29ya3MgdGhhdCBkbyBub3QgaGF2ZSBhIHN1ZmZpY2llbnQgbGV2ZWwgb2YgcHJvZmVz c2lvbmFsIHJlc291cmNlcyBzdXBwb3J0aW5nIHRoZW0gaW4gdGhlIGZpcnN0IHBsYWNlLi4uPw0K DQpBdmFudGksDQpCb2JODQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbmlt YSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFIENh cnBlbnRlcg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNiwgMjAxOCA0OjIyIFBNDQpUbzogQW5p bWEgV0cgPGFuaW1hQGlldGYub3JnPg0KU3ViamVjdDogW0FuaW1hXSAicHJvZmVzc2lvbmFsbHkg bWFuYWdlZCIgYW5kIHRoZSByZWZlcmVuY2UgbW9kZWwNCg0KV2hpbGUgbG9va2luZyBhdCBQYXNj YWwncyBBQ1AgcmV2aWV3LCBJIG5vdGljZWQgdGhhdCBhbHRob3VnaCBBTklNQSBzY29wZSBpcyBs aW1pdGVkIGJ5IGNoYXJ0ZXIgdG8gInByb2Zlc3Npb25hbGx5IG1hbmFnZWQiIG5ldHdvcmtzLCB3 ZSBkbyBub3QgbWVudGlvbiB0aGF0IHNjb3BlIGluIGRyYWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNl LW1vZGVsLg0KSXQgc2VlbXMgbGlrZSBzb21ldGhpbmcgdG8gYmUgYWRkZWQgdG8gdGhlIEludHJv ZHVjdGlvbi4NCg0KQ29tbWVudHM/DQoNClJlZ2FyZHMNCiAgIEJyaWFuIENhcnBlbnRlcg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBbmltYSBt YWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FuaW1hDQoNCg== From nobody Mon Feb 26 14:35:34 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3106312711A for ; Mon, 26 Feb 2018 14:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9a-eH4vRM29l for ; Mon, 26 Feb 2018 14:35:30 -0800 (PST) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871EB127333 for ; Mon, 26 Feb 2018 14:35:30 -0800 (PST) Received: by mail-pl0-x231.google.com with SMTP id s13so10144450plq.6 for ; Mon, 26 Feb 2018 14:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cEyQrSOXwCDgNuy8EJ9VDHm8hdNdmOPNOY6eJuRzTbc=; b=Aj0C2G1dun3kuOgQ+wC8twrVQCjx34qX6hfQAckPlLEML2HmFSeZL+M0Bj5GuigyXa GMPP8uCYS+3pMivYZNSJhhGDrkpJ2V0Ej9GSxgmECWle38IcM1WswjctbpKqp8Nu6wV0 uSDM0ruq9aJlkslgnMs4/XaBMf5zCrDNOov08lZbIXcputRIMZNN1uBmcBzUOzrZYquo UGfbgV6pXhGcWlTWJnfno1res2AAaK/mJ+iB0W40WPX4Ou2NmnZQ1z3+FbCS9oiV/wyi S9E9XZFT4/Iwx/YsPHRukCiOg9p6lyapNILhx5be94vyBRfSN1uD5iQ+FiGpaQgDtlIq TI0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cEyQrSOXwCDgNuy8EJ9VDHm8hdNdmOPNOY6eJuRzTbc=; b=Plm9IcidMCBDMq2sj/YqKrqXZW7gqbXv4WCNKCdDgL/H72N0DMnuJqcTHyM4l8nyMP ETnVsknHrJsBRugqptiCAkzMOHvNHG2prbaDBRC2vUZ+0Gz0Sg3V6eNtIshRyEqu7jny Tu5uwk4IuofDl1yfO047S8ma5aJbyAlWNY8p4RvZTqzm5CY2RE5KMpEKBlbDhiy56PNR iWEceXz04Wpg7GNZ1tAyEjX0JZtrKnEsAReaTG0lsZGAXHK/kCG5UiaS/M341lMi/qOF 8DNvr3BsxGLmJqqWDYCO6Rb/pF89o90VSkXnc1fERq7WcR2ChlduAYQ2Lnx7ww5ixUeQ 9L9Q== X-Gm-Message-State: APf1xPBs2uscEUEINMSBfa4XUvF9EPrIOp+taORxHcvK5S8puqiB6xs7 VtrBWddUBc5tWnmQ9C+iGI5zoZFN X-Google-Smtp-Source: AH8x2276dVzaP094DnZzm+XSMaS9doRfjr8kV7avqPSS9EM+vk1MFWNPWdsD0CdD+Xcxe6qAQ/LsTA== X-Received: by 2002:a17:902:2803:: with SMTP id e3-v6mr12005737plb.238.1519684529900; Mon, 26 Feb 2018 14:35:29 -0800 (PST) Received: from [130.216.38.97] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.97]) by smtp.gmail.com with ESMTPSA id q17sm8347333pgt.7.2018.02.26.14.35.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 14:35:29 -0800 (PST) Sender: Brian Carpenter To: "Natale, Bob" Cc: Anima WG References: From: Brian E Carpenter Message-ID: Date: Tue, 27 Feb 2018 11:35:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] "professionally managed" and the reference model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 22:35:32 -0000 On 27/02/2018 11:14, Natale, Bob wrote: > Lurker question (and a predictable one at that): What does it mean to be "professionally managed"? I am sure we can all think of multiple reasonable definitions, but it seems we need to have an explicit statement of the one we're using to constrain the scope of ANIMA. Yes, we probably need to add a few words. The discussion in https://tools.ietf.org/html/rfc7575#section-3.2 applies, I think, even though it doesn't use the word "professional". The idea is that there is a NOC, there are skilled human operators, and we have to co-exist with traditional management tools. > More important perhaps (and don't forget the lurker status!), one value of technologies like ANIMA might well be to better manage networks that do not have a sufficient level of professional resources supporting them in the first place...? Oh, I think we agree on that as the long-term goal. But we were specifically chartered to avoid clashing with the HOMENET WG, where clearly pure plug-and-play is the goal. Brian > > Avanti, > BobN > > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Monday, February 26, 2018 4:22 PM > To: Anima WG > Subject: [Anima] "professionally managed" and the reference model > > While looking at Pascal's ACP review, I noticed that although ANIMA scope is limited by charter to "professionally managed" networks, we do not mention that scope in draft-ietf-anima-reference-model. > It seems like something to be added to the Introduction. > > Comments? > > Regards > Brian Carpenter > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Feb 27 03:06:22 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAD91273B1 for ; Tue, 27 Feb 2018 03:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 Z6xTZOE-cfD6 for ; Tue, 27 Feb 2018 03:06:19 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A521204DA for ; Tue, 27 Feb 2018 03:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2872; q=dns/txt; s=iport; t=1519729579; x=1520939179; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NVfNd/cpGBsp/C5YQL41VBHXBW+mUapX84S+mAeMsBw=; b=fXIoUg89p5i+Z1Ghee2ACq6Dgi804y0frNQWgXRpfCCrvjEt2Vu8JX/k KbQXHGN4ZQ2CWxIFTdqwdMgDBMKhfCiynHU6h7gDXZnWKbmebOXvH8Hx3 jxC1B3DKh15Aj6zjU7MZQT8fBMh/nIiQnBY34UCbd64kWylYkhRM6fZQN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAABiOpVa/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNQZnAoCo1sjX+CAoEWlCqCFQoYDYFbgzICgkpUGAECAQEBAQE?= =?us-ascii?q?BAmsohSMBAQEEAQE4LQcLBQcEAgEIDgMEAQEBHgkHJwsUCQgCBAENBQiFDRCtK?= =?us-ascii?q?ohwghQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYYugRqBV4Fmgy2DLgEBgVuGBQW?= =?us-ascii?q?aTgkChk6KGI59iXqHKQIRGQGBLQEeOIFRcBU6gkOCQxyBe3eMJ4EXAQEB?= X-IronPort-AV: E=Sophos;i="5.47,400,1515456000"; d="scan'208";a="361291194" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2018 11:06:18 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w1RB6IAj014811 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Feb 2018 11:06:18 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 27 Feb 2018 05:06:17 -0600 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Tue, 27 Feb 2018 05:06:17 -0600 From: "Owen Friel (ofriel)" To: Toerless Eckert , Michael Richardson CC: "Max Pritikin (pritikin)" , "Eliot Lear (elear)" , "anima@ietf.org" Thread-Topic: [Anima] BRSKI over 802.11 Thread-Index: AQHTpbS80kr8dImS10GyGhws45k3TKOkp4YAgAABSoCAATh3oIAAjAeAgACdrhCAAJidAIAAFaSAgBBw3KA= Date: Tue, 27 Feb 2018 11:06:17 +0000 Message-ID: <179832fc3cae4ba0bef3f3167deda795@XCH-RCD-012.cisco.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C7960181@nkgeml514-mbx.china.huawei.com> <1CD3D5E0-AFB4-426F-A065-AB1CA3203387@cisco.com> <20180214165601.GB27823@faui40p.informatik.uni-erlangen.de> <31460.1518635300@obiwan.sandelman.ca> <20180214191257.GC27823@faui40p.informatik.uni-erlangen.de> <7255.1518732749@obiwan.sandelman.ca> <3188.1518799384@obiwan.sandelman.ca> <20180216180031.GG27823@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20180216180031.GG27823@faui40p.informatik.uni-erlangen.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.230.16.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] BRSKI over 802.11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 11:06:21 -0000 An early draft of this is now available at: https://github.com/anima-wg/brski-over-802dot11/blob/master/brski-over-802d= ot11.md -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de]=20 Sent: Friday 16 February 2018 18:01 To: Michael Richardson Cc: Owen Friel (ofriel) ; Max Pritikin (pritikin) ; Eliot Lear (elear) ; anima@ietf.org Subject: Re: [Anima] BRSKI over 802.11 I am not even sure we would need to come up with just one permitted option. The two directions i see now from Owens input: a) "enterprise" Model. Relying on AAA server to be able to authenticate Pledges based on e.g.: EAP= -TLS with IDevID as auth. No additional SSID needed. Should try to also ann= ounce 802.11u GAS, but need to figure out if/how this would work in the fac= e of multiple SSIDs supported (aka: multi-domain). b) SSID approach - can work without any change to 802.11 infra, just put BRSKI proxy on the = BRSKI VLAN. - Work without AAA, e.g.: PSK (home AP). - multi-domain, no 802.11u support needed (unclear how ubiquitous that is). Single domain mode where AP has only one domain offering BRSKI, BRSKI SSID = is just called BRSKI%%, no beacon sent (called "hidden" in most UIs). Conne= cts only to BRSKI Proxy, carries only BRKSI traffic therefore.=20 Multiple 's on an AP, each one wanting to offer BRSKI, second and fur= ther SSID have to be renamed to BRSKI%. But actual SSID for BRSKI for= those 's is BRSKI%. No crypto, just connected to BRSKI Proxy.= =20 Cheers Toerless On Fri, Feb 16, 2018 at 11:43:04AM -0500, Michael Richardson wrote: >=20 > Owen Friel (ofriel) wrote: > > [ofriel] I think a more comprehensive analysis of the various SSID > > discover options (DPP, hardcoded SSID, NAI Realm,..) and how each f= its > > into the two post-SSID discovery options of (i) a new EAP-BRSKI > > vs. (ii) reuse of EAP-TLS (or some suitable EAP method, possibly wi= th > > 2x 80.1x exchanges) is needed before any consensus on the contents = of > > an ID is necessary. Unless you are suggesting than an initial ID me= rely > > outlines the multiple options but makes no final recommendation > > yet. Happy to get started on that... >=20 > Yes... the point of the ID would be to layout the options.... >=20 > The options-not-selected would go into an appendix of a final document=20 > to explain paths not taken. >=20 > -- > Michael Richardson , Sandelman Software Works =20 > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Feb 27 08:34:10 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66065127136 for ; Tue, 27 Feb 2018 08:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EJeXUC0EOSSZ for ; Tue, 27 Feb 2018 08:34:06 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9498124217 for ; Tue, 27 Feb 2018 08:34:05 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id v111so13302419wrb.3 for ; Tue, 27 Feb 2018 08:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=+XIL1AgL0Jo5JpGzXFxppFD/CSYXRKm5V2/KDmdvB00=; b=sQF/gEZ2TQ6QdXACqHCx5oxvEDl7IBairRopc+oNHuLhdZ9YtCy1c7NYeoE8IF9U9S xQLbaCiLCJO6rRTzq1EefO5wQMxLcEfSEPGYS2h793c+OlSO7FQYAQAkU86TJoRLTtmy lEwAhVsTRJJHLkJgTRBhlliHYpKqeXqjCtbOVjyY0DEKPzMdXeBL+Q4lGmhqzfVXzaH/ /WzSkPxTmI0Bc2tVoOMqeryMCzmGViqrq10V+8dd5eFiRXStRat30IXOmgl7dWnKZkpN BbIlAN1qbv1d48AmJg7/H4KGVLiSTe2v2M2b7yTlD+v3yJEsaN+gyOvQuw9eHWyGAkAA RN2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+XIL1AgL0Jo5JpGzXFxppFD/CSYXRKm5V2/KDmdvB00=; b=D+WWvdSQ7Kx7cyRYjsnUGpovOdaW38zRuHISUKcR30ND1mUV4DVJYoOpbHjKNec8k0 P7SFcrouZ0b4H9PD0N4YTQiTFoR4bjnOz5g/wMQIMMlxOtgOWNAXHFbPU248YU1VI6qu 96KN/TqekPLSRtKh8YeDJRXjL5kZMj+GADFuuP4AaISeiozWqAahCxq+7GJ8saZZz0Ih yCC511Gpsrd/wsMGqtZ7wmDYD+tMiBqP4Uv/HaXvx1Jd4s82QYjV/JnU2jyQZsZnylOX 8p6AJRBwm6vRM7OLNojKB9U7USghgV79RifmENvaWAIO5bj7uwrZCjuMickt9vxJVEJT DoBQ== X-Gm-Message-State: APf1xPCxBvtTT+EpOFecgcAwR+YXK7Bx0L6axDcmtU8d4c0zQysksdfS PN+WNOVvlGD/Y3pRNCLlM7a/VGUG X-Google-Smtp-Source: AH8x226rirsHJa9+jKHyVgGulCekP22FrYp2uFCDNzpSB3xo6n1ghBoneFuPnDC2XPQvCorW+LUMBQ== X-Received: by 10.223.179.17 with SMTP id j17mr12780312wrd.223.1519749244117; Tue, 27 Feb 2018 08:34:04 -0800 (PST) Received: from [172.16.4.39] ([185.12.3.4]) by smtp.gmail.com with ESMTPSA id l38sm20613689wrc.96.2018.02.27.08.34.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 08:34:03 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima@ietf.org References: Message-ID: <03ab2d02-f7d1-4c39-40c0-d232c909a111@gmail.com> Date: Tue, 27 Feb 2018 17:34:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr-classic Archived-At: Subject: Re: [Anima] "professionally managed" and the reference model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 16:34:09 -0000 In principle I'm happy with that, and I agree that it would be a good idea. However, I hope we can avoid another WGLC with this change? (Sheng?) Looking... Actually, the intro has this paragraph, which I think pretty much covers this case:    As discussed in [RFC7575], the goal of this work is not to focus    exclusively on fully autonomic nodes or networks.  In reality, most    networks will run with some autonomic functions, while the rest of    the network is traditionally managed.  This reference model allows    for this hybrid approach. Isn't that even a better description than "professionally managed", which has itself raised a lot of questions? My vote for now: We're good! No changes needed. Michael On 26/02/18 22:21, Brian E Carpenter wrote: > While looking at Pascal's ACP review, I noticed that although ANIMA > scope is limited by charter to "professionally managed" networks, > we do not mention that scope in draft-ietf-anima-reference-model. > It seems like something to be added to the Introduction. > > Comments? > > Regards > Brian Carpenter > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Feb 27 10:09:43 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF427120726; Tue, 27 Feb 2018 10:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mg3McDQBBvQi; Tue, 27 Feb 2018 10:09:38 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877BA126CD6; Tue, 27 Feb 2018 10:09:36 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DC55358C4BA; Tue, 27 Feb 2018 19:09:31 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id C2E0CB0DBAC; Tue, 27 Feb 2018 19:09:31 +0100 (CET) Date: Tue, 27 Feb 2018 19:09:31 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: "Pascal Thubert (pthubert)" , iot-dir , "ops-dir@ietf.org" , "int-dir@ietf.org" , "draft-ietf-anima-autonomic-control-plane@ietf.org" , "anima@ietf.org" Message-ID: <20180227180931.GA11701@faui40p.informatik.uni-erlangen.de> References: <449b7e2f10094531b325919710696754@XCH-RCD-001.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 18:09:41 -0000 +1, thanks a lot, Pascal. Will only get back after Mar 5 to reply, some other deadline stuff upfront. I think the correct term in reality is '"professionally' "managed"' networks. But kidding aside: resource constrained networks are not necessarily so autonomic that they do not require 'professional' 'management', that is just lucky coincidence, so the missing discussion if any would have to be about constrained devices and the subset of ACP functionality feasible/useful. I thought i had already some text in the appendix. WIll check and improve next week. Cheers Toerless On Tue, Feb 27, 2018 at 10:17:01AM +1300, Brian E Carpenter wrote: > Pascal, > > Great review! > > > - Section 3; the IOT certainly could use an ACP. It would be useful to scope the feature that is proposed in this document, whether it is compatible of not with constrained environments, whether it needs adaptations, point on Michael's enrollment draft. It would also be useful to indicate whether the ACP works between L3 bridges, IOW whether ACP operates the same (over IP) regardless of the packet forwarding layer in the data plane; > > Perhaps this point belongs in draft-ietf-anima-reference-model. ANIMA is chartered for "professionally managed" networks, and the reference model says: "At a later stage ANIMA may define a scope for constrained nodes with a reduced ANI [autonomic infrastructure] and well-defined minimal functionality. They are currently out of scope." So while your point is very valid, it's been considered out of scope so far. > > I'll leave the rest of your excellent comments to the ACP authors. > > Thanks > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Feb 27 10:35:04 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721121270AC for ; Tue, 27 Feb 2018 10:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.959 X-Spam-Level: X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aCobIK4jMQma for ; Tue, 27 Feb 2018 10:35:01 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18483126CD6 for ; Tue, 27 Feb 2018 10:35:01 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4212058C5A6; Tue, 27 Feb 2018 19:34:56 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 26A61B0DBAC; Tue, 27 Feb 2018 19:34:56 +0100 (CET) Date: Tue, 27 Feb 2018 19:34:56 +0100 From: Toerless Eckert To: "Michael H. Behringer" Cc: anima@ietf.org Message-ID: <20180227183455.GB11701@faui40p.informatik.uni-erlangen.de> References: <03ab2d02-f7d1-4c39-40c0-d232c909a111@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <03ab2d02-f7d1-4c39-40c0-d232c909a111@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] "professionally managed" and the reference model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 18:35:02 -0000 As co-author: +1, I would also trying to avoid bringing in more text re "professionally managed" into the ANI docs, but rather stick to technical wordings which (as michael pointed out) we have. As i said in recent mails, in my memory, this charter statement ("professionally managed") was primarily an IETF definition to separate ANIMA from homenet, but its really hard to translate into technical terms: IMHO, after we have ANI docs out, a technical comparison could easily be another document, maybe something nice to work on: Does a home network need BRSKI ? "No, Mrs. Jones will always directly touch the devices in a pre-staging network consisting of a notebook cable and the new device". "Actually, Mr. Eckert does remotely install devices in other family member homes, and especially with a lot of untrusted equipment in the home, BRKI would be on the top of my list to ask for adoption into home networks..." Does a home network need GRASP ? "Well.. Homenet already had enough of fights about what protocols to use for what purpose." "IMHO we first need strong use-cases for GRASP that makes it easier to use GRASP than the whatever ad-hoc protocol pre-exists! DNS-SD via GRASP could be one such use-case" "How about we define how to use Babel as a transport and security layer for GRASP ?" Does a home network or other constrained networks need ACP ? "Well... i think there are various degress of variations of ACP to make it more lightweight. We specifically did focus on high security first, there is definitely easy options for more lightweight approaches, most of them just suggested by current ACP draft in appendix". Cheers Toerless On Tue, Feb 27, 2018 at 05:34:02PM +0100, Michael H. Behringer wrote: > In principle I'm happy with that, and I agree that it would be a > good idea. However, I hope we can avoid another WGLC with this > change? (Sheng?) > > Looking... > > Actually, the intro has this paragraph, which I think pretty much > covers this case: > >    As discussed in [RFC7575], the goal of this work is not to focus >    exclusively on fully autonomic nodes or networks.  In reality, most >    networks will run with some autonomic functions, while the rest of >    the network is traditionally managed.  This reference model allows >    for this hybrid approach. > > Isn't that even a better description than "professionally managed", > which has itself raised a lot of questions? > > My vote for now: We're good! No changes needed. > > Michael > > > > On 26/02/18 22:21, Brian E Carpenter wrote: > >While looking at Pascal's ACP review, I noticed that although ANIMA > >scope is limited by charter to "professionally managed" networks, > >we do not mention that scope in draft-ietf-anima-reference-model. > >It seems like something to be added to the Introduction. > > > >Comments? > > > >Regards > > Brian Carpenter > > > > > >_______________________________________________ > >Anima mailing list > >Anima@ietf.org > >https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Feb 27 13:40:58 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB32D12DA53 for ; Tue, 27 Feb 2018 13:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uJ2NPcyfVjFn for ; Tue, 27 Feb 2018 13:40:56 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F901277BB for ; Tue, 27 Feb 2018 13:40:55 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id 17so116777pfw.11 for ; Tue, 27 Feb 2018 13:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KvTIWeNmBz8dF5y/Lc65DbnzmmdQtNkAexd+B5RqKfc=; b=orvAPD1eUNTn05+CVDfWeGzOc/5rhfcquBoN5uU/zIXEgmrKrWpPfOrNIiDVlWPlGh SXc3hTNlLf3pdVM8wRl4rTyTHvIcC50nL2HNC3Kb1+Ea8W3osQrPerCwua1tY/dZyevt +mG/3YBnpZw1bSUUpgiu07RoSDYpxm/7dWUFVXzPgwFrfYnkBDVxiF84PIfXsrpGwLNB /mo3EEQPrlpMZeJk31c7jJKEPu9h7wajpJMevrFYeyfZmX+9ki0UKtYJyKKzG5UvSg1o ZIAnd87+B3R9DUipWen85MeL12E4DUvUtOdr8H7wsbc054XqkpypAL4w5NEMJpA1/zwC cqhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KvTIWeNmBz8dF5y/Lc65DbnzmmdQtNkAexd+B5RqKfc=; b=cmj30g8pcyBm5pfMBbnxEb9kYfXzutT/UWH5mob6N5ZkL4kqrlY+wLB+Dynp0lLJpu c4U8dOtxpQywrBzhxfai70prB8GJ14tnC+Ver3G4tWzYW0z6IysgAV9STLg9LTTyEL18 EMKBBBvYWvg5Ib72QlovDWkPSpMAbO9kTZLNS0SDwiD4VPjAz1JP3z8wo5kB3I99xFlX gKpmMo0ZjxyKrngd4nZfKCrRns0a5331vKeAwJRDu6E8BaDUAfeltyz/+M6Wn/2rgmjm quCsSb4yhysrItDt1edFvJT2aiulMnXkW4IXPZbpVWnnlZoZyRFLR5wwyYxQTSpkFxCQ zBWg== X-Gm-Message-State: APf1xPC90a7mdHA+8yqTOGY8+Iy+QfWt+CSuVy7s3P+f9wlFF5kmGdxu HvSn1HSX04+ynytS18F1J5yKVY1g X-Google-Smtp-Source: AH8x227WSJrkc4/q0F1bEWlFShhNVFSsg0NODkAJ7UkMo7JvKd1Vde670fIPrWUXpvJD0PM9f8YODw== X-Received: by 10.98.166.85 with SMTP id t82mr15314785pfe.237.1519767655196; Tue, 27 Feb 2018 13:40:55 -0800 (PST) Received: from [192.168.182.31] ([114.23.138.211]) by smtp.gmail.com with ESMTPSA id y124sm101639pgb.29.2018.02.27.13.40.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 13:40:54 -0800 (PST) Sender: Brian Carpenter To: anima@ietf.org References: <03ab2d02-f7d1-4c39-40c0-d232c909a111@gmail.com> From: Brian E Carpenter Message-ID: Date: Wed, 28 Feb 2018 10:40:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <03ab2d02-f7d1-4c39-40c0-d232c909a111@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] "professionally managed" and the reference model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 21:40:58 -0000 On 28/02/2018 05:34, Michael H. Behringer wrote: > In principle I'm happy with that, and I agree that it would be a good=20 > idea. However, I hope we can avoid another WGLC with this change? (Shen= g?) >=20 > Looking... >=20 > Actually, the intro has this paragraph, which I think pretty much cover= s=20 > this case: >=20 > =C2=A0=C2=A0 As discussed in [RFC7575], the goal of this work is not t= o focus > =C2=A0=C2=A0 exclusively on fully autonomic nodes or networks.=C2=A0 I= n reality, most > =C2=A0=C2=A0 networks will run with some autonomic functions, while th= e rest of > =C2=A0=C2=A0 the network is traditionally managed.=C2=A0 This referenc= e model allows > =C2=A0=C2=A0 for this hybrid approach. >=20 > Isn't that even a better description than "professionally managed",=20 > which has itself raised a lot of questions? >=20 > My vote for now: We're good! No changes needed. (a) Undoubtedly we will have changes to make after IETF Last Call, so we can put this on ice until then. (b) Yes, I think the text here and in RFC7575 is fine. Maybe it's the WG charter which is wrong :-). As you know, the point was to avoid any clash with HOMENET. But "traditionally managed" is a better phrase than "professionally managed", I think. Brian >=20 > Michael >=20 >=20 >=20 > On 26/02/18 22:21, Brian E Carpenter wrote: >> While looking at Pascal's ACP review, I noticed that although ANIMA >> scope is limited by charter to "professionally managed" networks, >> we do not mention that scope in draft-ietf-anima-reference-model. >> It seems like something to be added to the Introduction. >> >> Comments? >> >> Regards >> Brian Carpenter >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Tue Feb 27 15:20:48 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFBB12EAA9; Tue, 27 Feb 2018 15:11:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: bclaise@cisco.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977308518.5200.10872525772253810685.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:25 -0800 Archived-At: Subject: [Anima] anima - Requested session has been scheduled for IETF 101 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:27 -0000 Dear Sheng Jiang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. anima Session 1 (2:30:00) Tuesday, Morning Session I 0930-1200 Room Name: Buckingham size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man Second Priority: roll v6ops dhc homenet netconf Third Priority: cfrg saag intarea opsarea People who must be present: Toerless Eckert Benoit Claise Sheng Jiang Terry Manderson Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Tue Feb 27 21:56:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FD612422F; Tue, 27 Feb 2018 21:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.105 X-Spam-Level: X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 L255VHf2_PGz; Tue, 27 Feb 2018 21:56:41 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 9499B120713; Tue, 27 Feb 2018 21:56:41 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 763E0F628B656; Wed, 28 Feb 2018 05:56:37 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 28 Feb 2018 05:56:38 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Wed, 28 Feb 2018 13:56:35 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: anima-chairs Thread-Topic: Call for agenda ANIMA @ IETF 101, London Thread-Index: AdOwWGKd4RIaPzDgQiCbL7FRUiUiwg== Date: Wed, 28 Feb 2018 05:56:34 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B928182F916@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B928182F916NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Call for agenda ANIMA @ IETF 101, London X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 05:56:43 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B928182F916NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all anima, We have been allocated a session of 2.5-hour for the ANIMA WG meeting for I= ETF-101 (London) and are starting to collect agenda items for the session. = Please send your request for agenda by March 8th, Thursday. Giving that most of our chartered work items have been sent to IESG for pub= lication by the meeting, we expect short time slots for only two or three o= f them. For this coming meeting, we would like to discuss potential future = ANIMA works. As normal, the priority among these non-charter work items would be: these = that have active discussion in mail list, then these have submitted drafts,= and topics without drafts. Please send us (anima-chairs at ietf.org;) requests for time slot by March 8th, Thursday and= include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 101, London can be found at: http://www.ietf.org/meeting/101/index.html Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Toerless & Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B928182F916NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, all anima,<=
o:p>
 
We have been al=
located a session of 2.5-hour for the ANIMA WG meeting for IETF-101 (London=
) and are starting to collect agenda items for the session. Please send you=
r request for agenda by March 8th, Thursday.
 
Giving that mos=
t of our chartered work items have been sent to IESG for publication by the=
 meeting, we expect short time slots for only two or three of them. For thi=
s coming meeting, we would like to discuss potential future ANIMA works.
 
As normal, the =
priority among these non-charter work items would be: these that have activ=
e discussion in mail list, then these have submitted drafts, and topics wit=
hout drafts.
 
Please send us =
(anima-chairs at ietf.org<https://ietf.org/>;) reques=
ts for time slot by March 8th, Thursday and include:

Name of time sl=
ot:


Name of draft(s=
):


Time requested:=



Presenter name(=
s):


 


More details ab=
out the IETF 101, London can be found at:


 


http://www.ietf.org/meeting/101/ind=
ex.html


 


Again, presente=
rs and draft authors please invoke active discussions in the ANIMA list. Ma=
il list is a very good place to discuss and reach consensus on technical is=
sues.


 


Best regards,


 


Toerless & =
Sheng


 
--_000_5D36713D8A4E7348A7E10DF7437A4B928182F916NKGEML515MBXchi_-- From nobody Wed Feb 28 06:37:05 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68D8129C5D; Wed, 28 Feb 2018 06:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no 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 wnCytwvAjOMa; Wed, 28 Feb 2018 06:37:01 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 EC6C9126BF3; Wed, 28 Feb 2018 06:37:00 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0D1D56BC51EE3; Wed, 28 Feb 2018 14:36:57 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 28 Feb 2018 14:36:57 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Wed, 28 Feb 2018 22:36:54 +0800 From: Sheng Jiang To: "Michael H. Behringer" , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 Thread-Index: AQHTrKecKNsDXYJTuES+POYHPFlKP6O56BRQ Date: Wed, 28 Feb 2018 14:36:53 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B928182FC9F@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92818111C7@NKGEML515-MBX.china.huawei.com> <22a65bfa-8954-304d-5a65-38d9e6d98b3f@gmail.com> In-Reply-To: <22a65bfa-8954-304d-5a65-38d9e6d98b3f@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.25.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 14:37:04 -0000 SGkgTWljaGFlbCwNCg0KVGhhbmtzIGZvciBhZGRyZXNzaW5nIG15IHJldmlldyBjb21tZW50cy4g QmVsb3cgaW4gbGluZXMgZm9yIG15IGZ1cnRoZXIgY29tbWVudHMgcmVnYXJkaW5nIHRvIHNldmVy YWwgcG9pbnRzLiBOb25lIG9mIHRoZW0gYXJlIG1ham9yLiBTbywgSSB3aWxsIHN0YXJ0IG15IGRv Y3VtZW50IHNoZXBoZXJkIGJhc2VkIG9uIHRoZSBjdXJyZW50IDA2IHZlcnNpb24uIEl0IGlzIHVw IHRvIHlvdSB0byBkbyBhIHF1aWNrIHVwZGF0ZSBzb29uIG9yIGFkZHJlc3NpbmcgdGhlbSB0b2dl dGhlciB3aXRoIHRoZSBJRVNHIHJldmlldyBjb21tZW50cywgd2hpY2ggSSBhbSBzdXJlIHdpbGwg aGF2ZS4NCg0KUmVnYXJkcywNCg0KU2hlbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBNaWNoYWVsIEguDQo+IEJlaHJpbmdlcg0KPiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIz LCAyMDE4IDk6MTAgUE0NCj4gVG86IFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+ OyBhbmltYUBpZXRmLm9yZw0KPiBDYzogYW5pbWEtY2hhaXJzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbQW5pbWFdIFJldmlldyBjb21tZW50cy8vUkU6IFdHTEMgb24gZHJhZnQtaWV0Zi1hbmlt YS0NCj4gcmVmZXJlbmNlLW1vZGVsLTA1IC0gUmVzcG9uZCBieSBKYW51YXJ5IDIybmQsIDIwMTgN Cj4gDQo+IE9uIDE4LzAxLzE4IDA5OjU5LCBTaGVuZyBKaWFuZyB3cm90ZToNCj4gPg0KPiA+IEhp LCBhdXRob3JzIG9mIGFuaW1hLXJlZmVyZW5jZS1tb2RlbCwNCj4gPg0KPiA+IEkgaGF2ZSByZXZp ZXdlZCB0aGUgZHJhZnQgYXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLCBzZWUgYmVsb3cgDQo+ID4g Y29tbWVudHMuIE92ZXJhbGwsIEkgZmVlbCB0aGlzIGRvY3VtZW50IGlzIHZlcnkgdXNlZnVsIGFu ZCBpdCBpcyANCj4gPiBhbG1vc3QgcmVhZHkgZm9yIGJlIHB1Ymxpc2hlZC4gUGxlYXNlIHByb3Bl cmx5IGFkZHJlc3MgbXkgY29tbWVudHMgDQo+ID4gdG9nZXRoZXIgd2l0aCBvdGhlciBXR0xDIGNv bW1lbnRzIHlvdSBtYXkgcmVjZWl2ZS4gQW5vdGhlciByZXZpc2VkIA0KPiA+IHZlcnNpb24gb2Yg dGhlIGRvY3VtZW50IGlzIG5lZWRlZCB0byBwcm9jZXNzIHRoZSBkb2N1bWVudCBmdXJ0aGVyIGlm IA0KPiA+IGl0IHBhc3NlZCB0aGUgV0dMQy4NCj4gPg0KPiANCj4gSGkgU2hlbmcsDQo+IA0KPiBG aXJzdCBvZiBhbGwgdGhhbmtzIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LiBJIGFtIG5vdyBmaW5p c2hlZCB3aXRoIA0KPiB3b3JraW5nIHlvdXIgY29tbWVudHMgaW50byB0aGUgZHJhZnQuIEkgYW0g anVzdCBwdWJsaXNoaW5nIHZlcnNpb24gLTA2Lg0KPiANCj4gVGhpcyB2ZXJzaW9uIHNob3VsZCBh ZGRyZXNzIGFsbCB5b3VyIGNvbW1lbnRzLiBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgDQo+IG90aGVy IG91dHN0YW5kaW5nIGNvbW1lbnRzLCBhbmQgYmVsaWV2ZSB3ZSBoYXZlIGFkZHJlc3NlZCBhbGwg b3BlbiBpc3N1ZXMgbm93Lg0KPiANCj4gRGV0YWlscyBiZWxvdyBpbiBsaW5lLg0KPiANCj4gTWlj aGFlbA0KPiANCj4gPiBHZW5lcmFsIGlzc3VlczoNCj4gPg0KPiA+IDEuIEluIHNlY3Rpb24gMy4x LCBpdCBzYXlzIOKAnFRoZSBBdXRvbm9taWMgQ29udHJvbCBQbGFuZSAoQUNQKSBpcyB0aGUgDQo+ ID4gc3VtbWFyeSBvZiBhbGwgaW50ZXJhY3Rpb25zIG9mIHRoZSBBdXRvbm9taWMgTmV0d29ya2lu ZyANCj4gPiBJbmZyYXN0cnVjdHVyZSB3aXRoIG90aGVyIG5vZGVzIGFuZCBzZXJ2aWNlcy7igJ0g SeKAmW0gYSBiaXQgY29uZnVzZWQgYnkgdGhpcyBzdGF0ZW1lbnQuDQo+ID4gSW4gbXkgdW5kZXJz dGFuZGluZywgdGhlIEFDUCBpdHNlbGYgaXMgbW9zdGx5IGEg4oCcY2hhbm5lbOKAnSwgYWx0aG91 Z2ggDQo+ID4gc29tZSBBTkkgZnVuY3Rpb25zIChzaWduYWxpbmcsIGFnZ3JlZ2F0ZWQgcmVwb3J0 aW5nIGV0Yy4pIGFyZSANCj4gPiBydW5uaW5nIHdpdGhpbiB0aGUgY2hhbm5lbCwgdGhleSBzaG91 bGQgYmUgcGFyYWxsZWwgd2l0aCBBQ1AgDQo+ID4gZnVuY3Rpb24gaW4gdGhlIGFyY2hpdGVjdHVy ZSB2aWV3Lg0KPiA+DQo+ID4gQXQgdGhlIHNhbWUgdGltZSwgdGhlcmUgYXJlIGluZGVlZCBzb21l IGZ1bmN0aW9ucyBjb25zaWRlcmVkIGFzIA0KPiA+IHN1Yi1mdW5jdGlvbnMgb2YgdGhlIEFDUCwg ZS5nLiB0aGUgYWRkcmVzc2luZyBhbmQgcm91dGluZywgd2hpY2ggYXJlIA0KPiA+IG5lY2Vzc2Fy eSB0byBtYWtlIHRoZSBBQ1AgcnVubmFibGUuDQo+ID4NCj4gPiBTbywgbXkgcXVlc3Rpb25zIHRv IHRoZSBjby1hdXRob3JzOg0KPiA+DQo+ID4gMSkgRG8geW91IHNlZSBBQ1AgYXMgYW4gaW5kaXZp ZHVhbCBmdW5jdGlvbiBhcyBJIHVuZGVyc3Rvb2QgKG1vc3RseSANCj4gPiBhIGNoYW5uZWwpLCBv ciBhIHN1bW1hcnkgb2YgYSBzdWl0ZSBvZiBmdW5jdGlvbnMgcnVubmluZyBpbnNpZGUgdGhlIEFD UD8NCj4gPg0KPiA+IDIpIFdoYXQgZnVuY3Rpb25zIGFyZSBzdWItZnVuY3Rpb25zIG9mIEFDUCwg YW5kIHdoYXQgYXJlIGluIHBhcmFsbGVsIA0KPiA+IHdpdGggQUNQPw0KPiA+DQo+IA0KPiBUaGVy ZSBhcmUgcmVhbGx5IHR3byBtZWFuaW5ncyB0byB0aGUgdGVybSAiQUNQIi4gVGhpcyBoYXMgY2F1 c2VkIHF1aXRlIA0KPiBzb21lIGNvbmZ1c2lvbiwgYW5kIEkgYWdyZWUgaXQgbmVlZHMgdG8gYmUg bmFpbGVkIG9uY2UgYW5kIGZvciBhbGwuDQo+IFRoYW5rcyBmb3IgcmFpc2luZyBpdCBoZXJlLg0K PiANCj4gMSkgVGhlIGdlbmVyYWwgdGVybSAiY29udHJvbCBwbGFuZSIgcmVmZXJzIHRvIHRoZSBz dW0gb2YgYWxsIHByb3RvY29scyANCj4gdGhhdCBjb250cm9sIG5ldHdvcmsgYmVoYXZpb3VyLiBM aWtlLCBpbiBhIHRyYWRpdGlvbmFsIG5ldHdvcmssIHJvdXRpbmcgcHJvdG9jb2xzLCBldGMuDQo+ IENvbnNlcXVlbnRseSwgYW4gIkF1dG9ub21pYyBDb250cm9sIFBsYW5lIiBpcyB0aGUgc3VtIG9m IGFsbCBwcm90b2NvbHMgDQo+IHRoYXQgY29udHJvbHMgdGhlIGJlaGF2aW91ciBvZiBhbiBhdXRv bm9taWMgbmV0d29yay4gSW4gDQo+IGRyYWZ0LWlldGYtYW5pbWEtc3RhYmxlLSBjb25uZWN0aXZp dHkgd2Ugbm93IHVzZSB0aGUgdGVybSAiR2VuZXJhbGl6ZWQgQUNQIiBmb3IgdGhpcyBhYnN0cmFj dCBjb25jZXB0Lg0KPiANCj4gMikgSW4gdGhlIEFOSU1BIGNvbnRleHQsIHdlIHVzZSB0aGUgdGVy bSAiQUNQIiBhbHNvIHRvIGRlc2NyaWJlIGEgdmVyeSANCj4gc3BlY2lmaWMgaW1wbGVtZW50YXRp b24gb2YgdGhlIGdlbmVyaWMgY29uY2VwdCBvZiBhbiAiQXV0b25vbWljIENvbnRyb2wgUGxhbmUi Lg0KPiANCj4gSSBub3cgY2xlYXJlZCB1cCB0aGUgbmFtaW5nIGluIHRoZSByZWZlcmVuY2UgZHJh ZnQuIFdoZXJlIHdlIG1lYW4gdGhlIA0KPiBhYnN0cmFjdCBjb25jZXB0ICgzLjEgZm9yIGV4YW1w bGUpLCBJIG5vdyB1c2UgIkdBQ1AiLCB3aGVyZSB3ZSBtZWFuIA0KPiB0aGUgaW1wbGVtZW50YXRp b24sIEkgbm93IHVzZSAiQUNQIiBhbmQgcmVmZXIgdG8gdGhlIEFDUCBkcmFmdC4NCj4gDQo+IFNw ZWNpZmljYWxseSwgSSBjaGFuZ2VkIGluIDMuMSBmcm9tIEFDUCB0byBHQUNQLiBBbmQgcmUtd29y ZGVkIHNlY3Rpb24gDQo+IDQuNiwgd2hpY2ggaXMgYWxsIGFib3V0IHRoZSBpbXBsZW1lbnRhdGlv biBvZiB0aGUgQUNQLg0KDQpbU2hlbmddIE15IG9yaWdpbmFsIGNvbW1lbnQgaW1wbGllZCB0d28g YXNwZWN0czoNCjEuIEFzIHlvdSBleHBsYWluZWQsIHRoZSAiR2VuZXJhbCIgY29udHJvbCBwbGFu ZSB2cy4gdGhlICJzcGVjaWZpYyIgaW1wbGVtZW50YXRpb24gKEFDUCkuIFNvLCBhcyBJIHVuZGVy c3Rvb2QsIHRoZSBBQ1AgaXMgYW4gaW5zdGFuY2Ugb2YgR0FDUC4gSSBoYXZlIG5vIHByb2JsZW0g b24gdGhpcy4NCjIuIFRoZSBzcGVjaWZpYyBBQ1AgYWN0dWFsbHkgc2VydmVzIGFzIGEgbWFuYWdl bWVudCBjaGFubmVsIGZvciB0aGUgdW5kZXJsYXkgbmV0d29yaywgaW4gdGhpcyBzZW5zZSwgdGhl IEFDUCBjb3VsZCBiZSBzZWVuIGFzIGEgIm1hbmFnZW1lbnQgcGxhbmUiIGZvciB0aGUgdW5kZXJs YXkgbmV0d29yazsgaW4gb3RoZXIgd29yZHMsIHRoZSBBQ1AgaXMgYSAiVmlydHVhbCBEQ04oRGF0 YSBjb21tdW5pY2F0aW9uIG5ldHdvcmspIi4gVGh1cywgdGhlcmUgY291bGQgYmUgYSBzdW1tYXJ5 IG9mIG1hbmFnZW1lbnQgZnVuY3Rpb25zIHJ1bm5pbmcgaW5zaWRlIHRoZSBBQ1AsIGFuZCB0aGlz IHN1bW1hcnkgZG9lc24ndCBiZWxvbmcgdG8gQUNQIGl0c2VsZi4gSWYgeW91IGFncmVlIHdpdGgg aXQsIEkgdGhpbmsgdGhpcyBhbHNvIG5lZWRzIHRvIGJlIGNsYXJpZmllZC4NCiANCj4gPiAyLiBJ 4oCZbSBjb25mdXNlZCBieSB0aGUgd2hvbGUgcHVycG9zZSBvZiBTZWN0aW9uIDMuIFRoZSBmaXJz dCANCj4gPiBzdWItY2xhdXNlIGlzIGRlc2NyaWJpbmcgdGhlIGFyY2hpdGVjdHVyZSBvZiBhbiBB dXRvbm9taWMgTmV0d29yayANCj4gPiBFbGVtZW50LCB3aGlsZSB0aGUgcmVzdCBzdWItY2xhdXNl cyAoYWRqYWNlbmN5IHRhYmxlLCBzdGF0ZSBtYWNoaW5lDQo+ID4gZXRjLikgc2VlbXMgbW9yZSBs aWtlIOKAnGltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRpb25z4oCdIG9yIOKAnHByb2NlZHVyZXPi gJ0uDQo+ID4gSSB0aGluayBib3RoIGFyZSB1c2VmdWwgY29udGVudCwgYnV0IHRoZXkgYXJlIGlu IHR3byBkaWZmZXJlbnQgDQo+ID4gZGltZW5zaW9ucywgbWF5YmUgc2VwYXJhdGUgdGhlbSBpbnRv IGRpZmZlcmVudCBzZWN0aW9ucz8NCj4gPg0KPiANCj4gV2VsbCwgdGhlIHNlY3Rpb24gaXMgYWJv dXQgdGhlIG5ldHdvcmsgZWxlbWVudC4gSSBmaW5kIGl0IHF1aXRlIGxvZ2ljIA0KPiB0aGF0IHlv dSBmaXJzdCBkaXNjdXNzIHRoZSBhcmNoaXRlY3R1cmUgb2YgdGhlIGVsZW1lbnQsIHRoZW4gaG93 IGl0IA0KPiBiZWhhdmVzIGluIGEgbmV0d29yay4gSG93ZXZlciwgSSBhZGRlZCBhbiBleHBsYW5h dG9yeSBpbnRybyBhdCB0aGUgDQo+IGJlZ2lubmluZyBvZiB0aGF0IHNlY3Rpb24gdG8gbWFrZSBp dCBjbGVhcmVyLiBUaGFua3MgZm9yIHBvaW50aW5nIG91dCANCj4gdGhhdCB0aGlzIHdhc24ndCBj bGVhciENCg0KPiA+IDMuIFNvbWUgdGV4dHMgKGUuZy4gcGFyYWdyYXBoIDQgb2YgU2VjdGlvbiAx KSBhcmUgZGlyZWN0bHkgYmluZCB0byANCj4gPiB0aGUgV0figJlzIGNoYXJ0ZXIsIEnigJltIG5v dCBzdXJlIGl0IGlzIGEgZ29vZCBhcHByb2FjaCB0aGF0IGFuIFJGQyANCj4gPiBub3JtYXRpdmVs eSByZWZlciB0aGUgV0cgY2hhcnRlciB3aGljaCBpcyBkeW5hbWljYWxseSBjaGFuZ2VkIGFsb25n IA0KPiA+IHdpdGggdGhlIHdvcmsgZ29pbmcgb24gaW4gdGhlIFdHLiBNYXliZSBqdXN0IHNpbXBs eSByZS1waHJhc2UgdGhlIA0KPiA+IOKAnGNoYXJ0ZXJlZCB3b3Jr4oCdIGFzIOKAnFBoYXNlIDEv bmVhciB0ZXJtIHdvcmvigJ0sIGFuZCDigJxub24tY2hhcnRlcmVk4oCdIGFzIA0KPiA+IOKAnFBo YXNlIDIgbG9uZy10ZXJt4oCdPw0KPiA+DQo+IA0KPiBBZ3JlZSB0aGF0IG5lZWRzIHRvIGJlIGZp eGVkLiBEaWQgc29tZSBlZGl0b3JpYWwgY2hhbmdlcyBmb3IgdGhhdC4gVGhlIA0KPiBzZWN0aW9u cyB3aXRoIGFuICgqKSBub3cgc3RhcnQgd2l0aCBhIHNlbnRlbmNlIGxpa2UgdGhpczoNCj4gICAg ICA8dD4uLi4gaXMgbm90IGNvdmVyZWQgaW4gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gc3Bl Y2lmaWNhdGlvbnMuDQo+IFRoaXMgc2VjdGlvbiBpcyBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3Nl cywgZm9yIGZvbGxvd2luZyBwaGFzZXMgb2YgDQo+IHN0YW5kYXJkaXphdGlvbi4gPC90Pg0KPiAN Cj4gQXMgcGFydCBvZiB0aGF0IGZpeCwgSSBhbHNvIHJlLXdvcmRlZCB0aGUgYWJzdHJhY3QuIEl0 IG5vdyByZWFkczoNCj4gDQo+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcmVmZXJlbmNlIG1v ZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2luZy4gSXQgDQo+IGRlZmluZXMgdGhlIGJlaGF2aW91 ciBvZiBhbiBhdXRvbm9taWMgbm9kZSwgaG93IHRoZSB2YXJpb3VzIGVsZW1lbnRzIA0KPiBpbiBh biBhdXRvbm9taWMgY29udGV4dCB3b3JrIHRvZ2V0aGVyLCBhbmQgaG93IGF1dG9ub21pYyBzZXJ2 aWNlcyBjYW4gDQo+IHVzZSB0aGUgaW5mcmFzdHJ1Y3R1cmUuDQo+IA0KPiBOb3csIHRoZSB3b3Jk ICJjaGFydGVyIiBpcyBubyBsb25nZXIgaW4gdGhlIHRleHQgYXQgYWxsLg0KPiANCj4gQ29tbWVu dHM/DQoNCj4gPiA0LiBUaGUgd2hvbGUgU2VjdGlvbiA3IHNlZW1zIHRvbyB0aGVvcmV0aWNhbCBh bmQgYWJzdHJhY3QuIFRoZSANCj4gPiBkZXNjcmliZWQgY29uY2VwdHMgYXJlIHZhbHVhYmxlLCBJ 4oCZZCBzdWdnZXN0IHRvIGhhdmUgbW9yZSB0ZXh0cyANCj4gPiBtYXBwaW5nIHRoZXNlIGNvbmNl cHRzIGludG8gdGhlIEFOSS9BTi4NCj4gPg0KPiANCj4gSSBtYWRlIHRoZSBjaGFuZ2VzIGRlc2Ny aWJlZCBhYm92ZSwgdG8gcG9pbnQgb3V0IHZlcnkgZXhwbGljaXRseSB0aGF0IA0KPiB0aGVzZSBz ZWN0aW9ucyBhcmUgZXNzZW50aWFsbHkgZm9yIGZ1dHVyZSBzdHVkeS4gSSB3b3VsZCBwcmVmZXIg Tk9UIHRvIA0KPiBkbyBhbnkgbW9yZSBlZGl0aW5nIGJleW9uZCB0aGF0LiBUaGF0IHNob3VsZCBi ZSBkb25lIGluIGEgc3Vic2VxdWVudCANCj4gZG9jdW1lbnQsIEkgdGhpbmsuDQoNCj4gPiBTcGVj aWZpYyBjb21tZW50czoNCj4gPg0KPiA+IFNlY3Rpb24gMSBJbnRyb2R1Y3Rpb24NCj4gPg0KPiA+ IC0gUGFyYWdyYXBoIDMgY2xhaW1zIOKAnFRoaXMgcmVmZXJlbmNlIG1vZGVsIGFsbG93cyBmb3Ig dGhpcyBoeWJyaWQgDQo+ID4gYXBwcm9hY2gu4oCdIEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVy IHRvIGV4cGxhaW4gaW4gd2hhdCBkZWdyZWUgdGhlIA0KPiA+IOKAnGh5YnJpZOKAnSBjb3VsZCBi ZS4gRm9yIGV4YW1wbGUsIHRoZSBBTkkgYWN0dWFsbHkgZG9lc27igJl0IHN1cHBvcnQgDQo+ID4g bm9uLWF1dG9ub21pYyBub2RlcyB0byBqb2luIGluIHRoZSBzYW1lIGRvbWFpbiB3aXRoIHRoZSBh dXRvbm9taWMgDQo+ID4gbm9kZXM7IHRodXMsIGluIHRoaXMgZGVwbG95bWVudCBsZXZlbCwgaXQg aXMgbm90IOKAnGh5YnJpZOKAnS4NCj4gPg0KPiANCj4gR29vZCBwb2ludC4gSSBhZGRlZCBhbiBl eGFtcGxlIHRvIGV4cGxhaW4gdGhlIGNvbmNlcHQuIEkgdGhvdWdodCBvZiANCj4gYWRkaW5nIG1v cmUsIGJ1dCB0aGVuIEkgdGhpbmsgdGhlIGludHJvIHdvdWxkIGJlY29tZSB0b28gbG9uZy4NCg0K PiA+IC0gQXMgc2FpZCBpbiB0aGUgZ2VuZXJhbCBpc3N1ZXMsIHBhcmFncmFwaCA0IHNlZW1zIGJp bmRpbmcgd2l0aCB0aGUgDQo+ID4gV0cgY2hhcnRlciB0b28gbXVjaC4NCj4gPg0KPiANCj4gVGhh dCBpcyByZXNvbHZlZC4NCj4gPg0KPiA+IFNlY3Rpb24gMiBUaGUgTmV0d29yayBWaWV3DQo+ID4N Cj4gPiAtIEluIHRoZSBmaWd1cmUsIGl0IHNlZW1zIHRoZSBBU0FzIGFyZSBoaWVyYXJjaGljYWws IGJ1dCB0aGVyZSBpcyBubyANCj4gPiByZWxldmFudCB0ZXh0cy4gTXkgdW5kZXJzdGFuZGluZyBp cyB0aGF0LCBpdCBpcyByZWFzb25hYmxlIHRvIA0KPiA+IGRpc3Rpbmd1aXNoIGxheWVyZWQgQVNB cywgZS5nLiwgc29tZSBBU0FzIG1pZ2h0IGJlIHZlcnkgZnVuZGFtZW50YWwsIA0KPiA+IGFuZCBz aG91bGQgYmUgdGhlIGZ1dHVyZSB3b3JrIG9mIHRoZSBBbmltYSBXRzsgd2hpbGUgbW9zdCBvZiB0 aGUgDQo+ID4gc3BlY2lmaWMgQVNBcyBhcmUgc2VydmljZS9zY2VuYXJpbyByZWxldmFudCwgdGhh dCBtaWdodCBub3QgYmUgDQo+ID4gc3VpdGFibGUgdG8gZG8gdGhlbSBjYXNlIGJ5IGNhc2UgaW4g QW5pbWEuDQo+ID4NCj4gDQo+IE9oLCBpdCB3YXMgbm90IHRoZSBpbnRlbnRpb24gdG8gaW1wbHkg YSBoaWVyYXJjaHkuIFRoYW5rcyBmb3IgcG9pbnRpbmcgDQo+IHRoaXMgb3V0LiBBU0FzIG1heSBv ciBtYXkgbm90IGJlIGhpZXJhcmNoaWNhbC4gSSBhZGRlZCBhIHNlbnRlbmNlIHRvDQo+IGNsYXJp Znk6ICJBU0FzIG1heSBiZSBzdGFuZGFsb25lLCBvciB1c2Ugb3RoZXIgQVNBcyBpbiBhIGhpZXJh cmNoaWNhbCB3YXkuIg0KDQo+ID4gLSDigJxUaGUgY3VycmVudCBjaGFydGVyIG9mIHRoZSBBTklN QSBXRyBpcyB0byBzcGVjaWZ5IHRoZSBBTkksIHVzaW5nIA0KPiA+IGEgZmV3IGF1dG9ub21pYyBm dW5jdGlvbnMgYXMgdXNlIGNhc2VzLuKAnSBBZ2FpbiwgSeKAmW0gbm90IHN1cmUgaXQgaXMgDQo+ ID4gZ29vZCB0byBiaW5kIHRoZSBSRkMgdG8gdGhlIFdHIGNoYXJ0ZXIuDQo+ID4NCj4gDQo+IEZp eGVkLg0KPiANCj4gPiBTZWN0aW9uIDMgVGhlIEF1dG9ub21pYyBOZXR3b3JrIEVsZW1lbnQNCj4g Pg0KPiA+IC0gSWYgRmlndXJlIDEgbWVhbnMgdG8gbWFrZSB0aGUgQVNBcyBoaWVyYXJjaGljYWws IHRoZW4gaXQgaXMgYmV0dGVyIA0KPiA+IHRvIGJlIGNvbnNpc3RlbnQgaW4gRmlndXJlIDIuDQo+ ID4NCj4gDQo+IEkgdGhpbmsgdGhpcyBpcyBmaXhlZCB3aXRoIHRoZSBhYm92ZSB0ZXh0LiBMZXQg bWUga25vdyBpZiBpdCBpcyBub3QgDQo+IGNsZWFyIGVub3VnaC4NCg0KPiA+IC0gTml0cyBpbiBG aWd1cmUgMg0KPiA+DQo+ID4gU3luY2hyb25pemF0aW9uIC0+IHN5bmNocm9uaXphdGlvbg0KPiA+ DQo+IA0KPiBUaGUgUkZDIGVkaXRvciB3aWxsIGZpeCBhbGwgdGhlIFVLIHZzIFVTIEVuZ2xpc2gg aXNzdWVzLiBJJ2xsIGxlYXZlIGl0IA0KPiB0byB0aGVtLCBzaW5jZSBJJ20gbm90IGEgbmF0aXZl IEVuZ2xpc2ggc3BlYWtlci4NCj4gDQo+ID4gSW4gdGhlIEFOSSBwYXJ0LCB0aGUg4oCcRGlzY292 ZXJ5LCBuZWdvdGlhdGlvbiBhbmQgc3luY2hyb25pc2F0aW9uIA0KPiA+IGZ1bmN0aW9uc+KAnSBs b29rcyBsaWtlIGEgc3ViLWl0ZW0gb2Yg4oCcQXV0b25vbWljIE5vZGUgQWRkcmVzc2luZ+KAnSwg SSANCj4gPiBndWVzcyBpdCBzaG91bGQgYmUgdHlwbz8NCj4gPg0KPiANCj4gR29vZCBjYXRjaC4g Rml4ZWQuDQo+IA0KPiA+IC0gU2VjdGlvbiAzLjEg4oCcVGhlIEF1dG9ub21pYyBOZXR3b3JraW5n IEluZnJhc3RydWN0dXJlIChBTkkpIGlzIA0KPiA+IG5vcm1hbGx5IGJ1aWx0IG9uIGEgaG9wLWJ5 LWhvcCBiYXNpcy7igJ0gSXQgaXMgdHJ1ZSBmb3IgQUNQLCBidXQgSSANCj4gPiBkb27igJl0IHRo aW5rIGl0IGFwcGxpZXMgZm9yIGFsbCB0aGUgb3RoZXIgQU5JIGZ1bmN0aW9ucywgZS5nLg0KPiA+ IG5lZ290aWF0aW9uL3N5bmMgc2lnbmFsaW5nLg0KPiA+DQo+IA0KPiBOb3RlIHRoZSAiYnVpbHQi LiBJIHRoaW5rIHRoZSBzZW50ZW5jZSBpcyBjb3JyZWN0LiBIb3dldmVyLCB0byANCj4gY2xhcmlm eSwgSSBjaGFuZ2VkICJidWlsdCIgdG8gImNvbnN0cnVjdGVkIi4gQW5kLCB3ZSdyZSByZWFsbHkg dGFsa2luZyBBQ1AgaGVyZS4NCj4gSSBjaGFuZ2VkIHRoYXQgYXMgd2VsbC4NCj4gPiAtIFNlY3Rp b24gMy4yLCB0aGUgZmlyc3QgYnVsbGV0IHBvaW50IG9mIHBhcmFncmFwaCAzIOKAnGxpbmsgbG9j YWwgDQo+ID4gZGlzY292ZXJ54oCdLCBpdCBpcyBhbWJpZ3VvdXMgdGhhdCB3aGF0IGtpbmQgaW5m b3JtYXRpb24gaXMgZ2F0aGVyZWQgDQo+ID4gdGhyb3VnaCBHUkFTUC4gSSB0aGluayB0aGVyZSBz aG91bGQgYmUgc29tZSBiYXNpYyBpbmZvcm1hdGlvbiANCj4gPiBnYXRoZXJlZCB0aHJvdWdoIE5E IHByb3RvY29sLg0KPiA+DQo+IA0KPiBZZXMsIHRoaXMgc2VjdGlvbiBpcyBhIGJpdCBhbWJpZ3Vv dXMsIEkgYWdyZWUuIEJ1dCBpZiB3ZSB3YW50IHRvIG1ha2UgDQo+IGl0IHByZWNpc2UsIGl0J3Mg Z29pbmcgdG8gZXhwbG9kZSB0aGUgc2VjdGlvbiBhbmQgbWFrZSBpdCB1bnJlYWRhYmxlLg0KPiBI bW1tLi4uIEkgdGhpbmsgdGhlIGlzc3VlIGlzIHJlYWxseSB0aGUgcGhyYXNlICJUaGlzIGlzIGRl c2NyaWJlZCBpbiANCj4gW0dSQVNQXSIuIEkgcmUtcGhyYXNlIHRoYXQgdG8gIlRoZSByZWxhdGVk IHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudHMgDQo+IChHUkFTUCwgQUNQLCBCUlNLSSkgZGVzY3Jp YmUgaW4gZGV0YWlsIGhvdyBsaW5rIGxvY2FsIGRpc2NvdmVyeSBpcyB1c2VkLiINCg0KPiA+IC0g U2VjdGlvbiAzLjIsIHRoZSB0aGlyZCBidWxsZXQgcG9pbnQ6IOKAnE9uY2UgdGhlIG5vZGUgaXMg cGFydCBvZiB0aGUgDQo+ID4gQUNQIG9mIGEgZG9tYWluLCBpdCB3aWxsIHVzZSBHUkFTUCBkaXNj b3ZlcnkgW0ktRC5pZXRmLWFuaW1hLWdyYXNwXSANCj4gPiB0byBmaW5kIFJlZ2lzdHJhcihzKSBv ZiBpdHMgZG9tYWluIGFuZCBwb3RlbnRpYWxseSBvdGhlciBzZXJ2aWNlcy7igJ0gDQo+ID4gVGhl IGxhdGVyIHZlcnNpb24gb2YgQlJTS0kgY2hhbmdlZCB0byB1c2UgYSBHUkFTUCBGbG9vZCBtZXNz YWdlIHRvIA0KPiA+IGFjdGl2ZWx5IGJyb2FkY2FzdCB0aGUgcmVnaXN0cmFyIHNlcnZpY2UgYnkg dGhlIHByb3hpZXMgaW4gdGhlaXIgDQo+ID4gbGluay1sb2NhbCBzY29wZS4NCj4gPg0KPiANCj4g SSByZW1vdmVkICJkaXNjb3ZlcnkiLiAiSXQgd2lsbCB1c2UgR1JBU1AiIGlzIGNvcnJlY3QuDQo+ IA0KPiA+IC0gU2VjdGlvbiAzLjMuMiwgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGJyaWVm bHkgZGlzY3VzcyB0aGUgDQo+ID4gc2l0dWF0aW9uIHRoYXQgaWYgYW4gZW5yb2xsZWQgbm9kZSBy ZS1ib290IGZyb20gcG93ZXIgY3V0IG9yIGJlIA0KPiA+IGF0dGFjaGVkIHRvIGFub3RoZXIgbmV0 d29yaywgaG93IHRoZSB0cmFuc2l0aW9uIHN0YXRlIHdvdWxkIGJlPyBJcyANCj4gPiBpdCB0aGUg c2FtZSB3aXRoIOKAnEZhY3RvcnkgcmVzZXTigJ0/DQo+ID4NCj4gDQo+IFRoaXMgZGlzY3Vzc2lv biBpcyBub3Qgc3BlY2lmaWMgdG8gMy4zLjIuIEEgbm9kZSBjYW4gcmVib290IGF0IGFueSANCj4g cG9pbnQgaW4gdGltZS4gVGhlIGltcG9ydGFudCBwYXJ0IGlzIGlmIGl0IGtlZXBzIGl0cyBMRGV2 SUQgb3Igbm90Lg0KPiANCj4gQnV0IHlvdSdyZSByaWdodC4gVGhpcyBpcyBub3QgbWVudGlvbmVk IGFueXdoZXJlLi4uIEhtbW0uLi4gVGhpbmtpbmcgDQo+IG1vcmUsIHRoaXMgaXMganVzdCBhbm90 aGVyIHRyYW5zaXRpb24gaW4gdGhlIHN0YXRlIG1hY2hpbmUsIGZvciBlYWNoIA0KPiBzdGF0ZS4g SSdsbCBhZGQgdGhhdCwgSSB0aGluayBpdCBtYWtlcyBzZW5zZS4NCj4gDQo+ICAgICAgIlBvd2Vy Y3ljbGUgZXZlbnQ6IFRoZSBkZXZpY2UgbG9zZXMgYWxsIHN0YXRlIHRhYmxlcywgYnV0IG5vdCBp dHMgDQo+IGRvbWFpbiBpZGVudGl0eSAoTERldklEKS4gTmV4dCBzdGF0ZTogMi4iDQo+IA0KPiBJ IGhvcGUgSSdtIG5vdCBvcGVuaW5nIGEgY2FuIG9mIHdvcm1zIGhlcmUuLi4gSXQgaXMgcG9zc2li bGUgdG8gDQo+IGNvbmNlaXZlIGEgbW9kZWwgd2hlcmUgYSBkZXZpY2UgYWxzbyBsb3NlcyBpdHMg TERldklELi4uIEkgdGhpbmsgDQo+IHRoYXQncyBnb2luZyB0byBiZSBhbiBleHRyZW1lIGNvcm5l ciBjYXNlLCBhbmQgd291bGQgcHJlZmVyIHRvIG5vdCBldmVuIG1lbnRpb24gaXQgaGVyZS4NCj4g VGhvdWdodHM/DQoNCltTaGVuZ10gVGhlIGFkZGVkIHRleHRzIGFyZSBnb29kIGZvciBtZS4gQnV0 IHBsZWFzZSBwYXJkb24gbWUgZm9yIG9wZW5pbmcgdGhlIGNhbiBldmVuIGEgYml0IG1vcmU6DQpX aGVuIG9uZSBkZXZpY2UgaGFzIGVucm9sbGVkLCBtYXliZSBpdCBpcyBnb29kIHRvIGtlZXAgdGhl IGRvbWFpbiBjZXJ0aWZpY2F0ZSBhcyB3ZWxsIGFzIHRoZSBMRGV2SUQ/IEluIHRoaXMgd2F5LCB0 aGUgbmV0d29yayB3b24ndCBzdWZmZXIgdG9vIG11Y2ggaW4gYSBwb3dlciBvdXRhZ2UgZXZlbnQu DQpJZiBpdCBpcyBwbHVnZ2VkIGludG8gYW5vdGhlciBkb21haW4sIGl0IHNob3VsZCBub3QgYmUg ZGlmZmljdWx0IHRvIGRldGVjdCB0aGUgYWJub3JtaXR5LiANCg0KPiA+IFNlY3Rpb24gNCBUaGUg QXV0b25vbWljIE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUNCj4gPg0KPiA+IC0gU2VjdGlvbiA0 LjIgQWRkcmVzc2luZywgdGhlcmUgYXJlIGEgbGlzdCBvZiBjb21wcmVoZW5zaXZlIA0KPiA+IHJl cXVpcmVtZW50cyBvZiBhZGRyZXNzaW5nLCB3aGljaCBhcmUgZ29vZCBjb250ZW50LiBJdCBtaWdo dCBiZSANCj4gPiBiZXR0ZXIgaWYgU2VjdGlvbiA0LjEgTmFtaW5nIGFsc28gaW5jbHVkZSBzdWNo IGEgcmVxdWlyZW1lbnQgbGlzdD8NCj4gPg0KPiANCj4gSSB0aGluayB0aGUgcmVxdWlyZW1lbnRz IGFyZSBpbiB0aGUgc2VjdGlvbiwganVzdCBub3QgaW4gYSBidWxsZXRlZCANCj4gbGlzdC4gRnJh bmtseSwgSSBwcmVmZXIgbm90IHRvIGNoYW5nZSB0aGlzIGF0IHRoaXMgc3RhZ2Ugb2YgdGhlIA0K PiBkb2N1bWVudC4gTGV0IG1lIGtub3cgaWYgd2UncmUgbWlzc2luZyBhIHJlcXVpcmVtZW50Lg0K PiANCj4gPiAtIFNlY3Rpb24gNC41IOKAnEFsbCBhdXRvbm9taWMgbm9kZXMgaW4gYSBkb21haW4g bXVzdCBiZSBhYmxlIHRvIA0KPiA+IGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhlciwgYW5kIHdp dGggYXV0b25vbWljIG5vZGVzIG91dHNpZGUgdGhlaXIgDQo+ID4gb3duIGRvbWFpbi7igJ0gVGhl IGNyb3NzLWRvbWFpbiBtZWNoYW5pc20gaGFzbuKAmXQgYmUgY292ZXJlZCB5ZXQsIG1heWJlIA0K PiA+IGl04oCZcyBiZXR0ZXIgdG8gbm90ZSB0aGlzIGZlYXR1cmUgaXMgZm9yIOKAnGxvbmcgdGVy beKAnSB3b3JrIHJhdGhlciB0aGFuIA0KPiA+IOKAnHBoYXNlIDHigJ0uDQo+ID4NCj4gDQo+IE9L LCBjaGFuZ2VkIHRoYXQgdG8gImluIGxhdGVyIHBoYXNlcyBhbHNvIHdpdGggLi4uIg0KPiANCj4g PiAtIFNlY3Rpb24gNC42IOKAnFRoZSB0b3RhbGl0eSBvZiBhdXRvbm9taWMgaW50ZXJhY3Rpb25z IGZvcm1zIHRoZSANCj4gPiAiQXV0b25vbWljIENvbnRyb2wgUGxhbmUiLiBBZ2FpbiwgaXQgaXMg dGhlIHNhbWUgYXMgTm8uMSBnZW5lcmFsIA0KPiA+IGlzc3VlIGFzIGRlc2NyaWJlZCBhYm92ZS4N Cj4gPg0KPiANCj4gQ2hhbmdlZCB0byAiVGhlICJBdXRvbm9taWMgQ29udHJvbCBQbGFuZSIgY2Fy cmllcyB0aGUgY29udHJvbCANCj4gcHJvdG9jb2xzIGluIGFuIGF1dG9ub21pYyBuZXR3b3JrLiIN Cj4gDQo+ID4gU2VjdGlvbiA1IFNlY3VyaXR5IGFuZCBUcnVzdCBJbmZyYXN0cnVjdHVyZQ0KPiA+ DQo+ID4gLSBTZWN0aW9uIDUuMiBkZXNjcmliZXMgZG9tYWluIGNlcnRpZmljYXRlOyBJIHRoaW5r IHRoZSBkZXZpY2UgDQo+ID4gY2VydGlmaWNhdGUsIHdoaWNoIGlzIHByZS1zZXQgYnkgdGhlIG1h bnVmYWN0dXJlIGFsc28gbmVlZHMgdG8gYmUgDQo+ID4gbWVudGlvbmVkLg0KPiA+DQo+IA0KPiBE b25lLg0KPiANCj4gPiBTZWN0aW9uIDYgQXV0b25vbWljIFNlcnZpY2UgQWdlbnRzIChBU0EpDQo+ ID4NCj4gPiAtIEl0IG1pZ2h0IGJlIGdvb2QgdG8gcmVmZXJlbmNlIGRyYWZ0LWNhcnBlbnRlci1h bmltYS1hc2EtZ3VpZGVsaW5lcz8NCj4gPg0KPiANCj4gR29vZCBwb2ludC4gSW5jbHVkZWQuDQo+ IA0KPiA+IC0gU2VjdGlvbiA2LjMgaXMgaW50ZXJlc3RpbmcsIGl0IGFjdHVhbGx5IHVudmVpbHMg dGhlIEFOSSBmdW5jdGlvbnMgDQo+ID4gKGV4Y2VwdCBHUkFTUCkgYXJlIHlldCBBU0FzLiBJdCBp cyBubyBwcm9ibGVtIGZvciBtZSwgYnV0IEkgaGF2ZSBhIA0KPiA+IGJpdCBjb25jZXJuIHRoYXQg bmV3IHJlYWRlcnMgbWlnaHQgYmUgY29uZnVzZWQgYWJvdXQgdGhlIOKAnG92ZXJsYXAvbWl4dHVy ZeKAnQ0KPiA+IGJldHdlZW4gQU5JIGFuZCBBU0FzPw0KPiA+DQo+IA0KPiBJIHRob3VnaHQgd2Ug d2VyZSBxdWl0ZSBjbGVhciBhYm91dCB0aGF0LiBJbiBzZWN0aW9uIDYuMSB3ZSBzYXk6DQo+IA0K PiAgICAgbyAgQSBmZXcgJ2luZnJhc3RydWN0dXJlIEFTQXMnIHRoYXQgdXNlIGJhc2ljIEFOSSBm ZWF0dXJlcyBpbiBzdXBwb3J0DQo+ICAgICAgICBvZiB0aGUgQU5JIGl0c2VsZiwgd2hpY2ggbXVz dCBydW4gaW4gYWxsIGF1dG9ub21pYyBub2Rlcy4gIFRoZXNlDQo+ICAgICAgICBhcmUgb3V0bGlu ZWQgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucy4NCj4gDQo+IEkgc3VnZ2VzdCB3ZSBsZWF2ZSBp dCBhdCB0aGF0Lg0KPiANCj4gDQo+ID4gU2VjdGlvbiA3IE1hbmFnaW5nIGEgKFBhcnRpYWxseSkg QXV0b25vbWljIE5ldHdvcmsNCj4gPg0KPiA+IC0gU2VjdGlvbiA3LjYgQVBJczogdGhpcyBzZWN0 aW9uIGFyZSB0b28gYWJzdHJhY3QgZm9yIG1lLCBJIGp1c3QgDQo+ID4gY291bGRu4oCZdCByZWFs bHkgZ2V0IHRoZSBwb2ludC4gSXQgc2VlbXMgbGlrZSBhIGdlbmVyYWwgZGVzaWduIA0KPiA+IHBh dHRlcm4gcmF0aGVyIHRoYW4gc3BlY2lmaWMgbWVjaGFuaXNtcyByZWxhdGVkIHRvIGF1dG9ub21p YyBuZXR3b3Jrcy4NCj4gPg0KPiANCj4gSSBhZ3JlZSB3aXRoIHlvdSwgaXQgaXMgZmFpcmx5IGdl bmVyaWMuIEF0IHRoZSBzYW1lIHRpbWUgaXQgcHJvdmlkZXMgDQo+IHNvbWUgY29udGV4dCB0byB0 aGUgQVBJcyB3ZSB1c2UsIGFuZCBpdCdzIGNsZWFybHkgbWFya2VkIHdpdGggYSAoKikgYXMgDQo+ IGJlaW5nIHBoYXNlIDIuIEkgc3VnZ2VzdCB3ZSBsZWF2ZSBpdCBpbi4gSWYgZm9sa3MgZmVlbCBz dHJvbmdseSwgSSANCj4gdGhpbmsgd2UgY291bGQgdGFrZSBvdXQgdGhlIGVudGlyZSBzZWN0aW9u LiBGb3Igbm93IEkgbGVhdmUgaXQuDQoNCltTaGVuZ10gSSB0aGluayBTZWN0aW9uIDcuNiAoQVBJ cykgaXMgcmVsYXRlZCB0byBkcmZhdC1pZXRmLWFuaW1hLWdyYXNwLWFwaSwgSSBjb3VsZG4ndCBl eGFjdGx5IHRlbGwgd2hldGhlciB0aGUgR1JBU1AgQVBJIGRlc2lnbiBjb25zaXN0cyB3aXRoIHRo ZSBkZXNpZ24gcHJpbmNpcGxlcyBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uLg0KSWYgdGhpcyBz ZWN0aW9uIGRvZXNuJ3QgbWVhbiB0aGF0IEFQSSByZWxhdGVkIHdvcmsgIk1VU1QiIGZvbGxvdyB0 aGUgZGVzaWduIHByaW5jaXBsZXMsIEknZCBzdWdnZXN0IHRvIGFkZCBhIHNlbnRlbmNlIHRvIGNs YXJpZnkgaXQuDQoNClJlZ2FyZHMsDQoNClNoZW5nDQoNCj4gPiAtIFNlY3Rpb24gNy43IERhdGEg TW9kZWwgaGFzIHRoZSBzaW1pbGFyIGlzc3VlIGFzIGFib3ZlLiBJdCBleHBsYWlucyANCj4gPiB0 aGUgY29uY2VwdCBidXQgbGFja3MgZXNzZW50aWFsIGNvbnRlbnQgcmVsYXRlZCB0byBBTkkuDQo+ ID4NCj4gDQo+IERpdG8uIEkgc3VnZ2VzdCB0byBsZWF2ZSBpdCBmb3Igbm93Lg0KPiANCj4gW2Vu ZCBvZiByZXBseV0NCj4gDQo+ID4gVGhhbmtzIGFuZCByZWdhcmRzLA0KPiA+DQo+ID4gU2hlbmcN Cj4gPg0KPiA+ICpGcm9tOipBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddICpP biBCZWhhbGYgT2YgKlNoZW5nIA0KPiA+IEppYW5nDQo+ID4gKlNlbnQ6KiBUdWVzZGF5LCBKYW51 YXJ5IDA5LCAyMDE4IDI6MjYgUE0NCj4gPiAqVG86KiBhbmltYUBpZXRmLm9yZw0KPiA+ICpDYzoq IGFuaW1hLWNoYWlyc0BpZXRmLm9yZw0KPiA+ICpTdWJqZWN0OiogW0FuaW1hXSBXR0xDIG9uIGRy YWZ0LWlldGYtYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA1IC0gDQo+ID4gUmVzcG9uZCBieSBKYW51 YXJ5IDIybmQsIDIwMTgNCj4gPg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IFRoaXMgbWVzc2FnZSBz dGFydHMgdGhlIHR3by13ZWVrIEFOSU1BIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIHRvIA0KPiA+ IGFkdmFuY2UgZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9kZWwtMDUsIEEgUmVmZXJlbmNl IE1vZGVsIGZvciANCj4gPiBBdXRvbm9taWMgTmV0d29ya2luZy4gVGhpcyBkb2N1bWVudCdzIGlu dGVuZGVkIHN0YXR1cyBpcyANCj4gPiBJbmZvcm1hdGlvbmFsLiBBdCBwcmVzZW50LCB0aGVyZSBp cyBubyBJUFIgZmlsZSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+ID4NCj4gPiBQbGVhc2Ugc2Vu ZCB5b3VyIGNvbW1lbnRzIGJ5IEphbnVhcnkgMjJuZCwgMjAxOC4gSWYgeW91IGRvIG5vdCBmZWVs IA0KPiA+IHRoaXMgZG9jdW1lbnQgc2hvdWxkIGFkdmFuY2UsIHBsZWFzZSBzdGF0ZSB5b3VyIHJl YXNvbnMgd2h5Lg0KPiA+DQo+ID4gU2hlbmcgSklBTkcgaXMgdGhlIGFzc2lnbmVkIGRvY3VtZW50 IHNoZXBoZXJkLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IFNoZW5nIChjby1jaGFpciwg VG9lcmxlc3Mgd2hvIGFzIGEgY28tYXV0aG9yIHN0YXllZCBuZXV0cmFsIG9uIHRoZSANCj4gPiBj b250ZW50IHNpZGUpDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gPiBBbmlt YUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5p bWENCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiBBbmltYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Wed Feb 28 07:52:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEB112DA1C for ; Wed, 28 Feb 2018 07:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 P_twVmmr8LuG for ; Wed, 28 Feb 2018 07:52:02 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8619512D87B for ; Wed, 28 Feb 2018 07:52:02 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 28F1158C4D6; Wed, 28 Feb 2018 16:51:58 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0961BB0DBC1; Wed, 28 Feb 2018 16:51:57 +0100 (CET) Date: Wed, 28 Feb 2018 16:51:57 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: anima@ietf.org Message-ID: <20180228155157.GA17673@faui40p.informatik.uni-erlangen.de> References: <03ab2d02-f7d1-4c39-40c0-d232c909a111@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] "professionally managed" and the reference model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 15:52:05 -0000 On Wed, Feb 28, 2018 at 10:40:55AM +1300, Brian E Carpenter wrote: > (a) Undoubtedly we will have changes to make after IETF Last Call, > so we can put this on ice until then. > (b) Yes, I think the text here and in RFC7575 is fine. Maybe it's > the WG charter which is wrong :-). As you know, the point was to > avoid any clash with HOMENET. But "traditionally managed" is a better > phrase than "professionally managed", I think. Interesting aside! Is a network with an SDN controller traditionally managed ? If the SDN controller uses the ACP, does this change the result ? Long term NMS'ler would say controller/orchestrator are just fancy new words for mostly the provisioning part of NMS, but: Good controllers/orchestrator would also be intent based only that the rendering of the intent would not necessarily be autonomic. But then we have never IMHO well described what criteria are required to call a particular method of intent rendering autonomic. Some for example would make distribution the key criteria while i would just look at the observable resilience of a function. To use a militaristic explanation: When doing PIM-SM, defense customers asked us what happens when the enemy shoots down the RP. And then shoot down its replacement. An so on. Now replace RP with SDN controller. Aka: resilient = able to automatically restart in one of enough places to make the solution survive all covered incidents. The "ability to shoot down anything" was btw. the original 1st requirement by DoD against Arpanet, so i would be careful to call autonomic networks non-traditional (managed). I would not know what would be more traditional than meeting this expectation for an IP network. Cheers Toerless > Brian > > > > Michael > > > > > > > > On 26/02/18 22:21, Brian E Carpenter wrote: > >> While looking at Pascal's ACP review, I noticed that although ANIMA > >> scope is limited by charter to "professionally managed" networks, > >> we do not mention that scope in draft-ietf-anima-reference-model. > >> It seems like something to be added to the Introduction. > >> > >> Comments? > >> > >> Regards > >> Brian Carpenter > >> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Feb 28 08:45:26 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC4212DA1D for ; Wed, 28 Feb 2018 08:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no 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 REvBLGBs36MT for ; Wed, 28 Feb 2018 08:45:19 -0800 (PST) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 9C8EB12D946 for ; Wed, 28 Feb 2018 08:45:14 -0800 (PST) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id w1SGjBEG008828 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 28 Feb 2018 17:45:11 +0100 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w1SGj9ua012787 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 28 Feb 2018 17:45:11 +0100 Received: from DEFTHW99ER7MSX.ww902.siemens.net (139.22.70.68) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 28 Feb 2018 17:45:05 +0100 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.65]) by DEFTHW99ER7MSX.ww902.siemens.net ([139.22.70.68]) with mapi id 14.03.0361.001; Wed, 28 Feb 2018 17:45:04 +0100 From: "Fries, Steffen" To: "anima@ietf.org" Thread-Topic: Proposal of enhancing the BRSKI example scope with CMP Thread-Index: AdOwse2wU6w3KpEsTGuI6647k8JrYQ== Date: Wed, 28 Feb 2018 16:45:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.40] Content-Type: multipart/alternative; boundary="_000_E6C9F0E527F94F4692731382340B337863448EDENBGAT9EH2MSXww9_" MIME-Version: 1.0 Archived-At: Subject: [Anima] Proposal of enhancing the BRSKI example scope with CMP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 16:45:24 -0000 --_000_E6C9F0E527F94F4692731382340B337863448EDENBGAT9EH2MSXww9_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have a question regarding the utilized enrollment protocols in BRSKI. The current BRSKI draft addresses the bootstrapping of a secure infrastruct= ure based on existent manufacturer certificates. This is for sure a basic r= equirement in industrial applications to enable secure service deployment o= r device integration. The current document utilizes EST to provide a realiz= ation example for the BRSKI approach. This already fits perfect for the ene= rgy automation domain, as EST is already been envisioned/utilized as enrol= lment protocol in IEC defined security. As we experience, there are other s= cenarios like industrial automation or intelligent traffic systems, which f= eature different enrollment approaches, like CMP, but could leverage the ge= neric BRSKI approach, we would like to propose to also consider CMP as furt= her example for BRSKI. In contrast to EST, CMP builds on a self-contained c= ontainer, which are independent from the transport. Hence, they can be easi= ly processed in online (connected) or offline scenarios, even if no direct = network access is possible. As CMP is very versatile, there is the option t= o profile the protocol to only support the features needed for a specific a= pplication. The LTE profile of CMP is one example of "simplifying" CMP by r= equiring only 3 Handshake messages to be supported. This profiling reduces = the burden on the device implementing CMP to not support all of its feature= s. Even though the BRSKI document is already advanced, we would like to propos= e to also include CMP as further example for certificate enrollment in BRSK= I. This inclusion would make it also easier for other standards or framewor= ks to consider security bootstrapping based on BRSKI. I hope it is okay to raise the question of scope enhancements of BRSKI in t= erms of mapped enrollment protocols on the mailing list and not wait till t= he next IETF meeting regarding a discussion. If this proposal is accepted, = we are very eager on providing a mapping section for the draft using a simi= lar approach as section 5 takes for defining BRSKI as extension to EST. Any thoughts regarding such an enhancement? Best regards Steffen -- Steffen Fries Siemens AG Corporate Technology Research and Development for Digitalization and Automation IT Security CT RDA ITS Otto-Hahn-Ring 6 81739 Muenchen, Germany Tel.: +49 89 636-633604 Fax: +49 89 636-48000 mailto:steffen.fries@siemens.com www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Crom= me; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Off= icer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike,= Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, German= y; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 668= 4; WEEE-Reg.-No. DE 23691322 --_000_E6C9F0E527F94F4692731382340B337863448EDENBGAT9EH2MSXww9_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have a question regarding the utilized = enrollment protocols in BRSKI.

The current BRSKI draft addresses the bootstrapping of a se= cure infrastructure based on existent manufacturer certificates. This is fo= r sure a basic requirement in industrial applications to enable secure service deployment or device integration. The current doc= ument utilizes EST to provide a realization example for the BRSKI approach.= This already fits perfect for the energy automation domain, as  EST i= s already been envisioned/utilized as enrollment protocol in IEC defined security. As we experience, there are o= ther scenarios like industrial automation or intelligent traffic systems, w= hich feature different enrollment approaches, like CMP, but could leverage = the generic BRSKI approach, we would like to propose to also consider CMP as further example for BRSKI. In cont= rast to EST, CMP builds on a self-contained container, which are independen= t from the transport. Hence, they can be easily processed in online (connec= ted) or offline scenarios, even if no direct network access is possible. As CMP is very versatile, there i= s the option to profile the protocol to only support the features needed fo= r a specific application. The LTE profile of CMP is one example of „s= implifying“ CMP by requiring only 3 Handshake messages to be supported. This profiling reduces the burden on the device = implementing CMP to not support all of its features.

Even though the BRSKI document is already advanced, we woul= d like to propose to also include CMP as further example for certificate en= rollment in BRSKI. This inclusion would make it also easier for other standards or frameworks to consider security bootstrapping based= on BRSKI.

I hope it is okay to raise the question of scope enh= ancements of BRSKI in terms of mapped enrollment protocols on the mailing l= ist and not wait till the next IETF meeting regarding a discussion. If this= proposal is accepted, we are very eager on providing a mapping section for the draft using a similar approac= h as section 5 takes for defining BRSKI as extension to EST.

 

Any thoughts regarding such an enhancement?

 

Best regards

Steffen

 


--

Steffen Fries
Siemens AG
Corporate Technology
Research and Development for Digitalization and Automation
IT Security
CT RDA ITS
Otto-Hahn-Ring 6
81739 Muenchen, Germany
Tel.: +49 89 636-633604
Fax: +49 89 636-48000
mai= lto:steffen.fries@siemens.com
www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Bo= ard: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Ch= ief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registe= red offices: Berlin and Munich, Germany; Commercial registries: Berlin Char= lottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

 

--_000_E6C9F0E527F94F4692731382340B337863448EDENBGAT9EH2MSXww9_-- From nobody Wed Feb 28 14:46:29 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFFE126FDC for ; Wed, 28 Feb 2018 14:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 mY1a39uKt8kJ for ; Wed, 28 Feb 2018 14:46:25 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE43126FB3 for ; Wed, 28 Feb 2018 14:46:25 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 819E820091; Wed, 28 Feb 2018 17:54:12 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9783080BCE; Wed, 28 Feb 2018 17:46:24 -0500 (EST) From: Michael Richardson To: "Fries, Steffen" cc: "anima@ietf.org" In-Reply-To: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Wed, 28 Feb 2018 17:46:24 -0500 Message-ID: <21379.1519857984@obiwan.sandelman.ca> Archived-At: Subject: Re: [Anima] Proposal of enhancing the BRSKI example scope with CMP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 22:46:27 -0000 Fries, Steffen wrote: > The current BRSKI draft addresses the bootstrapping of a secure > infrastructure based on existent manufacturer certificates. This is for > sure a basic requirement in industrial applications to enable secure > service deployment or device integration. The current document utilizes > EST to provide a realization example for the BRSKI approach. This > already fits perfect for the energy automation domain, as EST is > already been envisioned/utilized as enrollment protocol in IEC defined > security. As we experience, there are other scenarios like industrial > automation or intelligent traffic systems, which feature different > enrollment approaches, like CMP, but could leverage the generic BRSKI Just to be sure, you are talking about: https://tools.ietf.org/html/rfc4210 > approach, we would like to propose to also consider CMP as further > example for BRSKI. In contrast to EST, CMP builds on a self-contained > container, which are independent from the transport. Hence, they can be > easily processed in online (connected) or offline scenarios, even if no > direct network access is possible. As CMP is very versatile, there is > the option to profile the protocol to only support the features needed > for a specific application. The LTE profile of CMP is one example of > "simplifying" CMP by requiring only 3 Handshake messages to be > supported. This profiling reduces the burden on the device implementing > CMP to not support all of its features. > Even though the BRSKI document is already advanced, we would like to > propose to also include CMP as further example for certificate > enrollment in BRSKI. This inclusion would make it also easier for other > standards or frameworks to consider security bootstrapping based on > BRSKI. I think that it would be very difficult to hack CMP into the BRSKI document at this point. > I hope it is okay to raise the question of scope enhancements of BRSKI > in terms of mapped enrollment protocols on the mailing list and not > wait till the next IETF meeting regarding a discussion. If this > proposal is accepted, we are very eager on providing a mapping section > for the draft using a similar approach as section 5 takes for defining > BRSKI as extension to EST. > Any thoughts regarding such an enhancement? > Best regards Steffen > -- > Steffen Fries Siemens AG Corporate Technology Research and Development > for Digitalization and Automation IT Security CT RDA ITS Otto-Hahn-Ring > 6 81739 Muenchen, Germany Tel.: +49 89 636-633604 Fax: +49 89 636-48000 > mailto:steffen.fries@siemens.com > www.siemens.com/ingenuityforlife > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard > Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief > Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina > Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: > Berlin and Munich, Germany; Commercial registries: Berlin > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > _______________________________________________ Anima mailing list > Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Wed Feb 28 16:53:25 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED46312D775 for ; Wed, 28 Feb 2018 16:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Nb9XZuF1umWy for ; Wed, 28 Feb 2018 16:53:20 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86BF12D77A for ; Wed, 28 Feb 2018 16:53:19 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id e9so1638320pgs.10 for ; Wed, 28 Feb 2018 16:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kNr95C16f1YR+mqvo5+Hk2ypX8QCLFJlZed7nQ33Lpc=; b=itxDwy6FHTO6Tm7jchpjuKxXrXVH+HKIflsNZMXBgk44APo/np9D+q9qcXVXDWJ6RG uC7Q/Infyc71ViWhqn0ezwF3y58aeVVCzW429ylU33VIVpQpdMJYUEfunynluIUooSl0 WPJ1xeWrttnFfBFZh+ycV/dPVfX9k+cg4CORFGe/d8tgHoKEdTPoogSBQJyLJzyMlgTB 65jBRXIPU+ULkVaaoM0HCnegR3TbrIb8p7Gl8ytf4kjEX3tL8m2O3XOLrJHlzoS2XDR5 0wfwOCFZgOEUXoORQdKJZ91jCLPzMe7PD9Xh/InasQYT2WolwZzoIW9p1SBoG0mlfGbV 78og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kNr95C16f1YR+mqvo5+Hk2ypX8QCLFJlZed7nQ33Lpc=; b=Fyf+Ne4VG1m0myd3nXeC4gmv4I80MoDn47QJj6TqWYuaQaVNjHeABKJvCyEu69NLz2 vEweEJAOHiVxLTRgdSM6ICtu2T0DMfFWPXqXRhrCrCY8NTMYrqqH6/RqUx9I2hTDLQDr rDG7TS7q0DMAvPGG29Z+labKdNFhb1l0r6tcPM1T6ruIFw9NEZkzMxA0k/37lmV1xGOe 8M81LpIIwcixCa4EwB1K2W1jp0c96gf0KlUPI9iJvZ0b+j+N++nhSZWX22qtipnjWJCF DHfCok939H93hiKKJEr6VbdIgxSagBoyqJcETi31JqY1p+pbSpA/IWL/4HrA95abCc+Q RnuA== X-Gm-Message-State: APf1xPDktCQzNlfRUauqQnc04LJ3XoPVpNCxpbSr1izYIXHWXHLEj297 drG2A3awLB1OCfY3KVcaZ1aLCZio X-Google-Smtp-Source: AG47ELu/yCMnnmrfywSZeKUwCfipeakfbCxAd3y27JHScUX8jF/5u7sRJQPK8Th6AUQQmiWBdi9Ixw== X-Received: by 10.99.140.85 with SMTP id q21mr23027pgn.51.1519865599077; Wed, 28 Feb 2018 16:53:19 -0800 (PST) Received: from [192.168.182.31] ([114.23.138.211]) by smtp.gmail.com with ESMTPSA id v14sm6279901pfi.8.2018.02.28.16.53.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 16:53:18 -0800 (PST) Sender: Brian Carpenter To: Toerless Eckert Cc: anima@ietf.org References: <03ab2d02-f7d1-4c39-40c0-d232c909a111@gmail.com> <20180228155157.GA17673@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Thu, 1 Mar 2018 13:53:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180228155157.GA17673@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] "professionally managed" and the reference model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 00:53:22 -0000 in line (all IMHO): On 01/03/2018 04:51, Toerless Eckert wrote: > On Wed, Feb 28, 2018 at 10:40:55AM +1300, Brian E Carpenter wrote: >> (a) Undoubtedly we will have changes to make after IETF Last Call, >> so we can put this on ice until then. >> (b) Yes, I think the text here and in RFC7575 is fine. Maybe it's >> the WG charter which is wrong :-). As you know, the point was to >> avoid any clash with HOMENET. But "traditionally managed" is a better >> phrase than "professionally managed", I think. > > Interesting aside! > > Is a network with an SDN controller traditionally managed ? If the SDN controller is configured by a NOC or an NMS database managed by the NOC, yes. I think we are talking about configured by a human in the NOC when we say "traditional" or "professional". > If the SDN controller uses the ACP, does this change the result ? No. But if the SDN controller is configured by an ASA, not by a human, it's autonomic. > Long term NMS'ler would say controller/orchestrator are just fancy new > words for mostly the provisioning part of NMS, but: > > Good controllers/orchestrator would also be intent based > only that the rendering of the intent would not necessarily be > autonomic. But then we have never IMHO well described what criteria > are required to call a particular method of intent rendering autonomic. One reason why "intent" is still a buzzword left for future study. > Some for example would make distribution the key criteria while i > would just look at the observable resilience of a function. > > To use a militaristic explanation: When doing PIM-SM, defense customers > asked us what happens when the enemy shoots down the RP. And then shoot > down its replacement. An so on. Now replace RP with SDN controller. > > Aka: resilient = able to automatically restart in one of enough places to > make the solution survive all covered incidents. > > The "ability to shoot down anything" was btw. the original 1st requirement > by DoD against Arpanet, so i would be careful to call autonomic networks > non-traditional (managed). I would not know what would be more traditional > than meeting this expectation for an IP network. Right. That's why the GRASP draft used to contain a riff about how routing algorithms were the original autonomic mechanisms. If you remember, we had to remove that to satisfy the Routing Area people. If ANIMA succeeds, we will have simply extended that original DARPA requirement. Brian > > Cheers > Toerless > >> Brian >>> >>> Michael >>> >>> >>> >>> On 26/02/18 22:21, Brian E Carpenter wrote: >>>> While looking at Pascal's ACP review, I noticed that although ANIMA >>>> scope is limited by charter to "professionally managed" networks, >>>> we do not mention that scope in draft-ietf-anima-reference-model. >>>> It seems like something to be added to the Introduction. >>>> >>>> Comments? >>>> >>>> Regards >>>> Brian Carpenter >>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Feb 28 17:02:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F2E12D7E4; Wed, 28 Feb 2018 17:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xXtOcoOnHsMr; Wed, 28 Feb 2018 17:02:37 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7E512D77B; Wed, 28 Feb 2018 17:02:37 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id d26so1760870pfn.5; Wed, 28 Feb 2018 17:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=l0EMb+gf3bUhRNB2ioFTtb/ExMZUL4g6ZVfuj/hy4Fg=; b=AJeWPiazhKqwew/73bW+YIcL4PeHW1aCNWTo4fdsKk/08mzKJNRSt6rsxc8BZ/OamG 0lP4+GRDSR7ekCcN/zKQQvvGNQvmDX5pBlD7xob8NNqXbAWj7oEJX7v4rX2JLbSTWbOW McIt3C2GQZnZY3Hp8PdcR91OmCeWbKnS+1bwDz9g7HS4fFDT8gskzSbwkcyh2xoOy2Bi dnkn8D5ukoKJtYYv7b1BRzrBnLnxzhHkLmDhjgBMuNmowLgZY2XZlbpiJm9tSASFG25f qNtTEGbQ88jhjtRu9ZeWbU07zWsegVWQYVMjDcxbLmkYsSych5sTdTsqXdlFEa1sPLun SzIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=l0EMb+gf3bUhRNB2ioFTtb/ExMZUL4g6ZVfuj/hy4Fg=; b=YbRKZk/siN7HpQMyxqrEs2WRJnWgpQ63wcULk6fHaYT+URuaBCjTqTahIigpp0n3Dc ARju56TjJlZp4VGTwJCh4xnhl30x4x1GSuaNOQjzP37suvxtXukgQttXoZiPMKTKgsp/ lzr34oi5s3NWUFaRkZi2WPdjgrXMb1Em+9MoZYVGcKF3PlsOPXcNjWgTPt1zfz7EKLRB MsPYtHDUJ45uwGCMNQ3LN9qJrlWjDWEQy2SErohl0ZQFQQI6yZlzKe1JMe7BbKH8TbSj eY+cU7qS+nmTrVa9/tXEHcB9SWqBJf0EPp57ES7biCfP1jRe3K8qhpGvNLGfBOflJWV5 ZnZA== X-Gm-Message-State: APf1xPCtZ1fUIcSYBbRe218foH11L9Hbyq6N5I25sYNy5EA5+kJp1BGy ovXzICMyajAQGNU2+m1qoNZqeJfl X-Google-Smtp-Source: AG47ELvtDUOfvQbMEPCv+lcrbD5R5vVfQuGLXZAU8x20upJmBXBoqE8qDPPHKNlAghBybZl8ieEuZw== X-Received: by 10.98.72.10 with SMTP id v10mr62986pfa.148.1519866156302; Wed, 28 Feb 2018 17:02:36 -0800 (PST) Received: from [192.168.182.31] ([114.23.138.211]) by smtp.gmail.com with ESMTPSA id z4sm4140794pgb.4.2018.02.28.17.02.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 17:02:35 -0800 (PST) Sender: Brian Carpenter To: Sheng Jiang , "anima@ietf.org" Cc: anima-chairs References: <5D36713D8A4E7348A7E10DF7437A4B928182F916@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Message-ID: Date: Thu, 1 Mar 2018 14:02:37 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B928182F916@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 101, London X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 01:02:39 -0000 There will be updates of these three drafts by the deadline: draft-ietf-anima-grasp-api draft-carpenter-anima-asa-guidelines draft-carpenter-anima-grasp-bulk Since there are few major changes, a short slot for each is sufficient. Perhaps 10 minutes for asa-guidelines as there is a new example logic flow to describe, and 5 minutes each for the other two. Presenters TBD. Because of the time difference, I cannot promise to be on MeetEcho. Regards Brian On 28/02/2018 18:56, Sheng Jiang wrote: > Hi, all anima, > > > > We have been allocated a session of 2.5-hour for the ANIMA WG meeting for IETF-101 (London) and are starting to collect agenda items for the session. Please send your request for agenda by March 8th, Thursday. > > > > Giving that most of our chartered work items have been sent to IESG for publication by the meeting, we expect short time slots for only two or three of them. For this coming meeting, we would like to discuss potential future ANIMA works. > > > > As normal, the priority among these non-charter work items would be: these that have active discussion in mail list, then these have submitted drafts, and topics without drafts. > > > > Please send us (anima-chairs at ietf.org;) requests for time slot by March 8th, Thursday and include: > > Name of time slot: > > Name of draft(s): > > Time requested: > > Presenter name(s): > > > > More details about the IETF 101, London can be found at: > > > > http://www.ietf.org/meeting/101/index.html > > > > Again, presenters and draft authors please invoke active discussions in the ANIMA list. Mail list is a very good place to discuss and reach consensus on technical issues. > > > > Best regards, > > > > Toerless & Sheng > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Feb 28 17:06:46 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DFD12D7EC for ; Wed, 28 Feb 2018 17:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HPgG6iGczblG for ; Wed, 28 Feb 2018 17:06:42 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38BA129C6C for ; Wed, 28 Feb 2018 17:06:42 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id u5so1763654pfh.6 for ; Wed, 28 Feb 2018 17:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9su92I2aVVgWQlPSgFogRehQiiJh26p0rdb+KFHyhoo=; b=eGMjuQZkvVIaZFRY8NWOZBePRsy+SaqksZ33+K3yMnuhTsAB2CBWhzKTCibcf2NRAc zrsiulVMxsfQOkpXWgFmAr4ornAwh9P3nmvtK9kWMn2Kt3f2BcAgPi2gMBD6sAGzQ5kn /WCf655E1Fm+cWgAehmJA/XGGaNH+GswkH/2p8TN0y+O04QP7/cX54QVpy2nXofIE2nL xCZMEMPUNmNy3J7/+cZ/Pp45hhcM40AVitelzZ9ra5in68rafZtreeZ+SrJ1TjbQeJCt Kb7aWiPeyW7n8RqHOrc3nO4rqG2UoAgmoySNxHJb4UUNXoqUDJVcwhNcKIGGEW9GPa1A PlIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9su92I2aVVgWQlPSgFogRehQiiJh26p0rdb+KFHyhoo=; b=hWdqZqmUw/kj9W1yk06tMFTjoOsID2FVJbPm4FgxVxnel1nmIpdZe/lctSpWd+pmPR td75nYq+FjhhfFnnBZpPZEYDjbxgEAg778b4VtVcmT3qxj2bARn0pdUvP8XoBxB2HaZd +HIpfbK9nAxQ8MoTAsbKuqwpxtyjAuq7c8uftIJi75IfyViaVTB5qpDozbBr2Ag1Mf0S +lJ6dQxCx1h6VVDd/Jk4SUmX0HF3Y+2ijXZ4OUJ7ncUgSsepb4MKduaB2bMs4jAJfiAZ bcZJjHY13s65wxs1uZ2zmu9Qz5+C33ewxxNqRq31aQ4SU6GG4q3TlzHJjPii1KAMTPmO 08LQ== X-Gm-Message-State: APf1xPDDKpv1OltrBHU7ojtMNPvchmM1eofW6M3P91DOQH6szNuLp6sV dCJOrNai1H+22+N4uQsI0evKOEI0 X-Google-Smtp-Source: AG47ELvVg5wyBhbyemkdrR5EpD27UwBZO/rMt7wTzRDsTWKv8VgO9k1xOOmTQSCsGf1ObF3BgFFUUg== X-Received: by 10.98.72.10 with SMTP id v10mr75124pfa.148.1519866402037; Wed, 28 Feb 2018 17:06:42 -0800 (PST) Received: from [192.168.182.31] ([114.23.138.211]) by smtp.gmail.com with ESMTPSA id p10sm5420403pfe.187.2018.02.28.17.06.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 17:06:41 -0800 (PST) Sender: Brian Carpenter To: Michael Richardson , "Fries, Steffen" Cc: "anima@ietf.org" References: <21379.1519857984@obiwan.sandelman.ca> From: Brian E Carpenter Message-ID: <451660e6-9ac2-5d44-bef9-1546baa9b6a1@gmail.com> Date: Thu, 1 Mar 2018 14:06:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <21379.1519857984@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Proposal of enhancing the BRSKI example scope with CMP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 01:06:44 -0000 On 01/03/2018 11:46, Michael Richardson wrote: ... > > Even though the BRSKI document is already advanced, we would like to > > propose to also include CMP as further example for certificate > > enrollment in BRSKI. This inclusion would make it also easier for other > > standards or frameworks to consider security bootstrapping based on > > BRSKI. > > I think that it would be very difficult to hack CMP into the BRSKI document > at this point. As a matter of principle, it seems better to get BRSKI published as quickly as possible to meet the WG milestone, and then publish any extensions as separate documents. It seems like a good idea to work on such extensions. But one step at a time :-). Brian From nobody Wed Feb 28 22:37:06 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5431B1267BB for ; Wed, 28 Feb 2018 22:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 VLYmloiFIeyj for ; Wed, 28 Feb 2018 22:37:02 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (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 1ADFE1241F8 for ; Wed, 28 Feb 2018 22:37:01 -0800 (PST) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w216ax7K024673 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Mar 2018 07:36:59 +0100 Received: from DEFTHW99ERKMSX.ww902.siemens.net (defthw99erkmsx.ww902.siemens.net [139.22.70.147]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w216awnK005457 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Mar 2018 07:36:59 +0100 Received: from DENBGAT9ER5MSX.ww902.siemens.net (139.22.70.80) by DEFTHW99ERKMSX.ww902.siemens.net (139.22.70.147) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 1 Mar 2018 07:36:58 +0100 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.65]) by DENBGAT9ER5MSX.ww902.siemens.net ([139.22.70.80]) with mapi id 14.03.0361.001; Thu, 1 Mar 2018 07:36:57 +0100 From: "Fries, Steffen" To: Michael Richardson CC: "anima@ietf.org" Thread-Topic: [Anima] Proposal of enhancing the BRSKI example scope with CMP Thread-Index: AQHTsOX538yXpc73rE65sSHDrEmaXqO67Zd/ Date: Thu, 1 Mar 2018 06:36:56 +0000 Message-ID: <480D264A-BABF-42FB-8DEB-C5A2F0A7D92C@siemens.com> References: <21379.1519857984@obiwan.sandelman.ca> In-Reply-To: <21379.1519857984@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Proposal of enhancing the BRSKI example scope with CMP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 06:37:04 -0000 > On 28. Feb 2018, at 23:46, Michael Richardson wrote: >=20 > Fries, Steffen wrote: >> The current BRSKI draft addresses the bootstrapping of a secure >> infrastructure based on existent manufacturer certificates. This is for >> sure a basic requirement in industrial applications to enable secure >> service deployment or device integration. The current document utilizes >> EST to provide a realization example for the BRSKI approach. This >> already fits perfect for the energy automation domain, as EST is >> already been envisioned/utilized as enrollment protocol in IEC defined >> security. As we experience, there are other scenarios like industrial >> automation or intelligent traffic systems, which feature different >> enrollment approaches, like CMP, but could leverage the generic BRSKI >=20 > Just to be sure, you are talking about: https://tools.ietf.org/html/rfc42= 10 Yes, exactly. It is utilized by most (if not all) of the CAs I=92m aware of= .=20 >=20 >> approach, we would like to propose to also consider CMP as further >> example for BRSKI. In contrast to EST, CMP builds on a self-contained >> container, which are independent from the transport. Hence, they can be >> easily processed in online (connected) or offline scenarios, even if no >> direct network access is possible. As CMP is very versatile, there is >> the option to profile the protocol to only support the features needed >> for a specific application. The LTE profile of CMP is one example of >> "simplifying" CMP by requiring only 3 Handshake messages to be >> supported. This profiling reduces the burden on the device implementing >> CMP to not support all of its features. >=20 >> Even though the BRSKI document is already advanced, we would like to >> propose to also include CMP as further example for certificate >> enrollment in BRSKI. This inclusion would make it also easier for other >> standards or frameworks to consider security bootstrapping based on >> BRSKI. >=20 > I think that it would be very difficult to hack CMP into the BRSKI docume= nt > at this point. Based on CMPs complexity? That was the reason to mention the LTE profile. N= ot as a transport for CMP but rather as example how to streamline CMP to th= e functionality needed.=20 Or was it based on the timeline for the BRSKI document? Best regards Steffen >=20 >> I hope it is okay to raise the question of scope enhancements of BRSKI >> in terms of mapped enrollment protocols on the mailing list and not >> wait till the next IETF meeting regarding a discussion. If this >> proposal is accepted, we are very eager on providing a mapping section >> for the draft using a similar approach as section 5 takes for defining >> BRSKI as extension to EST. >=20 >> Any thoughts regarding such an enhancement? >=20 >> Best regards Steffen >=20 >=20 >> -- >> Steffen Fries Siemens AG Corporate Technology Research and Development >> for Digitalization and Automation IT Security CT RDA ITS Otto-Hahn-Ring >> 6 81739 Muenchen, Germany Tel.: +49 89 636-633604 Fax: +49 89 636-48000 >> mailto:steffen.fries@siemens.com >> www.siemens.com/ingenuityforlife >=20 >> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard >> Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief >> Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina >> Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: >> Berlin and Munich, Germany; Commercial registries: Berlin >> Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 >=20 >> _______________________________________________ Anima mailing list >> Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 From nobody Wed Feb 28 22:45:38 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADAE12422F for ; Wed, 28 Feb 2018 22:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Dx6JTfgONq1d for ; Wed, 28 Feb 2018 22:45:35 -0800 (PST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 C79821241F8 for ; Wed, 28 Feb 2018 22:45:34 -0800 (PST) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w216jVr6019389 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Mar 2018 07:45:32 +0100 Received: from DEFTHW99ERHMSX.ww902.siemens.net (defthw99erhmsx.ww902.siemens.net [139.22.70.133]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w216jJMB021838 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Mar 2018 07:45:31 +0100 Received: from DENBGAT9ER7MSX.ww902.siemens.net (139.22.70.90) by DEFTHW99ERHMSX.ww902.siemens.net (139.22.70.133) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 1 Mar 2018 07:45:29 +0100 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.65]) by DENBGAT9ER7MSX.ww902.siemens.net ([139.22.70.90]) with mapi id 14.03.0361.001; Thu, 1 Mar 2018 07:45:28 +0100 From: "Fries, Steffen" To: Brian E Carpenter CC: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] Proposal of enhancing the BRSKI example scope with CMP Thread-Index: AQHTsOX538yXpc73rE65sSHDrEmaXqO6gI4AgABvapU= Date: Thu, 1 Mar 2018 06:45:27 +0000 Message-ID: References: <21379.1519857984@obiwan.sandelman.ca>, <451660e6-9ac2-5d44-bef9-1546baa9b6a1@gmail.com> In-Reply-To: <451660e6-9ac2-5d44-bef9-1546baa9b6a1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Proposal of enhancing the BRSKI example scope with CMP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 06:45:36 -0000 > On 1. Mar 2018, at 02:06, Brian E Carpenter = wrote: >=20 > On 01/03/2018 11:46, Michael Richardson wrote: > ... >>> Even though the BRSKI document is already advanced, we would like to >>> propose to also include CMP as further example for certificate >>> enrollment in BRSKI. This inclusion would make it also easier for other >>> standards or frameworks to consider security bootstrapping based on >>> BRSKI. >>=20 >> I think that it would be very difficult to hack CMP into the BRSKI docum= ent >> at this point. >=20 > As a matter of principle, it seems better to get BRSKI published as quick= ly > as possible to meet the WG milestone, and then publish any extensions as > separate documents. I was looking into the charter and based on the date of the initial draft o= f the document I somehow feared that the document is already in the final s= tate. I did not find an expected timeline on when the draft is expected to = be finalized.=20 >=20 > It seems like a good idea to work on such extensions. But one step > at a time :-). We came up with the proposal as the current title of the document gives the= impression, that BRSKI would solely work with EST as it is the only exampl= e stated. As we see different use cases, which already target CMP, we thoug= ht it would be good to cover it in the base document. If the schedule of th= e document is that tight, then an extension in terms of a separate document= might be the way to go. Steffen >=20 > Brian