From nobody Fri Nov 1 12:48:05 2019 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 75BD812007A; Fri, 1 Nov 2019 12:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 4dui_IzXiGGT; Fri, 1 Nov 2019 12:48:01 -0700 (PDT) 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 437DA1201CE; Fri, 1 Nov 2019 12:47:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 31E633818F; Fri, 1 Nov 2019 15:45:06 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3372DA0; Fri, 1 Nov 2019 15:47:54 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-Reply-To: <20191024053636.GG69013@kduck.mit.edu> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <25780.1571775837@localhost> <20191024053636.GG69013@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) [COMMENTS] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2019 19:48:05 -0000 --=-=-= Content-Type: text/plain I may post this as -30 on Monday, or I may wait as your requested changes are minor. https://tinyurl.com/y6op6z5y Benjamin Kaduk wrote: >> The original purpose of the subjectKeyIdentifier was to indicate which >> keypair the client (pledge) had attempted to enroll. Upon successful >> enrollment, a new TLS connection is started (usually), which proves that the >> enrollment is success, and so no KeyIdentifier is needed. >> In the case of a failure, the existing TLS connection is maintained, so >> the server (Registrar) can associate the failure with the previous attempt >> to enroll. >> This change (removing the subjectKeyIdentifier) was made in -05, but the >> prose was not updated. The use of a subjectKeyIdentifier, which might no >> longer be a SHA-1 hash of a public key, is problematic, as the CSR does >> not include an appropriate KeyIdentifier, so the server would be left >> trying to calculate it, using the default (and now obsolete) SHA-1 >> mechanism. Including the KeyIdentifier has proved more trouble than >> benefit. > The removal of SKI seems okay, but I'm still looking for something like > "the body of the POST is a JSON object with the following [whoops, I forget > the right terminology for name/value pairs]" I have added some text, and some CDDL. + enrollstatus-post = { + "version": uint, + "status": bool, + "reason": text, + ? "reason-context" : { $$arbitrary-map } + } + } + + Figure 18: CDDL for enrollment status POST + >> Esko has complained that we have 14 open issues; that's probably negligence >> on my part about not closing them as we solved the issues. >> So we also closed all but three "auth48" tickets that had been opened. >> >> > Section 2.5.1 >> >> > The pledge is the device that is attempting to join. The pledge can >> > talk to the Join Proxy using link-local network connectivity. In most >> > cases, the pledge has no other connectivity until the pledge completes >> > the enrollment process and receives some kind of network credential. >> >> > I'd consider s/can talk to/is assumed to talk to/. >> >> okay. some have complained this isn't strong enough. >> Maybe MUST talk to? > I don't have a strong opinion on this, but it feels like something that > will probably be different for ACP vs. other deployments -- MUST feels > right for ACP but is probably not universal. I am leaving the text as I put it above. >> > How painful would it be to require 1.3 at this point? RFC 8446 has >> > been out for more than a year, and the TLS WG is leaning on me to >> > tighten up on this... >> >> Yes, but how many FIPS-140 validated TLS 1.3 implementations are there that >> are drop-in available to router platforms with 3-5 year R&D cycles? >> OpenSSL is FIPS for 1.0.1 and 1.0.2 which do not include TLS 1.3, for >> instance (which is 1.1.x). > I take it that FIPS-140 validation is required for those $100k BFRs, then? That's what implementers said awhile ago. >> WolfSSL has FIPS-140 for TLS 1.3 (to read the press releases), and some >> entities could drop it in, but others might have license issues. >> >> How about if I change the text to say: >> >> Use of TLS 1.3 (or newer) is encouraged. >> TLS 1.2 or newer is REQUIRED on the Pledge side. >> TLS 1.3 (or newer) SHOULD be available on the Registrar server interface, >> and the Registrar client interface, but TLS 1.2 MAY be used. >> TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS >> 1.2 MAY be used. > That's an okay compromise on the 1.3-encouragement front, but I don't think > that everyone will read "Foo server interface" and "Foo client interface" > in the same way. ok. > editorial nits on the linked diff: > Section 2.5.3 talks about the set of MASA that are trusted being limited > by the MASA TA database, but in the paragraph about the BRSKI-EST client > TA database. 2.5.3. Domain Registrar ... The registrar uses an Implicit Trust Anchor database for authenticating the BRSKI-MASA connection's MASA TLS Server Certificate. Configuration or distribution of trust anchors is out- of-scope for this specification. The registrar uses a different Implicit Trust Anchor database for authenticating the BRSKI-EST connection's Pledge TLS Client Certificate. Configuration or distribution of the BRSKI-EST client trust anchors is out-of-scope of this specification. Note that the trust anchors in/excluded from the database will affect which manufacturers' devices are acceptable to the registrar as pledges, and can also be used to limit the set of MASAs that are trusted for enrollment. I'm not seeing the issue. We split up paragraphs to clarify things, but maybe we failed. > s/described Appendix B/described in Appendix B/ (sorry, section number > not visible from diff; maybe 40% through the diff) fixed. > Section 5.4 is missing an "for" in "SHOULD be used for authentication of > the MASA". fixed. > s/accesptable/acceptable/ fixed. > Figure 17 is introduced as an "abstract example", though it seems more > of a concrete one after this diff. fixed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl28i+kACgkQgItw+93Q 3WUxJwf/XPfVxTgXbva6JxJdcnzJsS0zVs2QGMOXXE8v/HFT55SfAuQv3jTZ2V3o dOt/7aVX8KZRvT5umYdLkZJMBN4Bn4y0v9mbgu3GGYUwmMdMeqrANInX63eFaNLn WPndpgNQ7VyO6ks4GFfFxkhXUXzEci06Y6vBN4eueLVkwyT83nh4KxBjKoMrRhfC HVgpKImU+ssR4/jljKk/R8n3BokgqsKtRlvpWhjPnJ3ILvPIspxS5TP9nM3aQuJf KOX1AhLsS79cr8wy3WL8kwlNwybigJLiHR9TayPnU+KmYFbiA9RMBOKnR6SO3m5l HzQQ0HaaAkfnwXMNohQu9HpUilyyzA== =M3mQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 1 13:14:36 2019 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 3228C121322; Fri, 1 Nov 2019 13:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 n5170GWz7_yR; Fri, 1 Nov 2019 13:14:24 -0700 (PDT) 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 B6674120A34; Fri, 1 Nov 2019 13:14:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7279D3897A; Fri, 1 Nov 2019 16:11:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7CF3E612; Fri, 1 Nov 2019 16:14:22 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, The IESG , tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20191029031843.GO69013@kduck.mit.edu> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> <22000.1572299410@localhost> <20191029031843.GO69013@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2019 20:14:32 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: doc> although it results in additional network traffic. The relying MASA doc> implementation MAY leverage internal state to associate this request doc> with the original, and by now already validated, voucher-request so doc> as to avoid an extra crypto validation. >> >> > It seems that doing so would turn the voucher-request into a bearer >> > token for retrieving audit-log information (if the MASA accepts >> > unauthenticated clients). >> >> That's what's intended. > I can see why that functionality is needed, but it seems likely to > introduce some privacy and/or security considerations to document. It's a > bit too late in the day for me to reason through them, though. To be clear: any registrar which has ever formed a valid voucher-request MAY retrieve the audit-log at regular intervals to verify the status of the device. The words, "now already validated" means that the MASA agreed with the voucher-request. Most implementations are going to log the voucher-request as part of the internal audit log, so a memcmp() on that is enough. This would reveal new owners. Whether the new owner is legitimate or not is not something we can answer: it might be that the device has been stolen, or maybe it's legitimately lent, rented, sold, etc. >> > Section 11 >> >> > I am somewhat embarassed that I did not previously note that the >> > mechanism used to generate the domainID needs to be >> > second-preimage-resistant or an attacker can claim to be a registrar for >> > a domain that already exists. >> >> Right now, that's in: >> >> 5.8.2. Calculation of domainID >> >> The domainID is a binary value (a BIT STRING) that uniquely >> identifies a Registrar by the "pinned-domain-cert" >> >> If the "pinned-domain-cert" certificate includes the >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be >> used as the domainID. If not, the SPKI Fingerprint as described in >> [RFC7469] section 2.4 is to be used. This value needs to be >> calculated by both MASA (to populate the audit-log), and by the >> Registrar (to recognize itself). >> >> We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to >> replace it appropriately. > That's all good and admirable; I'm suggesting that we add a note in the > security considerations of this document noting that we rely on the > domainID (however determined) to be second-preimage-resistant. I've added this to the security considerations as 11.2. doc> Although the nonce used by the Pledge in the voucher-request does not doc> require a strong cryptographic randomness, the use of TLS in all of doc> the protocols in this document does. >> >> > We discuss the need for strong randomness in the nonce in Section 11.3, >> > so it's not clear this is actually true. >> >> We don't think that the voucher nonce has to be of the same quality as something that >> goes into a KDF. It is at the level of TCP Sequeunce number, not seed for >> generating a private key... > I mean, we literally say "Reducing the possibility of this is why the > pledge is mandated to generate a strong random or pseudo-random number > nonce." So to also say "the nonce [...] does not require a strong > cryptographic randomness" seems to be in conflict with the former > statement. > Are you saying that "strong random" and "strong cryptographic random" mean > different things, or am I misreading the document in some other way? I take your point, and I guess we were splitting hairs. I'll just rephrase it to remove the Although statement. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl28kh4ACgkQgItw+93Q 3WUq5gf+PZ8+u8bz9cESX0l/gAPYIt3UOFDHQRn7gOeNV1nSZcVpFOn8E/70frxM FcvI28yT2EHG1H4ctlydMie0fppGn/b/r1VUojfWATRMnJxu53FYnfIvf6ii51qx /G8hk1ShHVRed12iuXN3xxTYXbNI7PgTFkD9upHPM29Wkmbk0AlYRiG/AfjJwWM1 KWZu0X3PVkxj41Kt12tdzhlXKEY8Q0HVBV7XFf8vzrUaMe0xZ1DEwgA1Cel1DdMA xv6cdtxo5zxJnTxbDkeheBwlGj6+IVKEcb72jnk6n+EHqrRJmdn8lhnUJYrR/vDv /9x+7RxBjqd9iniHjqJdOK+D3r94qg== =Cjw4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 2 21:04:51 2019 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 EC10F12008B for ; Sat, 2 Nov 2019 21:04:49 -0700 (PDT) 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_HELO_NONE=0.001, 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 TQq7K2i6UqSD for ; Sat, 2 Nov 2019 21:04:47 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 9F320120013 for ; Sat, 2 Nov 2019 21:04:47 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id r1so9029866pgj.12 for ; Sat, 02 Nov 2019 21:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=jvntBrAG7yNJFtjeLsWtBzUVOw0K43vbuDTKAZu+t38=; b=L7wk3vM6nUxIVyUE9wbstwCNUxX8lysmgKX5GDo2EL+JscbdNsP5gSaSE5leXt1dEV hJ4vuDJumWIU4HSHfkmhEVH98g0sgmNGUIaBXggkjTiIJPyrKNyfb/99LgHVCkLvSzMd IHDy/MRrzp4LUc4tSgmc8KKaH6CTm/rg3W5uw8e/v6hy7vXJnCi9fedWJRTjs7UBHUOu xBpnM/YK2fAk4qlMjxQssV2p1bgaBDcQpYYMT3C+/a16d1TPPARGPFbmioHwxlihuFrc KxgV9bUtgFZf1TjG+4jAoKZyGe83FPi7/p/HHincdUySbj2uneLGH5TLG/U7ioBkt1F/ lhHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=jvntBrAG7yNJFtjeLsWtBzUVOw0K43vbuDTKAZu+t38=; b=WCdG0sfbKksMcBrMeoj2uj7TipxhRamj5vH7a6Csw6h9IuhYc9d2+8qxmVTyx/SpAr UVyo6ZhLS92pzu17SVY7Wu0EycwDYkzjaho3mqGt9vxnBMxF1URoOtYbqvpRo3+H3Pr1 tCv3cTQkN4kRycDmKln0gqCw23g5SsP7+4vNzo7tfNzMWXsjCA+Ji4GDyyEbL9t2IgIe BWXpKTZrjfswVozfhN2G5rXjjy70ikIenIp6TEXofiMuKgDALo42LYkZhlFYnjZ9Cvje EfPGk33M0XAXTK5JVMueVxaAloTNOSMTlb/C8QD1621URwixNWFAp8Z19DG7n1ToWzYx F3uA== X-Gm-Message-State: APjAAAX7hu20hFhHSYlUQqsZOQs2kFsrPDSMGJcJegIiBsnrj5ZT0062 /R8QKqwbaEEhVb5d9lk4Dpd2upqg X-Google-Smtp-Source: APXvYqytgmduJm3Jwnfd/HtbnO9+Ieym13pYk6wp+GnTzOuMAchR3WYVo2okY5U56YoxK/djThX+Vg== X-Received: by 2002:a63:1042:: with SMTP id 2mr23924889pgq.59.1572753886651; Sat, 02 Nov 2019 21:04:46 -0700 (PDT) Received: from [192.168.178.30] (46.137.69.111.dynamic.snap.net.nz. [111.69.137.46]) by smtp.gmail.com with ESMTPSA id j11sm10873743pfa.127.2019.11.02.21.04.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Nov 2019 21:04:45 -0700 (PDT) References: <2019110217041558514611@chinatelecom.cn> To: Anima WG From: Brian E Carpenter X-Forwarded-Message-Id: <2019110217041558514611@chinatelecom.cn> Message-ID: <5417752e-8447-f242-8535-cdbca87219c9@gmail.com> Date: Sun, 3 Nov 2019 17:04:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <2019110217041558514611@chinatelecom.cn> Content-Type: multipart/mixed; boundary="------------8512A161DB85381B81DE21AE" Content-Language: en-US Archived-At: Subject: [Anima] Fwd: Re: [OPSAWG] WG adoption call for draft-wu-model-driven-management-virtualization-07 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2019 04:04:50 -0000 This is a multi-part message in MIME format. --------------8512A161DB85381B81DE21AE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have a question for ANIMA. This draft's Abstract says: This document provides a framework that describes and discusses an architecture for service and network management automation that takes advantage of YANG modeling technologies.... The document aims to exemplify an approach that specifies the journey from technology-agnostic services to technology-specific actions. My question is: how can ANIMA embody this work in autonomic networks? There's a life cycle diagram at https://tools.ietf.org/html/draft-wu-model-driven-management-virtualizati= on-07#page-9 that very much reminds me of some our discussions of ASA life cycle management. Is there any reason we can't integrate this YANG-based approach in the ASA model? Brian -------- Forwarded Message -------- Subject: Re: [OPSAWG] WG adoption call for draft-wu-model-driven-managem= ent-virtualization-07 Date: Sat, 2 Nov 2019 17:04:16 +0800 From: xiechf@chinatelecom.cn To: opsawg Hi, all=EF=BC=8C This=C2=A0document=C2=A0provides=C2=A0a=C2=A0framework=C2=A0that=C2=A0des= cribes=C2=A0how=C2=A0to=C2=A0use=C2=A0YANG=C2=A0modeling=C2=A0=C2=A0for=C2= =A0network=C2=A0management=C2=A0automation.=C2=A0 As=C2=A0one=C2=A0co-aut= her=C2=A0of=C2=A0this=C2=A0draft, I=C2=A0hope=C2=A0it=C2=A0can=C2=A0be=C2= =A0adopted=C2=A0after=C2=A0many=C2=A0times=C2=A0of=C2=A0revision.=C2=A0 Thank=C2=A0you! Chongfeng=C2=A0Xie =C2=A0 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: OPSAWG [mailto:opsawg-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Tianran Zhou =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B410=E6=9C=8829=E6=97= =A5 9:44 =E6=94=B6=E4=BB=B6=E4=BA=BA: opsawg@ietf.org =E6=8A=84=E9=80=81: draft-wu-model-driven-management-virtualization.a= uthors@ietf.org; opsawg-chairs@ietf.org =E4=B8=BB=E9=A2=98: [OPSAWG] WG adoption call for draft-wu-model-driv= en-management-virtualization-07 =C2=A0 Hi WG, =C2=A0 This email starts a 2 weeks working group adoption call for draft-wu-= model-driven-management-virtualization-07. https://datatracker.ietf.org/doc/draft-wu-model-driven-management-vir= tualization/ This document provides a framework that describes and discusses an ar= chitecture for service and network management automation that takes advan= tage of YANG modeling technologies. =C2=A0 If you support adopting this document please say so, and please give = an indication of why you think it is important. Also please say if you wi= ll be willing to review and help the draft. If you do not support adopting this document as a starting point for = work on this topic, please say why. This poll will run until Nov 11. Thanks, Tianran and Joe =C2=A0 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --------------8512A161DB85381B81DE21AE Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0FX RyBtYWlsaW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg0K --------------8512A161DB85381B81DE21AE-- From nobody Sun Nov 3 13:14:33 2019 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 124391200C4; Sun, 3 Nov 2019 13:14:27 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <157281566701.13377.10441193144238448088@ietfa.amsl.com> Date: Sun, 03 Nov 2019 13:14:27 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-21.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 21:14:27 -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 : An Autonomic Control Plane (ACP) Authors : Toerless Eckert Michael H. Behringer Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-21.txt Pages : 163 Date : 2019-11-03 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 Operations Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-21 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-21 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 Sun Nov 3 13:27:55 2019 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 21BD4120124; Sun, 3 Nov 2019 13:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 6LI_z43rMmRO; Sun, 3 Nov 2019 13:27:48 -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 ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5816712012E; Sun, 3 Nov 2019 13:27:48 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5ADDC54802E; Sun, 3 Nov 2019 22:27:41 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 589A3440015; Sun, 3 Nov 2019 22:27:41 +0100 (CET) Date: Sun, 3 Nov 2019 22:27:41 +0100 From: Toerless Eckert To: Benjamin Kaduk Cc: The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20191103212741.GA48708@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156331768227.15267.2488890611024053018.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2019 21:27:54 -0000 Hi Ben, In my last reply to your review from Jul 24th (appended below), i resolved most issues in -20, and mentioned two open issues. I hope i "resolved" them with -21 which i just posted. Diff 20 - 21: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-21.txt Complete diff since your last review, -19 -> -21: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-21.txt 1. Your suggestion for ASN encoding of domain-information / new ASN element for ACP domain information. I did list in my last response to you a range of conditions under which we could agree that a new ASN.1 certificate element would be a potentially better soution than using the rfc822 field. I did discuss this during montreal with the WG, but it does really seem as if the rfc822address was the best coice for ease of adoption: The main reason reflected by others was the ability of existing ASN.1 libraries to support the rfc822address field without new versions of a library or more complex updates/extensions to said libraries. I think this was also for low-end libraries in the IOT space. I listed other reasons (ease of diagnostics with existing tools, human readible string, etc..) too in my last email below. Aka: At this stage, i would like to stick to the current rfc822address encoding. I think we did do a good amount of diligence for it in the WG, and existing coding seems to support our decision. So, i did not change any text for it in -21. 2. Missing crypto parameters. I think i resolved the missing parameters in -21, pls. see diff. Re-reading our thread (last reply appended below), you mentioned a desire for GMAC in IPsec, but i went for ENCR_AES_GCM_16 already in -20 because rfc8221 says: "AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms should only be used for AH and not for ESP." to hopefully wrap up the crypto discussion: If there are any remaining crypto parameter gaps, where you can not simply suggest text to resolve them, i think the best way to resolve them is in person in singapore. After montreal, i sent a request to the crypto experts you recommended me but didn't receive reply to the email, so everybody is really busy and its harder and harder to resolve smaller and smaller issues via email. Cheers Toerless Appended below our last exchange. On Tue, Jul 23, 2019 at 01:22:43AM +0200, Toerless Eckert wrote: > --- Context: > > I hope i am correctly restating, that this reply is as follows: > -> After finishing second round of replies for -16, Ben Kaduk provided a reply > that is now also his new DISCUS position on datsatracker. this is my reply > to that DISCUS. > > -> The diff for the changes discussed in this email is: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.2.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.3.txt > They are also summarized under section (3) of the -20 changelog. > > -> The total changes -19 to -20 are of course: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt > On Tue, Jul 16, 2019 at 03:54:42PM -0700, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-19: Discuss > > 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-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > [trimming to just the topics still under discussion; no change to the > text of the remaining items even though some changes have been made > to the document] > > I think there needs to be some justification of why rfc822Name is chosen > over a more conventional structure in the otherName portion of the > subjectAltName, which is explicitly designed to be extensible. Let me but the compromise proposal and conditions on top: Compromise proposal (not integrated into current text yet): The document defines a new otherName like ACPdomainIdentity, type IA5String I can figure out how to write the the necessary formal text for this, stealing from e.g.: rfc8398 or the like (asking for IANA registration etc..) i will whine for help (from you) when i fail with that text formalisms/ASN1. stuff. The encoding of the string is the existing domain-information The length limitation of 64 for the local part is lifted (yeah). The rest of the text (justification for formatting etc.) is appropriately fixed up. I will remove all the text suggesting this could be an actual rfc822 address and just escribe it in terms of below reasoning (nice format to express domain based identities "local+policies@domain" or the like. Condition: Sufficient support in WG (tomorrow meeting) wrt. the following key aspects: -> Belief that even the most stupid existing libraries to deparse certificates can give access to this information without rev'ing such libraries (we assume this is true for rfc822Name). -> Ability of a good amount of existing diagnostics tools to actually display the string content as a string, even when it obviously doesn't know what type the otherName is. This is based on my hope that i correctly understand BER/DER to be self identifying, so deparser would know the element is string, but thats's what i am not sure about. Reasons: - We need both a human readable and in-cmputer representation of the information. I really don't see enough reason to have two different ones, and i really don't want to write to structure defintions. So i think the existing ABNF string is nice for both purposes. This info will go into all type of backend systems, inventory tracking etc.. deparsing specifically formatted strings is quite common there. - The domain-information is really the non-cryptographic part of the ACP device identity. and the local@domain part is an established way to represent this, so its hopefully "nice" too - e.g.: i woldn't know a more appropriate format. > In a few places, the MTI cryptographic mechanisms are under-specified, > whether the cipher mode for IKE or the TLS ciphersuites. I have attempted > to note these locations in my section-by-section comments. Right. a) I couldn't find good references for certificate requirements. The IPsec/IKEv2 reference STANDARDS RFCs lamely said something like "problem for the PKIX community". (seems like a gapipng big interop hope for those protocols if it doesn't exist). b) I am confused about TLS parameters needed beside what i wrote in latest update. See nit discuss below. > Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL > root, but if I understand correctly the RPL root is automatically > determined within the ACP, and thus the operator does not a priori know > which node will become the RPL root. Am I misunderstanding, or is this > effectively placing this requirement on all ACP nodes? Fixed by adding an option to not ask for this diagnostics to lowest-end nodes least in line to become root. When one of those nodes becomes root, the network is already in a worst degraded state, so this advanced diagnostics is then likely the least of problems. Details in reply to original -16 review answer you sent. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for adding the implementation experience note to the shepherd > writeup; it is helpful to understand the maturity level of the document. > > The comments here are probably best understood in the context of my > previous ballot position, specifically with respect to certain topics > being "speculative" or a matter for "future work". > > One somewhat general comment that occurred to me on the reread is that > by encoding the ACP address into a node's LDevID, we are on the face of > things locking it into a given addressing model, though in practice it > should be fairly straightforward to issue a new certificate through > regular update/renewal mechanisms. I forget if we have discussion of > this non-issue already. Readdressing is possible, but the address is really the non-security part of the identity of an ACP node (security part is key-pair), so all the ACP text talks about trying to maintain it whenever possible (discussed in the text for example in the face of change of registrars, so the originally assigning registrar is gone). There is really nothing breaking in the ACP when ACP nodes change their addresses, but typically the short-term adoptions of ACP into non-fully autonomic environments would love to see persistent addresses, because thats what they do today: Operators have used IP addresses as ideally never-changing network services identifiers of nodes for decades (loopback addresses). Thats just what we do with ACP, and the assignment via certificate is an elegant way to solve the current manual problem of network wide unique assignment, it just gets a bit complicated under the hood in above mentioned cases (registrar change during cert renewal). The use of well-defined address plans standardized in the ACP document is also something that effectively just automates operational practices and keeps deployment specific options at a minimum. > Section 1 > > Combining ACP with Bootstrapping Remote Secure Key Infrastructures > (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the > "Autonomic Network Infrastructure" as defined in > [I-D.ietf-anima-reference-model], which provides autonomic > connectivity (from ACP) with fully secure zero-touch (automated) > bootstrap from BRSKI. The ANI itself does not constitute an > > nit: It's unclear that there's universal agreement about what "fully > secure" might mean, so I'd suggest just using "secure". Done. > Section 2 > > ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate > (LDevID) carrying the domain information field which is used by > > nit: I think the reference is for "certificate", not "provisioned". > > ACP secure channel: A cryptographically authenticated and encrypted > data connection established between (normally) adjacent ACP nodes > to carry traffic of the ACP VRF secure and isolated from Data- > Plane traffic in-band over the same link/path as the Data-Plane. > > nit: I'm not sure if "secure" or "securely" is better (but what does > "secure from" mean?) securely sounds find. fixed. I think its read ... "secure(ly)" and "isolated from". > > Enrollment: The process where a node presents identification (for > example through keying material such as the private key of an > IDevID) to a network and acquires a network specific identity and > trust anchor such as an LDevID. > > nit: the LDevID is the identity; it's not a trust anchor. Fixed to: network specific identity such as an LDevID and trust anchors such as Certificate Authority (CA) certificate. > Section 5 > > 3. For each node in the candidate peer list, it authenticates that > node (according to Section 6.1.2) and negotiates a mutually > acceptable channel type. > > 4. For each node in the candidate peer list, it then establishes a > secure tunnel of the negotiated type. The resulting tunnels are > then placed into the previously set up VRF. This creates an > overlay network with hop-by-hop tunnels. > > nit: the "channel type" of (3) is the "negotiated type" of the "secure > tunnel" in (4), right? It might be nice to use the same word in > both items, to help tie the language together. Changed to "negotiated channel type in 4". > Section 6 > > nit: "must have it's ACP domain certificate" gained an apostrophe in "it's" > but the original "its" was correct. fixed. > Section 6.1 > > members. The LDevID is used to cryptographically authenticate the > membership of its owner node in the ACP domain to other ACP domain > members, the TA is used to authenticate the ACP domain membership of > other nodes (see Section 6.1.2). > > nit: comma splice fixed (two sentences). > The ACP does not mandate specific mechanisms by which this keying > material is provisioned into the ACP node, it only requires the > Domain information field as specified in Section 6.1.1 in its domain > certificate as well as those of candidate ACP peers. See > > nit: comma splice fixed (two sentences). > The ACP domain certificate SHOULD be used for any authentication > between nodes with ACP domain certificates (ACP nodes and NOC nodes) > where the required condition is ACP domain membership, such as ACP > > nit(?) I'd suggest s/required condition/required authorization > condition/ fixed. > Section 6.1.1 > > The ABNF in Figure 2 seems to have multiple what I'll call for lack of a > better term "terminal constructions" (i.e., routing-subdomain and > domain-information) that are not used in other rules. Some text on > which one is used in the rfc822Name and which is just informational for > other purposes is probably in order. Added below figure: domain-information is the encoded information that is put into the ACP domain certificates subjectAltName / rfc822Name field. routing-subdomain is a string that can be constructed from the domain-information, and it is used in the hash-creation of the ULA (see below). The requirements and sementics of the parts of this information are explained in the following paragraphs: I think there are no more terminal name than those two. > o The maximum size of "domain-information" is 254 characters and the > maximum size of node-info is 64 characters according to [RFC5280] > that is referring to [RFC2821] (superseded by [RFC5321]). > > nit: I don't think we refer to node-info anywhere. s/node-info/local-part/ > On the topic of rfc822Name vs. otherName, I note that there's no > requirement to use ASN.1 for the internal structure of the value; it's > perfectly acceptable to make it an OCTET STRING and shove a > more-friendly data structure in there. (It's a little bit weird in > terms of mental models, but funny looks aside, it's pretty common.) If > the other structure is fixed-length, there is not any actual ASN.1 > knowledge required by the recipient; they just check that the length is > right and the data starts with the correct fixed prefix (corresponding > to the OID and ASN.1 length encoding), before processing the encoded > data in whatever manner is appropriate. Since we want to put domain > names in, fixed-length is probably out of the figure, but even if we're > limited to what openssl provides, getting an ASN1_OCTET_STRING and > extracting its contents to a pointer+length is pretty well established; > we don't need to make people learn about ASN1_SEQUENCE() at all. So you > could have the fundamental structure of the otherName be something like: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +---------------------------------------------------------------+ > | Flags |M|A| > +---------------------------------------------------------------+ > | | > + + > | | > + [acp-address] + > | | > + + > | | > +---------------------------------------------------------------+ > | rsub-len | rsub... | > +------------------------------+ + > ~ ~ > +---------------------------------------------------------------+ > | acp-domain-len | acp-domain... | > +------------------------------+ + > ~ ~ > +---------------------------------------------------------------+ > | [TLV extensions] | > +---------------------------------------------------------------+ > > where M means that the holder of the cert is allowed to establish an ACP > secure channel (what the '0' acp-address does in the present > formulation) and A means that the acp-address field is present > > and just pack that into an OCTET STRING. > > Is the rfcSELF@acp.example.com email address for human use really > providing much value? This is pretty clearly breaking an abstraction > barrier, from my point of view. See above at the DISCUSS for my list of reasons to go with the rfc822name encoding. Compared to your (more efficient) encoding, its specifically about diagnostics and the ability for any existing certificarte tool to correctly display a string for an existing field (rfc822name). What would a randomn existing tool show a human for your field ? could i easily copy & paste it, could i easily have a script put it into a list, copy into excel spreadsheet (annoyingly enough we still live in a world where we need to deal with humans and their preferences. We're trying to minize what humans need to manage in ANIMA/ACP, but this is exactly the pieces they will need to deal with whenever they troubleshoot). We wouldn't only have to redo the whole encoding into the certificate as you proposed, but also come up with recommended standard representations for humans to make it easy to operate across all type of tool chains where humans are involved. Which could be the rfc822 representation because its kinda nicely human logical ("node+tags@domain"...). > It also makes acp-domain-name a valid e-mail target across all > routing-subdomains. > > nit: rfcSELF@acp-domain-name actually "domain-information", fixed. > o It should be possible to share the LDevID with other uses beside > the ACP. Therefore, the information element required for the ACP > should be encoded so that it minimizes the possibility of creating > incompatibilities with such other uses. > > otherName with an ACP-specific OID has zero possibility of collisions > with other uses; reusing rfc822Name has nonzero possibility of > collision. (Note that having multiple otherNames is allowed.) Q1: Who allocates the OID ? Q2: Could we put the currently domain-information into the otherName as a string ? Q3: Would existing tools that deparse certificates human readable display OtherNames that are string type (with e.g.: BER) ? > o The information for the ACP should not cause incompatibilities > with any pre-existing ASN.1 software. This eliminates the > introduction of a novel information element because that could > require extensions to such pre-existing ASN.1 parsers. > > Even getting to the rfc822Name requires some level of ASN.1 parsing, so > it's unclear how strong this argument really is. >From what we discussed in the WG, all ASN.1 parsers people knew would already be able to parse those defined fields, especially rfc822Name > > o The element required for the ACP should not be misinterpreted by > any other uses of the LDevID. If the element used for the ACP is > interpreted by other uses, the impact should be benign. > > [OIDs are by construction unique] See Q1. > o At minimum, both the AN domain name and the non-domain name > derived part of the ACP address need to be encoded in one or more > appropriate fields of the certificate, so there are not many > alternatives with pre-existing fields where the only possible > conflicts would likely be beneficial. > > It's even possible to define multiple OIDs for otherName use, one for > acp-domain-name, one for rsub, etc.. But that feels kind of like > overkill to me. See above. I am a lot more partial to keep a easily human readable string representation of the information than using rfc822Name. And i do not really want to bother about two representations (human vs. machine) in this case. Not using rfc822Name would also give the ability to define a longer limit for local-part which is my biggest worry when we're talking future extensions. > Section 6.1.2 > > 3: The peer's certificate passes certificate path validation as > defined in [RFC5280] against one of the Trust Anchors associated > with the ACP nodes ACP domain certificate (see Section 6.1.3 > below). > > nit: "node's" possessive Fixed. > 4: If the node certificate indicates a Certificate Revocation List > (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or > Online Certificate Status Protocol (OCSP) responder ([RFC5280], > section 4.2.2.1), then the peer's certificate must be valid > according to those criteria: An OCSP check for the peer's > certificate across the ACP must succeed or the peer certificate > must not be listed in the CRL retrieved from the CDP. [...] > > side note: we could (but don't have to) note that OCSP stapling is a > way to get an OCSP response to check. Right. thats why i fixed the text already via feedback to i think your first round by adding that this only applies when the security association protocol is incapable to carry the CDP/OCSP information itself. > 5: The peer's certificate has a syntactically valid ACP domain > information field (encoded as subjectAltName / rfc822Name) and the > acp-domain-name in that peer's domain information field is the > same as in this ACP node's certificate (lowercase normalized). > > (Writing this as "has an otherName subjectAltName using the ACP OID" > seems more concise to me, but I'll try to stop beating that horse.) ;-) Let me understand your answers to Q1...Q3 and also tell me what you think about keeping the string ("looks like an email identity") enoding but using your suggested field. > When an ACP node learns later via OCSP/CRL that an ACP peers > certificate for which rule 4 had to be skipped during ACP secure > channel establishment is invalid, then the ACP secure channel to that > peer SHOULD be closed even if this peer is the only connectivity to > access CRL/OCSP. The ACP secure channel connection MUST be retried > periodically to support the case that the neighbor aquires a new, > valid certificate. > > nit: we could probably tighten up the writing here about "MUST be > retried periodically" in terms of needing to reestablish the TLS > connection provisionally and repeat the initial connection steps, though > on second read the current text seems better than I thought on first read. I will not take action against this comment as i am not clear what the suggestion exactly is. Do you want me to try to cut the first sentence into multiple smaller ones to make sound less like a german hold hostage by the english language (or vice versa). > Only when checking a candidate peer's certificate for the purpose of > establishing an ACP secure channel, one additional check is > performed: > > nit: I'd suggest s/Only when/When/ Done. > Formally, the ACP domain membership check includes both the > authentication of the peers certificate (steps 1...4) and a check > authorizing this node and the peer to establish an ACP connection > and/or any other secure connection across ACP or data-plane end to > end. Step 5 authorizes to build any non-ACP secure connection > between members of the same ACP domain, step 5 and 6 are required to > build an ACP secure channel. For brevity, the remainder of this > document refers to this process only as authentication instead of as > authentication and authorization. > > I'd prefer to see a penultimate sentence along the lines of "Other > authorization models are possible by local policy, but for this > specification (and to some extent, autonomic systems in general), domain > membership is deemed sufficient authorization for all operations." "_local_ policy" is in general a big no-no for us except where we can't avoid it, so i better don't say "local" this without good reason. I also don't find this section specifically talking about ACP Domain membership check the right place to say this. I did ad the following paragraph to the new section 6.1.1 about ACP domain certificates: Note that is no intention to constrain authorization within the ACP or autonomic networks using the ACP to just the ACP domain membership check as defined in this document. It can be extended or modified with future requirements. Such future authorizations can use and require additional elements in certificates or policies or even additional certificates. For example, see . Aka: that example in the appendix already is explaining our recognition that for higher layers at least roles seem to be clearly needed to create better security. Indeed the flag in the certificate for an EST server is really just a speific example of such a role. Except that it seems to be called "extended certificate usage" instead of role ;-). > Section 6.1.3 > > A certificate path is a chain of certificates starting at a self- > signed certificate of a so called root-CA or Trust Anchor, followed > > nit(?): I'm used to seeing chain construction start at the > leaf/end-entity and chain up to the root, but to some extent this is an > editorial question. In routing and biology, trees start at the root, so pls. excuse my ignorance ;-) fixed to: A certificate path is a chain of certificates starting at the ACP certificate (leaf/end-entity) followed by zero or more intermediate Trust Point or sub-CA certificates and ending with a self-signed certificate of a so called root-CA or Trust Anchor. > A single owner can operate multiple independent ACP domains from the > same set of private trust anchors (CAs) when the ACP Registrars are > trusted not to permit certificates with incorrect ACP information > fields to be signed. Such as ACP information with a wrong acp-domain > field. [...] > > nit: This last sentence is a sentence fragment (I suggest joining it to > the previous one with a comma). Done. > Section 6.1.4 > > with its ACP domain certificate. When BRSKI (see > [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of > the BRSKI registrar from the BRSKI TLS connection SHOULD be > remembered and used for the next renewal via EST if that registrar > also announces itself as an EST server via GRASP (see next section) > on its ACP address. > > IIUC, the BRSKI spec currently advertises BRSKI registrars with the > EST-TLS objective, and I don't really understand how this interacts with > SRV.est or whether this text should change. The equivalent to the SRV.est announcement is actually in BRSKI the AN_join_registrar announcement. A registrar that does both BRSKI (initial enrollment) and renewal (EST propoer) would send both announcements. I think this text is fine. > Section 6.1.4.1 > > The objective name "SRV.est" indicates that the objective is an > [RFC7030] compliant EST server because "est" is an [RFC6335] > registered service name for [RFC7030]. Objective-value MUST be > ignored if present. Backward compatible extensions to [RFC7030] MAY > be indicated through objective-value. Non [RFC7030] compatible > certificate renewal options MUST use a different objective-name. > > I'd consider adding some text about ignoring unrecognized > objective-values, to attempt to preserve the usability of this extension > point. Non-recognized objective-values (or parts thereof if it is a structure partially understood) MUST be ignored. > Section 6.1.4.3 > > The ACP node SHOULD support Certificate Revocation Lists (CRL) via > HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s) > > My understanding is that HTTP-not-s is commonly used for CRL > distribution since the CRL content itself is signed, and there would be > a risk of a circular dependency in validating the server's TLS > certificate to get to the CRL information. Fixed. > HTTPs connections. The connecting ACP node SHOULD verify that the > CDP certificate used during the HTTPs connection has the same ACP > address as indicated in the CDP URL of the nodes ACP domain > certificate if the CDP URL uses an IPv6 address. > > nit: "node's" possessive. fixed. > Section 6.1.4.5 > > enrollment. Using the ACP node's domain certificate allows the BRSKI > registrar to learn that nodes ACP domain information field, so that > > nit: "node's" possessive. fixed > with its old ACP certificate. The re-enrolling candidate ACP node > SHOULD only request a voucher from the BRSKI registrar when this > authentication fails during TLS connection setup. > > I might suggest "SHOULD only fall back to requesting a voucher". fixed. > Section 6.1.4.6 > > An ACP domain certificate is called failing in this document, if/when > the ACP node can determine that it was revoked (or explicitly not > renewed), or in the absence of such explicit local diagnostics, when > the ACP node fails to connect to other ACP nodes in the same ACP > domain using its ACP certificate. For connection failures to > > nit: maybe "the ACP node to which the certificate was issued", since > when I first read this I was expecting it to be about telling that some > other node's certificate is failing, not a node's own certificate. fixed. > Section 6.5 > > 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. > (This is a future-looking statement that implies uncertainty in the > current spec.) Yikes. How did this sentence survive so long. With all the other places pounding on the key thing being to not mandate a single network wide MTI because there is sufficient insight that it would be way too limiting. removed. Thanks a lot. > [11:C2] Node 2 certificate has lower ACP Node-ID than Node2, > therefore Node 1 considers itself Bob and Node 2 Alice > on connection C1, but they also identify that C2 is to the > > I think this first "Node 2" should be "Node 1"? Fixed. > interface" that they both connect to. An autonomic node must not > assume that neighbors with the same L2 or link-local IPv6 addresses > on different L2 interfaces are the same node. This can only be > determined after examining the certificate after a successful > security association attempt. > > This could potentially be a "MUST NOT". fixed. > Section 6.7.1.1 > > To run ACP via IPsec natively, no further IANA assignments/ > definitions are required. An ACP node that is supporting native > IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and > peer link-local IPv6 addresses used for encapsulation. It MUST then > support ESP with AES-256-GCM ([RFC4106]) for encryption and SHA256 > hash and MUST NOT permit weaker crypto options. Key establishment > MUST support ECDHE with P-256. > > I don't think "SHA256 hash" is quite specific enough (and we probably > want GMAC for integrity anyway). In the answer to your i already changed this text to ENCR_AES_GCM_16. The way i understand it (pls. help me if i am wrong), it comes with its own integrity protection mechanism. Pls. check new text in 6.7.1.1 > Section 6.7.1.2 > > To run ACP via GRE/IPsec, no further IANA assignments/definitions are > required. An ACP node that is supporting ACP via GRE/IPsec MUST then > support IPsec security setup via IKEv2, IPsec transport mode, local > and peer link-local IPv6 addresses used for encapsulation, ESP with > AES256 encryption and SHA256 hash. > > Why is IPsec/GRE using AES256/SHA256 when IPsec native is using > AES256-GCM? Error in duplication. New text from your and erics review removes all duplication and has GRE just refer to the native requirements and only explain changes. > Section 6.7.2 > > We define the use of ACP via DTLS in the assumption that it is likely > the first transport encryption code basis supported in some classes > of constrained devices. > > nit: I don't think "basis" is quite the right word, here; maybe "base" > (or collapsed back to "codebase" as one word) or omit it entirely. deleted term. > Section 6.7.3 > > support DTLS. An ACP node connecting an area of constrained ACP > nodes with an area of baseline ACP nodes MUST therefore support IPsec > and DTLS and supports therefore the baseline and constrained profile. > > nit: this could probably work just fine as a non-normative "must", since > it's just describing facts. fixed. > Section 6.8.2 > > nit: Figure 8 has a doubled word "ACP GRASP virtual virtual interfaces" > in the second box from the top. > fixed > ............................................................... > . | | | ^^^ Users of ACP (GRASP/ASA) . > . | | | ACP interfaces/addressing . > . | | | . > . | | | A > . | ACP-Loopback Interf.| <- ACP Loopback interface C > . | ACP-address | - address (global ULA) P > . subnet1 | subnet2 <- ACP virtual interfaces . > . link-local | link-local - link-local addresses . > ............................................................... > > I'm still a bit confused by this box in the figure -- is the "Users of > ACP" label supposed to apply to the previous box(es) or the current one? > If the former, it's confusing to see the "ACP security and transport > substrate for GRASP" being described as a "user of ACP". Changed to "Users of ACP interfaces". Alas i have no more lines without breaking the picture onto multiple pages in RFC TXT so i can not well try to carve out better space to show where ASA sit (difficult as they would use both ACP interfaces as well as some GRASP API. > GRASP unicast messages inside the ACP always use the ACP address. > Link-local addresses from the ACP VRF must not be used inside > objectives. GRASP unicast messages inside the ACP are transported > via TLS 1.2 ([RFC5246]) connections with AES256 encryption and > SHA256. Mutual authentication uses the ACP domain membership check > defined in (Section 6.1.2). > > Just "AES256 encryption and SHA256" describes quite a few TLS > ciphersuites > (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4); > I'd suggest limiting to a specific handful like > "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" > (the "Recommended" column in > the registry will be helpful at picking things). > It's probably also useful to specify a RSA/ECDSA key size (and elliptic > curve for ECDSA) and the nature of the ECDHE or DHE. Can you please suggest recommended text here ? I spent a lot of reading up on the whole IPsec/channel level especially also because you indicated we would need other folks to help on IPsec, but i figure you would be a good person to ask for TLS. Given how this is all new code, i see no reason to have mor than one MTI, its also easy to override at application level (this would ahppen for application scoped GRASP TLS connections). How about mandating LS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 I have no idea how ECDHE are intermixed with RSA here, and what key sizes we talk about - i hope the one from the cert, but the cert would only hae one type of public key, ECDHE or RSA, right ? > Section 6.8.2.1 > > If GRASP peer connections would just use TCP, compromised ACP members > could simply eavesdrop passively on GRASP peer connections for whom > they are on-path ("Man In The Middle" - MITM). Or intercept and > > nit: I'd suggest "were to use just TCP". fixed. > modify them. With TLS, it is not possible to completely eliminate > > nit: sentence fragment merged with prior sentence. > > Section 6.10 > > Links inside the ACP only use link-local IPv6 addressing, such that > each nodes ACP only requires one routable virtual address. > > nit: "node's" possessive. fixed. > Section 6.10.2 > > o Establishing connectivity between different ACP (different acp- > domain-name) is outside the scope of this specification. If it is > being done through future extensions, then the rsub of all > routing-subdomains across those autonomic networks need to be > selected so their hashes do not collide. For example a large > > nit: the grammar could be more clear that it's hash(routing-subdomain) > that must be collision-free, rather than hash(rsub) Fixed to .. so the resulting routing-subdomain hashes.. > Section 6.10.7.2 > > information - ACP domain-name, ACP-address, and so on. If the ACP > registrar uses BRSKI, it signals the ACP domain information field to > the Pledge via the EST /csraddrs command (see > [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR > Attributes"). > > I don't see a "csraddrs" EST well-known URL in either BRSKI or RFC 7030 > (and the section number is probably stale as well, as the RFC Editor > note attests). Oh, but /csrattrs is very close, so this is likely just > a typo. fixed to csrattr, section now 5.9.2 in brski-22 > Section 6.10.7.3 > > scheme. The first address of the prefix is the ACP address, all > other addresses in the prefix are for other uses by the ACP node as > described in the zone and Vlong addressing sub scheme sections. The > > nit: comma splice fixed. > policy. For example, in BRSKI, the ACP registrar is aware of the > IDevID of the candidate ACP node, which contains a serialNnumber that > is typically indicating the nodes vendor and device type and can be > > nits: "serialNumber", "node's vendor" possessive fixed > > ACP registrars SHOULD default to allocate ACP zone sub-address scheme > addresses with Subnet-ID 0. Allocation and use of zone sub-addresses > with Subnet-ID != 0 is outside the scope of this specification > > nit: it's only referred to as "Subnet-ID" in the manual addressing > sub-scheme; for the zone addressing sub-scheme it's "Zone-ID". > *yikes*. Good catch. There was one more further down of this mistake. fixed. > Section 6.11.1.1 > > Additionally, failed ACP tunnels can be quickly discovered the secure > channel protocol mechanisms such as IKEv2 Dead Peer Detection. This > > nit: missing word, maybe "through the secure channel protocol" fixed. > Section 6.11.1.9 > > [RFC6550] security not used, substituted by ACP security. > > Because the ACP links already include provisions for confidentiality > and integrity protection, their usage at the RPL layer would be > redundant, and so RPL security is not used. > > The ACP links provide only hop-by-hop security, but it looks like at > least some of the RFC6550 mechanisms provide more global source > authentication. (I'm not suggesting we change the protocol to use RPL > security, just noting that this text is not quite right about being > entirely redundant.) I really have no idea. I had these profile template points be filled out by Pascal Thubert, so i would assume it is correct. I forwarded the nit to him, let's see what he says. > Section 6.11.1.14 > > I still think it's worth calling out that the RPL root is not > necessarily preconfigured and this "SHOULD" requirement could > potentially apply to any node, but this is only Comment-level and you > should feel free to ignore it. Check the paragraph i inserted into the section for your first review email talking about how this does not apply to nodes supporting only "default" administrative preference. Hope this is a good trick to aleviate the need for forwarding plane enhancemeents on that wouldn't never become root in a network operating in a state where this diagnostic function would be useful. > Section 6.12.5 > > Care must also be taken when creating multi-access ACP virtual > interfaces across ACP secure channels between ACP nodes in different > domains or routing subdomains. The policies to be negotiated may be > described as peer-to-peer policies in which case it is easier to > create ACP point-to-point virtual interfaces for these secure > channels. > > nit: the text is unclear about what sort of policies are being > negotiated. Changed sentence to: If for example future inter-domain ACP policies are defined as "peer-to-peer" policies, it is easier to create ACP point-to-point virtual interfaces for these inter-domain secure channels. > Section 8.1.1 > > When an ACP Edge node receives a packet from an ACP connect > interface, it MUST only forward it intot he ACP if it has an IPv6 > > nit: "into the" fixed. > Section 9.1 > > when using OCSP/CRL. The same benefit can be achieved when using > CRL/OCSP, periodically refreshing the revocation information and > also tearing down ACP secure channels when the peers (long-lived) > certificate is revoked. There is no requirement against ACP > > nit: "peer's" possessive fixed. > partition is left with one or more of such ACP registrars, it can > continue to enroll new candidate ACP nodes as long as the ACP > registrars sub-CA certificate does not expire. Because the ACP > > nit: "registrar's sub-CA" possessive fixed. > Section 9.2.2 > > not the Data-Plane. Especially for those management plane functions > that have no good protection by themselves because they do not have > secure end-to-end transport and to whom ACP does not only provides > automatic reliable connectivity but also protection against attacks. > > nit: s/does not only/not only/ fixed > Section 9.3 > > An ACP is self-forming, self-managing and self-protecting, therefore > has minimal dependencies on the administrator of the network. > Specifically, since it is (intended to be) independent of > configuration, there is no scope for configuration errors on the ACP > itself. The administrator may have the option to enable or disable > > nit: Given that Section 8.2.1 talks about configuring ACP neighbors and > 8.2.2 about configuring tunneled neighbors, I'd suggest to s/no > scope/only limited scope/, fixed. > and perhaps similar tweaks in the following paragraphs. fixed to. While configuration (except for and ) is not possible > Section 10.1 > > o Check the validity of the domain certificate: > > * Does the certificate authenticate against the trust anchor? > > nit: s/authenticate/validate/ fixed. > - The neighbors certificate does not have the required > trust anchor. Provide diagnostics which trust anchor it > has (can identify whom the device belongs to). > > - The neighbors certificate does not have the same domain > (or no domain at all). Diagnose domain-name and > potentially other cert info. > > - The neighbors certificate has been revoked or could not > be authenticated by OCSP. > > - The neighbors certificate has expired - or is not yet > valid. > > nit: s/neighbors/neighbor's/ (every time) fixed > Section 10.2.2 > > For BRSKI or other mechanisms using vouchers: Parameters to > determine how to retrieve vouchers for specific type of secure > bootstrap candidate ACP nodes (such as MASA URLs), unless this > information is automatically learned such as from the LDevID of > candidate ACP nodes (as defined in BRSKI). > > I thought the LDevID was essentially synonymous with "ACP domain > certificate" in this document, so I can't understand what this means > (unless IDevID was intended). Yes, this and i think one or two more typos LDevID -> IDevID where fixed already for your first review email. > Section 10.2.3 > > Even when such a malicious ACP registrar is detected, resolving the > problem may be difficult because it would require identifying all the > wrong ACP domain certificates assigned via the ACP registrar after it > was compromised. And without additional centralized tracking of > assigned certificates there is no way to do this. > > side note: RFC 6962-style certificate transparency is a somewhat > decentralized way to do such tracking, though I do not think the > engineering tradeoffs favor trying to use it for this situation. Interesting RFC. i pondered adding a reference to it, because some of the actual logging data structures seems quite useful, but the openness model would very likely scare operators off ("ACP makes me public how many and what nodes my network has ??? go away"). > Section 10.2.5 > > Which candidate ACP node is permitted or not permitted into an ACP > domain. This may not be a decision to be taken upfront, so that a > per-serialNumber policy can be loaded into ever ACP registrar. > > nit: "every" fixed. > Section 10.3.x > > I still think the document quality here is not as mature as the majority > of the document, though concede there is value in covering these topics > to some extent in the initial work. Copied from reply to your first mail: Not sure how i could bake it better, but it would probably not be worth it in this document, given how this is mostly food for thought not impacting interoperability and standardization would only come through implementation and deployment experimentation followed by some Yang model. Other reviewers (Joel if i remember correctly) where grumbling, but couldn't provide any better suggestions of how to make operator level interface shutdowns more resilient against unintential network disconnect. Hence i argued strongly to keep this section in there as important food for thought, especially because its been the #1 ask against ACP to figure out by operators i talked to. > Section 10.3.5 > > interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will > operate interface where "ACP/ANI enable" is set. Setting of > > nit: "operate on interfaces where" fixed > Section 10.3.5.1 > > Automatically setting "ANI enable" on brownfield nodes where the > operator is unaware of it could also be a critical security issue > depending on the vouchers used by BRKSI on these nodes. An attacker > could claim to be the owner of these devices and create an ACP that > the attacker has access/control over. In networks where the operator > explicitly wants to enable the ANI this could not happen, because he > would create a BRSKI registrar that would discover attack attempts. > Nodes requiring "ownership vouchers" would not be subject to that > attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more > details. Note that a global "ACP enable" alone is not subject to > these type of attacks, because it always depends on some other > mechanism first to provision domain certificates into the device. > > It's probably worth double-checking that all of these details are still > synchronized with RFC 8366 and the current state of BRSKI. Yepp. Nothing changed as this is very fundamental, but i still rewrote the paragraph somewhat to better express the main concern, which is that an operator with no clue what BRSKI/MASA is even though his devices support it would not attempt to get an account at the MASA and that opens the door to attackers to easier do some form of identity theft "Frank, we got a letter from our router-vendor with techno-mumbo-jumbo-masa-account", "oh, no idea, we're not using that stuff. throw it in the trash bin". And then someone who did forge the request to get the account for the company goes through that company's trash. > Section 10.3.6 > > Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the > reliable operations of the ACP if it can be executed by mistake or > unauthorized. This behavior could be influenced through some > additional property in the certificate (e.g., in the domain > information extension field) subject to future work: In an ANI > > [I don't know if it was intentional or an omission to leave this "future > work" note in place when most others were removed.] I only got rid of all "future" in the normative part, which didn't only consist of removing the word, but moving text out of the normative section referring to this - and this is where such text ended up being (non-normative). Consider this 10.3.x stuff to be staging for hopefully something we would put into YANG in followup work (and as in this case extensions to the cert). (unless we define operator interfaces via YANG, we can't standardize them anyhow). > Section 10.4 > > There is no desirable configuration for the ACP. Instead, all > parameters that need to be configured in support of the ACP are > limitations of the solution, but they are only needed in cases where > not all components are made autonomic. Whereever this is necessary, > it will rely on pre-existing mechanisms for configuration such as CLI > > "will rely on" can also be seen as an indicator for future work. In this case i was just thinking about the future as implementations of this spec, not future features. So i reworded to "it relies on". > > o When the ACP needs to be extended across interfacess other than > L2, the ACP as defined in this document can not autodiscover > candidate neighbors automatically. Remove neighbors need to be > configured, see Section 8.2. > > nit: s/Remove/Remote/ fixed. > Once the ACP is operating, any further configuration for the data- > lane can be configured more reliably across the ACP itself because > > nit: data-plane fixed before. > Section 11 > > o Every ACP registrar is criticial infrastructure that needs to be > hardened against attacks similar to a CA. A malicious registrar > > nit: as written, this parses as saying that the attacks are similar to a > CA, not the amount of hardening needed on the ACP registrar. Adding a > comma would probably help. fixed. > The ACP It is designed to enable automation of current network > management and future autonomic peer-to-peer/distributed network > > s/It // fixed. > Attacks from impacted ACP nodes against the ACP are more difficult > than against the data-plane because of the autoconfiguration of the > ACP and the absence of configuration options that could be abused > that allow to change/break ACP behavior. This is excluding > configuration for workaround in support of non-autonomic components. > [...] > The ACP acts as a security (and transport) substrate for GRASP inside > the ACP such that GRASP is not only protected by attacks from the > outside, but also by attacks from compromised inside attackers - by > relying not only on hop-by-hop security of ACP secure channels, but > adding end-to-end security for those GRASP messages. See > Section 6.8.2. > > This is true, but the system as a whole still has the weakness that the > compromised node is able to announce GRASP objectives for arbitrary > services and potentially cause legitimate traffic to be directed towards > it. The connection would still validate (until the certificate > expires or is revoked) and the attacker could return bad data that > causes honest nodes to misbehave. Yes. For non-autonomic networks such as those we target via rfc8368, i think we can most easily solve this problem easily via cert bits for Roles (A.10.5), so only NOC equipment can announce services. Note that this was traditionally not a real issue which is why we didn't wanted to add all these aspects to certs initially: you would have a real hard time to get new attack software into a typical legacy HW network infra. You'd have to attack by adding new hardware that has the software. Of course, in the last 5 years (after we started this *sigh*) network infra components become a lot more like PCs, so adding software becomes easier and hence also attacks from such software. And i fear that even though secure boot etc. exists, the security chains there are not necesssarily very strong. More fully distributed, self-organizing "Autonomic" solutions of course will be tougher. I would be happy if we can show that the security shell provided by the ACP and secure router platforms would be strong enough that there is enough room for starting to deploy more distributed services management without necessarily having to figure out upfront how to build self-organizing higher levels of security such as through self-learning reputation sccoring or the like. There is just a difference between what would be fun to do, and what i as an operator would be willing to accept as baked enough at any point in time ;-) > revocation and non-renewal of short-lived cdrtificates. In this > > nit: "certificates" fixed. > Section A.6 > > In my opinion, a lot of this could be split out into a separate draft > (that need not be published as an RFC) and just a couple paragraphs left > here with a pointer to that separate draft. But this is only a > Comment-level point, and I do not insist on it. Hah. In the other reply i gave you i think i referred to this text as already removed, but i forgot that the idea was to remove it before publication. So now i added the two notes to the top of this section: [RFC Editor: This section to be removed before RFC. [This section kept for informational purposes up until the last draft version as that would be the version that readers interested in the changelog would also go to to revisit it.] E.g.: I think its hard to justify putting more time (like separate RFC) into something that should be called "leftover ramblings from when we worked out the ACP, that we really should not forget". Going up to last draft seems like a low-cost compromise. Btw: Its nice you didn't say this is crazy, because as i mentioned in the other mail, the WG conclusion was that this type of multi-stage negotiation would be way too complex (hence also the removal). ;-) > Section A.7 > > An ACP domain is the set of all ACP nodes using certificates from the > same CA using the same domain field. GRASP inside the ACP is run > across all transitively connected ACP nodes in a domain. > > It's not entirely clear to me that we need to insist on a single shared > CA; given our discussion of potentially joining two distinct ACT domains > into a combined network, it seems that we just need to have all nodes > using the same set of trust anchor(s), which could potentially include > multiple CAs. (There would of course need to be some out-of-band > mechanism to avoid address-assignment collisions, which could be as > simple as rsub.) "from one or more Trust Anchors (TA) (typically one CA)" > Section A.8 > > For example, Intent could indicate the desire to build an ACP across > all domains that have a common parent domain (without relying on the > rsub/routing-subdomain solution defined in this document). For > example ACP nodes with domain "example.com", "access.example.com", > "core.example.com" and "city.core.example.com" should all establish > one single ACP. > > It is interesting to see this discussion in the context of the text in > the previous section about """If different ACP domains are to be created > [...] Domains "example.com" and "research.example.com" are separate > domains if both are domain elements in the domain information element of > certificates.""" Because this document doesn't intend to fnish working this out, its in appendices ;-) > Section A.8 > > There still feels like a lot of speculative things in here; I'd suggest > adding a disclaimer/introduction at the top that "Intent is the > architecture component [...]. Its applicability for use is quite > flexible and freeform, with potential applications including:" Its applicability for use is quite flexible and freeform, with potential applications including policies flooded across ACP GRASP and interpreted on every ACP node. i like "flexible and freeform" as a euphemism for "unclear, undefined and ongoing contentuous" ;-)) But yes, once we come up with specific policies we want to get standardized, we'll figure out a fitting way to do it, and thats what we then call Intent ;-) > Section A.9 > > Some solutions may already have an auto-addressing scheme, for > example derived from existing unique device identifiers (e.g., MAC > addresses). In those cases it may not be desirable to assign > addresses to devices via the ACP address information field in the way > described in this document. The certificate may simply serve to > identify the ACP domain, and the address field could be empty/unused. > The only fix required in the remaining way the ACP operate is to > define another element in the domain certificate for the two peers to > decide who is Alice and who is Bob during secure channel building. > > I think we need to mention this requirement for tiebreaking earlier in > the document, when we introduce the possibility of a certificate with > ACP address of '0'. The "0" address ACP nodes are not allowed to build secure channels, they are for ACP-connect'ed nodes in the NOC (i added that explanation through the reply to your first review email). The ++ = no-address ACP addresses are the ones that this spec does not define but supports interop with (by defining the address format). Added to the channel selection text in 6.5: A peer with an empty ACP address field in its ACP domain certificate becomes Bob (this specification does not define such peers, only the interoperability with them) In other words: I do not know nor care yet how to decide on Alive vs. Bob when both peers have no ACP address in their certificate. Subject to future work. > Section A.10 > > nit: the section title uses "futures" as a standalone term synonymous > with "future work"; unfortunately, "futures" is already an English word > with a quite distinct meaning. Changed to: "Further (future) options" I could sell you some A.10.7 options, sure they will go up in value ;-) (is that what you meant ?). > Section A.10.7 > > 1. Consider if LLDP should be a recommended functionality for ANI > devices to improve diagnostics, and if so, which information > elements it should signal (insecure). Includes potentially new > information elements. > > I'd suggest changing the parenthetical to "noting that such information > is conveyed in an insecure manner)". Fixed. > 3. The IDevID of BRSKI pledges should be included in the selected > insecure diagnostics option. > > In some environments (not really the current target case of Enterprise > networks) the IDevID would be considered privacy-sensitive, which may be > worth mentioning again here. Hmm. i went with a security example (which is arguably one reason for the desire of privacy, but i think many readers would associate privacy mostly with humans, so would be harder to read by some): This may be undesirable when exposure of device information is seen as too much of a security issue (ability to deduce possible attack vectors from device model for example) I also added a similar note to the end of the paragraph in 6.1.1 about certificates: Any other field of the ACP domain certificate is to be populated as required by or desired by the operator of the ACP domain ACP registrars/CA and required by other purposes that the ACP domain certificate is intended to be used for. For diagnostic and other operational purposes, it is beneficial to copy the device identifying fields of the node's IDevID into the ACP domain certificate, such as the "serialNumber" (see section 2.3.1). Inclusion of this information makes it easier to potentially attack the node though, for example by learning the device model, which may help to select a fitting subset of attacks. Neighboring attackers can retrieve the certificate through an otherwise unsuccessful initiation of a secure channel association. > Section A.10.8 > > Ensuring that manaement sessions using invalidated credentials are > > typo: "management" Fixed. From nobody Tue Nov 5 15:20:12 2019 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 7454112008F; Tue, 5 Nov 2019 15:20:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=cert.org 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 Rxu0JTHFJyOJ; Tue, 5 Nov 2019 15:20:02 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.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 31E9E120072; Tue, 5 Nov 2019 15:20:00 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xA5NJcN7032648; Tue, 5 Nov 2019 18:19:38 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu xA5NJcN7032648 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1572995978; bh=0YLRDe4OJ7AgOs+53BHBsaaj/Jgpf4JTccAKMjIaDTE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ptBOEz2IDu2FA+iww9KNlZVDZzKRyMhirFiQdKbqoFLEUAIn+EMmkvRhofsS91+BZ zPky+wETKgvUxlR3j83lB3SYGgIj4jG62dRYKy+IE460jPKNNfZtu6PeAmmLGRRAwh qcIACCPhzfC+ck8d4OEYLxQehksI+xKjeKhjDPpk= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xA5NJXrD008972; Tue, 5 Nov 2019 18:19:33 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Tue, 5 Nov 2019 18:19:33 -0500 From: Roman Danyliw To: "'Michael Richardson'" , Christian Huitema CC: "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , "tte+ietf@cs.fau.de" , "anima-chairs@ietf.org" , "The IESG" , "anima@ietf.org" Thread-Topic: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) Thread-Index: AQHVhIeYyx5AvXxfuUGQRO91lISI4KdflLIAgB2O/hA= Date: Tue, 5 Nov 2019 23:19:32 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E709807E@marchand> References: <157127457937.7863.815173980398917672.idtracker@ietfa.amsl.com> <8262.1571345790@dooku.sandelman.ca> In-Reply-To: <8262.1571345790@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2019 23:20:05 -0000 SGkgTWljaGFlbCENCg0KUHJ1bmluZyB0aGUgdGhyZWFkIC4uLg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cgPGllc2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIE1pY2hhZWwgUmljaGFyZHNvbg0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNywg MjAxOSA0OjU3IFBNDQo+IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBDaHJpc3Rp YW4gSHVpdGVtYQ0KPiA8aHVpdGVtYUBodWl0ZW1hLm5ldD4NCj4gQ2M6IGRyYWZ0LWlldGYtYW5p bWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYUBpZXRmLm9yZzsgdHRlK2lldGZAY3MuZmF1LmRlOw0K PiBhbmltYS1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgYW5pbWFA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtBbmltYV0gUm9tYW4gRGFueWxpdydzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1hbmltYS0NCj4gYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0yODogKHdpdGgg RElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IA0KPiB7cGxlYXNlIGV4Y3VzZSBtZSBpZiB0aGlz IGlzIGEgcmVzZW5kfQ0KPiANCj4ge0FMU08gcmVzcG9uZGluZyB0byBDaHJpc3RpYW4ncyB0aGly ZCByZXZpZXcgY29tbWVudHMuDQo+ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv cmV2aWV3LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0NCj4gMjgtc2VjZGlyLXRl bGVjaGF0LWh1aXRlbWEtMjAxOS0xMC0xMi8gfQ0KPiANCj4gUm9tYW4gRGFueWxpdyB2aWEgRGF0 YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPiAgICAgPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ICAgICA+IERJU0NVU1M6DQo+ICAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmtzIGZvciB0 aGUgdXBkYXRlZCB0ZXh0IGluIC0yOS4gIEkndmUgY2xlYXJlZCB0aGUgRElTQ1VTUyBpbiB0aGUg dHJhY2tlci4NCg0KPiAgICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgICA+IENPTU1FTlQ6DQo+ICAg ICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmtzIGZvciBhZGRyZXNzaW5nIHRoZXNlIG90aGVyIGNv bW1lbnRzICh3aGljaCBJIGhhdmUgcmVtb3ZlZCBmcm9tIHRoZSB0aHJlYWQpLg0KDQo+ICAgICA+ ICoqIFNlY3Rpb24gMTAuMy4gIFBlciDigJxbdF1oZSBzby1jYWxsZWQgImNhbGwtaG9tZSIgbWVj aGFuaXNtIHRoYXQNCj4gICAgID4gb2NjdXJzIGFzIHBhcnQgb2YgdGhlIEJSU0tJLU1BU0EgY29u bmVjdGlvbiBzdGFuZGFyZGl6ZXMgd2hhdCBoYXMNCj4gYmVlbg0KPiAgICAgPiBkZWVtZWQgYnkg c29tZSBhcyBhIHNpbmlzdGVyIG1lY2hhbmlzbSBmb3IgY29ycG9yYXRlIG92ZXJzaWdodCBvZg0K PiAgICAgPiBpbmRpdmlkdWFscy4gKFtsaXZpbmd3aXRoSW9UXSBhbmQgW0lvVHN0cmFuZ2VUaGlu Z3NdIGZvciBhIHNtYWxsDQo+ICAgICA+IHNhbXBsZSku4oCdDQo+IA0KPiAgICAgPiAtLSBUaGFu a3MgZm9yIGluY2x1ZGluZyB0aGlzIHRleHQgYWJvdXQgdGhlIOKAnGNhbGwtaG9tZeKAnSBtZWNo YW5pc20uDQo+ICAgICA+IEhvd2V2ZXIgdGhlIHJlZmVyZW5jZXMgZG9u4oCZdCBzZWVtIGxpa2Ug YSBmaXQuICBCb3RoIHJlZmVyZW5jZXMgYXBwZWFyDQo+ICAgICA+IHRvIGZvY3VzIG9uIHRoZSBy ZWd1bGFyIOKAnGNhbGwgaG9tZeKAnSBhY3Rpdml0eSBvZiB0aGVzZSBkZXZpY2UgcmF0aGVyDQo+ ICAgICA+IHRoYW4gdGhlIG5hcnJvdywgb24tdGltZSBvbmUtdGltZSBvbmJvYXJkaW5nIHByb2Nl c3MuICBUaGUgbmF0dXJlIG9mDQo+ICAgICA+IHRoZSDigJxjYWxsLWhvbWXigJ0gaXNu4oCZdCBq dXN0IGFib3V0IHByaXZhY3kgKGFzIHRoZXNlIGFydGljbGVzIGltcGx5KSwgYnV0DQo+ICAgICA+ IGFsc28gbG9jay1pbi4NCj4gDQo+IFdoaWxlIEkgYWdyZWUgd2l0aCB5b3UsIHRoZSBkZXZpY2Vz IG1lbnRpb25lZCBpbiB0aGUgYWJvdmUgcmVmZXJlbmNlcyBkaWUgaWYNCj4gdGhleSBjYW4ndCBj YWxsIGhvbWUgQVQgQU5ZIFRJTUUuICBOb3QganVzdCBhdCBvbmJvYXJkaW5nLiAgIFNvLCB0aGUN Cj4gb3ZlcnNpZ2h0IHByZXNlbnQgaW4gQlJTS0kgaXMganVzdCBsZXNzIGVmZmVjdGl2ZSB0aGFu IG90aGVyIGRldmljZXMuDQoNCkknbSBub3QgZGlzcHV0aW5nIHRoZSBwaGVub21lbm9uIG9mIGRl dmljZXMgbm90IHdvcmtpbmcgaWYgdGhleSBhcmVuJ3QgY29ubmVjdGVkIHRvIHRoZSBuZXR3b3Jr LiAgSSdtIHN0cnVnZ2xpbmcgdG8gZmluZCB0aGF0IG1lc3NhZ2UgaW4gdGhlIHByb3ZpZGVkIHJl ZmVyZW5jZXMuDQoNCltsaXZpbmd3aXRoSW9UXQ0KaHR0cHM6Ly93d3cuc2lsaWNvbnJlcHVibGlj LmNvbS9tYWNoaW5lcy9pb3Qtc21hcnQtZGV2aWNlcy1yZWFsaXR5DQoNCltJb1RzdHJhbmdlVGhp bmdzXQ0KaHR0cHM6Ly93d3cud2VsaXZlc2VjdXJpdHkuY29tLzIwMTcvMDMvMDMvaW50ZXJuZXQt b2YtdGhpbmdzLXNlY3VyaXR5LXByaXZhY3ktaW90LXVwZGF0ZS8NCg0KVW5yZWxhdGVkLCB3aXRo IFtsaXZpbmd3aXRoSW9UXSwgZGlkIHlvdSByZWFsbHkgbWVhbiB0aGUgc2lsaWNvbnJlcHVibGlj IGNvbnRlbnQgb3IgdGhlIGxpbmsgdG8gdGhlIGdpem1vZG8gYXJ0aWNsZSBpdCBtYWtlcyB0bzoN Cg0KaHR0cHM6Ly9naXptb2RvLmNvbS90aGUtaG91c2UtdGhhdC1zcGllZC1vbi1tZS0xODIyNDI5 ODUyDQoNCj4gICAgID4gLS0gSXQgaXNuJ3QgYXBwcm9wcmlhdGUgdG8gY2hhcmFjdGVyaXplIGNv bmNlcm5zIGFib3V0IHRoZSBCUklTS0ktTUFTQQ0KPiAgICAgPiBsaW5rIGFzIOKAnHNpbmlzdGVy IG1lY2hhbmlzbXMgLi4u4oCdLg0KPiANCj4gRGlkIHlvdSByZWFkIHRoZSByZXZpZXcgY29tbWVu dHMgYmFjayBpbiBOb3ZlbWJlci9EZWNlbWJlciAyMDE4PyA6LSkgaWYNCj4geW91IGFyZSBhcmd1 aW5nIHRoYXQgSSdtIHVzaW5nIHRvbyBhbGFybWlzdCBsYW5ndWFnZSwgSSB3aWxsIGFjY2VwdCBz dWdnZXN0cyBmb3INCj4gbGVzcyBhbGFybWlzdCBsYW5ndWFnZS4NCg0KSSBkaWQgOy0pIEJ1dCBp dCBpc24ndCBjbGVhciB0byBtZSB0aGF0IGZ1dHVyZSByZWFkZXJzIHdpbGwgcmVtZW1iZXIgdGhp cyBkaXNjdXNzaW9uLiAgSSdkIGFkdm9jYXRlIGZvciBzdGFuZC1hbG9uZSBsYW5ndWFnZS4gVGhl IGxlc3MgYWxhcm1pc3QgdGV4dCBJIHdvdWxkIHByb3Bvc2UgaXM6IA0KDQpPTEQ6DQoNClRoZSBz by1jYWxsZWQgImNhbGwtaG9tZSIgbWVjaGFuaXNtIHRoYXQgb2NjdXJzIGFzIHBhcnQgb2YgdGhl IEJSU0tJLQ0KICAgTUFTQSBjb25uZWN0aW9uIHN0YW5kYXJkaXplcyB3aGF0IGhhcyBiZWVuIGRl ZW1lZCBieSBzb21lIGFzIGENCiAgIHNpbmlzdGVyIG1lY2hhbmlzbSBmb3IgY29ycG9yYXRlIG92 ZXJzaWdodCBvZiBpbmRpdmlkdWFscy4NCiAgIChbbGl2aW5nd2l0aElvVF0gYW5kIFtJb1RzdHJh bmdlVGhpbmdzXSBmb3IgYSBzbWFsbCBzYW1wbGUpLg0KDQogICBBcyB0aGUgQXV0b25vbWljIENv bnRyb2wgUGxhbmUgKEFDUCkgdXNhZ2Ugb2YgQlJTS0kgaXMgbm90IHRhcmdldGVkDQogICBhdCBp bmRpdmlkdWFsIHVzYWdlIG9mIElvVCBkZXZpY2VzLCBidXQgcmF0aGVyIGF0IHRoZSBFbnRlcnBy aXNlIGFuZA0KICAgSVNQIGNyZWF0aW9uIG9mIG5ldHdvcmtzIGluIGEgemVyby10b3VjaCBmYXNo aW9uLCB0aGUgImNhbGwtaG9tZSINCiAgIHJlcHJlc2VudHMgYSBkaWZmZXJlbnQga2luZCBvZiBj b25jZXJuLg0KDQpORVc6DQoNCldpdGggY29uc3VtZXItb3JpZW50ZWQgZGV2aWNlcywgdGhlICJj YWxsLWhvbWUiIG1lY2hhbmlzbSBpbiBJb1QgZGV2aWNlcyByYWlzZXMgc2lnbmlmaWNhbnQgcHJp dmFjeSBjb25jZXJucy4gIFNlZSBbbGl2aW5nd2l0aElvVF0gYW5kIFtJb1RzdHJhbmdlVGhpbmdz XSBmb3IgZXhlbXBsYXJzLiAgVGhlIEF1dG9ub21pYyBDb250cm9sIFBsYW5lIChBQ1ApIHVzYWdl IG9mIEJSU0tJIGlzIG5vdCB0YXJnZXRlZCBhdCBpbmRpdmlkdWFsIHVzYWdlIG9mIElvVCBkZXZp Y2VzLCBidXQgcmF0aGVyIGF0IHRoZSBFbnRlcnByaXNlIGFuZCBJU1AgY3JlYXRpb24gb2YgbmV0 d29ya3MgaW4gYSB6ZXJvLXRvdWNoIGZhc2hpb24gd2hlcmUgdGhlICJjYWxsLWhvbWUiIHJlcHJl c2VudHMgYSBkaWZmZXJlbnQgY2xhc3Mgb2YgcHJpdmFjeSBhbmQgbGlmZWN5Y2xlIG1hbmFnZW1l bnQgY29uY2VybnMuIA0KDQo+ICAgICA+ICoqIFNlY3Rpb24gMTAuNy4gIFBlciDigJxJdCBpcyBh bnRpY2lwYXRlZCB0aGF0IHNwZWNpYWxpc3Qgc2VydmljZQ0KPiAgICAgPiBwcm92aWRlcnMgd2ls bCBjb21lIHRvIGV4aXN0IHRoYXQgZGVhbCB3aXRoIHRoZSBjcmVhdGlvbiBvZiB2b3VjaGVycyBp bg0KPiAgICAgPiBtdWNoIHRoZSBzYW1lIHdheSB0aGF0IG1hbnkgY29tcGFuaWVzIGhhdmUgb3V0 c291cmNlZCBlbWFpbCwNCj4gICAgID4gYWR2ZXJ0aXNpbmcgYW5kIGphbml0b3JpYWwgc2Vydmlj ZXMu4oCdLCBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBhIGZhaXINCj4gICAgID4gYW5hbG9neS4g IERlbGVnYXRpbmcgdGhlIHZvdWNoZXIgcHJvY2VzcyB0byBhbiBlbnRpdHkgd291bGQgdGFrZSBh Y3RpdmUNCj4gICAgID4gY29vcGVyYXRpb24gb2YgdGhlIG1hbnVmYWN0dXJlci4gIElmIHRoZSBt YW51ZmFjdHVyZSBpcyBvdXQgb2YNCj4gICAgID4gYnVzaW5lc3MsIHRoZXJlIGlzIG5vdCBndWFy YW50ZWUgdGhpcyB3b3VsZCBoYXZlIGJlZW4gcHV0IGluIHBsYWNlIChvcg0KPiAgICAgPiB0aG9z ZSBhc3NldHMgd2VyZSBhY3F1aXJlZCBpbiB0aGUgbGlxdWlkYXRpb24pDQo+IA0KPiBSZWNlbnQg Y2hhbmdlcyByZW1pbmQgdGhhdCB0aGUgbWFudWZhY3R1cmVyIG5lZWRzIHRvIGVzY3JvdyB0aGVp ciBrZXlzLg0KPiBJZiB0aGUgbWFudWZhY3R1cmVyIGlzIG91dCBvZiBidXNpbmVzcywgdGhlbiB3 aGVyZSB3aWxsIHlvdSBnZXQgc2VjdXJpdHkNCj4gdXBkYXRlcyBmcm9tPyAgRG8geW91IHdhbnQg dG8gZW5hYmxlIGEgc2Vjb25kYXJ5IG1hcmtldCBmb3IgZGV2aWNlcyB3aXRoDQo+IGRlY2FkZSBv bGQgc2VjdXJpdHkgaG9sZXM/DQoNCkknbSBxdWVzdGlvbmluZyB0aGUgYW5hbG9neSB0byBhZHZl cnRpc2luZyBvciBqYW5pdG9yaWFsIHNlcnZpY2VzLiAgVG8gbWUsIGJvdGggb2YgdGhlc2UgZXhh bXBsZXMgYXJlIGluc3RhbmNlcyBvZiBhIHNlcnZpY2UgYmVpbmcgcHJvdmlkZWQgdG8gdGhlIGV4 aXN0aW5nIGNvbXBhbnkgcmF0aGVyIHRoYW4gZGVtb25zdHJhdGluZyBob3cgYXNzZXQgaGFuZC1v ZmYgb3IgY29udGludWVkIG1haW50ZW5hbmNlIHdvdWxkIG9jY3VyIGluIHRoZSBjYXNlIG9mIGJh bmtydXB0Y3kvbGlxdWlkYXRpb24uDQogDQo+ICAgICA+ICoqIFNlY3Rpb24gMTEuNS4yLjIgcHJl c2NyaWJlcyB0aGF0IHRoZSBvcGVyYXRvciBvZiBhIE1BU0Eg4oCcTVVTVCBpc3N1ZQ0KPiAgICAg PiBhIGZpcm13YXJlIHVwZGF0ZSB0byBhbGwgZGV2aWNlcyB0aGF0IGhhZCB0aGF0IGtleSBhcyBh IHRydXN0IGFuY2hvcuKAnS4NCj4gICAgID4gVGhpcyBzdWdnZXN0cyBhIHJlcXVpcmVkIGNhcGFi aWxpdHkgdG8gdXBkYXRlIHRydXN0IGFuY2hvcnMuICBIb3dldmVyLA0KPiAgICAgPiBTZWN0aW9u IDcuNC4zIGRpc2N1c3NlcyBhIHNpbWlsYXIgKGFsYmVpdCBtb3JlIGZsZXhpYmxlKSBwcmFjdGlj ZSBidXQNCj4gICAgID4gdGhpcyBpcyBub24tbm9ybWF0aXZlIGFuZCBkZWVtZWQgcmVkdWNlZCBz ZWN1cml0eS4gIFdoeSB0aGUNCj4gZGlzc2lkZW5jZT8NCj4gDQo+IElmIHlvdSBsb3NlIHlvdXIg a2V5LCB5b3UnbGwgaGF2ZSB0byB1cGRhdGUgdGhlIGZpcm13YXJlIHRvIHVwZGF0ZSB0aGUNCj4g YW5jaG9ycy4NCj4gSWYgeW91IGhhdmUgaW1wbGVtZW50ZWQgNy40LjMsIHRoZW4gaXQgbWlnaHQg YmUgdGhhdCB5b3UgY2FuIGRvIGxlc3MuDQo+IEhvd2V2ZXIsIGluIG9uZSB2ZXJzaW9uIG9mIDcu NC4zLCBhIGZhY3RvcnkgcmVzZXQgbWlnaHQgcmVzdG9yZSB0aGUgb3JpZ2luYWwNCj4gKGxvc3Qp IGtleXMsIHdoaWNoIGlzIHdoeSBhIGZpcm13YXJlIHVwZGF0ZSB3b3VsZCBpbiBnZW5lcmFsIGJl IG5lZWRlZC4NCg0KR290IGl0LiAgVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NClRoYW5r cy4NCg0KUmVnYXJkcywNClJvbWFuDQogDQo= From nobody Thu Nov 7 03:48:04 2019 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 5A929120125; Thu, 7 Nov 2019 03:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CwtvNwRI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=raC6rX7G 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 LYRddefMC6iS; Thu, 7 Nov 2019 03:48:01 -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 3B05D120096; Thu, 7 Nov 2019 03:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15867; q=dns/txt; s=iport; t=1573127281; x=1574336881; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o8cJG9ZtrPHZqwcULdLkh1YUz1AfPdaGDUvtp0WgMTA=; b=CwtvNwRINxoIRjcrGqj1XfcLD5Kv6Jj5q0UATZZaGihUvvXrCWt1tWhK ww0D0ryEmI2bohaLZOS9ejiikiBWLIAc1ZhtKziQUDxoI1pZOijZR4D2A SLRmRSPudpZRbzLASKRcNJXGQIeSXrYSXunhDvQTmu8e4AiL3r2xJ0B3Q Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A695uohJDhW503I6sxNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCtKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEr1Nv/nawQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAAAkA8Rd/5JdJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBagYBAQELAYEbLyknBWxYIAQLKodvA4RahiaCXpd+gS4?= =?us-ascii?q?UgRADVAkBAQEMAQEjCgIBAYRAAoQOJDQJDgIDCwEBBAEBAQIBBQRthTcMhVE?= =?us-ascii?q?BAQEBAxILEBMBATcBDwIBCBEEAQEoBzIUCQgBAQQBDQUIGoMBgXlNAy4BAgy?= =?us-ascii?q?oDAKBOIhggieCfgEBBYE0AYNVGIIXCYE2AYwTGIFAP4ERRoJMPoEEgV4CAoE?= =?us-ascii?q?sARECASArCQiDBIIsjQ6IOCSYHgqCJIcXjkWCPHKGbo9WhDqKDIgxkTkCBAI?= =?us-ascii?q?EBQIOAQEFgVI5Z3FwFTuCOAEzCUcRFJA2gScBB4JEhRSFPgF0AYEnkAEBAQ?= X-IronPort-AV: E=Sophos;i="5.68,278,1569283200"; d="scan'208,217";a="436307279" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Nov 2019 11:47:59 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id xA7Blxce007795 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2019 11:47:59 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 05:47:59 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 05:47:57 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 7 Nov 2019 06:47:57 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ke3YtcmOwVzlyzaYprdSreRf/YzfzGs+HrFG7df/d2pHLq1zCfsspnd1kZ9IXCR8Ak40QEDHtn7c6D7+hTVbPTMBvSQPtGXZrwuL3AIdwwk9Xnx3I0c6hTNstDbeJE/z6uq89Q+qPuwK8iDMADUKShFJHyzNT7MjAw31RVl+T5aE+ftjftLmrCXVx2wkHXDFdL3yi5gOjC/Tlucf8+ZWcI2ueWpIXdGTEJV8VGXqUNIKpuoeUUqbzp9Aw3fCve3uActVB8a7YCDqxg4gSBMb+jbOSqY5aawKBhxKVfRpfIzO/rwMchqGB+uE9Yxan3nC9nzUAHkYpoqvQbhYlTfzgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ifHBRaBJYmZp5IME5QPr8RPapCO72PdSUYSmn5XPaF0=; b=W37cadS25lAOGObEDS6Awh5lyuf1k472aVbZrUoHs7usn6LyzOJ98jlkHuykXpoSn4A3ny8RwFd8segD5SCpKzwALHXrNQ1+QxOUjBnUI7to15M9wOjg8MrezhYYeefWfncxJI60oOly8ZpDZS7kAf0hJiA/zwGAvc+rWLmy63DjLfLKKMFvhFRmAaiX9Uz9GI1Hl9diZX5wDATGc6uoWOD/TAFZnq3/A9gDeKvRqj5iMLhXq3/8KRbO7evUwcedSm/pCq190BJCFOv9lEJSFBuFnZOG71TvofpZlW2jvc17ohHmmU3PCO0OBShzxmFZf3dshchcpWzBD2USIvANNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ifHBRaBJYmZp5IME5QPr8RPapCO72PdSUYSmn5XPaF0=; b=raC6rX7GWvd/k6U3WPzv2MP0olVEbunriCaZjUBuWl423MtyJHPj8s6u+9cSF2ftn6G+abWsnZYsLj6xmov4mdV1hP9JNJT7B78EdVzBKOuLAUf+165xAYuqOVxSX/e3nUyyMRg/+XcONxPEQjbcKGY9kfhdnW9wPUCSiXGna7A= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3696.namprd11.prod.outlook.com (20.178.253.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Thu, 7 Nov 2019 11:47:56 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2430.023; Thu, 7 Nov 2019 11:47:55 +0000 From: "Owen Friel (ofriel)" To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 106, Singapore Thread-Index: AdV9jBLkoEaxILscRaKWE42MKoRSFwX1IQvQ Date: Thu, 7 Nov 2019 11:47:55 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> 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=ofriel@cisco.com; x-originating-ip: [2001:420:4041:1300:6d98:e3fd:9fdd:799e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b2b4c2d-226e-4354-b63b-08d76378546a x-ms-traffictypediagnostic: MN2PR11MB3696: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(376002)(346002)(396003)(199004)(189003)(52536014)(66446008)(66476007)(966005)(2501003)(110136005)(66556008)(6246003)(66946007)(4326008)(6116002)(33656002)(2906002)(606006)(76176011)(53546011)(229853002)(316002)(76116006)(102836004)(54896002)(790700001)(6306002)(5660300002)(7696005)(9686003)(55016002)(236005)(8676002)(6436002)(14454004)(64756008)(186003)(256004)(14444005)(71190400001)(476003)(8936002)(478600001)(11346002)(9326002)(486006)(25786009)(86362001)(81156014)(446003)(81166006)(7736002)(46003)(71200400001)(99286004)(74316002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3696; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f7Pn5vMUZwr2j2JAITAJRDaQ0J5lJ8W+ptS4vT78Gr2sNPXgJXrlhy8NVB6cebQotVqV18X6OVfMTsBUA7RvGeUvRA7eQciswScDpOitJDNVLuvPGVzAO53czOtDuaV3TpOJdjY2ghQQ47FuVVhEle7QmGnXf0DJSGueuyAQHt0yYDlCXinEbC6fDkc7XgAZvUuwhYHXlGqxW5mlUje4xEL+nYSdYYQZ3mzYxds0wO3HB9MLGLMp0a+rGphn6NbZbufl4m9kI/7ORXEpNow5tLx9g8pzAi6Srk8j1Ap7JK1cGZnWGlfzBXz7vX6S+87JdH19FcMylLnDu/OGe3pcgc3WgSYxM05saWjW+mH922eEFrsOPniUFyw2IMtNNuqQg8YTZBjDJ1NBhh9YL2UWouePATn/RmH2NIxBGN47l8A/pyXaxsFa//u5pl4heMypq0PgUpA8Y58I4mm13SJbv9MYFqC9PtQJ+vVogJHrPqA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3901DD8CF27429ECAF1AA874DB780MN2PR11MB3901namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0b2b4c2d-226e-4354-b63b-08d76378546a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 11:47:55.7850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ImhoVQEtw18BBeqEHOHdHIqEB3TwWJaE4kjwTE99b6ye2H6+ry/L5rCrz+/W8pJB8LqRBmmvH0/jpQkCrenrdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3696 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2019 11:48:04 -0000 --_000_MN2PR11MB3901DD8CF27429ECAF1AA874DB780MN2PR11MB3901namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sheng, Could I request 2 slots: Slot 1: Name: BRSKI Cloud Registrar Draft: draft-friel-anima-brski-cloud Time: 15 mins Presenters: Owen Friel / Michael Richardson Slot 2: Name: ACME Integrations Drafts: draft-friel-acme-integrations, draft-friel-acme-subdomains Time: 10 mins Presenter: Owen Friel Thanks, Owen From: Anima On Behalf Of Sheng Jiang Sent: 08 October 2019 04:56 To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore Hi, all anima, We have been allocated two sessions of 1.5 + 1 hour for the ANIMA WG meetin= g for IETF-106 (Singapore). We are now starting to collect agenda items for= the sessions. Please send your request for agenda by October 31th, Thursda= y, to anima-chairs@ietf.org> and both chairs' email. Please = note that email to a single chair may cause single-point failure. 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. As you may observed, we now have the new WG charter in the place, but still= , we have the priority to complete the current WG documents over to adopt a= ny new work. Please send us (anima-chairs at ietf.org) requests for time slot by October 31th, Thursday and inc= lude: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 106, Montreal can be found at: https://www.ietf.org/how/meetings/106/ 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, Sheng --_000_MN2PR11MB3901DD8CF27429ECAF1AA874DB780MN2PR11MB3901namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sheng,

 

