From nobody Mon Oct 1 05:47:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50AA130DDC; Mon, 1 Oct 2018 05:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms_lOneKxQGs; Mon, 1 Oct 2018 05:47:44 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29497130E60; Mon, 1 Oct 2018 05:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14564; q=dns/txt; s=iport; t=1538398064; x=1539607664; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=VCIfZGsz71B8emzO/ZgrodXUtQgirjlmUhgr68FuHoM=; b=QEKmvICQih7NL+jexVolUzt6/oIPj/9AewM7Dhq2chkUrwpNuxQkz+eQ l0u6Sqgr8JBzWKEFymIQQBjA4Zgty0SWUCBRNpR2Juv7tIEcLZUOrMucj R+m3IWFpbBxwqk0NJtBsylfSHsRa5TiICZVyFDFnpEgNy46I7/1ARvbV0 o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAADyFrJb/xbLJq1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVINeEoQciHSNKi2RG4VTgWYIA4RsAoQxNxUBAwEBAgE?= =?us-ascii?q?BAm0ohTgBAQEBAgEjVgULCxgqAgJXBgEMCAEBgx0BgXkIpByBLh+JXA+CbYV?= =?us-ascii?q?OdhCBWIIAgRIngmuEOggWgyeCVwKIYxuTXE8JhAGBZoNqhl0GF4kFhkqVMYF?= =?us-ascii?q?YIoFVMxoIGxU7gm2QVT2KagEkB4IgAQE?= X-IronPort-AV: E=Sophos;i="5.54,327,1534809600"; d="asc'?scan'208,217";a="6921976" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2018 12:47:32 +0000 Received: from [10.61.94.24] (ams3-vpn-dhcp7705.cisco.com [10.61.94.24]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w91ClVkx019355; Mon, 1 Oct 2018 12:47:31 GMT To: Christian Huitema , Randy Bush Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <2df690be-21ac-bfc8-5ffd-e5b5b9d83a5f@cisco.com> Date: Mon, 1 Oct 2018 14:47:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <057bd957-06b4-824e-a7c8-214383819621@huitema.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gJihEWo3W3olZEykyEyFxsUWi3BreJY3D" X-Outbound-SMTP-Client: 10.61.94.24, ams3-vpn-dhcp7705.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 01 Oct 2018 12:47:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gJihEWo3W3olZEykyEyFxsUWi3BreJY3D Content-Type: multipart/mixed; boundary="KZUrUXHIHU6NvkbcjJg7sTdlKsz0FvQuG"; protected-headers="v1" From: Eliot Lear To: Christian Huitema , Randy Bush Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate Message-ID: <2df690be-21ac-bfc8-5ffd-e5b5b9d83a5f@cisco.com> Subject: Re: Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> In-Reply-To: <057bd957-06b4-824e-a7c8-214383819621@huitema.net> --KZUrUXHIHU6NvkbcjJg7sTdlKsz0FvQuG Content-Type: multipart/alternative; boundary="------------FFFE7C9D5CC765E9FE4F0484" Content-Language: en-US This is a multi-part message in MIME format. --------------FFFE7C9D5CC765E9FE4F0484 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Christian, On 01.10.18 07:42, Christian Huitema wrote: > If the manufacturer is willing to issue "good until time=3DX" vouchers,= > then in theory you could provide the voucher to your buyer, provided th= e > time limit of the voucher has not elapsed. If the manufacturer signs a > voucher "good until infinity", then the device can in theory be sold an= d > resold forever. But that's probably not true in practice, because the > voucher is written for a specific domain, and includes the certificate > of the domain for which the voucher is good. You may be able to play > games with some kind of certificate chain and make it work, but I will > believe that when I see it. IMHO it should be possible as an option to not pin the domain.=C2=A0 In t= hat case, a voucher could be a scannable label or BOM that can be handed off directly with the device.=C2=A0 Obviously that's a nonceless option as we= ll.=C2=A0 Think of it as a file that one simply uploads to the registrar.=C2=A0 The= key thing here is that the manufacturer needs to make the decision for which devices it wants to do this.=C2=A0 This would also solve [6] in your list= of issues.=C2=A0 However, this mitigation will not always be appropriate, particularly for devices that may transit from one network to another, or where it is simply inconvenient to retain a label. Addressing some more of your LC comments: > 1) Denial of service against the vendor MASA service. Adversaries could= mount an > attack against the service at a critical time, preventing real-time iss= uance of > nonced vouchers. This could for example prevent the deployment of auton= omic networks > during emergencies. This can be mitigated by onboarding devices in inventory *before* the emergency.=C2=A0 It could also be mitigated as per the above. > 2) Compromise of the vendor's public key. This would allow attackers to= get > "ugly ducklings" imprinted in the domain. Let's be clearer, because there are two separate threats: 1. A compromised end point inappropriately being onboarded in order to attack a network; where the registrar is validating the signature and certificate; and 2. A perfectly fine endpoint being inappropriately onboarded to an unauthorized network; where the endpoint is validating the signature and certificate. Also, I think you are referring to the *private* key associated with a vendor certificate.=C2=A0 [1] can be mitigated by the registrar by the ve= ndor reissuing the voucher signing cert and checking a CRL.=C2=A0 [2] requires= a bit more care and a backup certificate of some form. > 3) Rotation of the vendor's public key. This could prevent old devices = from > joining the domain, or from verifying the new vouchers. Old certificates never die.=C2=A0 They just fade away.=C2=A0 More serious= ly, if the cert is used, it should be kept available, unless a backup is also provided. > 7) The closest to ship and forget is a MASA service configured to alway= s > issue vouchers, regardless of the device ID and the registrar domain. I= would > expect that to be popular with some manufacturers. It is mentioned in > section 6.4, which recommend that manufacturers should not do that. Wha= t > are the consequences if they still do?=20 In a wireless scenario this could be problematic, since the device could imprint on the first network seen.=C2=A0 This presumes something like draft-lear-eap-teap-brski.txt.=C2=A0 We haven't gotten that far, but it i= s clearly an issue and something we want to discuss in Bangkok.=C2=A0 In a wired environment this is less of an issue, although there are still risk= s. > 8) Attacks by the device. What happens if a device refuses to be imprin= ted? It will not be able to trust the local environment, and may not be able to retrieve a local certificate.=C2=A0 I presume lots of issues would cro= p up from there. > 11) Attacks by the MASA. What happens if the MASA refuses to provide a = voucher, > or provides a wrong voucher?=20 Same as above.=C2=A0 There is a mitigating factor against this behavior: = the cost of a support call. > 12) Device implementation of random numbers. The draft discusses manage= ment of=20 > time in a drop ship device, but what about the management of random num= bers? For > example, what if poorly manufactured devices always generated the same = nonce, > or a predictable nonce? Then we have bigger fish to fry.=C2=A0 The device's crypto is broken. > 13) Device individualization. The drop ship model assumes that devices = are > shipped with factory default, but BRSKI also assumes that devices come = with > individuals ID and certificate. This requires a specific per device ste= p in > the manufacturing process. Some makers of inexpensive devices don't do = that, > and ship devices that are all strictly identical. How does that affect = the > BRSKI process? It's a prerequisite, so... > 14) Privacy considerations. Third parties will be able to observe traff= ic > between domain registrar and service provider MASA. They will at a mini= mum > be able to learn that domain X is a customer of provider Y. Can they do= more? > The communication is protected by TLS. How much is revealed by clear > text components like the SNI? How much can be obtained by traffic > analysis? This could be mitigated by using unpinned vouchers that come with the device. Eliot --------------FFFE7C9D5CC765E9FE4F0484 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Christian,

On 01.10.18 07:42, Christian Huitema wrote:
If the manufacturer is willing to issue "good until =
time=3DX" vouchers,
then in theory you could provide the voucher to your buyer, provided the
time limit of the voucher has not elapsed. If the manufacturer signs a
voucher "good until infinity", then the device can in theory be sold and
resold forever. But that's probably not true in practice, because the
voucher is written for a specific domain, and includes the certificate
of the domain for which the voucher is good. You may be able to play
games with some kind of certificate chain and make it work, but I will
believe that when I see it.

IMHO it should be possible as an option to not pin the domain.=C2=A0 = In that case, a voucher could be a scannable label or BOM that can be handed off directly with the device.=C2=A0 Obviously that's a noncele= ss option as well.=C2=A0 Think of it as a file that one simply uploads t= o the registrar.=C2=A0 The key thing here is that the manufacturer need= s to make the decision for which devices it wants to do this.=C2=A0 This w= ould also solve [6] in your list of issues.=C2=A0 However, this mitigation= will not always be appropriate, particularly for devices that may transit from one network to another, or where it is simply inconvenient to retain a label.

Addressing some more of your LC comments:

1) Denial of service against the vendor MASA service=
=2E Adversaries could mount an
attack against the service at a critical time, preventing real-time issua=
nce of
nonced vouchers. This could for example prevent the deployment of autonom=
ic networks
during emergencies.

This can be mitigated by onboarding devices in inventory before the emergency.=C2=A0 It could also be mitigated as per the above.
= 
2) Compromise of the vendor's public key. This would=
 allow attackers to get
"ugly ducklings" imprinted in the domain.

Let's be clearer, because there are two separate threats:
  1. A compromised end point inappropriately being onboarded in order to attack a network; where the registrar is validating the signature and certificate; and
  2. A perfectly fine endpoint being inappropriately onboarded to an unauthorized network; where the endpoint is validating the signature and certificate.
Also, I think you are referring to the private key associated with a vendor certificate.=C2=A0 [1] can be mitigated by t= he registrar by the vendor reissuing the voucher signing cert and checking a CRL.=C2=A0 [2] requires a bit more care and a backup certificate of some form.

3) Rotation of the vendor's public key. This could p=
revent old devices from
joining the domain, or from verifying the new vouchers.

Old certificates never die.=C2=A0 They just fade away.=C2=A0 More ser= iously, if the cert is used, it should be kept available, unless a backup is also provided.

7) The closest to ship and forget is a MASA service =
configured to always
issue vouchers, regardless of the device ID and the registrar domain. I w=
ould
expect that to be popular with some manufacturers. It is mentioned in
section 6.4, which recommend that manufacturers should not do that. What
are the consequences if they still do?

In a wireless scenario this could be problematic, since the device could imprint on the first network seen.=C2=A0 This presumes somethin= g like draft-lear-eap-teap-brski.txt.=C2=A0 We haven't gotten that far,= but it is clearly an issue and something we want to discuss in Bangkok.=C2= =A0 In a wired environment this is less of an issue, although there are still risks.

8) Attacks by the device. What happens if a device r=
efuses to be imprinted?

It will not be able to trust the local environment, and may not be able to retrieve a local certificate.=C2=A0 I presume lots of issues would crop up from there.
11) Attacks by the MASA. What happens if the MASA re=
fuses to provide a voucher,
or provides a wrong voucher?

Same as above.=C2=A0 There is a mitigating factor against this behavi= or: the cost of a support call.

12) Device implementation of random numbers. The dra=
ft discusses management of=20
time in a drop ship device, but what about the management of random numbe=
rs? For
example, what if poorly manufactured devices always generated the same no=
nce,
or a predictable nonce?

Then we have bigger fish to fry.=C2=A0 The device's crypto is broken.= 

13) Device individualization. The drop ship model as=
sumes that devices are
shipped with factory default, but BRSKI also assumes that devices come wi=
th
individuals ID and certificate. This requires a specific per device step =
in
the manufacturing process. Some makers of inexpensive devices don't do th=
at,
and ship devices that are all strictly identical. How does that affect th=
e
BRSKI process?

It's a prerequisite, so...
14) Privacy considerations. Third parties will be ab=
le to observe traffic
between domain registrar and service provider MASA. They will at a minimu=
m
be able to learn that domain X is a customer of provider Y. Can they do m=
ore?
The communication is protected by TLS. How much is revealed by clear
text components like the SNI? How much can be obtained by traffic
analysis?

This could be mitigated by using unpinned vouchers that come with the device.

Eliot

--------------FFFE7C9D5CC765E9FE4F0484-- --KZUrUXHIHU6NvkbcjJg7sTdlKsz0FvQuG-- --gJihEWo3W3olZEykyEyFxsUWi3BreJY3D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAluyF2IACgkQh7ZrRtnS ejOpygf/YkmgI7VMTKWMCIWraz1fnT9CEbYRdMXffqyE53VY8K9OD07paUJ5ncY6 jc9ifyJCQcViEmVJUIasgc5j/hf88kpOOqFo0e2BUGODG3z3HMX2ueG0BS2vUI4T yWNggLKDPBvWarxo6DYYxfGhf2oSmPr4OCPhKAQGXzhIzHWGxf1zTiZotM1xHjr9 XpHEkv7WSWMh0PVmBMJwiOJy1WKtwaDhUm+CqKEawXCckVAI7I7L6cJYbyycQ9BD kGRzWBYDxt13IwEZCuPwNI8LY5FDiH390L9VMk1auKPDjHIED6HzV4GDtDFaT2Z0 qufwgAyLFzVN2TadL4a7uAEAY2xQiw== =3VTU -----END PGP SIGNATURE----- --gJihEWo3W3olZEykyEyFxsUWi3BreJY3D-- From nobody Mon Oct 1 12:37:16 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350CA130EDE; Mon, 1 Oct 2018 12:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 mZJD4qZNYM8o; Mon, 1 Oct 2018 12:37:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 B6DE5130EC9; Mon, 1 Oct 2018 12:37:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g7401-0000i6-7c; Mon, 01 Oct 2018 19:36:57 +0000 Date: Mon, 01 Oct 2018 12:36:56 -0700 Message-ID: From: Randy Bush To: Michael Richardson Cc: "Joel M. Halpern" , Brian E Carpenter , Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate In-Reply-To: <3136.1538342967@localhost> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <0cbdf93d-c432-57f5-5000-8595b006d6d0@gmail.com> <3136.1538342967@localhost> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 01 Oct 2018 19:37:15 -0000 >> a stunning review as usual. but i have two questions which you kind >> of finessed. they are simple binary, i.e. yes/no, questions that the >> end user, to whom the IETF is ultimately responsible, really cares >> about. > >> if the manufacturer's servers go down, either permanently or even for >> a day, does the device i have purchased still work? i.e. is it fail >> soft? [0] > > First, BRSKI as used by ANIMA is specifically not targetted at Things. > (We are developing profiles of BRSKI that are about Things, but I > think that this internet-draft should not be be evaluated on that > basis). > > It's targetted at routers and other devices found at ISPs or > Enterprises. i missed where i said light bulbs. i do have some of those, but i run routers, servers, etc.; and do not want $vendor to break my network for *any* reason. > Second, the only time the manufacturer's servers need to be alive is > when device ownership is claimed. i.e. when i sell the router to some other op. that was my second question. > Once the device is claimed, it joins *YOUR* network, and trusts your > infrastructure, not the manufacturer. Whether or not the device will > *operate* without the manufacturer's servers is really outside of > BRSKI. ahhh. we just sell the guns, we do not say how they are used. >> That answer seems to imply that if the MASA is down before I try to >> transfer my device, and if the MASA is still down when the recipient >> tries to get my device working, it won't work. > >> Which seems to mean that once a MASA goes down permanently, any new >> can not get a device reliant on that MASA to work. > >> Seems a pretty severe limitation. > > You are answering a different question than Randy asked no. he is speaking to the second question i asked. and his answer deeply concerns me. > This is a pretty important question and we have discussed it at > length. I remain concerned, but as far as I can see, we have this > problem already. if i understand correctly, it creates a new problem, needing the manufacturer's consent for me to resell my light^Hrouter. > It fundamentally depends upon a number of things which unfortunately, the > manufacturer has ultimate decision making about. see above about guns randy From nobody Mon Oct 1 14:47:34 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C14130E16; Mon, 1 Oct 2018 14:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaXNZythURds; Mon, 1 Oct 2018 14:47:31 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 CE66A130EC0; Mon, 1 Oct 2018 14:47:31 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id p24-v6so1697129pff.10; Mon, 01 Oct 2018 14:47:31 -0700 (PDT) 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=s6Vur4LMpNXyMO7Jswd2CEC8I24lJS4WG4Odp2xZI9A=; b=IHCUOEelgkVWdqU/TnMM18lAH5AxyF9ulJsjMeUuAzLRfTNSzVw/N9JXGEuOopl08M TmqI3Y0bZrOKVxCNYBIqC1W2nEzQWCBk4R35e+8kCuzBPWDjVFMZxcG+6WTiKzXKjqe2 4xpDE7/juehc7vHw/YSbwI+IDraOH6Qqnxbv4YUtUKEtjqAJrng5rJYzeUhmNaSI7K8a mFownzOE9VfGi2ufiYdQik61K5hKTta+xCQd9WBv8WqMTkhAv7Iu4qS3yzQp5gAu4MSF CLa8ZkO4Z1gEdrtiA+UJKGJ1qPb83wEkAaarKLjPu0UjfDp6kxhEkzmZoeZsCgYDarE5 r8yw== 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=s6Vur4LMpNXyMO7Jswd2CEC8I24lJS4WG4Odp2xZI9A=; b=moon0Tnzt66Yl9IZKeryJN2mQZUMFIy49WX8dQCGNrQ4DkwZ+0lIAM/BEKapW2xVo1 eeXWdn0wfUjCA0RMIwvpKeh8klXiOj2mXK4kp1tx1v9CyQCB1XrUc9tck/BauUB8tPwM Fd+4T2hEKlIU8yMmq52xiZ9aTVNLLVEcC/KewEt4L/yoiMvBBZPjWyC5CAzG+c+jCHm3 2k67wrDcVHneNHlu2oXh4PYmFGlMCdcsXkSr/Fi5A6KgwXulFtdk3HzRn2za0fbmbXr9 bR7yvXKe2cd+Y8KRz9jNIsvBv3Cu5LTvag6DafrJrAWDK0cT4xRvU5NxNX8WYExFnz3o Ox5Q== X-Gm-Message-State: ABuFfojgRGXwtG9KZZ53e9LsMZdCyihpisTHhu5fm0oPyiGHsEI5UZRO Mi76t4IwGJEYQTodVcjnkhnX387r X-Google-Smtp-Source: ACcGV63NpOL5ltarTKfVNyuCrAADOkSKKE5jtWOV70og14D15S+UliFXGIEyS+zSbMvrlLsyeC4xEg== X-Received: by 2002:a17:902:758b:: with SMTP id j11-v6mr13717604pll.5.1538430451047; Mon, 01 Oct 2018 14:47:31 -0700 (PDT) Received: from [130.216.38.15] (ggim001.sfac.auckland.ac.nz. [130.216.38.15]) by smtp.gmail.com with ESMTPSA id v81-v6sm29708505pfj.25.2018.10.01.14.47.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 14:47:30 -0700 (PDT) To: Randy Bush , Michael Richardson Cc: "Joel M. Halpern" , Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF discussion list , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <0cbdf93d-c432-57f5-5000-8595b006d6d0@gmail.com> <3136.1538342967@localhost> From: Brian E Carpenter Message-ID: <8303d9ed-237e-1960-cf2f-d277a92338f7@gmail.com> Date: Tue, 2 Oct 2018 10:44:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 01 Oct 2018 21:47:34 -0000 On 2018-10-02 08:36, Randy Bush wrote: >>> a stunning review as usual. but i have two questions which you kind >>> of finessed. they are simple binary, i.e. yes/no, questions that the >>> end user, to whom the IETF is ultimately responsible, really cares >>> about. >> >>> if the manufacturer's servers go down, either permanently or even for >>> a day, does the device i have purchased still work? i.e. is it fail >>> soft? [0] >> >> First, BRSKI as used by ANIMA is specifically not targetted at Things. >> (We are developing profiles of BRSKI that are about Things, but I >> think that this internet-draft should not be be evaluated on that >> basis). >> >> It's targetted at routers and other devices found at ISPs or >> Enterprises. > > i missed where i said light bulbs. i do have some of those, but i run > routers, servers, etc.; and do not want $vendor to break my network for > *any* reason. > >> Second, the only time the manufacturer's servers need to be alive is >> when device ownership is claimed. > > i.e. when i sell the router to some other op. that was my second > question. > >> Once the device is claimed, it joins *YOUR* network, and trusts your >> infrastructure, not the manufacturer. Whether or not the device will >> *operate* without the manufacturer's servers is really outside of >> BRSKI. > > ahhh. we just sell the guns, we do not say how they are used. It's not quite that. We sell X's. We cannot control how the X's are used. But if they are used without calling home to our MASA, we cannot certify that they are genuine X's. They might be counterfeit X's. BRSKI is a way of proving that the X announcing its identity as X12345 really is the one and only X12345. If you sell it to someone who doesn't care about that, they can use it anyway. Anyway, that's how I understand it. Brian > >>> That answer seems to imply that if the MASA is down before I try to >>> transfer my device, and if the MASA is still down when the recipient >>> tries to get my device working, it won't work. >> >>> Which seems to mean that once a MASA goes down permanently, any new >>> can not get a device reliant on that MASA to work. >> >>> Seems a pretty severe limitation. >> >> You are answering a different question than Randy asked > > no. he is speaking to the second question i asked. and his answer > deeply concerns me. > >> This is a pretty important question and we have discussed it at >> length. I remain concerned, but as far as I can see, we have this >> problem already. > > if i understand correctly, it creates a new problem, needing the > manufacturer's consent for me to resell my light^Hrouter. > >> It fundamentally depends upon a number of things which unfortunately, the >> manufacturer has ultimate decision making about. > > see above about guns > > randy > From nobody Mon Oct 1 15:44:58 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E242A129619; Mon, 1 Oct 2018 15:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Y8rZNIa2OdhD; Mon, 1 Oct 2018 15:44:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2F7D2124C04; Mon, 1 Oct 2018 15:44:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g76vs-0001P4-8M; Mon, 01 Oct 2018 22:44:52 +0000 Date: Mon, 01 Oct 2018 15:44:51 -0700 Message-ID: From: Randy Bush To: Christian Huitema Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate In-Reply-To: <057bd957-06b4-824e-a7c8-214383819621@huitema.net> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 01 Oct 2018 22:44:56 -0000 > The "soft fail" happens if devices need to be reset to factory > settings for some reason, then you will have to wait for the > manufacturer's servers to bring them back up. when i sell the lightb^Hrouter to mary, of course i reset to factory settings. > That may be mitigated if the manufacturer provided you with nonceless > vouchers, valid until "time=3DX", and in particular if the manufacturer > gave you vouchers "good until infinity". In that case, your old > devices could still be reset to factory condition and restarted, > without even "soft fail". dear world: be absolutely sure that, when you buy a lightb^Hrouter, you get a nonceless voucher with an infinite lifetime. before handing them your cash, you can test this by .... right how about the spec says that "the manufacturer MUST accompany the lightb^Hrouter with a nonceless voucher with an infinite lifetime. purchasers who, for whatever reason, with more restricted vouchers may negotiate." >> if the manufacturer's servers go down, either permanently or even for >> a day, can i give/sell the device i have purchased to a third, well >> fourth i guess, party, at my whim and seamlessly unencumbered? >=20 > It depends somewhat on the type of voucher that the manufacturer is > willing to give you, but the short answer is No, you can't. >=20 > If the manufacturer only wants to provide real time vouchers that > incorporate the random nonce issued by the device, then the answer is > very clearly no, you cannot resell the device without approval from the > manufacturer. The voucher in that case acts as a kind of DRM. then i strongly object to the ietf specifying this; c.f. selling guns. =20 > If the manufacturer is willing to issue "good until time=3DX" vouchers, > then in theory you could provide the voucher to your buyer, provided the > time limit of the voucher has not elapsed. If the manufacturer signs a > voucher "good until infinity", then the device can in theory be sold and > resold forever. But that's probably not true in practice, because the > voucher is written for a specific domain, and includes the certificate > of the domain for which the voucher is good. You may be able to play > games with some kind of certificate chain and make it work, but I will > believe that when I see it. i.e. practically you can not resell something you thought you had bought. baaaaaad. > The BRSKI specification is a tradeoff and that's why I would really > like to see the tradeoff explained in clear terms in the spec. It is > designed to prevent hijacking of the device during its registration in > the buyer's network. if, to actually own a device i bought, i need to manage my own security, then i will take that. > If BRSKI implemented a pure RFC 7030 process, the device=A0 might have > to accept to be imprinted by the registrar without having verified to > whom it is talking. In practice that would mean relying on some kind > of physical security, or maybe relying on the kind of trust anchors > commonly used for web services. From the registrar point of view, the > failure mode is that some kind of man-in-the-middle inserts itself > during the registration process, and maintains control of the device > after it is connected to the network. >=20 > The voucher system mitigates that risk, but at the cost of strong > dependency on the manufacturer. As I say, that's a trade-off, and I > could see different buyers having different opinions on that > dependency. In fact, I could see buyers willing to buy devices only > if they permitted "voucher-less" initialization. If the standard > allowed that option, then market forces would quickly define how > valuable the voucher system is. two problems. the buyer will not realize that they just rented the lightb^Hrouter until they go to sell it; way too late to do anything about it. the manufactures have very small incentive to lower drm barriers. i can point to a jillion current examples. my favorite of the week is john deere. randy From nobody Mon Oct 1 17:28:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45D9126CB6; Mon, 1 Oct 2018 17:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v7c8TWRr-MIe; Mon, 1 Oct 2018 17:28:09 -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 35074124C04; Mon, 1 Oct 2018 17:28:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9265720090; Mon, 1 Oct 2018 20:28:07 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3D3FF1537; Mon, 1 Oct 2018 20:28:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 38EBBAE0; Mon, 1 Oct 2018 20:28:08 -0400 (EDT) From: Michael Richardson To: Randy Bush cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org, Security Directorate In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <0cbdf93d-c432-57f5-5000-8595b006d6d0@gmail.com> <3136.1538342967@localhost> 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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 00:28:12 -0000 --=-=-= Content-Type: text/plain Randy Bush wrote: >>> a stunning review as usual. but i have two questions which you kind >>> of finessed. they are simple binary, i.e. yes/no, questions that the >>> end user, to whom the IETF is ultimately responsible, really cares >>> about. >> >>> if the manufacturer's servers go down, either permanently or even for >>> a day, does the device i have purchased still work? i.e. is it fail >>> soft? [0] >> >> First, BRSKI as used by ANIMA is specifically not targetted at Things. >> (We are developing profiles of BRSKI that are about Things, but I >> think that this internet-draft should not be be evaluated on that >> basis). >> >> It's targetted at routers and other devices found at ISPs or >> Enterprises. > i missed where i said light bulbs. i do have some of those, but i run > routers, servers, etc.; and do not want $vendor to break my network for > *any* reason. Then I suggest that you never patch the OS or apply firmware updates :-) The reality is that they can break your network trivially if they want to. But, you have a contract that says that they won't do that. >> Second, the only time the manufacturer's servers need to be alive is >> when device ownership is claimed. > i.e. when i sell the router to some other op. that was my second > question. Yes, so when you sell the router, whether or not the buyer gets firmware updates, the export firmware, or even a license is also up to the vendor, and so the vendor already has a say. This really changes nothing, except that it formalizes the arrangement in computer code rather than legal code. I'm not particularly happy about this, btw, but I don't see a way to both do secure imprinting and liberate the end user from vendor control. If you have a way to solve this tussle, I'd really like to know. >> Once the device is claimed, it joins *YOUR* network, and trusts your >> infrastructure, not the manufacturer. Whether or not the device will >> *operate* without the manufacturer's servers is really outside of >> BRSKI. > ahhh. we just sell the guns, we do not say how they are used. naw, we just sell 3D printers, we do not say how they are used. >> This is a pretty important question and we have discussed it at >> length. I remain concerned, but as far as I can see, we have this >> problem already. > if i understand correctly, it creates a new problem, needing the > manufacturer's consent for me to resell my light^Hrouter. Yes, but operators already had this problem. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluyu5cACgkQgItw+93Q 3WWKiQf+OPn8ipGAzsk4PKHSKUdQfgcpGmVTBFyEvyrMmR3xyi8PjCgLlp42tFU7 BL0qadKNE0LxYr2l7BwTxHNGJ1pYV+M0ZV02h9Vtjg1w/19t9qsUPCzkQkW1kbqQ 4eErnfLWBxzqK8Wduwu1EumbuNOGgm7G/RinljuS5X1wcfemlLUcp+Fw+R6VxP94 6HXoh4CCtcZOOYRIBi0aQJDwvJR4vH4FCL04Zv+AWjPMZFT2dLqVhJ5IFaTc5+Cg gfnZcgij+IhYzganB9nGzXA42oRHZqW5rSswPapyEfV9mJiEWLoAfPsn/820j6Aj r+8N1Lc0X/8YVg6PaRnny69G3oitHA== =A4CK -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 1 17:32:41 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E56126CB6; Mon, 1 Oct 2018 17:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KR9jyFwa94Er; Mon, 1 Oct 2018 17:32:29 -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 90461124C04; Mon, 1 Oct 2018 17:32:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0DF5620090; Mon, 1 Oct 2018 20:32:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B4C2F1537; Mon, 1 Oct 2018 20:32:28 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B13D5AE0; Mon, 1 Oct 2018 20:32:28 -0400 (EDT) From: Michael Richardson To: Randy Bush , Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org, Security Directorate In-Reply-To: <8303d9ed-237e-1960-cf2f-d277a92338f7@gmail.com> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <0cbdf93d-c432-57f5-5000-8595b006d6d0@gmail.com> <3136.1538342967@localhost> <8303d9ed-237e-1960-cf2f-d277a92338f7@gmail.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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 00:32:32 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > It's not quite that. > We sell X's. We cannot control how the X's are used. But if they are > used without calling home to our MASA, we cannot certify that they are > genuine X's. They might be counterfeit X's. Or, they might be genuine X's running trojaned's software. The fact that between leaving seller A and buyer C, they were activated by attacker M will be in the MASA's audit log, if buyer C looks. {Can attacker M replace software via serial console without leaving a trace? Not BRSKI's problem exactly, but it's certainly a concern} > BRSKI is a way of proving that the X announcing its identity as X12345 > really is the one and only X12345. > If you sell it to someone who doesn't care about that, they can use it > anyway. Depending upon the software in X, you may be able to hook up a craft/serial console and just configure it the way you want, just like you do today. Or it might be some new-fangled SDN switch that won't operate with a controller attached, and it doesn't even have a serial console. Nothing I can do will change that. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluyvJwACgkQgItw+93Q 3WVo7Af/fSlpLqGMU4OuRP1YaDhmUYOdT+OzYulfGPkqG6BQ1xzGAzdmoIGkVgHe yy/hck+z0NbI0eI3ekJIQ9exBtNXqo3xOrsWUMKvN1gN4PEqMnZ5BPm9wQTOJgB9 fLtReT2XGBhqIg4+vrtA+SWS/J/k0zGsVitGihG/qHASv5sCp0goM4feA21l9WfO ONksjiaJ0iHKK8QVDAu4J0B1eX1s4t5gm0JBJp/XtD2zGXj6OostdtB+MpZa0J25 NR//UCjG0Yr9pxhh3ojcBM1Wifjzv7z+CquQeBzY/rlDXFIFrU1qjOavlfsbSzwd mEhVpP3ov+nmF1KFwIM3qjPJhktBKw== =5AKc -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 1 18:07:09 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA42126CB6; Mon, 1 Oct 2018 18:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Sz9bMKQdw1GF; Mon, 1 Oct 2018 18:07:06 -0700 (PDT) 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 EFBC6124C04; Mon, 1 Oct 2018 18:07:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 13F5320090; Mon, 1 Oct 2018 21:07:04 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B54B21537; Mon, 1 Oct 2018 21:07:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B09B6AE0; Mon, 1 Oct 2018 21:07:04 -0400 (EDT) From: Michael Richardson To: Randy Bush cc: Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org, Security Directorate In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> 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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 01:07:07 -0000 --=-=-= Content-Type: text/plain Randy Bush wrote: >> The BRSKI specification is a tradeoff and that's why I would really >> like to see the tradeoff explained in clear terms in the spec. It is >> designed to prevent hijacking of the device during its registration in >> the buyer's network. > if, to actually own a device i bought, i need to manage my own > security, then i will take that. I think that this is already the case, and I see BRSKI as a mechanism by which to safely handoff control from the manufacturer to the owner. If the manufacturer doesn't want to do this, BRSKI isn't very useful to them. They should retain control of the device via their cloud infrastructure, and not let the end user have any control at all. > the manufactures have very small incentive to lower drm barriers. i > can point to a jillion current examples. my favorite of the week is > john deere. You are right. But at least it's clear that john deere actually owns the tractor, not the farmer and walk away from the mortgage. It's not a pretty picture, but I don't think we are making the situation worse: there is already DRM and TPM. What we are doing is making it clear that the tractor is actually owned, and not p0wned. However, I'm not sure that BRSKI has a value for large devices with real user interfaces. Maybe it has value for implements though. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluyxLgACgkQgItw+93Q 3WVrcAgAriqToqpvzaWt6001Z/RlAoVwhVBvoSZmFdCnn+Nwx/rnQDYjFJG0hijj T7bov2B2Vt56P8OEinl5Zwnq2l4qLAp8RuEU8m0rW0bOg9drKOR3F3+2IoZtdLH3 rdHEN7nrxN5yIo2PFtOIBj689nXOSxDfFZAQBbD928q9gAmHIrYEQOBhFzZYBqUL qIO2jqCv4XQbsgXO8Z46odUfliQ2H99qH8PuGIjhP2Y/377nhSZzu+MSVZx5x5tO PponiE49GwwEBkhMMxuIaGyvQ5CdwNWtmo06eysCIeTJ0EZzJmdZLshQ38ipcbBh EOku+ACO1n3vPzooRpYLA4PHKr/0hw== =oH9n -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 1 23:53:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2384D128B14; Mon, 1 Oct 2018 23:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpn4mBRPCXvj; Mon, 1 Oct 2018 23:53:34 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F77130E14; Mon, 1 Oct 2018 23:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2028; q=dns/txt; s=iport; t=1538463212; x=1539672812; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=VsSz0uQik/ipShhRjd/lMyOGAEDiH4WWl5nq8E97YFQ=; b=mT/sJftVoDs6055gt9XY2KDX8SM18FkSiK7h6Z51P8whZYxA7NCGJZQh HW9E259iTCoCAiQRZPqH6Wy5Diun1tvcvUlGFLABp/SP5MNC8pGcRg7Zp LLymoSoJ4Vkk1YTovcurMCn6TA33uq+eOe17znZwN4Tr0rVrFferpLS0I A=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAADZE7Nb/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGFMhKEHIh0jRstlnCBZggDhGwChDk4FAEDAQECAQECbSi?= =?us-ascii?q?FOQEFI1YQCxgqAgJXBgEMCAEBFYMIAYIBpTeBLooQD4JtiCuCAIE5gj0uhGe?= =?us-ascii?q?DGIJXAohklFYJhAGBaIpJBheBOgGHUoZNlTeBWSGBVTMaCBsVgyiCTI4JPY4?= =?us-ascii?q?AAQE?= X-IronPort-AV: E=Sophos; i="5.54,330,1534809600"; d="asc'?scan'208"; a="6935203" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 06:53:29 +0000 Received: from [10.61.94.24] (ams3-vpn-dhcp7705.cisco.com [10.61.94.24]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w926rSfN007880; Tue, 2 Oct 2018 06:53:29 GMT To: Randy Bush , Christian Huitema Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Tue, 2 Oct 2018 08:53:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mHBIiA4gvzbBGDATbrEUcoJNRYiH8F6qW" X-Outbound-SMTP-Client: 10.61.94.24, ams3-vpn-dhcp7705.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 06:53:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mHBIiA4gvzbBGDATbrEUcoJNRYiH8F6qW Content-Type: multipart/mixed; boundary="IZl78ocgpfyg34izfs8TvJSwcWYYJ9dre"; protected-headers="v1" From: Eliot Lear To: Randy Bush , Christian Huitema Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate Message-ID: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> In-Reply-To: --IZl78ocgpfyg34izfs8TvJSwcWYYJ9dre Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 02.10.18 00:44, Randy Bush wrote: > when i sell the lightb^Hrouter to mary, of course i reset to factory > settings. Great.=C2=A0 Mary can register the device with light^hrouter manufacturer= and life goes on. Eliot --IZl78ocgpfyg34izfs8TvJSwcWYYJ9dre-- --mHBIiA4gvzbBGDATbrEUcoJNRYiH8F6qW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAluzFeoACgkQh7ZrRtnS ejN90wf/Yen2BSSLhzd9SQbqRv8TyscrERJ/YE/U08do7pX2T7OdI4CCXmJmFGrT EvSiW0CEMwTniq1PUrFoCmXbzWI/4BW1gGSP+luds1Ch8zLsyLABfTz8+kYKzU87 v6ettBUBLVphgHwKdPh0KXkhqChyFgXsCLkstrpQSa2F9VLAbEkt0bo2DXzL2AoX MnjTtzPHhASBL217D0IjoR6v+SIgHij+dhTyLjeki6b+h0/mKsveXEEX9dk3R47K G4uM/Uh1255hNVTCEm05UyP0wyW8vzv84u6NYhqSI1+O+Ogh63JBy00Yh8n08d3Q hnvPYi+S3gw99/OPwyQg6TJ/EBxc2Q== =GjiY -----END PGP SIGNATURE----- --mHBIiA4gvzbBGDATbrEUcoJNRYiH8F6qW-- From nobody Tue Oct 2 04:21:45 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51730126BED; Tue, 2 Oct 2018 04:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 pj_TKCXGTmYp; Tue, 2 Oct 2018 04:21:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 58A19130DDD; Tue, 2 Oct 2018 04:21:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g7Ik2-0004fE-Mh; Tue, 02 Oct 2018 11:21:26 +0000 Date: Tue, 02 Oct 2018 04:21:25 -0700 Message-ID: From: Randy Bush To: Eliot Lear Cc: Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 11:21:33 -0000 >> when i sell the lightb^Hrouter to mary, of course i reset to factory >> settings. >=20 > Great.=A0 Mary can register the device with light^hrouter manufacturer > and life goes on. iff the manufacturer still exists and the manufacture is willing. you and others seem to be missing that there is a major right of ownership war going on out here in the real world. randy From nobody Tue Oct 2 05:28:48 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACC5130DF6; Tue, 2 Oct 2018 05:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSCG_jKCMB6v; Tue, 2 Oct 2018 05:28:30 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4472127598; Tue, 2 Oct 2018 05:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3584; q=dns/txt; s=iport; t=1538483310; x=1539692910; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=8Gv5Czrt/DhmoP2K9wKZdxr2S8OWXww42a/nZJ44jME=; b=h8hWIMhtw0RJM8fx7uJyooOd5UBprNR/DADq5PSY6tdbgFSJwCoSxvTk bXvJa6VSHD3lOColFPAINlaIkgOtUbGU2LsGM35AeW0D7DZWQNypFYvC1 Z4Kg8cygcOaqmTw3aU48y3Hvbku1Ap8CUuNqFaT3qsugtKNfuy1BcmLd9 Y=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiAAD4Y7Nb/xbLJq1aGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVINeEoQciHSNSZZwgWYIA4F3gnUChC43FQEDAQECAQECbSi?= =?us-ascii?q?FOQEFI1YQCxgqAgJXBg0IAQEVAoMGAYIBpTqBLooND4JtiC2CAIE5gW1QLoR?= =?us-ascii?q?ngxiCVwKIZJRYCYQBgWiKSQYXiQ2GTZVAgVgigVUzGggbFYMogiQXEY4JPY8?= =?us-ascii?q?AAQE?= X-IronPort-AV: E=Sophos; i="5.54,331,1534809600"; d="asc'?scan'208"; a="6884293" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 12:28:27 +0000 Received: from [10.61.94.24] (ams3-vpn-dhcp7705.cisco.com [10.61.94.24]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w92CSRgv003734; Tue, 2 Oct 2018 12:28:27 GMT To: Randy Bush Cc: Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> Date: Tue, 2 Oct 2018 14:28:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="981ih7QmMURQLEwL07H96ixPyUQlTuSjH" X-Outbound-SMTP-Client: 10.61.94.24, ams3-vpn-dhcp7705.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 12:28:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --981ih7QmMURQLEwL07H96ixPyUQlTuSjH Content-Type: multipart/mixed; boundary="caSgmM5l1X2XeNJf9IG7t9GzBummopEyD"; protected-headers="v1" From: Eliot Lear To: Randy Bush Cc: Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate Message-ID: <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> In-Reply-To: --caSgmM5l1X2XeNJf9IG7t9GzBummopEyD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Randy On 02.10.18 13:21, Randy Bush wrote: >>> when i sell the lightb^Hrouter to mary, of course i reset to factory >>> settings. >> Great.=C2=A0 Mary can register the device with light^hrouter manufactu= rer >> and life goes on. > iff the manufacturer still exists and the manufacture is willing. > > you and others seem to be missing that there is a major right of > ownership war going on out here in the real world. > > I think we've lost sight of what we're talking about.=C2=A0 We're talking= about a completely automated method for a local trust anchor to be installed on a device, and a kick to EST for the device to receive a local credential.=C2=A0 For that to happen there needs to be a trusted introduction, and the device manufacturer or its agent is in the best position to do that. There are many ways for a manufacturer to lock a device to a deployment without this, just one example being a software license that gets erased on device reset (remember?=C2=A0 you said you were going to perform a dev= ice reset).=C2=A0 I'd suggest that we not get wrapped around the axle over th= e ownership war.=C2=A0 I would be more concerned about what happens if the manufacturer goes out of business.=C2=A0 I think that's a bigger deal, but can I ask that w= e also consider that problem with some more experience under our belts?=C2=A0= I could easily envision a few solutions, but better would be to face down the problem with some more code and deployment.=C2=A0 BTW, manufacturer g= oing out of business also means no more {bug fixes, security patches, h/w support, etc}, and so zooming in and just dealing with this may be suboptimal. Eliot --caSgmM5l1X2XeNJf9IG7t9GzBummopEyD-- --981ih7QmMURQLEwL07H96ixPyUQlTuSjH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAluzZGwACgkQh7ZrRtnS ejPECQf9F1/qVd9vmNdYUyfWMxzHswq/ljodJwlnD2WMLIVDMvtrNIbnjMk3H9In ixpBK1q9+p9vlWdEnKHzICJvGusg/NVLO9FZm2UH/QSEVVNcFLtz/yUQSvXM33BC tPgwUUx3NtiaOtr2OnpK8897cBInoe4KxlC6V4y36RCNil9qsywBC972cIRCX0ab VbFmNGB0neAL4EOiVc3QAuBrXhehtEbQE8vutmtBUrMMLA9DOUAKH1UZ2yF0aiG2 630FXeStC+GUzZUydsJIk97QVAiik5dmz+ISxAqaQnCOPRSTrMYSUtctZnRxGYMV v3pex2jABm8Qt4JUYyXuL8nExnINUw== =WSHg -----END PGP SIGNATURE----- --981ih7QmMURQLEwL07H96ixPyUQlTuSjH-- From nobody Tue Oct 2 05:41:50 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47FD1277D2; Tue, 2 Oct 2018 05:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 jPB1ISBYmJRQ; Tue, 2 Oct 2018 05:41:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7DB21124D68; Tue, 2 Oct 2018 05:41:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g7Jzj-0005P5-9H; Tue, 02 Oct 2018 12:41:43 +0000 Date: Tue, 02 Oct 2018 05:41:42 -0700 Message-ID: From: Randy Bush To: Eliot Lear Cc: Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate In-Reply-To: <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 12:41:49 -0000 > I think we've lost sight of what we're talking about.=A0 We're talking > about a completely automated method for a local trust anchor to be > installed on a device, and a kick to EST for the device to receive a > local credential.=A0 For that to happen there needs to be a trusted > introduction, and the device manufacturer or its agent is in the best > position to do that. no. the owner's trust controller is. randy From nobody Tue Oct 2 11:20:29 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008D31310A7 for ; Tue, 2 Oct 2018 11:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 8Cc31AoqwyAz for ; Tue, 2 Oct 2018 11:20:09 -0700 (PDT) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 128A3131182 for ; Tue, 2 Oct 2018 11:20:06 -0700 (PDT) Received: by mail-yw1-xc31.google.com with SMTP id y14-v6so1166521ywa.4 for ; Tue, 02 Oct 2018 11:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gKbf2s4R/eQAFu+inewXkAYmdCohSvIIa8Uj5iPp1k0=; b=bewdmOUtrFUBMYNhltm5C6TaS50+u4nnUool8cPSfmcuFMGMtDidWmb5t6dP1EsRof UYwrxzK/om6yZ38gFbNFh0Lym6t30LXQ279zk+FX19ICay90+HcGiPZVCo/Nqzt4scjo F+puitzD9IPRHcJ+xgnVIEy6N6jzsKF0VvlpMtWW8AivwOFymKtDqdfuBj18qCQjmx9w Q22kdq3n+e3zdgakilHQuffR2xoQ8l9XFu1Hfgmugsjc1oYkUNABBUUTRV/PvhyIRmQv KxFk+EzjmBXDp2BLIuVaiU9g4/mmUZVlyAmi8zh4hGY2kp9lwHfm88MXuvGUTsoQnUPJ ZPFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gKbf2s4R/eQAFu+inewXkAYmdCohSvIIa8Uj5iPp1k0=; b=L3ZNWK91QHC1pLDdjTeSL7OExzCEB3CTwmuut1WqsYNy6eZJApAl9x7QXhOITeK+5k 9VJvhRELyBA3biDAf7ikb996IIKP297YzJzjqUeHYoiOSKIq6Rr3Q3xpvEjvqmmqsgKm KUJLKpvH3htKhAP7DGULTM856tzCGCLxMVpMmwZWXiH990lhOlG6kRRYWUjtDiQ51jjX QG8ng6U9YtWe53oQrZLZ3wguXwReSB/OkEvwtZuW4b0fcbMfozkIljPYCoQ1aV4fQVop apawK1hahkGa+X16S3dDziI1p/bMqhEmpZtgz2fG6mYF6vygryOPQuGY+Wlqv7YMly2B K9Eg== X-Gm-Message-State: ABuFfogM1ioZvKF514QPXU3GFu3+rlDBShHjjNKg0Af3lAUbqZzU6917 PhUmpY5oFOTnr+QPraAssPsQAA== X-Google-Smtp-Source: ACcGV62YMxFY8d4ashTiXpxZTrlL3yIhp5Lx5EUD+VlvDq7n+p5W1w/YELU8LzmN9tq6fBUtkjBBRw== X-Received: by 2002:a81:4fd4:: with SMTP id d203-v6mr9292894ywb.71.1538504406055; Tue, 02 Oct 2018 11:20:06 -0700 (PDT) Received: from [10.0.100.12] (c-73-167-89-221.hsd1.ma.comcast.net. [73.167.89.221]) by smtp.gmail.com with ESMTPSA id 200-v6sm6648664ywr.102.2018.10.02.11.20.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 11:20:04 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_85F2328B-CBC1-498D-9A7E-2A85ADB8C27B" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 2 Oct 2018 14:20:02 -0400 In-Reply-To: <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> Cc: Randy Bush , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, Christian Huitema , IETF Rinse Repeat , anima@ietf.org, Security Directorate To: Eliot Lear References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 18:20:17 -0000 --Apple-Mail=_85F2328B-CBC1-498D-9A7E-2A85ADB8C27B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 2, 2018, at 8:28 AM, Eliot Lear wrote: > I would be more concerned about what happens if the manufacturer goes > out of business. I think that's a bigger deal, but can I ask that we > also consider that problem with some more experience under our belts? = I > could easily envision a few solutions, but better would be to face = down > the problem with some more code and deployment. BTW, manufacturer = going > out of business also means no more {bug fixes, security patches, h/w > support, etc}, and so zooming in and just dealing with this may be > suboptimal. The manufacturer-going-out-of-business use case argues for there being a = way that a person with physical access to the unit can re-key it without = contacting the manufacturer. It also argues for open source, but = that's out of scope. :) --Apple-Mail=_85F2328B-CBC1-498D-9A7E-2A85ADB8C27B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Oct 2, 2018, at 8:28 AM, Eliot Lear <lear@cisco.com> wrote:
I would be more concerned about what happens if the = manufacturer goes
out of business.  I think that's a bigger deal, but can = I ask that we
also consider = that problem with some more experience under our belts?  = I
could easily = envision a few solutions, but better would be to face down
the problem = with some more code and deployment.  BTW, manufacturer = going
out of = business also means no more {bug fixes, security patches, h/w
support, = etc}, and so zooming in and just dealing with this may be
suboptimal.

The manufacturer-going-out-of-business use case argues for = there being a way that a person with physical access to the unit can = re-key it without contacting the manufacturer.   It also argues for = open source, but that's out of scope. :)

= --Apple-Mail=_85F2328B-CBC1-498D-9A7E-2A85ADB8C27B-- From nobody Tue Oct 2 11:27:10 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAFC130FF0 for ; Tue, 2 Oct 2018 11:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 DN2U3A4mJmOm for ; Tue, 2 Oct 2018 11:27:08 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 1F6CD130EF5 for ; Tue, 2 Oct 2018 11:27:08 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1g7PNs-00080m-S5 for anima@ietf.org; Tue, 02 Oct 2018 20:27:04 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1g7PNo-0008N9-GZ for anima@ietf.org; Tue, 02 Oct 2018 14:26:57 -0400 Received: (qmail 1304 invoked from network); 2 Oct 2018 18:26:53 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.134]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Oct 2018 18:26:53 -0000 From: Christian Huitema To: Randy Bush Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <9e9604ff-6c1e-87f3-9b5f-fa9d9e7535c3@huitema.net> Date: Tue, 2 Oct 2018 11:26:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <057bd957-06b4-824e-a7c8-214383819621@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rU0K0vHYo+5Zk65+YOG09x602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO2DwRKf1oV61KIEJHR619+RVjyn5UrUp4n4yKOOaq9Ax7yi21uJqQRoFbXPX0W9fFVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5qUALHGqxBO534sbPOpB/O05EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsezipi5yDiig4uL/e3hw9DLyIIhNd1CXx7oT7o95oVlwxifju3cO6Bau TfHrpfZDL1rFVfV8YwbQTud2ndj194c9/49qryIYbFFBOkVCXXzvNoACQcwXnrT9jVUoMBm9/34R FZ4oobg8BBg3Jq+ntzj0et0qR8A3RvoDZyRDjyEOGC6m92U/Rr2NiuKWX4lMKSmG+jVXBcM8SwpA GKcVWhlHYhj6eov8PPpEk6KkAxffDcStknsMa5xMcOok/WzPHhk7ic0+wIe9JFgmIv/ATh4OKnRQ uDY0Mm9V3b12yAdZ3vy4dDNddHGUz9B9NosalGMzzZ1TJCc1Jsz93JxBBgxpJBPvPDjBPaowofdk fHH45mUVrBsPGnNiJ83AD/4JscB0VTS+bY/ezHW1Vxxj2dVmDKpXV/g3aWnksZpz4kAf+OlNC4wc 2LkM7XQE4YLVklOegMwrtwdodggrHZMuX9HK X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 18:27:09 -0000 On 9/30/2018 10:42 PM, Christian Huitema wrote: > The BRSKI specification is a tradeoff and that's why I would really like > to see the tradeoff explained in clear terms in the spec. It is designed > to prevent hijacking of the device during its registration in the > buyer's network. By the way, there are many cases where the buyers and the manufacturers interests are well aligned, besides just securing the bootstrap. For example, consider the "router fell from the back of the truck" scenario. I assume that both the original buyer and the manufacturer will be interested to find out who the second hand buyer is. -- Christian Huitema From nobody Tue Oct 2 11:32:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0C5130FF5; Tue, 2 Oct 2018 11:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 tf7etlYMrFYR; Tue, 2 Oct 2018 11:32:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 CCDCF130FF3; Tue, 2 Oct 2018 11:32:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g7PTR-0006vU-1o; Tue, 02 Oct 2018 18:32:45 +0000 Date: Tue, 02 Oct 2018 11:32:41 -0700 Message-ID: From: Randy Bush To: Christian Huitema Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, IETF Rinse Repeat , anima@ietf.org, Security Directorate In-Reply-To: <9e9604ff-6c1e-87f3-9b5f-fa9d9e7535c3@huitema.net> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <9e9604ff-6c1e-87f3-9b5f-fa9d9e7535c3@huitema.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 18:32:48 -0000 >> The BRSKI specification is a tradeoff and that's why I would really >> like to see the tradeoff explained in clear terms in the spec. It is >> designed to prevent hijacking of the device during its registration >> in the buyer's network. > > By the way, there are many cases where the buyers and the > manufacturers interests are well aligned, besides just securing the > bootstrap. For example, consider the "router fell from the back of the > truck" scenario. I assume that both the original buyer and the > manufacturer will be interested to find out who the second hand buyer > is. yep. i like the idea of find my iphone, though it has not helped find a lost phone for me. but it is MY choice to use it. MY choice to register the phone with apple's add-on service. to quote myself from a private thread > i might have other relationships with the manufacture or third > parties, such as warranty, add-ons with non-ownership, color-matched > magenta paint, etc. but when i purchase the bleeping thing, i bloody > own it. randy From nobody Tue Oct 2 12:01:23 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1FE13119F; Tue, 2 Oct 2018 12:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oXa0kKzoKnpu; Tue, 2 Oct 2018 12:01:12 -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 1B9D2131184; Tue, 2 Oct 2018 12:00:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 996B920090; Tue, 2 Oct 2018 15:00:44 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 56E16230C; Tue, 2 Oct 2018 15:00:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 539CEAE; Tue, 2 Oct 2018 15:00:45 -0400 (EDT) From: Michael Richardson To: Randy Bush cc: Eliot Lear , Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org, Security Directorate In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 19:01:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable lear> I think we've lost sight of what we're talking about.=C2=A0 We're= talking lear> about a completely automated method for a local trust anchor to be lear> installed on a device, and a kick to EST for the device to receiv= e a lear> local credential.=C2=A0 For that to happen there needs to be a tr= usted lear> introduction, and the device manufacturer or its agent is in the = best lear> position to do that. Randy Bush wrote: > no. the owner's trust controller is. Cool. It's a relief to know that we've missed something obvious. Could you please explain things more? We call the owner's trust controller the "Registrar", or sometimes the Join-Registrar/Coordinator. I don't mind calling it a trust controller, but maybe your term has a different meaning. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluzwFwACgkQgItw+93Q 3WX/mwgAnfum05CcMHrt2QQkQH5q2EeRG/hlYzgDVWMmpGleZVjRSL2bVvHSgR7x jRI2FVEVRTQJsb1Gzayd/AUjSkMJeot65zFMlq1fgOurGe1fb8Mr+SEImgVJneu0 KBi62Mwl82fAy9IGVH5Ol/gGDII2HIYBu0h1WqQLAdg2HlbLkN4mLp9agVCFbs7i NVBfDuefwYfxA95DUnwOgdkkZaDzCa0Vc//fELZgEgTneoPT1BF6xWb5cI6n/UB+ uVyAGu7tCmkcPYpkRR3VQy1epn34/KcieujsAJbLXNLDeeCwGmaw21vDsj3ekOSs /FE0fDkYaYQyeeQVLlQpXqNDESspTQ== =dx7o -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 2 12:05:45 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD68131057; Tue, 2 Oct 2018 12:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gXEEmnjdydME; Tue, 2 Oct 2018 12:05:35 -0700 (PDT) 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 95824130EF5; Tue, 2 Oct 2018 12:05:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EC57D20090; Tue, 2 Oct 2018 15:05:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id ACB12230C; Tue, 2 Oct 2018 15:05:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A983BAE; Tue, 2 Oct 2018 15:05:34 -0400 (EDT) From: Michael Richardson To: Ted Lemon cc: Eliot Lear , draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, Security Directorate , Randy Bush , Christian Huitema , anima@ietf.org In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 19:05:39 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: > The manufacturer-going-out-of-business use case argues for there being > a way that a person with physical access to the unit can re-key it > without contacting the manufacturer. It also argues for open source, > but that's out of scope. :) The authors think that having the box rekeyed is a feature that some manufacturers will provide, and some buyers will **insist** upon. It has to be difficult, and in some cases, physical access may be too insecure! It's not much different than handing an (sometimes encrypted) QIC-tape/CD/DVD containing source code over to an escrow lawyer, something I've regularly done when I've worked on products with proprietary stacks. We will see such things being discussed when we do the security review for SUIT as well. Being able to replace the manufacturer trust anchors for firmware, and the trust anchor for validating ownership vouchers will become a checkmark feature. Any company can become Nortel. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluzwX4ACgkQgItw+93Q 3WVFtggAgxp6wjhFCaCigsZfOPvIvCliTwDF9LyJqzBgg12cmJJLRvQNujluf+xb pgt2BuYfZwCSkF0AtmK9sGaVHlAGvtT8EDJvMGtezhEud02z6FYx0PLvSuuBGVmz jxCVXYuQqES3NDaUdlx4dpafL/ICp1EWUzEAHasJTiN/YE3IsAunfn7nVcuMIyTv 1R+cJqBYG8hKhA8j5nOxJerNMiNI/SIWMQTZcQDfLmDxBxENrf6G8Lnz7jGAen58 b7TLty5sUGbse4Gmkt3lVeZMp79I6hoisxEIZ1gLIjDNkmY3/rkMPi0iaskkj2uY rd5dpMfXb+d1OWhFrOehwmVZcdijsQ== =zuNB -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 2 12:10:31 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480DE130EF5 for ; Tue, 2 Oct 2018 12:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 nIIGfMA9V2d6 for ; Tue, 2 Oct 2018 12:10:21 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 62342130DC2 for ; Tue, 2 Oct 2018 12:10:19 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id q4-v6so2998958iob.8 for ; Tue, 02 Oct 2018 12:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nq3Ae4ZSLV2QQq2AKAH76nAAemmvFkeIYqY8bxmcZt4=; b=JtK2+lzF+KzFrh1yIJ3o7EBLGQL+jO2hjiSI+EwmNC1NywsvXJA+/I216x/4galG90 vrF+LqIY8Bp2qSXECyod9ADDtd2f2iQnytdjxhh+mKFM0u0qRmWW/kqjX2V+jbWcYRlF SuJoXBlI85OCqsgHBj1PdX4C8l4ZIm9Rhk8QonfdaYCrvzOlt6f1V7DjT3fEu2pJv9et HajttE0ja45Yov/52M6V1TSs/zT6c/NfRfgLa4ZmYZDuEP+wh1YXys+sY+LWjNZk3SV6 lkd/P6rALFZeVaBy4Ccmqe713HT2USob7sAtufNV+tmSUyG15MmaQCl8zLOvwCDAorL+ Yocw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nq3Ae4ZSLV2QQq2AKAH76nAAemmvFkeIYqY8bxmcZt4=; b=V9FGlqMPt0pU/TjFFcUgWNrZNj/W/7B90x2S1CYHxTBwKMJCPfdXWGe9APfu+q0KNh UdqeLFrg/DPrs8Ti57S8AKOEzXMBR6FavFGFUADFjVB0QqkZ5Nt3MUGxyQGY+HtweZrD Vdw8H/5OHa7aQL05dpyic5LxnocnhYHcQj1ptRDz/0+btfwFOnV/tvaFdEie/QT4JAXZ 96XSduOq7x4V+hGcU0e22wsrxATFKEehL8a6yf4BTzp5knzBqv1ae9eqCYlwqjlT3mUf r5aKMTVllIaWULGmmYugJIg7cj0q/pGRU0bLUzdxKdFHEM1hJDQjGnrQN9c5PUqrRLmq lvVA== X-Gm-Message-State: ABuFfogqSGB2ME01ROGEKlyPouNT2bJpSAfAU1yaTfozVmg7YyBvPGzp Ax2ick9XG2KozecAqWbuW6eBiHsKB4KRbfJNjbPSE51QTOU= X-Google-Smtp-Source: ACcGV61wToRuIZ5KZ8TMrjFmib3lpRIrgJPzrbnXRUHzq2cd2lXhkdnwCEnmvWLEZzDYXs+bofF3UhoXWwZhgfTxGOM= X-Received: by 2002:a6b:dd11:: with SMTP id f17-v6mr11506671ioc.45.1538507418570; Tue, 02 Oct 2018 12:10:18 -0700 (PDT) MIME-Version: 1.0 References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <3590.1538507134@localhost> In-Reply-To: <3590.1538507134@localhost> From: Ted Lemon Date: Tue, 2 Oct 2018 15:10:07 -0400 Message-ID: To: Michael Richardson Cc: Christian Huitema , Eliot Lear , Randy Bush , Security Directorate , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000002b25f6057743ac43" Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 19:10:22 -0000 --0000000000002b25f6057743ac43 Content-Type: text/plain; charset="UTF-8" The problem is that possibly billions of devices will be bricked and landfilled before this becomes the norm. On Tue, Oct 2, 2018 at 3:05 PM Michael Richardson wrote: > > Ted Lemon wrote: > > The manufacturer-going-out-of-business use case argues for there > being > > a way that a person with physical access to the unit can re-key it > > without contacting the manufacturer. It also argues for open source, > > but that's out of scope. :) > > The authors think that having the box rekeyed is a feature that some > manufacturers will provide, and some buyers will **insist** upon. > > It has to be difficult, and in some cases, physical access may be too > insecure! > > It's not much different than handing an (sometimes encrypted) > QIC-tape/CD/DVD > containing source code over to an escrow lawyer, something I've regularly > done when I've worked on products with proprietary stacks. > We will see such things being discussed when we do the security review for > SUIT as well. > > Being able to replace the manufacturer trust anchors for firmware, and the > trust anchor for validating ownership vouchers will become a checkmark > feature. Any company can become Nortel. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --0000000000002b25f6057743ac43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The problem is that possibly billions of devices wil= l be bricked and landfilled before this becomes the norm.=C2=A0
=

On Tue, Oct 2, 2018 at= 3:05 PM Michael Richardson <= mcr+ietf@sandelman.ca> wrote:
mellon@= fugue.com> wrote:
=C2=A0 =C2=A0 > The manufacturer-going-out-of-business use case argues f= or there being
=C2=A0 =C2=A0 > a way that a person with physical access to the unit can= re-key it
=C2=A0 =C2=A0 > without contacting the manufacturer. It also argues for = open source,
=C2=A0 =C2=A0 > but that's out of scope. :)

The authors think that having the box rekeyed is a feature that some
manufacturers will provide, and some buyers will **insist** upon.

It has to be difficult, and in some cases, physical access may be too
insecure!

It's not much different than handing an (sometimes encrypted) QIC-tape/= CD/DVD
containing source code over to an escrow lawyer, something I've regular= ly
done when I've worked on products with proprietary stacks.
We will see such things being discussed when we do the security review for<= br> SUIT as well.

Being able to replace the manufacturer trust anchors for firmware, and the<= br> trust anchor for validating ownership vouchers will become a checkmark
feature.=C2=A0 Any company can become Nortel.


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



--0000000000002b25f6057743ac43-- From nobody Tue Oct 2 12:29:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE9B1310AB; Tue, 2 Oct 2018 12:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1cFNQPHfhqb; Tue, 2 Oct 2018 12:29:40 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19334130DC2; Tue, 2 Oct 2018 12:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2658; q=dns/txt; s=iport; t=1538508579; x=1539718179; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=aZBlvvK/8Jqw5z34euu9cRSzuuiIe9Vz6EH5TM5LMKU=; b=j8PpevJWc8/GOFsT+AfvqSm4T6YR3r5iqcHG54bKZVojZdukRpZyQ4Ln w3GgW75fnmb1NRtVgfkwbotJTubb/C+A3MLTj6VWU+dYKy61lOGQhnlVg M1C+Iey+hCbEwor1w1HfdD674ArDVXmz1sahl09UNLixcf6h3hMBnQc2e Y=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAACJxrNb/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGFMhKEHIh0jRwtmFYIA4RsAoQvOBQBAwEBAgEBAm0ohTk?= =?us-ascii?q?BBSNWEAsOCioCAlcGAQwIAQGDHQGCAadDgS6KCA+CbYgtggCBOYI9Lod/glc?= =?us-ascii?q?ChieXFQmEAYFohnuDTgYXgTqHU4ZNlUCBWSGBVTMaCBsVgyiCTI4JPY57AQE?= X-IronPort-AV: E=Sophos; i="5.54,333,1534809600"; d="asc'?scan'208"; a="6952553" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 19:29:36 +0000 Received: from [10.61.94.24] (ams3-vpn-dhcp7705.cisco.com [10.61.94.24]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w92JTbTZ013089; Tue, 2 Oct 2018 19:29:37 GMT To: Ted Lemon , Michael Richardson Cc: Christian Huitema , Randy Bush , Security Directorate , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <3590.1538507134@localhost> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <35fdaa10-426d-d732-717d-37a25207250b@cisco.com> Date: Tue, 2 Oct 2018 21:29:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aUK4cjAPDaFAxXhp6oO2m93j5ySncQt31" X-Outbound-SMTP-Client: 10.61.94.24, ams3-vpn-dhcp7705.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 19:29:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aUK4cjAPDaFAxXhp6oO2m93j5ySncQt31 Content-Type: multipart/mixed; boundary="Yjy9CSExcmEFZjcSJjAzdT8ycNyndjZYo"; protected-headers="v1" From: Eliot Lear To: Ted Lemon , Michael Richardson Cc: Christian Huitema , Randy Bush , Security Directorate , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org Message-ID: <35fdaa10-426d-d732-717d-37a25207250b@cisco.com> Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <3590.1538507134@localhost> In-Reply-To: --Yjy9CSExcmEFZjcSJjAzdT8ycNyndjZYo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Ted, On 02.10.18 21:10, Ted Lemon wrote: > The problem is that possibly billions of devices will be bricked and > landfilled before this becomes the norm. You really answered your own concern.=C2=A0 Nobody would put up with such= an approach that either intentionally bricked* a perfectly functional device.=C2=A0 We have to pay some attention change of ownership and organizations going out of business.=C2=A0 That's work to do, not a reaso= n to claim the sky is falling. Eliot --Yjy9CSExcmEFZjcSJjAzdT8ycNyndjZYo-- --aUK4cjAPDaFAxXhp6oO2m93j5ySncQt31 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAluzxyQACgkQh7ZrRtnS ejMr+Af/eHssFZmERHdMbzmxGqtjJR6dt1TdyWEAWiuQwL4rs+lhBEk/Ul6oWJcR fCa+E57Clf49Leq8gxySOE2c4P851uNlBDk/uZ4bdRWsrjsRW66eiGqayI9k0q6G CJoVQeKIANWRopD61WlbcOkB6My6LdIuxsSGgNPBAo9JQ0tgmwAk6iTkZrhfTK4G RsqHc4TU5Fw3IWBJL0R/ah4PjxQLqu+UcLixgxAQ3rbdhmxCEKOuq0rR5MErb0A3 gGq88IoWUXvJi7Dn1Yh97Gy3ez97J0q0F0Yx+9Mblth6Qxepo5v3bxdcRGh6rqrx M28U7I4bA84isHxdGG6WmiyjF/yWgw== =5x0e -----END PGP SIGNATURE----- --aUK4cjAPDaFAxXhp6oO2m93j5ySncQt31-- From nobody Tue Oct 2 12:31:19 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFEA130FF0; Tue, 2 Oct 2018 12:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 0BTN33tJmu7o; Tue, 2 Oct 2018 12:31:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 68825130EF5; Tue, 2 Oct 2018 12:31:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g7QNu-00077z-VF; Tue, 02 Oct 2018 19:31:07 +0000 Date: Tue, 02 Oct 2018 12:31:06 -0700 Message-ID: From: Randy Bush To: Eliot Lear Cc: Ted Lemon , Michael Richardson , Christian Huitema , Security Directorate , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org In-Reply-To: <35fdaa10-426d-d732-717d-37a25207250b@cisco.com> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <3590.1538507134@localhost> <35fdaa10-426d-d732-717d-37a25207250b@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 19:31:12 -0000 > Nobody would put up with such an approach that either intentionally > bricked* a perfectly functional device. https://www.nytimes.com/2016/01/14/fashion/nest-thermostat-glitch-battery-dies-software-freeze.html From nobody Tue Oct 2 12:46:34 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7D21310B0; Tue, 2 Oct 2018 12:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jyutI7u_Mx9; Tue, 2 Oct 2018 12:46:30 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 03B1A1310AB; Tue, 2 Oct 2018 12:46:30 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id c25-v6so158816pfe.6; Tue, 02 Oct 2018 12:46:30 -0700 (PDT) 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=RBJ1d0Y2FJ0NRy3aQO7xTgD4YIJfWRJgJmVbmoZdjok=; b=ZFV2IWrUXXfXHgIC1iZUhmRqaIbd/JlWUJGc//FMLjPO0hJJqdeTYg82Jc2PykC+3c jiNNOU5TH0awX8FALYAlVej1jRFXnvdQAhGqMCZGY3ckonaDRgFNGLwVgu66QLE/j0Uh SS01XG1iAKhaRTYBQaL5vNm8DaWEtmG/QGOA7VXsRK5R9A2uR1vncPKqF6/fRjT98KkB 1uac0LeszzJV1Jp32qbvJdA0wCgMQrzgJmAsIOAUll8yM8WstIfX/oBPvdVoJed/GqDo QZu5zA6GdkoMwwwiP91ul6yoyLvJUecV3T+CfJn4OAX16Zu7EqeJBwsX7Yv6o73hz0pG uTpQ== 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=RBJ1d0Y2FJ0NRy3aQO7xTgD4YIJfWRJgJmVbmoZdjok=; b=YYELoNQiQElnXi0cW47KIfqVj3PYoZ9LdtGrmjXdkQCDrf1bZR6zZvkAMN2z4HYV1f nfu6eKEt5x6U4padSRazm4ct4J8IlToTxJ+otb0xMFOc02toLj5NogvRDe+wbx5nNfyz XciGJDft17DlHQVTGIM43weaT4Sddky+K3JCY8G43grEDsIKw2RENpVtpZz75sbxo8WV b6ZwMnkg8sa5lZQnkwAia6om7+q8ZaYZ6w0hjP3+99T41MzVSxjqHBN7A/+8wKkYi4jx TIHFRqZqufNH9FCruy9ETcRXXJp8z+RIs3uKrqv1WpsbBHJYcG+N1BCfDQQbMImLk8Ps GBLA== X-Gm-Message-State: ABuFfojgTPvKE3hFyAD6PMhJFnU9sterNRw9LOA9TNMfKJFHDzVwed/w CmYLVwMk6DfdxU4YXr8dsvQfkf8a X-Google-Smtp-Source: ACcGV61PochD+3zjYIIuWVPtWqBAUu9VZrKLLBytR5u+YoypAtGY4kZK7Wgrux61JYZ8kOQwrNya6g== X-Received: by 2002:aa7:83cb:: with SMTP id j11-v6mr13844945pfn.91.1538509589229; Tue, 02 Oct 2018 12:46:29 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id w23-v6sm22499056pgi.18.2018.10.02.12.46.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 12:46:28 -0700 (PDT) To: Michael Richardson , Randy Bush Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, Christian Huitema , anima@ietf.org, Eliot Lear , Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> From: Brian E Carpenter Message-ID: <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> Date: Wed, 3 Oct 2018 08:46:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2555.1538506845@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 19:46:32 -0000 On 2018-10-03 08:00, Michael Richardson wrote: >=20 > lear> I think we've lost sight of what we're talking about.=C2=A0 W= e're talking > lear> about a completely automated method for a local trust anchor = to be > lear> installed on a device, and a kick to EST for the device to re= ceive a > lear> local credential.=C2=A0 For that to happen there needs to be = a trusted > lear> introduction, and the device manufacturer or its agent is in = the best > lear> position to do that. >=20 > Randy Bush wrote: > > no. the owner's trust controller is. >=20 > Cool. It's a relief to know that we've missed something obvious. > Could you please explain things more? >=20 > We call the owner's trust controller the "Registrar", or sometimes the > Join-Registrar/Coordinator. I don't mind calling it a trust controller= , but > maybe your term has a different meaning. There's a point that close followers of Anima may know and that others don't. There is a topic intentionally missed out of the BRSKI document, which is how the registrar decides whether a particular device, let's say device X12345, is allowed to join the secure domain in question. This point is skated over in the draft; in fact there is a text glitch in section 5.2 where it should be stated, already known to the authors. (Sorry, but we didn't find that text glitch soon enough to fix it before the IETF Last Call.) The actual authorization mechanism - "X12345 is allowed to join" - is not part of BRSKI. It is, as Randy rightly implies, not the business of the manufacturer. The MASA is used only to verify that X12345 is in fact X12345. It's part of the trust model, not the authorization model. If I had my wishes, the MASA would be optional, with a local voucher store in the registrar as the alternative. But that wasn't the WG consensus. Brian From nobody Tue Oct 2 13:06:41 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCB91310AB; Tue, 2 Oct 2018 13:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 iQtVikfWfYFS; Tue, 2 Oct 2018 13:06:37 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 B4974130FF0; Tue, 2 Oct 2018 13:06:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 96A1A1C040A; Tue, 2 Oct 2018 13:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538510797; bh=hevd1REdMoVykcFAStM2DCVxDMn/oeww/1WH7NXP5dA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bSK1L2kgKsE91gkVFyUwGIrb6pWIdOdCU75sXZERVhdBWQY9DcmPgZm/x8JkVZWYT 1CZVrToCA/3BaHPuB7ICM8vpxAIVc2tec2EF5kXqVKkhZY45FYxsPSttLYRSU1ZH05 NY53qCoRcWsJcvo8AVBy5QWg4FlMj3NeJisXjHJA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id DA29F1C00E2; Tue, 2 Oct 2018 13:06:35 -0700 (PDT) To: Brian E Carpenter , Michael Richardson , Randy Bush Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, Christian Huitema , Eliot Lear , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 2 Oct 2018 16:06:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 20:06:39 -0000 Off-list: It sounds from you rnote like either: 1) Anima admission process is seriously underspecified in a way that affects itneroperability, or 2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and advanced (if desired) by some other working group. I doubt either is your intention. And statements such as Eliot's ill-formed comment that no one would do that do not help the case for the Anima WG having thought this through. Yours, Joel On 10/2/18 3:46 PM, Brian E Carpenter wrote: > On 2018-10-03 08:00, Michael Richardson wrote: >> >> lear> I think we've lost sight of what we're talking about.  We're talking >> lear> about a completely automated method for a local trust anchor to be >> lear> installed on a device, and a kick to EST for the device to receive a >> lear> local credential.  For that to happen there needs to be a trusted >> lear> introduction, and the device manufacturer or its agent is in the best >> lear> position to do that. >> >> Randy Bush wrote: >> > no. the owner's trust controller is. >> >> Cool. It's a relief to know that we've missed something obvious. >> Could you please explain things more? >> >> We call the owner's trust controller the "Registrar", or sometimes the >> Join-Registrar/Coordinator. I don't mind calling it a trust controller, but >> maybe your term has a different meaning. > > There's a point that close followers of Anima may know and that others > don't. There is a topic intentionally missed out of the BRSKI document, > which is how the registrar decides whether a particular device, let's > say device X12345, is allowed to join the secure domain in question. > > This point is skated over in the draft; in fact there is a text glitch > in section 5.2 where it should be stated, already known to the authors. > (Sorry, but we didn't find that text glitch soon enough to fix it before > the IETF Last Call.) > > The actual authorization mechanism - "X12345 is allowed to join" - is > not part of BRSKI. It is, as Randy rightly implies, not the business > of the manufacturer. > > The MASA is used only to verify that X12345 is in fact X12345. It's > part of the trust model, not the authorization model. > > If I had my wishes, the MASA would be optional, with a local voucher > store in the registrar as the alternative. But that wasn't the WG > consensus. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Oct 2 13:19:56 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B98F131141 for ; Tue, 2 Oct 2018 13:19:54 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 sI1Vtp3HcntV for ; Tue, 2 Oct 2018 13:19:52 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 24DDB131110 for ; Tue, 2 Oct 2018 13:19:52 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id 184-v6so1385074ybg.1 for ; Tue, 02 Oct 2018 13:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gNcZI4A4jGUAgvXuXZcGiDSHOvkTK6za+K6iBmm8b6E=; b=AL+nQntQcPA+ozbZhm3251HeDrxN1qN851aj+gPC5ujeOFbxxcOOr+aAL4+U/XEm4o DWGlAT9bsCG67bCguzVRpbfrKhi9xgzwc6Uq/0T9GDxFwX9g4oXUWxCyOQtB3p9rSQYR aR8LK980MX6LxH5q51uJ3oNsldBt0OFEAmKM2f/mfw/dY9ifjNHUfJ6kHtlC5X+WqQ82 57XA80jlujtPSaHibIxyp5oDeBmHI3OWDlpVhfpAnINiXgVl3+6QSipUiwA6nlnNHd2k HDohRIyrqvMXnaci3bjbZXUXCX+nBra/TS0zeg8QOTcejJ6/UXJnC/fX1bnk8kJPL3PN MebA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gNcZI4A4jGUAgvXuXZcGiDSHOvkTK6za+K6iBmm8b6E=; b=R1zF7Gy2Cr/E3ByR4MjYjj7f2BkjG6XqsjLQGU1f+KEiS92BTUK9RRL7s8vPgikS6M aC0RmJmtA3OxJ+/FHMKSlpU2idRhay7QzEQH76oKTroYSI5T6r2DEDkxJpGizc3EzVq4 CU1zyiXPcwEb8A8rK3hjOz3z+OSWyA2CFcGbnNpRG8aAc1iT5Jq76+j/HKaxPeeQbFul Y2BXtdDnIMJU2fYiIKPoHu/mHyOpGQFk+73qElwNSkbPn8UJ32eGZqHNft6yEP0F/TVf MRTLxqVedvOXV6WuiI1DEymnE16G7mcT0PXDyugmHX8nT3MDAntAT7d9goQ7PyYGXBMU zNVA== X-Gm-Message-State: ABuFfojpSwfh0qz/mDMdkchYBkyd5/u+eJauB9HSdzVLaE3RVqSTowpY mwzTAlaviirDLUwkymn3mzBb0nLIkgLpiw== X-Google-Smtp-Source: ACcGV63oB5/UJRSyB+dR4rjmstBY+c+rGQnWGjJx4lJvW2yLCd1Fi0/R3WeWfFvOCiByppLExS4r8Q== X-Received: by 2002:a25:c4c4:: with SMTP id u187-v6mr9975599ybf.413.1538511591274; Tue, 02 Oct 2018 13:19:51 -0700 (PDT) Received: from [10.0.100.12] (c-73-167-89-221.hsd1.nh.comcast.net. [73.167.89.221]) by smtp.gmail.com with ESMTPSA id h13-v6sm6371372ywc.100.2018.10.02.13.19.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 13:19:48 -0700 (PDT) From: Ted Lemon Message-Id: <8B8C96FF-69D2-4ED5-A961-068C975C6D4E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E2A689A8-8703-4BAD-B5E3-DEE8EC6CCA69" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 2 Oct 2018 16:19:46 -0400 In-Reply-To: <35fdaa10-426d-d732-717d-37a25207250b@cisco.com> Cc: Michael Richardson , Christian Huitema , Randy Bush , Security Directorate , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org To: Eliot Lear References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <3590.1538507134@localhost> <35fdaa10-426d-d732-717d-37a25207250b@cisco.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 20:19:54 -0000 --Apple-Mail=_E2A689A8-8703-4BAD-B5E3-DEE8EC6CCA69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 2, 2018, at 3:29 PM, Eliot Lear wrote: > You really answered your own concern. Nobody would put up with such = an > approach that either intentionally bricked* a perfectly functional > device. No one would put up with it if they anticipated it. The problem is = that they might not anticipate it. It's the kind of risk that the end = user might simply not imagine. --Apple-Mail=_E2A689A8-8703-4BAD-B5E3-DEE8EC6CCA69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Oct 2, 2018, at 3:29 PM, Eliot Lear <lear@cisco.com> wrote:
You really answered your own concern.  Nobody would put = up with such an
approach that either intentionally bricked* a perfectly = functional
device.

No one would put up with it if they anticipated it.   = The problem is that they might not anticipate it.   It's the kind = of risk that the end user might simply not imagine.

= --Apple-Mail=_E2A689A8-8703-4BAD-B5E3-DEE8EC6CCA69-- From nobody Tue Oct 2 15:44:49 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A701311BD; Tue, 2 Oct 2018 15:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Rfif9sPjQodK; Tue, 2 Oct 2018 15:44:45 -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 E043D13119F; Tue, 2 Oct 2018 15:44:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 90FEB20090; Tue, 2 Oct 2018 18:44:42 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 811BD230F; Tue, 2 Oct 2018 18:44:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7D78D230C; Tue, 2 Oct 2018 18:44:42 -0400 (EDT) From: Michael Richardson To: Ted Lemon cc: Christian Huitema , Eliot Lear , Randy Bush , Security Directorate , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <3590.1538507134@localhost> 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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 22:44:47 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: > The problem is that possibly billions of devices will be bricked and > landfilled before this becomes the norm. It is very sad. Maybe some will get firmware upgrades, but I doubt it. So we should hurry up and get to his out there, so we can learn how to do it correctly sooner. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluz9NoACgkQgItw+93Q 3WXW3ggAg+kQMcgoM0Tyxp/E+o9GWnuP+YNLdmVu+pk9QzXcXC1b8V5rlokCzlsZ DcylByUvh1DCQxbdSQeMs53ncWzybrsA0OaFDoiTnSbwuxBOhPfVC7Pz2tzWkK+8 IbDaiNN6LnPU6B/izImf1y48CjUBoq7eo/isWZ9lUqnZkm2Yoo11MTErmrX5rA4E CPnycxympdEeqcRfhxxMhBrisGq2y9DCOVbd+uaQtTB0QPHA1wz9GovvlnH6cMzT e2y2go6v/ZgHfr8/1mGF7qUErECP8rkI+6YqYNfgu8XsGj0lx8KRBR3wSCmgG7Jw bA2yJ2/lQHJyvn37Vqc0raZMCF0xiA== =TcLR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 2 15:46:17 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9031311AE; Tue, 2 Oct 2018 15:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 f2rWZpDwzrRJ; Tue, 2 Oct 2018 15:46:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2DDE313119F; Tue, 2 Oct 2018 15:46:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g7TQV-0007oS-Rt; Tue, 02 Oct 2018 22:46:00 +0000 Date: Tue, 02 Oct 2018 15:45:59 -0700 Message-ID: From: Randy Bush To: Michael Richardson Cc: Ted Lemon , Christian Huitema , Eliot Lear , Security Directorate , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org In-Reply-To: <21256.1538520282@localhost> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <3590.1538507134@localhost> <21256.1538520282@localhost> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 22:46:10 -0000 > So we should hurry up and get to his out there, so we can learn how to > do it correctly sooner. definitely important to rush and not be distracted by warnings about the model being sorely broken. randy From nobody Tue Oct 2 15:53:07 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136271311C0; Tue, 2 Oct 2018 15:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qQKT3yRnMO-M; Tue, 2 Oct 2018 15:53:04 -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 64E411311BD; Tue, 2 Oct 2018 15:53:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A7CD20090; Tue, 2 Oct 2018 18:53:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4DB45230F; Tue, 2 Oct 2018 18:53:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4A600230C; Tue, 2 Oct 2018 18:53:03 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, Security Directorate In-Reply-To: <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 02 Oct 2018 22:53:06 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > If I had my wishes, the MASA would be optional, with a local voucher > store in the registrar as the alternative. But that wasn't the WG > consensus. So you speak of non-expiring nonceless vouchers with wildcard for the domain owner, that would come with the device? I.e. a bearer voucher/token on a QR code. We decided that such a thing was fraught with issues. So we painted around it, and declared that version out of scope for now, because we didn't think we were smart enough to figure out the security implications of it. (We did this in RFC8366, btw) In particular, we did not think it had a place in the medium to high-value devices that we expect ANIMA ACP BRSKI to deal with. [i.e. routers, VM hosts, NAS boxes... not light bulbs] I think that there are better ways to deal with a bearer voucher, and that a layer of intermediation would help with the issues possible with a bearer token. This may suit "ship and mostly forget" situation, but I also think it's squarely an IoT application, rather than appropriate for BFRs. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluz9s4ACgkQgItw+93Q 3WXdLQf9GijHIAS02WZjDn3PduieBs3dvkC+jifm4j4415CDky/1Wp+jyWA4NVw2 fHPiDh+bTOTjsSzrQI8RVL5UAiZp01Wggp56W8ayuPUk3cBPtABHDQ/9oLvLwGc/ lo4OLVcvWVKTGs2T+tCpOQcUHlS4oKI1gRGU2ryYkkAuI1xwXGn6up7jsvHfFm+D xb0h4BuMuz4tLs/ErH0LwZk20VjXHntNlaIwagWtczeseukx78QmD6CdyzFW0IrB J5qMsxm7Cv6R5XZWFrnN5F+3/DXQP8hwj9xbbuIAOSB4Zj6dpL9xS2w4eOKfiKAU /Y+lmEtdWR/gA4lQ2vja8ReNju3OEw== =eJ1x -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 2 17:33:31 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B390131160; Tue, 2 Oct 2018 17:33:30 -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_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 yqAevghqzOql; Tue, 2 Oct 2018 17:33:27 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 BFDB11310E0; Tue, 2 Oct 2018 17:33:27 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id n31-v6so712830pgm.7; Tue, 02 Oct 2018 17:33:27 -0700 (PDT) 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=lGHesTmntO24QfXW32IfliD4vnz12JRxKcYPYF2b0sY=; b=s//ZP/JYqpRgkxwSaZBdKX/zHsLv8gbuHbsK8e9LUzPrnlP7DUnR3p4oa/LmXIiNGU irgTlE0wuQmkeW0mQ12wTTJrwQBw0d7RX1B8SFMjSL7nFpvHF4UL+a7EhADXp/ldI5X7 CazI+dXeJ8/H20GpaZ6+EDTGA0uhTwxeeG0fb6Wt2101JMU5VFP+nh8hkSutoMFcO5VS ztKdBeQaZuPfXvV1abIGUlfecySyQ5RozKd9wzufZlmyGA+ehSMmbvLfQXxOENI10wk7 hnPZ4vUESVSJ5vRPqqF1btYC+Nniksxqtn1gHy00Ap1+1Qv1oMK2Y/NjMGZJZfsbSZs7 Xp4A== 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=lGHesTmntO24QfXW32IfliD4vnz12JRxKcYPYF2b0sY=; b=ajnfkgE2dTQUgwfAwjMegxue+7Dn/PQv1WczB43eWIFYbuhpbjzHFis9M7BvP/xrsj e2yFcI9fBsTnY7aAt7duKTsVqMytahTXbmMIruFCivprmMXxzF86sDE9M1gXmqr5JAzD MKxPSO9uW4vdaacfTJUsOGcr3EETzRH1WG+96JRYENP1kWp4al3XNXWBY6pJ8HzYcnzd 7gHwXD4FzATnqDKiMinVKGOo9UJ+pYSip4vN++djtFpGxNtq3pCf/50WCDVJb2i/mOpJ d/10DIFMSJ1m7/AJNeVWCSJ5eKpco6v0Qpz942o/IqiH/jkgXq13uJBflEEe2VCv8rnM Y53A== X-Gm-Message-State: ABuFfog0KqiLD6LdEPwyxLnwbNgEnYANyWcYK5//HywcS8hdCG+bKrin AL++UYXtKxZYuyxrc+QjT9Vzdxfl X-Google-Smtp-Source: ACcGV60f2v0qyJQb4VUbBJ28XlFiOVUndAV1T2Hq+AJkGKBu2X0nK3iU8LUxInYsXioVTIjXO3dxxw== X-Received: by 2002:a63:2106:: with SMTP id h6-v6mr16232693pgh.161.1538526806849; Tue, 02 Oct 2018 17:33:26 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id p17-v6sm22837086pfk.186.2018.10.02.17.33.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 17:33:25 -0700 (PDT) To: "Joel M. Halpern" , Michael Richardson , Randy Bush Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, Christian Huitema , Eliot Lear , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> From: Brian E Carpenter Message-ID: Date: Wed, 3 Oct 2018 13:33:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 03 Oct 2018 00:33:30 -0000 On 2018-10-03 09:06, Joel M. Halpern wrote: > Off-list: >=20 > It sounds from you rnote like either: > 1) Anima admission process is seriously underspecified in a way that=20 > affects itneroperability, or No, it's *intentionally* underspecified w.r.t. authorization. The registr= ar is part of a specific autonomic networking implementation, so I think it'= s OK that this is not standardized. Once there is established practice, it might be time to revisit this. =20 > 2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and=20 > advanced (if desired) by some other working group. I think BRSKI has the misfortune of being potentially quite general, but it is in fact required by Anima as the basis for the initial secure substrate. > I doubt either is your intention. Indeed not. > And statements such as Eliot's ill-formed comment that no one would do = > that do not help the case for the Anima WG having thought this through.= I think it's been thought through but badly articulated. In that sense, the Last Call is doing its job. Brian >=20 > Yours, > Joel >=20 > On 10/2/18 3:46 PM, Brian E Carpenter wrote: >> On 2018-10-03 08:00, Michael Richardson wrote: >>> >>> lear> I think we've lost sight of what we're talking about.=C2=A0= We're talking >>> lear> about a completely automated method for a local trust anch= or to be >>> lear> installed on a device, and a kick to EST for the device to= receive a >>> lear> local credential.=C2=A0 For that to happen there needs to = be a trusted >>> lear> introduction, and the device manufacturer or its agent is = in the best >>> lear> position to do that. >>> >>> Randy Bush wrote: >>> > no. the owner's trust controller is. >>> >>> Cool. It's a relief to know that we've missed something obvious. >>> Could you please explain things more? >>> >>> We call the owner's trust controller the "Registrar", or sometimes th= e >>> Join-Registrar/Coordinator. I don't mind calling it a trust controll= er, but >>> maybe your term has a different meaning. >> >> There's a point that close followers of Anima may know and that others= >> don't. There is a topic intentionally missed out of the BRSKI document= , >> which is how the registrar decides whether a particular device, let's >> say device X12345, is allowed to join the secure domain in question. >> >> This point is skated over in the draft; in fact there is a text glitch= >> in section 5.2 where it should be stated, already known to the authors= =2E >> (Sorry, but we didn't find that text glitch soon enough to fix it befo= re >> the IETF Last Call.) >> >> The actual authorization mechanism - "X12345 is allowed to join" - is >> not part of BRSKI. It is, as Randy rightly implies, not the business >> of the manufacturer. >> >> The MASA is used only to verify that X12345 is in fact X12345. It's >> part of the trust model, not the authorization model. >> >> If I had my wishes, the MASA would be optional, with a local voucher >> store in the registrar as the alternative. But that wasn't the WG >> consensus. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > . >=20 From nobody Tue Oct 2 17:46:28 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F538131161; Tue, 2 Oct 2018 17:46:18 -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_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 a18_4sl5p5ky; Tue, 2 Oct 2018 17:46:16 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 DB45D131160; Tue, 2 Oct 2018 17:46:15 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id w14-v6so2556557plp.6; Tue, 02 Oct 2018 17:46:15 -0700 (PDT) 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=14+vZkBR0q65GO8kRo7KL5vDp5jlXDx0kwvB33wsH64=; b=gQfAcsnc9YD9Lbl9FShiLWx+/MXfiwWPz9ifBTulWer9Gaz0hXdY3Gys/dH+vWd9iS /eMRWoUnl6PCWLXAFuOxwZRqt7wi1ik/zqiyca43I9Fp8pxIaYyhjPebDfglQO2zdNab hUerckumv5HpD0bziG+T47nSeY5L+sttq6yHwgZrJiWqUSbDW1m0xc+6yPRr/WYt0/M7 TFDRmW3VKzs1lshZnRKIHc4DGS3ye51HXDi6PALIhKh+8JIf8FeMfwQI1OnW/DL77nU9 REcg4BiIT2RsC9r43sQzPKgeo6Gxgq7UvjxEJvucwRID/qlsHSbR34I+r+Ub+mo61xVK V4EA== 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=14+vZkBR0q65GO8kRo7KL5vDp5jlXDx0kwvB33wsH64=; b=L6MGFJbL1OYI/D7pMf21OEixLPBi0BaN8hHSHV2usslEhKJiV6l/OijpDOZ4u68q3C HKQN7LdLXZOe19gnWMlh9XHVbkUiK1fKsyMA+AGRaoWNWTntQFCAv9pTR1SeqEX/P3k7 qeF8xfc2Wf0JSbRV8lmdcU+Y0yJYHdOWbYC/4ilKErVBHTPB89VlgW1s552FAs1d60Cc cAhzNHOLXVNYdOuFUdjgWnX6VG2Q0cplUKXpiMGCeMw99v3MiHO85Gf9dy/AJXedGJhX z/Oqnu4g3Hx6WKEJvUDmhND6vv+AmNKJJZxUNef/G1JWzHNRsFTpnCWI4yEJPUcOe0V5 x42w== X-Gm-Message-State: ABuFfogPXl4LxJLg8zk+32B8TNnQwMrUQEF+1hfU3dT+wFxoiZh1d4VZ L4Yh/QzK8aZ4dW4F5c2r6CqBgwH3 X-Google-Smtp-Source: ACcGV62ztK5YmRSKBb/bccG6Vzu+IVXdNmwpk4MQaLh33on3bpCicp5DTxM4I6hc0dYX0TAqmh4gJw== X-Received: by 2002:a17:902:f096:: with SMTP id go22mr19254125plb.235.1538527574985; Tue, 02 Oct 2018 17:46:14 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id f15-v6sm22080442pgv.66.2018.10.02.17.46.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 17:46:14 -0700 (PDT) To: Michael Richardson , anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> <23133.1538520783@localhost> From: Brian E Carpenter Message-ID: Date: Wed, 3 Oct 2018 13:46:09 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <23133.1538520783@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 03 Oct 2018 00:46:19 -0000 On 2018-10-03 11:53, Michael Richardson wrote: > > Brian E Carpenter wrote: > > If I had my wishes, the MASA would be optional, with a local voucher > > store in the registrar as the alternative. But that wasn't the WG > > consensus. > > So you speak of non-expiring nonceless vouchers with wildcard for the domain > owner, that would come with the device? I.e. a bearer voucher/token on a QR code. > > We decided that such a thing was fraught with issues. > > So we painted around it, and declared that version out of scope for now, > because we didn't think we were smart enough to figure out the security > implications of it. (We did this in RFC8366, btw) > > In particular, we did not think it had a place in the medium to high-value > devices that we expect ANIMA ACP BRSKI to deal with. > [i.e. routers, VM hosts, NAS boxes... not light bulbs] There are issues with not doing it too. I think the thing right now is that the draft doesn't explain itself properly, hence this discussion. I'm still gnawing on my original bone: if I was running a highly secure, personnel-safety-critical network, like the particle accelerator control network I used to run for a living, I *would not* allow it to rely on masa.vendor.com, and it would be physically impossible to do so because there would be no physical link anyway. I would get my vouchers some other way. This is not light bulbs either. I believe this can be fixed by clearer scoping of the document, and by renaming the "lower security" section as "alternative trust models" or something. Brian > I think that there are better ways to deal with a bearer voucher, > and that a layer of intermediation would help with the issues possible > with a bearer token. This may suit "ship and mostly forget" situation, > but I also think it's squarely an IoT application, rather than appropriate > for BFRs. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Oct 2 17:53:07 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1107313116D; Tue, 2 Oct 2018 17:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 bcGdxg4LoDpH; Tue, 2 Oct 2018 17:53:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 9A25D131161; Tue, 2 Oct 2018 17:53:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g7VPL-0002tW-Cr; Wed, 03 Oct 2018 00:52:56 +0000 Date: Tue, 02 Oct 2018 17:52:54 -0700 Message-ID: From: Randy Bush To: Brian E Carpenter Cc: Christian Huitema , Eliot Lear , anima@ietf.org, Security Directorate In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 03 Oct 2018 00:53:05 -0000 > I think it's been thought through but badly articulated. In that sense, > the Last Call is doing its job. does that mean that i can stop trying for a narten medal, go back to work, and christian will wake me up again when my two scenarios have clear answers; one hopes ones with which i can live? also, please tell me that i do not need to stick my nose into the rest of anima in order to let the user unequivocally own what they buy. i have my own rabbit holes to pursue in the ietf. randy From nobody Tue Oct 2 18:07:00 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D92F131186; Tue, 2 Oct 2018 18:06:53 -0700 (PDT) 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_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 QyqI2iBFYGJi; Tue, 2 Oct 2018 18:06:51 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 D5500131160; Tue, 2 Oct 2018 18:06:50 -0700 (PDT) X-AuditID: 12074423-449ff70000003967-47-5bb416275ee0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id FC.B9.14695.82614BB5; Tue, 2 Oct 2018 21:06:48 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w9316kaN016955; Tue, 2 Oct 2018 21:06:46 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w9316Tjm020646; Tue, 2 Oct 2018 21:06:34 -0400 Received: from W92EXHUB12.exchange.mit.edu (18.7.73.21) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 2 Oct 2018 21:06:12 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.191]) by W92EXHUB12.exchange.mit.edu ([18.7.73.21]) with mapi id 14.03.0352.000; Tue, 2 Oct 2018 21:06:36 -0400 From: Uri Blumenthal To: Brian E Carpenter CC: "anima@ietf.org" , Eliot Lear , "Security Directorate" , "randy@psg.com" Thread-Topic: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 Thread-Index: AQHUWhyykvn3lDncMkaktwy1V6dY16UMEvCAgAASvACAAAOzAIAAaeeAgAAMuYCAAAWrAIAASoeAgAAFeQCAAAPSAA== Date: Wed, 3 Oct 2018 01:06:35 +0000 Message-ID: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-2355C6F5-6A50-4EF0-A770-4BF45955DEF9"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02Te0hTURzHO/fe3Z2JN2/zsZMW1M3A10zRYlRERIVRfxT1RySRN3fmVtuU e7fQCjJ6a4WaxVykzkfQyh5qmdJDV1EqmD0FwWBimQ7Diohmr3t3e/jf93e+n/P9nsO9B5La JjoWWuwOLNh5K0eHUVpN9AJ9QkxrdpqvZpHBXzdAGI4+u0cYvvw8ThneHRkjDJMeP7VSlVU5 dUOV1e4eUmc1NHwjss5WnQcbqW1hy43YatmDhUUrcsLMgdZusuCFvvDcKS9dDC4nlQANRGwm qugYpktAGNSy9QR64PpAKMN9gM40TpLK8AigMU/HH6wNoGMPTgJl8AIUfP6aksNolkOTw80h HcVmoIMlvSoZIlkPQO86nxKyEcliNNVXARTIhMpfBQlF70ITwaGQpth4NHqzmpQ1wy5FD6ub KKWtnUJ9dwK0bGjYJPR5tDzUBtgY9LXnSmgzyerQ4EgNoVwvCvmf9dKKjkE/O/y0cqJzAFVf vaFSGmah7qoRqgzEuKftd0/n3NM4N4CSkYLOeIDCJ6OLngCp6GXIFeyiFb0YBR59/MPMR5Wl fnUtgF4w12jbq7fxFquIc/ViLm+3Y0G/JNVmcaRio7MZyN9dvXrBbTB2er0PsBBw4UxOTUu2 VsXvEYtsPjAbElw0E26TlmbuzDcWmXnRvENwWrHoA/FS1/D1y/0glrLn2zEXxZzmJY4x8kV7 sZD/F4uDFKdjyg/XZ2vZPN6Bd2NcgIW/7hwIOcQkR7dma2cJOA8XmixWx3+bgBofQDBcCvdG SQwjFvA20ZKn+D0gA753HXeR8OjbARepDZ0jVsfkyHGsjJqd9n9pob9cvY4dBzrpopFMhEyF S2/gX964VEVIVQed1+UqB//fii0GiXCTqXvhD11DmWbJV1PC3Fct6rZRvu3HYZ6PuGRp+uZd UyUKmReKI8B3077BgfGEXD2b/oHIP/XSfbfCWVb96VZghfXEL+5A4El/cWU8rLVY6+PqrqbN KNnQee1xcHtpYs8MvJbYktJdcWhr+5FVU/Mmpob2o6GuppObqS+NbzhKNPPpSaQg8r8BU/wH ksADAAA= Archived-At: Subject: Re: [Anima] [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 03 Oct 2018 01:06:54 -0000 --Apple-Mail-2355C6F5-6A50-4EF0-A770-4BF45955DEF9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Based on this exchange, and the arguments presented here that I observed so f= ar, I'm with Randy. I have not seen adequate answers to his concerns (which I= MHO are reasonable). P.S. Feel free to trim the CC: list when/if responding. P.P.S. In one of my prior incarnations many years ago, we designed a somewha= t similar system, and called it "Zero-Touch Provisioning". It was a very big= company, so we did not consider the possibility of it/us going out of busin= ess (and leaving the customers stranded). But if Randy's arguments were pres= ented to our team then, we'd probably accepted them and tried to address... Sent from my test iPhone On Oct 2, 2018, at 20:53, Randy Bush wrote: >> I think it's been thought through but badly articulated. In that sense, >> the Last Call is doing its job. >=20 > does that mean that i can stop trying for a narten medal, go back to > work, and christian will wake me up again when my two scenarios have > clear answers; one hopes ones with which i can live? >=20 > also, please tell me that i do not need to stick my nose into the rest > of anima in order to let the user unequivocally own what they buy. i > have my own rabbit holes to pursue in the ietf. >=20 > randy >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail-2355C6F5-6A50-4EF0-A770-4BF45955DEF9 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMDAzMDEwNjM1WjAvBgkq hkiG9w0BCQQxIgQg4VLrFXEeWOe17LkjPvvmg0+alLdEe35YVe8gPb/q3rMwMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYAxPcek 2uPhr7ZdhJzBEa3/YaPtVoagn0Zmk9ZUQakxltvvtN+oogpkrxzuzq/dI0PRSS5NpNggWyYAKrwc dvG7cELDOn0W7WggJgLNXPU0rniE4YER18UcyLyek+djaM79HYxxP8RP1XHsM45dpUxmab2+JRcq 7tykE4P1WLL7inlNPTtWveZRWrDqZCCsiiHpCOL8DXeNdg5QsqtBwSOZKYWC42BOjrWv4upXncZ+ txhVOcnkXXOcW9+FOnhfrVMpbZxVRehG2kCerY+iP2FguRbCmIjghGjitNQMq3VyarXCbCb457cU o8JGsI880jszm2CQMAUEBWdv6yn+RT3wurpSgnv5aAggMzAA3Yi8DyFiGS3L/6sRrQNGjuPO3kkJ 5ABW3/CuaqgD6j2wys0ZR6aw1G/l0PaP0NDHtD9eY501OS38Yu9GI5OzDeu/J+Qb89pBU71fSUGg X8bVncRvrGcpmUCjr5qSLGcHex/xLs+5Qqq8uCKzcCT+YcIzKjUAAAAAAAA= --Apple-Mail-2355C6F5-6A50-4EF0-A770-4BF45955DEF9-- From nobody Tue Oct 2 19:35:37 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24007131126; Tue, 2 Oct 2018 19:35:29 -0700 (PDT) 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_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 yoPV4Z8nkaFP; Tue, 2 Oct 2018 19:35:27 -0700 (PDT) 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 BFE54131181; Tue, 2 Oct 2018 19:35:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A5EDA20090; Tue, 2 Oct 2018 22:35:20 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6CEDB230F; Tue, 2 Oct 2018 22:35:21 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 68F86230C; Tue, 2 Oct 2018 22:35:21 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org, Security Directorate In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> <23133.1538520783@localhost> 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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 03 Oct 2018 02:35:29 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > I'm still gnawing on my original bone: if I was running a highly > secure, personnel-safety-critical network, like the particle > accelerator control network I used to run for a living, I *would not* > allow it to rely on masa.vendor.com, and it would be physically > impossible to do so because there would be no physical link anyway. I > would get my vouchers some other way. This is not light bulbs either. So possibilities that I see: 1) you run a half-mind Registrar that is on the secure side of your air-gap, and it has a USB interface (or 9-track tape drive... statscan.gc.ca used to run unidirectional UUCP over 9-track tapes walked across the machine room air-gap) on which it can place voucher requests, and receive vouchers from other-half-mind Registrar. This lets you use nonced vouchers, potentially with expiry dates. Maybe very long expiry dates. Or maybe your personnel-safety-critical equipment has a best-before date, and so it's acceptable for you to have vouchers only until that date. Also recall that we permit the Registrar to ask for, and get, voucher renewals at any time, so the connected ("other-half-mind") Registrar could always keep a live set of vouchers. 2) you use NETCONF's mechanism with vouchers that you obtain another way, and you place them on USB key/CDROM/QR-code. 3) you continue to configure such a network with craft-serial console, initiating the EST connection via some other credential. > I believe this can be fixed by clearer scoping of the document, and by > renaming the "lower security" section as "alternative trust models" or > something. I accept that the document could have better text here. At one point we discussed an operational considerations document. Is that really what you are asking for? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlu0KugACgkQgItw+93Q 3WU0cwf+Myuo9lklKAMTegD/17ZJpItF/CcvO9adBkxVQ0U8HvNGAyM+n3GdDMJX 4tjV5HlJkyR/O5ZQjqZ6aCt4bQgIYGNfRb7vtoNNo9v7m1JhMjEcq9itmWPWsAoa 9ll0x9p1lemLbTEDf2pGq4y+peOYQb0y77bKJVTj5Tb4ulcN6HJBnVtrGR/g1ctD Nu2huF2yW0RY4osFIcrLrV5YcmcXl41SdTYTCM/rFOW+56Uv/q9TmmHfo2ipMCIt fZXA10C9uTyDqN9hFyU1YuA/f5fvpg+ABPKapVfEqi79RmEwJhSPWY3FXkAiCaQ8 MnT6XjGXVK7IZdk2Q+iaVHKorQvGzg== =HNZG -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 2 20:50:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8519613118E; Tue, 2 Oct 2018 20:50:43 -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_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 L_mzmb38hz9v; Tue, 2 Oct 2018 20:50:41 -0700 (PDT) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 0F2B0130FF0; Tue, 2 Oct 2018 20:50:41 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id i4-v6so898457pgq.9; Tue, 02 Oct 2018 20:50:41 -0700 (PDT) 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=YCO26Ru5U8yCAVo8WxdeaOUQz0M8ImyUxZpvSp1rKWM=; b=qQgvxv+RwzUp/4kMAQzZIr1DrG9coydRTPJRv/Rmak/Bt2IsC65zZ6Hr2VEMikjStR Ob9DLHKjeO4aLbwNVZ1EIj2aeI+kPUW/I7X9ra1Y7ZyKUEZQo6NVa/cGsyt8WZuqMmYI FJfiIX4ZGyV2HzBiF39zRAzzNbziP9aIfZyMdYjUdvp7HIjZo5nsGKOwKHr9aXmVxxLM CKyOzAIdt89i0cQHR+P+Slwtt8L+VrpjgmCghsPo8BXM7sWE0FB65qy/22GChFBVBitE Z/hAVEBwZkTWsmTB/IOelOLx+dExaQACkjhK5uyKx2nal8nkXZrbfGz04QUWpPl/TnEn gXcg== 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=YCO26Ru5U8yCAVo8WxdeaOUQz0M8ImyUxZpvSp1rKWM=; b=uS6S3N9yBKezooNwzVTDpueRZo9T8O5EJE+9Yw0ctqAN7nbGf60qfMKRzQ3LDgdQKx 7IcfxAEpqn4LE+FopOM7VLWUR/1t65puxxQzo2fvasBuDC/coRODPKRlFHPPyTjaOK5S LdUErJHbzw/+RL33hNEIu0KtFJijcbRSr4NXFQObdSgpdKxDmPF3QN7BYdY8ohr30n75 CkLKl7laN1raZbhqc8NMuomtbirwPIRhD1e+k46Xewg/u8h3tzQPhkGz/h53KGh1AyEh NDJp25z9FvO3dHI+soyd0/X7fhatcmTBYFfLhXf7p58f4StcVTU8lp4yH5cjcu0Sr5KD aRbA== X-Gm-Message-State: ABuFfoilHXISDLlnHFQCa++BAIUylqHBcdt4+/49aFoUKomxyxCmqGYW 25GUTAzQ9KcYELwbfOxU+rnthU/U X-Google-Smtp-Source: ACcGV60mSz+w+e9/6DV8JE5INgFSBQ8wDlGsdEE2S9CxYC/2ozvq/M/hZbLhzT12+8UReFJOtJq5jw== X-Received: by 2002:a63:214d:: with SMTP id s13-v6mr11908202pgm.148.1538538640119; Tue, 02 Oct 2018 20:50:40 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id d2-v6sm82042pfd.100.2018.10.02.20.50.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 20:50:38 -0700 (PDT) To: Michael Richardson Cc: anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> <23133.1538520783@localhost> <10809.1538534121@localhost> From: Brian E Carpenter Message-ID: Date: Wed, 3 Oct 2018 16:50:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <10809.1538534121@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 03 Oct 2018 03:50:43 -0000 On 2018-10-03 15:35, Michael Richardson wrote: > > Brian E Carpenter wrote: > > I'm still gnawing on my original bone: if I was running a highly > > secure, personnel-safety-critical network, like the particle > > accelerator control network I used to run for a living, I *would not* > > allow it to rely on masa.vendor.com, and it would be physically > > impossible to do so because there would be no physical link anyway. I > > would get my vouchers some other way. This is not light bulbs either. > > So possibilities that I see: > > 1) you run a half-mind Registrar that is on the secure side of your air-gap, and it has > a USB interface (or 9-track tape drive... statscan.gc.ca used to run > unidirectional UUCP over 9-track tapes walked across the machine room air-gap) > on which it can place voucher requests, and receive vouchers from > other-half-mind Registrar. > > This lets you use nonced vouchers, potentially with expiry dates. > Maybe very long expiry dates. Or maybe your personnel-safety-critical > equipment has a best-before date, and so it's acceptable for you to have > vouchers only until that date. > > Also recall that we permit the Registrar to ask for, and get, voucher > renewals at any time, so the connected ("other-half-mind") Registrar could > always keep a live set of vouchers. Yes, that sort of solution would work. > 2) you use NETCONF's mechanism with vouchers that you obtain another way, and > you place them on USB key/CDROM/QR-code. You could. But that makes me a bit nervous too. It's not far from seeing a yellow sticky in the ops room saying "sys pw muggle3scop#" or whatever. People who want airgap security are very cautious about USB keys these days. > 3) you continue to configure such a network with craft-serial console, > initiating the EST connection via some other credential. It still doesn't scale. > > > I believe this can be fixed by clearer scoping of the document, and by > > renaming the "lower security" section as "alternative trust models" or > > something. > > I accept that the document could have better text here. > At one point we discussed an operational considerations document. > Is that really what you are asking for? Later, maybe, but to get this draft out of the door I think we can do a simpler fix. As Christian pointed out, there isn't really a distinct security analysis, so I think we need to say: This is the recommencded trust model, based on an on-line MASA. If you don't like that trust model, here are the alternatives: . Brian From nobody Tue Oct 2 23:20:36 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83611311F3; Tue, 2 Oct 2018 23:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 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 Dg6q1sUvlpL2; Tue, 2 Oct 2018 23:20:34 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB44131090; Tue, 2 Oct 2018 23:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2978; q=dns/txt; s=iport; t=1538547634; x=1539757234; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=eOaOYtcbBOkdP8kRdvMpNLSbP9CZyPKPnwRObdcxV+Q=; b=dP69qYsjRJveChM718BtqyhRIUtuo8P4W6wUNOYWiDQcRg4vtxNZBrWp atslxeekblAmUX4L35z5T2ysBgxgkj3Ls6D5VfIEbvwW/H58TXvDrPto8 koOCZqDUO50nxpDEXthJ/L2ACck6KKbgAZ5pyuqMp8Ohwyv90ZsZR/Te/ I=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AAC/XrRb/xbLJq1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGERW0SKIN0iHSNHi2YVggDG4RRAoQ4OBQBAwEBAgEBAm0?= =?us-ascii?q?cDEIOAYRoAQUjVhALGCoCAlcGAQwIAQGDHQGCAaUQgS6KAQ+CbYgtggCBEie?= =?us-ascii?q?CPS6Hf4JXAp1DCYQBgWhfiWwGF4IUhnqGUJVHgVkhgVUzGggbFYMnCYJEgmG?= =?us-ascii?q?LKD0whVGJCwEB?= X-IronPort-AV: E=Sophos; i="5.54,334,1534809600"; d="asc'?scan'208"; a="6902152" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 06:20:31 +0000 Received: from [10.61.165.23] ([10.61.165.23]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w936KVGt002841; Wed, 3 Oct 2018 06:20:31 GMT To: Michael Richardson , Brian E Carpenter Cc: anima@ietf.org, Security Directorate References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> <23133.1538520783@localhost> <10809.1538534121@localhost> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <83c2e4dd-e60a-158b-50aa-7e243216854a@cisco.com> Date: Wed, 3 Oct 2018 08:20:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <10809.1538534121@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ht557MXmAIP3cp9Z7MaEbmzUKdMaS9uHT" X-Outbound-SMTP-Client: 10.61.165.23, [10.61.165.23] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 03 Oct 2018 06:20:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ht557MXmAIP3cp9Z7MaEbmzUKdMaS9uHT Content-Type: multipart/mixed; boundary="akldOHhjlJQHzntTE9sams1QCEqA43Kr4"; protected-headers="v1" From: Eliot Lear To: Michael Richardson , Brian E Carpenter Cc: anima@ietf.org, Security Directorate Message-ID: <83c2e4dd-e60a-158b-50aa-7e243216854a@cisco.com> Subject: Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> <23133.1538520783@localhost> <10809.1538534121@localhost> In-Reply-To: <10809.1538534121@localhost> --akldOHhjlJQHzntTE9sams1QCEqA43Kr4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Michael: On 03.10.18 04:35, Michael Richardson wrote: > 1) you run a half-mind Registrar that is on the secure side of your air= -gap, and it has > a USB interface (or 9-track tape drive... statscan.gc.ca used to run= > unidirectional UUCP over 9-track tapes walked across the machine roo= m air-gap) > on which it can place voucher requests, and receive vouchers from > other-half-mind Registrar. > > This lets you use nonced vouchers, potentially with expiry dates. > Maybe very long expiry dates. Or maybe your personnel-safety-critic= al > equipment has a best-before date, and so it's acceptable for you to = have > vouchers only until that date. One approach I would like would be to get the voucher size down to the point where it could reasonably fit into a QR code.=C2=A0 Then it's a sca= n.=C2=A0 I see that as future work. Eliot --akldOHhjlJQHzntTE9sams1QCEqA43Kr4-- --ht557MXmAIP3cp9Z7MaEbmzUKdMaS9uHT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlu0X64ACgkQh7ZrRtnS ejMNWwf/et8+opX0MiBrnsBybbqO+LPLJnGaByW21P9iZQJJ52wKHReZ0MN5fSRZ lhschuNBJl6mVclNVs3CUoIn41eTyD0cGTY106eMDESab9HABlrdTQ2eMcWBy/cW r+HQ2zzhJbugf3qpLZ/W4mzRf6+DiolCyuytSQkmP+4MmJz6ijld9+ol8ssyC2EA XieGsm3hZ9dPGDUIu/Y7ndRzCAp8e6ZVpZogoJfr/9/sqS6u/ADYHsLHfixg86Wj CamlvAN4s1US52l1mkjcykeoL0Gt9Y/Y8evXLj58+r9fg/6TDSPiK6nfI8s4CaTG FJnwUXxQ/8PVJ9n2I5PPwhhE80XT7A== =k3vp -----END PGP SIGNATURE----- --ht557MXmAIP3cp9Z7MaEbmzUKdMaS9uHT-- From nobody Wed Oct 3 07:28:23 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D1D1312B3; Wed, 3 Oct 2018 07:28:15 -0700 (PDT) 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_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 nVOR3RLtQ2SP; Wed, 3 Oct 2018 07:28:13 -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 463ED13129E; Wed, 3 Oct 2018 07:28:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 55F3620090; Wed, 3 Oct 2018 10:28:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 24EA62352; Wed, 3 Oct 2018 10:28:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 21B44234D; Wed, 3 Oct 2018 10:28:12 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org, Security Directorate In-Reply-To: References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> <23133.1538520783@localhost> <10809.1538534121@localhost> 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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 03 Oct 2018 14:28:16 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> 2) you use NETCONF's mechanism with vouchers that you obtain another >> way, and you place them on USB key/CDROM/QR-code. > You could. But that makes me a bit nervous too. It's not far from > seeing a yellow sticky in the ops room saying "sys pw muggle3scop#" or > whatever. People who want airgap security are very cautious about USB > keys these days. I agree, it's a bit similar. Except that the voucher is a signed entity, and disclosing it causes privacy issues (people know what you have), rather than being p0wned. It can easily go on a CDROM or something else you do trust. A QR code is also possible, assuming your personnel-safety-critical device has a camera. [oh. Now I'm thinking about 2001, Space Odyssey. I'm seeing Dave Borman with a giant QR code tattoed on him, much like we proposed doing with the RSA algorithm back during the cryptowars of the 1990s ] {and the issues with USB devices are squarely a problem of GUIs accepting input devices without validation. It's fixable} >> 3) you continue to configure such a network with craft-serial console, >> initiating the EST connection via some other credential. > It still doesn't scale. And, worse, I think, it's prone to human error, which is exactly what we want personnel-safety-critical devices not to suffer from. >> > I believe this can be fixed by clearer scoping of the document, and >> by > renaming the "lower security" section as "alternative trust >> models" or > something. >> >> I accept that the document could have better text here. At one point >> we discussed an operational considerations document. Is that really >> what you are asking for? > Later, maybe, but to get this draft out of the door I think we can do a > simpler fix. As Christian pointed out, there isn't really a distinct > security analysis, so I think we need to say: This is the > recommencded trust model, based on an on-line MASA. If you don't like > that trust model, here are the alternatives: . okay. It's gonna take a gallon or two of caffeinated beverage. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlu00fsACgkQgItw+93Q 3WV0aAgAvRTI8tkNi1xBzu9Pf1muZ6k/958le5RQL1QNQNfpBGZhal4Rkhd6JXvq ch9JpZHb3799S0Ze1CDsCeE6+V6HgK0RJI+RLySi32FFyGc9+g/HojhmSRkfoiaQ qUTxVEwzsD66vOuRFwyDV1+lcJBe5Bk7dSgdPODA4g7MK5cJ1ez8fgwwhtl9c3bf WJ6wRgkWh10xzMdE23rXRmS+XF8OfnIzS56zQOUSLdj6uzMwOefj+B2vJdqnThN+ VoNOSZFsHVpcTO3XoWFJdXSdzftoDzDQn9sJS0sx2ONNSePqeWzOAfdiUcnQiG1r Z2nfizHU1cio+k/1J4QoMqGo7PLQnQ== =T8dg -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 3 07:37:47 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDE91312B2; Wed, 3 Oct 2018 07:37:38 -0700 (PDT) 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_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 D1uxOavxtriz; Wed, 3 Oct 2018 07:37:36 -0700 (PDT) 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 E7A66131280; Wed, 3 Oct 2018 07:37:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 816C720090; Wed, 3 Oct 2018 10:37:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 502CC2352; Wed, 3 Oct 2018 10:37:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4D5A4234D; Wed, 3 Oct 2018 10:37:33 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: Brian E Carpenter , anima@ietf.org, Security Directorate In-Reply-To: <83c2e4dd-e60a-158b-50aa-7e243216854a@cisco.com> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> <23133.1538520783@localhost> <10809.1538534121@localhost> <83c2e4dd-e60a-158b-50aa-7e243216854a@cisco.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] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 03 Oct 2018 14:37:38 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >> This lets you use nonced vouchers, potentially with expiry dates. >> Maybe very long expiry dates. Or maybe your personnel-safety-critic= al >> equipment has a best-before date, and so it's acceptable for you to >> have vouchers only until that date. > One approach I would like would be to get the voucher size down to the > point where it could reasonably fit into a QR code.=C2=A0 Then it's a= scan.=C2=A0 > I see that as future work. current constrained voucher: dooku-[projects/pandora/highway](2.4.1) mcr 10028 %ls -l tmp/voucher_00-D0-E5-F2-10-03.vch =2Drw-r--r-- 1 mcr mcr 800 Oct 2 23:06 tmp/voucher_00-D0-E5-F2-10-03.vch Note that this does not include the key that did the signing (the MASA key), and I think that this pins a certificate rather than a Raw Public Key, so it could be smaller. (I have to check what I put in that one) It's okay not to include the signing key inside, as the pledge already has it. The Registrar ("owner's trust controller") would like to have that key to audit the signature, but that can be done outside of the voucher. It converts to QR code just fine: http://www.sandelman.ca/tmp/qr1.png Probably needs to have some URI or some such to tell things what is inside. However, not many devices we care about (whether routers or lightbulbs) have cameras. If there is some smartphone interaction, then that's a different thing, and DPP could work, provided we get the APIs that we need = to make it deployable. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlu01CwACgkQgItw+93Q 3WXDJwgAp/bA/u/XMgC1lsdJmcCmcHlzR6iWU52XwKIhZgApVTwQJfPTZuE0aGT7 cuGup/8A6h5KstrxNChXO8avwJc/BtqrOuA3CsMTY1n2mDj/HfGViZMTAzN8BVfJ EuAeOfNRVZN07NovTnw5I3KG3MMKV0v1rmyZ+cQbpZ2PPdbJnjx/y13B5X2Evk8F jRrC9RmRAnBCX67Hiv8LDDjKaGlwHXEvrWifuigb2Pn0Ske/n7lhwjEOxvALewvs KPYexHSm+7O26WotdmPCGkCgHJMyE9kntugG37m2LLl7ccnOfhEHWJzY07ZLJqm0 egku0YnVH6KeFYmAdlta/7mCKHuBDQ== =y07n -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 4 00:07:55 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E64130DE9; Thu, 4 Oct 2018 00:07:53 -0700 (PDT) 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.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <153863687351.4429.1743994740065935512@ietfa.amsl.com> Date: Thu, 04 Oct 2018 00:07:53 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-reference-model-08.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: Thu, 04 Oct 2018 07:07:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : A Reference Model for Autonomic Networking Authors : Michael H. Behringer Brian Carpenter Toerless Eckert Laurent Ciavaglia Jeferson Campos Nobre Filename : draft-ietf-anima-reference-model-08.txt Pages : 30 Date : 2018-10-04 Abstract: This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-reference-model-08 https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-08 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 Thu Oct 4 00:12:59 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DC7130DE9; Thu, 4 Oct 2018 00:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGf0Ea40dkQj; Thu, 4 Oct 2018 00:12:56 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 464B8130DDF; Thu, 4 Oct 2018 00:12:56 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id a8-v6so3853558wmf.1; Thu, 04 Oct 2018 00:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:references:to:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=bChxbheObPowURStut9/SFbqES/eveUJE6WPM27oTh4=; b=bcImXfolws/5tM1RM7FYu7SqH3CZZ29V2GUACn8Ez4ykkdBGCO2hWp2W0PG2R/bYnY p7dgvbm0VW1aw8iMWR7rwYSqAlklunGtow0GxWZ4FVW9etiwAHV/9WRMlxzwGuaUWZRV lXz4Kivvr9/fh9y7q5DMoGgQOSpb35CVfZFRhBYzSuFuHaWudBT3GIE7F6wUY0MpLcnR dUVPkO5Gc3EbwV/hz1XabrMn7UM1XFdxCt1fcM6ySdmpdD60VR+Mc1cb1hIQId5mwSx/ b9BbK83Mo7cleaJmvFnNvWvbEHz9+JsDUfpCPbruq1jK03c3mqyhH59JOdlYnUCGjg21 bOmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:references:to:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bChxbheObPowURStut9/SFbqES/eveUJE6WPM27oTh4=; b=Ib0T2GAtjWiJe8+XlprdAqeno5SEj5tgRAYqaqMQQgA/CsLYYFq1N6Bev+vFAu+w2I B5iyvFLgZp6RJ/FKBF78PTeNGngpR85NXjC4Y4HBZ62F6ZJN8v77iqXncFBOYMjUQlLe vntIeNEMsTEVNflb4F0TlSRSeaa+wxpJdwtACTKNI+EEoJpyylwgvOxuI9fcJreiSpc9 wP8HDUTnChuNAXfYpjVKXuKPt6YyR2mTHbJF9nmtFAlPykCOEFuH+x149x1112JT0QU2 gxnW9iLV5i/g1b0V9fw/f7ewDp50VCkKFH7pUqsS6GthuTNRAE2jr7kaUDiZ0Yn030ue m8og== X-Gm-Message-State: ABuFfoiisjudFXhJ60bBPldAijzw7px2WY/VigZuseejVXNlixhB/3nk bsTE51xNTfA2AnoeU0xTmp25uOt9 X-Google-Smtp-Source: ACcGV60mQJ3sxMeen/1KqPIpLUhKDjyTSIglk0asDqlMZ0rOibk0RXpWaGeHBXNQeqEjygJh1nIw2Q== X-Received: by 2002:a1c:a9ce:: with SMTP id s197-v6mr3583030wme.82.1538637174552; Thu, 04 Oct 2018 00:12:54 -0700 (PDT) Received: from [192.168.1.22] (ANice-652-1-30-93.w83-201.abo.wanadoo.fr. [83.201.181.93]) by smtp.gmail.com with ESMTPSA id 77-v6sm7990404wmv.6.2018.10.04.00.12.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Oct 2018 00:12:53 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" References: <153863687351.4429.1743994740065935512@ietfa.amsl.com> To: "anima@ietf.org" , Christian Hopps , draft-ietf-anima-reference-model.all@ietf.org, "anima-chairs@tools.ietf.org" X-Forwarded-Message-Id: <153863687351.4429.1743994740065935512@ietfa.amsl.com> Message-ID: Date: Thu, 4 Oct 2018 09:12:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153863687351.4429.1743994740065935512@ietfa.amsl.com> Content-Type: text/html; charset=windows-1252 Content-Language: fr-classic Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-ietf-anima-reference-model-08.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: Thu, 04 Oct 2018 07:12:58 -0000 ANIMA chairs, Christian,

This new version addresses the comments made in the RTGDIR review of Christian Hopps. Other comments were addressed in previous versions of the document.

Christian, could you please review, and see if there are any open issues that we overlooked? If not, could you please clear the "issues" flag?

We haven't received any further comments in the Last Call. I believe the document is ready for publication.

Thanks,
Michael


-------- Forwarded Message --------
Subject: [Anima] I-D Action: draft-ietf-anima-reference-model-08.txt
Date: Thu, 04 Oct 2018 00:07:53 -0700
From: internet-drafts@ietf.org
Reply-To: anima@ietf.org
To: i-d-announce@ietf.org
CC: anima@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF.

        Title           : A Reference Model for Autonomic Networking
        Authors         : Michael H. Behringer
                          Brian Carpenter
                          Toerless Eckert
                          Laurent Ciavaglia
                          Jeferson Campos Nobre
	Filename        : draft-ietf-anima-reference-model-08.txt
	Pages           : 30
	Date            : 2018-10-04

Abstract:
   This document describes a reference model for Autonomic Networking
   for managed networks.  It defines the behaviour of an autonomic node,
   how the various elements in an autonomic context work together, and
   how autonomic services can use the infrastructure.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-reference-model-08
https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-08


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
From nobody Thu Oct 4 19:04:02 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E5F12F295 for ; Thu, 4 Oct 2018 19:04:00 -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_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 k9wE_k5i1yoQ for ; Thu, 4 Oct 2018 19:03:58 -0700 (PDT) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 A21AC1292F1 for ; Thu, 4 Oct 2018 19:03:58 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id az3-v6so6052299plb.4 for ; Thu, 04 Oct 2018 19:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nTssSBEGFNJqXRRUbc3ECotnOgJNTjpjbtScKdLuHIQ=; b=FOBxIjqLOi7mUJJQvicxeI8IS3GnMn9jHSW+bajB5YEELw/uP5xmvB6D/KD5YqSmK7 ib1za2uHzYml4Qua3vVZuzkR9zNKIRhOz1zmOcQqsQTt4kzkb49W7dLvbTAaSGb8y0y9 HirOXLX4jqRfQeNrmkT6RJ7Bp0M7h5m6LbOuromzRxU/40DpyuP+mOchKrHxg4g1t1ZD vOuqhGy14oUcu+ZRYsqmS/6FIpN0ovahKbWLEN5DJKBjOAxSQ4uT5iEyRZrlYrazGVu7 w+3qhlTMpedRJyQf1lhRYjmzJvnOt7OBjr227IN5wbb02eY3F6PuBOlCncSOD0VTO3+k 7OyQ== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=nTssSBEGFNJqXRRUbc3ECotnOgJNTjpjbtScKdLuHIQ=; b=i9rwOZCa0A+1IDjHmCYVpFhs/WGv1F1P/HGPI5bOoiOKThZbdVV2Jkh4EgchusPY8v LuQVyJJiGcVY3f16/yfGxVQQbE2ma3bjifd+XDyzRKcx94nZPGQm9l8VWSBNKN3ePbly vQQrbAtxmB7wl/F+x7P9PH1UhbMMlJXW6WQ6fRTRdAArxZa0kutHRyd9Lr94Gw1S+hi+ Qvnpss9OqRYixJ5zZwMbH0/bQ4/kufVptocHbgYnWRZsNZz56kNV3hfLh9hls410LcqW /QFqgX7vz6iMhloquZ0JOqNclK8SHwfZAb5Nay9HRF73GHN8iOc7VzYX/+ZHomntHLn5 m2pA== X-Gm-Message-State: ABuFfojN4QdUz+ESqE6Sv9tYi1i0j6SjEP1XUGcJ0g+usvT6i1qlWXCt mZ04ttBZLi8gODtEMxOc2fvRO9kU X-Google-Smtp-Source: ACcGV60yMwtxKSWUOBKiJwGAOJF+ewwsj+7Sp2SNPN1nOkfJGXwUUfmQUD1Fd3WGTl1Bi8ODhtccaA== X-Received: by 2002:a17:902:292a:: with SMTP id g39-v6mr9220700plb.269.1538705037881; Thu, 04 Oct 2018 19:03:57 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id c28-v6sm23190944pfk.48.2018.10.04.19.03.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Oct 2018 19:03:57 -0700 (PDT) To: anima@ietf.org References: <153825200726.18811.5817453433918930845@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <659e84c2-551c-4b7c-1002-b156337a92ac@gmail.com> Date: Fri, 5 Oct 2018 15:03:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153825200726.18811.5817453433918930845@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-vanderstok-constrained-anima-dtls-join-proxy-00.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: Fri, 05 Oct 2018 02:04:01 -0000 How does the constrained pledge discover the LL address of the constrained proxy? Regards Brian Carpenter On 2018-09-30 09:13, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Constrained Join Proxy for Bootstrapping Protocols > Authors : Michael Richardson > Peter van der Stok > Panos Kampanakis > Filename : draft-vanderstok-constrained-anima-dtls-join-proxy-00.txt > Pages : 10 > Date : 2018-09-29 > > Abstract: > This document defines a protocol to securely assign a pledge to an > owner, using an intermediary node between pledge and owner. This > intermediary node is known as a "constrained-join-proxy". > > This document extends the work of > [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- > proxy by a stateless constrained join-proxy, that uses IP > encapsulation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-vanderstok-constrained-anima-dtls-join-proxy/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00 > https://datatracker.ietf.org/doc/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Fri Oct 5 00:24:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA66130DE1 for ; Fri, 5 Oct 2018 00:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Y_Kd8UxoteGU for ; Fri, 5 Oct 2018 00:24:45 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55011130DDD for ; Fri, 5 Oct 2018 00:24:44 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 7FDC01E099; Fri, 5 Oct 2018 07:24:43 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:1:2:41:72:152:355:379:582:599:800:962:967:973:983:988:989:1049:1152:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1730:1777:1792:2068:2069:2198:2199:2288:2525:2528:2553:2559:2568:2682:2685:2693:2741:2771:2859:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4250:4321:4361:4605:4860:5007:6117:6119:6261:6298:6657:6659:6678:7875:7903:8599:8603:9010:9025:9177:10004:10049:10848:11232:11258:11658:11914:11984:12043:12109:12114:12291:12379:12438:12683:12740:12776:12895:12926:13139:13161:13229:13255:13439:13846:14093:14094:14095:14096:14110:14651:21060:21080:21324:21433:21451:21625:21740:30003:30006:30025:30046:30054:30060:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0. X-HE-Tag: tub87_29309cfc72446 X-Filterd-Recvd-Size: 11057 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf04.hostedemail.com (Postfix) with ESMTPA; Fri, 5 Oct 2018 07:24:43 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_202c38e40dd245138bf598f3f7475267" Date: Fri, 05 Oct 2018 09:24:42 +0200 From: Peter van der Stok To: Brian E Carpenter Cc: anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <659e84c2-551c-4b7c-1002-b156337a92ac@gmail.com> References: <153825200726.18811.5817453433918930845@ietfa.amsl.com> <659e84c2-551c-4b7c-1002-b156337a92ac@gmail.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.44.113] Archived-At: Subject: Re: [Anima] I-D Action: draft-vanderstok-constrained-anima-dtls-join-proxy-00.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: Fri, 05 Oct 2018 07:24:49 -0000 --=_202c38e40dd245138bf598f3f7475267 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Brian. The answer consists of a selection of text of section 7 of the draft. The discovery follows the standard coap discovery. ________________________________________________________________ The discovery of the Join-Proxy by the Pledge is an extension to the discovery described in section 4 of [I-D.ietf-anima-bootstrapping-keyinfra]. In particular this section replaces section 4.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. The Pledge can discover a Join-Proxy by sending a link-local multicast message to ALL CoAP Nodes with address FF01::FD. Multiple or no nodes may respond. The handling of multiple responses and the absence of responses follow section 4 of [I-D.ietf-anima-bootstrapping-keyinfra]. The presence and location of (path to) the join-proxy resource are discovered by sending a MC GET request to "/.well-known/core" including a resource type (RT) parameter with the value "brski-proxy" [RFC6690]. Upon success, the return payload will contain the root resource of the Join-Proxy resources. ____________________________________________________________ Looking forward to your comments and suggestions, Peter Brian E Carpenter schreef op 2018-10-05 04:03: > How does the constrained pledge discover the LL address of the constrained proxy? > > Regards > Brian Carpenter > > On 2018-09-30 09:13, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Constrained Join Proxy for Bootstrapping Protocols >> Authors : Michael Richardson >> Peter van der Stok >> Panos Kampanakis >> Filename : draft-vanderstok-constrained-anima-dtls-join-proxy-00.txt >> Pages : 10 >> Date : 2018-09-29 >> >> Abstract: >> This document defines a protocol to securely assign a pledge to an >> owner, using an intermediary node between pledge and owner. This >> intermediary node is known as a "constrained-join-proxy". >> >> This document extends the work of >> [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- >> proxy by a stateless constrained join-proxy, that uses IP >> encapsulation. >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-vanderstok-constrained-anima-dtls-join-proxy/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00 >> https://datatracker.ietf.org/doc/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00 >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --=_202c38e40dd245138bf598f3f7475267 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Brian.

The answer consists of a selection of text of section = 7 of the draft.
The discovery follows the standard coap discovery.
________________________________________________________________

The discovery of the Join-Proxy by the
   Pledge is an e= xtension to the discovery described in section 4 of
   [I-D= =2Eietf-anima-bootstrapping-keyinfra].  In particular this section
   replaces section 4.2 of [I-D.ietf-anima-bootstrapping-keyin= fra].

   The Pledge can discover a Join-Proxy by sen= ding a link-local
   multicast message to ALL CoAP Nodes wi= th address FF01::FD.  Multiple
   or no nodes may resp= ond.  The handling of multiple responses and the
   ab= sence of responses follow section 4 of
   [I-D.ietf-anima-b= ootstrapping-keyinfra].

The presence and location of (path to) the join-proxy resource are
=    discovered by sending a MC GET request to "/.well-known/core"= including
   a resource type (RT) parameter with the value= "brski-proxy"
   [RFC6690].  Upon success, the return= payload will contain the root
   resource of the Join-Prox= y resources.

___________________________________________________= _________

Looking forward to your comments and suggestions,

Peter

Brian E Carpenter schreef op 2018-10-05 04:03:

= How does the constrained pledge discover the LL address of the constrained = proxy?

Regards
   Brian Carpenter

On 2018-09-30 09:13, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-l= ine Internet-Drafts directories.


    =     Title        &nb= sp;  : Constrained Join Proxy for Bootstrapping Protocols
&= nbsp;       Authors    &n= bsp;    : Michael Richardson
   &n= bsp;            = ;          Peter van der = Stok
          &nbs= p;            &= nbsp;  Panos Kampanakis
    Filename &n= bsp;      : draft-vanderstok-constrained-anim= a-dtls-join-proxy-00.txt
    Pages   &n= bsp;       : 10
   =  Date           &nbs= p;: 2018-09-29

Abstract:
   This document = defines a protocol to securely assign a pledge to an
  &nbs= p;owner, using an intermediary node between pledge and owner.  This    intermediary node is known as a "constrained-join-pro= xy".

   This document extends the work of
=    [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the = Circuit-
   proxy by a stateless constrained join-prox= y, that uses IP
   encapsulation.


Th= e IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-vanderstok-constrained-anima-dtls-join-proxy/

There are = also htmlized versions available at:
https://tools.ietf.org/html/draft-vanderstok-constra= ined-anima-dtls-join-proxy-00
https://datatracker.ietf.org/doc/html/draf= t-vanderstok-constrained-anima-dtls-join-proxy-00


Ple= ase 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/

________________= _______________________________
I-D-Announce mailing list
I-D-Announce@ietf.org=
https://www.ietf.org/mailman/listinfo/i-= d-announce
Internet-Draft directories: http://www.ietf.or= g/shadow.html
or ftp://ftp.ietf.org/ietf/1shado= w-sites.txt


_______________________________________________
Anima mailing = list
Anima@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/ani= ma
--=_202c38e40dd245138bf598f3f7475267-- From nobody Fri Oct 5 05:35:01 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD390130E66; Fri, 5 Oct 2018 05:34:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jari Arkko To: Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153874289877.989.15433226866680411112@ietfa.amsl.com> Date: Fri, 05 Oct 2018 05:34:58 -0700 Archived-At: Subject: [Anima] Genart last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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: Fri, 05 Oct 2018 12:34:59 -0000 Reviewer: Jari Arkko Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-anima-bootstrapping-keyinfra-?? Reviewer: Jari Arkko Review Date: 2018-09-27 IETF LC End Date: 2018-10-02 IESG Telechat date: Not scheduled for a telechat Summary: I have reviewed this document. My intent was to complete this review by the original Gen-ART and IETF last call deadline on October 2. Unfortunately, it took longer to read the document than expected, for which I apologize. Hopefully these comments are still useful. I have some overall comments and then a number of more detailed technical and editorial comments. First up, I agree with Christian Huitema's stellar review that was posted earlier on the IETF list. He brought out many of the most relevant questions about this specification. I won't repeat those questions, but I'll observe that I *do* think it is useful to build enrollment and imprinting protocols, for various situations. It is beneficial for there to be standards in this space, and for those standards to support use cases that fit me and others that fit other people's goals. I do agree with Christian and others that one has to be careful about doing that though, and be careful about, for instance, avoid putting any party in a more controlling role than others purely due to how the technology is constructed. I did encounter a number of question marks and have several suggestions throughout the document. It also wasn't an easy read, particularly from the point of view of understanding what its implications are. My first bigger comment is that I believe the security and privacy considerations section should have provided an actual in-depth analysis of the characteristics offered by the protocol, perhaps under several different situations, as the protocol can be operated in different modes. My second comment is that the protocol as defined is quite focused on manufacturer-controlled situations. As Christian mentioned, there is some discussion of other situations in the document (Section 6.4), but not much, and there's little information on what happens if one tries to use the protocol in this way. It would seem that a better support for getting a voucher or vouchers when the device is new and the manufacturer still around would alleviate some of the concerns that were raised in the IETF list discussion. There's little information about the security implications, little explanation of the various lifetimes and when infinite lifetimes are OK and when not, etc. All of those details would have been useful. But for now, it is difficult to even evaluate those aspects, because I don't know if I can use the protocol for in a more owner-oriented fashion. And if I can't, is that because of a fundamental limit or because we chose to design the protocol that way? More detailed technical comments: Section 1: > It uses a TLS connection and an PKIX (X.509v3) > certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer > points 1 and 2. It uses a new artifact called a "voucher" that the > registrar receives from a "Manufacturer Authorized Signing Authority" > and passes to the pledge to answer points 3 and 2. What is used to answer point 4? Section 1.3.3: > This document presumes that network access control has either already > occurred, is not required, or is integrated by the proxy and > registrar in such a way that the device itself does not need to be > aware of the details. I understand why this limitation is specified, but this does considerably reduce the number of cases where BRSKI can be applied. Section 2.1: > A unique nonce can be > included ensuring that any responses can be associated with this > particular bootstrapping attempt. It seems odd to have such a fundamental request-response matching be optional. Also, are these the same nonces as were described early for one-time usage limits, or different? Section 2.2: > Vouchers provide a signed but non-encrypted communication channel > among the pledge, the MASA, and the registrar. The registrar > maintains control over the transport and policy decisions allowing > the local security policy of the domain network to be enforced. Is this a potential privacy vulnerability, as there are serial numbers and possibly some other information in the voucher? (One could have, for instance, exposed a hash of the relevant information during the process onlu reveal the actual data once the encrypted channel is set up to avoid this.) Section 2.3: > 4. (Optionally) communicating the MUD URL (see Appendix C. There's plenty of potentially useful information that could be communicated. The linkage to MUDs seems a bit arbitrary. Could this perhaps be generalized? Section 2.4: > P---Voucher Request (include nonce)------>| | Is this nonce the one inside the voucher or something different? Section 3.1: > grouping voucher-request-grouping > +---- voucher > +---- created-on? yang:date-and-time > +---- expires-on? yang:date-and-time > +---- assertion enumeration > +---- serial-number string I'm not sure it is necessary to base everything on a serial number. Section 3.2: > "proximity-registrar-cert": "base64encodedvalue==" I do not understand the notation that you are using here, nor did my grep for the above string find anything from the RFC directory other than in RFC 8366. Is "base64encodedvalue==" a value that you are using as an example, or some special format that signifies something else? Section 4: > A proxy MAY assume TLS framing for auditing purposes, but MUST NOT > assume any TLS version. Is this specification sufficient to understand what this means from a actual behaviour point of view? Must pass all bytes unchanged? Section 4: > In the ANI, the Autonomic Control Plane (ACP) secured instance of > GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI > registrar ACP addresses and ports by ANI proxies. The TCP leg of the > proxy connection between ANI proxy and ANI registrar therefore also > runs across the ACP. MUST seems a strong keyword to use here. Perhaps some systems would like to use another mechanism, but this MUST prohibits any such changes. MUST support maybe... Also, a bit later in Section 4.1 it says "The pledge MAY listen concurrently for other sources of information" which would seem to contradict the MUST. Section 4.1: > The result of discovery is a logical communication with a registrar, > through a proxy. The proxy is transparent to the pledge but is > always assumed to exist. Is it really a requirement that it must exist? I could imagine small networks where the registrar is on the network... Section 4.1: > A new temporary > address SHOULD be allocated whenever the discovery process is > forced to restart due to failures. Why is this necessary? It seems to set a pretty high requirement on the integration of the IP stack and the brski functionality. Presumably RFC 4941 is used by many applications and there should be support in the general facility for sufficiently frequent change of addresses. Section 5: > o The pledge either attempts concurrent connections, or it times out > quickly and tries connections in series. Concurrent connections to where? You mean multiple proxies? Be more specific. Section 5.2: > nonce: The pledge voucher-request MUST contain a cryptographically > strong random or pseudo-random number nonce. Doing so ensures > Section 2.6.1 functionality. The nonce MUST NOT be reused for > multiple bootstrapping attempts. But elsewhere in the document you talk about the nonceless case, so how can the nonce actually be mandatory? Or are there multiple nonces? The document is unclear on this. Section 5.4: > The registrar SHOULD verify that the serial number > field it parsed matches the serial number field the pledge > provided in its voucher-request. It is surprising that this is only a SHOULD. The pledge will be made for a wrong device and/or there is an attack somewhere if the two values don't match. Section 5.4.7: > It MAY perform a simple > consistency check: If the registrar voucher-request contains a nonce > and the prior-signed-voucher-request exists then the nonce in both > MUST be consistent. The formulation is odd, because you are specifying something optional (MAY) which then has a MUST statement but that statement relates to how things are supposed to be, not what the implementations should do. And again, I think these consistency checks should be mandatory. Section 5.5: > expires-on: This is set for nonceless vouchers. The MASA ensures > the voucher lifetime is consistent with any revocation or pinned- > domain-cert consistency checks the pledge might perform. See > section Section 2.6.1. There are three times to consider: (a) a > configured voucher lifetime in the MASA, (b) the expiry time for > the registrar's certificate, (c) any certificate revocation > information (CRL) lifetime. The expires-on field SHOULD be before > the earliest of these three values. Typically (b) will be some > significant time in the future, but (c) will typically be short > (on the order of a week or less). The RECOMMENDED period for (a) > is on the order of 20 minutes, so it will typically determine the > lifespan of the resulting voucher. There are several issues here, the lifetimes of the imprinting with the owner/registrar vs. the lifetimes of the imprinting process artifacts. Please clarify. I *think* you are talking about the process expery times above, not about the expiry of the imprinting. And certainly I'd hope 20min is not the duration of the imprinting, but rather it needs to be infinite in most cases. Section 5.5.2: > The pinned-domain-cert MAY be installed as an trust anchor for future > operations. Could this be used for future imprinting, or only for other things? Please clarify. Section 5.7.1: > 5.7.1. MASA audit log response I found this section not providing enough details to tell what the MASA should return. Everything? Only log entries concerning the device in question? Log entries for the same domain as in the indicated voucher request? Section 5.7.2: > A "proximity" assertion > assures the registrar that the pledge was truly communicating with > the prior domain and thus provides assurance that the prior domain > really has deployed the pledge. I don't think I understand the promixity assurances. Obviously, the pledge and the owner's domain are in some kind of communication, but not sure how that proves proximity, given that requests from a pledge could easily be tunneled from somewhere else. Section 6.2: > 2. The pledge MAY support "trust on first use" for physical > interfaces such as a local console port or physical user > interface but MUST NOT support "trust on first use" on network > interfaces. This is because "trust on first use" permanently > degrades the security for all use cases. > > 3. The pledge MAY have an operational mode where it skips voucher > validation one time. For example if a physical button is > depressed during the bootstrapping operation. This can be useful > if the manufacturer service is unavailable. This behavior SHOULD > be available via local configuration or physical presence methods > (such as use of a serial/craft console) to ensure new entities > can always be deployed even when autonomic methods fail. This > allows for unsecured imprint. I think #2 is actually too conservative; with a "TOFU" button one would reasonably be able to pair devices to a local, previously untrusted registrar. And #3 is I suppose something along those lines, but defined quite imprecisely. One should verify the exchanges and signatures and go through the whole process, but NOT require signature from the trusted MASA. Section 6.4: > 6.4. MASA security reductions > ... > 1. Not enforcing that a nonce is in the voucher. This results in > distribution of a voucher that never expires and in effect makes > the Domain an always trusted entity to the pledge during any > subsequent bootstrapping attempts. Depending on your viewpoint this may be a security reduction or increase. It is only a reduction if you are the manufacturer. Owners and users might wish to protect themselves against the manufacturer, however, in which case permanent vouchers are a feature, not a bug. Section 8: > 8. Privacy Considerations This does not discuss the role of serial numbers and other identifying information. Section 9: > 9. Security Considerations I expected to find a section that would go through the protocol and explain the security properties that it has, along with some discussion of residual vulnerabilities. What I found was a discussion of a handful of specific issues, such as the impacts of trusting the manufacturers, or why the nonce design is the way it is in the protocol. I'd find it useful to have, say, a discussion for each major mode of the protocol and what security properties it provides and does not provide. Nits/editorial comments: > BRSKI provides a solution for secure zero-touch (automated) bootstrap > of virgin (untouched) devices that are called pledges in this Maybe s/virgin (untouched)/new (unconfigured)/ > Services that benefit from this: > o Device management. > o Routing authentication. > o Service discovery. Are these examples? If so, say so? Otherwise, please specify why these services and not others are suitable for BRSKI. > the following actions are required and MUST be performed by the > pledge: > > o BRSKI: Request Voucher > o EST: CA Certificates Request > o EST: CSR Attributes > o EST: Client Certificate Request > o BRSKI: Enrollment status Telemetry Actions? Operations? Steps? (Later you use the term operations.) Would be good to clarify if the listed items are sending a message, or performing a procedure called , or something else. Wording here is quite loose. > 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices FWIW, it would have felt more natural to have thee requirements specified in the ANI documents, rather than here. > The pledge goes through a series of steps, which are outlined here at > a high level. The Section 2.1 steps in the figure do not match the "actions" from Section 1.5. > 4. Imprint on the registrar. This requires verification of the > manufacturer service provided voucher. A voucher contains > sufficient information for the pledge to complete authentication > of a registrar. (The embedded 'pinned-domain-certificate' > enables the pledge to finish authentication of the registrar TLS > server certificate). There is a lot going on here. Might have been better to separate the steps. > After imprint a secure transport exists between pledge and registrar. Do you mean there's an open TLS/TCP connection or that there are credentials&keys to securely communicate between the two? > The pledge goes through a series of steps, which are outlined here at > a high level. > > ... > > | +------v-------+ > | | (6) Enrolled | > ^------------+ | > Factory +--------------+ "Enrolled" is not a step, but rather a state... > 2. Securely authentating the pledges identity via TLS connection to typo > 2. Securely authentating the pledges identity via TLS connection to s/pledges/pledge's/? > registrar. This provides protection against cloned/fake pledged. s/pledged/pledge/? > 3. Secure auto-discovery of the pledges MASA by the registrar via > the MASA URI in IDevID as explained below. I can't parse the sentence. > 4. (Optionally) communicating the MUD URL (see Appendix C. Missing closing paren. > The following newly defined field SHOULD be in the PKIX IDevID > certificate: I didn't understand the formulation here. Are you defining one (seems like it below) or are you referencing a newly elsewhere defined field? Suggest a reformulation, e.g., "This document defines a new field for PKIX certificates. These fields SHOULD appear in the PKIX IDevID certificates when used with BRSKI." > Specifically, the IDevID: > > 1. Uniquely identifying the pledge by the Distinguished Name (DN) > ... > 2. Securely authentating the pledges identity via TLS connection to > ... > 3. Secure auto-discovery of the pledges MASA by the registrar via > ... > 4. (Optionally) communicating the MUD URL (see Appendix C. > > 5. (Optional) Signing of voucher-request by the pledges IDevID to > ... > 6. Authorizing pledge (via registrar) to receive certificate from There's something wrong with the language here. Maybe "Specifically, the IDevID enables the following: 1. Unique identification of the ..." Section 2.4 protocol flow is very different from the explanation in Section 2.1, which does not show the role of the background systems (MASA) at all. > P | /---> | | > P | | [accept device?] | > P | | [contact Vendor] | > P | | |--Pledge ID-------->| > P | | |--Domain ID-------->| > P | | |--optional:nonce--->| > P | | | [extract DomainID] > P | optional: | [update audit log] > P | |can | | > P | |occur | | > P | |in | | > P | |advance | | > P | |if | | > P | |nonceless | | > P | | |<- voucher ---------| > P | \----> | | I had a difficulty in understanding the notation here. Is the thing in the middle with the label "optional" a bracket that shows a part of the flow can be at a different place? Or is it some entity with some messages flowing from it, because it has arrows? I think the format, but this is unclear. > The registrar uses an Implicit Trust Anchor database for Upon the first reference to the term you should include a reference to RFC 7030. > be-determined mechanism (such as an Intent) to become the local Reference needed to "Intent". > 4.2. CoAP connection to Registrar > > The use of CoAP to connect from pledge to registrar is out of scope > for this document, and may be described in future work. I would just have said other mechanisms can be defined in future work. > In the nonced case, validation of the registrar MAY be omitted if the Nonced? > assertion: The assetion leaf in the voucher and audit log indicates Typo From nobody Fri Oct 5 06:31:26 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF798130E02 for ; Fri, 5 Oct 2018 06:31:24 -0700 (PDT) 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_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 OFrDuED25oMm for ; Fri, 5 Oct 2018 06:31:20 -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 BDF83128CF3 for ; Fri, 5 Oct 2018 06:31:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5C2C020090; Fri, 5 Oct 2018 09:31:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5A6292354; Fri, 5 Oct 2018 09:31:17 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 562FC12A0; Fri, 5 Oct 2018 09:31:17 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: <659e84c2-551c-4b7c-1002-b156337a92ac@gmail.com> References: <153825200726.18811.5817453433918930845@ietfa.amsl.com> <659e84c2-551c-4b7c-1002-b156337a92ac@gmail.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] I-D Action: draft-vanderstok-constrained-anima-dtls-join-proxy-00.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: Fri, 05 Oct 2018 13:31:25 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > How does the constrained pledge discover the LL address of the > constrained proxy? Depends upon the target environment. If ANIMA, then it would use GRASP, and probably we need to define an extension to the AN_Proxy announcement as previously discussed. I guess that extension could go into this document. If 6tisch, then it would use enhanced beacons. If something else, TBD. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlu3Z6QACgkQgItw+93Q 3WWztggAjLribPvSN1qUxoyhwtSXeTAZsO07V3rMxitjMILQr0BQqZinpoQsPO9f F0SNtj1hng3dwZebRmvMrsVjQxqepUdfH95EClOpyMXSt1kfIa1JEVDJ9VjtIQEZ 7dEh4DUwDtzv+zJlFkKEze2KSr+JmcyghOUrHibUOb9OTOKwAStsoiQYwHWDdm8j 0wk3zGw/kunqve1Zt1VOflDVxgCdRNNKk+r9yyzepn80FqZgu1IIP9E/pmXQGzbN 8juxSTNuuA6VxJujoJm9Nst9CuWkckiTxZUfPKqn36n52F8R8J2jtdaC6miKfqXE ++CzSdRhIhkBqoSooR86MqdClHal6w== =szS/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 5 06:34:16 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0528130DEB for ; Fri, 5 Oct 2018 06:34:13 -0700 (PDT) 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_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 mR3lQiERaxXS for ; Fri, 5 Oct 2018 06:34:12 -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 723DB130DC6 for ; Fri, 5 Oct 2018 06:34:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 981D220090; Fri, 5 Oct 2018 09:34:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 944A52354; Fri, 5 Oct 2018 09:34:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 911D012A0; Fri, 5 Oct 2018 09:34:11 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org cc: Brian E Carpenter , anima@ietf.org In-Reply-To: References: <153825200726.18811.5817453433918930845@ietfa.amsl.com> <659e84c2-551c-4b7c-1002-b156337a92ac@gmail.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] I-D Action: draft-vanderstok-constrained-anima-dtls-join-proxy-00.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: Fri, 05 Oct 2018 13:34:14 -0000 --=-=-= Content-Type: text/plain Peter van der Stok wrote: > The answer consists of a selection of text of section 7 of the draft. > The discovery follows the standard coap discovery. > ________________________________________________________________ > The discovery of the Join-Proxy by the > Pledge is an extension to the discovery described in section 4 of > [I-D.ietf-anima-bootstrapping-keyinfra]. In particular this section > replaces section 4.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. > The Pledge can discover a Join-Proxy by sending a link-local > multicast message to ALL CoAP Nodes with address FF01::FD. Multiple > or no nodes may respond. The handling of multiple responses and the > absence of responses follow section 4 of > [I-D.ietf-anima-bootstrapping-keyinfra]. That would be the all-CoAP solution where the pledge attracks attention to iself. I don't think it would be used in an ANIMA ACP situation, but I think that Peter has some ideas where it would be useful. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlu3aFMACgkQgItw+93Q 3WV8owgArxC7r6XmaFhx9TYVdQfLJvp04WjvxRcgBVQtFDooaTU5Dfx6E/2QO4rL cbfU2Y3ozvUXoM/zvYxL+qGaB03vFAEelPxxCjE12xl/4SWS3u6wlxxjxdfIei91 PD6ms7HD6fb95hqIKIpZyzLYd2G4sdOXoNEh7E/nwyh0ClKX2HD2BCGUiTxVBxT0 azVX3P9ynQfODF6AuVjKeZm8FqM8dqZLokHeigU1jiTN+9M6nEBfAq76tygHpo+8 btDSFqq+lHIZzZbrp/1fQiIxbKiXPesSmW23mmxi/fNt3chGq+tC7T+hi1f2Osh7 /LkX2vBI6s7GTTKfhdr1HqJh7bj5qA== =AbBs -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 5 12:42:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6AA130EB2 for ; Fri, 5 Oct 2018 12:42:04 -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_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 RMp28uvvoEeA for ; Fri, 5 Oct 2018 12:42:01 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 D8D65130EC8 for ; Fri, 5 Oct 2018 12:42:01 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id v5-v6so7270700plz.13 for ; Fri, 05 Oct 2018 12:42:01 -0700 (PDT) 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=cevDjOj2vprYHW6YXcIzKDoagWAsvhaQoMdCPEYnoQs=; b=m3n+AiwCD6wx657Tx1xB2mEWAsfGPMC878ta2MYn/L3y3Mwtfu10kk/QroXhErgzFE pxwlcvbWutBwBGjjk0xITTRRNnw/VFoymQe+fsaKpdC9WzxpyCGVOSZOLTQJ1HnYUiw4 eJ3P9JfcdzeDCjb3tGbdaadtKcdScyw3j3XZWDYwLoRjxqQjugejGwHgqbCeedCAbyOk G2+YqdrHgumQh18x2QEzQAkBLZNuqJkBXf8fk8JdYpmbr+GtkAqxQeIWLVFb8hINaUYm eLKCqWzCUZsns4fWQsdINsxtBh6cet4GmGwYvi9sPqZ8nfEkGP/ySDTL/7wtO1iHHtDe BqjA== 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=cevDjOj2vprYHW6YXcIzKDoagWAsvhaQoMdCPEYnoQs=; b=m502Mr5soZrTRxgElMajs7rvHXIvWgQswTlRI0387Yjr2aqOiLpHxgT3mv2fzcfbV/ Z/c24L+DXzRd1T7Ah6kZVxEOTIXoPd3hUxlqWILt1Mc3KCRNapxRTPSRoCgeTA0b7MLo tf/6tW2UBB2uovvMjOBiSua0JaGvkivIl7ueyLpBVv7dAdDthnUNvh5/XHYaj9taTFvC viS1Kqi58esemdvBmW70qdp58pyIvwL45FwKDALPoKUrKDEGJ+5tIsxhbJtveKA46Mp0 MvwuziDqE69BuEcITZRcX4WEY7iHgotvKBDkjdOcEsuEKCdRK18qGHlgXYR8R7GUbFar aYxw== X-Gm-Message-State: ABuFfoi6vLO5ER0zppWn2eK0Gf1OL773FK9cijUIi/LXcmbzyPtM4uH2 nZOWeFjCneI1q71n2hNdXZc++/Ib X-Google-Smtp-Source: ACcGV61UJV2TzDQECbzQzC7bNTwznJu/UwakxlotDCQFncm2y+hu4T83QcDkXe3j9RKGa1tA/Js/ow== X-Received: by 2002:a17:902:7b84:: with SMTP id w4-v6mr12642130pll.32.1538768521084; Fri, 05 Oct 2018 12:42:01 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id m27-v6sm14091173pff.187.2018.10.05.12.41.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Oct 2018 12:42:00 -0700 (PDT) To: consultancy@vanderstok.org Cc: anima@ietf.org References: <153825200726.18811.5817453433918930845@ietfa.amsl.com> <659e84c2-551c-4b7c-1002-b156337a92ac@gmail.com> From: Brian E Carpenter Message-ID: Date: Sat, 6 Oct 2018 08:41:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.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] I-D Action: draft-vanderstok-constrained-anima-dtls-join-proxy-00.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: Fri, 05 Oct 2018 19:42:14 -0000 Peter, On 2018-10-05 20:24, Peter van der Stok wrote: > Hi Brian. > > The answer consists of a selection of text of section 7 of the draft. Huh? Section 7 is "security considerations" and the text you quote below is nowhere in the draft. Maybe it's time for version -01 already? Also, ff01::fd confuses me. It is not a link-local address - it is node-local. I think you mean ff02::fd, which is link-local and belongs to COAP. Regards Brian > The discovery follows the standard coap discovery. > ________________________________________________________________ > The discovery of the Join-Proxy by the > Pledge is an extension to the discovery described in section 4 of > [I-D.ietf-anima-bootstrapping-keyinfra]. In particular this section > replaces section 4.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. > > The Pledge can discover a Join-Proxy by sending a link-local > multicast message to ALL CoAP Nodes with address FF01::FD. Multiple > or no nodes may respond. The handling of multiple responses and the > absence of responses follow section 4 of > [I-D.ietf-anima-bootstrapping-keyinfra]. > > The presence and location of (path to) the join-proxy resource are > discovered by sending a MC GET request to "/.well-known/core" > including > a resource type (RT) parameter with the value "brski-proxy" > [RFC6690]. Upon success, the return payload will contain the root > resource of the Join-Proxy resources. > > ____________________________________________________________ Looking > forward to your comments and suggestions, > > Peter > Brian E Carpenter schreef op 2018-10-05 04:03: > >> How does the constrained pledge discover the LL address of the constrained proxy? >> >> Regards >> Brian Carpenter >> >> On 2018-09-30 09:13, internet-drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> Title : Constrained Join Proxy for Bootstrapping Protocols >>> Authors : Michael Richardson >>> Peter van der Stok >>> Panos Kampanakis >>> Filename : draft-vanderstok-constrained-anima-dtls-join-proxy-00.txt >>> Pages : 10 >>> Date : 2018-09-29 >>> >>> Abstract: >>> This document defines a protocol to securely assign a pledge to an >>> owner, using an intermediary node between pledge and owner. This >>> intermediary node is known as a "constrained-join-proxy". >>> >>> This document extends the work of >>> [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- >>> proxy by a stateless constrained join-proxy, that uses IP >>> encapsulation. >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-vanderstok-constrained-anima-dtls-join-proxy/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00 >>> https://datatracker.ietf.org/doc/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00 >>> >>> 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/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima From nobody Fri Oct 5 13:03:19 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753281274D0; Fri, 5 Oct 2018 13:03:11 -0700 (PDT) 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 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 iUl3qzESzRt6; Fri, 5 Oct 2018 13:03:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3171B126BED; Fri, 5 Oct 2018 13:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19586; q=dns/txt; s=iport; t=1538769788; x=1539979388; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tcTIQ3sROO5LNEj1gPk2H25pOHXfsf3JcO1xY8m+cfw=; b=c77b/ZnnRVE4t6T4t1oWnG1e1a9FD9cEud42ScA7hdzdX2BQl0JMd+DA 1PLzYbpq2xYgjW95WrVfkg+R7zajtezKdsCFnv3h/tiTqPb4EhHCrgR2t Rc44WSmXaMtoV7HjhmD+OI/jw21cMoDDGTCGnvYFPfirc+2wwL8cr8S58 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAAAhw7db/4UNJK1jDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVIDAQEBAQELAYFbKmZ/KAqDapQ7gWiBHZAmhUAUgWY?= =?us-ascii?q?LAQEYAQqEA0YCF4QYITUMDQEDAQECAQECbRwMhToCAQMBASFLCxACAQg/AwI?= =?us-ascii?q?CAiULFBECBAoEBYMhAYEdZA+kZYEuihmLMReCAIESJwwTghcHLoMbAQEDgTc?= =?us-ascii?q?QTYJLMYImAogzBzEWBYUDjwgOQwkChkqDEYRGgiMXgUxLhBqJQ4cFhRmJIQI?= =?us-ascii?q?RFIElHwI0gVVwFTsqAYJBCYIdFxFqAQyHUoUEOm+LeIEugR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,345,1534809600"; d="scan'208,217";a="459035646" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2018 20:02:56 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w95K2uWX016804 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Oct 2018 20:02:56 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 5 Oct 2018 15:02:55 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1395.000; Fri, 5 Oct 2018 15:02:55 -0500 From: "Max Pritikin (pritikin)" To: Uri Blumenthal CC: Brian E Carpenter , "randy@psg.com" , Eliot Lear , "anima@ietf.org" , Security Directorate Thread-Topic: [Anima] [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 Thread-Index: AQHUWrVmgB2wYYbock+QT5LGcM09j6URazOA Date: Fri, 5 Oct 2018 20:02:55 +0000 Message-ID: <7A4C6D47-A343-4319-8EDD-8403530B3BD3@cisco.com> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: multipart/alternative; boundary="_000_7A4C6D47A34343198EDD8403530B3BD3ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Anima] [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16 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, 05 Oct 2018 20:03:12 -0000 --_000_7A4C6D47A34343198EDD8403530B3BD3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpHcmVhdCB0aHJlYWQgeW91IGFsbC4gU29tZSBrZXkgcG9pbnRzIGZvciByZXNwb25zZSBmb2xs b3cuIEFkZGl0aW9uYWxseSB3ZeKAmXJlIHdvcmtpbmcgdGhyb3VnaCBlYWNoIG51bWJlcmVkIGNv bW1lbnQgc3BlY2lmaWNhbGx5Lg0KDQpHZW5lcmFsbHkgbGV0cyBrZWVwIHRoZSBzY29wZSBvZiBC UlNLSSBpbiBtaW5kLiBJdCBpcyBhIG5ldyBwcm90b2NvbCBmb3IgYm9vdHN0cmFwcGluZyB2aWEg dm91Y2hlcnMuIEl0IGRvZXMgbm90IHByZWNsdWRlIHRoZSB1c2Ugb2YgYSBsb2NhbCBjb25zb2xl IGZvciBib290c3RyYXBwaW5nL2Fzc2VydGluZyBvd25lcnNoaXAuIFRoZSBjdXJyZW50IHZvdWNo ZXIgZm9ybWF0IGlzIGEgc3RhcnRpbmcgcG9pbnQgYW5kIHRoZXJlIGlzIGFscmVhZHkgd29yayBp biBwcm9ncmVzcyBmb3IgdmFyaW91cyBhZGRpdGlvbmFsIGZvcm1zIG9mIHZvdWNoZXJzIHRvIGFk ZHJlc3MgdGhlIG90aGVyIHVzZSBjYXNlcyBicm91Z2h0IHVwLg0KDQpSZTogQ2FuIHZvdWNoZXJz IGJlIGRpc3RyaWJ1dGVkIGRpcmVjdGx5IHJhdGhlciB0aGFuIHRocm91Z2ggdGhlIEJSU0tJLU1B U0Egc3ViLXByb3RvY29sDQoNClZvdWNoZXJzIGFyZSBzaWduZWQgbWVzc2FnZXMgYW5kIHRoZXJl IGFyZSBhIG51bWJlciBvZiBkaXN0cmlidXRpb24gbW9kZWxzIGF2YWlsYWJsZS4gVGhpcyBwcm90 b2NvbCBkZXNjcmliZXMgYSBwcmVkb21pbmF0ZWx5IG9ubGluZSBtb2RlbC4gVGhlIG5ldGNvbmYg emVyb3RvdWNoIGRyYWZ0IGRlc2NyaWJlcyBhIGRpZmZlcmVudCBtZXRob2QgdXNpbmcgdGhlIHNh bWUgdm91Y2hlcnMgd2l0aCBzbGlnaHRseSBkaWZmZXJlbnQgb3BlcmF0aW9uYWwgdHJhZGUtb2Zm cy4gVGhlIGludGVudGlvbiBpcyB0aGF0IGJldHdlZW4gdGhlc2UgYSBnb29kIGZvdW5kYXRpb24g aXMgc2V0IGZvciBhbGwgdXNlIGNhc2VzICh3aXRoIGEgZm9jdXMgb24gYW5pbWEgYW5kIG5ldGNv bmY7IHdoZXJlIHRoZXNlIGRvY3VtZW50cyB3ZXJlIHdvcmtpbmcgZ3JvdXAgaXRlbXMpLiBBcyBk ZXNjcmliZWQgYmVsb3cgdGhlIGN1cnJlbnQgbWV0aG9kIGFuZCBjdXJyZW50IEJSU0tJIGZsb3cg d29yayB3aXRoIGRpcmVjdCBkaXN0cmlidXRpb24gYXMgZW52aXNpb25lZCBieSBzb21lIG9mIHRo ZSBkaXNjdXNzaW9uIG9uIHRoaXMgdGhyZWFkIChlLmcuIG5vIE1BU0EpIGJ1dCB0aGF0IGlzIG5v dCBhIHByaW1hcnkgdXNlIGNhc2UuIFRoZSBleGlzdGluZyB3b3JrIG9uIG1vcmUgY29uc3RyYWlu ZWQgdm91Y2hlciBmb3JtYXRzIGNvdWxkIGhlbHAgdG8gZW5hYmxlIHRob3NlIGlkZWFzIGEgbW9y ZSBkaXJlY3QgdXNlIGNhc2VzIGJ1dCB3aWxsIG5vdCByZXF1aXJlIEJSU0tJIHByb3RvY29sIGV4 Y2hhbmdlcyB0byBjaGFuZ2UuDQoNClJlOiBEb2VzIEJSU0tJIGNoYW5nZSB0aGUgb3duZXJzaGlw IG1vZGVsIGZyb20gdGhlIG93bmVyIHRvIHRoZSBtYW51ZmFjdHVyZXI/DQoNCkFic29sdXRlbHkg bm90LiBCUlNLSSBkZWZpbmVzIGEgc2NhbGFibGUgbWV0aG9kIG9mIGJvb3RzdHJhcHBpbmcgcmVt b3RlIHNlY3VyZSBrZXkgaW5mcmFzdHJ1Y3R1cmVzIHZpYSB0aGUgZGlzdHJpYnV0aW9uIG9mIOKA nHZvdWNoZXJz4oCdIGZyb20gdGhlIHJlZ2lzdHJhciB0byB0aGUgZGV2aWNlLiBJdCBzcGVjaWZp Y2FsbHkgYXR0ZW1wdHMgdG8gZW5zdXJlIHRoZSByZWdpc3RyYXIgKG93bmVyKSBpcyBpbiBjb250 cm9sIG9mIGRlY2lzaW9ucyBhbmQgYXR0ZW1wdHMgdG8gbWluaW1pemUgc3VwcGx5IGNoYWluIGlu dGVncmF0aW9ucyAoZS5nLiBob3cgbXVjaCB0aGUgdmVuZG9yIGV2ZW4ga25vd3MgYWJvdXQgd2hv IGFjdHVhbGx5IG93bnMgYSBkZXZpY2UpLiBUaGUgc3RydWN0dXJlIGlzIHN1Y2ggdGhhdCBhIDNy ZCBwYXJ0eSBjb3VsZCBwcm92aWRlIGFsbCB0aGUgTWFudWZhY3R1cmVyIEF1dGhvcml6ZWQgU2ln bmluZyBBdXRob3JpdHkgKE1BU0EpIHJlc3BvbnNpYmlsaXRpZXMg4oCUIHRodXMgZW5hYmxpbmcg Y29tcGxldGUgdmVuZG9yIGluZGVwZW5kZW5jZSBmcm9tIGEgQlJTS0kgcHJvdG9jb2wgcGVyc3Bl Y3RpdmUuIEl0IHNwZWNpZmljYWxseSBzdXBwb3J0cyBtb2RlbHMgd2hlcmVpbiB0aGUgdm91Y2hl ciBpcyBkaXN0cmlidXRlZCBpbiBhZHZhbmNlLCBvbiBhIDJkIGJhcmNvZGUgb3IgaW4gc2FsZXMg bWF0ZXJpYWwgb3Igd2hhdGV2ZXIuIFRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uIG9mIGEgc2VjdXJl IGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgZGV2aWNlIGFuZCB0aGUgdmVuZG9yIChiZXlvbmQgYW4g ZXhwZWN0YXRpb24gdGhhdCB2b3VjaGVycyBhcmUgc2lnbmVkKS4gVGhlIGdvYWwgaGVyZSBpcyB0 byBhbGxvdyB0aGUgdmVuZG9yIHRvIGhlbHAgcHJvdmlkZSBhIHNjYWxhYmxlIGRlcGxveW1lbnQg bW9kZWwuDQoNClJlOiBXaGF0IGFib3V0IHRyYW5zZmVyIG9mIG93bmVyc2hpcDsgcGFydGljdWxh cmx5IGlmIHRoZSBNQVNBIGlzIGFudGFnb25pc3RpYyB0byByZXNhbGU/DQoNCkJlY2F1c2UgdGhl cmUgaXMgbm8gZXhwZWN0YXRpb24gb2Ygc2FsZXMtY2hhbm5lbCBpbnRlZ3JhdGlvbiB0aGlzIGlz IHJlYWxseSBsaW1pdGVkIHRvIGRpc2N1c3Npb25zIG9mIGFudGFnb25pc3RpYyB2ZW5kb3JzLiBJ IGFwcGxhdWQgcHVyY2hhc2luZyBkZWNpc2lvbnMgdG8gYXZvaWQgc3VjaCB2ZW5kb3JzLiBTdWNo IHZlbmRvcnMgYXJlIG9ubHkgYWJsZSB0byByZWplY3QgemVybyB0b3VjaCBkZXBsb3ltZW50IOKA lCB0aGV5IGNhbuKAmXQgZWZmZWN0IGN1c3RvbWVycyB0aGF0IHVzZSBsZXNzIHNjYWxhYmxlIGRl cGxveW1lbnQgbW9kZWxzIHN1Y2ggYXMgY29uc29sZSBhY2Nlc3MuIEFsbCB2ZW5kb3JzIGhhdmUg dGhlIG9wdGlvbiBvZiBsZXZlcmFnaW5nIHNlY3VyaXR5IHRlY2hub2xvZ2llcyB0byBtYWtlIHJl c2FsZSBkaWZmaWN1bHQuLi4gdGhlIGV4aXN0ZW5jZSBvZiBCUlNLSSBvbmx5IGV4cG9zZXMgc3Vj aCBhdHRlbXB0cyBpbiB0aGUgc2FtZSB3YXkgdGhlIHNpZ25lZCBpbWFnZSBsb2FkaW5nIGhpZ2hs aWdodHMgc2ltaWxhciBhdHRlbXB0cyB0byBhdm9pZCAzcmQgcGFydHkgY29kZS4NCg0KQXMgcGVy IHRoZSBiYXNpYyB0cnVzdCBtb2RlbCB0aGUgcmVnaXN0cmFyIGNhbiBldmVuIHByb3ZpZGUgdGhl IG5ldyBvd25lciA5MCUgb2YgdGhlIGZ1bmN0aW9uYWxpdHkgZXZlbiBpbiB0aGUgZmFjZSBvZiBh biBhbnRhZ29uaXN0aWMgTUFTQTogVGhlIG93bmVyIGNhbiBvYnRhaW4gYSBub25jZS1sZXNzIHZv dWNoZXIgYWdhaW5zdCBhIGRldmljZSBzcGVjaWZpYyByZWdpc3RyYXIga2V5cGFpci4gVGhpcyB0 aGVuIHByb3ZpZGVzIHRoZW0gYSBwZXJtYW5lbnQgbWV0aG9kIG9mIGJvb3RzdHJhcHBpbmcgdGhl IGRldmljZSB0aGF0IHRoZXkgY2FuIHNhZmVseSBwcm92aWRlIHdpdGggdGhlIGRldmljZSBkdXJp bmcgcmVzYWxlLiBUaGlzIG1haW50YWlucyB0aGUgbWFqb3JpdHkgdmFsdWUgb2YgdGhlIHByb3Rv Y29sIHRvIHRoZSBuZXcgb3duZXIgd2hpbGUgY29tcGxldGVseSBjaXJjdW12ZW50aW5nIGFueSBm dXR1cmUgYW50YWdvbmlzbSBieSB0aGUgdmVuZG9yLiBUaGUgZGV2aWNlIGNhbiBiZSByZXNldCB0 byBmYWN0b3J5IGRlZmF1bHRzIGJlZm9yZSB0aGUgc2FsZS4NCg0KUmU6IFdoYXQgaGFwcGVucyBp ZiB0aGUgTUFTQSBzZXJ2aWNlIGlzIHVuYXZhaWxhYmxlPw0KDQpCUlNLSSBpcyBmb3IgdGhlIHRy YW5zZmVyIG9mIHRydXN0IHRvIHRoZSBjdXJyZW50IG93bmVyLiBUaGVyZSBpcyBubyBlZmZlY3Qg dG8gZGVwbG95ZWQgZGV2aWNlcy4NCkFzIGRpc2N1c3NlZCBpbiB0aGlzIHRocmVhZCB0aGVyZSBh cmUgZmFjaWxpdGllcyBmb3Igbm9uY2UtbGVzcyBwZXJtYW5lbnQgdm91Y2hlcnMgaW5jbHVkaW5n IG9uZXMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgcmVzYWxlLiBBbiBvd25lciB0aGF0IGlzIHdvcnJp ZWQgYWJvdXQgcmUtZGVwbG95aW5nIGluIHRoZSBmdXR1cmUgc3RhdGUgY2FuIHRha2UgdGhpcyBh cHByb2FjaC4gRWl0aGVyIHVzaW5nIGEgY29tbW9uIHJlZ2lzdHJhciBvciBieSB1c2luZyBhIHJl Z2lzdHJhciBwZXIgZGV2aWNlIChkZXBlbmRpbmcgb24gaWYgdGhleSBwbGFuIHRvIHJlc2FsZSku DQoNClRoZXJlIHdpbGwgYWx3YXlzIGJlIGNhc2VzIHdoZXJlIGEgdmVuZG9yIGdvZXMgYXdheSBh bmQgYSBkZXZpY2UgaXMgdGhlcmVmb3JlIGxpbWl0ZWQuIEZvciBleGFtcGxlIHNlY3VyaXR5IHVw ZGF0ZXMgdG8gc2lnbmVkIGZpcm13YXJlIGNhbiBiZSBpbXBhY3RlZCBpZiB0aGUgdmVuZG9yIG5v IGxvbmdlciBwcm9kdWNlcyB0aGVtLiBCUlNLSSBkb2VzIG1ha2UgdGhpcyByZWFsaXR5IHdvcnNl Lg0KDQotIG1heA0KDQpPbiBPY3QgMiwgMjAxOCwgYXQgNzowNiBQTSwgVXJpIEJsdW1lbnRoYWwg PHVyaUBtaXQuZWR1PG1haWx0bzp1cmlAbWl0LmVkdT4+IHdyb3RlOg0KDQpCYXNlZCBvbiB0aGlz IGV4Y2hhbmdlLCBhbmQgdGhlIGFyZ3VtZW50cyBwcmVzZW50ZWQgaGVyZSB0aGF0IEkgb2JzZXJ2 ZWQgc28gZmFyLCBJJ20gd2l0aCBSYW5keS4gSSBoYXZlIG5vdCBzZWVuIGFkZXF1YXRlIGFuc3dl cnMgdG8gaGlzIGNvbmNlcm5zICh3aGljaCBJTUhPIGFyZSByZWFzb25hYmxlKS4NCg0KUC5TLiBG ZWVsIGZyZWUgdG8gdHJpbSB0aGUgQ0M6IGxpc3Qgd2hlbi9pZiByZXNwb25kaW5nLg0KDQpQLlAu Uy4gSW4gb25lIG9mIG15IHByaW9yIGluY2FybmF0aW9ucyBtYW55IHllYXJzIGFnbywgd2UgZGVz aWduZWQgYSBzb21ld2hhdCBzaW1pbGFyIHN5c3RlbSwgYW5kIGNhbGxlZCBpdCAiWmVyby1Ub3Vj aCBQcm92aXNpb25pbmciLiBJdCB3YXMgYSB2ZXJ5IGJpZyBjb21wYW55LCBzbyB3ZSBkaWQgbm90 IGNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZiBpdC91cyBnb2luZyBvdXQgb2YgYnVzaW5lc3Mg KGFuZCBsZWF2aW5nIHRoZSBjdXN0b21lcnMgc3RyYW5kZWQpLiBCdXQgaWYgUmFuZHkncyBhcmd1 bWVudHMgd2VyZSBwcmVzZW50ZWQgdG8gb3VyIHRlYW0gdGhlbiwgd2UnZCBwcm9iYWJseSBhY2Nl cHRlZCB0aGVtIGFuZCB0cmllZCB0byBhZGRyZXNzLi4uDQoNClNlbnQgZnJvbSBteSB0ZXN0IGlQ aG9uZQ0KDQpPbiBPY3QgMiwgMjAxOCwgYXQgMjA6NTMsIFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5j b208bWFpbHRvOnJhbmR5QHBzZy5jb20+PiB3cm90ZToNCg0KSSB0aGluayBpdCdzIGJlZW4gdGhv dWdodCB0aHJvdWdoIGJ1dCBiYWRseSBhcnRpY3VsYXRlZC4gSW4gdGhhdCBzZW5zZSwNCnRoZSBM YXN0IENhbGwgaXMgZG9pbmcgaXRzIGpvYi4NCg0KZG9lcyB0aGF0IG1lYW4gdGhhdCBpIGNhbiBz dG9wIHRyeWluZyBmb3IgYSBuYXJ0ZW4gbWVkYWwsIGdvIGJhY2sgdG8NCndvcmssIGFuZCBjaHJp c3RpYW4gd2lsbCB3YWtlIG1lIHVwIGFnYWluIHdoZW4gbXkgdHdvIHNjZW5hcmlvcyBoYXZlDQpj bGVhciBhbnN3ZXJzOyBvbmUgaG9wZXMgb25lcyB3aXRoIHdoaWNoIGkgY2FuIGxpdmU/DQoNCmFs c28sIHBsZWFzZSB0ZWxsIG1lIHRoYXQgaSBkbyBub3QgbmVlZCB0byBzdGljayBteSBub3NlIGlu dG8gdGhlIHJlc3QNCm9mIGFuaW1hIGluIG9yZGVyIHRvIGxldCB0aGUgdXNlciB1bmVxdWl2b2Nh bGx5IG93biB3aGF0IHRoZXkgYnV5LiAgaQ0KaGF2ZSBteSBvd24gcmFiYml0IGhvbGVzIHRvIHB1 cnN1ZSBpbiB0aGUgaWV0Zi4NCg0KcmFuZHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNlY2RpciBtYWlsaW5nIGxpc3QNCnNlY2RpckBpZXRmLm9y ZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZWNkaXINCndpa2k6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFj L3dpa2kvU2VjRGlyUmV2aWV3DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KQW5pbWEgbWFpbGluZyBsaXN0DQpBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5p bWFAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1h DQoNCg== --_000_7A4C6D47A34343198EDD8403530B3BD3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3C29DCB5E58F6D44A4B98DCE3C3EA6A4@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWF0IHRocmVhZCB5b3UgYWxsLiBTb21lIGtleSBwb2lu dHMgZm9yIHJlc3BvbnNlIGZvbGxvdy4gQWRkaXRpb25hbGx5IHdl4oCZcmUgd29ya2luZyB0aHJv dWdoIGVhY2ggbnVtYmVyZWQgY29tbWVudCBzcGVjaWZpY2FsbHkuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HZW5lcmFsbHkgbGV0cyBr ZWVwIHRoZSBzY29wZSBvZiBCUlNLSSBpbiBtaW5kLiBJdCBpcyBhIG5ldyBwcm90b2NvbCBmb3Ig Ym9vdHN0cmFwcGluZyB2aWEgdm91Y2hlcnMuIEl0IGRvZXMgbm90IHByZWNsdWRlIHRoZSB1c2Ug b2YgYSBsb2NhbCBjb25zb2xlIGZvciBib290c3RyYXBwaW5nL2Fzc2VydGluZyBvd25lcnNoaXAu IFRoZSBjdXJyZW50IHZvdWNoZXIgZm9ybWF0IGlzIGEgc3RhcnRpbmcgcG9pbnQgYW5kIHRoZXJl DQogaXMgYWxyZWFkeSB3b3JrIGluIHByb2dyZXNzIGZvciB2YXJpb3VzIGFkZGl0aW9uYWwgZm9y bXMgb2Ygdm91Y2hlcnMgdG8gYWRkcmVzcyB0aGUgb3RoZXIgdXNlIGNhc2VzIGJyb3VnaHQgdXAu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YiBjbGFzcz0iIj5SZTogQ2FuIHZvdWNoZXJzIGJlIGRpc3RyaWJ1dGVkIGRpcmVjdGx5IHJh dGhlciB0aGFuIHRocm91Z2ggdGhlIEJSU0tJLU1BU0Egc3ViLXByb3RvY29sPC9iPjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Vm91Y2hl cnMgYXJlIHNpZ25lZCBtZXNzYWdlcyBhbmQgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIGRpc3RyaWJ1 dGlvbiBtb2RlbHMgYXZhaWxhYmxlLiBUaGlzIHByb3RvY29sIGRlc2NyaWJlcyBhIHByZWRvbWlu YXRlbHkgb25saW5lIG1vZGVsLiBUaGUgbmV0Y29uZiB6ZXJvdG91Y2ggZHJhZnQgZGVzY3JpYmVz IGEgZGlmZmVyZW50IG1ldGhvZCB1c2luZyB0aGUgc2FtZSB2b3VjaGVycyB3aXRoIHNsaWdodGx5 IGRpZmZlcmVudA0KIG9wZXJhdGlvbmFsIHRyYWRlLW9mZnMuIFRoZSBpbnRlbnRpb24gaXMgdGhh dCBiZXR3ZWVuIHRoZXNlIGEgZ29vZCBmb3VuZGF0aW9uIGlzIHNldCBmb3IgYWxsIHVzZSBjYXNl cyAod2l0aCBhIGZvY3VzIG9uIGFuaW1hIGFuZCBuZXRjb25mOyB3aGVyZSB0aGVzZSBkb2N1bWVu dHMgd2VyZSB3b3JraW5nIGdyb3VwIGl0ZW1zKS4gQXMgZGVzY3JpYmVkIGJlbG93IHRoZSBjdXJy ZW50IG1ldGhvZCBhbmQgY3VycmVudCBCUlNLSSBmbG93IHdvcmsgd2l0aA0KIGRpcmVjdCBkaXN0 cmlidXRpb24gYXMgZW52aXNpb25lZCBieSBzb21lIG9mIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMg dGhyZWFkIChlLmcuIG5vIE1BU0EpIGJ1dCB0aGF0IGlzIG5vdCBhIHByaW1hcnkgdXNlIGNhc2Uu IFRoZSBleGlzdGluZyB3b3JrIG9uIG1vcmUgY29uc3RyYWluZWQgdm91Y2hlciBmb3JtYXRzIGNv dWxkIGhlbHAgdG8gZW5hYmxlIHRob3NlIGlkZWFzIGEgbW9yZSBkaXJlY3QgdXNlIGNhc2VzIGJ1 dCB3aWxsIG5vdCByZXF1aXJlDQogQlJTS0kgcHJvdG9jb2wgZXhjaGFuZ2VzIHRvIGNoYW5nZS4m bmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiIGNsYXNzPSIiPlJlOiBEb2VzIEJSU0tJIGNoYW5nZSB0aGUgb3duZXJzaGlwIG1v ZGVsIGZyb20gdGhlIG93bmVyIHRvIHRoZSBtYW51ZmFjdHVyZXI/PC9iPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWJzb2x1dGVseSBu b3QuIEJSU0tJIGRlZmluZXMgYSBzY2FsYWJsZSBtZXRob2Qgb2YgYm9vdHN0cmFwcGluZyByZW1v dGUgc2VjdXJlIGtleSBpbmZyYXN0cnVjdHVyZXMgdmlhIHRoZSBkaXN0cmlidXRpb24gb2Yg4oCc dm91Y2hlcnPigJ0gZnJvbSB0aGUgcmVnaXN0cmFyIHRvIHRoZSBkZXZpY2UuIEl0IHNwZWNpZmlj YWxseSBhdHRlbXB0cyB0byBlbnN1cmUgdGhlIHJlZ2lzdHJhciAob3duZXIpIGlzIGluIGNvbnRy b2wgb2YgZGVjaXNpb25zDQogYW5kIGF0dGVtcHRzIHRvIG1pbmltaXplIHN1cHBseSBjaGFpbiBp bnRlZ3JhdGlvbnMgKGUuZy4gaG93IG11Y2ggdGhlIHZlbmRvciBldmVuIGtub3dzIGFib3V0IHdo byBhY3R1YWxseSBvd25zIGEgZGV2aWNlKS4gVGhlIHN0cnVjdHVyZSBpcyBzdWNoIHRoYXQgYSAz cmQgcGFydHkgY291bGQgcHJvdmlkZSBhbGwgdGhlIE1hbnVmYWN0dXJlciBBdXRob3JpemVkIFNp Z25pbmcgQXV0aG9yaXR5IChNQVNBKSByZXNwb25zaWJpbGl0aWVzIOKAlCB0aHVzDQogZW5hYmxp bmcgY29tcGxldGUgdmVuZG9yIGluZGVwZW5kZW5jZSBmcm9tIGEgQlJTS0kgcHJvdG9jb2wgcGVy c3BlY3RpdmUuIEl0IHNwZWNpZmljYWxseSBzdXBwb3J0cyBtb2RlbHMgd2hlcmVpbiB0aGUgdm91 Y2hlciBpcyBkaXN0cmlidXRlZCBpbiBhZHZhbmNlLCBvbiBhIDJkIGJhcmNvZGUgb3IgaW4gc2Fs ZXMgbWF0ZXJpYWwgb3Igd2hhdGV2ZXIuIFRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uIG9mIGEgc2Vj dXJlIGNvbm5lY3Rpb24gYmV0d2Vlbg0KIHRoZSBkZXZpY2UgYW5kIHRoZSB2ZW5kb3IgKGJleW9u ZCBhbiBleHBlY3RhdGlvbiB0aGF0IHZvdWNoZXJzIGFyZSBzaWduZWQpLiBUaGUgZ29hbCBoZXJl IGlzIHRvIGFsbG93IHRoZSB2ZW5kb3IgdG8gaGVscCBwcm92aWRlIGEgc2NhbGFibGUgZGVwbG95 bWVudCBtb2RlbC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj5SZTogV2hhdCBh Ym91dCB0cmFuc2ZlciBvZiBvd25lcnNoaXA7IHBhcnRpY3VsYXJseSBpZiB0aGUgTUFTQSBpcyBh bnRhZ29uaXN0aWMgdG8gcmVzYWxlPzwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlY2F1c2UgdGhlcmUgaXMgbm8gZXhwZWN0YXRp b24gb2Ygc2FsZXMtY2hhbm5lbCBpbnRlZ3JhdGlvbiB0aGlzIGlzIHJlYWxseSBsaW1pdGVkIHRv IGRpc2N1c3Npb25zIG9mIGFudGFnb25pc3RpYyB2ZW5kb3JzLiBJIGFwcGxhdWQgcHVyY2hhc2lu ZyBkZWNpc2lvbnMgdG8gYXZvaWQgc3VjaCB2ZW5kb3JzLiBTdWNoIHZlbmRvcnMgYXJlIG9ubHkg YWJsZSB0byByZWplY3QgemVybyB0b3VjaCBkZXBsb3ltZW50IOKAlCB0aGV5DQogY2Fu4oCZdCBl ZmZlY3QgY3VzdG9tZXJzIHRoYXQgdXNlIGxlc3Mgc2NhbGFibGUgZGVwbG95bWVudCBtb2RlbHMg c3VjaCBhcyBjb25zb2xlIGFjY2Vzcy4gQWxsIHZlbmRvcnMgaGF2ZSB0aGUgb3B0aW9uIG9mIGxl dmVyYWdpbmcgc2VjdXJpdHkgdGVjaG5vbG9naWVzIHRvIG1ha2UgcmVzYWxlIGRpZmZpY3VsdC4u LiB0aGUgZXhpc3RlbmNlIG9mIEJSU0tJIG9ubHkgZXhwb3NlcyBzdWNoIGF0dGVtcHRzIGluIHRo ZSBzYW1lIHdheSB0aGUgc2lnbmVkDQogaW1hZ2UgbG9hZGluZyBoaWdobGlnaHRzIHNpbWlsYXIg YXR0ZW1wdHMgdG8gYXZvaWQgM3JkIHBhcnR5IGNvZGUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BcyBwZXIgdGhlIGJhc2lj IHRydXN0IG1vZGVsIHRoZSByZWdpc3RyYXIgY2FuIGV2ZW4gcHJvdmlkZSB0aGUgbmV3IG93bmVy IDkwJSBvZiB0aGUgZnVuY3Rpb25hbGl0eSBldmVuIGluIHRoZSBmYWNlIG9mIGFuIGFudGFnb25p c3RpYyBNQVNBOiBUaGUgb3duZXIgY2FuIG9idGFpbiBhIG5vbmNlLWxlc3Mgdm91Y2hlciBhZ2Fp bnN0IGEgZGV2aWNlIHNwZWNpZmljIHJlZ2lzdHJhciBrZXlwYWlyLiBUaGlzIHRoZW4gcHJvdmlk ZXMNCiB0aGVtIGEgcGVybWFuZW50IG1ldGhvZCBvZiBib290c3RyYXBwaW5nIHRoZSBkZXZpY2Ug dGhhdCB0aGV5IGNhbiBzYWZlbHkgcHJvdmlkZSB3aXRoIHRoZSBkZXZpY2UgZHVyaW5nIHJlc2Fs ZS4gVGhpcyBtYWludGFpbnMgdGhlIG1ham9yaXR5IHZhbHVlIG9mIHRoZSBwcm90b2NvbCB0byB0 aGUgbmV3IG93bmVyIHdoaWxlIGNvbXBsZXRlbHkgY2lyY3VtdmVudGluZyBhbnkgZnV0dXJlIGFu dGFnb25pc20gYnkgdGhlIHZlbmRvci4gVGhlIGRldmljZQ0KIGNhbiBiZSByZXNldCB0byBmYWN0 b3J5IGRlZmF1bHRzIGJlZm9yZSB0aGUgc2FsZS4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGIgY2xhc3M9IiI+ UmU6IFdoYXQgaGFwcGVucyBpZiB0aGUgTUFTQSBzZXJ2aWNlIGlzIHVuYXZhaWxhYmxlPyZuYnNw OzwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkJSU0tJIGlzIGZvciB0aGUgdHJhbnNmZXIgb2YgdHJ1c3QgdG8gdGhlIGN1cnJlbnQg b3duZXIuIFRoZXJlIGlzIG5vIGVmZmVjdCB0byBkZXBsb3llZCBkZXZpY2VzLiZuYnNwOzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5BcyBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQgdGhlcmUgYXJlIGZh Y2lsaXRpZXMgZm9yIG5vbmNlLWxlc3MgcGVybWFuZW50IHZvdWNoZXJzIGluY2x1ZGluZyBvbmVz IHRoYXQgY2FuIGJlIHVzZWQgZm9yIHJlc2FsZS4gQW4gb3duZXIgdGhhdCBpcyB3b3JyaWVkIGFi b3V0IHJlLWRlcGxveWluZyBpbiB0aGUgZnV0dXJlIHN0YXRlIGNhbiB0YWtlIHRoaXMgYXBwcm9h Y2guIEVpdGhlciB1c2luZyBhIGNvbW1vbiByZWdpc3RyYXINCiBvciBieSB1c2luZyBhIHJlZ2lz dHJhciBwZXIgZGV2aWNlIChkZXBlbmRpbmcgb24gaWYgdGhleSBwbGFuIHRvIHJlc2FsZSkuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5U aGVyZSB3aWxsIGFsd2F5cyBiZSBjYXNlcyB3aGVyZSBhIHZlbmRvciBnb2VzIGF3YXkgYW5kIGEg ZGV2aWNlIGlzIHRoZXJlZm9yZSBsaW1pdGVkLiBGb3IgZXhhbXBsZSBzZWN1cml0eSB1cGRhdGVz IHRvIHNpZ25lZCBmaXJtd2FyZSBjYW4gYmUgaW1wYWN0ZWQgaWYgdGhlIHZlbmRvciBubyBsb25n ZXIgcHJvZHVjZXMgdGhlbS4gQlJTS0kgZG9lcyBtYWtlIHRoaXMgcmVhbGl0eSB3b3JzZS4mbmJz cDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPi0gbWF4PC9kaXY+DQo8ZGl2IHN0eWxlPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBPY3QgMiwgMjAxOCwgYXQg NzowNiBQTSwgVXJpIEJsdW1lbnRoYWwgJmx0OzxhIGhyZWY9Im1haWx0bzp1cmlAbWl0LmVkdSIg Y2xhc3M9IiI+dXJpQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5C YXNlZCBvbiB0aGlzIGV4Y2hhbmdlLCBhbmQgdGhlIGFyZ3VtZW50cyBwcmVzZW50ZWQgaGVyZSB0 aGF0IEkgb2JzZXJ2ZWQgc28gZmFyLCBJJ20gd2l0aCBSYW5keS4gSSBoYXZlIG5vdCBzZWVuIGFk ZXF1YXRlIGFuc3dlcnMgdG8gaGlzIGNvbmNlcm5zICh3aGljaCBJTUhPIGFyZSByZWFzb25hYmxl KS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQLlMuIEZlZWwgZnJlZSB0byB0cmltIHRo ZSBDQzogbGlzdCB3aGVuL2lmIHJlc3BvbmRpbmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KUC5QLlMuIEluIG9uZSBvZiBteSBwcmlvciBpbmNhcm5hdGlvbnMgbWFueSB5ZWFycyBhZ28s IHdlIGRlc2lnbmVkIGEgc29tZXdoYXQgc2ltaWxhciBzeXN0ZW0sIGFuZCBjYWxsZWQgaXQgJnF1 b3Q7WmVyby1Ub3VjaCBQcm92aXNpb25pbmcmcXVvdDsuIEl0IHdhcyBhIHZlcnkgYmlnIGNvbXBh bnksIHNvIHdlIGRpZCBub3QgY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIGl0L3VzIGdvaW5n IG91dCBvZiBidXNpbmVzcyAoYW5kIGxlYXZpbmcgdGhlIGN1c3RvbWVycw0KIHN0cmFuZGVkKS4g QnV0IGlmIFJhbmR5J3MgYXJndW1lbnRzIHdlcmUgcHJlc2VudGVkIHRvIG91ciB0ZWFtIHRoZW4s IHdlJ2QgcHJvYmFibHkgYWNjZXB0ZWQgdGhlbSBhbmQgdHJpZWQgdG8gYWRkcmVzcy4uLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNlbnQgZnJvbSBteSB0ZXN0IGlQaG9uZTxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIE9jdCAyLCAyMDE4LCBhdCAyMDo1MywgUmFuZHkgQnVz aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhbmR5QHBzZy5jb20iIGNsYXNzPSIiPnJhbmR5QHBzZy5j b208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PkkgdGhpbmsgaXQncyBiZWVuIHRob3VnaHQgdGhyb3VnaCBidXQgYmFkbHkgYXJ0aWN1bGF0ZWQu IEluIHRoYXQgc2Vuc2UsPGJyIGNsYXNzPSIiPg0KdGhlIExhc3QgQ2FsbCBpcyBkb2luZyBpdHMg am9iLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCmRvZXMgdGhh dCBtZWFuIHRoYXQgaSBjYW4gc3RvcCB0cnlpbmcgZm9yIGEgbmFydGVuIG1lZGFsLCBnbyBiYWNr IHRvPGJyIGNsYXNzPSIiPg0Kd29yaywgYW5kIGNocmlzdGlhbiB3aWxsIHdha2UgbWUgdXAgYWdh aW4gd2hlbiBteSB0d28gc2NlbmFyaW9zIGhhdmU8YnIgY2xhc3M9IiI+DQpjbGVhciBhbnN3ZXJz OyBvbmUgaG9wZXMgb25lcyB3aXRoIHdoaWNoIGkgY2FuIGxpdmU/PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KYWxzbywgcGxlYXNlIHRlbGwgbWUgdGhhdCBpIGRvIG5vdCBuZWVkIHRvIHN0 aWNrIG15IG5vc2UgaW50byB0aGUgcmVzdDxiciBjbGFzcz0iIj4NCm9mIGFuaW1hIGluIG9yZGVy IHRvIGxldCB0aGUgdXNlciB1bmVxdWl2b2NhbGx5IG93biB3aGF0IHRoZXkgYnV5LiAmbmJzcDtp PGJyIGNsYXNzPSIiPg0KaGF2ZSBteSBvd24gcmFiYml0IGhvbGVzIHRvIHB1cnN1ZSBpbiB0aGUg aWV0Zi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpyYW5keTxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyIGNsYXNzPSIiPg0Kc2VjZGlyIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5vcmciIGNsYXNzPSIiPnNlY2RpckBpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rp cjxiciBjbGFzcz0iIj4NCndpa2k6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFj L3dpa2kvU2VjRGlyUmV2aWV3PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpBbmlt YSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5v cmciIGNsYXNzPSIiPkFuaW1hQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7A4C6D47A34343198EDD8403530B3BD3ciscocom_-- From nobody Sat Oct 6 02:46:52 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2FB130DDA for ; Sat, 6 Oct 2018 02:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 arhwbpLxCjjX for ; Sat, 6 Oct 2018 02:46:47 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CC5130DD5 for ; Sat, 6 Oct 2018 02:46:47 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id F0425837F243; Sat, 6 Oct 2018 09:46:45 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:1:2:41:72:152:355:379:582:599:800:962:967:973:983:988:989:1049:1152:1189:1208:1212:1221:1260:1263:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1730:1777:1792:2068:2069:2194:2198:2199:2200:2288:2525:2528:2553:2559:2568:2682:2685:2693:2741:2771:2859:2894:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4050:4250:4321:4361:4362:4605:4860:5007:6117:6119:6261:6298:6657:6659:6678:7464:7875:7903:8599:8603:8985:9010:9025:9108:9177:10004:10049:10848:11232:11258:11658:11914:11984:12043:12109:12114:12291:12295:12379:12438:12683:12740:12776:12895:13139:13161:13229:13255:13439:13846:14095:14096:14651:21060:21080:21324:21433:21451:21611:21625:21740:30003:30006:30025:30046:30054:30060:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.2 X-HE-Tag: coil75_1de7151e82509 X-Filterd-Recvd-Size: 13177 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf15.hostedemail.com (Postfix) with ESMTPA; Sat, 6 Oct 2018 09:46:45 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_04bc872992ba99abf1f7ededafec583b" Date: Sat, 06 Oct 2018 11:46:44 +0200 From: Peter van der Stok To: Brian E Carpenter Cc: consultancy@vanderstok.org, anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <153825200726.18811.5817453433918930845@ietfa.amsl.com> <659e84c2-551c-4b7c-1002-b156337a92ac@gmail.com> Message-ID: <17e6498e9610c1a8658c38d27e367233@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [90.0.44.113] Archived-At: Subject: Re: [Anima] I-D Action: draft-vanderstok-constrained-anima-dtls-join-proxy-00.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: Sat, 06 Oct 2018 09:46:51 -0000 --=_04bc872992ba99abf1f7ededafec583b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Brian, thanks, A new version is in preparation, I forgot that it was not yet published. The remark of Michael, that coap discovery is an extension to GRASP discovery is also valid. In the text, a mention about Grasp discovery will be inserted, and a reference to constrained coap networks to motivate the coap discovery. And indeed copying IP addresses is not my best side. Greetings, Peter Brian E Carpenter schreef op 2018-10-05 21:41: > Peter, > On 2018-10-05 20:24, Peter van der Stok wrote: > >> Hi Brian. >> >> The answer consists of a selection of text of section 7 of the draft. > > Huh? Section 7 is "security considerations" and the text you quote below > is nowhere in the draft. Maybe it's time for version -01 already? > > Also, ff01::fd confuses me. It is not a link-local address - it is node-local. > I think you mean ff02::fd, which is link-local and belongs to COAP. > > Regards > Brian > > The discovery follows the standard coap discovery. > ________________________________________________________________ > The discovery of the Join-Proxy by the > Pledge is an extension to the discovery described in section 4 of > [I-D.ietf-anima-bootstrapping-keyinfra]. In particular this section > replaces section 4.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. > > The Pledge can discover a Join-Proxy by sending a link-local > multicast message to ALL CoAP Nodes with address FF01::FD. Multiple > or no nodes may respond. The handling of multiple responses and the > absence of responses follow section 4 of > [I-D.ietf-anima-bootstrapping-keyinfra]. > > The presence and location of (path to) the join-proxy resource are > discovered by sending a MC GET request to "/.well-known/core" > including > a resource type (RT) parameter with the value "brski-proxy" > [RFC6690]. Upon success, the return payload will contain the root > resource of the Join-Proxy resources. > > ____________________________________________________________ Looking > forward to your comments and suggestions, > > Peter > Brian E Carpenter schreef op 2018-10-05 04:03: > > How does the constrained pledge discover the LL address of the constrained proxy? > > Regards > Brian Carpenter > > On 2018-09-30 09:13, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Constrained Join Proxy for Bootstrapping Protocols > Authors : Michael Richardson > Peter van der Stok > Panos Kampanakis > Filename : draft-vanderstok-constrained-anima-dtls-join-proxy-00.txt > Pages : 10 > Date : 2018-09-29 > > Abstract: > This document defines a protocol to securely assign a pledge to an > owner, using an intermediary node between pledge and owner. This > intermediary node is known as a "constrained-join-proxy". > > This document extends the work of > [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- > proxy by a stateless constrained join-proxy, that uses IP > encapsulation. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-vanderstok-constrained-anima-dtls-join-proxy/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00 > https://datatracker.ietf.org/doc/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00 > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima --=_04bc872992ba99abf1f7ededafec583b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Brian,

thanks,
A new version is in preparation, I forgot th= at it was not yet published.
The remark of Michael, that coap discover= y is an extension to GRASP discovery is also valid.
In the text, a men= tion about Grasp discovery will be inserted, and a reference to constrained= coap networks to motivate the coap discovery.
And indeed copying IP a= ddresses is not my best side.

Greetings,

Peter

Brian E Carpenter schreef op 2018-10-05 21:41:

= Peter,
On 2018-10-05 20:24, Peter van der Stok wrote:
Hi Brian.

The answer consists of a selecti= on of text of section 7 of the draft.

Huh? Section 7 is "security considerations" and the text you quote b= elow
is nowhere in the draft. Maybe it's time for version -01 already= ?

Also, ff01::fd confuses me. It is not a link-local address - = it is node-local.
I think you mean ff02::fd, which is link-local and = belongs to COAP.

Regards
    Brian
The discovery follows the standard coap discovery.
________________________________________________________________
T= he discovery of the Join-Proxy by the
   Pledge is an = extension to the discovery described in section 4 of
  &nbs= p;[I-D.ietf-anima-bootstrapping-keyinfra].  In particular this section=
   replaces section 4.2 of [I-D.ietf-anima-bootstrapp= ing-keyinfra].

   The Pledge can discover a Join= -Proxy by sending a link-local
   multicast message to= ALL CoAP Nodes with address FF01::FD.  Multiple
  &nb= sp;or no nodes may respond.  The handling of multiple responses and th= e
   absence of responses follow section 4 of
&n= bsp;  [I-D.ietf-anima-bootstrapping-keyinfra].

The pr= esence and location of (path to) the join-proxy resource are
 &n= bsp; discovered by sending a MC GET request to "/.well-known/core"
including
   a resource type (RT) parameter with th= e value "brski-proxy"
   [RFC6690].  Upon success= , the return payload will contain the root
   resource= of the Join-Proxy resources.

_________________________________= ___________________________ Looking
forward to your comments and sugg= estions,

Peter
Brian E Carpenter schreef op 2018-10-05 04= :03:

How does the constrained pledge discover the LL addres= s of the constrained proxy?

Regards
Brian Carpenter
=
On 2018-09-30 09:13, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Int= ernet-Drafts directories.

Title      &= nbsp;    : Constrained Join Proxy for Bootstrapping Pro= tocols
Authors         : Mich= ael Richardson
Peter van der Stok
Panos Kampanakis
Filena= me        : draft-vanderstok-constrained= -anima-dtls-join-proxy-00.txt
Pages      &nb= sp;    : 10
Date      &n= bsp;     : 2018-09-29

Abstract:
= This document defines a protocol to securely assign a pledge to an
ow= ner, using an intermediary node between pledge and owner.  This
= intermediary node is known as a "constrained-join-proxy".

This = document extends the work of
[I-D.ietf-anima-bootstrapping-keyinfra] = by replacing the Circuit-
proxy by a stateless constrained join-proxy= , that uses IP
encapsulation.

The IETF datatracker status= page for this draft is:
https://datatracker.ietf.org/doc/draft-vanderstok-constrain= ed-anima-dtls-join-proxy/

There are also htmlized versions = available at:
= https://tools.ietf.org/html/draft-vanderstok-constrained-anima-dtls-join-pr= oxy-00
https://datatracker.ietf.org/doc/html/draft-vanderstok-constrained-a= nima-dtls-join-proxy-00

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

Internet-Drafts are a= lso available by anonymous FTP at:
ftp://ftp.ietf.org/intern= et-drafts/

_______________________________________________<= br /> I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-= Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Anima mailing = list
Anima@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/ani= ma

_______________________________________________
Anima mailing = list
Anima@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/ani= ma
--=_04bc872992ba99abf1f7ededafec583b-- From nobody Wed Oct 10 04:23:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7AD130ED6; Wed, 10 Oct 2018 04:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9zJyr3Pr3vX3; Wed, 10 Oct 2018 04:23:41 -0700 (PDT) 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 5A921130ED3; Wed, 10 Oct 2018 04:23:41 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id ABD8E2F778A55; Wed, 10 Oct 2018 12:23:37 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 10 Oct 2018 12:23:38 +0100 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.0399.000; Wed, 10 Oct 2018 19:23:32 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 103, Bangkok Thread-Index: AdRgitwxlpC0WU+JRRyNZnZcYxme8w== Date: Wed, 10 Oct 2018 11:23:31 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B929020B40D@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_5D36713D8A4E7348A7E10DF7437A4B929020B40DNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Call for agenda ANIMA @ IETF 103, Bangkok 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, 10 Oct 2018 11:23:43 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B929020B40DNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all anima, We have been allocated a session of 2-hour for the ANIMA WG meeting for IET= F-103 (Bangkok) - Monday afternoon session I. We are now starting to collec= t agenda items for the session. Please send your request for agenda by Octo= ber 25th, Thursday. For this coming meeting, we would like to discuss potential future ANIMA wo= rks. As normal, the priority among these non-charter work items would be: t= hese that have active discussion in mail list, then these have submitted dr= afts, and topics without drafts. Please send us (anima-chairs at ietf.org) requests for time slot by October= 25th, Thursday and include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 103, Bangkok can be found at: https://www.ietf.org/how/meetings/103/ Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Toerless & Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B929020B40DNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, all anima,<=
o:p>
 
We have been al=
located a session of 2-hour for the ANIMA WG meeting for IETF-103 (Bangkok)=
 – Monday afternoon session I. We are now starting to collect agenda =
items for the session. Please send your request for agenda by October 25th,=
 Thursday.
 
For this coming=
 meeting, we would like to discuss potential future ANIMA works. As normal,=
 the priority among these non-charter work items would be: these that have =
active discussion in mail list, then these have submitted drafts, and topic=
s without drafts.
 
Please send us =
(anima-chairs at ietf.org) requests for time slot by October 25th, Thursday=
 and include:
 
Name of time sl=
ot:
Name of draft(s=
):
Time requested:=

Presenter name(=
s):
 
More details ab=
out the IETF 103, Bangkok can be found at:
 
https://www.ietf.org/how/meetings/103/<=
/a>
 
Again, presente=
rs and draft authors please invoke active discussions in the ANIMA list. Ma=
il list is a very good place to discuss and reach consensus on technical is=
sues.
 
Best regards,
 
Toerless & =
Sheng
--_000_5D36713D8A4E7348A7E10DF7437A4B929020B40DNKGEML515MBXchi_-- From nobody Thu Oct 11 19:17:40 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCD4130DF0; Thu, 11 Oct 2018 19:17:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153931065834.7195.2686513424411133580@ietfa.amsl.com> Date: Thu, 11 Oct 2018 19:17:38 -0700 Archived-At: Subject: [Anima] Genart telechat review of draft-ietf-anima-reference-model-08 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: Fri, 12 Oct 2018 02:17:39 -0000 Reviewer: Joel Halpern Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-anima-reference-model-08 Reviewer: Joel Halpern Review Date: 2018-10-11 IETF LC End Date: 2018-08-21 IESG Telechat date: 2018-10-25 Summary: This document is ready for publication as a Informational RFC. I appreciate the author's work in addressing my concerns. Major issues: N/A Minor issues: N/A Nits/editorial comments: The reference [IDevID] still appears to me to be a normative reference. In 3.3.3, the new parenthetical e.g. (replacing the wording "For example", seems to have no closing parenthesis. From nobody Thu Oct 11 22:22:39 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0473130DF0; Thu, 11 Oct 2018 22:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7Do6ixWqz1I; Thu, 11 Oct 2018 22:22:30 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 D5B3B130DE0; Thu, 11 Oct 2018 22:22:30 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id k19-v6so5586347pfi.1; Thu, 11 Oct 2018 22:22:30 -0700 (PDT) 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=CXNvCvqJ/7KuYfBDa8s0SMvyJTVJn/y4Yq/4dGxVAtE=; b=i+ZmF0lynL1y2CE+JFLsdu0Ikl5R1TLmkrw5oxuxvrkHZvKboGRDRC9mI0dRBVr3Lc OwxahQ9Hx7CKLz+GK7Wo/H1T95nATVJJSwm9uWq+Ip3lrHEOUiEaQzsw034cF0nqpbq9 onoiE7OR9DoeyHxs1MopvUULVkjZL/vrACy65rCj3kmMjPkkAYu+qgK6tQcE5CwTlKdy wZ54xzZh2enxnPL6AiIMbTSTjRbXpgFZjkdg46HnPB3vicgmxa1Lp7bmA1b733I7TJPd hvJPcuVmSt3BJdmEgj3WxYxbiVg9xF5tKB33VkWwVdjTNtWNYxI2+gyOKFANtaAx8A5O HJ0g== 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=CXNvCvqJ/7KuYfBDa8s0SMvyJTVJn/y4Yq/4dGxVAtE=; b=eJAQxd4fQusBnSLSjIPnsWfmXdWI+AI4EX2Y56PCX8SD2ECHMameBMp8u7kKXqyeco dcIcyv1AzMxAOd0ObnYMbhgWVUvxi/maHNrCmkWiKu40imInYAvN01ouCZnRmhxwvThl VVdPJJ0R7BIM1UCQpUmcK9jlLFlibJ3l2nYyqcIu8CiHQdSkVno/0FnuF+VG63ExXtAz WOT2Ipb+XOS8nByEuO06/tA0XjfA8JWw+HLAYjN3CECaSsO/golkOYugWk9zewNmKu6j VIevF1MluEMJMXMknKC6SAmPCSx6SfSbPOi0eGsDrWaAgB6lscMWVAtMrAXCV/Q6PYFc wRag== X-Gm-Message-State: ABuFfohI41dFEX7QQzDMnMVXGD+kxAQ6cKzJ96vWNpfTlqZHTpbPpq3O yFsmbeBjmaT6lfFDeox2Ft5yZyso X-Google-Smtp-Source: ACcGV60YDPryQ5EfoPf4haLxG+hwQeeWXa5K5O5ogh3SoD8nyWIwIic+g6cle81mq50mZEZr29D72g== X-Received: by 2002:a65:4783:: with SMTP id e3-v6mr4110983pgs.12.1539321750101; Thu, 11 Oct 2018 22:22:30 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id u21-v6sm171656pfa.176.2018.10.11.22.22.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 22:22:29 -0700 (PDT) To: Joel Halpern , gen-art@ietf.org Cc: ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org References: <153931065834.7195.2686513424411133580@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Fri, 12 Oct 2018 18:22:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153931065834.7195.2686513424411133580@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Genart telechat review of draft-ietf-anima-reference-model-08 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, 12 Oct 2018 05:22:33 -0000 Joel, On 2018-10-12 15:17, Joel Halpern wrote: ... > Nits/editorial comments: > The reference [IDevID] still appears to me to be a normative reference. It is normative in draft-ietf-anima-bootstrapping-keyinfra, where it really matters. Seems like a marginal point in an Informational document, but of course we'll follow the IESG's guidance. > In 3.3.3, the new parenthetical e.g. (replacing the wording "For example", > seems to have no closing parenthesis. Ack. Thanks Brian From nobody Sun Oct 14 06:36:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5835C1293FB; Sun, 14 Oct 2018 06:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pK6yjU_JDrQA; Sun, 14 Oct 2018 06:36:32 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB9112F1A6; Sun, 14 Oct 2018 06:36:32 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [82.117.217.154]) by relay.sandelman.ca (Postfix) with ESMTPS id C784F1F906; Sun, 14 Oct 2018 13:36:30 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 4C958E38; Sun, 14 Oct 2018 09:36:22 -0400 (EDT) From: Michael Richardson To: ace@ietf.org, 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, 14 Oct 2018 15:36:22 +0200 Message-ID: <8106.1539524182@dooku.sandelman.ca> Archived-At: Subject: [Anima] FYI: EST COAP, and enrollment interop list 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, 14 Oct 2018 13:36:35 -0000 --=-=-= Content-Type: text/plain The group of people who want to do EST, EST-COAP, and ANIMA-BRSKI enrollment testing has become too unweidly for a CC list to be useful. The conclusion was that we probably do not need an @ietf.org archived list, etc. I created a list at: https://lists.sandelman.ca/mailman/listinfo/est-and-bootstrap-plugtesting We have planned a series of online/virtual testing sessions on EST-COAP, generally Tuesday at 1500UTC for an hour (Oct. 15 and Oct. 23). We expect to do work at/during the IETF103 Hackathon, and we would welcome remote hackathon participants as well: but obviously you'll need a public IPv4 and/or IPv6 so that we can get traffic to you. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlvDRlUACgkQlUzhVv38 QpDcPQf+P2nqs4AhCr5jRpvv3jux31009UMWGDXCj+dWYcCNCuuUEvzXEyhtQcBw CMn1KGafARh6k07ViKboTgJ7zJic85fPCYKvXxvyjCosI4LV+tBgAKn1IW+hmmQF QxCCWIcaUn7m1G8cc16yFSryQ/Iplk/lY/zDGP+/RMCzPsy1QpxLePtUJxHDCo8W q4B2vTQqgHexDx8Dmj/Fd1wIYo0asa90wvsI3hS3dzEOHg9mY6OYALT6dYsQO+ny 8SXzdtWbc+dpJlE3MQPofl+SUuyLlIFFyDoHlRkcQS6RG3JL45BaSkC/SHIawutr kZFeiyPEfA0e8rkrU0beI2SJufu2kw== =VJ0b -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 14 17:41:01 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017B01286E3 for ; Sun, 14 Oct 2018 17:41:00 -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_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 ho78gVSofGAl for ; Sun, 14 Oct 2018 17:40:57 -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 C0142128B14 for ; Sun, 14 Oct 2018 17:40:57 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id y18-v6so8325966pge.0 for ; Sun, 14 Oct 2018 17:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=V+8Ug6PLn5gfrflwE7KTRXPOQtRQsviYNAIOYMBCqcA=; b=oweBT0NgoPzdDcXxFQ+/ZppTuidWjuN93TnWOKWCelSkXQvPs3mEeAhwHNNywnA2/o o8NeG3VVvHLPPVGrgafVqM+6V7Yyn4ROPY0hrTap2wh/6BT/o29aWw9uDMBAPE/iAP4N 15AXkSu5KjiOnfjZzEq573H/N++7RrVi6gKFeHLjI3CltQAHq3NpI5PPxPnJuSGSQUaI JFGxp+Gq53BQTD+TQDdJwjITOAAx3DA4fQtTpraUDtqu5AN7NYCCX/Kb+zb8uHF3hjRb QZ9Nun96d/IIj/gCNvWi4i/78xdXS5uGtFz+WMj3WrxqXX4xXn/i6PTEvQt7uzL1yKcF InmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V+8Ug6PLn5gfrflwE7KTRXPOQtRQsviYNAIOYMBCqcA=; b=ZTGEge/mhuuYhTYmz0j6iU9rj0C/PHlmhB7nUJpfLwiypAKW38gvzYAktJsRzZb7Io SeQdev2QUQBouXFl8HidoUtc64yjcl3G5Kai8LsA5S31iIaKRahGxlu7jCj2fyl3muP7 XKps1AT0chceiEFoBApmW50tvaVwqEOUIZCGLEvqXezcv7hozTzTxCOKRSMBozNTGkvS Aq9RAkhQtCo7WJhfk/9fqSYAC5sFvfQrUaYgh4HpsOQnoWhF06KvyHKmD7t8Oiw8mE/X UGVs1Cg0gi5MgAFoXWOejxEWgXXW1s3j32tFNV2ir+kVbBJ818igOeJRXzOiI6QJvqdS g+FA== X-Gm-Message-State: ABuFfoi2g553wDSN7Hy5H6ZQPV8K7bBtQwGls1vi42tTM6XZUsXFui2E 94GWOEoZuD6TzQL3w1xZfGs/P62E X-Google-Smtp-Source: ACcGV61+AAMaE0dfvUTQaSCK+eHhTNtrhlDj7YlhgBWtUwzbpoN9Yrki9tLFez7oU/6p4SOcCdvD3A== X-Received: by 2002:a62:fd0b:: with SMTP id p11-v6mr15092088pfh.167.1539564057014; Sun, 14 Oct 2018 17:40:57 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id x23-v6sm10092968pfm.113.2018.10.14.17.40.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Oct 2018 17:40:56 -0700 (PDT) From: Brian E Carpenter To: Anima WG References: <153954555641.5558.6443982058036831464@ietfa.amsl.com> Message-ID: <0cc4af6e-ab66-d13d-4ba9-6e8190446910@gmail.com> Date: Mon, 15 Oct 2018 13:40:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153954555641.5558.6443982058036831464@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-04.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, 15 Oct 2018 00:41:00 -0000 Hi, We have significantly updated this draft, with some reorganization of existing material, and two new sections added: 6. The Scope of Protocols in Limited Domains 7. Functional Requirements of Limited Domains We suggest discussion on the int-area@ietf.org list. Brian + Bing -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-limited-domains-04.txt Date: Sun, 14 Oct 2018 12:32:36 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Limited Domains and Internet Protocols Authors : Brian Carpenter Bing Liu Filename : draft-carpenter-limited-domains-04.txt Pages : 22 Date : 2018-10-14 Abstract: There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains and emerging solutions, and develops a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the needs for a precise definition of limited domain membership and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-limited-domains-04 https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-04 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Oct 18 02:53:57 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393AA120072 for ; Thu, 18 Oct 2018 02:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 90BBzqivJLcr for ; Thu, 18 Oct 2018 02:53:52 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0224.hostedemail.com [216.40.44.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF90D130934 for ; Thu, 18 Oct 2018 02:53:51 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 89D3B837F24A for ; Thu, 18 Oct 2018 09:53:50 +0000 (UTC) X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :, RULES_HIT:41:72:152:355:379:582:602:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1433:1434:1436:1437:1516:1517:1518:1535:1544:1571:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2528:2553:2559:2568:2570:2629:2682:2685:2703:2741:2859:2892:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3622:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4118:4250:4321:4605:5007:6117:6119:6261:6298:7464:7875:7903:8603:9025:9163:10004:10234:11658:12740:13139:13161:13200:13229:14827, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:28, LUA_SUMMARY:none X-HE-Tag: laugh18_3e92e0609c92c X-Filterd-Recvd-Size: 7776 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf16.hostedemail.com (Postfix) with ESMTPA for ; Thu, 18 Oct 2018 09:53:49 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_e90a841381584cc8fa34151d35a1700a" Date: Thu, 18 Oct 2018 11:53:49 +0200 From: Peter van der Stok To: anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <7bc8101c0511dc987d85f9387da27670@bbhmail.nl> References: <153985613173.22117.9488162884694227885.idtracker@ietfa.amsl.com> <7bc8101c0511dc987d85f9387da27670@bbhmail.nl> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: [Anima] Fwd: New Version Notification for draft-vanderstok-anima-constrained-join-proxy-00.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: Thu, 18 Oct 2018 09:53:54 -0000 --=_e90a841381584cc8fa34151d35a1700a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi all, We have submitted a new draft about constrained join proxy that replaces the circuit proxy in BRSKI. The intention is to present the draft during ietf103. Greetings, peter -------- Oorspronkelijke bericht -------- ONDERWERP: New Version Notification for draft-vanderstok-anima-constrained-join-proxy-00.txt DATUM: 2018-10-18 11:48 AFZENDER: internet-drafts@ietf.org ONTVANGER: "Michael Richardson" , "Panos Kampanakis" , "Peter van der Stok" A new version of I-D, draft-vanderstok-anima-constrained-join-proxy-00.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-anima-constrained-join-proxy Revision: 00 Title: Constrained Join Proxy for Bootstrapping Protocols Document date: 2018-10-18 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-anima-constrained-join-proxy-00.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-anima-constrained-join-proxy/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-anima-constrained-join-proxy-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-vanderstok-anima-constrained-join-proxy Abstract: This document defines a protocol to securely assign a pledge to an owner, using an intermediary node between pledge and owner. This intermediary node is known as a "constrained-join-proxy". This document extends the work of [ietf-anima-bootstrapping-keyinfra] by replacing the Circuit-proxy by a stateless constrained join-proxy, that transports routing information. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=_e90a841381584cc8fa34151d35a1700a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Hi all= ,

We have submitted a new draft about constrained join proxy tha= t replaces the circuit proxy in BRSKI.
The intention is to present the= draft during ietf103.

Greetings,

peter

-------- Oorspronkelijke bericht --------

Onderwerp: New Version Notification for draft-vanderstok-anima-constrained-join-pr= oxy-00.txt
Datum: 2018-10-18 11:48
Afzender: internet-drafts@ietf.org
Ontvanger: "Michael Richardson" <mcr+ietf@sandelman.ca>, "Panos Kampanakis" = <pkampana@cisco.com>, "Peter van der Stok" <consultancy@vanderstok= =2Eorg>


A new version of I-D, draft-vanderstok-anima-constrained-join-proxy= -00.txt
has been successfully submitted by Peter van der Stok and pos= ted to the
IETF repository.

Name:     = ;   draft-vanderstok-anima-constrained-join-proxy
Revi= sion:    00
Title:       = ; Constrained Join Proxy for Bootstrapping Protocols
Document da= te:    2018-10-18
Group:      = ;  Individual Submission
Pages:     &nb= sp;  11
URL:        &nbs= p;   https://www.ietf.org/internet-drafts/draft-vanderstok-anima-constr= ained-join-proxy-00.txt
Status:      &nb= sp;  https:= //datatracker.ietf.org/doc/draft-vanderstok-anima-constrained-join-proxy/
Htmlized:       https://tools.ietf.org/html/draft-vanderstok= -anima-constrained-join-proxy-00
Htmlized:    &nbs= p;  htt= ps://datatracker.ietf.org/doc/html/draft-vanderstok-anima-constrained-join-= proxy


Abstract:
   This document= defines a protocol to securely assign a pledge to an
  &nb= sp;owner, using an intermediary node between pledge and owner.  This    intermediary node is known as a "constrained-join-pr= oxy".

   This document extends the work of [ietf= -anima-bootstrapping-keyinfra]
   by replacing the Cir= cuit-proxy by a stateless constrained join-proxy,
   t= hat transports routing information.

    &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  


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

The IETF Secretariat
<= br />
--=_e90a841381584cc8fa34151d35a1700a-- From nobody Thu Oct 18 05:34:09 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7281A130DCB for ; Thu, 18 Oct 2018 05:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQUotzzaVqgc for ; Thu, 18 Oct 2018 05:34:05 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80107.outbound.protection.outlook.com [40.107.8.107]) (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 2C16012D4ED for ; Thu, 18 Oct 2018 05:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q/9V6x3q4aDT84OvFnL8V/HNWIIvuNoonIADNCiVHMQ=; b=eD5xXQ9uX5kql30d8u+Kh4j8NTCbecZjpJxz/dTplT+O2UeIbl5VNz0rqWOULH2laygjRbtS+ZQM25dBKGYwr0INP5IPWWtoYZNK73gHdHPz21QUJqMPItXrXzjSlQnOfAqeaYzwu/oOdjl5VWYdIRJTBVq2NjRnxZpCQmZuVIw= Received: from VI1PR07MB4687.eurprd07.prod.outlook.com (20.177.57.95) by VI1PR07MB4896.eurprd07.prod.outlook.com (20.177.200.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.25; Thu, 18 Oct 2018 12:34:02 +0000 Received: from VI1PR07MB4687.eurprd07.prod.outlook.com ([fe80::94c:3540:695e:6b90]) by VI1PR07MB4687.eurprd07.prod.outlook.com ([fe80::94c:3540:695e:6b90%4]) with mapi id 15.20.1250.014; Thu, 18 Oct 2018 12:34:02 +0000 From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" To: "anima@ietf.org" Thread-Topic: Test... Please ignore Thread-Index: AdRm3rri+u4OWecvSZiZ7Zvh+73Ndg== Date: Thu, 18 Oct 2018 12:34:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=laurent.ciavaglia@nokia.com; x-originating-ip: [176.130.37.253] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB4896; 6:mTSCE2FtEt9blfhIMnjP5wD1qT96Omcc5D4GRbh3WyGYAr+6LCS+6v6llMbD6yBtoWrq82t2jK+8JI4OKDkJkGfqD5UyEQxGE+urkt/dEG0RAF0CJj74hS3pNYoQzDVho/ReBXiZHvrKzZJKGq/bz2rrPLYMEqvrsqDjHMmCWArcIKQ2C1qBpe2cqAK1gsN5anpziPs0WZfFF995St5JzTcJmCFbZVcwY5LSAkvFS4syS9rnKY5qQ4vWY0F7w1Cjim2nOHnZ3/47Rw74LnAa3vNOqwphT75m73bPAyQ6XNQDzs1U5jaEbDx7NaRu6FffmUkotaotSJq44MqNMJhB4lr0xbSRSPd+lfKOFe17zJM8sZJ/DO3WYSB1A1jG8NM7fCUYtuObAAvIPmlOQDZ5gAH5ZvP/aZbMaemPi35aDmw4q0lRdiPHzZplRpsfRk+MVTito1VTK5VOmbWVEhvYeQ==; 5:nklKd3aArLNHjI0N7IMszYzaSOC8EmvmpgTOfbuRdNMN5SreNIheKLiZIPL2HDu13UALgxI0eeipHfv/GWP3dplOorybuSnN1UlmfkaFUESSiZuInq9rpw5cU3iAeC89l53Sx5lKFfTrvCJtNsyZ1keybqmtB+ZuiV3+L0WCcZY=; 7:/2ttVklD1LmD44TFtx6imtuEAfm7JGE8q0QHLtyXr8qRW23oXyO4M26NF8Vn5WotineQWCQveczpjv7wP5NpZI9zFX5sRUXSCzkk9KNImYl0MfLI1feR5u53x78k2cKRhj73zRHAwVgKeYcSFkSbMKIBfZwu5SmalxnHbNL+Qdz0/yDmmPdGMpJrMl/V5JUG+uAN7sFJddEMh6q/OxG6qTWCcrVcT0ifB1CMBoaI3fsKLgFFbVdQgDnx31q4EuT8 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4ae5e10f-0166-411d-0191-08d634f5fc92 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:VI1PR07MB4896; x-ms-traffictypediagnostic: VI1PR07MB4896: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231355)(11241501184)(806099)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4896; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4896; x-forefront-prvs: 08296C9B35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(366004)(376002)(346002)(189003)(199004)(33656002)(68736007)(7696005)(5660300001)(2501003)(3846002)(558084003)(102836004)(4270600006)(790700001)(186003)(6116002)(97736004)(2906002)(6436002)(26005)(6506007)(2351001)(5640700003)(9686003)(6306002)(54896002)(6916009)(316002)(486006)(476003)(478600001)(66066001)(2900100001)(71190400001)(71200400001)(8676002)(105586002)(86362001)(7736002)(25786009)(8936002)(5250100002)(14454004)(106356001)(81166006)(99286004)(81156014)(53936002)(55016002)(74316002)(1730700003)(5630700001)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4896; H:VI1PR07MB4687.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bpfQZN18DGfigOn+0Wdsx1ZRSVt+/7FoO4Zk2QfhVHmcU6ek8VE0nLcmw+ug32Mt5FOSzV4qCTEhcGH2ZC4HoCtmeB05DxffSFc5pDEEe29rszjAxVqI6ra7Kha6KWqw3NKhLAlXeduiYIV3DO4RefsrE4ARC3PZKmDm4yt3mk4e4ulLmWSX0A9Kmdg6J/7zuKWs5PsVOWO70oMjvcjuFNBhboxfXtHxlJMDxzIh28bYwzjOZf4PAEwIBNEnW+XhtKYbJFWsTLhZZEucKZG4jF0gePRCI/jQhNf/LliZx2bXReywDLEYuq4/R/bi+3FVnWhD3Z5JAaqtT3HV4UamvrZr2JkMeGTLHa1pxZT66WGMnKdCJsj9NEUTyoj30lCW/ZJo5ton9je6hywcYPFwLA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB46878BE02AB56470DA31DDEAF3F80VI1PR07MB4687eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ae5e10f-0166-411d-0191-08d634f5fc92 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2018 12:34:02.7156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4896 Archived-At: Subject: [Anima] Test... Please ignore 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, 18 Oct 2018 12:34:07 -0000 --_000_VI1PR07MB46878BE02AB56470DA31DDEAF3F80VI1PR07MB4687eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just running some tests as I'm not receiving emails for IETF mailing lists. -Laurent. --_000_VI1PR07MB46878BE02AB56470DA31DDEAF3F80VI1PR07MB4687eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just running some tests as I’m not receiving emails = for IETF mailing lists.

 

-Laurent.

--_000_VI1PR07MB46878BE02AB56470DA31DDEAF3F80VI1PR07MB4687eurp_-- From nobody Fri Oct 19 12:04:17 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 455F7131145; Fri, 19 Oct 2018 11:56:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ibagdona@gmail.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997540227.6592.8868360997413051761.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:42 -0700 Archived-At: Subject: [Anima] anima - Requested session has been scheduled for IETF 103 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: Fri, 19 Oct 2018 18:56:50 -0000 Dear Sheng Jiang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. anima Session 1 (2:00 requested) Monday, 5 November 2018, Afternoon Session I 1350-1550 Room Name: Meeting 1 size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/anima.ics Request Information: --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man Second Priority: roll v6ops dhc homenet netconf detnet Third Priority: cfrg saag intarea opsarea dinrg panrg People who must be present: Toerless T. Eckert Sheng Jiang Terry Manderson Ignas Bagdonas Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Sat Oct 20 07:42:51 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71BE12F1A5; Sat, 20 Oct 2018 07:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvanginBRqsk; Sat, 20 Oct 2018 07:42:29 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4881200D7; Sat, 20 Oct 2018 07:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16136; q=dns/txt; s=iport; t=1540046548; x=1541256148; h=references:subject:to:cc:from:message-id:date: mime-version:in-reply-to; bh=+IhH208hXb19gtVshE88fSycbu42xXGwOHp5J0XN80g=; b=a5TQOp/i/ul4nHgBjuP3cx3jJWC3HZDwbe0IN6+LXtthR60RMClDONGw 87t4FhVAS3v3ZNNmBdRyeep0ZSMckmZKXlt/JSBBT5+Syc/PUccQPM1hO 9SuDmzI3sUT1vA9rJPJu05hDb64X3M7hrAO/RhQ/XYtPnF/X4eLfRg+ij 4=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.54,404,1534809600"; d="asc'?eml'208?scan'208,208,217";a="7392481" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2018 14:42:26 +0000 Received: from [10.61.201.80] ([10.61.201.80]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w9KEgPbt017261; Sat, 20 Oct 2018 14:42:25 GMT References: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> To: "opsawg@ietf.org" Cc: Michael Richardson , "Owen Friel (ofriel)" , Anima WG , Christian Huitema , Kent Watsen , emu@ietf.org From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== X-Forwarded-Message-Id: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> Message-ID: Date: Sat, 20 Oct 2018 16:42:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n5ODYPsUfcbDS7BGKzW0ipxdg72zW7aXN" X-Outbound-SMTP-Client: 10.61.201.80, [10.61.201.80] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Anima] Fwd: New Version Notification for draft-lear-brski-pop-00.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: Sat, 20 Oct 2018 14:42:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n5ODYPsUfcbDS7BGKzW0ipxdg72zW7aXN Content-Type: multipart/mixed; boundary="QWZ1bjlDIfz4Y2j90TYZiyYdP5kytCM4l"; protected-headers="v1" From: Eliot Lear To: "opsawg@ietf.org" Cc: Michael Richardson , "Owen Friel (ofriel)" , Anima WG , Christian Huitema , Kent Watsen , emu@ietf.org Message-ID: Subject: Fwd: New Version Notification for draft-lear-brski-pop-00.txt References: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> In-Reply-To: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> --QWZ1bjlDIfz4Y2j90TYZiyYdP5kytCM4l Content-Type: multipart/mixed; boundary="------------949FFF619DBD569EFBD81152" Content-Language: en-US This is a multi-part message in MIME format. --------------949FFF619DBD569EFBD81152 Content-Type: multipart/alternative; boundary="------------E4BD44975B6F3CA35D46834B" --------------E4BD44975B6F3CA35D46834B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As promised, here is a draft that attempts to wangle BRSKI to allow for proof of possession tests.=C2=A0 This is very early work and intended for= discussion at this point during OPSAWG and at the side meeting we have scheduled for Tuesday night.=C2=A0 If people like what they see, we can discuss in more detail in Prague. This draft includes three specific test types, one of which may come out Real Soon: 1. The registrar has obtained proof of possession and provides that proof to the MASA.=C2=A0 This solves a wireless case. 2. The registrar has obtained proof of possession and, rather than providing proof to the MASA, provides proof to the pledge (two-party instead of three). 3. The registrar tells the MASA, =E2=80=9CTrust Me!=C2=A0 Really!=E2=80=9D= in its best Joe Isuzu voice*.=C2=A0 (This may be redundant, which is why it may come = out.) Discussion points: * The basis of all of this work is really that Max, Michael, and Kent did a bang up job by coming up with the voucher concept, and so let's all agree PLEASE that no matter how we slice it, a voucher request needs to be generated, and a voucher response needs to be delivered.=C2=A0 The means for proof, and even the identity returned,= can be stretched. * Should we stretch further, and include different keying material objects?=C2=A0 I'm CCing EAP folk because that is a big fat question = for them. Eliot * See https://www.youtube.com/watch?v=3DmR361ASrMew --------------E4BD44975B6F3CA35D46834B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

As promised, here is a draft that attempts to wangle BRSKI to allow for proof of possession tests.=C2=A0 This is very early work = and intended for discussion at this point during OPSAWG and at the side meeting we have scheduled for Tuesday night.=C2=A0 If people l= ike what they see, we can discuss in more detail in Prague.

This draft includes three specific test types, one of which may come out Real Soon:

  1. The registrar has obtained proof of possession and provides that proof to the MASA.=C2=A0 This solves a wireless case.
  2. The registrar has obtained proof of possession and, rather than providing proof to the MASA, provides proof to the pledge (two-party instead of three).
  3. The registrar tells the MASA, =E2=80=9CTrust Me!=C2=A0 Really!=E2= =80=9D in its best Joe Isuzu voice*.=C2=A0 (This may be redundant, which is why it m= ay come out.)

Discussion points:

  • The basis of all of this work is really that Max, Michael, and Kent did a bang up job by coming up with the voucher concept, and so let's all agree PLEASE that no matter how we slice it, a voucher request needs to be generated, and a voucher response needs to be delivered.=C2=A0 The means for proof, and even the identity returned, can be stretched.
  • Should we stretch further, and include different keying material objects?=C2=A0 I'm CCing EAP folk because that is a big = fat question for them.

Eliot

* See https://www.youtube.com/watch?v=3DmR361ASrM= ew


--------------E4BD44975B6F3CA35D46834B-- --------------949FFF619DBD569EFBD81152 Content-Type: message/rfc822; name="New Version Notification for draft-lear-brski-pop-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-lear-brski-pop-00_txt.eml" X-Mozilla-Keys: Received: from xch-rtp-005.cisco.com (64.101.220.145) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Mailbox Transport; Sat, 20 Oct 2018 09:30:10 -0500 Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 20 Oct 2018 10:30:10 -0400 Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 20 Oct 2018 10:30:09 -0400 Received: from rcdn-iport-2.cisco.com (173.37.86.73) by mail.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 20 Oct 2018 10:30:09 -0400 Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2018 14:30:07 +0000 Received: from alln-inbound-a.cisco.com (alln-inbound-a.cisco.com [173.37.147.231]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9KEU2Oi016011 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Oct 2018 14:30:07 GMT Received-SPF: Pass (alln-inbound-a.cisco.com: domain of internet-drafts@ietf.org designates 2001:1900:3001:11::2c as permitted sender) identity=mailfrom; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-a.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="internet-drafts@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64 ip4:66.70.182.38 ip4:158.69.166.16/29 ip6:2607:5300:203:1b26::0/64 ip4:158.69.229.207 ip4:192.95.54.40/29 ip6:2607:5300:0060:9ccf::0/64 -all" Received-SPF: None (alln-inbound-a.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-a.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-a.cisco.com; dkim=none (message not signed) header.i=none; spf=Pass smtp.mailfrom=internet-drafts@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dmarc=pass (p=none dis=none) d=ietf.org X-from-outside-Cisco: 2001:1900:3001:11::2c IronPort-PHdr: =?us-ascii?q?9a23=3A3currhfTZbkiTntkB675MpEOlGMj4u6mDksu8p?= =?us-ascii?q?Mizoh2WeGdxcS4Yh7h7PlgxGXEQZ/co6odzbaO7Oa4ASQp2tWoiDg6aptCVh?= =?us-ascii?q?sI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFR?= =?us-ascii?q?rhKAF7Ovr6GpLIj8Swyuu+54Dfbx9HiTahY75+Ngm6oRnMvcQKnIVuLbo8xA?= =?us-ascii?q?HUqXVSYeRWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLn?= =?us-ascii?q?s65Nb3uhnZTAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD?= =?us-ascii?q?+v9LlgRgP2hygbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2?= =?us-ascii?q?VcRMZcTyNODZ+zYYUPEeQPIP5YopLhp1YMsReyGRWgCP/txzJOm3T43bc60+?= =?us-ascii?q?MkEQze3QwgGc4Ov2rOrNXzKqgSTfm5w7TSzTrZYfNWxSz95ZPJch8/vfGMU6?= =?us-ascii?q?h8cc3LyUkgEQ7Ok1ueqYvgPzyP1+QNtXCW7+t+WuKzhW4rsQZxoiKgxsoql4?= =?us-ascii?q?LHhZoVx0ja+Sll3Io5ONi1RFN/bNK4DJddsi+XO5dqTs8/RmxkpTs2x7gDtJ?= =?us-ascii?q?KlYCcHzoksyQTFZPydaYeI5wruVOaPLjd8g3JoYLe/iAyz8Uik0OH8V9e70E?= =?us-ascii?q?pEriZfldnMrH8N2wTS6siBVPR94l+s1SiT2wzP9+1JJF04mK7HJ5I9x7M9mI?= =?us-ascii?q?YfvVjeEiLzhUn6kaqbe0A69ue08+jnZ6/ppp6YN496kAH+NaEul9S+AeQ+Lg?= =?us-ascii?q?gBQXKb+eKi273/5EH2Xa9Kgec4kqnFq5DXPsUbqbClAw9byIoj7Ay/Dzi+3N?= =?us-ascii?q?QCgXYHNE5FeA6Aj4XxP1HBPur3De2kjluwkTdr3OzJPrr7DprRKXjDla/rfa?= =?us-ascii?q?xh5E5E1Aoz0ddf6opTCrEPOvLzW1H+tNjDAxAlMgy02ProCNJn2owCXmKPB/?= =?us-ascii?q?zRDKSH+3KM5+Uza82BbZVf8GL5JvE/z/XvlnQ+31QaeP/tldEwd32+Vtp8Ik?= =?us-ascii?q?idKzK4hdkbEGoOlgE/V+ftzlaFVGgASWy1Wvc94C02EoSrEcLPXImjnKep3S?= =?us-ascii?q?qnENtRfG8VWRi3DX70etDcCL83YyWIL5oky2RcCOqNbqYb/kj16l2ij5ZiJ/?= =?us-ascii?q?DfwCATsojvhpBtsuvUkxx2vSR/E5HEiznJB3psyydATjM13aUquwg1w0yb3/?= =?us-ascii?q?1ix7RCCNUG1LMGXgIzL5XrxuN1I877XgOHc9KASVLpBp3/WW1hE41vm55KKw?= =?us-ascii?q?YyF9CrlBuGxSeyBKUJv72GGJJy9bjTkDy5fp4hmyuZivFguh0gRc1Cbzf0r7?= =?us-ascii?q?Nj9wXVG4/CmlmYkKDvT6kHwSrR7z3bkDiHuEVeFQ92W6LYW3xabw3drM/y4Q?= =?us-ascii?q?XJSLr9QbgkMw4Uz8mEJ+MKb9DyllxJSb/lP8iWeGO+nWq8RF6Iy7qAYZCsej?= =?us-ascii?q?Ab2yPQWwAfiw5GxX+dLkAlAzu55WfXDThgD1XqNkLq7eRkrn6nC0Muxg+WdG?= =?us-ascii?q?Vg2qa7vBkPiq/UUOsdi5QDvippsDBoBBC90tbRXsKHvBZkdb5AbMkV5V5G0S?= =?us-ascii?q?TYuhBzeJu6IPMqilsXaQ8ip0r1zF03EtBGls4n5H8r1190LqSVkRtNIjKVwZ?= =?us-ascii?q?62PafYczOgxh2kZq/I112b6+64p/dXuswxsE6r/AitEkxn8nNt1MRT3z6VoJ?= =?us-ascii?q?7LFwEVF5n2VxR/+x9/rrDcKi4zguGcnXxqLaSutDLent4zDeU50T6hcstRdq?= =?us-ascii?q?SeG0f+HtYbCM6nNOEx0wLxNktWZbEKrPxvZ5v/JaLfivzxN65ph1fExSxf7Z?= =?us-ascii?q?p4016Q+iY0UePO05sfgrmZ0gaBSzbgnQKku8Hzl5pDYGJ3fCL3wizlCYhNI6?= =?us-ascii?q?xqKNxTUT78epzvnocl38a0CScBpgz5DABjuofhYxeZYl3j0BcF3EATpzmmny?= =?us-ascii?q?G/0jp41jhvpauE1yuIyOPnJ39lciZGQndviVD0LM26ldcfCQKpaRQkjh2o+Q?= =?us-ascii?q?P23aFVuL9XLmTPTwFPZSe8fAQAGuOg86GPZcJC8sZisCNLXf66bEzfRqT0rQ?= =?us-ascii?q?cB+yLuA2UYwyo0PWLiqtDymBp0j3iYJXB4oS/CYc9HwhHb9Y+5J7YZzn8cSS?= =?us-ascii?q?J/kzWSGkmkMozj44CPj5ma+LP2Rye7W5ZUayWu0Y6QqH7x+zhxGRPm+pL70t?= =?us-ascii?q?z/TVpml3SikYA7BWOT9lGmPcHqz/roa7o/JxsxVQekuZEiQtgsytNp3cNCgT?= =?us-ascii?q?9E2vD3tTIGiTuhb4sdhvq4NSpXA2Vbi9/NvFq8hR0lcCPPntynECzDhZEwAr?= =?us-ascii?q?vyKmIOhHBnsZgVWvrPtOQWx3Mu8AOy91yDM6A6wGtVyONyuidH06dX6Ux3lH?= =?us-ascii?q?TbWOhNeCsQdS30y0bRvor4/fgROTrpLeD3jhs2nMj/Xuvc+l4OBS2hIsV6RX?= =?us-ascii?q?EovJR0O1yegiW0tN2sPdDUaZhK7E+unhzNjvZYJNcKrtRR33I1H2X7sDVlwu?= =?us-ascii?q?o/i1lv25u9oY6Lbmwr96OiCRkePTrwNYsV/Xn2gKBSk9zzvcjnF4h9GjgNQJ?= =?us-ascii?q?rjTO65WDMUu/P9Mg+SETo64n6FELvbFAWb5Q9otXXKW5ysMniWIjEew7AADF?= =?us-ascii?q?GFI1dDhQkPQDggtpswFwTsxcH9fgF+/D9Qrl/0px1Qy/55YhnyVmCMwWXgIj?= =?us-ascii?q?wwSZWZMF9X9lQYvx+MY5XPtrohRHkAp8/49V7fcGfIAmYARXsEUUGFGV35a7?= =?us-ascii?q?Cq4d+F8u6SAfe4I77HJ76PsudZEfyPwMHKsMMu8jCSO8GIJnQnAec83x8JXH?= =?us-ascii?q?ZlFt7flilKRzYemT7WR8+WuBn6/Td45JPakryjSEf06I2DBqEHe81o4AyziL?= =?us-ascii?q?yfOvS4gS94LXBZ248Cg3jSx/JMlE5XgCZoeT63FL0GviOYV7rerahRCw9COn?= =?us-ascii?q?FDcfBQ5qd55TFjfMvSi9f7zLl916ZnClpZWxrmgM77PJVXcVH4D0vOAQOwDJ?= =?us-ascii?q?rDJTDPxJiqM6a1SLkWjehIuVu3oznJS0I=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A8FTAACUOstbfQAZASCDgISAEQAsZB4?= =?us-ascii?q?BBgcGgVEJCwGBMAFQaXAECyiDdYh3izyFTJNWgXoNExAJAoQ+hQsZBwE0DQ0?= =?us-ascii?q?BAwEBAQEBAQEBAQECEAEBCRYITAyCNiQBDy8cPgEBAQEBAScBAQEBAQEjAkQ?= =?us-ascii?q?2IFQRJgImAgIDRBYBF4MdgSBiBAqlYIEuhDACDECDc4ErgQuIA4JEgheBEYM?= =?us-ascii?q?SgxsBAQIBAYF6gmaCVwKJAoVIQjKPCgmGYooQF4FSTIQniWmMWIoFgUOCDn0?= =?us-ascii?q?igw0JixCFXk8BgQaKZAEB?= X-IPAS-Result: =?us-ascii?q?A8FTAACUOstbfQAZASCDgISAEQAsZB4BBgcGgVEJCwGBM?= =?us-ascii?q?AFQaXAECyiDdYh3izyFTJNWgXoNExAJAoQ+hQsZBwE0DQ0BAwEBAQEBAQEBA?= =?us-ascii?q?QECEAEBCRYITAyCNiQBDy8cPgEBAQEBAScBAQEBAQEjAkQ2IFQRJgImAgIDR?= =?us-ascii?q?BYBF4MdgSBiBAqlYIEuhDACDECDc4ErgQuIA4JEgheBEYMSgxsBAQIBAYF6g?= =?us-ascii?q?maCVwKJAoVIQjKPCgmGYooQF4FSTIQniWmMWIoFgUOCDn0igw0JixCFXk8Bg?= =?us-ascii?q?QaKZAEB?= X-IronPort-AV: E=Sophos;i="5.54,404,1534809600"; d="scan'208";a="117908310" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([IPv6:2001:1900:3001:11::2c]) by alln-inbound-a.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2018 14:30:02 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 904C712F1A5; Sat, 20 Oct 2018 07:30:01 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: To: Eliot Lear , Owen Friel Subject: New Version Notification for draft-lear-brski-pop-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> Date: Sat, 20 Oct 2018 07:30:01 -0700 X-Outbound-SMTP-Client: 173.37.147.231, alln-inbound-a.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Return-Path: internet-drafts@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-RTP-010.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: 845ea357-f2a2-4c9c-ccc0-08d6369889d6 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 A new version of I-D, draft-lear-brski-pop-00.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-lear-brski-pop Revision: 00 Title: Proof of Possession to Devices for Onboarding Document date: 2018-10-20 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-lear-brski-pop-00.txt Status: https://datatracker.ietf.org/doc/draft-lear-brski-pop/ Htmlized: https://tools.ietf.org/html/draft-lear-brski-pop-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-lear-brski-pop Abstract: This memo specifies a RESTful interface for local deployments to demonstrate proof of possession to a device or to a manufacturer authorized signing authority (MASA). This covers the case where a MASA would not otherwise have knowledge of where a device is deployed, or when a MASA may not be required. Such knowledge is important to onboard certain classes of devices, such as those on IEEE 802.11 networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------949FFF619DBD569EFBD81152-- --QWZ1bjlDIfz4Y2j90TYZiyYdP5kytCM4l-- --n5ODYPsUfcbDS7BGKzW0ipxdg72zW7aXN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlvLPtAACgkQh7ZrRtnS ejMD2QgAlqz2nPodc6IGVzLGmLBzH6hAUkb45JZb3DZpVDwUtb2YQVaIO5mxUOWk pW6uHT5q6RkxdF3GmAFxnj+txCNKhY6E5qpjBTE5wXtdQUY2/TSNuSHuPVcvd/qw ZcGnz9JrwN9klpG225TCyQjnDoJnT9ynR4pjXzM4q7KQ1U5RDwgekEBwsv8wkxo1 UgPWTlKQAkxoyZlnIrWEL7YEDTysB9dqKKlB67bNA3Was6A4iAuNYKFG48hg/4FS q2mtQhfxImudmPxszBVykDKzmme4uxvqO489zpRhh7WxQs0Het8pNQgK3COlOcBL 77JH31mHIV40eK2TRixUpWxEFyqZvA== =IyCJ -----END PGP SIGNATURE----- --n5ODYPsUfcbDS7BGKzW0ipxdg72zW7aXN-- From nobody Sun Oct 21 18:44:04 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6212F12D4F2 for ; Sun, 21 Oct 2018 18:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8_ZD0HY4F9v for ; Sun, 21 Oct 2018 18:44:00 -0700 (PDT) Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A11120072 for ; Sun, 21 Oct 2018 18:43:59 -0700 (PDT) Received: from unknown (HELO smtpeg.etri.re.kr) (129.254.27.142) by 129.254.9.16 with ESMTP; 22 Oct 2018 10:43:50 +0900 X-Original-SENDERIP: 129.254.27.142 X-Original-MAILFROM: choits@etri.re.kr X-Original-RCPTTO: anima@ietf.org Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 22 Oct 2018 10:43:56 +0900 Received: from SMTP1.etri.info ([169.254.1.106]) by SMTP2.etri.info ([10.2.6.31]) with mapi id 14.03.0319.002; Mon, 22 Oct 2018 10:43:51 +0900 From: =?utf-8?B?7LWc7YOc7IOB?= To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-choi-anima-trust-networking-01.txt Thread-Index: AQHUY7yZT3vsCcOHF0CxGVxja0jn5aUqiZPg Date: Mon, 22 Oct 2018 01:43:50 +0000 Message-ID: References: <153952147038.5407.12858119464419526983.idtracker@ietfa.amsl.com> In-Reply-To: <153952147038.5407.12858119464419526983.idtracker@ietfa.amsl.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.10.21] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] FW: New Version Notification for draft-choi-anima-trust-networking-01.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, 22 Oct 2018 01:44:02 -0000 QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNob2ktYW5pbWEtdHJ1c3QtbmV0d29ya2luZy0w MS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGFlIFNhbmcgQ2hvaSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1jaG9pLWFu aW1hLXRydXN0LW5ldHdvcmtpbmcNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlUcnVzdCBuZXR3b3Jr aW5nIGFuZCBwcm9jZWR1cmVzIGZvciBBdXRvbm9taWMgTmV0d29ya2luZw0KRG9jdW1lbnQgZGF0 ZToJMjAxOC0xMC0xNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMzIN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtY2hvaS1hbmltYS10cnVzdC1uZXR3b3JraW5nLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNob2ktYW5pbWEtdHJ1c3QtbmV0 d29ya2luZy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtY2hvaS1hbmltYS10cnVzdC1uZXR3b3JraW5nLTAxDQpIdG1saXplZDogICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1jaG9pLWFuaW1hLXRydXN0LW5l dHdvcmtpbmcNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtY2hvaS1hbmltYS10cnVzdC1uZXR3b3JraW5nLTAxDQoNCkFic3RyYWN0Og0KICAg ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRydXN0IG5ldHdvcmtpbmcgYXMgYW4gYXBwbGlj YXRpb24gb2YNCiAgICAgICBhdXRvbm9taWMgbmV0d29ya2luZy4gVGhlIG9iamVjdGl2ZSBvZiB0 cnVzdHdvcnRoeSBhdXRvbm9taWMNCiAgICAgICBuZXR3b3JraW5nIGlzIHByb3ZpZGluZyB0cnVz dCBuZXR3b3JraW5nIGVudmlyb25tZW50IHdoZXJlIGFsbA0KICAgICAgIGF1dG9ub21pYyBub2Rl cyBjYW4gY29tbXVuaWNhdGUgd2l0aG91dCBhbnkgc2VjdXJpdHkgY29uY2Vybi4gSXQNCiAgICAg ICBkZWZpbmVzIGEgdHJ1c3QgbmV0d29ya2luZyBkb21haW4gYW5kIGRlc2NyaWJlcyBob3cgdG8g Y29uZmlndXJlIGFuZA0KICAgICAgIG1haW50YWluIHRoZSB0cnVzdCBuZXR3b3JraW5nIGRvbWFp bi4gV2hpbGUgY29tbXVuaWNhdGlvbiB3aXRoaW4gdGhlDQogICAgICAgdHJ1c3QgbmV0d29ya2lu ZyBkb21haW4gaXMgZG9uZSB3aXRoIHRydXN0LCB0aGUgY29tbXVuaWNhdGlvbiB3aXRoDQogICAg ICAgZXh0ZXJuYWwgbm9kZXMgc2hvdWxkIGJlIGRvbmUgdmlhIGEgc3BlY2lmaWMgYXV0b25vbWlj IHNlcnZpY2UgYWdlbnQNCiAgICAgICAoQVNBKSBjYWxsZWQgInRydXN0IGdhdGV3YXkiLiBUaGUg dHJ1c3QgZ2F0ZXdheSBBU0EgcGVyZm9ybXMgdHJ1c3QNCiAgICAgICBldmFsdWF0aW9uIG9mIHRo ZSBleHRlcm5hbCBub2RlcyBhbmQgZW5mb3JjZXMgZG9tYWluIHNwZWNpZmljDQogICAgICAgcG9s aWNpZXMgdG8ga2VlcCB0aGUgZG9tYWluIHRydXN0d29ydGh5Lg0KDQoNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Oct 22 00:40:00 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099F9130DE1 for ; Mon, 22 Oct 2018 00:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDRAJuOmd_aq for ; Mon, 22 Oct 2018 00:39:58 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DD0130DC3 for ; Mon, 22 Oct 2018 00:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4276; q=dns/txt; s=iport; t=1540193997; x=1541403597; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=NQoKcNRfOxzY8TuaVzN2wWPpZB5aQ0QnmjSx0LXTzWk=; b=Yv0M9pqJZpWy7wT/cMDMdr2nm/hel0FRdllkdQnSH9AiDQYrLq85Pm7w dZsDW8OWimdfmEbEnetmesIEmnMr7ax7+A6J0k7PPjYLRGfUkgtFe6epb nSQ1q2cF4DcNnNXR7V20eDIy6dVzRb3H7DiSgp8FUV9kvoWUv7xXA2+kC 8=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAACfs1b/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgmptEiiDdYh3jRkIJYMxk3iBZggFGA2?= =?us-ascii?q?ERwKFMDcKDQEDAQECAQECbRwMhTsBAQEDAQEhSwkSCQIYKgICJzAGAQwGAgE?= =?us-ascii?q?Bgx0BggEPiCObTYEuhDACDECFBQ+CbYh8ggCBOAyCX4MbAQECAQEWgQuDP4J?= =?us-ascii?q?XAo5Kj34JhA+BbmWKCgYXgVJMhCeCboZ7jFiKBYFZIoFVMxoIGxUaIYJsCYJ?= =?us-ascii?q?GiEqFQD0wAYt/AQE?= X-IronPort-AV: E=Sophos; i="5.54,411,1534809600"; d="asc'?scan'208"; a="7371917" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 07:39:55 +0000 Received: from [10.61.109.57] (dhcp-10-61-109-57.cisco.com [10.61.109.57]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9M7dspk001051; Mon, 22 Oct 2018 07:39:55 GMT To: =?UTF-8?B?7LWc7YOc7IOB?= , "anima@ietf.org" References: <153952147038.5407.12858119464419526983.idtracker@ietfa.amsl.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <13c7f704-9283-a96f-902e-8f432af5089e@cisco.com> Date: Mon, 22 Oct 2018 09:39:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9MfJ2WVfKAyCVKBs7YZ0qmdcK7tYUPi3X" X-Outbound-SMTP-Client: 10.61.109.57, dhcp-10-61-109-57.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Anima] FW: New Version Notification for draft-choi-anima-trust-networking-01.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, 22 Oct 2018 07:40:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9MfJ2WVfKAyCVKBs7YZ0qmdcK7tYUPi3X Content-Type: multipart/mixed; boundary="pJoqIJ4v98VWvoN8ypKmeDK9KCZFxMBcS"; protected-headers="v1" From: Eliot Lear To: =?UTF-8?B?7LWc7YOc7IOB?= , "anima@ietf.org" Message-ID: <13c7f704-9283-a96f-902e-8f432af5089e@cisco.com> Subject: Re: [Anima] FW: New Version Notification for draft-choi-anima-trust-networking-01.txt References: <153952147038.5407.12858119464419526983.idtracker@ietfa.amsl.com> In-Reply-To: --pJoqIJ4v98VWvoN8ypKmeDK9KCZFxMBcS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi! This is a very interesting draft that addresses an issue industry has been seeing.=C2=A0 One of the challenges within an autonomic system is th= e establishments of rights, even when a device is identified.=C2=A0 If we l= ook at Figure 6 in your draft, it is very similar to that of the conduit and conduit controller mechanism envisioned by IEC 62443.=C2=A0 It would be useful to have a discussion about that work in the context of this draft.= Eliot On 22.10.18 03:43, =EC=B5=9C=ED=83=9C=EC=83=81 wrote: > A new version of I-D, draft-choi-anima-trust-networking-01.txt > has been successfully submitted by Tae Sang Choi and posted to the IETF= repository. > > Name: draft-choi-anima-trust-networking > Revision: 01 > Title: Trust networking and procedures for Autonomic Networking > Document date: 2018-10-14 > Group: Individual Submission > Pages: 32 > URL: https://www.ietf.org/internet-drafts/draft-choi-anima-t= rust-networking-01.txt > Status: https://datatracker.ietf.org/doc/draft-choi-anima-trust= -networking/ > Htmlized: https://tools.ietf.org/html/draft-choi-anima-trust-netw= orking-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-choi-anima-= trust-networking > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-choi-anima-tr= ust-networking-01 > > Abstract: > This document describes trust networking as an application of > autonomic networking. The objective of trustworthy autonomic > networking is providing trust networking environment where all > autonomic nodes can communicate without any security concern. It= > defines a trust networking domain and describes how to configure= and > maintain the trust networking domain. While communication within= the > trust networking domain is done with trust, the communication wi= th > external nodes should be done via a specific autonomic service a= gent > (ASA) called "trust gateway". The trust gateway ASA performs tru= st > evaluation of the external nodes and enforces domain specific > policies to keep the domain trustworthy. > > > > = =20 > > > Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org= =2E > > The IETF Secretariat > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --pJoqIJ4v98VWvoN8ypKmeDK9KCZFxMBcS-- --9MfJ2WVfKAyCVKBs7YZ0qmdcK7tYUPi3X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlvNfsoACgkQh7ZrRtnS ejOGqAgAlVjoGKfYdAWqNwITZEbf94oj3q29h78Vj6MXLfHG5+9j485fclg5TE8B Nms3UL2jYUMT2DpZ/mh3qDCYbU6AMn9H9eB/uyNRot7DnhMEK/4eKv9MXEssacO3 7ZmKh5FgYGIcjLi5lSX8JrO0YD2IVIi+fXpk8h17uY9NEee96k58mXaE/krv0AK9 L75BctytMYuVeJ/hl9xw7h0/UQm4KBSmN8apstyMpUOxONSKr6drxOeeplNwmh3W D1z7owVBn2gfqmBKoMtBTeC6Ypb+xbzQoD88Rx2Tuasr9dKH7PwjmNMVfqwxEfDI tJyKO9pMbOZ9GfMW+nUkdrI1ZSfi/A== =Lgsz -----END PGP SIGNATURE----- --9MfJ2WVfKAyCVKBs7YZ0qmdcK7tYUPi3X-- From nobody Mon Oct 22 11:15:23 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FBB128CB7; Mon, 22 Oct 2018 11:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6ofjEEQI9ooT; Mon, 22 Oct 2018 11:15:08 -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 C21A7128B14; Mon, 22 Oct 2018 11:15:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F12F20008; Mon, 22 Oct 2018 14:15:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 891142363; Mon, 22 Oct 2018 14:15:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 87464235A; Mon, 22 Oct 2018 14:15:04 -0400 (EDT) From: Michael Richardson To: "opsawg\@ietf.org" , Anima WG reply-to: "opsawg\@ietf.org" , Anima WG , emu@ietf.org cc: Eliot Lear , "Owen Friel \(ofriel\)" , Christian Huitema , Kent Watsen , emu@ietf.org In-Reply-To: References: <154004580158.13697.488879931982830841.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] Fwd: New Version Notification for draft-lear-brski-pop-00.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, 22 Oct 2018 18:15:12 -0000 --=-=-= Content-Type: text/plain Eliot, thanks for this document. If nothing else, it means that we BRSKI authors can deal with some review comments by pointing to "future work" :-) (A)"request-voucher-with-possession" <-- what about intent to traffic? :-) (for those that don't get the joke: https://criminal.findlaw.com/criminal-charges/possession-with-the-intent-to-distribute.html ) if leaf out-of-band-claim to be set by the PLEDGE? I think it is set by the Registar? The document sadly ends too soon... You say it is trying to do a few things. 1) deal with middle value pledge, (and low-value pledges in very congested places) where an out-of-band supply-chain integration is unavailable, and the MASA has a any-registar policy for the device. 2) provide a ship-and-forget mechanism. It seems that the cryptographic POP mechanism is an ends to accomplish a means, rather than a core goal of the protocol. The Pledge already can sign it's voucher-request, and since it includes the Registrar's key when it does a proximity assertion, it's pretty good proof of possession for the *Registrar*, but it might provide inadequate assurance to the MASA of it's freshness. If the MASA could provide a nonce for the pledge to sign (requiring another round trip, and even more online assurance), that would provide even more proof. Given that you pushed this out before today's cutoff, I am not upset that there is so few details. I am suspecting that in your thinking that you created the three objects, and realized that could accomplish "ship-and-forget" using a combination of them? I also wonder if cryptographic-POP is being confused with "proof of ownership", which I think is what you really want to accomplish. If one assumes some machine readable (QR) code that comes with the product, then there are a few things one can do to differently. One of the things that I have thought a lot about is that one uses the printed code in the Registrar to establish a relationship with the MASA. That is, one creates the supply-chain-integration by using the QR code with some zero-knowledge proof (I think that PAKE is the latest one) to establish that one is the legitimate Registrar for the product. One can do this as *any time* (some mumble about the lifetime of the CA of the Registrar's key), and the product will be enrolled correctly at any future time. About my joke (A) above, I think that ship-and-forget is an interesting goal, and in particular, if also may enable desireable "traffic"ing. That is, if the manufacturer can transfer the product to my ownership without any online interaction, then presumably, I can also *resell* the device to you using the same lack-of-interaction? ==== > In addition, some manufacturers may prefer not to require the > existence of a MASA. In these circumstances proof of possession to > the device is required. I would prefer that we split this into a different draft. I am very concerned that ship-and-forget is not a desireable property in the IoT space. It essentially means that the manufacturer has no further interest in providing any kind of updates for the device. I have serious cybersecurity concerns about such devices being out there (sitting unpatched and untracked in a warehouse somewhere), as well as significant environmental concerns about devices designed to die like this. I am trying to think of devices where this makes sense. I come up with a few things: single-use medical devices (like bandages, syringes, etc.), prophylactics and other single-use sex toys, things you eat, and some variety of devices that might be called "spy craft". In each case, I'm having difficulty knowing what the "smart" aspect of the product is, other than simply tracking it's existence and current stocking location. A smart package containing a dumb device is a good idea, but it seems like something that would be better recycled, and in any case, it's not ship-and-forget for the packaging. So this is why I think that splitting ship-and-forget mechanism into another document would let us treat it better. In particular, I want to know who is going to deploy using such mechanisms, and if they are at the table now. I guess I shall add a slide to my ANIMA BRSKI stack about this in an attempt to get feedback. I suspect that there is a category of devices that some think of being ship-and-forget which might actually be ship-to-holding-company. Holding company leases to end user for period of time. End user identity is never communicated back, and might be very much pseudonymous. I'm thinking about car-rentals, hotel rooms (full of devices), ... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvOE6gACgkQgItw+93Q 3WXBjwf/YCDdfvND1FAd/hb0dNClPGvFJPj6ykf4fKZK57Scyc86FXqP0j+OAzkp w9GCY/BCqnTja3i7L8fKiPfQ909Qz/bh+CSkMQsXdfBotjf38ZwUqT8VikRmG/Pu KmFxwq+EmXyt9UFRJl+qqpsebXoQbEeSGZ0pdqwZTpGXXkl5SOwCipUU/Ctw4iNd LGaPODL27gKhVn7QdCnXt0Wjy8zWZjiE6jnmUbmm7Sr5o7DgvZIVoJVj3PTufqY5 R4vMv+Yp/QafaiKCX6v9NdtC/Yet+tF7Kc2wtNEQEY6n8nBgIiKjRZDD5ZwWKdDT dVtGhHFKfuao+Wj0KzH0fyXUp+Jtfg== =mkhd -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 22 11:44:41 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDB4128766; Mon, 22 Oct 2018 11:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiExWrM_NdU0; Mon, 22 Oct 2018 11:44:24 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E5B1277C8; Mon, 22 Oct 2018 11:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8900; q=dns/txt; s=iport; t=1540233864; x=1541443464; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=iJgq7fQNNQ2HEHWSKNdePs+h7c/2Q3LF0l3EGjlOr+E=; b=FxfAuZ40zBxVA8W4ZM2amp6KzSPQz1c1bBDl7By4u9o4fZWglxBh3avE c3d67GpPNvkWQUoShswLPKndoIaujM/j7hH09nGs5BTBTMtB6n2EitHAB ZrlamQZf5fKWWcRMOMC/+n64FBE70CgrnytP0wtjkn7L9vEbjdNBp0CVF w=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos; i="5.54,413,1534809600"; d="asc'?scan'208"; a="7389458" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 18:44:21 +0000 Received: from [10.61.232.53] ([10.61.232.53]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9MIiKMn020362; Mon, 22 Oct 2018 18:44:20 GMT To: "opsawg@ietf.org" , Anima WG , emu@ietf.org Cc: "Owen Friel (ofriel)" , Christian Huitema , Kent Watsen References: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> <30525.1540232104@localhost> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Mon, 22 Oct 2018 20:44:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <30525.1540232104@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3XfHbHt1YNlkwRUxtg0nipQqO6lLC1mnL" X-Outbound-SMTP-Client: 10.61.232.53, [10.61.232.53] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Anima] Fwd: New Version Notification for draft-lear-brski-pop-00.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, 22 Oct 2018 18:44:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3XfHbHt1YNlkwRUxtg0nipQqO6lLC1mnL Content-Type: multipart/mixed; boundary="FnB28d6ALuHMH1tMIQwLdizjMEJDC78JK"; protected-headers="v1" From: Eliot Lear To: "opsawg@ietf.org" , Anima WG , emu@ietf.org Cc: "Owen Friel (ofriel)" , Christian Huitema , Kent Watsen Message-ID: Subject: Re: Fwd: New Version Notification for draft-lear-brski-pop-00.txt References: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> <30525.1540232104@localhost> In-Reply-To: <30525.1540232104@localhost> --FnB28d6ALuHMH1tMIQwLdizjMEJDC78JK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US [Christian, read down a ways] On 22.10.18 20:15, Michael Richardson wrote: > Eliot, thanks for this document. If nothing else, it means that > we BRSKI authors can deal with some review comments by pointing to "fut= ure > work" :-) > > (A)"request-voucher-with-possession" <-- what about intent to traffic? = :-) > (for those that don't get the joke: > https://criminal.findlaw.com/criminal-charges/possession-with-the-int= ent-to-distribute.html ) > > if leaf out-of-band-claim to be set by the PLEDGE? > I think it is set by the Registar? In all cases, any out of band claim has to be collected by the Registrar.=C2=A0 It is possible that having received such a claim from th= e Registrar, the pledge forwards it along to the MASA. > > The document sadly ends too soon... Gosh.=C2=A0 You want it all at once, don' you?!=C2=A0 Become an editor ;-= ) > > You say it is trying to do a few things. > 1) deal with middle value pledge, > (and low-value pledges in very congested places) > where an out-of-band supply-chain integration is unavailable, > and the MASA has a any-registar policy for the device. Yes. > > 2) provide a ship-and-forget mechanism. Yes. > > It seems that the cryptographic POP mechanism is an ends to accomplish = a > means, rather than a core goal of the protocol. I never employ hashes just for fun ;-) > The Pledge already can > sign it's voucher-request, and since it includes the Registrar's key wh= en it > does a proximity assertion, it's pretty good proof of possession for th= e > *Registrar*, but it might provide inadequate assurance to the MASA of i= t's > freshness. I think this covers the Joe Isuzu case that can fall out of the draft, and maybe one other.=C2=A0 The fundamental issue with the others is that = the Pledge needs some reason to believe that it is really on the correct network.=C2=A0 Proof of possession can come in several forms, depending o= n the device, but we're assuming that there's no user input to the device available (e.g., no buttons, to touch screen, etc).=C2=A0 It could also b= e that the Pledge really doesn't want to validate proof of possession by itself.=C2=A0 In that case, there's no reason for the pledge to even know= the proof of possession. > If the MASA could provide a nonce for the pledge to sign > (requiring another round trip, and even more online assurance), that wo= uld > provide even more proof. > > Given that you pushed this out before today's cutoff, I am not upset > that there is so few details. I am suspecting that in your thinking th= at you > created the three objects, and realized that could accomplish > "ship-and-forget" using a combination of them? That's part of the thinking, yes. > > I also wonder if cryptographic-POP is being confused with "proof of > ownership", which I think is what you really want to accomplish. We can have that discussion . > > If one assumes some machine readable (QR) code that comes with the prod= uct, > then there are a few things one can do to differently. One of the thin= gs > that I have thought a lot about is that one uses the printed code in th= e > Registrar to establish a relationship with the MASA. That is, one crea= tes > the supply-chain-integration by using the QR code with some zero-knowle= dge > proof (I think that PAKE is the latest one) to establish that one is th= e > legitimate Registrar for the product. One can do this as *any time* > (some mumble about the lifetime of the CA of the Registrar's key), and > the product will be enrolled correctly at any future time. Good point.=C2=A0 One possible thought in terms of the evolution of this = work would be =E2=80=9CMore stuff you can do with vouchers=E2=80=9D with a ple= thora of documented uses.=C2=A0 Or we might want to spawn a few more drafts.=C2=A0= Again, worth discussion. > > About my joke (A) above, I think that ship-and-forget is an interesting= > goal, and in particular, if also may enable desireable "traffic"ing. T= hat > is, if the manufacturer can transfer the product to my ownership withou= t any > online interaction, then presumably, I can also *resell* the device to > you using the same lack-of-interaction? Yes.=C2=A0 In fact that is a goal that I think both Christian and Randy h= ave motivated.=C2=A0 I would want to explore a bit whether or not to split ou= t ship and forget, but I would rather we tried to solve for that problem because it really is here (see below). > > =3D=3D=3D=3D > > > In addition, some manufacturers may prefer not to require the > > existence of a MASA. In these circumstances proof of possession t= o > > the device is required. > > I would prefer that we split this into a different draft. > > I am very concerned that ship-and-forget is not a desireable property > in the IoT space. It essentially means that the manufacturer has no fu= rther > interest in providing any kind of updates for the device. I have ser= ious > cybersecurity concerns about such devices being out there (sitting unpa= tched > and untracked in a warehouse somewhere), as well as significant environ= mental > concerns about devices designed to die like this. It could also be the case that the device is intended to be deployed in disconnected environments.=C2=A0 I also think it's going to be a little w= hile before certain classes of manufacturers will seriously be able to run an online MASA.=C2=A0 And I would like them to at least be able to consume a= voucher, even if we need different sorts of transfer approaches. > > I am trying to think of devices where this makes sense. I come up with= a few > things: single-use medical devices (like bandages, syringes, etc.), > prophylactics and other single-use sex toys, things you eat, and some > variety of devices that might be called "spy craft". In each case, I'm= > having difficulty knowing what the "smart" aspect of the product is, ot= her > than simply tracking it's existence and current stocking location. A sm= art > package containing a dumb device is a good idea, but it seems like some= thing > that would be better recycled, and in any case, it's not ship-and-forge= t > for the packaging. > > So this is why I think that splitting ship-and-forget mechanism into an= other > document would let us treat it better. In particular, I want to know w= ho is > going to deploy using such mechanisms, and if they are at the table now= =2E > I guess I shall add a slide to my ANIMA BRSKI stack about this in an at= tempt > to get feedback. > > I suspect that there is a category of devices that some think of being > ship-and-forget which might actually be ship-to-holding-company. > Holding company leases to end user for period of time. End user identi= ty > is never communicated back, and might be very much pseudonymous. > I'm thinking about car-rentals, hotel rooms (full of devices), ... > > Let's discuss further.=C2=A0 Looking forward to the Tuesday 6:00pm Side m= eeting. Eliot --FnB28d6ALuHMH1tMIQwLdizjMEJDC78JK-- --3XfHbHt1YNlkwRUxtg0nipQqO6lLC1mnL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlvOGoQACgkQh7ZrRtnS ejOPqggAliIjC7O1pU7l1LtZQpqNkcODmS//RlLCLyKeK+UYfTUF3ycADNN7v6MD xUgLsgCgs7xFBsEFxgh4075K3kuTjVVSCgNgwS/s38hYq2ZqCZ9hA+/k8C2CsvJM z7jY3n1+msQ+SRCiTJKs5CzRTyXrrrEMMuQmaCPIUMmeTaeRKgcarcl0GuRks9zu jkFrw/8ruxeNWOYYyRf8mdSxU3CDv51f1gcerBnXR/qB3RRtLCqUAEE6JBbmkes0 umCyCfNf9HdBLvtDeqCqnBIZc5Do8U4/3WqFKr52SWb3x5om+Y+pCwsSaOX6P5EL XuPy5kyUjcRJdEsawFbzXqap0uZSiQ== =hSN/ -----END PGP SIGNATURE----- --3XfHbHt1YNlkwRUxtg0nipQqO6lLC1mnL-- From nobody Mon Oct 22 12:54:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DE212D7EA; Mon, 22 Oct 2018 12:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aV5_R-ekTcSL; Mon, 22 Oct 2018 12:54:35 -0700 (PDT) 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 AF97E1294D7; Mon, 22 Oct 2018 12:54:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EF8220008; Mon, 22 Oct 2018 15:54:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B7F662363; Mon, 22 Oct 2018 15:54:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B62AE22D5; Mon, 22 Oct 2018 15:54:34 -0400 (EDT) From: Michael Richardson To: "opsawg\@ietf.org" , Anima WG , emu@ietf.org In-Reply-To: References: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> <30525.1540232104@localhost> 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: [Anima] ship and forget use cases for onboarding 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, 22 Oct 2018 19:54:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {cutting CC of people, and we need to pick a WG list to discuss this on?} Eliot Lear wrote: >> The Pledge already can >> sign it's voucher-request, and since it includes the Registrar's key= when it >> does a proximity assertion, it's pretty good proof of possession for= the >> *Registrar*, but it might provide inadequate assurance to the MASA o= f it's >> freshness. > I think this covers the Joe Isuzu case that can fall out of the draft, > and maybe one other.=C2=A0 The fundamental issue with the others is t= hat the > Pledge needs some reason to believe that it is really on the correct > network.=C2=A0 Proof of possession can come in several forms, dependi= ng on > the device, but we're assuming that there's no user input to the devi= ce > available (e.g., no buttons, to touch screen, etc).=C2=A0 It could al= so be > that the Pledge really doesn't want to validate proof of possession by > itself.=C2=A0 In that case, there's no reason for the pledge to even = know the > proof of possession. https://en.wikipedia.org/wiki/Joe_Isuzu ... I asked google, and I'm not quite sure I get the connection. >> I would prefer that we split this into a different draft. >> >> I am very concerned that ship-and-forget is not a desireable property >> in the IoT space. It essentially means that the manufacturer has no >> further >> interest in providing any kind of updates for the device. I have >> serious >> cybersecurity concerns about such devices being out there (sitting >> unpatched >> and untracked in a warehouse somewhere), as well as significant >> environmental >> concerns about devices designed to die like this. > It could also be the case that the device is intended to be deployed = in > disconnected environments.=C2=A0 I also think it's going to be a litt= le while > before certain classes of manufacturers will seriously be able to run= an > online MASA.=C2=A0 And I would like them to at least be able to consu= me a > voucher, even if we need different sorts of transfer approaches. It's not enough to say that they are going to be deployed in disconnected environments. It's that they one wants to drop-ship them from the *manufacturers* warehouse to the disconnected location. When one thinks about drop-ship to a disconnected location, one tends to think about containers of humanitarian AID going out the back of a aircraft (C-2, Hercules, etc.) with a parachute. If anything, that situation is probably *NOT* the case we are thinking about, because in that case the kit would have already gone through the owner's warehouse (whether the owner is a UN aid agency, some FEMA equivalent). The entire kit could have been onboarded (wirelessly) as it went *onto* the aircraft, or could even occur as late as when it's on the aircraft. And you said, "online MASA", when it could well be that it's an offline MASA. If you buy enough product, the manufacturer could well just put a custom trust anchor in and give you the private key. That's essentially what happens in Industrial 4.0 802.15.4 deployments today. So I'm saying, let's not invent a problem before we understand who actually has the problem.... and make sure that the people who can solve the problem are at our table. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvOKvoACgkQgItw+93Q 3WVjrQf+LDsORDMpORT2WEtvCoWJzvdEcAQYW+Vt96GtxJfg/np/ludSEcV53CDO I2vBJLZrW5hpJbzfRzHO2H+boA4cMDPX562IjUc0kW6BkeGLtGTlu70Qw47faZBJ xfPMLNvuhdYQKJ3LCwItY3u3ceU7CV1OBFPmzpW7bgfZn8vCLtpzzXa6Ral/Lvf+ TAZ/klWr4TEfJQj6CoeLklzIUx/tMh6TPD1P/9T/WQsEt+SmqpdzzCtK6XiNKkEy i8FBLpV/uSumF7obkwV8itGG9nUQVtUt8oV7cJa4h02nUgMQwOfWUtyygn3ZjB7O PFdChHVMKaAqGB9FTI0xGp7GNl+QsQ== =osBo -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 23 04:27:03 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B54130E02; Tue, 23 Oct 2018 04:26:48 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlvrzvxbHK2v; Tue, 23 Oct 2018 04:26:46 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E24D1271FF; Tue, 23 Oct 2018 04:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9615; q=dns/txt; s=iport; t=1540294005; x=1541503605; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Z0AcZQzyyyv2iSw1Yx7oputw1qi7l9T3bxFTkEY8yJo=; b=CQqyZdbV36N7VE9ve1IC0D46mbhRmqv3p0xdVxpQVi9lfncp+zbn+ZqB BY/uiHscVLH1GDpbgy+7PT0Ss4cXCMXlyBg875cyKETeTR1qFarLh4HuH c08HCWOerZp5+cEQXHfLqDMG8fdhyz+Vi6YUzcvhv1ewcc2/awd133+yA A=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAABaBM9b/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYJrbRIog3WId41MkU2HQggFGAEKgVSCdQKFSTgWAQMBAQI?= =?us-ascii?q?BAQJtHAyFOgEBAQECAQEBIUsEDAsJAhgqAgInMAYBDAYCAQGDHQGBeQgPij2?= =?us-ascii?q?bTYEuH4l2CgWCbYkLggCBESeCPS6DGwEBA4EqDYMqglcCiQMCFpU1CYQQgW5?= =?us-ascii?q?lgx2GbgYXiTSGfIxcig+BWiE0gSEzGggbFTuCbIImF4hchUA9MIsugk0BAQ?= X-IronPort-AV: E=Sophos;i="5.54,416,1534809600"; d="asc'?scan'208,217";a="7407734" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 11:26:42 +0000 Received: from [10.61.70.182] (ams3-vpn-dhcp1718.cisco.com [10.61.70.182]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w9NBQf88024714; Tue, 23 Oct 2018 11:26:41 GMT To: Michael Richardson , "opsawg@ietf.org" , Anima WG , emu@ietf.org References: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> <30525.1540232104@localhost> <22917.1540238074@localhost> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <09c86b2f-bcf3-0c9a-1b62-abc7e28cb124@cisco.com> Date: Tue, 23 Oct 2018 13:26:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <22917.1540238074@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dI5Bv6QVLZ34pY6NpE4ZJ1HGLA3fb2EPE" X-Outbound-SMTP-Client: 10.61.70.182, ams3-vpn-dhcp1718.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Anima] ship and forget use cases for onboarding 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, 23 Oct 2018 11:26:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dI5Bv6QVLZ34pY6NpE4ZJ1HGLA3fb2EPE Content-Type: multipart/mixed; boundary="KSE8TpCTKkRX1QHrFp7Eb5RDARPVgIeLD"; protected-headers="v1" From: Eliot Lear To: Michael Richardson , "opsawg@ietf.org" , Anima WG , emu@ietf.org Message-ID: <09c86b2f-bcf3-0c9a-1b62-abc7e28cb124@cisco.com> Subject: Re: [Anima] ship and forget use cases for onboarding References: <154004580158.13697.488879931982830841.idtracker@ietfa.amsl.com> <30525.1540232104@localhost> <22917.1540238074@localhost> In-Reply-To: <22917.1540238074@localhost> --KSE8TpCTKkRX1QHrFp7Eb5RDARPVgIeLD Content-Type: multipart/alternative; boundary="------------6A665F1E44E0036EF06D7914" Content-Language: en-US This is a multi-part message in MIME format. --------------6A665F1E44E0036EF06D7914 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, On 22.10.18 21:54, Michael Richardson wrote: > > > https://en.wikipedia.org/wiki/Joe_Isuzu ... I asked google, and I'm no= t > quite sure I get the connection. Sorry- this was a reference to an earlier message.=C2=A0 There is a mode = in which the MASA is acting based on its relationship with the registrar.=C2= =A0 The punch line with Joe Isuzu was =E2=80=9CTrust me!=E2=80=9D > It's not enough to say that they are going to be deployed in disconnect= ed > environments. It's that they one wants to drop-ship them from the > *manufacturers* warehouse to the disconnected location. There are quite a number of use cases where connectivity may be an issue:= * A secure building, where Internet access is limited, and even carrying in a USB stick is problematic.=C2=A0 This can range from a military installation to a pharmaceutical laboratory, to certain departments of financial institutions. * It could simply be an order of operations matter, where the device has arrived in advance of Internet connectivity but still wants to function (think fire suppression systems). You may say, =E2=80=9Cbut onboard them advance of their deployment=E2=80=9D= =2E=C2=A0 That may or may not be practicable. > When one thinks about drop-ship to a disconnected location, one tends t= o > think about containers of humanitarian AID going out the back of a airc= raft > (C-2, Hercules, etc.) with a parachute. If anything, that situation i= s > probably *NOT* the case we are thinking about, because in that case the= kit > would have already gone through the owner's warehouse (whether the owne= r is > a UN aid agency, some FEMA equivalent). The entire kit could have been= > onboarded (wirelessly) as it went *onto* the aircraft, or could even oc= cur > as late as when it's on the aircraft. I think we're get a better feel for some of this as time goes on, but one could imagine components sitting in a drawer for five years.=C2=A0 > > And you said, "online MASA", when it could well be that it's an offline= > MASA. If you buy enough product, the manufacturer could well just put > a custom trust anchor in and give you the private key. That's essentia= lly > what happens in Industrial 4.0 802.15.4 deployments today. I certainly know manufacturers who do that, and they mostly hate it, because it requires custom builds. > > So I'm saying, let's not invent a problem before we understand who actu= ally > has the problem.... and make sure that the people who can solve the pro= blem > are at our table. This sounds like an EXCELLENT conversation for the next few weeks. Eliot > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --------------6A665F1E44E0036EF06D7914 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Michael,


On 22.10.18 21:54, Michael Richardson wrote:


https://en.wikipedia.org/wiki/Joe_Isuzu  ... I asked googl=
e, and I'm not
quite sure I get the connection.

Sorry- this was a reference to an earlier message.=C2=A0 There is a m= ode in which the MASA is acting based on its relationship with the registrar.=C2=A0 The punch line with Joe Isuzu was =E2=80=9CTrust me!= =E2=80=9D
It's not enough to say that they are going to be deployed in disconnected=

environments.  It's that they one wants to drop-ship them from the
*manufacturers* warehouse to the disconnected location.

There are quite a number of use cases where connectivity may be an issue:
  • A secure building, where Internet access is limited, and even carrying in a USB stick is problematic.=C2=A0 This can range from= a military installation to a pharmaceutical laboratory, to certain departments of financial institutions.
  • It could simply be an order of operations matter, where the device has arrived in advance of Internet connectivity but still wants to function (think fire suppression systems).

You may say, =E2=80=9Cbut onboard them advance of their deploymen= t=E2=80=9D.=C2=A0 That may or may not be practicable.

When one thinks about drop-ship to a disconnected location, one tends to
think about containers of humanitarian AID going out the back of a aircra=
ft
(C-2, Hercules, etc.) with a parachute.   If anything, that situation is
probably *NOT* the case we are thinking about, because in that case the k=
it
would have already gone through the owner's warehouse (whether the owner =
is
a UN aid agency, some FEMA equivalent).  The entire kit could have been
onboarded (wirelessly) as it went *onto* the aircraft, or could even occu=
r
as late as when it's on the aircraft.

I think we're get a better feel for some of this as time goes on, but one could imagine components sitting in a drawer for five years.=C2=A0 

And you said, "online MASA", when it could well be that it's an offline
MASA.  If you buy enough product, the manufacturer could well just put
a custom trust anchor in and give you the private key.  That's essentiall=
y
what happens in Industrial 4.0 802.15.4 deployments today.

I certainly know manufacturers who do that, and they mostly hate it, because it requires custom builds.


So I'm saying, let's not invent a problem before we understand who actual=
ly
has the problem.... and make sure that the people who can solve the probl=
em
are at our table.

This sounds like an EXCELLENT conversation for the next few weeks.
Eliot


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






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

--------------6A665F1E44E0036EF06D7914-- --KSE8TpCTKkRX1QHrFp7Eb5RDARPVgIeLD-- --dI5Bv6QVLZ34pY6NpE4ZJ1HGLA3fb2EPE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlvPBXAACgkQh7ZrRtnS ejNVWggAs2lKXmBTJ2ZiIcwt0/a4/+eo/pUHKPX8vEm223O+nK3KBLuc8uklDFGv wlRIiaVFoRr2NqwvlZmgJdj0dUynowb7p2oHGslKDixN3/gMBhhiN2J5KGD7qjSP zgWicJKt+4LpJIoS1AF1pGvubkdIrHvu4YG62w8LfHBtvl0qNMYL3hHLj9D7gkq3 ge3tctQ2I22Fsx9oQ5uLvZeGoso0hI/L3C9sREgbPMkmEfbxzhmdemxaSIxNJxBf uSVQGoXHeyOaOGE9Y8LCULYInxafKk8cTM+Kd3eVBF8SRRUOborhwJYH9ou218eo OIf3kwUU3cweHSFm9OS4v7HDwWc8Sg== =CVDm -----END PGP SIGNATURE----- --dI5Bv6QVLZ34pY6NpE4ZJ1HGLA3fb2EPE-- From nobody Tue Oct 23 10:26:03 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE7B127B92; Tue, 23 Oct 2018 10:26:02 -0700 (PDT) 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_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 b6jVmZVi3fWJ; Tue, 23 Oct 2018 10:26:00 -0700 (PDT) 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 817A01274D0; Tue, 23 Oct 2018 10:26:00 -0700 (PDT) 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 4C066548025; Tue, 23 Oct 2018 19:25:56 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3B92B440210; Tue, 23 Oct 2018 19:25:56 +0200 (CEST) Date: Tue, 23 Oct 2018 19:25:56 +0200 From: Toerless Eckert To: Sheng Jiang Cc: "anima@ietf.org" , "anima-chairs@ietf.org" Message-ID: <20181023172556.hbxx2765xbqrjkpy@faui48f.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B929020B40D@NKGEML515-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B929020B40D@NKGEML515-MBX.china.huawei.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 103, Bangkok 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, 23 Oct 2018 17:26:02 -0000 Hi Sheng Pls add two slots for me a) Would like make a WG adoption call for the two standard target track drafts to support the concepts of automated network management via ANI introduced in draft-stable connectivity (RFC8368) draft-eckert-anima-grasp-dnssd draft-eckert-anima-noc-autoconfig 10 mins b) Will probably miss the deadline uploading the update today, but will finish it and want to present for ACP draft (in IESG review). 10 mins. Thanks Toerless On Wed, Oct 10, 2018 at 11:23:31AM +0000, Sheng Jiang wrote: > Hi, all anima, > > > > We have been allocated a session of 2-hour for the ANIMA WG meeting for IETF-103 (Bangkok) - Monday afternoon session I. We are now starting to collect agenda items for the session. Please send your request for agenda by October 25th, Thursday. > > > > For this coming meeting, we would like to discuss potential future ANIMA works. As normal, the priority among these non-charter work items would be: these that have active discussion in mail list, then these have submitted drafts, and topics without drafts. > > > > Please send us (anima-chairs at ietf.org) requests for time slot by October 25th, Thursday and include: > > > > Name of time slot: > > Name of draft(s): > > Time requested: > > Presenter name(s): > > > > More details about the IETF 103, Bangkok can be found at: > > > > https://www.ietf.org/how/meetings/103/ > > > > Again, presenters and draft authors please invoke active discussions in the ANIMA list. Mail list is a very good place to discuss and reach consensus on technical issues. > > > > Best regards, > > > > Toerless & Sheng -- --- tte@cs.fau.de From nobody Tue Oct 23 14:24:12 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5774E130DC7 for ; Tue, 23 Oct 2018 14:24:10 -0700 (PDT) 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_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 eaa0Z7iuwLx1 for ; Tue, 23 Oct 2018 14:24:08 -0700 (PDT) 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 5C03D130D7A for ; Tue, 23 Oct 2018 14:24:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 519C620008; Tue, 23 Oct 2018 17:24:04 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B06D22302; Tue, 23 Oct 2018 17:24:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AE1131FD; Tue, 23 Oct 2018 17:24:06 -0400 (EDT) From: Michael Richardson To: max pritikin , anima@ietf.org X-Attribution: mcr 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: [Anima] HTTP codes from JRC to Pledge 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, 23 Oct 2018 21:24:10 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Max, In section 5.5 we outline a number of HTTP codes that can be returned From=20the MASA and from the Registrar. In my coding I did a few dumb things (like testing against the wrong code base) which resulted in my MASA failing and return error code 500 to the Registrar. What should the Registrar do? It seems that we ought to say more about how MASA error codes translate into codes being returned to the Pledge is a more coherent fashion. I was thinking that maybe all 4xx codes returned from the MASA result in a specif= ic 4xx (not necessarily the same one) code being returned to the Pledge. I am less certain that a 5xx code from the MASA ought to result in a specif= ic 5xx code to the pledge. For instance, there are a number of network conditions that might occur between the Registrar and MASA which, to the Pledge probably mean: just hang on and try again. Or might even result in a 201 code being returned and the Pledge could/shou= ld poll that location for an update. I partly think that this might be simply be future work (in which case, we should say this): for that step from DS to IS, where we have actual experience to be able to map things. Or perhaps we would start a document collecting experiences. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvPkXYACgkQgItw+93Q 3WVZfQgAseeXMvI/jQAOLjfqa+zSEcfscDU9UWvERSOO6+Jk2NdYYULJ1Y/daqvC D1Jyk6nQhU/VtxZog4mPCp9SOCpg35YGii6UtCedaFUq/fEk379zzs6h1RAUZW15 2FSBvBeJsJjvNMCgVwVIut34D7OClzFoYDrJrGqXW+c4zBrBz7IYAA6oz5Hzn+CD fb7ToYyDXZ7mDYh4oui2k/UQNv+CqhgNCcJexyTnBH3dZmrYDs0HlStiCtWbVtBr zim+MykknbgCaj8vJjd2o0k5X+DZkXALrH2yGCoCYnFr2GiDfaCwm1MuhAp7/X04 eKhJQRhPKT9TO04UIzwDjruMpGDHow== =yIGR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 23 14:36:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10102130E71 for ; Tue, 23 Oct 2018 14:36:11 -0700 (PDT) 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_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 Ph3K4Zfj2t-Q for ; Tue, 23 Oct 2018 14:36:09 -0700 (PDT) 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 BBB8E130E6B for ; Tue, 23 Oct 2018 14:36:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2A3A320008; Tue, 23 Oct 2018 17:36:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 86CFE2302; Tue, 23 Oct 2018 17:36:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 84FD51FD; Tue, 23 Oct 2018 17:36:07 -0400 (EDT) From: Michael Richardson to: max pritikin , anima@ietf.org 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: [Anima] EST (EST-COAP) usage vs BRSKI 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, 23 Oct 2018 21:36:11 -0000 --=-=-= Content-Type: text/plain Max, While implementing pure enrollment code for EST-COAP testing, I have realized that on the Registrar there is a state which we may not have adequately discussed. While 2.1 provides a nice diagram for the Pledge, when we changed the view of things we lost some of the state machine thoughts from the Registrar point of view. For a pure first-time enrollment, there is not a lot of issue. The issue comes when one tries to combine a few functions in a registrar. (BTW: I had advocated splitting these into seperate servers and ports) When a registrar receives a connection from another node, it examines the TLS Client Certificate and may categorize it into three possible things: 1) This is an LDevID certificate (possibly recently expired, see LAMPS), and the node is about to as for a simpleenrollment to renew it! 2) This is an IDevID certificate from a manufacturer which implements BRSKI (and which is in the whitelist) and which is expected to do voucher processing. 3) This is an IDevID certificate from a manufacturer/device which has a known anchor, just does EST enrollment, and already trusts the Registrar via "magic". Part of my surprise was that I realized that the TLS connection is never really "provisional" from the Registrar point of view. It's either authenticated by the IDevID/manufacturer-certificate, or via the LDevID. Or the client certificate does not lead to any reasonable trust anchor, and the connection is to be rejected. Unless the Registrar is "promiscuous", which is to say has a "*" in the anchor whitelist. It seems to me that like we either ought to fail the TLS connection in a very clear fashion if the client certificate is unacceptable, or we need to have a very clear 5xx return to all operations if we think it's a good idea to let the connection persist. (Caveat, we might actually want to log the telemetry status operation, and perhaps we always return 200 for that) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvPlEcACgkQgItw+93Q 3WVExAf+MWonJ20hvP6Lp79Cf/ETzIAgWW+tH7YcrciVbHcMwT0S8DnYokH8gV4D TezlBqYhzFDfZGmWYOKkbtc7bM7JiAtjKlSTR+VHVqtpBT5gRMheqtIMoTuzbShm F/pH8cChF5CQJXNpIqCRRy8QuSuVDl1msnQHN5XQhIwBA9SnxnqJqoJREw+IvrUz cNgd/oZShgJl/GWn8jn93K1ZJVQ1mBlvMqr8imwHRMxh/MIeq4IPbjNcPw4i0Lfo yeRC2SFOKjXi3lDI27C86BN4WRyLUeq7S1zDhuz/l960csFnLKeIXtkctQkbrqDR TKt+2LJl7W/h6Fs4MZNd1hb5XfMuLw== =tj70 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 24 06:40:28 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF643130E35; Wed, 24 Oct 2018 06:40:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , anima-chairs@ietf.org, Sheng Jiang , anima@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154038842683.6988.10941024706455634298.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2018 06:40:26 -0700 Archived-At: Subject: [Anima] Eric Rescorla's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT) 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: Wed, 24 Oct 2018 13:40:27 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-anima-reference-model-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3602 COMMENTS S 2. > +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + > : Autonomic Networking Infrastructure : > +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + > +--------+ : +--------+ : +--------+ : +--------+ > | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | > +--------+ : +--------+ : +--------+ : +--------+ This diagram is kind of hard to follow. You say ASAs are instantiated on nodes, but these ASAs don't seem to be attached to any particular nodes. S 4.3. > > 4.3. Discovery > > Traditionally, most of the information a node requires is provided > through configuration or northbound interfaces. An autonomic > function should rely on such northbound interfaces minimally or not is "northbound" a synonym for "configuration"? S 6.1. > Thus we can distinguish at least three classes of ASAs: > > o Simple ASAs with a small footprint that could run anywhere. > > o Complex, possibly multi-threaded ASAs that have a significant > resource requirement and will only run on selected nodes. This is kind of nitpicking but there are plenty of languages where multithreading is natural even in simple programs (e.g., Rust or to some extent Go). S 6.1. > components. Also, they may be coded in a variety of programming > languages, in particular including languages that support object > constructs as well as traditional variables and structures. The APIs > should be designed with these factors in mind. > > It must be possible to run ASAs as non-privileged (user space) You probably don't want parentheses here. non-privileged and user space are different thigns. S 6.1. > negotiation failures must be treated as routine, with the ASA > retrying the failed operation, preferably with an exponential back- > off in the case of persistent errors. When multiple threads are > started within an ASA, these threads must be monitored for failures > and hangups, and appropriate action taken. Attention must be given > to garbage collection, so that ASAs never run out of resources. Hmm.... This is PL nitpickery again, but many languages don't have garbage collection. Perhaps you mean "memory management" S 9.1. > > Here, we assume that all systems involved in an autonomic network are > secured and operated according to best current practices. These > protection methods comprise traditional security implementation and > operation methods (such as code security, strong randomization > algorithms, strong passwords, etc.) as well as mechanisms specific to "randomization" is a term of art here that means that the algorithms are randomized (as in randomized hashing) not that you generate strong random numbers. S 9.1. > valuable information about network configuration, security > precautions in use, individual users, and their traffic patterns. If > encrypted, AN messages might still reveal some information via > traffic analysis, but this would be quite limited (for example, this > would be highly unlikely to reveal any specific information about > user traffic). Don't bet on this. Traffic analysis is very powerful. S 9.2. > AN or other protocols. Also this is a generic threat that applies > to all network solutions. > > The above threats are in principle comparable to other solutions: In > the presence of design, implementation or operational errors, > security is no longer guaranteed. However, the distributed nature of This isn't obvious to me. The issue here is that control of one non- privileged device might let you affect others. That wouldn't be true of centrally managed systems. From nobody Wed Oct 24 14:00:27 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D74128D68; Wed, 24 Oct 2018 14:00:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Deborah Brungard To: "The IESG" Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154041482526.6887.1508175710316372385.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2018 14:00:25 -0700 Archived-At: Subject: [Anima] Deborah Brungard's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT) 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: Wed, 24 Oct 2018 21:00:25 -0000 Deborah Brungard has entered the following ballot position for draft-ietf-anima-reference-model-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In discussing the Autonomic Control Plane (section 4.6), it says "is implemented as an overlay network". "Overlay" in routing documents (e.g. GMPLS) refers to an abstraction of the underlying data layer. The rtgdir reviewer (Chris) was also confused on the use of "overlay". Is your intention for the control plane to be independent of the topology of the data plane layer? For GMPLS, where the control plane and data plane are clearly separated, the control and data planes are said to be "decoupled" (control plane neighbors may not necessarily be data plane neighbors). Suggest not to use "overlay" if your intention is for it to be decoupled. If the intention is for it to reflect an (abstracted) connectivity of the data plane layer than could use '"overlay" though it would be helpful to define what is meant. Please review Chris's other comments. From nobody Wed Oct 24 15:15:40 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE5212F18C; Wed, 24 Oct 2018 15:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEhX8eZlafmd; Wed, 24 Oct 2018 15:15:37 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 CDD63128D0C; Wed, 24 Oct 2018 15:15:34 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id a5-v6so2097539pgt.13; Wed, 24 Oct 2018 15:15:34 -0700 (PDT) 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=MYuxmVwdfxdmCm7aB3Pn0CVENIE8LSvhULos8bWz4iA=; b=LoQ3qbLvlz3C1OMxBH9nJGa+mqJma9VcE1/i9sUlQ6wDW5nTj903/pKbWCyLkcbpZT 0WWwUcxdihfCxsRLgCvkHNhrCBi2UpbckYYQqwgSqOuAZeMi6i2QbaDn0mFdE3PjOKI3 5boO4XoqQNPWyAVK9OH1OAumlSJcbru4qMwpawKK0UQastukTTaRmzzfcHmJqGO3oygK 2vBNohI/Z1sUkZBjWrjeWjTtG0i344C1YwzT6zFOUR0e0IziYRtm7z7z92vALcEJ49Dh +yto776KZlI/013/BRwdiKtwsSOK1Goqny75m2JdrhJ0SqlhK5S34D7tKvPU95/0MSZc HNTQ== 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=MYuxmVwdfxdmCm7aB3Pn0CVENIE8LSvhULos8bWz4iA=; b=aYP7763qfGXYKx9rXCJUDTFaRkoF9sXlhW6dnmRj+cfuY8vyUP/ocpfCrn0LUsDBN8 sgAX9eYgD3KjN5h3TXUnp6ph9KLRtuj2bALd0w6jdDmlvGi0NxY6JhIsegHAvL4yFIXo 8l98UN0GcFbt3WUawjF4aZ8trjaGjwV6oQ7GTZ35ii+TedJ6EM1nFpLEwPvY1HdEtJCr C//krsWLgLkYO0nteNgpp6TeVEZZpQRH1TDiBxyjDcApKAUaNq68Vfox99Uz18lbvyPF tAgHsxQNt9qOD3ehBpAOSBZXTUIigZ71JtkakHwa8nNqYOANyoKRE+ZVK8jztnzniypB miqg== X-Gm-Message-State: AGRZ1gKgwa4FGGjo0o96s+w89fb7KG6KoF3Di+tt0yZA2Pu2X8xp+EZF zQk0ZrdmCethwr6kjjSaGNIsa1Dn X-Google-Smtp-Source: AJdET5dFtaGO/1AHLkACCLhB0J4WSJAuYaqxkXKOsPNsg//AaLhYAZG0XLO3SS39EBdZ2OCkL54ZdA== X-Received: by 2002:aa7:8305:: with SMTP id t5-v6mr4257416pfm.81.1540419334052; Wed, 24 Oct 2018 15:15:34 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id 72-v6sm7734993pfl.126.2018.10.24.15.15.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 15:15:32 -0700 (PDT) To: Eric Rescorla , The IESG Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , anima-chairs@ietf.org, Sheng Jiang , anima@ietf.org References: <154038842683.6988.10941024706455634298.idtracker@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <021c5915-0926-afdd-c7a3-03ea01366060@gmail.com> Date: Thu, 25 Oct 2018 11:15:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154038842683.6988.10941024706455634298.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's No Objection on draft-ietf-anima-reference-model-08: (with 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: Wed, 24 Oct 2018 22:15:39 -0000 Thanks Eric, all good points. On one bit that I drafted: On 2018-10-25 02:40, Eric Rescorla wrote: ... > S 6.1. >> Thus we can distinguish at least three classes of ASAs: >> >> o Simple ASAs with a small footprint that could run anywhere. >> >> o Complex, possibly multi-threaded ASAs that have a significant >> resource requirement and will only run on selected nodes. > > This is kind of nitpicking but there are plenty of languages where > multithreading is natural even in simple programs (e.g., Rust or to > some extent Go). True. I wrote the GRASP prototype in multithreaded Python, but low end nodes might well run a subset and only have a C/C++ run time. We're not trying to be categorical here, just to show there's a range of possibilities. Brian From nobody Wed Oct 24 16:08:43 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A59C12D4EC; Wed, 24 Oct 2018 16:08:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154042252127.6853.18391573929277125477.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2018 16:08:41 -0700 Archived-At: Subject: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT) 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: Wed, 24 Oct 2018 23:08:41 -0000 Ben Campbell has entered the following ballot position for draft-ietf-anima-reference-model-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work on this. I just have one editorial comment: - Several sections describe themselves as being for "informational purposes". Given that this is an informational document, isn't that true of all sections? From nobody Wed Oct 24 18:10:19 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C654E129BBF; Wed, 24 Oct 2018 18:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulOMUHKwQODt; Wed, 24 Oct 2018 18:10:16 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 9362B130934; Wed, 24 Oct 2018 18:10:16 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id i4-v6so3168523pgq.9; Wed, 24 Oct 2018 18:10:16 -0700 (PDT) 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=hiNROcYhXWLMmtjPZ0d1GuVKtnVL5aSf4fi8nQIcUVA=; b=QHHIXVoUdEYPHbHg0+1Heaa/CVDvpwve+sIddMcsioJSEa3QKpYwLc9liYzw3xnnMH Rb6zIGef5Jd+6q11DOpkODN8PSamN/DevJsWo6dymtMkZ93u/oKhgNYJG2J8UheFFY91 hdjx8Sw5EWGySe2bCVah8KfeRdek69NOxDAD8xzfzGXFFbhVT6udi2w7LQereK8g/9H0 rE33yrSn5net4IjgPxmUDRnOo6F4blOh4Cife7/KrZyyZRB0ktKb06TWbZSNfZDzeKk8 GYbrt0Il2oc1lmrNjdx7HcIA1LRq//mG0aAQpWg4o/4LICKawo+OwcxL6SB7W2oy4EaM UBbw== 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=hiNROcYhXWLMmtjPZ0d1GuVKtnVL5aSf4fi8nQIcUVA=; b=lmAtEmz1fHjrn6CnsphMSoxHCU2dbPuz7wNgbJVsa2+4My2I2p92BLPRTkDwhMWvYe qLw058tNTic7QPxS6QGWQZkdB2GICQAXL7NORye5YIi9/bTXVlC0Oi9cQ++EDX6E/a3m Xak3TziG6J5GtO6V1/3qoQdS+jAPGdH/TPssjchBnhjtgqy9/io1WZ7skFJ8CRuWRkDO FKVYyDLICuCIokjVJA7AhpKemwHcwMiku5AzXF76f4WeDqJojAnQXiEq1YemZ968gaDy x1h8fVgQzgP0k0U8wmFcinZJjoubYXURsOM4f2lIy+dSmpZ8hVXfHr1cMZTB/4vww1vb q4kQ== X-Gm-Message-State: AGRZ1gJglRRZg01j2cVbt2QLuFo+RtGcl3x+bpmXV03vXsvLyZPcgzlT UHlc6S7n1UDwYvzFJVA4i3/6GFQX X-Google-Smtp-Source: AJdET5fvq3lJ0qqqtom7E/dBqn34bg/Vdsq8BE6Z7urkq/lHCUpTkW55GFboC2IiP/BcvS/1nUMqpg== X-Received: by 2002:a63:e818:: with SMTP id s24-v6mr4475747pgh.90.1540429815789; Wed, 24 Oct 2018 18:10:15 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id y12-v6sm13745175pga.77.2018.10.24.18.10.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 18:10:15 -0700 (PDT) To: Ben Campbell , The IESG Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <154042252127.6853.18391573929277125477.idtracker@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <1db87d2f-6709-2613-0422-182989531701@gmail.com> Date: Thu, 25 Oct 2018 14:10:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154042252127.6853.18391573929277125477.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 01:10:19 -0000 Hi Ben, On 2018-10-25 12:08, Ben Campbell wrote: ... > Thanks for the work on this. I just have one editorial comment: > > - Several sections describe themselves as being for "informational purposes". > Given that this is an informational document, isn't that true of all sections? Those sections are among the ones tagged (*) as per: >> Some topics are considered architecturally >> in this document, but are not yet reflected in the implementation >> specifications. They are marked with an (*). Possibly the (*) is sufficient and the phrase you mention can be removed. Brian From nobody Wed Oct 24 19:33:22 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC41130DEC; Wed, 24 Oct 2018 19:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 PQtQ5oVrP3Xu; Wed, 24 Oct 2018 19:33:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6F7E2130DDF; Wed, 24 Oct 2018 19:33:19 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9P2X4A3026328 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Oct 2018 21:33:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_CBF99838-0FB3-48BB-8DBB-AD61531D4134"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 24 Oct 2018 21:33:04 -0500 In-Reply-To: <1db87d2f-6709-2613-0422-182989531701@gmail.com> Cc: The IESG , Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model@ietf.org, Sheng Jiang To: Brian E Carpenter References: <154042252127.6853.18391573929277125477.idtracker@ietfa.amsl.com> <1db87d2f-6709-2613-0422-182989531701@gmail.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 02:33:21 -0000 --Apple-Mail=_CBF99838-0FB3-48BB-8DBB-AD61531D4134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 24, 2018, at 8:10 PM, Brian E Carpenter = wrote: >=20 > Hi Ben, >=20 > On 2018-10-25 12:08, Ben Campbell wrote: > .... >=20 >> Thanks for the work on this. I just have one editorial comment: >>=20 >> - Several sections describe themselves as being for "informational = purposes". >> Given that this is an informational document, isn't that true of all = sections? >=20 > Those sections are among the ones tagged (*) as per: >=20 >>> Some topics are considered architecturally >>> in this document, but are not yet reflected in the implementation >>> specifications. They are marked with an (*). >=20 > Possibly the (*) is sufficient and the phrase you mention can be = removed. I think that could help. Or alternatively, put a few extra words in the = (*) sections to remind people what it means :-) Thanks! Ben. --Apple-Mail=_CBF99838-0FB3-48BB-8DBB-AD61531D4134 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvRK2AACgkQgFZKbJXz 1A1FQA/+OHWcJy6x1HDw6o4cdP1xnFJVUVz07vnk0C6CsjJs1bCahEto4uFlJ24T v6gxR5tKVxzYHoUjRWyUdKs2d0wc8isb3WwputnhpjqhLJ0T7p+VvKwqc24TuQIy J7xTAKnyAU920ms2QZEjAiNsc75ieoqrWI4z8tHFws7nQIvt+L8IY9VBBMcO6tI3 f8QfHkMEcNd+dloqQdaTSbqCq3faxlv0rrU469OjGsIHM7w8JYRXrbWgjSRptBT0 K5SfRPgj2kTwLoc810374o9SFDlgTEAjbb+hthhkDbvVtKi2IEs7Ckrcc09sYNBN 1XBGFU16OW46JO7+ca/5RJ0RFKBhJHJ/i3ssXrTV9oIQAtD9heG5qJbAQS3JG6eF TGOLDgyTuiXkDpBJGc30KgU3cUDVJstKIuujffk7rC33B7/EGRKDTuKluw3C+RHx 6AaSwu2FtirLCvWdVC1ZFSt2SQnIOACuJSMx4C78Xn75yWkSgQcvInVZvUauHxam 5bN/OvuCjkQQXUq9vymBF/LJdSkryD6fu2IkXUzVzk0Jbdj+nuK+o7xSLlLItj7V bS1M+QY4zTfP94pyTnKo8Pzv0pRWqDkj8XJf8T+K8VIIg//7kxPjpZXO/fX/XC/n w7iWzVbKJlh3bVQCrWycX7qSRVA2yjYueeejY0S3uPmln1+aaGM= =ZtQm -----END PGP SIGNATURE----- --Apple-Mail=_CBF99838-0FB3-48BB-8DBB-AD61531D4134-- From nobody Wed Oct 24 19:54:33 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E9C130E12; Wed, 24 Oct 2018 19:54:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154043606142.6984.8313509153635593599.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2018 19:54:21 -0700 Archived-At: Subject: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-reference-model-08: (with COMMENT) 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: Thu, 25 Oct 2018 02:54:21 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-anima-reference-model-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm confused here ... This document describes a first, simple, implementable phase of an Autonomic Networking solution. It is expected that the experience from this phase will be used in defining updated and extended specifications over time. Some topics are considered architecturally in this document, but are not yet reflected in the implementation specifications. They are marked with an (*). This is true now, but when this document is approved, will it be published immediately (in which case, this is "truth decay", because it becomes less true in the unchanging RFC every time a topic is reflected in implementation specifications), or will it be held until all the (*)s are stable? From nobody Wed Oct 24 20:16:44 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6735130E65; Wed, 24 Oct 2018 20:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiCWZivv5kqy; Wed, 24 Oct 2018 20:16:28 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 163CD130DCD; Wed, 24 Oct 2018 20:16:28 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id p7-v6so3185738plk.5; Wed, 24 Oct 2018 20:16:28 -0700 (PDT) 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=zAaip2tsDivqEhH9KDdUgy9yInPYh1XS4T4YgYm/dws=; b=QXLtJSvsJsHowebUQ6xs+ILFRmdqaOyMfgY0yLtXKBSrDNp2p1pvkJz21HnJqKYr5U 6Ts6v99o0Gt53cYImwElq7qvh7JAIKd5OWCN8iTlV9X3KYRmw7tVq2Nsxd5PzfoJhheg cGMgKUcf+3vVjwDT3qKr8wdUIhFhqBcZ5JZHnfgQYZ8v0EOplAGHHW13wS4++C7TovY5 ZMjtBE0Iw9X2hFZXr/PfJDIJd99uvoo7Vtn5l5M4YrAOyDuIP/XVX23NouZNnKpCSLSv 1KHzx/j9OM2D7DaP9ffjzpvyFXWF55Wwduf97gzvS7W61KXrYzNuKpkk5AWFXXnuTzam /TDw== 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=zAaip2tsDivqEhH9KDdUgy9yInPYh1XS4T4YgYm/dws=; b=UJJCP79Tg+2Pty6x7gBliCXKkax2TFfDtwcsXRHfnFKyp79IGpBgovEaAQCd7o/vK/ oslju6cGaEGC29kXchjgddQgluZtPicCx6wrGKbHyGIAEl9pULx9EDqZiqqVCvi3sPI5 54GCa0OTdvSusC7e5/ggOvC2MpPHxZqDquUQtut5K1hDY21olWtrG7YBN8FP0yVwF+Ix YfcgeFOLrtShUz0cyB2nxe6tyrmp3WXeumFi63HpuMWuJ0UmGll5fFeTbqzY7pYCuPi5 uBGJSyH6ihyH8/++mxGfivGs7InC3IV/2zM/49ffzp3Pu6NoVFZa8R6UnNLHYNL7mf0U PzoQ== X-Gm-Message-State: AGRZ1gIoTWYU4MZNY4F4fPsgOX+xnyAXQf4QX5CxsjOLXqIdZaYCjsIn wdkn9ZHyPLonyoRHF/GHCqzkpteK X-Google-Smtp-Source: AJdET5fO1clHIs+2dbIUh2sC/EumpUWiHNGYxjZp5HCOinAuTzaQ23UztQsADJ/bFRS/06/RIw3rkQ== X-Received: by 2002:a17:902:62:: with SMTP id 89-v6mr4892090pla.298.1540437387265; Wed, 24 Oct 2018 20:16:27 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id g88-v6sm10664247pfd.181.2018.10.24.20.16.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 20:16:26 -0700 (PDT) To: Spencer Dawkins , The IESG Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <154043606142.6984.8313509153635593599.idtracker@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <16137534-76d0-0c98-5169-a5efe2012f8d@gmail.com> Date: Thu, 25 Oct 2018 16:16:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154043606142.6984.8313509153635593599.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 03:16:36 -0000 Hi Spencer, On 2018-10-25 15:54, Spencer Dawkins wrote: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm confused here ... > > This document describes a first, simple, implementable phase of an > Autonomic Networking solution. It is expected that the experience > from this phase will be used in defining updated and extended > specifications over time. Some topics are considered architecturally > in this document, but are not yet reflected in the implementation > specifications. They are marked with an (*). > > This is true now, but when this document is approved, will it be published > immediately (in which case, this is "truth decay", because it becomes less true > in the unchanging RFC every time a topic is reflected in implementation > specifications), or will it be held until all the (*)s are stable? The intention is to publish it now; the (*) items are FFS (for further study) in ITU or ISO speak. Should we make the last sentence explicit?: They are marked with an (*) and are intended for further study. Brian From nobody Wed Oct 24 20:22:19 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9F0130E76; Wed, 24 Oct 2018 20:22:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N56V16Yo8KIN; Wed, 24 Oct 2018 20:22:11 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801CD130DCD; Wed, 24 Oct 2018 20:22:11 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id t22-v6so6755829lji.7; Wed, 24 Oct 2018 20:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mYZbvDerz6r2mBJjDZbTQ7yOdTQddC+ETBequ+pD2tg=; b=qtX8G+z+F7Du0G0kYFYBiosOELm0LoEA+dW61UD/P+3UEb4FTYSc9idcvJwgTDmZXp /YXCUpSERPQdc6/SkZzo/Ig4RQ+2y/VimArw5WSuoARDNK7cRUosUIvI12XbndvoZUE6 Hpu0mx50zPNTI9expvKR9AJBVAYOS40A+06YYH04MbU2LODzRIuC4zWIXjiO2R+yl05+ gqj65188WO84JaqJo/tuxZ9j6HD3h7nlh9bHrmJHRe1uxzlqKsTg8z/3TEWe9UyiL6oS WrtNZ+/Wm7dIIA4r9Wvgs2bLYnH1vh1hZrUkYu6rtw3aDeR+3cEvcNF1hwl3VRxOfbKc fXRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mYZbvDerz6r2mBJjDZbTQ7yOdTQddC+ETBequ+pD2tg=; b=GVDFTpWOlIDp97NOZJXWCk/DNdZuQiib0z+gbgbdXZM5CIi8QgiDXXGyq/LySnuiK/ Ksjzbhy5QZnui4gJaF7W2umIDW9KbGsV8us5CHDNlPFoXarjKfU+1cj5O56J5h0CAX8G NljQmo3MFe7iO+byjUaxwl1BfUdT5zI9ljasVXnshcWOGzUAJKR4L42to151gwR89xrT ONbeix6ucSXX8sGLmluIg3gzLG5juhIZi/67lEA/kNLlL2ZjAwy+5m4kuh8aQ/fG60Yt LIPvJIaqmHFHj/+o+0an+rhrEE8/Z/TkvCzCe1656cKK3O2R3hqzHKTs5EBewH5hUeLA D/Fw== X-Gm-Message-State: AGRZ1gJa6mCdfJjtNdNWzieR1UQYwFt6V605MRTvxagc8flUZTHSYiKD jCOCJ2rykwRkoXZKb7oijTntSgXENJafeLfdWWc= X-Google-Smtp-Source: AJdET5fV4Bp1P4L2zz2RlBrgmDm4yP3KdDzIXXAoYB9va/nyXcaqXq+QZTEZyuJWssxoxvySKmm7GRCGpCrZYkz5i9c= X-Received: by 2002:a2e:8545:: with SMTP id u5-v6mr3321363ljj.164.1540437729683; Wed, 24 Oct 2018 20:22:09 -0700 (PDT) MIME-Version: 1.0 References: <154043606142.6984.8313509153635593599.idtracker@ietfa.amsl.com> <16137534-76d0-0c98-5169-a5efe2012f8d@gmail.com> In-Reply-To: <16137534-76d0-0c98-5169-a5efe2012f8d@gmail.com> From: Spencer Dawkins at IETF Date: Wed, 24 Oct 2018 22:21:57 -0500 Message-ID: To: Brian E Carpenter Cc: IESG , draft-ietf-anima-reference-model@ietf.org, tte+anima@cs.fau.de, Sheng Jiang , anima-chairs@ietf.org, Anima WG Content-Type: multipart/alternative; boundary="000000000000ad2da30579051b39" Archived-At: Subject: Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 03:22:19 -0000 --000000000000ad2da30579051b39 Content-Type: text/plain; charset="UTF-8" Hi, Brian, On Wed, Oct 24, 2018 at 10:16 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi Spencer, > On 2018-10-25 15:54, Spencer Dawkins wrote: > ... > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I'm confused here ... > > > > This document describes a first, simple, implementable phase of an > > Autonomic Networking solution. It is expected that the experience > > from this phase will be used in defining updated and extended > > specifications over time. Some topics are considered architecturally > > in this document, but are not yet reflected in the implementation > > specifications. They are marked with an (*). > > > > This is true now, but when this document is approved, will it be > published > > immediately (in which case, this is "truth decay", because it becomes > less true > > in the unchanging RFC every time a topic is reflected in implementation > > specifications), or will it be held until all the (*)s are stable? > > The intention is to publish it now; the (*) items are FFS (for further > study) > in ITU or ISO speak. Should we make the last sentence explicit?: > > They are marked with an (*) and are intended for further study. > Thanks for the quick reply. I think that would be an improvement, but if it was clear that there's a reason to include them in a document being published now, that might be useful to include. If it's possible that some of these items might be significantly re-thought after further study, or even dropped, that seems unhelpful to a reader in five years. Spencer > Brian > > --000000000000ad2da30579051b39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Brian,

On Wed, Oct 24, 2018 at 10:16 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:<= br>
Hi Spencer,
On 2018-10-25 15:54, Spencer Dawkins wrote:
...

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I'm confused here ...
>
>=C2=A0 =C2=A0This document describes a first, simple, implementable pha= se of an
>=C2=A0 =C2=A0 Autonomic Networking solution.=C2=A0 It is expected that = the experience
>=C2=A0 =C2=A0 from this phase will be used in defining updated and exte= nded
>=C2=A0 =C2=A0 specifications over time.=C2=A0 Some topics are considere= d architecturally
>=C2=A0 =C2=A0 in this document, but are not yet reflected in the implem= entation
>=C2=A0 =C2=A0 specifications.=C2=A0 They are marked with an (*).
>
> This is true now, but when this document is approved, will it be publi= shed
> immediately (in which case, this is "truth decay", because i= t becomes less true
> in the unchanging RFC every time a topic is reflected in implementatio= n
> specifications), or will it be held until all the (*)s are stable?

The intention is to publish it now; the (*) items are FFS (for further stud= y)
in ITU or ISO speak. Should we make the last sentence explicit?:

They are marked with an (*) and are intended for further study.

Thanks for the quick reply.=C2=A0

I think that would be an improvement, but if it was clear that the= re's a reason to include them in a document being published now, that m= ight be useful to include.=C2=A0

If it's possi= ble that some of these items might be significantly re-thought after furthe= r study, or even dropped, that seems unhelpful to a reader in five years.= =C2=A0

Spencer
=C2=A0
=C2=A0 =C2=A0Brian

--000000000000ad2da30579051b39-- From nobody Thu Oct 25 01:43:21 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B36130E2A; Thu, 25 Oct 2018 01:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9oO94ggb5eV; Thu, 25 Oct 2018 01:43:13 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 2696D130E03; Thu, 25 Oct 2018 01:43:13 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id b203-v6so617855wme.5; Thu, 25 Oct 2018 01:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=bVw6joOzaV82+q8CJz4wVrGH1yj/MLY1GZABTCdh5Mg=; b=mWctqihF7gklPM82k0Y2QcvYvH1KJ6gOwyM+bq86/L3OTt4w7C5KrpJpnrBu+X0ehD +LaJxt9dJ3d1+EkGTklC0Muken/oRBcc7z1y6d15UDFWqt/ZvTnzVA110G4wAWvL+jqU qqzPUp9tZSbBpcM+fjGrnx50cYTy5y9a4AIJ+x60O+ijCKQH6m+HO+sXUyVbTzjIdRo1 QHWe2glW/H915jEvQNXKbNP3hS/uY7uG475rEORrtKTycraYsKGLpiW6wXHmuYysz4IU uqPQlX8sq+FM7AJfl2sEqFMaDmp5DUyyjCn1kOkEckDxcGH5Q08727P84T9+5TSyJKBO cgKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=bVw6joOzaV82+q8CJz4wVrGH1yj/MLY1GZABTCdh5Mg=; b=jTbjbsEs/oviMkb3TwHD2nKY2QXyRI6Yn8ss6fQp5TzqEIJifV0/sM41NAWwlytBS1 At2KYe0685kX6q9jO4aLVvaqUA86GbGwj7sOh7sRmpOwkHWiC08Fa7NXEjF0kn3h8LJj QiXP/1Fka3tn1NvT59JRVzYBA3feKD4C5ILToounJh/O3DygN9aS87m2ZeLJ69hIwj5u EK4dvxMoVVhinpitsdBcRSl1HN1lE8+wVNHvYiSzizTEeswECMTWaL5by5BxCrTGcrpp ui6IDTSKpWX+QpNKvSn0FnqGuqBjkWnd07UPVI2DA6+TQzUWrz8aZ7ONtr8zsjtcfDcI SnEg== X-Gm-Message-State: AGRZ1gLXuiV4AzrWxWSaA0oyPYHhfD0Eu3O4jg+pGn/J6FQBzxObjDDn g9MunGj82A3jxMuZxO1blwQ= X-Google-Smtp-Source: AJdET5c7GRgvbJDxoqTWlFM+43ZT59qD6habk31wQQ3SuR2HwlWr9TeK2EDjKGoSKYdKKVivoZqL7w== X-Received: by 2002:a1c:f417:: with SMTP id z23-v6mr905426wma.80.1540456991526; Thu, 25 Oct 2018 01:43:11 -0700 (PDT) Received: from [192.168.1.31] (anice-652-1-371-113.w83-201.abo.wanadoo.fr. [83.201.206.113]) by smtp.gmail.com with ESMTPSA id g76-v6sm437607wmd.25.2018.10.25.01.43.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 01:43:10 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Ben Campbell , Brian E Carpenter Cc: The IESG , Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model@ietf.org, Sheng Jiang References: <154042252127.6853.18391573929277125477.idtracker@ietfa.amsl.com> <1db87d2f-6709-2613-0422-182989531701@gmail.com> Message-ID: Date: Thu, 25 Oct 2018 10:43:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: fr-classic Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 08:43:15 -0000 Hi Ben, thanks for your review! Yes, we're a bit "verbose" with those topics. There was a consistent worry all through our work to distinguish phase 1 and phase 2 work, and to not let phase 2 work creep into phase 1. So we probably erred on the more "explicit" wording, trying to make REALLY sure everybody understands what's in scope for phase 1 or not. Unless you have a real concern at some specific points, I would prefer to not open those debates again. Yes, from a language point of view there is redundancy, but at least we're being very clear. Michael On 25/10/2018 04:33, Ben Campbell wrote: > >> On Oct 24, 2018, at 8:10 PM, Brian E Carpenter wrote: >> >> Hi Ben, >> >> On 2018-10-25 12:08, Ben Campbell wrote: >> .... >> >>> Thanks for the work on this. I just have one editorial comment: >>> >>> - Several sections describe themselves as being for "informational purposes". >>> Given that this is an informational document, isn't that true of all sections? >> Those sections are among the ones tagged (*) as per: >> >>>> Some topics are considered architecturally >>>> in this document, but are not yet reflected in the implementation >>>> specifications. They are marked with an (*). >> Possibly the (*) is sufficient and the phrase you mention can be removed. > I think that could help. Or alternatively, put a few extra words in the (*) sections to remind people what it means :-) > > Thanks! > > Ben. From nobody Thu Oct 25 05:01:27 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A36EC130E59; Thu, 25 Oct 2018 05:01:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154046888466.16267.13432407173386866634.idtracker@ietfa.amsl.com> Date: Thu, 25 Oct 2018 05:01:24 -0700 Archived-At: Subject: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT) 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: Thu, 25 Oct 2018 12:01:25 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-anima-reference-model-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Since draft-ietf-anima-bootstrapping-keyinfra is a normative reference in this document, IDevID seems like it should be as well. That is, it seems to be used in a normative way in the same manner as the other normative references in this document. If the document were not going to have any normative references, then I think IDevID could be informative. From nobody Thu Oct 25 05:02:19 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6135130E3D; Thu, 25 Oct 2018 05:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=J9WWGxc6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dWAMnzva 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 2mJDAe-wJh8k; Thu, 25 Oct 2018 05:02:09 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19056130E47; Thu, 25 Oct 2018 05:02:08 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id F207A21D7E; Thu, 25 Oct 2018 08:02:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 25 Oct 2018 08:02:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=m 4T/gjKhQkWztECO08/AEXjx0SCTGPwR6lTpPA15hbY=; b=J9WWGxc6aFaviblaY mThtAVTjUeWMdtJdXknNYMKfPC8wzIb6PMty2hwbO29brYltkcWt7MMJp37b1QhP jK0nL5oet54+bhgqSApH/9tyt1jYTUbHO2Mo5Mym7bjUmW4qcZCf5Ufxe0/l8iN4 r7VOhu0cQPLSDcY4XuMxd93Ws/86j1Y71t/EqXNWU88c44rkTXjdykQZdH0RUkH3 KYPQzsLnK5W1yAXRCXVJO2hwqCkJEZNPRaQpz16G4OBgQcmqZZrXhlwFLLBGq5gZ sCbE2yBFEgMzLdUfQ8E334mNi8sLv4uprwTTKtbu04youGYl5JxhDhvnR2ZH5CEW 2Uf7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=m4T/gjKhQkWztECO08/AEXjx0SCTGPwR6lTpPA15h bY=; b=dWAMnzvaeMOtj9MB8hZp15yJzMqxuW4fddVDQy+8G3vfc5xPKdop6Dw9Z rCTIhINJ7K1gZrmNssDacUGg6grVVk/cVA+mvl/W2c4wEVDzX+eSa2p3JptEwfzv xn1bzo6pPovJmSl0PcrMy1qMAffDpuL9xGnVElkQKhHvdwfRkTVr8Qqe06o2popQ fs1SF1rBTK0vJPJ/XGpr75Mnb8dI8tYHjZ9873HVZ0aO+tfLTGXmIjzJ7sCps33E DskAmWOSS4Mh2Vq0r64i+TG7l+6Czl/yXNGvkEWQCe8LwAHW5x7oOyoTom1MHNE1 WZ8H0rzSNwKE0FEKLBKRGJ6slZBew== X-ME-Sender: X-ME-Proxy: Received: from [10.82.174.167] (unknown [173.38.117.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 60706E47CB; Thu, 25 Oct 2018 08:02:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Thu, 25 Oct 2018 14:02:01 +0200 Cc: Joel Halpern , General Area Review Team , anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153931065834.7195.2686513424411133580@ietfa.amsl.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] [Gen-art] Genart telechat review of draft-ietf-anima-reference-model-08 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, 25 Oct 2018 12:02:17 -0000 Brian, > On Oct 12, 2018, at 7:22 AM, Brian E Carpenter = wrote: >=20 > Joel, >=20 > On 2018-10-12 15:17, Joel Halpern wrote: > .... >=20 >> Nits/editorial comments: >> The reference [IDevID] still appears to me to be a normative = reference. >=20 > It is normative in draft-ietf-anima-bootstrapping-keyinfra, where it = really=20 > matters. Seems like a marginal point in an Informational document, but = of course > we'll follow the IESG's guidance. Since draft-ietf-anima-bootstrapping-keyinfra is a normative reference = in this document, IDevID seems like it should be as well. That is, it = seems to be used in a normative way in the same manner as the other = normative references in this document. If the document were not going to = have any normative references, then I think IDevID could be informative. Joel, thanks for your review. I entered a No Objection ballot. Alissa >=20 >> In 3.3.3, the new parenthetical e.g. (replacing the wording "For = example", >> seems to have no closing parenthesis. >=20 > Ack. >=20 > Thanks > Brian >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Oct 25 05:45:56 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 564AD129385; Thu, 25 Oct 2018 05:45:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154047155434.16367.1235435202156100952.idtracker@ietfa.amsl.com> Date: Thu, 25 Oct 2018 05:45:54 -0700 Archived-At: Subject: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-anima-reference-model-08=3A_=28with_COMMENT=29?= 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: Thu, 25 Oct 2018 12:45:54 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-anima-reference-model-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One comment: I'm just wondering if there is any insider (or outsider) attack where an attacker node could disconnect all or some other nodes, or at least overload the network such that is would be unusable. Would be nice to see some more discussion about this in the security considerations section! From nobody Thu Oct 25 08:18:35 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4EE130DE5; Thu, 25 Oct 2018 08:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 hd58tf7B--Vw; Thu, 25 Oct 2018 08:18:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9014A127133; Thu, 25 Oct 2018 08:18:31 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9PFIJ4Q053626 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 Oct 2018 10:18:20 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: <9E85B59E-93AF-4225-B143-DC56796FCB67@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9E4862FA-E003-4254-AAA6-A25DE4EFA916"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 25 Oct 2018 10:18:18 -0500 In-Reply-To: Cc: Brian E Carpenter , The IESG , Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model@ietf.org, Sheng Jiang To: "Michael H. Behringer" References: <154042252127.6853.18391573929277125477.idtracker@ietfa.amsl.com> <1db87d2f-6709-2613-0422-182989531701@gmail.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 15:18:33 -0000 --Apple-Mail=_9E4862FA-E003-4254-AAA6-A25DE4EFA916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, My real concern is that =E2=80=9Cinformational=E2=80=9D is a term of art = in the IETF, and the use of it to label =E2=80=9Clater phase=E2=80=9D = sections is a different use than that. I will leave it to the authors to decide if that would be confusing to = the target audience. Thanks! Ben. > On Oct 25, 2018, at 3:43 AM, Michael H. Behringer = wrote: >=20 > Hi Ben, thanks for your review! >=20 > Yes, we're a bit "verbose" with those topics. There was a consistent = worry all through our work to distinguish phase 1 and phase 2 work, and = to not let phase 2 work creep into phase 1. So we probably erred on the = more "explicit" wording, trying to make REALLY sure everybody = understands what's in scope for phase 1 or not. >=20 > Unless you have a real concern at some specific points, I would prefer = to not open those debates again. Yes, from a language point of view = there is redundancy, but at least we're being very clear. >=20 > Michael >=20 >=20 > On 25/10/2018 04:33, Ben Campbell wrote: >>=20 >>> On Oct 24, 2018, at 8:10 PM, Brian E Carpenter = wrote: >>>=20 >>> Hi Ben, >>>=20 >>> On 2018-10-25 12:08, Ben Campbell wrote: >>> .... >>>=20 >>>> Thanks for the work on this. I just have one editorial comment: >>>>=20 >>>> - Several sections describe themselves as being for "informational = purposes". >>>> Given that this is an informational document, isn't that true of = all sections? >>> Those sections are among the ones tagged (*) as per: >>>=20 >>>>> Some topics are considered architecturally >>>>> in this document, but are not yet reflected in the = implementation >>>>> specifications. They are marked with an (*). >>> Possibly the (*) is sufficient and the phrase you mention can be = removed. >> I think that could help. Or alternatively, put a few extra words in = the (*) sections to remind people what it means :-) >>=20 >> Thanks! >>=20 >> Ben. >=20 --Apple-Mail=_9E4862FA-E003-4254-AAA6-A25DE4EFA916 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvR3roACgkQgFZKbJXz 1A2CbBAAlGG0FpEkNpZjltB9crsgTIPasF0kgSu1kOqp2CP7AGYBdnNRrGJEb8c2 a/O6oCHU3CNbxdGqKp3H5bWnGQnV1UoRMb/1OFKOMcQ6RvuJJnachvgzDQjqOZSp 1ojLj1o52Nj4zPs23uzy/BW5TITiWaKNOzydsesJTCRKG/wcBT6LV4seO+kHCqcB cc9vuf//8cH0wmarhQQaa8E9UalmNmXSEZyWVsErECn6jcBGVMOd2a7l7sGJhx0E km7PD0CZWJ8+MGVOBKloaRUuEtHI0sLoofxhpxUvLezGSf6NhOFjP1f2TrfIqxOk ySb80i9vRpY/LUvLm0EqbsdJr+DpfyZn0bemb1EBVWotXr/Llz1s8hGWdNSOPET5 0y5ObB21kkj26wBeAnuLD+FKXUtVJ98+RMVYV7aOZyvx+TamxkI/A/V3DOkTkZ+W To/ISquqpRhwRHbgGHBfigya3trKBoTysUS5/lJUywPls4dFg53vKGXVjdE3AQbT CD4PIcL82PkvI0Nd9dYBMGEpDTKseZ/RjHqfoB7jupebnHkwAO2Gt/FQ+A9nDqY0 wzRQy/BAEZy39/kSYjOmmIBJED2h2S73POxZcgQzKsBgIEWbxbJwGHMOilY2RFZm hUcpuvUsGhGg0h7UZS3w/QR5EXP45M3ollTX0dLtG9pU5hJdkX4= =6za1 -----END PGP SIGNATURE----- --Apple-Mail=_9E4862FA-E003-4254-AAA6-A25DE4EFA916-- From nobody Thu Oct 25 12:47:26 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4894D130EC2; Thu, 25 Oct 2018 12:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EJs7Xy6wtA9; Thu, 25 Oct 2018 12:47:16 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 8DA1E130EA3; Thu, 25 Oct 2018 12:47:16 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id d2-v6so10540014wro.7; Thu, 25 Oct 2018 12:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=AgkXJ8PHIIbTEVxvYxqKl6VJ2mdq01EMZJ7Swy9JQXM=; b=BaA35aWBD6Bk1qQV/q1at6u40IWTVsUwBeF5rvYIcnZ8s+ftH66FDXkjfzMPJw3meg MThzIUOy51AM33BqGOSgYX5BYnOn41W14jhI7GsqkoGF1dZl/NXFSmK8YqSCl89yIaKn E791HwXN0GUZheVTpc2HcKhJ841/e+zNIq4aQe29pO9LaQ3vP4o+8g/yiVCbMmKx/3Eh MaH/Crn402lzwlsmit2QX0XbAsc3XeuKUYBFly8yKfsTAagJ6JUukZ7TPpaBQ/Jm3YJG 5DnOCGwlejd8ZxJIwihLMmqA8+b8BcT5WkBK3qe9g91j6WrBR5jmeu07EeSQ0HO15NhG /Qrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=AgkXJ8PHIIbTEVxvYxqKl6VJ2mdq01EMZJ7Swy9JQXM=; b=ljZlvrgzdpCh5rv8A2af9Q/zzZmXUofEfd2C2KV43bpDSwqdWr5lzQ0bzSh81prgdE Z/uRLcYLKfHLhWmbkSme9HWXI4NFWDtwusM6JCl0ydd2NmuLVfXB5pdL82VQQXnooOAU 8+zlMRVqYBmOWkOaq6bdGrPr24j5RMcDBLjxI8iajUDd0HMdJO08TrVVeQwjpPaHMvs5 wWYDq3XMVpV0TXpbxKan/mvBnFJTak/yjSmzgbEYZ2Ws0LWB3spBMpyrw+1mCZHqx2vH vPA4msJIjG19/weFQRDvwYeZFauAkgyOlw1DBIOtU7ef3Noe7XB4FgWcFdz4D3e30+Rb Ycww== X-Gm-Message-State: AGRZ1gKUfHuDo6mVfT5OzwAYq6HlZf5qf6J5anC2CpxOzbufddGGKckv +/UbQgXODVXFS+5IY4Y9d2E= X-Google-Smtp-Source: AJdET5e3li7SbJNVReAOpb4Q/YfRWxN28jm0o4i860ipk2x5h2U6+w88XQbmNEAk92mPDgngaAtmXw== X-Received: by 2002:adf:f384:: with SMTP id m4-v6mr3174272wro.111.1540496834824; Thu, 25 Oct 2018 12:47:14 -0700 (PDT) Received: from [192.168.1.31] (anice-652-1-371-113.w83-201.abo.wanadoo.fr. [83.201.206.113]) by smtp.gmail.com with ESMTPSA id x15-v6sm10228963wrt.90.2018.10.25.12.47.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 12:47:13 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Ben Campbell Cc: Brian E Carpenter , The IESG , Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model@ietf.org, Sheng Jiang References: <154042252127.6853.18391573929277125477.idtracker@ietfa.amsl.com> <1db87d2f-6709-2613-0422-182989531701@gmail.com> <9E85B59E-93AF-4225-B143-DC56796FCB67@nostrum.com> Message-ID: Date: Thu, 25 Oct 2018 21:47:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9E85B59E-93AF-4225-B143-DC56796FCB67@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr-classic Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 19:47:18 -0000 Ah, now I understand. Thanks for clarifying. Yes, we really used it as sort of a "boiler plate" for topics that are not part of this phase of ANIMA work. I guess we just introduced (informational)^2. I'm happy to change that "boiler plate" text.  What about "This section discusses a topic for further research". I guess we can edit that when we get to the RFC Editor queue. Michael On 25/10/2018 17:18, Ben Campbell wrote: > Hi Michael, > > My real concern is that “informational” is a term of art in the IETF, and the use of it to label “later phase” sections is a different use than that. > > I will leave it to the authors to decide if that would be confusing to the target audience. > > Thanks! > > Ben. > >> On Oct 25, 2018, at 3:43 AM, Michael H. Behringer wrote: >> >> Hi Ben, thanks for your review! >> >> Yes, we're a bit "verbose" with those topics. There was a consistent worry all through our work to distinguish phase 1 and phase 2 work, and to not let phase 2 work creep into phase 1. So we probably erred on the more "explicit" wording, trying to make REALLY sure everybody understands what's in scope for phase 1 or not. >> >> Unless you have a real concern at some specific points, I would prefer to not open those debates again. Yes, from a language point of view there is redundancy, but at least we're being very clear. >> >> Michael >> >> >> On 25/10/2018 04:33, Ben Campbell wrote: >>>> On Oct 24, 2018, at 8:10 PM, Brian E Carpenter wrote: >>>> >>>> Hi Ben, >>>> >>>> On 2018-10-25 12:08, Ben Campbell wrote: >>>> .... >>>> >>>>> Thanks for the work on this. I just have one editorial comment: >>>>> >>>>> - Several sections describe themselves as being for "informational purposes". >>>>> Given that this is an informational document, isn't that true of all sections? >>>> Those sections are among the ones tagged (*) as per: >>>> >>>>>> Some topics are considered architecturally >>>>>> in this document, but are not yet reflected in the implementation >>>>>> specifications. They are marked with an (*). >>>> Possibly the (*) is sufficient and the phrase you mention can be removed. >>> I think that could help. Or alternatively, put a few extra words in the (*) sections to remind people what it means :-) >>> >>> Thanks! >>> >>> Ben. From nobody Thu Oct 25 12:54:35 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDD7130E41; Thu, 25 Oct 2018 12:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ED_sg4ycAaI; Thu, 25 Oct 2018 12:54:32 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 E1C5D127148; Thu, 25 Oct 2018 12:54:31 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id r63-v6so2722205wma.4; Thu, 25 Oct 2018 12:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HO/aMK87DfAXpC/XBJchMCVtZlAZHEcmxOQndYfCIOY=; b=vHOwvH+6TgzR1S/1qpYsrURCTKUrhjBUpY8VOSdscoIF9yba/WV/TpkA2ol033yFjD /lVnGdu4UUBqcTJVsMfDkTkEPnJ1aetn7uscCpdr+uibk/A5neJsWJW3bCsVFNEZ0jg6 1bxlbGmYHZuyPxoT2lfykZCy4MYQS4lqTl+m/Zcd0oIaaRGztysRgK2MmLFKQzgvdJL8 VBbbRV6PJBE7XM4McY+gL3w4EnPq5S9NkzVPNjV0oKAPu/N+o0YDAiVwP7iqxothHpV0 kyRqY4JmYn/k8ob0/jf0AH9APrqfWVfpS8Cad1Bh/xcVZDGcYZCUptcfXu95UcC4qwTN g/aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HO/aMK87DfAXpC/XBJchMCVtZlAZHEcmxOQndYfCIOY=; b=SU4Sk0mnzy8lzR7jHhPJ/b3ycrOk9dhy3a1p+AwDAOMDfrDE9VEvALAk721gF0BCvB Ng6a6kCMCL1t5TOqeSdL5yD1G6+NMaIjWa1PjXsVRWP46NzXkp0/vucTC7YMTYWjrjSu ion5XIgjkjNUO4nZVnBLIrpU3nDoyJjU0kdSlAH5+5HT/IXVduopM4RaCeNrKNlpTKWE ani6eHmIkAxhskUz1czXuj9tSWInL6/q3vh3N3pOaNRXB19BGo4McSH86vmFTjwzh8zv CwK/OVvMwVuRV13yBsuoR3BDJ9iKxBZT2pR/X5DuOtSLbSPQVhaEskESJQwB8S+Onmk1 ALBw== X-Gm-Message-State: AGRZ1gKnw8opRePqEKhW5TuZSvhHheSnvK40GqlgmG+Be5AP9qG3xuPn jDFIg4TPY1OINvEmnsC3A5JeuLfJ8n4= X-Google-Smtp-Source: AJdET5eoqVpYmmCH3t483wS1QF0ctoRGh17mp/Rg2Z0pZKYeUticYUyBc8YYV7/pp6tovZCL7slTOg== X-Received: by 2002:a1c:9753:: with SMTP id z80-v6mr3217052wmd.1.1540497269984; Thu, 25 Oct 2018 12:54:29 -0700 (PDT) Received: from [192.168.1.31] (anice-652-1-371-113.w83-201.abo.wanadoo.fr. [83.201.206.113]) by smtp.gmail.com with ESMTPSA id g4-v6sm6420309wrr.95.2018.10.25.12.54.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 12:54:28 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Spencer Dawkins at IETF , Brian E Carpenter Cc: IESG , draft-ietf-anima-reference-model@ietf.org, tte+anima@cs.fau.de, Sheng Jiang , anima-chairs@ietf.org, Anima WG References: <154043606142.6984.8313509153635593599.idtracker@ietfa.amsl.com> <16137534-76d0-0c98-5169-a5efe2012f8d@gmail.com> Message-ID: <80b51b66-6a6b-43a4-8bec-23c463c311ae@gmail.com> Date: Thu, 25 Oct 2018 21:54:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=utf-8 Content-Language: fr-classic Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 19:54:34 -0000
On 25/10/2018 05:21, Spencer Dawkins at IETF wrote:
Hi, Brian,

On Wed, Oct 24, 2018 at 10:16 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi Spencer,
On 2018-10-25 15:54, Spencer Dawkins wrote:
...

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm confused here ...
>
>   This document describes a first, simple, implementable phase of an
>    Autonomic Networking solution.  It is expected that the experience
>    from this phase will be used in defining updated and extended
>    specifications over time.  Some topics are considered architecturally
>    in this document, but are not yet reflected in the implementation
>    specifications.  They are marked with an (*).
>
> This is true now, but when this document is approved, will it be published
> immediately (in which case, this is "truth decay", because it becomes less true
> in the unchanging RFC every time a topic is reflected in implementation
> specifications), or will it be held until all the (*)s are stable?

The intention is to publish it now; the (*) items are FFS (for further study)
in ITU or ISO speak. Should we make the last sentence explicit?:

They are marked with an (*) and are intended for further study.

Thanks for the quick reply. 

I think that would be an improvement, but if it was clear that there's a reason to include them in a document being published now, that might be useful to include. 

If it's possible that some of these items might be significantly re-thought after further study, or even dropped, that seems unhelpful to a reader in five years.

Thanks for the thoughts, Spencer. I sort of see that we might end up with a situation where one of those (*) topics completely disappears in 5 years, in which case it might indeed look odd.

However, the RFCs come with a publication date. I think it'll then be clear that 5 years ago, we were thinking in a different direction, but that over time, the views changed.

Personally, I find it very interesting to read in older documents why certain things were done or not done, considered or not considered, even if things change later on.

So, I would trust the future reader to understand that this is context at the time of publishing the RFC, and might have changed since. And I think we could well live with that. My suggestion: Leave.

Michael


Spencer
 
   Brian


From nobody Thu Oct 25 13:02:15 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795041274D0; Thu, 25 Oct 2018 13:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DZE3bfvbB-Q; Thu, 25 Oct 2018 13:02:12 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 8600A127148; Thu, 25 Oct 2018 13:02:12 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id b203-v6so2702275wme.5; Thu, 25 Oct 2018 13:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=vZjrXfnsLM8mirZhM08wFxwOxhQMdH8mejS9y/tZ26U=; b=VR2W159ofw/4R6G8WFbXPIpwtRZa/DocPRgbOF1tY3Wb1lMjZqRthYe1GINgyEH5rK biXtdAJHqUT/Pt49cd9YwLv268CxzzZzp74ErMhK/76glcwjTTzNYUckAoBW9x54fMYi HHt6K7LmDUcGMfQq89i3KwNVQltPyHFjSmzegUIHaaC/jjkIQGnXRtu6CITsWnyfM1Zl 0/nmyJW0mrUnQAXQn0TVBFRcsgfA8KBSe/EJt2RNg1I14wa+2CJzdmGZW3NIxF1n3l3m TOEDVHCEUVG0m/1NAQaqsjhtmXm/JKP7aWiLYaSG3OpNu8Fc89CXRqw13dreLRuW8FIT vQFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=vZjrXfnsLM8mirZhM08wFxwOxhQMdH8mejS9y/tZ26U=; b=onQSLkcpUE0yxnQIvltsb3/YtDBdJb1hEfEDLMbSs3jCiTi5aHLXUJ2DWOtFU2bObq wy2f29eTSgd8R99sYOFwUIzCqnIwZktwwF/4sf8LVxuaaqcwRH8IaNHE8vc7sVugdKNS aItY3WGFkD8wTL1XtwkvHN9Zkhpudamabnq6xfNthd8/k3Ru/QpOdTd2hY4M9Vp9f4Ce KkJfVIAPhjI++QcDIIzcsT73BNpxeuyPW8v2+42W1bwl/BNj6rj+5AFm7ESOvhXCtlZn WTaYdbmnsVpzLqZk0n1taYsFAOHWRUvNo4IsOEzVWYwVslnnIrvWj6AJRkFC164Mfkgm vuxQ== X-Gm-Message-State: AGRZ1gJdShes5n7xAMzcdtzOPRhRGOVgoEnVO2MzdCdF/Qz1nOmamuLl cTfq4pOtyPzNWS2u0tiNUwl3kmYYOuE= X-Google-Smtp-Source: AJdET5cDypf/k+vwoUBOJGN+DT68ApDXZpDD7KxsWQ0JtpwNKnEts/R78qhPOF4AkomOp4uOdfcc4Q== X-Received: by 2002:a1c:8e85:: with SMTP id q127-v6mr3138037wmd.68.1540497730548; Thu, 25 Oct 2018 13:02:10 -0700 (PDT) Received: from [192.168.1.31] (anice-652-1-371-113.w83-201.abo.wanadoo.fr. [83.201.206.113]) by smtp.gmail.com with ESMTPSA id b2-v6sm6678023wru.51.2018.10.25.13.02.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 13:02:09 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Alissa Cooper , The IESG Cc: draft-ietf-anima-reference-model@ietf.org, Toerless Eckert , Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <154046888466.16267.13432407173386866634.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 25 Oct 2018 22:02:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154046888466.16267.13432407173386866634.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: fr-classic Archived-At: Subject: Re: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 20:02:15 -0000 On 25/10/2018 14:01, Alissa Cooper wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since draft-ietf-anima-bootstrapping-keyinfra is a normative reference in this > document, IDevID seems like it should be as well. That is, it seems to be used > in a normative way in the same manner as the other normative references in this > document. If the document were not going to have any normative references, then > I think IDevID could be informative. I have no problem moving IDevID to the normative references. In draft-ietf-anima-bootstrapping-keyinfra it is also in the normative section, so it would make sense to do this here as well. Will do. (Unless I hear an objection) Michael From nobody Thu Oct 25 13:35:13 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16765130E67; Thu, 25 Oct 2018 13:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 qOOrfFQcKMiO; Thu, 25 Oct 2018 13:35:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 992CC130DC3; Thu, 25 Oct 2018 13:35:09 -0700 (PDT) Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9PKY0mR006770 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 Oct 2018 15:35:00 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27] From: Ben Campbell Message-Id: <91FB1474-0A4D-4A5B-9588-7A81B21208FB@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CE954BBA-EF3A-43BB-88FC-B2CF6990F8E8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 25 Oct 2018 15:35:00 -0500 In-Reply-To: Cc: Brian E Carpenter , The IESG , Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model@ietf.org, Sheng Jiang To: "Michael H. Behringer" References: <154042252127.6853.18391573929277125477.idtracker@ietfa.amsl.com> <1db87d2f-6709-2613-0422-182989531701@gmail.com> <9E85B59E-93AF-4225-B143-DC56796FCB67@nostrum.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 20:35:11 -0000 --Apple-Mail=_CE954BBA-EF3A-43BB-88FC-B2CF6990F8E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 ""This section discusses a topic for further research=E2=80=9D sounds = good to me. Thanks! Ben. > On Oct 25, 2018, at 2:47 PM, Michael H. Behringer = wrote: >=20 > Ah, now I understand. Thanks for clarifying. Yes, we really used it as = sort of a "boiler plate" for topics that are not part of this phase of = ANIMA work. I guess we just introduced (informational)^2. >=20 > I'm happy to change that "boiler plate" text. What about "This = section discusses a topic for further research". >=20 > I guess we can edit that when we get to the RFC Editor queue. >=20 > Michael >=20 > On 25/10/2018 17:18, Ben Campbell wrote: >> Hi Michael, >>=20 >> My real concern is that =E2=80=9Cinformational=E2=80=9D is a term of = art in the IETF, and the use of it to label =E2=80=9Clater phase=E2=80=9D = sections is a different use than that. >>=20 >> I will leave it to the authors to decide if that would be confusing = to the target audience. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>> On Oct 25, 2018, at 3:43 AM, Michael H. Behringer = wrote: >>>=20 >>> Hi Ben, thanks for your review! >>>=20 >>> Yes, we're a bit "verbose" with those topics. There was a consistent = worry all through our work to distinguish phase 1 and phase 2 work, and = to not let phase 2 work creep into phase 1. So we probably erred on the = more "explicit" wording, trying to make REALLY sure everybody = understands what's in scope for phase 1 or not. >>>=20 >>> Unless you have a real concern at some specific points, I would = prefer to not open those debates again. Yes, from a language point of = view there is redundancy, but at least we're being very clear. >>>=20 >>> Michael >>>=20 >>>=20 >>> On 25/10/2018 04:33, Ben Campbell wrote: >>>>> On Oct 24, 2018, at 8:10 PM, Brian E Carpenter = wrote: >>>>>=20 >>>>> Hi Ben, >>>>>=20 >>>>> On 2018-10-25 12:08, Ben Campbell wrote: >>>>> .... >>>>>=20 >>>>>> Thanks for the work on this. I just have one editorial comment: >>>>>>=20 >>>>>> - Several sections describe themselves as being for = "informational purposes". >>>>>> Given that this is an informational document, isn't that true of = all sections? >>>>> Those sections are among the ones tagged (*) as per: >>>>>=20 >>>>>>> Some topics are considered architecturally >>>>>>> in this document, but are not yet reflected in the = implementation >>>>>>> specifications. They are marked with an (*). >>>>> Possibly the (*) is sufficient and the phrase you mention can be = removed. >>>> I think that could help. Or alternatively, put a few extra words in = the (*) sections to remind people what it means :-) >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >=20 --Apple-Mail=_CE954BBA-EF3A-43BB-88FC-B2CF6990F8E8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvSKPQACgkQgFZKbJXz 1A3XrQ/9HkF9QpjLcu4beBzyWP+wouhYfg+TAHb/RdknsvRtIX6fgbMJ/2lGdrUr CkfX4WmppKb/tqGKdKbmMnxlC6l4kHJ/al4J2oOw3hc/AJje7rWKfANr1tE909t4 Fnnauq8/C2xJKG2NqUsstyALajCXJHtL9QqEG5ioigKbor+oMUAB64oci9sCz+KO OeD+MZfLJyy7SnKo3FRJXlk9C7ufY+N1FMR+GQcwrGBbpnrCTajgJl5cThBBwV2d GcSYeGpwP/ZQKyQNm3rw9gIl7CYXN1yrnRA4vRf7DhSiCMpfHsrRqRMeAmdJULmZ CiuTVP4QJOoGInQeBUAajmfijyi1zxbOb2PtGGgN7vqakanhozrXkecfo1QbSrk7 IhtKNOqVBQAxwpcbDoXmz0BrImOoonY9VGQ1ZofgAj4i9BWS5wXeERlAr0/iuxgw 3BdrShfnUHS5eH2MD72tRMNvxL9YOa2ipDLBLs4I6hLc+LvTnITzRSuJ/UwD+Lt+ eOrAHQBcfk/v/yNAUiQqxmiGoGM0qLy32nJog5DC+tW1tfy37GbOw6FMKA/v7wye /siapUFOR7KPaxPyJIW0Z31Y3wc/14hQeUcHnqjRFxE5+DxgHxd373ujUnkgmZK0 N04giVOy2haGFzYbh2VpPiMVZ2XRHShbs7YXt6ToBvTLvKR/rfE= =KFsT -----END PGP SIGNATURE----- --Apple-Mail=_CE954BBA-EF3A-43BB-88FC-B2CF6990F8E8-- From nobody Thu Oct 25 13:36:22 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48976130DC3; Thu, 25 Oct 2018 13:36:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2dQb5KOsoZj; Thu, 25 Oct 2018 13:36:11 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 802991276D0; Thu, 25 Oct 2018 13:36:11 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id q6-v6so7106470lfh.9; Thu, 25 Oct 2018 13:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lU5PGsttOc+opk0NwgjAf5LKyUjOfCYcJqFbFLPdaVE=; b=frI7adczwjbLjDPdkOsMo2Fi6ZhjzS/uMNVebC3scfkHfDdnmQXqHz2Xm+9pKzXCYj XpGmEPYC5+fU+xBzVkxD2mKAvUOVlBIVQ/60z4bpsh2I5IVVqruKMfQynHs8er+F8POP bAtozdtKxtpYc+sVqOid/6WTlY83qnO9r2/44J3uhWIjWDbcdF+F9lHFvJXrXg9/57Vr ol7MMLclRY8/yVz/48okt5/n1MPyKtJXqhFZ/jSVaguk3MzO78zVXFyJ7e+O1aSyMcqk tJfnYaYu369UkzEF44TwNe979fA0jo/1w/QYSLl1mL2K9HNG7OGF2t28mWFYz+7doWlt kMkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lU5PGsttOc+opk0NwgjAf5LKyUjOfCYcJqFbFLPdaVE=; b=V+lw9akUhLHXKGVs/g4Qn7L7zZyQ1oL+nS7doq271WG+UkhqeSJ739gjoiGZt4TFAC 49SGa8YxR/ynUJwLdTs+JB6nynVr19Yw6lTF+0bxiRU8Ab/2qjsv4k7kN3fbRjtlMaa2 c5065iLRhC7OnKTFJFihB5i+fdInuPXPKiUeOKj/1qs71ncOrU9GL3JbgsmcIHdWLA63 AZWYjk6j5X+bNXeyuDsZYE0I4plIy1Jdsx5+EfmSkDalO/Rh3ePO6CSNWqOS3uSFaMlo +3W2ZfIyUZQtNxMH/HhfzVZJAScskzbGklsEqc4xcAMHJvo50Z/7SfN01zUSRSnWjbaC jieA== X-Gm-Message-State: AGRZ1gJ1abxBGOd1UtfgN1Ndxs/tIBiPJqucf3ZJm8Uq4ZVHnuCJcN8u IdKVaaQBcvvmsTxBqMKMB80CCUel0V/C1oF4geNDMCXF X-Google-Smtp-Source: AJdET5cuAOZtF2x6ReSxApeE6SxVjm61WjGMWYQT6jEoOltlYO1XqQYDVFca2P3BN7926vNIK3Rg+B8JK6YOu4s87Ew= X-Received: by 2002:a19:a302:: with SMTP id m2mr473709lfe.108.1540499769609; Thu, 25 Oct 2018 13:36:09 -0700 (PDT) MIME-Version: 1.0 References: <154043606142.6984.8313509153635593599.idtracker@ietfa.amsl.com> <16137534-76d0-0c98-5169-a5efe2012f8d@gmail.com> <80b51b66-6a6b-43a4-8bec-23c463c311ae@gmail.com> In-Reply-To: <80b51b66-6a6b-43a4-8bec-23c463c311ae@gmail.com> From: Spencer Dawkins at IETF Date: Thu, 25 Oct 2018 15:35:56 -0500 Message-ID: To: michael.h.behringer@gmail.com Cc: Brian E Carpenter , IESG , draft-ietf-anima-reference-model@ietf.org, tte+anima@cs.fau.de, Sheng Jiang , anima-chairs@ietf.org, Anima WG Content-Type: multipart/alternative; boundary="0000000000008b55440579138dcc" Archived-At: Subject: Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-reference-model-08: (with 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: Thu, 25 Oct 2018 20:36:15 -0000 --0000000000008b55440579138dcc Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Thu, Oct 25, 2018 at 2:54 PM Michael H. Behringer < michael.h.behringer@gmail.com> wrote: > On 25/10/2018 05:21, Spencer Dawkins at IETF wrote: > > Hi, Brian, > > On Wed, Oct 24, 2018 at 10:16 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Hi Spencer, >> On 2018-10-25 15:54, Spencer Dawkins wrote: >> ... >> >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I'm confused here ... >> > >> > This document describes a first, simple, implementable phase of an >> > Autonomic Networking solution. It is expected that the experience >> > from this phase will be used in defining updated and extended >> > specifications over time. Some topics are considered architecturally >> > in this document, but are not yet reflected in the implementation >> > specifications. They are marked with an (*). >> > >> > This is true now, but when this document is approved, will it be >> published >> > immediately (in which case, this is "truth decay", because it becomes >> less true >> > in the unchanging RFC every time a topic is reflected in implementation >> > specifications), or will it be held until all the (*)s are stable? >> >> The intention is to publish it now; the (*) items are FFS (for further >> study) >> in ITU or ISO speak. Should we make the last sentence explicit?: >> >> They are marked with an (*) and are intended for further study. >> > > Thanks for the quick reply. > > I think that would be an improvement, but if it was clear that there's a > reason to include them in a document being published now, that might be > useful to include. > > If it's possible that some of these items might be significantly > re-thought after further study, or even dropped, that seems unhelpful to a > reader in five years. > > > Thanks for the thoughts, Spencer. I sort of see that we might end up with > a situation where one of those (*) topics completely disappears in 5 years, > in which case it might indeed look odd. > > However, the RFCs come with a publication date. I think it'll then be > clear that 5 years ago, we were thinking in a different direction, but that > over time, the views changed. > > Personally, I find it very interesting to read in older documents why > certain things were done or not done, considered or not considered, even if > things change later on. > > So, I would trust the future reader to understand that this is context at > the time of publishing the RFC, and might have changed since. And I think > we could well live with that. My suggestion: Leave. > I'm sorry, I probably confused people. I wasn't questioning whether to keep or remove the information. My point was that in five years, some of them might be in implementation applications, but this RFC will still say that they aren't. If this included Brian's suggested "They are marked with an (*) and are intended for further study.", that would be more accurate, and would explain why they're being included in this document, even though the contents are somewhat speculative. And my comment is even more incredibly non-blocking now that Brian made that suggestion. I'm sure you folk will do the right thing. Spencer > Michael > > > Spencer > > >> Brian >> >> > --0000000000008b55440579138dcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,=C2=A0

On Thu, Oct 25, 2018 at 2:54 PM Michael H. Be= hringer <michael.h.behr= inger@gmail.com> wrote:
=20 =20 =20
On 25/10/2018= 05:21, Spencer Dawkins at IETF wrote:
=20
Hi, Brian,

On Wed, Oct 24, 2018 at 10:16 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi Spencer,
On 2018-10-25 15:54, Spencer Dawkins wrote:
...

> -------------------------------------------------------------= ---------
> COMMENT:
> -------------------------------------------------------------= ---------
>
> I'm confused here ...
>
>=C2=A0 =C2=A0This document describes a first, simple, implementable phase of an
>=C2=A0 =C2=A0 Autonomic Networking solution.=C2=A0 It is = expected that the experience
>=C2=A0 =C2=A0 from this phase will be used in defining up= dated and extended
>=C2=A0 =C2=A0 specifications over time.=C2=A0 Some topics= are considered architecturally
>=C2=A0 =C2=A0 in this document, but are not yet reflected= in the implementation
>=C2=A0 =C2=A0 specifications.=C2=A0 They are marked with = an (*).
>
> This is true now, but when this document is approved, will it be published
> immediately (in which case, this is "truth decay&qu= ot;, because it becomes less true
> in the unchanging RFC every time a topic is reflected in implementation
> specifications), or will it be held until all the (*)s are stable?

The intention is to publish it now; the (*) items are FFS (for further study)
in ITU or ISO speak. Should we make the last sentence explicit?:

They are marked with an (*) and are intended for further study.

Thanks for the quick reply.=C2=A0

I think that would be an improvement, but if it was clear that there's a reason to include them in a document being published now, that might be useful to include.=C2=A0

If it's possible that some of these items might be significantly re-thought after further study, or even dropped, that seems unhelpful to a reader in five years.

Thanks for the thoughts, Spencer. I sort of see that we might end up with a situation where one of those (*) topics completely disappears in 5 years, in which case it might indeed look odd.

However, the RFCs come with a publication date. I think it'll then be clear that 5 years ago, we were thinking in a different direction, but that over time, the views changed.

Personally, I find it very interesting to read in older documents why certain things were done or not done, considered or not considered, even if things change later on.

So, I would trust the future reader to understand that this is context at the time of publishing the RFC, and might have changed since. And I think we could well live with that. My suggestion: Leave.

I'm sorry, I prob= ably confused people.=C2=A0

I wasn't questioni= ng whether to keep or remove the information.=C2=A0

My point was that in five years, some of them might be in implementation = applications, but this RFC will still say that they aren't.=C2=A0
=

If this included Brian's suggested "They are m= arked with an (*) and are intended for further study.", that would be = more accurate, and would explain why they're being included in this doc= ument, even though the contents are somewhat speculative.=C2=A0
<= br>
And my comment is even more incredibly non-blocking now that = Brian made that suggestion. I'm sure you folk will do the right thing.= =C2=A0

Spencer
=C2=A0
Michael


Spencer
=C2=A0
=C2=A0 =C2=A0Brian


--0000000000008b55440579138dcc-- From nobody Tue Oct 30 07:59:45 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66706129C6A; Tue, 30 Oct 2018 07:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3sbVm0LTSIs8; Tue, 30 Oct 2018 07:59:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC06128CFD; Tue, 30 Oct 2018 07:59:41 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [14.143.0.166]) by relay.sandelman.ca (Postfix) with ESMTPS id 8AE761F8D5; Tue, 30 Oct 2018 14:59:39 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5DE33744; Tue, 30 Oct 2018 15:59:11 +0100 (CET) From: Michael Richardson To: anima-chairs@ietf.org cc: anima@ietf.org, ibagdona@gmail.com 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: Tue, 30 Oct 2018 20:29:11 +0530 Message-ID: <21819.1540911551@dooku.sandelman.ca> Archived-At: Subject: [Anima] early allocation for CT for constrained-vouchers 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, 30 Oct 2018 14:59:44 -0000 --=-=-= Content-Type: text/plain WG chairs, would you please consider asking Ignas and IANA for an early allocation for draft-ietf-anima-constrained-voucher. Specifically, https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-02#section-9.7 9.7. CoAP Content-Format Registry Additions to the sub-registry "CoAP Content-Formats", within the "CoRE Parameters" registry are needed for two media types. These can be registered either in the Expert Review range (0-255) or IETF Review range (256-9999). Media type mime type Encoding ID References ---------------------------- ----------- --------- ---- ---------- application/voucher-cms+cbor - - CBOR TBD2 [This RFC] application/voucher-cose+cbor "COSE-Sign1" CBOR TBD3 [This RFC] We are presenty starting interop testing among a few companies of this draft, and while we can use a private CT for now, it would be better if we could sort this out in the next 2 or 3 weeks! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlvYcb4ACgkQlUzhVv38 QpD38Qf/ZIjcaW/NkOCMgYwJcPbHHyQ25t5cstufQZcEtW7r8iiy7trmmmlM1QdK oxZ0g6wBsDLRCxwF3O9e1UA1KnfP4OCwmjdA92Suy8f1zUiHmOZt54uCCzx6OOA0 MlKJSFVLRXHxEi1HfSOqGokty3k1RnDPNSSdx0WbnlosPPy7Z6Gacgstz/MZTLqL 6WF2+bhgWxS4/pwAfjSguWkG2h6VPPtAbKJKqH4WJn+teuQo4HJY+aWi65VwEDjL XPT6ftcmJBTmlvmR7wtB23NKPqugOi2z5qy3CZPF1l9SFVRht/lEFQXcrgtKyqoJ uujXdMaQzhuGvzB8iislhPB17BKhhw== =ZE9x -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 31 01:01:34 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F15B130DD9; Wed, 31 Oct 2018 01:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 b6trKCMxp3qP; Wed, 31 Oct 2018 01:01:26 -0700 (PDT) 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 61E62130E1D; Wed, 31 Oct 2018 01:00:46 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8EBD920AE1713; Wed, 31 Oct 2018 08:00:42 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 31 Oct 2018 08:00:44 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.120]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Wed, 31 Oct 2018 16:00:41 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Primary ANIMA Agenda for IETF103 Thread-Index: AdRw6oiwlIYLllTAQAm57g34FDZE3g== Date: Wed, 31 Oct 2018 08:00:40 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B929023D21C@NKGEML515-MBS.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_5D36713D8A4E7348A7E10DF7437A4B929023D21CNKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Primary ANIMA Agenda for IETF103 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, 31 Oct 2018 08:01:28 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B929023D21CNKGEML515MBSchi_ 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/103/materials/agenda-103-anima Please no hesitate to contact the chair for any miss or mistake. Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B929023D21CNKGEML515MBSchi_ 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 ch=
anged.
=
 
https://d=
atatracker.ietf.org/meeting/103/materials/agenda-103-anima
=
 
=
Please no hesitate to contact the chair for any miss or mistake.=

=
 
=
Regards,
=
 
=
Sheng

 

--_000_5D36713D8A4E7348A7E10DF7437A4B929023D21CNKGEML515MBSchi_--