Could I request 2 slots:

 

Slot 1:

 

Name: BRSKI Cloud Registrar

Draft: draft-friel-anima-brski-cloud

Time: 15 mins

Presenters: Owen Friel / Michael Richardson

 

Slot 2:

 

Name: ACME Integrations

Drafts: draft-friel-acme-integrations, draft-friel-ac= me-subdomains

Time: 10 mins

Presenter: Owen Friel

 

Thanks,

Owen

 

 

 

 

From:= Anima <anima-bounces@ie= tf.org> On Behalf Of Sheng Jiang
Sent: 08 October 2019 04:56
To: anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore

 

Hi, all anima,
 
We have been allocated two sessions of 1.5 + 1 hour for the A=
NIMA WG meeting for IETF-106 (Singapore). We are now starting to collect ag=
enda items for the sessions. Please send your request for agenda by October=
 31th, Thursday, to anima-chairs@ietf.org<mailto:anima-chairs@ietf.org&=
gt; and both chairs' email. Please note that email to a single chair may ca=
use single-point failure.
 
As normal, the priority among these non-charter work items would =
be: these that have active discussion in mail list, then these have submitt=
ed drafts, and topics without drafts.
 
As you may observed, we now have the new WG charter in the place,=
 but still, we have the priority to complete the current WG documents over =
to adopt any new work.
 
Please send us (anima-chairs at ietf.org<https://ietf.=
org/><http://ietf.org%3Chttps/ietf.org/)>) requests for time s=
lot by October 31th, Thursday and include:
 
Name of time slot:
Name of draft(s):
Time requested:
Presenter name(s):
 
More details about the IETF 106, Montreal can be found at:
 
https://www.ie=
tf.org/how/meetings/106/
 
Again, presenters and draft authors please invoke active discussi=
ons in the ANIMA list. Mail list is a very good place to discuss and reach =
consensus on technical issues.
 
Best regards,
 
Sheng

 

--_000_MN2PR11MB3901DD8CF27429ECAF1AA874DB780MN2PR11MB3901namp_-- From nobody Fri Nov 8 01:59:39 2019 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 A8EF2120893; Fri, 8 Nov 2019 01:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 sNvClQWr1aOy; Fri, 8 Nov 2019 01:59:35 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B869612088F; Fri, 8 Nov 2019 01:59:34 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 376945B5E0BFFC988750; Fri, 8 Nov 2019 09:59:31 +0000 (GMT) Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Nov 2019 09:59:30 +0000 Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 8 Nov 2019 09:59:30 +0000 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 8 Nov 2019 09:59:30 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Fri, 8 Nov 2019 17:59:22 +0800 From: Sheng Jiang To: "Owen Friel (ofriel)" , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 106, Singapore Thread-Index: AdV9jBLkoEaxILscRaKWE42MKoRSFwX1IQvQAC6fmfA= Date: Fri, 8 Nov 2019 09:59:22 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299C12449@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> In-Reply-To: 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_5D36713D8A4E7348A7E10DF7437A4B9299C12449NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2019 09:59:38 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9299C12449NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Own, Thanks for your emails. Your application for time slot are noted. The chair= s will allocate time according to the overall received applications. The ag= enda will be settle down soon. Best regards, Sheng From: Owen Friel (ofriel) [mailto:ofriel@cisco.com] Sent: Thursday, November 07, 2019 7:48 PM To: Sheng Jiang ; anima@ietf.org Cc: anima-chairs@ietf.org Subject: RE: Call for agenda ANIMA @ IETF 106, Singapore Hi Sheng, Could I request 2 slots: Slot 1: Name: BRSKI Cloud Registrar Draft: draft-friel-anima-brski-cloud Time: 15 mins Presenters: Owen Friel / Michael Richardson Slot 2: Name: ACME Integrations Drafts: draft-friel-acme-integrations, draft-friel-acme-subdomains Time: 10 mins Presenter: Owen Friel Thanks, Owen From: Anima > On Beha= lf Of Sheng Jiang Sent: 08 October 2019 04:56 To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore Hi, all anima, We have been allocated two sessions of 1.5 + 1 hour for the ANIMA WG meetin= g for IETF-106 (Singapore). We are now starting to collect agenda items for= the sessions. Please send your request for agenda by October 31th, Thursda= y, to anima-chairs@ietf.org> and both chairs' email. Please = note that email to a single chair may cause single-point failure. 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. As you may observed, we now have the new WG charter in the place, but still= , we have the priority to complete the current WG documents over to adopt a= ny new work. Please send us (anima-chairs at ietf.org) requests for time slot by October 31th, Thursday and inc= lude: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 106, Montreal can be found at: https://www.ietf.org/how/meetings/106/ 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, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B9299C12449NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Own,

 

Thanks for your emails. Your= application for time slot are noted. The chairs will allocate time accordi= ng to the overall received applications. The agenda will be settle down soo= n.

 

Best regards,

 

Sheng

&n= bsp;

&n= bsp;

From: Owen Friel (ofriel) [mailto:ofriel@cisco.com]
Sent: Thursday, November 07, 2019 7:48 PM
To: Sheng Jiang <jiangsheng@huawei.com>; anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: RE: Call for agenda ANIMA @ IETF 106, Singapore<= /span>

 

Hi Sheng,

 

Could I request 2 slots:

 

Slot 1:

 

Name: BRSKI Cloud Registrar=

Draft: draft-friel-anima-brski-cloud

Time: 15 mins

Presenters: Owen Friel / Michael Richa= rdson

 

Slot 2:

 

Name: ACME Integrations

Drafts: draft-friel-acme-integrations,= draft-friel-acme-subdomains

Time: 10 mins

Presenter: Owen Friel

 

Thanks,

Owen

 

 

 

 

 

Hi, all anima,
 =

We have been allo=
cated two sessions of 1.5 + 1 hour for the ANIMA WG meeting for IETF-10=
6 (Singapore). We are now starting to collect agenda items for the sessions=
. Please send your request for agenda by October 31th, Thursday, to anima-chai=
rs@ietf.org<mailto:anima-chairs@ietf.org> and both chairs' email.=
 Please note that email to a single chair may cause single-point failure.
 =

As normal, the pr=
iority among these non-charter work items would be: these that have active =
discussion in mail list, then these have submitted drafts, and topics witho=
ut drafts.
 =

As you may observ=
ed, we now have the new WG charter in the place, but still, we have the pri=
ority to complete the current WG documents over to adopt any new work.=

 =

Please send us (a=
nima-chairs at ietf.org<https://ietf.org/><http://ietf.org=
%3Chttps/ietf.org/)>) requests for time slot by October 31th, Thursd=
ay and include:
 =

Name of time slot=
:
Name of draft(s):=

Time requested:
Presenter name(s)=
:
 =

More details abou=
t the IETF 106, Montreal can be found at:
 =

https://www.ietf.org/how/meetings/106/
 =

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 issu=
es.
 =

Best regards,
 =

Sheng<=
/span>

 

--_000_5D36713D8A4E7348A7E10DF7437A4B9299C12449NKGEML515MBXchi_-- From nobody Fri Nov 8 03:39:28 2019 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 729D412004F; Fri, 8 Nov 2019 03:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 yXoId_gv1qEe; Fri, 8 Nov 2019 03:39:24 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 39AD9120041; Fri, 8 Nov 2019 03:39:24 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 10D608808359CA0FF024; Fri, 8 Nov 2019 11:39:19 +0000 (GMT) Received: from lhreml717-chm.china.huawei.com (10.201.108.68) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Nov 2019 11:39:18 +0000 Received: from lhreml717-chm.china.huawei.com (10.201.108.68) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 8 Nov 2019 11:39:18 +0000 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 8 Nov 2019 11:39:18 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Fri, 8 Nov 2019 19:39:11 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: Brian Carpenter , Michael Richardson , "anima-chairs@ietf.org" Thread-Topic: Primary ANIMA agenda for IETF 106 Thread-Index: AdWWKDPIkV1qB0a3S/i+jv2t4J/6ng== Date: Fri, 8 Nov 2019 11:39:10 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299C124C7@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_5D36713D8A4E7348A7E10DF7437A4B9299C124C7NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Primary ANIMA agenda for IETF 106 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2019 11:39:27 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9299C124C7NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, ANIMA, The below is the link to our primary ANIMA agenda. It is a subject to be ch= anged. https://datatracker.ietf.org/meeting/106/materials/agenda-106-anima Please no hesitate to contact the chair for any miss or mistake. Speakers, please send your slides to chairs by Sunday, November 17th, 2019.= Thanks. Brian, in your previous email, you mentioned a topic anima ecosystem, but d= id not explicitly apply a time slot. I have allocated it together with your= ASA guideline topic. Let me know, if you have different opinion. Michael, in your previous email, you mentioned a newly coming topic delegat= ed-voucher, but neither explicitly apply a time slot or submit a new draft.= Since we still have 15 minutes spare time in BRASK session. If you want to= present this topic, I can put it at the end as the last backup topic. Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B9299C124C7NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, ANIMA,
 
The below is the link to our primary=
 ANIMA agenda. It is a subject to be changed.
 
https://datatracker.ietf.org/me=
eting/106/materials/agenda-106-anima
 
Please no hesitate to contact the ch=
air for any miss or mistake.
 
Speakers, please send your slides to=
 chairs by Sunday, November 17th, 2019. Thanks.
 
Brian, in your previous email, you m=
entioned a topic anima ecosystem, but did not explicitly apply a time slot.=
 I have allocated it together with your ASA guideline topic. Let me know, i=
f you have different opinion.
 
Michael, in your previous email, you=
 mentioned a newly coming topic delegated-voucher, but neither explicitly a=
pply a time slot or submit a new draft. Since we still have 15 minutes spar=
e time in BRASK session. If you want to present this topic, I can put it at=
 the end as the last backup topic.
 
Regards,
 
Sheng
--_000_5D36713D8A4E7348A7E10DF7437A4B9299C124C7NKGEML515MBXchi_-- From nobody Fri Nov 8 05:54:53 2019 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 967041201E0; Fri, 8 Nov 2019 05:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 w6uY_aHz4ErI; Fri, 8 Nov 2019 05:54:49 -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 166AB12003F; Fri, 8 Nov 2019 05:54:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9CB353897B; Fri, 8 Nov 2019 08:51:47 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CC8445E4; Fri, 8 Nov 2019 08:54:45 -0500 (EST) From: Michael Richardson To: Sheng Jiang cc: "anima\@ietf.org" , Brian Carpenter , "anima-chairs\@ietf.org" In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299C124C7@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9299C124C7@NKGEML515-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] Primary ANIMA agenda for IETF 106 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2019 13:54:52 -0000 --=-=-= Content-Type: text/plain Sheng Jiang wrote: > The below is the link to our primary ANIMA agenda. It is a subject to be changed. > https://datatracker.ietf.org/meeting/106/materials/agenda-106-anima > Please no hesitate to contact the chair for any miss or mistake. > Speakers, please send your slides to chairs by Sunday, November 17th, > 2019. Thanks. > Brian, in your previous email, you mentioned a topic anima ecosystem, > but did not explicitly apply a time slot. I have allocated it together > with your ASA guideline topic. Let me know, if you have different > opinion. > Michael, in your previous email, you mentioned a newly coming topic > delegated-voucher, but neither explicitly apply a time slot or submit a > new draft. Since we still have 15 minutes spare time in BRASK > session. If you want to present this topic, I can put it at the end as > the last backup topic. Thank you, that is appreciated. I did not have time to finish that document before the cut-off date. I do have requirements from a number of industrial players, as well as a very loud desire from the IESG to solve the second-sale problem. So I could do three slides on possible ways to solve this problem, posting a document on Monday. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3Fc6UACgkQgItw+93Q 3WUScQgAq1fspqeTYCjQqImTDiglmCT3Ch0HD0V4uAuzKX7QEqSNAYnakNfDiRp8 Sa32v22PBGRzLm4kfityLIN6ugl6vAaWLobz0kAgkmnmqHwKFGMyQbxGSGoJIxW/ DNikHvKN5tbrotRkjTKEw5uJySF1FCM3VHFpWi/UpnHRUxo8IGvzDt+rK+PuAV5k wPfnuHWsw73Ix/5V13cAUTYmVHNQR22k/yqZ3b2e/h6XLuyIUTXbgaip3uo1YV7N aohHnd/h/AF2QkJdjAJdXz6gAPNQDeJcaEfBOJe0M/6nXuXpn2QlKunTdjgrLd3Q WQep9F5nio+fn66lZIeEHZ9Ppx6/RA== =J6aB -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 8 11:01:30 2019 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 30CA012094A; Fri, 8 Nov 2019 11:01:28 -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_HELO_NONE=0.001, 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 U2t2BpbKCP-E; Fri, 8 Nov 2019 11:01:26 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 94CB6120B98; Fri, 8 Nov 2019 11:01:18 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id f19so4501367pgk.11; Fri, 08 Nov 2019 11:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FmDnb7SHQRxZQXWYOmOwWL5xXRvNf/Lg2bFH2eIXcDM=; b=KCtysgESEntTpXg5OYtiET88EQRNNgDdHnaNvwUFTuGp7lLbtvNNp1gwscN8rqO+ZE ZcEv5lh4ExdbCQv1TSjhPxNWxU4V0TKtBREgwWLSsDnhKokXoETYhFF2prpwOjlhBL6I mR2sT5e5q2H8Oj3397zaAW8zFDAuZG93/xKJqdAh0OTVg3G5Z0/BX1s8Rwz0ZgyS0gOW 42XnrbgSX3O7A+057t8ZRWvr7+UxuEI1Nwwo0LTUuzhEASLwcmx/zZR3NIAy8EZFk0ri S9w/JOgKXHZoAIEFha+lmrrvSVjxSiyqv9JmPWsecSPCVTBuxyScBBDnW38BQKSKMSCZ UpDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FmDnb7SHQRxZQXWYOmOwWL5xXRvNf/Lg2bFH2eIXcDM=; b=S7zgqkJt9X6uML9ZXGxpKF/dln/HdzCavfVHrJO13QtQ/8OnRogQvkWoQND3ot6c98 H19v8EUF3mPhNXAq4bJNnlqhyVstYkWcUy6Kt4H8BruonWi2CME7I+Q4fTZ42dqdaJiD eesvPxpdcLj+yL79zUhg6XGQRFQ7a3YTqgoEvJY7g+2OYtBhw8IYr1JIUJELFG+caA7a k2RY1mgq+Zj49eLSXo2VWqUn0QONzEGJJIphq77UHqEJl2683MfWyIKi9jEuDKKdPb/r NpqXTchQEayR8QzhCRYKTHmGVUvzdzBaP21r77nN11zDKlwE7VGK0BGvjFrIam+NWufR H8Pg== X-Gm-Message-State: APjAAAVUiKMXATd3BBA3KeLfmctmSSvz+6mKeIo7Z35P15C6w4U+KmpZ b/D/1qR1ZC7TiFCYHZALr4ZoKjc6 X-Google-Smtp-Source: APXvYqz4GyXyw0pnkfCiwfhlbt743vDNPmSrlAKkgDSH/QXKJN0hQCSECPX1LOwHb/0K2ad16PngNQ== X-Received: by 2002:a63:7c03:: with SMTP id x3mr13992641pgc.382.1573239676770; Fri, 08 Nov 2019 11:01:16 -0800 (PST) Received: from [192.168.178.30] (8.166.69.111.dynamic.snap.net.nz. [111.69.166.8]) by smtp.gmail.com with ESMTPSA id j10sm6932675pfn.128.2019.11.08.11.01.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Nov 2019 11:01:16 -0800 (PST) To: Sheng Jiang , "anima@ietf.org" Cc: Michael Richardson , "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B9299C124C7@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Message-ID: <719f66f7-ffe1-df6f-d2aa-34d039f22133@gmail.com> Date: Sat, 9 Nov 2019 08:01:12 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299C124C7@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Primary ANIMA agenda for IETF 106 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2019 19:01:28 -0000 > Brian, in your previous email, you mentioned a topic anima ecosystem, b= ut did not explicitly apply a time slot. I have allocated it together wit= h your ASA guideline topic. Let me know, if you have different opinion. No, that's perfect. In fact there is not much new to say about the asa-gu= idelines draft. It might be a good idea to swap items 6 and 7, so that La= urent can speak right after me, since it is somewhat related: > 7. Introduce of ETSI ZSM on closed loops - 10 min > 18:30 - 18:40, By Laurent CiavagliaOne of my questions to the WG will b= e "What ecosystem issues are out of scope for the IETF?" Thanks Brian On 09-Nov-19 00:39, Sheng Jiang wrote: > Hi, ANIMA, >=20 > =C2=A0 >=20 > The below is the link to our primary ANIMA agenda. It is a subject to b= e changed. >=20 > =C2=A0 >=20 > https://datatracker.ietf.org/meeting/106/materials/agenda-106-anima >=20 > =C2=A0 >=20 > Please no hesitate to contact the chair for any miss or mistake. >=20 > =C2=A0 >=20 > Speakers, please send your slides to chairs by Sunday, November 17th, 2= 019. Thanks. >=20 > =C2=A0 >=20 > Brian, in your previous email, you mentioned a topic anima ecosystem, b= ut did not explicitly apply a time slot. I have allocated it together wit= h your ASA guideline topic. Let me know, if you have different opinion. >=20 > =C2=A0 >=20 > Michael, in your previous email, you mentioned a newly coming topic del= egated-voucher, but neither explicitly apply a time slot or submit a new = draft. Since we still have 15 minutes spare time in BRASK session. If you= want to present this topic, I can put it at the end as the last backup t= opic. >=20 > =C2=A0 >=20 > Regards, >=20 > =C2=A0 >=20 > Sheng >=20 From nobody Sun Nov 10 06:24:50 2019 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 2CE9E1200B2; Sun, 10 Nov 2019 06:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 HIUTR1ijYHyL; Sun, 10 Nov 2019 06:24:47 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 017C212004A; Sun, 10 Nov 2019 06:24:47 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 744257D2A4B504B24408; Sun, 10 Nov 2019 14:24:44 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 10 Nov 2019 14:24:43 +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.0439.000; Sun, 10 Nov 2019 22:24:33 +0800 From: Sheng Jiang To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" , Michael Richardson Thread-Topic: Primary ANIMA agenda for IETF 106 Thread-Index: AdWWKDPIkV1qB0a3S/i+jv2t4J/6ngBqtAfg Date: Sun, 10 Nov 2019 14:24:33 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299C28BA3@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9299C124C7@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299C124C7@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.45.26.40] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9299C28BA3NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Primary ANIMA agenda for IETF 106 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2019 14:24:49 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9299C28BA3NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updated according to the feedback from Brian & Michael. Sheng From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Friday, November 8, 2019 7:39 PM To: anima@ietf.org Cc: anima-chairs@ietf.org; Michael Richardson Subject: [Anima] Primary ANIMA agenda for IETF 106 Hi, ANIMA, The below is the link to our primary ANIMA agenda. It is a subject to be ch= anged. https://datatracker.ietf.org/meeting/106/materials/agenda-106-anima Please no hesitate to contact the chair for any miss or mistake. Speakers, please send your slides to chairs by Sunday, November 17th, 2019.= Thanks. Brian, in your previous email, you mentioned a topic anima ecosystem, but d= id not explicitly apply a time slot. I have allocated it together with your= ASA guideline topic. Let me know, if you have different opinion. Michael, in your previous email, you mentioned a newly coming topic delegat= ed-voucher, but neither explicitly apply a time slot or submit a new draft.= Since we still have 15 minutes spare time in BRASK session. If you want to= present this topic, I can put it at the end as the last backup topic. Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B9299C28BA3NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Updated= according to the feedback from Brian & Michael.

&n= bsp;

Sheng

 

From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Friday, November 8, 2019 7:39 PM
To: anima@ietf.org
Cc: anima-chairs@ietf.org; Michael Richardson <mcr@sandelman.ca&g= t;
Subject: [Anima] Primary ANIMA agenda for IETF 106=

 

Hi, ANIMA,
 
The below is the link to our primary=
 ANIMA agenda. It is a subject to be changed.
 
https://datatracker.ietf.org/me=
eting/106/materials/agenda-106-anima
 
Please no hesitate to contact the ch=
air for any miss or mistake.
 
Speakers, please send your slides to=
 chairs by Sunday, November 17th, 2019. Thanks.
 
Brian, in your previous email, you m=
entioned a topic anima ecosystem, but did not explicitly apply a time slot.=
 I have allocated it together with your ASA guideline topic. Let me know, i=
f you have different opinion.
 
Michael, in your previous email, you=
 mentioned a newly coming topic delegated-voucher, but neither explicitly a=
pply a time slot or submit a new draft. Since we still have 15 minutes spar=
e time in BRASK session. If you want to present this topic, I can put it at=
 the end as the last backup topic.
 
Regards,
 
Sheng
--_000_5D36713D8A4E7348A7E10DF7437A4B9299C28BA3NKGEML515MBXchi_-- From nobody Tue Nov 12 12:01:58 2019 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 BCF6F120839 for ; Tue, 12 Nov 2019 12:01:56 -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_HELO_NONE=0.001, 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 FJYFw0aoK55Z for ; Tue, 12 Nov 2019 12:01:54 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 3717B1200F9 for ; Tue, 12 Nov 2019 12:01:54 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id p26so14095117pfq.8 for ; Tue, 12 Nov 2019 12:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:organization:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=KB7CFEWK2OGVNjxM8L7bWc95Y4tDmZZ7GhMufo7QI78=; b=gJVs3NEwC0+NjaBEuxOJertgWkyaWuwy/RMx741nwaRKGW0Zu8Xnd9REyDqcIgYk77 cPaT0Avwh3hZBgXs9hLq8UCzvUQpM0iT2CTWNo4xEeLZvSQ/DVVYB+J/6anPl5wjSWsG gFQmLkaQTsSjS2KWSdHQSAOKnn0gYs7NLkGdwD0Xg6IPgbVDCZJ1I46IrZ84EJV8Zaev 4UYxAjys8gJaRRNQHAqqSZNFyWctXn/OZh/ylsFfZz8JjHtp58Ma4WZLhKaOnRaHSwD7 WoazN5n+Jpib2bJ+zD0FMSy25PsB4g0MZruC2nUMu/VKUYPvjGEdi69/ZIxz2O+wHc6k ERZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:organization:to:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=KB7CFEWK2OGVNjxM8L7bWc95Y4tDmZZ7GhMufo7QI78=; b=dlq4ybiK9EmlwcNiCyfBnCVZvLrE7gFdeUUZExoruNgR3mCtWet6rHWeLYPbEcZAud R+g4Re31OlHt0nMrAi0QOTUg6bSZbtMRrSVCE7jsGtNMjogUfAE/vPS9VrpAZotWKhTZ Bhy6hFqY6hTejFAdiR840cJ+5d2v2Y6+l9YeEwHykYmPppYbBEZs2phbJLoiYqFKauFA 6x6G/3vIsBkAtilSy01ZLt/I3CiWG+aiSssdWZch50EeAw5zAH1JifnVWK55RzBBaRwu Zk1QMpQxJHnrTapQMPsIss+yZPZRloS3MRju8s1aV0Izwg1D0GuZegQV9LtfTiJzGNOv Yygw== X-Gm-Message-State: APjAAAUx9SeTYrhy+JVhKouzpUqfthesXcsKlXjLIbUmBhZiBtWKc4Bu nix0RVV4UZIYnHy1cSg2pLrQqqpy X-Google-Smtp-Source: APXvYqyrWmtbzRqzsVCaY805mJIUZVshqJpbKQXsvidWGMKWaiJ/5lVnkmS/fGbscOZDdHjT/kWT2Q== X-Received: by 2002:a63:dd11:: with SMTP id t17mr37116235pgg.242.1573588913357; Tue, 12 Nov 2019 12:01:53 -0800 (PST) Received: from [192.168.178.30] (8.166.69.111.dynamic.snap.net.nz. [111.69.166.8]) by smtp.gmail.com with ESMTPSA id b26sm19624987pfo.158.2019.11.12.12.01.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Nov 2019 12:01:52 -0800 (PST) From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: <87eb9861-114d-b910-fb97-9405470715be@gmail.com> Date: Wed, 13 Nov 2019 09:01:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP as a secure session layer X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 12 Nov 2019 20:01:57 -0000 Hi, While thinking about what we need in an ANIMA ecosystem, and about how we might marry ANIMA with more traditional techniques like NETCONF/YANG (as indicated in RFC8368), I remembered one suggestion that I think came from Toerless: is there a way for an ASA to use a secure "clear channel" across the ACP? But of course if we do that, many of the features of GRASP would be lost (discovery, session management). So here's a possible solution. Allow an ASA to use GRASP discovery etc. to set up a secure session with another ASA, but then instead of using GRASP negotiation or synchronization messages, simply take over the session and use simple send/receive primitives for whatever it wants. No sooner thought than done. I added one optional parameter to grasp.req_negotiate() to indicate this mode, and two new functions grasp.send() and grasp.recv(), and GRASP became a secure session layer. The code is really too new for me to commit to GitHub, but it's a very convincing proof of concept. Regards Brian Carpenter From nobody Wed Nov 13 17:49:50 2019 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 8A0F3120044 for ; Wed, 13 Nov 2019 17:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 n68r8cH9apuT for ; Wed, 13 Nov 2019 17:49:45 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A341200C1 for ; Wed, 13 Nov 2019 17:49:45 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DFA2854800B; Thu, 14 Nov 2019 02:49:39 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D51A1440015; Thu, 14 Nov 2019 02:49:39 +0100 (CET) Date: Thu, 14 Nov 2019 02:49:39 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20191114014939.GB33266@faui48f.informatik.uni-erlangen.de> References: <87eb9861-114d-b910-fb97-9405470715be@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eb9861-114d-b910-fb97-9405470715be@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] GRASP as a secure session layer X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 14 Nov 2019 01:49:49 -0000 So.. in the ACP document, the hop-by-hop GRASP connections across the ACP are using TCP because there is no added benefit of TLS given how the connection is to a direct neighbor to which the ACP already uses the secure channel encryption (e.g.: IPsec). End-to-end GRASP connections across the ACP are expected to use TLS. So, i would argue that the peer-to-peer communication of GRASP across ACP is a secure session layer. Just the discovery by its nature requires to trust the third party mitigating the discovery. Because we're doing hop-by-hop forwarding this means discovey needs to trust the intermediate GRASP ACP nodes. If we had a client-server model, (e.g.: unicsat DNS servers), we'd have to trust those servers. So i am not quite sure what you suggested to change. Maybe in the generic case of an undefined "secure transport substrate" below GRASP you give the app the option whether or not to encrypt ? Maybe i am confused ? Cheers Toerless On Wed, Nov 13, 2019 at 09:01:48AM +1300, Brian E Carpenter wrote: > Hi, > > While thinking about what we need in an ANIMA ecosystem, and about how > we might marry ANIMA with more traditional techniques like NETCONF/YANG > (as indicated in RFC8368), I remembered one suggestion that I think came > from Toerless: is there a way for an ASA to use a secure "clear channel" > across the ACP? But of course if we do that, many of the features of > GRASP would be lost (discovery, session management). > > So here's a possible solution. Allow an ASA to use GRASP discovery etc. > to set up a secure session with another ASA, but then instead of using > GRASP negotiation or synchronization messages, simply take over the session > and use simple send/receive primitives for whatever it wants. > > No sooner thought than done. I added one optional parameter to > grasp.req_negotiate() to indicate this mode, and two new functions > grasp.send() and grasp.recv(), and GRASP became a secure session layer. > The code is really too new for me to commit to GitHub, but it's a very > convincing proof of concept. > > Regards > Brian Carpenter > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Nov 13 19:20:24 2019 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 9CF2112007A for ; Wed, 13 Nov 2019 19:20:23 -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_HELO_NONE=0.001, 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 S03xBmnyPcGF for ; Wed, 13 Nov 2019 19:20:20 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 CC54912006B for ; Wed, 13 Nov 2019 19:20:20 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id f19so2726973pgk.11 for ; Wed, 13 Nov 2019 19:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tx1H0+nFHZ2QvOdhbTuI+x/WP7Ya7GKJZaOsGO8MrOY=; b=V4+jV5npg7JHg6cnBeoDJNI3AYbRVFjG+Xet+bj0SfXj1M77zE6flJFHYLDIE69I6O mQFR1APynfkCWn9QSZbOWroUCrjqRg7Rct3Cy4b9EZOixRS4o3pCTWCcMaaoEPID5ich TYztuH4SSW0BEkJyPwG92vSUI81Tyc+41xY0zBaztloXzPUmcL136hFachauSM8H8FdW CzRcedcYG4AStS8ag0/eAPbEW9t/LVWiCj+lYxsSmP9Nlef7X09gI6XccAgNzcjGuHKH ekZPv/BV5226geRdgrieMPKx9tiiAJdcLx9A6QriuehWhhn0NVnLLGk6lGwHxPGxzXgy 8+OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tx1H0+nFHZ2QvOdhbTuI+x/WP7Ya7GKJZaOsGO8MrOY=; b=DU9FyXAw96f71cf6srX7qUaS9VNmQSyEw4f7Yr6a0/Lb5osGQOx10C7bTA0aacJZgY mqC9hm0SiOCjsC0MhmfeAUN0SNxTus3g4u/Zgzocad5E5XhV0MJKTs1jMAfSP3UR+IFS 0nDxWqXoDLtB+Y9yzcUGMzbTBklieB8dpmn66txSA6aRVfGZ6Us9A1bmh2b7rMP5aAlT Zl5H3dDhHBYy+nzh/SK28wI5cyZ3OMMIFBwNCZkTXJr22HTN8lytfp5ZMnMWgWuz/f4s qJVlw7+G6ziE1YXwqDo2MqgEicmOnjMBs8i4HjfV7tUHDZDO71MdXgY8vufEU9FQfgY6 oLUg== X-Gm-Message-State: APjAAAWtT1SfzqEam7iennvnfzwHeWwQa/ogaH4XeCkS4wSxs4a5iUsK vb9I2NAqeJXxf09yjRuwOFbKbBH7 X-Google-Smtp-Source: APXvYqzVrGuLgx5cHfCIVFHYTe2Xo5WAy/UoVQpQymGR9Q6Ks2D3Ewp6iOwLf33lTFqiDuN/GjzEUg== X-Received: by 2002:a63:3603:: with SMTP id d3mr7452960pga.259.1573701619802; Wed, 13 Nov 2019 19:20:19 -0800 (PST) Received: from [192.168.178.30] (8.166.69.111.dynamic.snap.net.nz. [111.69.166.8]) by smtp.gmail.com with ESMTPSA id w8sm4079408pfi.60.2019.11.13.19.20.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 19:20:19 -0800 (PST) To: Toerless Eckert Cc: Anima WG References: <87eb9861-114d-b910-fb97-9405470715be@gmail.com> <20191114014939.GB33266@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <2bee821e-cdeb-187f-f5be-f8527313ead0@gmail.com> Date: Thu, 14 Nov 2019 16:20:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191114014939.GB33266@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP as a secure session layer X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 14 Nov 2019 03:20:24 -0000 On 14-Nov-19 14:49, Toerless Eckert wrote: > So.. in the ACP document, the hop-by-hop GRASP connections across > the ACP are using TCP because there is no added benefit of TLS > given how the connection is to a direct neighbor to which the > ACP already uses the secure channel encryption (e.g.: IPsec). > End-to-end GRASP connections across the ACP are expected to use TLS. Assuming we are worried about MITM attacks by other nodes enrolled in the ACP, yes. But if that isn't part of the threat model, TLS isn't really needed there. > So, i would argue that the peer-to-peer communication of GRASP > across ACP is a secure session layer. Just the discovery by > its nature requires to trust the third party mitigating the > discovery. Because we're doing hop-by-hop forwarding this means > discovey needs to trust the intermediate GRASP ACP nodes. If we had > a client-server model, (e.g.: unicsat DNS servers), we'd have to > trust those servers. > > So i am not quite sure what you suggested to change. Remember that I started this 3 weeks ago because I got bored waiting for the real ACP. Running code, right? My first step was to add shared-key encryption to *all* GRASP packets. My second step was to use a Diffie-Hellman exchange to safely spread those shared keys. All I've done now is add a new option where you use GRASP discovery to find a server and a GRASP request message to start a session. In effect, GRASP hands the socket over to you (encrypted or not). It could work exactly the same if GRASP was using TLS sockets. I'm sure you suggested something like that a couple of years ago. Server: wait for GRASP M_REQ_NEG do forever: grasp.grecv() grasp.gsend() Client: discover peer (GRASP M_DISCOVERY etc) send GRASP M_REQ_NEG do forever: grasp.gsend() grasp.grecv() > Maybe in the generic case of an undefined "secure transport substrate" > below GRASP you give the app the option whether or not to encrypt ? I'm not suggesting that we should formally add encryption to GRASP. It's not a game for amateurs. Remember that the main issue we have is insecure multicast, which is why GRASP is defined only to use LL multicast. If DTLS supported multicast, things could be different, But yes, we could choose to handle this explicitly - it's really an implementation and API issue. > Maybe i am confused ? Maybe my explanations are confused. You can see examples testclient.py and testserver.py at https://github.com/becarpenter/graspy I will be arriving Friday evening in SG and will likely hang around the hackathon. Regards Brian > > Cheers > Toerless > > On Wed, Nov 13, 2019 at 09:01:48AM +1300, Brian E Carpenter wrote: >> Hi, >> >> While thinking about what we need in an ANIMA ecosystem, and about how >> we might marry ANIMA with more traditional techniques like NETCONF/YANG >> (as indicated in RFC8368), I remembered one suggestion that I think came >> from Toerless: is there a way for an ASA to use a secure "clear channel" >> across the ACP? But of course if we do that, many of the features of >> GRASP would be lost (discovery, session management). >> >> So here's a possible solution. Allow an ASA to use GRASP discovery etc. >> to set up a secure session with another ASA, but then instead of using >> GRASP negotiation or synchronization messages, simply take over the session >> and use simple send/receive primitives for whatever it wants. >> >> No sooner thought than done. I added one optional parameter to >> grasp.req_negotiate() to indicate this mode, and two new functions >> grasp.send() and grasp.recv(), and GRASP became a secure session layer. >> The code is really too new for me to commit to GitHub, but it's a very >> convincing proof of concept. >> >> Regards >> Brian Carpenter >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Nov 13 19:40:42 2019 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 6484E120103 for ; Wed, 13 Nov 2019 19:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 0AzaoGXDS2qX for ; Wed, 13 Nov 2019 19:40:36 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DB21200B1 for ; Wed, 13 Nov 2019 19:40:36 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4222A548005; Thu, 14 Nov 2019 04:40:31 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 320D1440015; Thu, 14 Nov 2019 04:40:31 +0100 (CET) Date: Thu, 14 Nov 2019 04:40:31 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20191114034031.GA56410@faui48f.informatik.uni-erlangen.de> References: <87eb9861-114d-b910-fb97-9405470715be@gmail.com> <20191114014939.GB33266@faui48f.informatik.uni-erlangen.de> <2bee821e-cdeb-187f-f5be-f8527313ead0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2bee821e-cdeb-187f-f5be-f8527313ead0@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] GRASP as a secure session layer X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 14 Nov 2019 03:40:40 -0000 On Thu, Nov 14, 2019 at 04:20:16PM +1300, Brian E Carpenter wrote: > On 14-Nov-19 14:49, Toerless Eckert wrote: > > So.. in the ACP document, the hop-by-hop GRASP connections across > > the ACP are using TCP because there is no added benefit of TLS > > given how the connection is to a direct neighbor to which the > > ACP already uses the secure channel encryption (e.g.: IPsec). > > End-to-end GRASP connections across the ACP are expected to use TLS. > > Assuming we are worried about MITM attacks by other nodes enrolled > in the ACP, yes. But if that isn't part of the threat model, TLS > isn't really needed there. Actually that was what trickled through during IESG security review. Without the end-to-end encryption one could argue that the the simple "trust every node in the ACP equally" would not really be a sufficient basis for GRASP apps to exchange all type of probably mutually confidential app-data. Hence the move of end-to-end GRASP connections across ACP to TLS. > > So, i would argue that the peer-to-peer communication of GRASP > > across ACP is a secure session layer. Just the discovery by > > its nature requires to trust the third party mitigating the > > discovery. Because we're doing hop-by-hop forwarding this means > > discovey needs to trust the intermediate GRASP ACP nodes. If we had > > a client-server model, (e.g.: unicsat DNS servers), we'd have to > > trust those servers. > > > > So i am not quite sure what you suggested to change. > > Remember that I started this 3 weeks ago because I got bored > waiting for the real ACP. Running code, right? My first step was > to add shared-key encryption to *all* GRASP packets. My second > step was to use a Diffie-Hellman exchange to safely spread those > shared keys. > All I've done now is add a new option where you use > GRASP discovery to find a server and a GRASP request message to > start a session. In effect, GRASP hands the socket over to you > (encrypted or not). Who am i ? ("hands the socket over to you") > It could work exactly the same if GRASP > was using TLS sockets. I'm sure you suggested something like that > a couple of years ago. > > Server: wait for GRASP M_REQ_NEG > do forever: > grasp.grecv() > grasp.gsend() > > Client: discover peer (GRASP M_DISCOVERY etc) > send GRASP M_REQ_NEG > do forever: > grasp.gsend() > grasp.grecv() Sounds like being on the way to some form of lightweight security substrate instead of ACP. What you should try to achieve is to go from the shared secrets to PFS for the encrypted P2P connection. DH seems like the usual tool here but i am not sure i understand the complete mechanism you implemented. > > Maybe in the generic case of an undefined "secure transport substrate" > > below GRASP you give the app the option whether or not to encrypt ? > > I'm not suggesting that we should formally add encryption to GRASP. It's > not a game for amateurs. Remember that the main issue we have is insecure > multicast, which is why GRASP is defined only to use LL multicast. If DTLS > supported multicast, things could be different, But yes, we could choose to > handle this explicitly - it's really an implementation and API issue. In my previous email i tried to explain how this is not an issue of insecure multicast but the fundamental fact that you need to trust a discovery mechanism as a third-party anyhow. The main novel issue we have in ACP is that we have no well-known unique identifies of peers. Aka: i don't think trying to encrypt discovery would add more security. > > Maybe i am confused ? > > Maybe my explanations are confused. You can see examples testclient.py > and testserver.py at https://github.com/becarpenter/graspy > > I will be arriving Friday evening in SG and will likely hang around the > hackathon. Yep, lets talk in person. Body will arrive also fri evening. After 17.5 hours flight, not sure about the mind though ;-) Cheers Toerless > Regards > Brian From nobody Wed Nov 13 20:30:55 2019 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 C3243120090 for ; Wed, 13 Nov 2019 20:30:54 -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_HELO_NONE=0.001, 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 W3NKvmabgJVR for ; Wed, 13 Nov 2019 20:30:52 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 3E5EF12006B for ; Wed, 13 Nov 2019 20:30:52 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id z24so2864205pgu.4 for ; Wed, 13 Nov 2019 20:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=phPtYc/ccqScv6SVej2yW8dCPCghhX7FSTbUqTXUyWY=; b=drJEdWVUwdWVaLr3Uxs9oAkI11H7wYKYN5pgNg4LI3BBPFn3nNHBbmJTWAhz+A1Etb a9k+DXXsw2fMaF44sEUZfK5hW1ZznmPYhCuluyZLIAn3Wl4NA/CTaI+vx2rzYVklT1/K qQ9IH0tuWakmxr3NcrBXZfhDIR5kukQQdbKvvk2/+UxzGQLqHoA/i+hJ10o2yVM3krl6 iaGrln/r8JgKHK8OIIeSGKec24bn1JtJBhNGa5xOQbY4IxlyDTBSn7lfraHY/JdCpalk GOpJ1OXiFh9OYC2rngrJwDln+esQiURAm2XBJBgWkUaKbgkErdCNyb2jk7OCkZC5VIES Hf7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=phPtYc/ccqScv6SVej2yW8dCPCghhX7FSTbUqTXUyWY=; b=rJk/PnOB5qlCkZ49TY4UUXF310hobUffc/rLIrphz6HWIbaWHLaZLn8CDyw+DLEelU QIUCjdKmrygy7epLrS/zNTRPBB8sCD2g1Y3EAwjJIxtbg3UwRQ8EbQthGW9iA1sOeqn6 aAqs9JxBAThQWsfPvtvAtaZmblV7zokOF5g4LEq8DXcXdVqeXPRI+rVeY88UuXiTgJoV mjI+IppYCAshyXMeTpudhP+NHtjU2jkidFLGOr7hZ/ytAvQ6i/azDKVL0wQzNuxBstYr Yb6WUMlPd07ZL/xv2ZRMRs4udB3/jRlu39mYvYyGjTU63yaxrpuTjetlrMaLIaLXUsEC XjOQ== X-Gm-Message-State: APjAAAVu9JPw20KTb5Td712aDn9kWEYU1RJElXC+9BMV4Y9NMZ8gu/nv JUseWVacBF5aY4/lbeLRgu6hlChN X-Google-Smtp-Source: APXvYqwfQWWj9DKATZdte3DSkodv/8uDM80iUCNejrTvsRvUW71fs2+Sad9grp8RbXKmJcePub0r8w== X-Received: by 2002:a63:f94e:: with SMTP id q14mr3000696pgk.411.1573705850346; Wed, 13 Nov 2019 20:30:50 -0800 (PST) Received: from [192.168.178.21] (8.166.69.111.dynamic.snap.net.nz. [111.69.166.8]) by smtp.gmail.com with ESMTPSA id n21sm3974920pjq.13.2019.11.13.20.30.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 20:30:49 -0800 (PST) To: Toerless Eckert Cc: Anima WG References: <87eb9861-114d-b910-fb97-9405470715be@gmail.com> <20191114014939.GB33266@faui48f.informatik.uni-erlangen.de> <2bee821e-cdeb-187f-f5be-f8527313ead0@gmail.com> <20191114034031.GA56410@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <74b44d7a-92b8-e51b-8575-658ded0762b9@gmail.com> Date: Thu, 14 Nov 2019 17:30:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191114034031.GA56410@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP as a secure session layer X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 14 Nov 2019 04:30:55 -0000 Just responding on one point that is probably crucial: > The main novel issue we > have in ACP is that we have no well-known unique identifies of peers. Absolutely, and we left authorization out of scope until now. But BRSKI gives us identities and surely the possibility of authzn built on those identities? Again - it depends on the threat model. My toy security uses AES and RSA and all that good stuff, but if someone presents the right password they become universally trusted. I did call it QUick And Dirty Security for a reason. (As for PFS, I don't see how that works for unsolicited multicasts. Clearly once you start a new session, you could regenerate keys. But for multicasts I think a shared key is unavoidable, isn't it?) Regards Brian On 14-Nov-19 16:40, Toerless Eckert wrote: > On Thu, Nov 14, 2019 at 04:20:16PM +1300, Brian E Carpenter wrote: >> On 14-Nov-19 14:49, Toerless Eckert wrote: >>> So.. in the ACP document, the hop-by-hop GRASP connections across >>> the ACP are using TCP because there is no added benefit of TLS >>> given how the connection is to a direct neighbor to which the >>> ACP already uses the secure channel encryption (e.g.: IPsec). >>> End-to-end GRASP connections across the ACP are expected to use TLS. >> >> Assuming we are worried about MITM attacks by other nodes enrolled >> in the ACP, yes. But if that isn't part of the threat model, TLS >> isn't really needed there. > > Actually that was what trickled through during IESG security review. > Without the end-to-end encryption one could argue that the the simple > "trust every node in the ACP equally" would not really be a sufficient > basis for GRASP apps to exchange all type of probably mutually > confidential app-data. Hence the move of end-to-end GRASP connections > across ACP to TLS. > >>> So, i would argue that the peer-to-peer communication of GRASP >>> across ACP is a secure session layer. Just the discovery by >>> its nature requires to trust the third party mitigating the >>> discovery. Because we're doing hop-by-hop forwarding this means >>> discovey needs to trust the intermediate GRASP ACP nodes. If we had >>> a client-server model, (e.g.: unicsat DNS servers), we'd have to >>> trust those servers. >>> >>> So i am not quite sure what you suggested to change. >> >> Remember that I started this 3 weeks ago because I got bored >> waiting for the real ACP. Running code, right? My first step was >> to add shared-key encryption to *all* GRASP packets. My second >> step was to use a Diffie-Hellman exchange to safely spread those >> shared keys. > All I've done now is add a new option where you use >> GRASP discovery to find a server and a GRASP request message to >> start a session. In effect, GRASP hands the socket over to you >> (encrypted or not). > > Who am i ? ("hands the socket over to you") > >> It could work exactly the same if GRASP >> was using TLS sockets. I'm sure you suggested something like that >> a couple of years ago. >> >> Server: wait for GRASP M_REQ_NEG >> do forever: >> grasp.grecv() >> grasp.gsend() >> >> Client: discover peer (GRASP M_DISCOVERY etc) >> send GRASP M_REQ_NEG >> do forever: >> grasp.gsend() >> grasp.grecv() > > Sounds like being on the way to some form of lightweight security > substrate instead of ACP. > > What you should try to achieve is to go from the shared secrets to PFS > for the encrypted P2P connection. DH seems like the usual tool here > but i am not sure i understand the complete mechanism you implemented. > >>> Maybe in the generic case of an undefined "secure transport substrate" >>> below GRASP you give the app the option whether or not to encrypt ? >> >> I'm not suggesting that we should formally add encryption to GRASP. It's >> not a game for amateurs. Remember that the main issue we have is insecure >> multicast, which is why GRASP is defined only to use LL multicast. If DTLS >> supported multicast, things could be different, But yes, we could choose to >> handle this explicitly - it's really an implementation and API issue. > > In my previous email i tried to explain how this is not an issue > of insecure multicast but the fundamental fact that you need to trust > a discovery mechanism as a third-party anyhow. The main novel issue we > have in ACP is that we have no well-known unique identifies of peers. > Aka: i don't think trying to encrypt discovery would add more security. > >>> Maybe i am confused ? >> >> Maybe my explanations are confused. You can see examples testclient.py >> and testserver.py at https://github.com/becarpenter/graspy >> >> I will be arriving Friday evening in SG and will likely hang around the >> hackathon. > > Yep, lets talk in person. Body will arrive also fri evening. After > 17.5 hours flight, not sure about the mind though ;-) > > Cheers > Toerless > >> Regards >> Brian > From nobody Fri Nov 15 06:20:38 2019 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 287F812086B for ; Fri, 15 Nov 2019 06:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 f6fYIMCsvrlD for ; Fri, 15 Nov 2019 06:20:34 -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 10CD2120013 for ; Fri, 15 Nov 2019 06:20:33 -0800 (PST) Received: from [192.168.42.31] (unknown [209.171.88.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id DC87C3897C for ; Fri, 15 Nov 2019 09:17:22 -0500 (EST) To: anima@ietf.org From: Michael Richardson Openpgp: preference=signencrypt Autocrypt: addr=mcr@sandelman.ca; keydata= mQGNBF3EaO8BDADNdcAioLgGWFMLcmR6SuX1ioVH0v1fcprk0Wl1Qc7LCdwqj+QSdv84oNe1 h6lTf+CsmzO+TZtL+2iUzR3WHyXViEJcSHldx2YIfgxGZkzqgqozDj2IoHCU6ezhQz2TwJO7 l6H7fIPBbemIu8qVezwP1azLVq3D+cXZkkOvsFhTiw1bF/WF8lIIAYEbQ4YyYyjk5DS30x59 kxFNSv6om8rqSAKs2epneEWpzybB0J82dBnB4VDDsMmTJWPkszvQoCjCbrvgDAuoRtL5su2V IQWw61O6N5p1mwJ7VQoPDWYyeFH4NrVlL71FwRLueVPle76Oi3ybE2IMUvHZ/e42jVBizlQj 1N/2x7mGk35Zrvz0WHjZLcFJYJkDOnLsMU1smhdRtxNfYf576DTlzQKVcLmNCfOKAWnz4DdQ gRI4pNs24NoxLXl5v5mhDHRX5Me+CuckkFNGSlCXZ5kMXzPPFAV6CwMlm65P1tVJq9td8Uh0 5I5okPcENk5iY+FniqMXamsAEQEAAbQlTWljaGFlbCBSaWNoYXJkc29uIDxtY3JAc2FuZGVs bWFuLmNhPokB1AQTAQgAPhYhBKMP9ag1YAG1i9s8WHACrsLM2IBDBQJdxGjwAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHACrsLM2IBDeJ4MAMvUmQjFqXgsg4KhIWQb QBcgNPxrtp9jW/i2m//0zVA2iGxbeTOZD6cmcNDRj153TbSGTEH03oJIeYbdwlOCe5blA6h4 FTEBwt/qX+mjRYKXuA3uvFdEJQJPFcaWFF68rgQMxgLPPUAnTYQ00SqaBEg+Vh4gSh8yOHuU 8VTgenm4JpBdJQx7/7syvIaQilhN2fF25CcA7hArmebkaG691x+cFD60s8ITI9PSf82SVUnp mspJTGptxFxH/GM/kW40iB4tUjZrUSQfTfWIXA/5j005XbVbo1DIYirWWNK0WPVsh51ullzt u37BDVj/SmgbGhvTUXwsBi4b+T2cJHLt+8QT/KM8OA+UA8AlkNPleKtOzxsg5z22m0fzollE Zcw9VIojPKIhTUYU79InmibEUoGfb05MFJM9aXX5BMoJNpKcB92PKI/gMsrxMwH1exs0cY/E K/xYdpFo3rTPw5KSsDkr7ZbqGPgz+QP2H+TLwgLKMFTBlVKpj+oqBnqeEVVrC7kBjQRdxGjv AQwA0T5oxtsQkr3I3FxBi5TkNSh0HZ7ND5xJJkyM6wLAsljLk5KhdcxjTlo6htNjRUuUy1Ld 0bARmezZf5GqKRh6fR7WX9EdYjGm0RbcK3tQ3L61h4p3EOplKgMSoGpGamLSDzRs3SAJu4GF iHfzQ20R0PxBN/CbzWh6ROPcxQ8wwt8G4ZOwU4zXfSmZqZwNp/6xosLCl3TKvFWX6421Vb/L WAOOAz/xSyS0GCUs/grBUfzu95+TTskRk7kkeYSQ//1Oq9srPlIU9lx3Y4jDgPkXIwd9eXOq e7/5y4bQkILGGMIux878DhAED865hPMBuHlkDNzIuo6HhjRkShLBM16yQhK+NJ0WI77+m1FD 7r5QL6iU57zI/B5U03JKZhW0Pm3Bm+RWZPWGVawkPUnvxoMFbw+x1+MnKZgXwRmRmbFsCHhD VmrDKLWXRm9QvTB+k0ZnTdme9ZwSNCn0CXME2rNtOR39Yh6dsWH2nMPvg/G5iUmZyO9Oa01W xhWcXnKA+v+VABEBAAGJAbwEGAEIACYWIQSjD/WoNWABtYvbPFhwAq7CzNiAQwUCXcRo7wIb DAUJAeEzgAAKCRBwAq7CzNiAQwaOC/4olaVHP/npCn2CrtAOstbyytePFmS9NAwdT8A6mA4s +WshPo1DhKEnKnYzW/S0jLf0iqlzT8LUqu2G8f6elGzghRR8WJVn0zH7LVCKMWo/tHE2rWyi Q1zuX9o7ChTodQ8cXx0lM1xdY8v4Amc5fFxyyhJprKZAtiDJ897vv1jP09fWLEBhaDsHqLhg ckQpIoee0Id4FXGt7wxDsPwa64SUUCTYdt98EiLoUY6eAWQnyelgbFU+D/bxkeytmmvWOVr7 UXVMQlEKG7E31G1XQMk6sFATF1dwiH/laLQPLuMYr7owUC+ef/YAWSHMTYeIfwdt/Yd8ngJ8 SFA6Uc+Bjr0i1jdnxS5H3EF4V1FNY2rh4zNPVNj2UrZaShK/XH4hnTJUYL5fo2ygt2ZM98ot 8lIsHGAJQHDl2/EffLsAL85pXDPl8E+nvOUOE1kwmfOgv/oV8z0469qu/hNiEpGp8xKBqGEL NWHd8fH5S9JxVix9Ed34vi9Cyf24iLjiWZBemXw= Message-ID: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> Date: Fri, 15 Nov 2019 22:20:25 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Anima] some comments about ACP connect X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2019 14:20:36 -0000 Toerless, I am preparing a document on Operational Considerations for Registrars: "Operational Considerations for BRSKI Registrar" I was reviewing section 8.1, on ACP connect.    To allow for auto-configuration of NMS hosts, the ACP edge device and    NMS hosts using ACP connect SHOULD support [RFC4191].  The ACP edge    device should announce the whole ACP ULA prefix via that standards    Router Advertisement signaling option.  It should also announce the    default route (::/) with a lifetime of 0.  In result, NMS hosts    supporting RFC4191 will route the ACP prefix via the ACP edge device,    but will not route the default route via it. I don't disagree with anything you say, btw. I think that maybe some explanation is in order here though. I recognize the document is in it's final stage, but maybe a word or two could be added here. First, what is the "whole ACP ULA prefix"?  Is it the /48?  I think we could say so. I will send a pull request once I finish writing. Second, if 6.10.2 defines the base scheme, and it's 8+40+2=50, why in 6.10.3 does it say "51*" above the "(base scheme)"?  Is that a typo? It seems that we could advertise a 6.10.3 non-zero "Zone" on the NOC ACP Connect "LAN"? It seems that we ought to sending a Routing Information Option for the /48, and a PIO for the specific /64 above. We might want to set L=0 here.  I understand that we advertise ::/0 with lifetime=0 because of RFC4191 section 3 analysis. I don't know if type A,B,or C hosts are common out there, I think that rfc4191 is widely implemented at this point, so I suspect most hosts are type C at this point. Generally, I think that NOC hosts should not autoconfigure (SLAAC or stable private address) addresses, as they ought to be manually configured.  I am open to discussion here.  I do think that they should listen to RAs for the ACP route so that we can have multiple routers, etc. * I will be making a few more specific recommendations in my document in line with the view above. From nobody Sat Nov 16 15:51:19 2019 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 EF5D2120807 for ; Sat, 16 Nov 2019 15:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 OVpDRqXlULiT for ; Sat, 16 Nov 2019 15:51:16 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 46DFE120025 for ; Sat, 16 Nov 2019 15:51:16 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id n13so8469664pff.1 for ; Sat, 16 Nov 2019 15:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=HfkJLJAMv/lGrcFSVDaw1DTA34mMvDc7M6q51FlTOMU=; b=Ci2AeVWGdi/s397n/6yM3DIK/2BYByp8jERtpZ0AT1nPrNphsZEa8ioT0HQnb64okO 6mhbcCGtSteE9Mkd4iiSgNHUrK1XLH3O6AXeebsxCZVa3tZtfzhEMN2AL12FaOI9Defs rej7rxpCOsliYlQMVJgriEkmkpLyRT8o2gpAkItgYG07wrF7GP1F1pHUpqBVy0uwtMtX J878CWZpwCKDydrfl4WJc5sBe5rLJTi5F2eM+XZGGYSR6LYc7Y61rowi5WZ2/Bn/61DL dWkNn767ukNhyNYhEx4yDrYhxkGY1ZZPNDVAMYXvhBdl1hDANT7skX5DrpYN/+dCdZKt CjWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HfkJLJAMv/lGrcFSVDaw1DTA34mMvDc7M6q51FlTOMU=; b=DuNIo56Gr/kpVKoC7jVkm99J5K6QVyeUHdAvGW6r2Dn2eu7YRlpmwIVlHKFm6jMSnu jwrDRpykAe5hxSLZYPZ2gEjBMAD+9IyyjpYJrRr8JspTajFuhHnVQ8s9azRmbnv3iC9R 3hm89HyOPrqrBTTtzpvLgyBTjF3HoeOGQlJ4DJcMp3Ro1zKqEMeTQyNZGSl8jbXWBqeu 09Bwh00MzkMBkWEZOp5+43K14TtMDOzeSzLPZp7TJGbZFcCTzdgch75ClPWXOEmmBiBD A9L/0d7AGtqSDx0geBF2pdoeEkUhdmY0Mw8XYQ9wGGW1HfZVySYU07gdmcKn++XhDL1k ZOyg== X-Gm-Message-State: APjAAAWaXK0sBqMwfANWq81sozGGANr1JJ09FkUw/RZjIAmF7tJ034NG AexQwI+2db4zP3UMCv/1vFfY1ihx X-Google-Smtp-Source: APXvYqzO/GMkI6wjx+KaelOb9NWvFTiXRFIpIl8LftpZKBFfks9smcM4XuYKFHtvIE3MqouTWqYT2Q== X-Received: by 2002:a63:7a50:: with SMTP id j16mr8040491pgn.206.1573948275296; Sat, 16 Nov 2019 15:51:15 -0800 (PST) Received: from [31.133.158.74] (dhcp-9e4a.meeting.ietf.org. [31.133.158.74]) by smtp.gmail.com with ESMTPSA id y4sm15378588pfn.97.2019.11.16.15.51.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Nov 2019 15:51:14 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> From: Brian E Carpenter Message-ID: Date: Sun, 17 Nov 2019 12:51:12 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] some comments about ACP connect X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2019 23:51:18 -0000 On 16-Nov-19 03:20, Michael Richardson wrote: > Toerless, I am preparing a document on Operational Considerations for > Registrars: "Operational Considerations for BRSKI Registrar" >=20 > I was reviewing section 8.1, on ACP connect. >=20 > =C2=A0=C2=A0 To allow for auto-configuration of NMS hosts, the ACP edge= device and > =C2=A0=C2=A0 NMS hosts using ACP connect SHOULD support [RFC4191].=C2=A0= The ACP edge > =C2=A0=C2=A0 device should announce the whole ACP ULA prefix via that s= tandards > =C2=A0=C2=A0 Router Advertisement signaling option.=C2=A0 It should als= o announce the > =C2=A0=C2=A0 default route (::/) with a lifetime of 0.=C2=A0 In result,= NMS hosts > =C2=A0=C2=A0 supporting RFC4191 will route the ACP prefix via the ACP e= dge device, > =C2=A0=C2=A0 but will not route the default route via it. >=20 > I don't disagree with anything you say, btw. > I think that maybe some explanation is in order here though. > I recognize the document is in it's final stage, but maybe a word or tw= o > could be added here. > First, what is the "whole ACP ULA prefix"?=C2=A0 Is it the /48?=C2=A0 I= think we > could say so. > I will send a pull request once I finish writing. Assuming it does mean the /48, that's an editorial clarification. (If it doesn't mean that, please explain.) =20 > Second, if 6.10.2 defines the base scheme, and it's 8+40+2=3D50, why in= > 6.10.3 does it > say "51*" above the "(base scheme)"?=C2=A0 Is that a typo? Huh? That is not present in the -21 draft. =20 > It seems that we could advertise a 6.10.3 non-zero "Zone" on the NOC AC= P > Connect "LAN"? >=20 > It seems that we ought to sending a Routing Information Option for the > /48, and a PIO for the specific /64 above. > We might want to set L=3D0 here.=C2=A0 > I understand that we advertise ::/0 with lifetime=3D0 because of RFC419= 1 > section 3 analysis. > I don't know if type A,B,or C hosts are common out there, I think that > rfc4191 is widely implemented at this point, so I suspect most hosts ar= e > type C at this point. >=20 > Generally, I think that NOC hosts should not autoconfigure (SLAAC or > stable private address) addresses, as they ought to be manually > configured.=C2=A0 I am open to discussion here. I can see that for conventional management tools. I will just observe that GRASP discovery doesn't need to be seeded with any well known addresses (except the GRASP LL multicast address) so GRASP is completely indifferent to how NOC hosts get their unicast addresses. In fact we could easily create a full NOC discovery mechanism over GRASP. I built a MUD Manager discovery mechanism in the hackathon yesterday, and any NOC server could be discovered the same way. It's probably worth re-reading RFC8368 before discussing further. (In my code, I gave preference to ULAs over GUAs, but GRASP doesn't even care about that). Brian > I do think that they should > listen to RAs for the ACP route so that we can have multiple routers, e= tc. > * > I will be making a few more specific recommendations in my document in > line with the view above. >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Sat Nov 16 20:51:56 2019 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 37DE3120043 for ; Sat, 16 Nov 2019 20:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 r2cyy4leK_f9 for ; Sat, 16 Nov 2019 20:51:51 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0952E120018 for ; Sat, 16 Nov 2019 20:51:50 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B5431548056; Sun, 17 Nov 2019 05:51:44 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B0AB0440055; Sun, 17 Nov 2019 05:51:44 +0100 (CET) Date: Sun, 17 Nov 2019 05:51:44 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20191117045144.GB56410@faui48f.informatik.uni-erlangen.de> References: <87eb9861-114d-b910-fb97-9405470715be@gmail.com> <20191114014939.GB33266@faui48f.informatik.uni-erlangen.de> <2bee821e-cdeb-187f-f5be-f8527313ead0@gmail.com> <20191114034031.GA56410@faui48f.informatik.uni-erlangen.de> <74b44d7a-92b8-e51b-8575-658ded0762b9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74b44d7a-92b8-e51b-8575-658ded0762b9@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] GRASP as a secure session layer X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2019 04:51:54 -0000 On Thu, Nov 14, 2019 at 05:30:45PM +1300, Brian E Carpenter wrote: > Absolutely, and we left authorization out of scope until now. But > BRSKI gives us identities and surely the possibility of authzn built on > those identities? Yes, it does, except we are missing the "well-known" part that we have in the Internet through a combination of (A) knowledge "example.com has the best 'whatever' product", and (B) the certificate for example.com so that you securely know you are connecting to example.com. IMHO, in a fully autonomic network, the problem is not (B), but (A). (B) can easily be an ACP (ANI/BRSKI) certificate. The problem is (A): How do you know from multiple GRASP offers which one to trust "most". Right now we have the model that all nodes are equally trustworthy. For a good self-organizing solution, it would be alot better to have mechanisms beyond this. > Again - it depends on the threat model. My toy security uses AES and RSA > and all that good stuff, but if someone presents the right password they > become universally trusted. I did call it QUick And Dirty Security for > a reason. I don't think this is only a security issue. I think more about a service quality vetting problem. In my DNS-SD -> GRASP drafts, i am just mapping service quality parameter as we did in DNS-SD, but that model implies tht there is a magic external entity that can assign consistent service quality parameters aross multiple instances. Like the magic operator or SDN controller. We do not have self-organization of this based on e.g.: control loops that measure the service experience and then dynamically update the service quality parameters. > (As for PFS, I don't see how that works for unsolicited multicasts. > Clearly once you start a new session, you could regenerate keys. But > for multicasts I think a shared key is unavoidable, isn't it?) The discovery is only has domain-membership-group-security. But once you build a p2p connection, your security association mechanism should ensure PFS. Which means that as soon as you start talking to a particular peer you will be sure you will continue to talkk only to that peer and can not be interepted by another peer. Most TLS options offer PFS. I am just not 100% sure right now if any simple DH step already is sufficient for PFS. Cheers Toerless > Regards > Brian > > On 14-Nov-19 16:40, Toerless Eckert wrote: > > On Thu, Nov 14, 2019 at 04:20:16PM +1300, Brian E Carpenter wrote: > >> On 14-Nov-19 14:49, Toerless Eckert wrote: > >>> So.. in the ACP document, the hop-by-hop GRASP connections across > >>> the ACP are using TCP because there is no added benefit of TLS > >>> given how the connection is to a direct neighbor to which the > >>> ACP already uses the secure channel encryption (e.g.: IPsec). > >>> End-to-end GRASP connections across the ACP are expected to use TLS. > >> > >> Assuming we are worried about MITM attacks by other nodes enrolled > >> in the ACP, yes. But if that isn't part of the threat model, TLS > >> isn't really needed there. > > > > Actually that was what trickled through during IESG security review. > > Without the end-to-end encryption one could argue that the the simple > > "trust every node in the ACP equally" would not really be a sufficient > > basis for GRASP apps to exchange all type of probably mutually > > confidential app-data. Hence the move of end-to-end GRASP connections > > across ACP to TLS. > > > >>> So, i would argue that the peer-to-peer communication of GRASP > >>> across ACP is a secure session layer. Just the discovery by > >>> its nature requires to trust the third party mitigating the > >>> discovery. Because we're doing hop-by-hop forwarding this means > >>> discovey needs to trust the intermediate GRASP ACP nodes. If we had > >>> a client-server model, (e.g.: unicsat DNS servers), we'd have to > >>> trust those servers. > >>> > >>> So i am not quite sure what you suggested to change. > >> > >> Remember that I started this 3 weeks ago because I got bored > >> waiting for the real ACP. Running code, right? My first step was > >> to add shared-key encryption to *all* GRASP packets. My second > >> step was to use a Diffie-Hellman exchange to safely spread those > >> shared keys. > All I've done now is add a new option where you use > >> GRASP discovery to find a server and a GRASP request message to > >> start a session. In effect, GRASP hands the socket over to you > >> (encrypted or not). > > > > Who am i ? ("hands the socket over to you") > > > >> It could work exactly the same if GRASP > >> was using TLS sockets. I'm sure you suggested something like that > >> a couple of years ago. > >> > >> Server: wait for GRASP M_REQ_NEG > >> do forever: > >> grasp.grecv() > >> grasp.gsend() > >> > >> Client: discover peer (GRASP M_DISCOVERY etc) > >> send GRASP M_REQ_NEG > >> do forever: > >> grasp.gsend() > >> grasp.grecv() > > > > Sounds like being on the way to some form of lightweight security > > substrate instead of ACP. > > > > What you should try to achieve is to go from the shared secrets to PFS > > for the encrypted P2P connection. DH seems like the usual tool here > > but i am not sure i understand the complete mechanism you implemented. > > > >>> Maybe in the generic case of an undefined "secure transport substrate" > >>> below GRASP you give the app the option whether or not to encrypt ? > >> > >> I'm not suggesting that we should formally add encryption to GRASP. It's > >> not a game for amateurs. Remember that the main issue we have is insecure > >> multicast, which is why GRASP is defined only to use LL multicast. If DTLS > >> supported multicast, things could be different, But yes, we could choose to > >> handle this explicitly - it's really an implementation and API issue. > > > > In my previous email i tried to explain how this is not an issue > > of insecure multicast but the fundamental fact that you need to trust > > a discovery mechanism as a third-party anyhow. The main novel issue we > > have in ACP is that we have no well-known unique identifies of peers. > > Aka: i don't think trying to encrypt discovery would add more security. > > > >>> Maybe i am confused ? > >> > >> Maybe my explanations are confused. You can see examples testclient.py > >> and testserver.py at https://github.com/becarpenter/graspy > >> > >> I will be arriving Friday evening in SG and will likely hang around the > >> hackathon. > > > > Yep, lets talk in person. Body will arrive also fri evening. After > > 17.5 hours flight, not sure about the mind though ;-) > > > > Cheers > > Toerless > > > >> Regards > >> Brian > > -- --- tte@cs.fau.de From nobody Sat Nov 16 22:32:06 2019 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 1521612009C for ; Sat, 16 Nov 2019 22:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 FmiuZW_BJda9 for ; Sat, 16 Nov 2019 22:32:03 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F2B12007C for ; Sat, 16 Nov 2019 22:32:02 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 32744548029; Sun, 17 Nov 2019 07:31:58 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2B463440055; Sun, 17 Nov 2019 07:31:58 +0100 (CET) Date: Sun, 17 Nov 2019 07:31:58 +0100 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20191117063158.GC56410@faui48f.informatik.uni-erlangen.de> References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] some comments about ACP connect X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2019 06:32:05 -0000 Thanks, Michael. Given how i may not 100% observe the github, make sure you also send email when oyu have proposed fixes. Please also use the latest xml on datatracker as the authoritative soucrce. I already missed one github feedback from you earlier. I apologize, but i am not the fluent github user yet. On Fri, Nov 15, 2019 at 10:20:25PM +0800, Michael Richardson wrote: > > I was reviewing section 8.1, on ACP connect. > >    To allow for auto-configuration of NMS hosts, the ACP edge device and >    NMS hosts using ACP connect SHOULD support [RFC4191].  The ACP edge >    device should announce the whole ACP ULA prefix via that standards >    Router Advertisement signaling option.  It should also announce the >    default route (::/) with a lifetime of 0.  In result, NMS hosts >    supporting RFC4191 will route the ACP prefix via the ACP edge device, >    but will not route the default route via it. I can not find this particular version of the paragraph in any version. Which version of the ACP draft is this from ? > I don't disagree with anything you say, btw. > I think that maybe some explanation is in order here though. > I recognize the document is in it's final stage, but maybe a word or two > could be added here. > First, what is the "whole ACP ULA prefix"?  Is it the /48?  I think we > could say so. > I will send a pull request once I finish writing. The document is not using the term "whole" in conjunction with "ACP prefix" and the acronym section (2.) defines "ACP (ULA) prefix(es)" as /48 bit prefixes. > Second, if 6.10.2 defines the base scheme, and it's 8+40+2=50, why in > 6.10.3 does it > say "51*" above the "(base scheme)"?  Is that a typo? The 51 below the (base scheme) in 6.10.3 was fixed to 50 in revision -09. > It seems that we could advertise a 6.10.3 non-zero "Zone" on the NOC ACP > Connect "LAN"? Yes, except that you would then need to figure out how to assign fitting /64 bit host-parts with Registrar-ID and Node-Number to non-autonomic devices on that autonomic-connect LAN. Hence the introduction of the Manual addressing scheme that does not have this expectation against the /64 host part. Aka: use the manual addressing sub-scheme. Where "manual" means "not managed by registrars". > It seems that we ought to sending a Routing Information Option for the > /48, and a PIO for the specific /64 above. > We might want to set L=0 here.  Probably faster if you spend some in-person cycles with me on those parameters as i do not have those route advertisement details memorized as much as you may have. > I understand that we advertise ::/0 with lifetime=0 because of RFC4191 > section 3 analysis. > I don't know if type A,B,or C hosts are common out there, I think that > rfc4191 is widely implemented at this point, so I suspect most hosts are > type C at this point. > > Generally, I think that NOC hosts should not autoconfigure (SLAAC or > stable private address) addresses, as they ought to be manually > configured.  I am open to discussion here.  I do think that they should > listen to RAs for the ACP route so that we can have multiple routers, etc. The whole idea of the text is to exactly allow for whatever host-address part allocation people feel most comfortable with and not predicate any preference. DHCP, SLAAC, whatever. The only thing the document tries to say is how to ensure that hosts which are multi-homed with such an acp-connect LAN being one of its subnets - would route all ACP prefixes to the ACP edge node, but not a default-route. So i hope we are in violent agreement here. If you think there is text missing, plase suggest. > I will be making a few more specific recommendations in my document in > line with the view above. Thanks Toerless From nobody Sat Nov 16 22:38:32 2019 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 895A1120089 for ; Sat, 16 Nov 2019 22:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 U4waNiRLwZ0y for ; Sat, 16 Nov 2019 22:38:30 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC20412007C for ; Sat, 16 Nov 2019 22:38:29 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 60ABD548029; Sun, 17 Nov 2019 07:38:24 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 50B10440055; Sun, 17 Nov 2019 07:38:24 +0100 (CET) Date: Sun, 17 Nov 2019 07:38:24 +0100 From: Toerless Eckert To: Brian E Carpenter Cc: Michael Richardson , anima@ietf.org Message-ID: <20191117063824.GD56410@faui48f.informatik.uni-erlangen.de> References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> 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.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] some comments about ACP connect X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2019 06:38:32 -0000 On Sun, Nov 17, 2019 at 12:51:12PM +1300, Brian E Carpenter wrote: > > Generally, I think that NOC hosts should not autoconfigure (SLAAC or > > stable private address) addresses, as they ought to be manually > > configured.  I am open to discussion here. > > I can see that for conventional management tools. I will just observe > that GRASP discovery doesn't need to be seeded with any well known > addresses (except the GRASP LL multicast address) so GRASP is completely > indifferent to how NOC hosts get their unicast addresses. In fact we > could easily create a full NOC discovery mechanism over GRASP. I built > a MUD Manager discovery mechanism in the hackathon yesterday, and any > NOC server could be discovered the same way. It's probably worth > re-reading RFC8368 before discussing further. > > (In my code, I gave preference to ULAs over GUAs, but GRASP doesn't even > care about that). Rereading Michaels sentence again after my previous email answer, i would lke to double down on what Brian said: today, there is a lot of manual configuration of NOC server IP addresses on each route for various services. The DNS-SD drafts i wrote (expired, to be revived, when i got ACP off my back) are exactly to overcome this problem by learning via DNS-SD (ACP GRASP as transport ;-) those NOC host services. Once you have this service discovery, NOC hosts do not need well-known IP addresses anymore, but can use SLAAC, or DHCP on the ACP connect LAN - whatever the operator prefers. Of course, ther is IMHO no need for DHCP, but its likely that in the non-ACP part of the network, some service parameters may still be learned from DHCP (such as DNS servers), and i have seen few deployments that tried to combine DHCP service discovery with SLAAC address assignment. Besides, there is also litte address tracking with SLAAC, and operators like to be able to track addresses. Aka: As long as we do not have stronger arguments either way, i wouldn't get into the middle of the SLAAC vs. DHCP debate. I just want to make sure that we do not need well-known IP addresses. Cheers Toerless From nobody Sun Nov 17 00:39:03 2019 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 559341200DF for ; Sun, 17 Nov 2019 00:39:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 pVv3yo0XuGq8 for ; Sun, 17 Nov 2019 00:38:58 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 439931200D5 for ; Sun, 17 Nov 2019 00:38:58 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id o9so7799463plk.6 for ; Sun, 17 Nov 2019 00:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=I0UG2jjTLTKU3s2wMdbpOR3buqQl2oVWDGnMTJo6AQw=; b=trDcEuzrWIN0Vx3HqC+NdM0G5/Q5DRQt/MWYkqJyWvWTolSAfuOo+HxrcJrELtRJHN ur2Y8iTRT8BeZwOAMOL3GPY0YRenNqlvJXaWRn6SBL13lPyrvb/RrwNm/lCiu4HtoQBT B9PljZqaHqh4oZEe6ckb3lf1bB/Zu/98ikiL62NuCiGwKnoQEeiklc1dVrbmB0AmLhw5 YvhEVOQJQ9n5Wi/pnnWuXHqKT3+dirh1IAdnafB8tHWg2ypgevsj3HoEnrRfesGi4J8m kOI15Ykdox6gDQb8gcyqOVETXWIzlkoK0iHpXGyLSf5OtfesGZEbl1AshQCzSBjKYnHM vm0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=I0UG2jjTLTKU3s2wMdbpOR3buqQl2oVWDGnMTJo6AQw=; b=BD1iKpLpJmPPfXG2d/pfozs2QPv6by9u/eDydzWoVtjPYNZwWzC4Speb4aI7fVi/WK LfeQRBacPEL23FO6XjwKqFVyewVaH8IvRpbNU/XMyZIpJsu9Y+yATRXaDgSAwlXDOouB Yv8woU8wfPgS+y37tPgzSPS/6U2xa3CdDPaGF6H/UCYJYxMDv2fUeEZ5+CUV/jqeI66C Ua6kvY1T+afsirtPEytTRp6+XKHwTudx2XHYdLy5FdzEFs2y138KLF/QFZ1jd2zROXXo OmXRWeFFusC/rr4v2m9ax/0qBElzz/wDHIO2PFdqZqiiFnvki/4zmgovhCHWFTrpD7Q4 cTJA== X-Gm-Message-State: APjAAAX+m6DtkUB29fJeq90NFUNj6xQyCl21oliGWvxtUYibm6EDhur4 qU7p7riEflJEMChcCInbZ5mtibFj X-Google-Smtp-Source: APXvYqxaYhYsRGQmSoJxWKQsC5kwBqxqPqT6HcSY+y9Nx6R/PPxeZt+Tn3Cak7AL0oPSGPQOD/sVDA== X-Received: by 2002:a17:90a:348c:: with SMTP id p12mr31364121pjb.105.1573979937157; Sun, 17 Nov 2019 00:38:57 -0800 (PST) Received: from [31.133.158.74] (dhcp-9e4a.meeting.ietf.org. [31.133.158.74]) by smtp.gmail.com with ESMTPSA id n18sm15076124pff.152.2019.11.17.00.38.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 00:38:56 -0800 (PST) To: Toerless Eckert Cc: Anima WG References: <87eb9861-114d-b910-fb97-9405470715be@gmail.com> <20191114014939.GB33266@faui48f.informatik.uni-erlangen.de> <2bee821e-cdeb-187f-f5be-f8527313ead0@gmail.com> <20191114034031.GA56410@faui48f.informatik.uni-erlangen.de> <74b44d7a-92b8-e51b-8575-658ded0762b9@gmail.com> <20191117045144.GB56410@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Sun, 17 Nov 2019 21:38:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191117045144.GB56410@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP as a secure session layer X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2019 08:39:00 -0000 On 17-Nov-19 17:51, Toerless Eckert wrote: > On Thu, Nov 14, 2019 at 05:30:45PM +1300, Brian E Carpenter wrote: >> Absolutely, and we left authorization out of scope until now. But >> BRSKI gives us identities and surely the possibility of authzn built on >> those identities? > > Yes, it does, except we are missing the "well-known" part that we > have in the Internet through a combination of (A) knowledge > "example.com has the best 'whatever' product", and (B) the certificate > for example.com so that you securely know you are connecting to > example.com. > > IMHO, in a fully autonomic network, the problem is not (B), but (A). > (B) can easily be an ACP (ANI/BRSKI) certificate. The problem is (A): > How do you know from multiple GRASP offers which one to trust "most". > Right now we have the model that all nodes are equally trustworthy. > For a good self-organizing solution, it would be alot better to have > mechanisms beyond this. Agreed. We should perhaps look at MUDs for this. I'm biased because I spent the hackathon writing code for a "thing" to send its MUD URL via GRASP to a MUD Manager, which can then fetch and validate the signed MUD file for the "thing" and authorize it accordingly. >> Again - it depends on the threat model. My toy security uses AES and RSA >> and all that good stuff, but if someone presents the right password they >> become universally trusted. I did call it QUick And Dirty Security for >> a reason. > > I don't think this is only a security issue. I think more about a > service quality vetting problem. In my DNS-SD -> GRASP drafts, i am > just mapping service quality parameter as we did in DNS-SD, but that > model implies tht there is a magic external entity that can assign > consistent service quality parameters aross multiple instances. Like > the magic operator or SDN controller. We do not have self-organization > of this based on e.g.: control loops that measure the service experience > and then dynamically update the service quality parameters. Yes, lots to be done still. > >> (As for PFS, I don't see how that works for unsolicited multicasts. >> Clearly once you start a new session, you could regenerate keys. But >> for multicasts I think a shared key is unavoidable, isn't it?) > > The discovery is only has domain-membership-group-security. Right. But in GRASP there are only two things that you can learn from multicasts: Node A is looking for a node that supports Objective X, or Node B is flooding the value of objective Y to everybody (which is the purpose of flooding). A group security model seems reasonable for that. > But once > you build a p2p connection, your security association mechanism should > ensure PFS. Which means that as soon as you start talking to a > particular peer you will be sure you will continue to talkk only to that > peer and can not be interepted by another peer. Most TLS options > offer PFS. I am just not 100% sure right now if any simple DH step > already is sufficient for PFS. Ack Brian > > Cheers > Toerless > >> Regards >> Brian >> >> On 14-Nov-19 16:40, Toerless Eckert wrote: >>> On Thu, Nov 14, 2019 at 04:20:16PM +1300, Brian E Carpenter wrote: >>>> On 14-Nov-19 14:49, Toerless Eckert wrote: >>>>> So.. in the ACP document, the hop-by-hop GRASP connections across >>>>> the ACP are using TCP because there is no added benefit of TLS >>>>> given how the connection is to a direct neighbor to which the >>>>> ACP already uses the secure channel encryption (e.g.: IPsec). >>>>> End-to-end GRASP connections across the ACP are expected to use TLS. >>>> >>>> Assuming we are worried about MITM attacks by other nodes enrolled >>>> in the ACP, yes. But if that isn't part of the threat model, TLS >>>> isn't really needed there. >>> >>> Actually that was what trickled through during IESG security review. >>> Without the end-to-end encryption one could argue that the the simple >>> "trust every node in the ACP equally" would not really be a sufficient >>> basis for GRASP apps to exchange all type of probably mutually >>> confidential app-data. Hence the move of end-to-end GRASP connections >>> across ACP to TLS. >>> >>>>> So, i would argue that the peer-to-peer communication of GRASP >>>>> across ACP is a secure session layer. Just the discovery by >>>>> its nature requires to trust the third party mitigating the >>>>> discovery. Because we're doing hop-by-hop forwarding this means >>>>> discovey needs to trust the intermediate GRASP ACP nodes. If we had >>>>> a client-server model, (e.g.: unicsat DNS servers), we'd have to >>>>> trust those servers. >>>>> >>>>> So i am not quite sure what you suggested to change. >>>> >>>> Remember that I started this 3 weeks ago because I got bored >>>> waiting for the real ACP. Running code, right? My first step was >>>> to add shared-key encryption to *all* GRASP packets. My second >>>> step was to use a Diffie-Hellman exchange to safely spread those >>>> shared keys. > All I've done now is add a new option where you use >>>> GRASP discovery to find a server and a GRASP request message to >>>> start a session. In effect, GRASP hands the socket over to you >>>> (encrypted or not). >>> >>> Who am i ? ("hands the socket over to you") >>> >>>> It could work exactly the same if GRASP >>>> was using TLS sockets. I'm sure you suggested something like that >>>> a couple of years ago. >>>> >>>> Server: wait for GRASP M_REQ_NEG >>>> do forever: >>>> grasp.grecv() >>>> grasp.gsend() >>>> >>>> Client: discover peer (GRASP M_DISCOVERY etc) >>>> send GRASP M_REQ_NEG >>>> do forever: >>>> grasp.gsend() >>>> grasp.grecv() >>> >>> Sounds like being on the way to some form of lightweight security >>> substrate instead of ACP. >>> >>> What you should try to achieve is to go from the shared secrets to PFS >>> for the encrypted P2P connection. DH seems like the usual tool here >>> but i am not sure i understand the complete mechanism you implemented. >>> >>>>> Maybe in the generic case of an undefined "secure transport substrate" >>>>> below GRASP you give the app the option whether or not to encrypt ? >>>> >>>> I'm not suggesting that we should formally add encryption to GRASP. It's >>>> not a game for amateurs. Remember that the main issue we have is insecure >>>> multicast, which is why GRASP is defined only to use LL multicast. If DTLS >>>> supported multicast, things could be different, But yes, we could choose to >>>> handle this explicitly - it's really an implementation and API issue. >>> >>> In my previous email i tried to explain how this is not an issue >>> of insecure multicast but the fundamental fact that you need to trust >>> a discovery mechanism as a third-party anyhow. The main novel issue we >>> have in ACP is that we have no well-known unique identifies of peers. >>> Aka: i don't think trying to encrypt discovery would add more security. >>> >>>>> Maybe i am confused ? >>>> >>>> Maybe my explanations are confused. You can see examples testclient.py >>>> and testserver.py at https://github.com/becarpenter/graspy >>>> >>>> I will be arriving Friday evening in SG and will likely hang around the >>>> hackathon. >>> >>> Yep, lets talk in person. Body will arrive also fri evening. After >>> 17.5 hours flight, not sure about the mind though ;-) >>> >>> Cheers >>> Toerless >>> >>>> Regards >>>> Brian >>> > From nobody Sun Nov 17 06:44:34 2019 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 A3B8F12006D; Sun, 17 Nov 2019 06:44:32 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <157400187259.20747.10050349799394092606@ietfa.amsl.com> Date: Sun, 17 Nov 2019 06:44:32 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-30.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 14:44:33 -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 Toerless Eckert Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-30.txt Pages : 117 Date : 2019-11-17 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. 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 deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. 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-30 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-30 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-30 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 Sun Nov 17 08:15:51 2019 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 E4BFA120123; Sun, 17 Nov 2019 08:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rzgFT-LIVHPT; Sun, 17 Nov 2019 08:15:49 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69F912006D; Sun, 17 Nov 2019 08:15:48 -0800 (PST) Received: from dooku.sandelman.ca (unknown [118.201.227.138]) by relay.sandelman.ca (Postfix) with ESMTPS id DCE961F450; Sun, 17 Nov 2019 16:15:45 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 02FB21295; Sun, 17 Nov 2019 21:06:50 +0800 (CST) From: Michael Richardson To: Roman Danyliw cc: Christian Huitema , "draft-ietf-anima-bootstrapping-keyinfra\@ietf.org" , "tte+ietf\@cs.fau.de" , "anima\@ietf.org" , The IESG , "anima-chairs\@ietf.org" In-reply-to: <359EC4B99E040048A7131E0F4E113AFC01E709807E@marchand> References: <157127457937.7863.815173980398917672.idtracker@ietfa.amsl.com> <8262.1571345790@dooku.sandelman.ca> <359EC4B99E040048A7131E0F4E113AFC01E709807E@marchand> Comments: In-reply-to Roman Danyliw message dated "Tue, 05 Nov 2019 23:19:32 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 17 Nov 2019 21:06:49 +0800 Message-ID: <1137.1573996009@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2019 16:15:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Roman Danyliw wrote: > NEW: > With consumer-oriented devices, the "call-home" mechanism in IoT > devices raises significant privacy concerns. See [livingwithIoT] and > [IoTstrangeThings] for exemplars. The Autonomic Control Plane (ACP) > usage of BRSKI is not targeted at individual usage of IoT devices, but > rather at the Enterprise and ISP creation of networks in a zero-touch > fashion where the "call-home" represents a different class of privacy > and lifecycle management concerns. I've used your suggested text in -30. > > ** Section 10.7. Per =E2=80=9CIt is anticipated that specialist se= rvice > > providers will come to exist that deal with the creation of voucher= s in > > much the same way that many companies have outsourced email, > > advertising and janitorial services.=E2=80=9D, I don=E2=80=99t thin= k this is a fair > > analogy. Delegating the voucher process to an entity would take ac= tive > > cooperation of the manufacturer. If the manufacture is out of > > business, there is not guarantee this would have been put in place = (or > > those assets were acquired in the liquidation) > >> Recent changes remind that the manufacturer needs to escrow their >> keys. If the manufacturer is out of business, then where will you g= et >> security updates from? Do you want to enable a secondary market for >> devices with decade old security holes? > I'm questioning the analogy to advertising or janitorial services. To > me, both of these examples are instances of a service being provided = to > the existing company rather than demonstrating how asset hand-off or > continued maintenance would occur in the case of > bankruptcy/liquidation. It has been standard practice in every non-open source software organzation= I have ever worked at (going back to 1993) to dump software build trees to backup media and escrow that to a lawyer. That used to be to 150M QIC tapes at the time, and I used to have a filing cabinet of the second copy of these thing= s. I don't see why the MASA keys wouldn't be part of Business Continuity backups, and that any Hardware Security Modules that would contain critical= keys like this would be duplicated along with the software escrow. If the company dies so catastrophically that even that is gone, then there won't be any more security patches either, and maybe the device OUGHT to be replaced. Customers are sometimes SOL when they deal with companies like that... Having said that, Nortel Contivity VPN boxes were still in use at gc.ca years after Nortel died, and may still be running now. Someone got the tapes and was contracted to do patches is what I heard. Noting that without the MASA keys, you can't do autonomic enrollment for a device that has lost it's configuration and had to go through factory default, or if you pull spare equipment out of cold storage. You can still plug in a console cable and tell it bootstrap from a specific IP, which is what you'd have to without BRSKI. If it's a $3 smartlightbulb, and the company went under, maybe that's regretable landfill. If you had 100,000 of them in the warehouse, well... that's government procurement :-) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3RRekACgkQlUzhVv38 QpBM9ggAje7VMmwJruYn/ohayq7zQkiD+RTd1I57+lWHa1+7PV0U2ZU3wi66Bdi+ 5TyOQhRmYH8xpBPJxwDUuvvn09oTPfwgRh+9eBRg3qaieKiF6kIfetMPE5B8zkcy Jkvb1p0FQ22j7VOIkunbtzHpFTD0SOfpVpXt2yD2AiXMu1sLvBw53t9c39nRtX3c 30d+2VXTt7pJWbUs2KpfsyORWkBaEQiim/Jkn1UK57a0DLMczBm6eyMsF0sXdHJ2 4Mi+OHtda9KpK08P5sDJdA7Ul3W50c0udifLvIRBEuWCZqm16ceWy8eEFLoHE6ec l4zROUNPt/i2giRAxKaALQ6bnGiZRw== =hFSM -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 17 18:17:10 2019 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 4AA02120843 for ; Sun, 17 Nov 2019 18:17:09 -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, SPF_HELO_NONE=0.001, 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 qoX5VQq7O8xZ for ; Sun, 17 Nov 2019 18:17:07 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCDE120048 for ; Sun, 17 Nov 2019 18:17:07 -0800 (PST) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:128:1ca0:aaff:fe40:7c9]) by relay.sandelman.ca (Postfix) with ESMTPS id D0EA21F450; Mon, 18 Nov 2019 02:17:05 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2A6BCD4A; Mon, 18 Nov 2019 10:17:04 +0800 (+08) From: Michael Richardson To: anima@ietf.org, Roman Danyliw , kaduk@mit.edu, Alissa Cooper In-reply-to: <157400187259.20747.10050349799394092606@ietfa.amsl.com> References: <157400187259.20747.10050349799394092606@ietfa.amsl.com> Comments: In-reply-to internet-drafts@ietf.org message dated "Sun, 17 Nov 2019 06:44:32 -0800." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 18 Nov 2019 10:17:04 +0800 Message-ID: <19529.1574043424@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-30.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2019 02:17:09 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I believe that -30 of BRSKI resolves: 1) comments from Roman. 2) comments from Ben. 3) the YANG DOCTOR review that Alissa pointed to. Slides posted at for this week's meeting: https://datatracker.ietf.org/doc/slides-106-anima-sessa-brski-draft-ietf= -anima-bootstrapping-keyinfra-status-slide/ that outline the changes between -24 and -30. internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyin= fra/ > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-30 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-= keyinfra-30 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-anima-bootstrapping-ke= yinfra-30 > 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/ > _______________________________________________ Anima mailing list > Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3R/x8ACgkQlUzhVv38 QpBjxQf/YO6q3m2qi9w8KqmEGXVJdy8p094KotY9BsEDci6MXPZs+0NXv0IsEUWo BV1SnKE0RQBOaZZKKPfaY2vIj872DrP4rz8hOt17hiodgM5xc0FeC7mo/Nv6Smok pCu/0d+WH0rzVC3sPQwjzPau0emXxQ2uxHJLzNkwpRmiLRtR7JRXwXARFp5uCGTy NmyGW9g98tYXbMek7YzQoz5ebR2uurjzAk/1LDzmx9K4IorHKK+6yaibUpaT4ctA am+6F6ZMYh1QttlB1RPOOJ3R6YapbCLl6Us/hQ//KDWHqgjxlPuwWhHEfUwHObuS +tbLLTrcJcioVsXArD6fEoFczAEQow== =gXsq -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 17 21:13:18 2019 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 C5D9412085E for ; Sun, 17 Nov 2019 21:13:16 -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, SPF_HELO_NONE=0.001, 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 2qwvWQkUEN21 for ; Sun, 17 Nov 2019 21:13:15 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65496120837 for ; Sun, 17 Nov 2019 21:13:14 -0800 (PST) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:128:1ca0:aaff:fe40:7c9]) by relay.sandelman.ca (Postfix) with ESMTPS id 1AE4C1F450; Mon, 18 Nov 2019 05:13:13 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id CFB6310EF; Mon, 18 Nov 2019 13:13:11 +0800 (+08) From: Michael Richardson To: Toerless Eckert cc: anima@ietf.org In-reply-to: <20191117063158.GC56410@faui48f.informatik.uni-erlangen.de> References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> <20191117063158.GC56410@faui48f.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Sun, 17 Nov 2019 07:31:58 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26754.1574053991.1@dooku.sandelman.ca> Date: Mon, 18 Nov 2019 13:13:11 +0800 Message-ID: <26755.1574053991@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] some comments about ACP connect X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2019 05:13:17 -0000 Toerless Eckert wrote: > Given how i may not 100% observe the github, make sure you also send > email when oyu have proposed fixes. Please also use the latest xml on > datatracker as the authoritative soucrce. I already missed one github > feedback from you earlier. I apologize, but i am not the fluent github > user yet. I suggest that you take the files off of github then :-) From nobody Mon Nov 18 02:29:24 2019 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 D1D161200DF; Mon, 18 Nov 2019 02:29:21 -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, SPF_HELO_NONE=0.001, 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 GJcuR0eRCnIW; Mon, 18 Nov 2019 02:29:19 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8B912086E; Mon, 18 Nov 2019 02:29:18 -0800 (PST) Received: from dooku.sandelman.ca (dhcp-8d1f.meeting.ietf.org [31.133.141.31]) by relay.sandelman.ca (Postfix) with ESMTPS id 744B01F450; Mon, 18 Nov 2019 10:29:17 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id DA65310F5; Mon, 18 Nov 2019 18:29:15 +0800 (+08) From: Michael Richardson To: acme@ietf.org, anima@ietf.org In-reply-to: <157406527667.20996.1127775260958916507.idtracker@ietfa.amsl.com> References: <157406527667.20996.1127775260958916507.idtracker@ietfa.amsl.com> Comments: In-reply-to I-D Expiring System message dated "Mon, 18 Nov 2019 00:21:16 -0800." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 18 Nov 2019 18:29:15 +0800 Message-ID: <5758.1574072955@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] I-D was expired X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2019 10:29:22 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I-D Expiring System wrote: > was just expired. This draft is > in the state "I-D Exists" in the Datatracker. I just wanted to say that this was intentional on the part of Kathleen and = I. We don't see any further value to this document, which just explained how things fit together and created no new requirements, bits-on-a-wire, or protocols. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3ScnsACgkQlUzhVv38 QpA3DAf/cM7DTzjqiwdVU2hrUg7XYIzF51a947Ae8OmJv3H7yYSe/u//Q93p7H// rXnpnxHGTJLIhtTpiah3l4Rw131gIildJq9zljO96Z+K6vGYDG6d+X3RC2eJhA6n iDS2ulEG/SgihM4gAUVk4lsViuRIIGaJ06grLGRCRWp6nOhG7z6qVlNNtDft+y0+ P8SnREpNe1ZqIrdsrRwq5WN3gIFu5CAnRH+toKh9jxbhGGh2lZRQfKgpg7gTtkGN g1lXmLBWC05j3d6EHWKk241y4/ollIPkAa8ED+NYyh1Wbfr+AG53Kd+On3yjFc+a R7vf92yfbYfoT51IJ0/tGlqH5kRx+Q== =Nduq -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 18 04:57:45 2019 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 E0E81120933; Mon, 18 Nov 2019 04:57: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_HELO_NONE=0.001, 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 zHu2Q-GjF1zr; Mon, 18 Nov 2019 04:57:37 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 21A1A120938; Mon, 18 Nov 2019 04:57:37 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id q70so14235371qke.12; Mon, 18 Nov 2019 04:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=IXvMcfCWrAJB9o11E75AD9kNBUZmWj0buapDdXljIZQ=; b=hVEmmsbI/nned6wDKYcHl1AYhAx4PBjh4iaqFXER5yNQ6xctzZCunREF2Ac4mxyK51 n5mg3F9wEyiBl/k9gU53d4R+r7PH+JBx9IW8D8mgrx9eaYeahkz8mHmhxkW/Z/TiBqWM xO9o5VYKr/mjumt6xGjUoSV07Hdvi0faANu7xc51aH9VpSO0a4jBWuytJjys2p2GUvG5 OyKlGpdI+mYQFAZxROyP4ZRrhs1ZuHYvOzfmueEcHGSs2VaHnlhKcKZsGStEZ4A2dIzm j+6LBTKo6VgzJpzLMBbHcd9i6tvEaHqWTzweslMA7e8H56i31/0mJf19Hul1NPaTN8hg BlzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=IXvMcfCWrAJB9o11E75AD9kNBUZmWj0buapDdXljIZQ=; b=Py0ec1D262EX5jEP3SM8HbEAUTYS/fhKh+XQBk/ouZN+DspDOYT74xg5+772wf5Adl 6O6Si6SPHU3VzvsogolPXr+nvTLtKyx7KmHG+KQOQgy42ttPrLBtV2RSlALhAKnmAKKC j4lxRauR4+VweMNu6+P4AwqPOMvyjq4SLhBZfwludmLs8IXYV3dxjcCAMxFYYLqUOTI8 4sN+AMObSVzcmIgj+e8quRj8HnWfgtRLtj+hRFdxe74BVcKB/VamwtKqjxKcGW9G9C3I 52MDm5S3rWqMUkQHkvAjlevxpSn2V/FjU0E8vjqH9Xnx+tcjL+1Sy6izuaoL2fOt8bSp Y8gg== X-Gm-Message-State: APjAAAV4GMyMFN2gAH96wI5UoRQ6GA9NBvWVfjyQNde1ZfuUEZs+yDhr SeoY6kh09+eTVFXAw2XAintJIc9Lv80= X-Google-Smtp-Source: APXvYqzvpg88WPRV+Jz8sFQsLk7EzSxJYwmxM9VKpqhm5m/S7vaDafEPPUMWu2gkj6wb+Ja3Cfnang== X-Received: by 2002:ae9:c30e:: with SMTP id n14mr24150191qkg.24.1574081856013; Mon, 18 Nov 2019 04:57:36 -0800 (PST) Received: from [192.168.1.4] (146-115-73-78.s5196.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.73.78]) by smtp.gmail.com with ESMTPSA id 11sm10102001qtx.45.2019.11.18.04.57.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Nov 2019 04:57:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kathleen Moriarty Mime-Version: 1.0 (1.0) Date: Mon, 18 Nov 2019 07:57:34 -0500 Message-Id: <439BE8C4-B824-41C2-A40E-21AAC1B4EA9C@gmail.com> References: <5758.1574072955@dooku.sandelman.ca> Cc: acme@ietf.org, anima@ietf.org In-Reply-To: <5758.1574072955@dooku.sandelman.ca> To: Michael Richardson X-Mailer: iPhone Mail (17A878) Archived-At: Subject: Re: [Anima] [Acme] I-D was expired X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2019 12:57:39 -0000 Sent from my mobile device > On Nov 18, 2019, at 5:29 AM, Michael Richardson wr= ote: >=20 > =EF=BB=BF > I-D Expiring System wrote: >> was just expired. This draft is >> in the state "I-D Exists" in the Datatracker. >=20 > I just wanted to say that this was intentional on the part of Kathleen and= I. > We don't see any further value to this document, which just explained how > things fit together and created no new requirements, bits-on-a-wire, or > protocols. Yes, thank you. With that said, I believe a question is on the agenda to se= e if anyone thinks it=E2=80=99s useful. If it is, then we can do more work o= n it. If not, we=E2=80=99re happy to leave it as an expired draft. Best regards, Kathleen=20 >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh networ= ks [=20 > ] Michael Richardson, Sandelman Software Works | network architec= t [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 > =20 >=20 >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Mon Nov 18 23:59:41 2019 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 9E54112080B for ; Mon, 18 Nov 2019 23:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 ULT2LHKAS2Yf for ; Mon, 18 Nov 2019 23:59:35 -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 ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1BF6120088 for ; Mon, 18 Nov 2019 23:59:34 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 10B61548016; Tue, 19 Nov 2019 08:59:28 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0C823440055; Tue, 19 Nov 2019 08:59:28 +0100 (CET) Date: Tue, 19 Nov 2019 08:59:28 +0100 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org Message-ID: <20191119075928.GA36155@faui48f.informatik.uni-erlangen.de> References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> <20191117063158.GC56410@faui48f.informatik.uni-erlangen.de> <26755.1574053991@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26755.1574053991@dooku.sandelman.ca> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] some comments about ACP connect X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2019 07:59:39 -0000 On Mon, Nov 18, 2019 at 01:13:11PM +0800, Michael Richardson wrote: > Toerless Eckert wrote: > > Given how i may not 100% observe the github, make sure you also send > > email when oyu have proposed fixes. Please also use the latest xml on > > datatracker as the authoritative soucrce. I already missed one github > > feedback from you earlier. I apologize, but i am not the fluent github > > user yet. > > I suggest that you take the files off of github then :-) Nah, github is perfectly fine as a great storage location without necessarily succumbing to the single-file diff-version management terror ;-) Kidding aside: I will improve in my skills to master this, just takes time. From nobody Sat Nov 23 23:28:48 2019 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 773F21200DF for ; Sat, 23 Nov 2019 23:28:47 -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, SPF_HELO_NONE=0.001, 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 W2bB8nGw1Y1I for ; Sat, 23 Nov 2019 23:28:45 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B93B1200D7 for ; Sat, 23 Nov 2019 23:28:44 -0800 (PST) Received: from dooku.sandelman.ca (eth-west-pareq2-46-193-2-123.wb.wifirst.net [46.193.2.123]) by relay.sandelman.ca (Postfix) with ESMTPS id 2AC791F47D for ; Sun, 24 Nov 2019 07:28:41 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 186F99D1; Sun, 24 Nov 2019 15:28:44 +0800 (+08) From: Michael Richardson To: "anima\@ietf.org" In-reply-to: References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> Comments: In-reply-to "Owen Friel (ofriel)" message dated "Thu, 07 Nov 2019 11:47:55 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 24 Nov 2019 08:28:44 +0100 Message-ID: <28576.1574580524@dooku.sandelman.ca> Archived-At: Subject: [Anima] Cloud BRSKI discussion -- Option 1 use cases X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2019 07:28:47 -0000 --=-=-= Content-Type: text/plain Following up on the discussion at the WG meeting. The meeting materials are not yet converted to PDF, but let me attach the three pictures, and start three threads on these options, and also I will insert the ascii art from the document itself. All three: https://github.com/anima-wg/brski-cloud/blob/master/presentations/three-flows.png In all cases the Pledge gets some kind of network connectivity. This could be an open WiFi, but is more often a cable plugged in with DHCPv4/IPv6. 1) Cloud Registrar Redirects This is the most non-cloudy of the solutions. The time sequence is below, and the diagram is at: https://github.com/anima-wg/brski-cloud/blob/master/presentations/option-1-cloud-redirect.png +--------+ +-----------+ +----------+ | Pledge | | Local | | Cloud RA | | | | Registrar | | / MASA | +--------+ +-----------+ +----------+ | | | 1. Full TLS | |<----------------------------------------------->| | | | 2. Voucher Request | |------------------------------------------------>| | | | 3. 3xx Location: localra.example.com | |<------------------------------------------------| | | | 4. Provisional TLS | | |<-------------------->| | | | | | 5. Voucher Request | | |--------------------->| 6. Voucher Request | | |------------------------->| | | | | | 7. Voucher Response | | |<-------------------------| | 8. Voucher Response | | |<---------------------| | | | | | 9. Validate TLS | | |<-------------------->| | | | | | 10. etc. | | |--------------------->| | This is the simplest variation, the local registrar is simply not discoverable from the location of the Pledge. The pledge is told of a way to reach the intended Registrar and process proceeds as normal. Note that the registrar still has to be proven by voucher. There could be attacks on the pledge via DNS. This flow does not work at all for devices/manufacturers with poor supply integration, as the Cloud RA would have no idea where to redirect the device. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3aMSsACgkQlUzhVv38 QpCsDggAm2N6ZTg1ylykBokBVDhfOPlfIMJQQOCAX5isquykgPoysLKPZzvqCsTk Tf94TWI2BoDm3s//ju9yY8mEaz3+Bug532w2cMGa+m0QL7JPfAUWnrXHuzGm5hHI Xx/oYE+aCvSbgJSksRVG/RLSfEKZlO3Kpdn+Z7+AOhrlGI7avrEjsW6qXk/j9wl0 GNa+LflKXSvPVO/ewblq20zJdtSlgim3A2QPrEySrym3URSmiftz4hXyU0xPhq5W 6JkTMS3dXQ3yEaaj+xs8JgdoIXlzo6Neehw3HqsShOumDrMOBGRm0V/CuQ5iuBdL aQxPtmxWqZz7aMuAZFsywDziknYXaA== =fUBm -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 23 23:36:48 2019 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 E2D9A12002E for ; Sat, 23 Nov 2019 23:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rUgyBDabrfuh for ; Sat, 23 Nov 2019 23:36:46 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F14120025 for ; Sat, 23 Nov 2019 23:36:46 -0800 (PST) Received: from dooku.sandelman.ca (eth-west-pareq2-46-193-2-123.wb.wifirst.net [46.193.2.123]) by relay.sandelman.ca (Postfix) with ESMTPS id D0C7E1F47D for ; Sun, 24 Nov 2019 07:36:44 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0D4AB9D1; Sun, 24 Nov 2019 15:36:48 +0800 (+08) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 24 Nov 2019 08:36:48 +0100 Message-ID: <28737.1574581008@dooku.sandelman.ca> Archived-At: Subject: [Anima] Cloud BRSKI discussion -- Option 2 use cases - Enroll Redirect X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2019 07:36:48 -0000 --=-=-= Content-Type: text/plain Following up on the discussion at the WG meeting. All three: https://github.com/anima-wg/brski-cloud/blob/master/presentations/three-flows.png In all cases the Pledge gets some kind of network connectivity. This could be an open WiFi, but is more often a cable plugged in with DHCPv4/IPv6. 2) Cloud Registrar Issues Voucher, Home RA issues LDevID (Note that the document has 7.2 having "Option 1", "Option 2", "Option 3". They are out of sync with the presentation) This is involves all the BRSKI mechanism occuring in the cloud, but the local domain still having a CA. The CA could be a pure EST (RFC7030) with no BRSKI extensions. The diagram is at: https://github.com/anima-wg/brski-cloud/blob/master/presentations/option-2-enroll-redirect.png 7.2.2 proposes to do this with the enroll getting a 3xx (probably 307) code: +--------+ +-----------+ +----------+ | Pledge | | Local | | Cloud RA | | | | Registrar | | / MASA | +--------+ +-----------+ +----------+ | | | 1. Full TLS | |<----------------------------------------------->| | | | 2. Voucher Request | |------------------------------------------------>| | | | 3. Voucher Response | |<------------------------------------------------| | | | 4. EST enroll | |------------------------------------------------>| | | | 5. 3xx Location: localra.example.com | |<------------------------------------------------| | | | 6. Full TLS | | |<-------------------->| | | | | | 7. EST Enrol | | |--------------------->| | | | | | 8. Certificate | | |<---------------------| | | | | | 9. etc. | | |--------------------->| | 7.2.3 proposes to do this with the voucher providing the address of the EST server. +--------+ +-----------+ +----------+ | Pledge | | Local | | Cloud RA | | | | Registrar | | / MASA | +--------+ +-----------+ +----------+ | | | 1. Full TLS | |<----------------------------------------------->| | | | 2. Voucher Request | |------------------------------------------------>| | | | 3. Voucher Response {localra:fqdn} | |<------------------------------------------------| | | | 4. Full TLS | | |<-------------------->| | | | | | 5. EST Enrol | | |--------------------->| | | | | | 6. Certificate | | |<---------------------| | | | | | 7. etc. | | |--------------------->| | In both cases, the voucher response provides a pinn of the Local Registrar. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3aMw8ACgkQlUzhVv38 QpC1JQf+NYdhy6nbbUGKu/IhihA2i7xFX0KMiFXhPz2ZFOdzqEbVgaDoO1Qoghg3 f4f3fQlHMk/6W8it8pFHxebCf0zoCRsHV9+U02tYxvvKd6UwIpOfvrXgeQlKYFu/ Cxtclz2D3Ux+s61qTgcfSt+Y4mlXaVi/dEcYPJnqgi/5LuWXD0iPRyahnwytAmbS 61VcXFQ6tLeDmFPAwxUmKDUTsS02y5U13bG6xve37Y21eYHu7lzsVMVxctJe+m/3 8usi+BBzlUSbP+2dfqJ+WGDaGgZ3VsihUlvS7QNEE+uXPCTHfydhiWL8YJy0Vtsw e3Q/Ye+rxiZ9zrv7rvckIzI2AevH4w== =3+4l -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 23 23:40:34 2019 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 2B69E120044 for ; Sat, 23 Nov 2019 23:40:33 -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, SPF_HELO_NONE=0.001, 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 XjPmZzt3yab9 for ; Sat, 23 Nov 2019 23:40:31 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185A5120025 for ; Sat, 23 Nov 2019 23:40:31 -0800 (PST) Received: from dooku.sandelman.ca (eth-west-pareq2-46-193-2-123.wb.wifirst.net [46.193.2.123]) by relay.sandelman.ca (Postfix) with ESMTPS id C56261F47D for ; Sun, 24 Nov 2019 07:40:29 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id E803D9D1; Sun, 24 Nov 2019 15:40:32 +0800 (+08) From: Michael Richardson To: "anima\@ietf.org" X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 24 Nov 2019 08:40:32 +0100 Message-ID: <28811.1574581232@dooku.sandelman.ca> Archived-At: Subject: [Anima] Cloud BRSKI discussion -- Option 3 use cases - Enroll to the Cloud X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2019 07:40:33 -0000 --=-=-= Content-Type: text/plain Following up on the discussion at the WG meeting. All three: https://github.com/anima-wg/brski-cloud/blob/master/presentations/three-flows.png In all cases the Pledge gets some kind of network connectivity. This could be an open WiFi, but is more often a cable plugged in with DHCPv4/IPv6. 3) Cloud issues voucher, Cloud issue registrar This is section 7.2.1 in the ocument. This is involves all the BRSKI mechanism occuring in the cloud, including the use of EST onboarding. The diagram is at: https://github.com/anima-wg/brski-cloud/blob/master/presentations/option-3-cloud-only.png 7.2.1: +--------+ +-----------+ +----------+ | Pledge | | Local | | Cloud RA | | | | Service | | / MASA | +--------+ +-----------+ +----------+ | | | 1. Full TLS | |<----------------------------------------------->| | | | 2. Voucher Request | |------------------------------------------------>| | | | 3. Voucher Response {service:fqdn} | |<------------------------------------------------| | | | 4. EST enroll | |------------------------------------------------>| | | | 5. Certificate | |<------------------------------------------------| | | | 6. Full TLS | | |<-------------------->| | | | | | 7. Service Access | | |--------------------->| | Note that this all activity occurs with the Cloud RA. In the case where the customer has a Registrar in a multi-tenant cloud service, that this is really option 1, because there is a redirect. This is closest to what current single-vendor verticals (e.g. Azure, Amazon, etc.) do today for onboarding, in that the customer is never actually represented. The certificate might be ACME. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3aM/AACgkQlUzhVv38 QpC01wf+PX5fY6FPeBIG1/1Wbl+wLi2EcifJZsBdRtE4f/gEWc5FhFqac/MOv+EC g7zhqwuWnIQc2sf5ygZaNs+L68Men/bJe5z44uCc24rVFtMR4PceAIUg5c9Hm20z 0Eg72FxIdpHWGy0L4MX+qU0hdvw/g3PFRI0MtYrrkAm7V6NJePy/SnBiMr3d3v5d xU7i07iphvASb/CW/QoCq3zN2d2s4IeSvAHio+rlKxpWPhE+b/mqLsMjHl5IWxpU zNjik/SQmcoZ1mUiPXCLPHKX0azun0kg9uYQj5arHkycwvsgS3SUtdc0MkozWKFi 5cktBVAaNsTmxydQFyJK1HHrBqQFeg== =dei1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 24 00:22:53 2019 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 0CB121200FF for ; Sun, 24 Nov 2019 00:22:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 SolzymdjDW9t for ; Sun, 24 Nov 2019 00:22:50 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 538B71200FE for ; Sun, 24 Nov 2019 00:22:50 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id p26so5742211pfq.8 for ; Sun, 24 Nov 2019 00:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fDukq7mobfgQeNh6/5ifDlru5bNvAJ1J42gkPZslBO4=; b=VCd2QHs/a9W4GC6YY/snkppWiU2PvqDj8ffwT0Bjsp2UNAmjGbHF0VQ6kqZj9jDaDz QlpTOErRUc2HMMpOx2fI3hyhtNSCfMDD+bcr2SpTBoSeRFcU7OEchnXBK8Ld/dAulkxo xcSxL4563GWUc6XUaEzGQnY8Az4MhzQF87nQ+oMuqyB5Xf4yoCWvw66ysI8Hzd1bqoHR VbFU5/ifMF+E9eiof9WaS6mZF1jdWy6biwZds7B0fSNtPRclWwV5vIBkb0dHNSVk/NEk HNTWZJk7mJLI0CF4vk0n4YK1qw8BvSPOEi25bKQpzz/eU0IGo7+tAQPVig1KTAIRq0rx qluA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fDukq7mobfgQeNh6/5ifDlru5bNvAJ1J42gkPZslBO4=; b=k3h8Mxdqu60teXOXwNQs5sSZbU8bFH1IAdaMyMUEmWMSXOkCggDU8VVdE71ITv1avK Lth+AcdJkzTO9dl8pfJuiFZZIPC8LepSCTbNRCRjJFBYhejiCOdI0v6x2MABnOIWI21n XHNfqqjPVr44jhrvLZ3i800nQp+pcBvVdmgBqykZPGO0SSth5HB3mkFTWIJp7n1Lc5Q0 9Wbfg0CjvqEbVKx96O4KMs12MEtNhyTWweXgaFMLHB+7gPwJACFX84Wc7NehqZnkQWW2 yRVmMivci8qWHbWQlMJ8PtpjR9JrU9GlpBnmYcjT94vUsrbqIkOsMcW3v85nkZ98M6pl QlrQ== X-Gm-Message-State: APjAAAUTNF4qcSm3kmkDjFvrrucv7XVbom43Aib3jPka9f82KcbZ0TlE /dR27cAvfUQ2+NGymIuKaracuszVHC8= X-Google-Smtp-Source: APXvYqwbhyZuPmI96FVmMDFO6UtR+ybNQKqCi2YhW8+nFApGSDvqS39y363k/mOv43HtPDv9Mr+BYA== X-Received: by 2002:a63:5920:: with SMTP id n32mr9185493pgb.359.1574583769387; Sun, 24 Nov 2019 00:22:49 -0800 (PST) Received: from [192.168.9.49] ([111.223.108.130]) by smtp.gmail.com with ESMTPSA id y4sm3728054pfn.97.2019.11.24.00.22.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Nov 2019 00:22:48 -0800 (PST) To: Michael Richardson , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <28576.1574580524@dooku.sandelman.ca> From: Brian E Carpenter Message-ID: <9c60c895-9e14-c064-9f4a-306c5d7a1105@gmail.com> Date: Sun, 24 Nov 2019 21:22:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <28576.1574580524@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 24 Nov 2019 08:22:52 -0000 One thing that doesn't seem to be clear either in BRSKI or in draft-friel-anima-brski-cloud is where the Cloud Registrar's "well known" URI comes from and how the pledge knows it. Is it vendor specific or what? Regards Brian (waiting in Changi) On 24-Nov-19 20:28, Michael Richardson wrote: > > Following up on the discussion at the WG meeting. > The meeting materials are not yet converted to PDF, but let me attach the > three pictures, and start three threads on these options, and also I will > insert the ascii art from the document itself. > All three: > > https://github.com/anima-wg/brski-cloud/blob/master/presentations/three-flows.png > > In all cases the Pledge gets some kind of network connectivity. > This could be an open WiFi, but is more often a cable plugged in with DHCPv4/IPv6. > > 1) Cloud Registrar Redirects > > This is the most non-cloudy of the solutions. The time sequence is below, > and the diagram is at: > https://github.com/anima-wg/brski-cloud/blob/master/presentations/option-1-cloud-redirect.png > > > +--------+ +-----------+ +----------+ > | Pledge | | Local | | Cloud RA | > | | | Registrar | | / MASA | > +--------+ +-----------+ +----------+ > | | > | 1. Full TLS | > |<----------------------------------------------->| > | | > | 2. Voucher Request | > |------------------------------------------------>| > | | > | 3. 3xx Location: localra.example.com | > |<------------------------------------------------| > | | > | 4. Provisional TLS | | > |<-------------------->| | > | | | > | 5. Voucher Request | | > |--------------------->| 6. Voucher Request | > | |------------------------->| > | | | > | | 7. Voucher Response | > | |<-------------------------| > | 8. Voucher Response | | > |<---------------------| | > | | | > | 9. Validate TLS | | > |<-------------------->| | > | | | > | 10. etc. | | > |--------------------->| | > > > This is the simplest variation, the local registrar is simply not > discoverable from the location of the Pledge. > > The pledge is told of a way to reach the intended Registrar and process > proceeds as normal. Note that the registrar still has to be proven > by voucher. There could be attacks on the pledge via DNS. > > This flow does not work at all for devices/manufacturers with poor supply > integration, as the Cloud RA would have no idea where to redirect the device. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Nov 25 01:21:49 2019 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 726661200DE for ; Mon, 25 Nov 2019 01:21: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, SPF_HELO_NONE=0.001, 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 wK1IcuhHZFM2 for ; Mon, 25 Nov 2019 01:21:45 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA93A12006B for ; Mon, 25 Nov 2019 01:21:45 -0800 (PST) Received: from dooku.sandelman.ca (x2f7f413.dyn.telefonica.de [2.247.244.19]) by relay.sandelman.ca (Postfix) with ESMTPS id 1C4BF1F47D; Mon, 25 Nov 2019 09:21:43 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0159513A4; Mon, 25 Nov 2019 17:14:42 +0800 (+08) From: Michael Richardson To: Brian E Carpenter cc: "anima\@ietf.org" In-reply-to: <9c60c895-9e14-c064-9f4a-306c5d7a1105@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <28576.1574580524@dooku.sandelman.ca> <9c60c895-9e14-c064-9f4a-306c5d7a1105@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Sun, 24 Nov 2019 21:22:46 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 25 Nov 2019 10:14:42 +0100 Message-ID: <1120.1574673282@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 25 Nov 2019 09:21:47 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > One thing that doesn't seem to be clear either in BRSKI or in > draft-friel-anima-brski-cloud is where the Cloud Registrar's "well > known" URI comes from and how the pledge knows it. Is it vendor > specific or what? It is vendor specific, and it's baked in. The idea is that we can transform the well-known, but very much proprietary "call-home" process that many devices use today into something that enables a transfer of ownership mechanism. -- ] 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----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3bm4IACgkQlUzhVv38 QpBauwgAgj+uApIe56MkcKJ+fk9MfC1s56iGeAEDgKKJDeMEsmqP3DnyCgR+JtOX mVo8mr8mpWsIrv3ekjcj4rZl66GyDC3Mojm742GTAQ9kDDVatWOzb92QtirD4Z5R jF1jiWzhTK5SR/06dvaieak6jBdoF4eFNW4B0wXWbN//qOv7fE7ou8SszEL8WD7c aV/9/Jrs6WeyBLHZyTl+WTsp1BAK+4jQcZMs+x9MyPuWJJinawdGFqe4U1b4ILjL vCVOlmZyK6WSgr0RCQ+EeySaBrkUXg7GNBIAN7dbcSj6JO3/7u15jWYSQWfIRNPX 2rKFuLTbmDsYYX850ONf6xaKJEFUyQ== =SISi -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 25 11:25:36 2019 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 E18D6120DCB for ; Mon, 25 Nov 2019 11:25:34 -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_HELO_NONE=0.001, 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 alf4X3KjKA1y for ; Mon, 25 Nov 2019 11:25:33 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 64BF3120DC4 for ; Mon, 25 Nov 2019 11:25:33 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id p26so7829323pfq.8 for ; Mon, 25 Nov 2019 11:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=b9AzZNW24rjhe6Eajfdq8lrN6cPlysvOu1LXUI6DAcc=; b=mXW3JcI0xJ+qNu+K20BfF7JJv4FRufth1np+8PLAYzJoTCYCjla+dJqeWc9DghFZZk Ty67KGc3arhsex13ByTsNIQfKuub/jijYH2KXEP1o2BLSleDsWm3RC8rqkpjaQjhUWz0 C5UZS4hcB58Xz6pYUL+uUvCvDOlDZofNbSnbigp3yNYz84QCujaY/9NzT7KmolMSBGf7 9o0fUd4XWCYDOjrJHS5qUkNOLAC5rw6sEi7WwvZqRpbg+eAcCQUhasF9/i7fmTbd+NFA GJMGn40dsldhZfmeVzOBuK+w+F1fvSPM3pPDn2oFAc72kQMzlKZGUrvQpThXPQalB2MA 2+GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b9AzZNW24rjhe6Eajfdq8lrN6cPlysvOu1LXUI6DAcc=; b=ePwCLwGIQx3JK0iMgJS/XbxDP5d1xqE0fX0TGl86e3xFUHC/TzfuQG38WR0vHNVHuU RY6jWLUlEUQZthZzhibC0JvOE/htRaTnLATPo3spDF/SakKPLmmPcS44a4Y2KPgUIUdF dQrgB8IlUuXTygcwHKTO7/3iZsGgOt6LpBNpIarQCl0fjwXgLzuMoLo2a08IYdsWaNv9 ahpTeO057hM8iAZAHiw4lPjl1DjO66naVSc1VOqtXtZo3YKnAmOFyODHOPAUyJ6RgrfD ySKWAt25JGa5NDQTRpn748AYUE0GTOt2esddKb43R3+nxJGZw1b5qsgKIpf/pild/Es2 Talw== X-Gm-Message-State: APjAAAWxEV0ILbkQP/GWhhMWaff9IF1VA0etCqqodnhhP92K5RPxDVJd lqGKxOUBKcTjlysw659olG2QkgZT X-Google-Smtp-Source: APXvYqyaY+mr7vEuCi6E135nqKJ/3i70YwRsEz1m1eqMKgViYaNU2G19p4Sm1NcaS1Mb+KKyPjGahw== X-Received: by 2002:a63:4547:: with SMTP id u7mr24715117pgk.423.1574709932451; Mon, 25 Nov 2019 11:25:32 -0800 (PST) Received: from [192.168.178.30] (8.166.69.111.dynamic.snap.net.nz. [111.69.166.8]) by smtp.gmail.com with ESMTPSA id j21sm8971452pfa.58.2019.11.25.11.25.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2019 11:25:31 -0800 (PST) To: Michael Richardson Cc: "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <28576.1574580524@dooku.sandelman.ca> <9c60c895-9e14-c064-9f4a-306c5d7a1105@gmail.com> <1120.1574673282@dooku.sandelman.ca> From: Brian E Carpenter Message-ID: <29988aee-9b8e-afab-1498-80dcf8b9f6fd@gmail.com> Date: Tue, 26 Nov 2019 08:25:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1120.1574673282@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 25 Nov 2019 19:25:35 -0000 On 25-Nov-19 22:14, Michael Richardson wrote: > > Brian E Carpenter wrote: > > One thing that doesn't seem to be clear either in BRSKI or in > > draft-friel-anima-brski-cloud is where the Cloud Registrar's "well > > known" URI comes from and how the pledge knows it. Is it vendor > > specific or what? > > It is vendor specific, and it's baked in. Thanks. That was my working assumption, but I suggest stating it up front in draft-friel-anima-brski-cloud. > The idea is that we can transform the well-known, but very much proprietary > "call-home" process that many devices use today into something that enables a > transfer of ownership mechanism. Understood. Brian From nobody Tue Nov 26 00:30:14 2019 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 442E6120832; Tue, 26 Nov 2019 00:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 goECkfbyvxPf; Tue, 26 Nov 2019 00:30:12 -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 6F19412003F; Tue, 26 Nov 2019 00:29:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B64A73818F; Tue, 26 Nov 2019 03:26:32 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 65B03613; Tue, 26 Nov 2019 03:29:57 -0500 (EST) From: Michael Richardson To: Alissa Cooper cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; 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] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 26 Nov 2019 08:30:13 -0000 --=-=-= Content-Type: text/plain Hi Alissa, just a reminder that the -30 draft posted during IETF week resolves the Yang Doctor issue that you had raised. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3c4oUACgkQgItw+93Q 3WUe8wgAus3Lup7Snc09Yodzj9CXq/A3g8/xvle39Jmy17R0mxm2LWGLRcryv/K/ mlfop4xDOJAW1e+KYFlqke90YgMwZM42X0M4wdKe4TrwojrdJuxQ5ttDzZeY/6pP x0m29fiouRRFu+824ygZHi3GoIcAPyBR4yM4dPgNNfuaLnD0gu3VTYcBqUNn2uwB s/9WA7EMOcu3PO6i/qndOkgZUZWaIPr63LDXDucC4O91PGWFdfIRde6qB4RrV9N/ 8qsDrc7Fj0eqGwM0o5p+k3qwqPDZhEODjuX9Rs/pQvF/+dbCHKS3KL1+buN9lF26 fYb2Z2SWQOcVKY058RkfUph2PT0bYQ== =/l/y -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 26 00:31:35 2019 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 382E612081B; Tue, 26 Nov 2019 00:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cnZPiX_2-_eI; Tue, 26 Nov 2019 00:31:22 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5BE12081A; Tue, 26 Nov 2019 00:31:18 -0800 (PST) Received: from dooku.sandelman.ca (unknown [194.42.227.53]) by relay.sandelman.ca (Postfix) with ESMTPS id 6ACBA1F47D; Tue, 26 Nov 2019 08:31:16 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 77C80109E; Tue, 26 Nov 2019 16:31:11 +0800 (+08) From: Michael Richardson To: Roman Danyliw , Benjamin Kaduk cc: Christian Huitema , "draft-ietf-anima-bootstrapping-keyinfra\@ietf.org" , "tte+ietf\@cs.fau.de" , "anima\@ietf.org" , The IESG , "anima-chairs\@ietf.org" In-reply-to: <359EC4B99E040048A7131E0F4E113AFC01E709807E@marchand> References: <157127457937.7863.815173980398917672.idtracker@ietfa.amsl.com> <8262.1571345790@dooku.sandelman.ca> <359EC4B99E040048A7131E0F4E113AFC01E709807E@marchand> Comments: In-reply-to Roman Danyliw message dated "Tue, 05 Nov 2019 23:19:32 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Tue, 26 Nov 2019 09:31:11 +0100 Message-ID: <20217.1574757071@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 26 Nov 2019 08:31:28 -0000 --=-=-= Content-Type: text/plain Just a reminder that the -30 draft posted last week resolves, I think, all of your COMMENTS and DISCUSS points. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3c4s8ACgkQlUzhVv38 QpAMcgf/WEbPRZXnmqOQAgKc7QCh3kzQhzMlIMbryKXLg/ZLNIhGQI0nOgLtazjL UUkeXbD8xV7CsyRZ6DqeHylX1qQ0uUtvS6iri7XjEhg0P+RWqoJQN0RJuPfFfZC5 +uqC5WiQAEySwlvppNpB9TOFWfAy89vVv3VI9cubGa3eE8BP+DHNpPdMLykQ2gQ6 lK2ya/3D7TuVqxAiil9y8efMmdZIxwUsOCEleyOdc6PhuXHIkUxip6cg7qi+oUV7 X/fIeXFCWCWz3JhUHIykml34MT04WC20i//JGv+3tIVEeJi+BRRrsTStJKMM/zzd 4yGhlmUI/b/LQKzD1a3F0yPEIZslNQ== =o2R3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 26 13:57:21 2019 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 A4AE5120AF1 for ; Tue, 26 Nov 2019 13:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UsMZQWR0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IvOfoYFd 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 eQZQyP48DcCP for ; Tue, 26 Nov 2019 13:57:17 -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 7E217120AEC for ; Tue, 26 Nov 2019 13:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1861; q=dns/txt; s=iport; t=1574805437; x=1576015037; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GzLWCgeknWSVNiRG/s84aNGjmsu+a4HDYB2G7Ayr1qc=; b=UsMZQWR0op/yaaq9A7vyHrWDMjbekIHKnsBqKRcNtbqjYWTAXJJzpwjQ CCVL5zIG/45znFWK6i2jZTa7x+BN2Dk1YqICoPr8tfaEspLEjbROOygyc 1RsvlIWZepRSp8bMERg5Lbf/jS++TTXCHstRP6Me9omBCImMO+fd9lsBg c=; IronPort-PHdr: =?us-ascii?q?9a23=3AQK2wRxEKIvxwm4/fM1bRKJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efnkdS03GOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAADRnt1d/4wNJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFtAgEBAQELAYFKUAVsWCAECyoKh2cDinCCX4l?= =?us-ascii?q?bjimCUgNUCQEBAQwBARgNCAIBAYRAAoF2JDcGDgIDDQEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhVIBAQEBAgEBARAoBgEBLAsBCwQCAQgRBAEBAR4QIQYLHQgCBAEJBAUIGoM?= =?us-ascii?q?BgkYDDiABAgynKwKBOIhggieCfgEBBYUXDQuCFwmBNgGMFRqBQD+BWIIeLj6?= =?us-ascii?q?CG0kBAQIBgUoYg0CCLI0aKBkDoBhCCoIshx2KIIQ0mh2EP4oJiDyCFI9CAgQ?= =?us-ascii?q?CBAUCDgEBBYFoI4FYcBU7gmwJRxEUhkiDc4UUhT90AYEnjToBgQ4BAQ?= X-IronPort-AV: E=Sophos;i="5.69,247,1571702400"; d="scan'208";a="378880063" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Nov 2019 21:57:15 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xAQLvEB5012291 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Nov 2019 21:57:14 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Nov 2019 15:57:14 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Nov 2019 16:57:13 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Nov 2019 15:57:12 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eUizduNiPy3AHte4onybNYojNygKLJ6lXFScYP+zm3K4FmbHz1KYjFQZlMnLHfHYtH5WTJLxYXBJ+aJSON0kB5PWgiJEfyaHd6fss/foJ9eKHPCPsudUpKud19EnTuupPWFdHAXcbwaOhk0hiJy5+syW5LdIjZXH7jo9xJPHLQeksErNwSHLAZFxeQz3ag4sHsxJTYBurkl0YEcOT9CkZoJfW5O1W1s52+z1CfNAQvFPjcSMo1c5qX51yssppdBoBHj3iU/Vza/CApt95OGGksJyohP2M2qo8vYlh1t36/pPbgwFbqA6rdkqa/lxNG965cJyzsZRizkXsKSWjc7RAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EgismndNCQ97qzysWTJRsH/djSM27zH4NWOuaiNGMHU=; b=C91hGULTim7t4T5NsvdCfX2k9dVNAcSM9EuYMe8mn1DfDH8H9igaQZFueeAegvmMLioNm0l35dB6/dGfjMC3HuKVnNboZQsUpeaCKGhrKemmKs/WI6VFohCpSNU+Jhv8Nqa4baqzc0u5dqNSkdXKL4coxTVK/qjF6Rwjye2L7AtzpE+GRZmyeqCD1ZAC6zis/bWCUdVjJQWIFte2HbC3WF9a0YHCvM47850fTupCbYMoqLtPoScrg/a9w5IIGkptD+3fCA7l5Qc9PCfcEN3p4LLTJQoLWbySVVzcehOyTXiblmVEGvFuszQikojuhafXkLhpCZpIqGF2ZUERO6XWRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EgismndNCQ97qzysWTJRsH/djSM27zH4NWOuaiNGMHU=; b=IvOfoYFdUVnqekpz/vktAPEMi8yPsZiEkrA+/r29D/67ROH0W5hHOxM58GmVA8Wie8lVk12V7rjldG8enfLnqcWpbnZuHYIZSrxwUHZqSPfP6bAFdo9SLQR08TAB72Q1tSWzcd5zam8VHMKz0wgCYbKxJe7M2BvvN3qpcYk83C0= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3806.namprd11.prod.outlook.com (20.178.254.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.19; Tue, 26 Nov 2019 21:57:12 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2474.019; Tue, 26 Nov 2019 21:57:12 +0000 From: "Owen Friel (ofriel)" To: Brian E Carpenter , Michael Richardson CC: "anima@ietf.org" Thread-Topic: [Anima] Cloud BRSKI discussion -- Option 1 use cases Thread-Index: AQHVopjjjfqPGl4MTE+qlqyqK5ndIaeZ+4EAgAGg1wCAAKqmAIABvHoA Date: Tue, 26 Nov 2019 21:57:12 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <28576.1574580524@dooku.sandelman.ca> <9c60c895-9e14-c064-9f4a-306c5d7a1105@gmail.com> <1120.1574673282@dooku.sandelman.ca> <29988aee-9b8e-afab-1498-80dcf8b9f6fd@gmail.com> In-Reply-To: <29988aee-9b8e-afab-1498-80dcf8b9f6fd@gmail.com> 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=ofriel@cisco.com; x-originating-ip: [173.38.220.39] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f0d546d-3f2a-4313-73d7-08d772bb978f x-ms-traffictypediagnostic: MN2PR11MB3806: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(396003)(366004)(39860400002)(136003)(13464003)(189003)(199004)(99286004)(186003)(966005)(6436002)(9686003)(2906002)(7736002)(316002)(4326008)(71190400001)(6306002)(11346002)(14454004)(478600001)(6116002)(446003)(55016002)(8676002)(25786009)(76116006)(3846002)(8936002)(66476007)(74316002)(52536014)(305945005)(7696005)(5660300002)(33656002)(26005)(76176011)(110136005)(256004)(229853002)(53546011)(6506007)(6246003)(64756008)(66556008)(66446008)(102836004)(81156014)(81166006)(66066001)(86362001)(66946007)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3806; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1igGi/+O4w9ia/2c2ouccIXDZ7feGGKb1ef+/aXIX5X+d/awhV99rBbSfE17uXHwv3QMxo14P9lrjY6vLBtUAPdL8NK/1TJl8R4QNXlDfIVISQ89T4POlH0/WOrFO+ORofV9W7f+/xeA3BNhwaQ30nROcsi7z6Iqe7tvZuFpiGLZMTSZO+Q6FAAR52MpLQ4+fsqm40NDho1qY9WzBvpAWPfUL3M/g5wzMlvlo0va45Yy7qgdC7OEAy0JrrLKAnK6mmK9x4bgxmaWP6zM9Kg0a1Nk1kXb8MgHYFZtIFxqhhqFpGVjRO6wtyqU1gag+/ciMIlGDXg95Yri9WgL4vE1ajM63epmTMSe+P5vHNzCBpHQCtnv3aoMoag5KpdMQ5HJdO7R5v/5tzZ9p/YJ787oZPhJ3p7b8750pAjED4u46dKq5q+A3gKjrk1C91LLPlsz7WFCBbZ0c+TyWBncrqod7UV0mTU3ZRfnagYbl4t/V5k= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8f0d546d-3f2a-4313-73d7-08d772bb978f X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2019 21:57:12.2636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: imjp2Q91UhbfbWh68AAdzI9r10/zBYSBBAa8tnNFqI1UjmURVSTR1sVRU3CU7EC5I/fa40W14bRAuLTU8/J8Ww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3806 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 26 Nov 2019 21:57:20 -0000 > -----Original Message----- > From: Anima On Behalf Of Brian E Carpenter > Sent: 25 November 2019 19:25 > To: Michael Richardson > Cc: anima@ietf.org > Subject: Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases >=20 > On 25-Nov-19 22:14, Michael Richardson wrote: > > > > Brian E Carpenter wrote: > > > One thing that doesn't seem to be clear either in BRSKI or in > > > draft-friel-anima-brski-cloud is where the Cloud Registrar's "wel= l > > > known" URI comes from and how the pledge knows it. Is it vendor > > > specific or what? > > > > It is vendor specific, and it's baked in. >=20 > Thanks. That was my working assumption, but I suggest stating it up front= in > draft-friel-anima-brski-cloud. [ofriel] https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfr= a-30#appendix-B states: " If no local proxy or registrar service is located using the GRASP mechanisms or the above mentioned DNS-based Service Discovery methods, the pledge MAY contact a well known manufacturer provided bootstrapping server by performing a DNS lookup using a well known URI such as "brski-registrar.manufacturer.example.com". The details of the URI are manufacturer specific. Manufacturers that leverage this method on the pledge are responsible for providing the registrar service. Also see Section 2.7." >=20 > > The idea is that we can transform the well-known, but very much > > proprietary "call-home" process that many devices use today into > > something that enables a transfer of ownership mechanism. >=20 > Understood. >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Nov 26 14:29:13 2019 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 3B505120AFA for ; Tue, 26 Nov 2019 14:29:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 XdCDtAFMg2S8 for ; Tue, 26 Nov 2019 14:29:10 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 4D919120AFE for ; Tue, 26 Nov 2019 14:29:10 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id t8so8725101plr.8 for ; Tue, 26 Nov 2019 14:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9GcraGEu5P5HSBbDCAtjoi0dGZstjMi6FhShX99v74E=; b=GSqLbMJY8Jugs9jSb9XfdI75NWwUcGA1F0KWRPQ+qHHxg4uIpaE0GcNakOZ+j4xS/O 7FH0+01fQY05mIbqoh/TudaglHDPQGyOb5nmHs4zKRXMhxMjNsDlmWZKYro/dk/IN/XO tuamhsdWhD48rKazab9RQzxT3BO0N7TGfaaZ9TgRa3+iEhCDVr52liPWwICDhcTm9/ln 0Ud1cgvuDF2BG8tKsrDm2J0gwyYwRfIcmvLHSo/6TuRRx/f9WUy6aEuPEntdX0VNLkS/ TwM5agiacF1FGZ4cViOzli57yB/5Of6mPwwINW/krzRHUFG4vLxiLlCNBcN5Xp/9jmaV IKLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9GcraGEu5P5HSBbDCAtjoi0dGZstjMi6FhShX99v74E=; b=rDxLZRT3wlafceYtP5IiIkBKAshbg0Ikvhd5tE1g8KQtoiISFV1Ucrc3+Lavc+Vos3 /KBYiCjjp7r2S7gwT3zURfhP8xVt9gcZR30rCHPP/x/P5/3ybfKIEQEbhHEFrHaWdalo 1CWQgowEQnGDVjfu9rwfutqvwTyUF4xBlb+VCDBwtvLnS0oDSR/yP7olL5+k9y7G1HOk V3YEIptbaZSjqRvOF3Xwlo84tK8a7ergWR52NN5APm+lV8x3fJNw1qvaBEGi9xJIIZ8A HflDg2khWmYr9Oeo9Sn+uMdl6/OoM9oB9nJBHSAwRE2xJ4cY13FF1b4J+RmpKS3IhNJz ZI9g== X-Gm-Message-State: APjAAAWtvVmrg2D9z1reTi7/0FD4uR71RnJ7yDiJ2irDZ+J3OgtIBDtX ahudvINsWm4X8vNy4/kicscJMvHz X-Google-Smtp-Source: APXvYqwMPuuCJbUUaArmw3oQTPUilSwaqpv/T5o7wDXKyy/GVphY22k+tPThml7ds0kcpmaGPz5Z+Q== X-Received: by 2002:a17:902:70cc:: with SMTP id l12mr713305plt.198.1574807349342; Tue, 26 Nov 2019 14:29:09 -0800 (PST) Received: from [192.168.178.30] (8.166.69.111.dynamic.snap.net.nz. [111.69.166.8]) by smtp.gmail.com with ESMTPSA id y81sm13946514pfb.178.2019.11.26.14.29.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Nov 2019 14:29:08 -0800 (PST) To: "Owen Friel (ofriel)" , Michael Richardson Cc: "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <28576.1574580524@dooku.sandelman.ca> <9c60c895-9e14-c064-9f4a-306c5d7a1105@gmail.com> <1120.1574673282@dooku.sandelman.ca> <29988aee-9b8e-afab-1498-80dcf8b9f6fd@gmail.com> From: Brian E Carpenter Message-ID: <0caf0245-2364-cd6e-7a33-969b39cf4a9a@gmail.com> Date: Wed, 27 Nov 2019 11:29:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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] Cloud BRSKI discussion -- Option 1 use cases X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 26 Nov 2019 22:29:12 -0000 On 27-Nov-19 10:57, Owen Friel (ofriel) wrote: > > >> -----Original Message----- >> From: Anima On Behalf Of Brian E Carpenter >> Sent: 25 November 2019 19:25 >> To: Michael Richardson >> Cc: anima@ietf.org >> Subject: Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases >> >> On 25-Nov-19 22:14, Michael Richardson wrote: >>> >>> Brian E Carpenter wrote: >>> > One thing that doesn't seem to be clear either in BRSKI or in >>> > draft-friel-anima-brski-cloud is where the Cloud Registrar's "well >>> > known" URI comes from and how the pledge knows it. Is it vendor >>> > specific or what? >>> >>> It is vendor specific, and it's baked in. >> >> Thanks. That was my working assumption, but I suggest stating it up front in >> draft-friel-anima-brski-cloud. > > [ofriel] https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-30#appendix-B states: > > " If no local proxy or registrar service is located using the GRASP > mechanisms or the above mentioned DNS-based Service Discovery > methods, the pledge MAY contact a well known manufacturer provided > bootstrapping server by performing a DNS lookup using a well known > URI such as "brski-registrar.manufacturer.example.com". The details > of the URI are manufacturer specific. Manufacturers that leverage > this method on the pledge are responsible for providing the registrar > service. Also see Section 2.7." Fair enough, but that doesn't capture "baked in" and you probably want manufacturers to be aware of that requirement, especially since this is distinct from baking in the MUD URL. Brian > >> >>> The idea is that we can transform the well-known, but very much >>> proprietary "call-home" process that many devices use today into >>> something that enables a transfer of ownership mechanism. >> >> Understood. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Nov 27 06:06:21 2019 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 6026A12083B for ; Wed, 27 Nov 2019 06:06:19 -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, SPF_HELO_NONE=0.001, 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 QIT9kWDL2FLc for ; Wed, 27 Nov 2019 06:06:18 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85C412012D for ; Wed, 27 Nov 2019 06:06:17 -0800 (PST) Received: from dooku.sandelman.ca (146.128-255-62.static.virginmediabusiness.co.uk [62.255.128.146]) by relay.sandelman.ca (Postfix) with ESMTPS id D2D5F1F47D; Wed, 27 Nov 2019 14:06:14 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7F2F2C9B; Wed, 27 Nov 2019 22:06:20 +0800 (+08) From: Michael Richardson To: "Owen Friel \(ofriel\)" cc: Brian E Carpenter , "anima\@ietf.org" In-reply-to: References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <28576.1574580524@dooku.sandelman.ca> <9c60c895-9e14-c064-9f4a-306c5d7a1105@gmail.com> <1120.1574673282@dooku.sandelman.ca> <29988aee-9b8e-afab-1498-80dcf8b9f6fd@gmail.com> Comments: In-reply-to "Owen Friel (ofriel)" message dated "Tue, 26 Nov 2019 21:57:12 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 27 Nov 2019 15:06:20 +0100 Message-ID: <16230.1574863580@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2019 14:06:19 -0000 --=-=-= Content-Type: text/plain Owen Friel (ofriel) wrote: >> > It is vendor specific, and it's baked in. >> >> Thanks. That was my working assumption, but I suggest stating it up front in >> draft-friel-anima-brski-cloud. > [ofriel] https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-30#appendix-B states: > " If no local proxy or registrar service is located using the GRASP > mechanisms or the above mentioned DNS-based Service Discovery > methods, the pledge MAY contact a well known manufacturer provided > bootstrapping server by performing a DNS lookup using a well known > URI such as "brski-registrar.manufacturer.example.com". The details > of the URI are manufacturer specific. Manufacturers that leverage > this method on the pledge are responsible for providing the registrar > service. Also see Section 2.7." So, maybe we should quote this literally in anima-brski-cloud's introduction. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3egtwACgkQlUzhVv38 QpAe+Af/U7q67XmMRHUXLHdTEjAh8pQnanfgKw1PCILFCoL1QAZUh8MpzZHXuXth OvIw1f+B72DIF8EbpO76GBnzdoNjDNInPNWjy2RgvmPBD4Vck1gLVjl5Nw3QQ5G6 K5AXCXDZTkaDaUhkZAGx5dbkkTasA+kTwATdG+Nf1KumOW1tIJfLKzhVmI8ypqnU 2Qd1CZSkDIKOEqlFnTwCg/oVayq9NIdLf2BeB581m/XomkwwHYqqoqCuNxBQQvN8 q4n+dqIjaw0nuZLBnPMdP9xwmt7sQmkvcZxsxc/TUXNBhHhf+UZuYim4YJKtyEgl FkkohH/HE5CRDmAGT6eY1DB6aE4LTA== =+YVo -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 28 01:39:11 2019 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 70D481200C7 for ; Thu, 28 Nov 2019 01:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.446 X-Spam-Level: * X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=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 TASiHWlpyY16 for ; Thu, 28 Nov 2019 01:39:08 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96A61200B9 for ; Thu, 28 Nov 2019 01:38:42 -0800 (PST) Received: from dooku.sandelman.ca (unknown [185.201.63.254]) by relay.sandelman.ca (Postfix) with ESMTPS id 752851F47D; Thu, 28 Nov 2019 09:38:40 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 4FB6CE65; Thu, 28 Nov 2019 17:38:29 +0800 (+08) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-reply-to: References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> Comments: In-reply-to Brian E Carpenter message dated "Sun, 17 Nov 2019 12:51:12 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 28 Nov 2019 10:38:29 +0100 Message-ID: <22922.1574933909@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] some comments about ACP connect X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2019 09:39:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> Toerless, I am preparing a document on Operational Considerations for >> Registrars: "Operational Considerations for BRSKI Registrar" >> >> I was reviewing section 8.1, on ACP connect. >> >> =C2=A0=C2=A0 To allow for auto-configuration of NMS hosts, the ACP e= dge device and >> =C2=A0=C2=A0 NMS hosts using ACP connect SHOULD support [RFC4191].= =C2=A0 The ACP edge >> =C2=A0=C2=A0 device should announce the whole ACP ULA prefix via tha= t standards >> =C2=A0=C2=A0 Router Advertisement signaling option.=C2=A0 It should = also announce the >> =C2=A0=C2=A0 default route (::/) with a lifetime of 0.=C2=A0 In resu= lt, NMS hosts >> =C2=A0=C2=A0 supporting RFC4191 will route the ACP prefix via the AC= P edge device, >> =C2=A0=C2=A0 but will not route the default route via it. >> >> I don't disagree with anything you say, btw. >> I think that maybe some explanation is in order here though. >> I recognize the document is in it's final stage, but maybe a word or= two >> could be added here. >> First, what is the "whole ACP ULA prefix"?=C2=A0 Is it the /48?=C2= =A0 I think we >> could say so. >> I will send a pull request once I finish writing. > Assuming it does mean the /48, that's an editorial clarification. > (If it doesn't mean that, please explain.) >> Second, if 6.10.2 defines the base scheme, and it's 8+40+2=3D50, why= in >> 6.10.3 does it >> say "51*" above the "(base scheme)"?=C2=A0 Is that a typo? > Huh? That is not present in the -21 draft. I seem to have been working from what was in github in order to better provide edits. That was a mistake I now see as the github hasn't been maintained. I'm fixing that... I see that the -21 text seems a bit better, and the third paragraph mentions the /48 explicitely. I also see that the 6.10.3 is already fixed. >> Generally, I think that NOC hosts should not autoconfigure (SLAAC or >> stable private address) addresses, as they ought to be manually >> configured.=C2=A0 I am open to discussion here. > I can see that for conventional management tools. I will just observe > that GRASP discovery doesn't need to be seeded with any well known > addresses (except the GRASP LL multicast address) so GRASP is complet= ely > indifferent to how NOC hosts get their unicast addresses. In fact we > could easily create a full NOC discovery mechanism over GRASP. I built > a MUD Manager discovery mechanism in the hackathon yesterday, and any > NOC server could be discovered the same way. It's probably worth > re-reading RFC8368 before discussing further. We will have quite a number of convential management tools in the NOC. The need to be able to reach out from operator desktop to equipment with SSH (or gosh... telnet?) will persist into the future, and it's why we built and secured the ACP. Many existing services will need names, and while putting ULAs into DNS mig= ht surprise some IPv4 operators, I think it's completely sane. A question will be how to connect the current crop of management tools to t= he ACP. This can be done by literally connecting desktops via ACP Connect. Another way will involve putting bastion hosts (ssh-jump-hosts) into the NO= C, as well as hosting virtual desktops on hypervisors connected via ACP Connec= t. =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 = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3flZQACgkQlUzhVv38 QpCRiwf7Bha8lE5VXUZMOBFN6SI/1mbbmF4z9PTiMOPvyIpuEdQOq3qIzV53F94e WS9/iiI2HkXEXXzsuAJORgO1niEkVMTuXXkL15Oj+33F8xl1re4q9sHcYgVhidah r8E86owe2ZS4vE4HyIWwAFTNpG1PhT4TAapdbQpqyO9fDL3xC1lMnehDlXz4oNYt DUjzb4E1AVFXX506fM/0H4pF1XgmXsBgo0BgPXLZ/fEGA0L70Va14+sq8vhkpAQU /8gHdm9JuH4uhZnP1sUEXE5/0T/8lZotlYbHmw9M49+bOV3/t1nY4cHdHIQcwAW/ fa8h1Ixj8v3leGMEMsfJP7TmRirVIg== =rHJR -----END PGP SIGNATURE----- --=-=-=--