From nobody Fri Feb 1 01:19:07 2019 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A22212875B; Fri, 1 Feb 2019 01:19:00 -0800 (PST) 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, 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 E6VrP2H0kmjq; Fri, 1 Feb 2019 01:18:58 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id CB4CD126C7E; Fri, 1 Feb 2019 01:18:57 -0800 (PST) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id x119IvIo020249; Fri, 1 Feb 2019 18:18:57 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 22849EA8377; Fri, 1 Feb 2019 18:18:57 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 180B1EA7FB8; Fri, 1 Feb 2019 18:18:57 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 06B95400976; Fri, 1 Feb 2019 18:18:57 +0900 (JST) References: <000601d4ba0e$86257fe0$92707fa0$@hco.ntt.co.jp> From: Shunsuke Homma X-Forwarded-Message-Id: <000601d4ba0e$86257fe0$92707fa0$@hco.ntt.co.jp> Message-ID: <5600d4e0-32a3-9e7c-bbeb-85ed1107906c@lab.ntt.co.jp> Date: Fri, 1 Feb 2019 18:19:30 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <000601d4ba0e$86257fe0$92707fa0$@hco.ntt.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit To: netslices@ietf.org, rtgwg@ietf.org, opsawg@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [OPSAWG] Fwd: New Version Notification for draft-homma-slice-provision-models-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 09:19:01 -0000 Hi, We wrote a new draft related to network slice provision as below. We believe that it will be help for clarifying the scope and architecture outline of network slicing. Your review and feedback would be greatly appreciated. Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-homma-slice-provision-models-00.txt Date: Fri, 01 Feb 2019 18:14:24 +0900 From: Shunsuke Homma To: homma.shunsuke@lab.ntt.co.jp A new version of I-D, draft-homma-slice-provision-models-00.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-homma-slice-provision-models Revision: 00 Title: Network Slice Provision Models Document date: 2019-02-01 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-homma-slice-provision-models-00.txt Status: https://datatracker.ietf.org/doc/draft-homma-slice-provision-models/ Htmlized: https://tools.ietf.org/html/draft-homma-slice-provision-models-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-homma-slice-provision-models Abstract: Network slicing is an approach to provide separate virtual network based on service requirements. It's a fundamental concept of the 5G, and the architecture and specification is under standardization in several organizations. However, the definitions and scopes of network slicing vary to some degree from one organization to another. This document provides classification of provisioning models of network slice for clarifying the differences on the definitions and scopes. 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 From nobody Sat Feb 2 00:19:22 2019 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE263130EBF; Sat, 2 Feb 2019 00:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ARo-MzMvu1VS; Sat, 2 Feb 2019 00:19:16 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.221]) by ietfa.amsl.com (Postfix) with ESMTP id 69BEC124BF6; Sat, 2 Feb 2019 00:19:09 -0800 (PST) HMM_SOURCE_IP: 172.18.0.80:54322.1454508020 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-106.121.74.30 (unknown [172.18.0.80]) by chinatelecom.cn (HERMES) with SMTP id 2893E28008E; Sat, 2 Feb 2019 16:19:04 +0800 (CST) X-189-SAVE-TO-SEND: sunqiong.bri@chinatelecom.cn Received: from EHLO ip<106.121.74.30> ([172.18.0.80]) by App0022 with ESMTP id b38a9e02-53ba-4761-a336-ff229e02b4a1 for draft-sun-opsawg-sdwan-service-model@ietf.org; Sat Feb 2 16:19:06 2019 X-filter-score: filter<0> X-Real-From: sunqiong.bri@chinatelecom.cn X-Receive-IP: 172.18.0.80 X-MEDUSA-Status: 0 From: To: "'Linda Dunbar'" , , "'Charles Eckel \(eckelcu\)'" Cc: Date: Sat, 2 Feb 2019 16:19:02 +0800 Message-ID: <000001d4bacf$f6a74160$e3f5c420$@chinatelecom.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D4BB13.04CBB9E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdS6z8uO9ylFUhU/RyumKKNabQQLFg== Content-Language: zh-cn Archived-At: Subject: Re: [OPSAWG] pros & cons of draft-sun-opsawg-sdwan-service-model aligning with MEF SD-WAN or ONUG SD-WAN X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 08:19:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D4BB13.04CBB9E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, Linda =20 Thank you for your detailed analysis of the ONUG and MEF SD-WAN service models. This is very helpful. =20 We are proposing to define the SD-WAN service model in the IETF so that = the SD-WAN model can be used together with L3SM and L2SM for consistent = modeling methods. =20 About the relationship of the models designed by MEF and ONUG, we are considering the following approaches: 1. Add text to reference ONUG SD-WAN architecture and align with ONUG service models. 1) The Path service model is a common policy model which also applies to intra-domain, and our draft has a similar model called path selection policy. 2) The Reachability service model will be referenced for interworking between different vendor domains.=20 =20 2. Add text for reference and analysis when MEF publish the SD-WAN specification. =20 =20 =B7=A2=BC=FE=C8=CB: OPSAWG =B4=FA=B1=ED Linda = Dunbar =B7=A2=CB=CD=CA=B1=BC=E4: 2019=C4=EA1=D4=C27=C8=D5 10:23 =CA=D5=BC=FE=C8=CB: opsawg@ietf.org; Charles Eckel (eckelcu) = =B3=AD=CB=CD: draft-sun-opsawg-sdwan-service-model@ietf.org =D6=F7=CC=E2: [OPSAWG] pros & cons of = draft-sun-opsawg-sdwan-service-model aligning with MEF SD-WAN or ONUG SD-WAN =20 I watched the video recording of IETF 103 OPSAwg session over the = Christmas break and want to add some comments (as I missed attending the session = in Bangkok due to conflicts).=20 =20 Both MEF and ONUG have SD-WAN related initiatives. As Charles Eckel = stated in the opsawg IETF 103 session that MEF is more from service = provider=A1=AFs perspective, whereas ONUG is more from single vendor=A1=AFs perspective. = =20 ONUG has Path Service model and Reachability service models, the purpose = of the Path Service model is to normalize the service specification, so = that it could be implemented through any vendor=A1=AFs controller (via API = support). Same for Reachability Service. The goal is to be able to configure = services within a vendor domain through a single API, with defined service = behaviors. =20 So the requirements from MEF and ONUG are for different entity, I am not sure if we can create one service models for both MEF and ONUG.=20 =20 Reading through the draft-sun-opsawg-sdwan-service-model, I feel it is = more from service providers=A1=AF perspective, i.e. more aligned with MEF.=20 =20 I agree with AD Ignas=A1=AF saying that we need to define service model = per ONUG user community provided requirement.=20 The problem is that the requirements from ONUG User community are very = high level (e.g. =A1=B0aggregate paths from N service providers to access = hybrid clouds=A1=B1), which can=A1=AFt be directly translated to service model requirements. Engineers, like IETF community, have to bear the burden to derive the detailed executable service model from the high level = requirement from User Community. I think a more realistic method is to bring the = IETF service modes to MEF and ONUG to be validated. =20 =20 Best Regards,=20 Linda Dunbar ------=_NextPart_000_0001_01D4BB13.04CBB9E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, = Linda

 

Thank you = for your detailed analysis of the ONUG and MEF SD-WAN service models. = This is very helpful.

 

We are = proposing to define the SD-WAN service model in the IETF so that the = SD-WAN model can be used together with L3SM and L2SM for consistent = modeling methods.

 

About the = relationship of the models designed by MEF and ONUG, we are considering = the following approaches:

1. Add text = to reference ONUG SD-WAN architecture and align with ONUG service = models.

1) The Path service model is a common policy = model which also applies to intra-domain, and our draft has a similar = model called path selection policy.

2) The = Reachability service model will be referenced for interworking between = different vendor domains.

 

2. Add text = for reference and analysis when MEF publish the SD-WAN = specification.

 <= /p>

 <= /p>

=B7=A2=BC=FE=C8=CB: OPSAWG <opsawg-bounces@ietf.org> = =B4=FA=B1=ED = Linda = Dunbar
=B7=A2=CB=CD=CA=B1=BC=E4: 2019=C4=EA1=D4=C27=C8=D5 10:23
=CA=D5=BC=FE=C8=CB: opsawg@ietf.org; Charles = Eckel (eckelcu) <eckelcu@cisco.com>
=B3=AD=CB=CD: = draft-sun-opsawg-sdwan-service-model@ietf.org
=D6=F7=CC=E2: [OPSAWG] pros & = cons of draft-sun-opsawg-sdwan-service-model aligning with MEF SD-WAN or = ONUG SD-WAN

 

I watched the video recording of = IETF 103 OPSAwg session over the Christmas break and want to add some = comments (as I missed attending the session in Bangkok due to = conflicts).

 

Both MEF and ONUG have SD-WAN related initiatives. As = Charles Eckel stated in the opsawg IETF 103 session that MEF is more = from service provider=A1=AFs perspective, whereas ONUG is more from = single vendor=A1=AFs perspective.

 

ONUG has Path Service model and = Reachability service models, the purpose of the Path Service model is to = normalize the service specification, so that it could be implemented = through any vendor=A1=AFs controller (via API support).  Same for = Reachability Service.  The goal is to be able to configure services = within a vendor domain through a single API, with defined service = behaviors.

 

So the requirements from MEF and ONUG are for different = entity, I am not sure if we can create one service models for both MEF = and ONUG.

 

Reading through the draft-sun-opsawg-sdwan-service-model, I = feel it is more from service providers=A1=AF perspective, i.e. more = aligned with MEF.

 

I agree with AD Ignas=A1=AF saying that we need to define = service model per ONUG user community provided requirement. =

The = problem is that the requirements from ONUG User community are very high = level (e.g. =A1=B0aggregate paths from N service providers to access = hybrid clouds=A1=B1), which can=A1=AFt be directly translated to service = model requirements. Engineers, like IETF community, have to bear the = burden to derive the detailed executable service model from the high = level requirement from User Community. I think a more realistic method = is to bring the IETF service modes to MEF and ONUG to be validated. =   

 

Best Regards,

Linda = Dunbar

------=_NextPart_000_0001_01D4BB13.04CBB9E0-- From nobody Sat Feb 2 18:23:48 2019 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9871294FA; Sat, 2 Feb 2019 18:23:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ibagdona@gmail.com, opsawg@ietf.org, zhoutianran@huawei.com, opsawg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154916062589.18396.11025718766811788773.idtracker@ietfa.amsl.com> Date: Sat, 02 Feb 2019 18:23:45 -0800 Archived-At: Subject: [OPSAWG] opsawg - New Meeting Session Request for IETF 104 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 02:23:46 -0000 A new meeting session request has just been submitted by Tianran Zhou, a Chair of the opsawg working group. --------------------------------------------------------- Working Group Name: Operations and Management Area Working Group Area Name: Operations and Management Area Session Requester: Tianran Zhou Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: nvo3 ippm rtgwg netconf netmod Second Priority: idr detnet People who must be present: Warren "Ace" Kumari Joe Clarke Tianran Zhou Ignas Bagdonas Resources Requested: Special Requests: PLEASE NOTE: Combined OpsAWG / OpsAREA --------------------------------------------------------- From nobody Thu Feb 14 06:49:12 2019 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A28131069 for ; Thu, 14 Feb 2019 06:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 gREXmcmmNeQu for ; Thu, 14 Feb 2019 06:49:08 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 C0455130F0E for ; Thu, 14 Feb 2019 06:49:07 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id f16so6363894wmh.4 for ; Thu, 14 Feb 2019 06:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=i6BYb7n+xv5TuN5kyYfijEIKgTIB/h54eePWvysn9wM=; b=ju+2EC/auaKWSGetEE7/kflrJO1SQo3wGYFYbEQ0chBwABTDuufFMHXoKmjqd6B/ln G1Ezkqa+HYE+3gSKSw2iCIk/VEjUcX7NGDtAZsGTnfx/LWf9oY0D2to2rA42mzmCtp2p rGli+ysGZBcvOxn367APUWixshqGE2euoDlZBtUlG15QD3bHl3jJXanRlCXH8jqnJ47n BeW0ZUTk+Z1TYSvvVjEbsvojLpPGweTwVk+rV81aHnVZe4MpIGutOcMdCQYgagJw9mEs zt5mt4GfBGbwOLleiQh6IBWV2N2Yw6BQDpx0GFOT1EMBIv0G7lecJWiqv0des1QpShkA bI8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=i6BYb7n+xv5TuN5kyYfijEIKgTIB/h54eePWvysn9wM=; b=ZIx/NwkMhqqGEoBPK1Gt4L9HUllIyiwO0/NBwvv1CmeLv05rR/Lv8eRn74HPH4W8uR J3/PGcZl0Ga71n99IRrdOinA0kmrfvmN7AguPe1PRK+j0xJumWxlaOiSJR0upDRhZq+u EOT6M6ULJ9B31A1tqH9JUhL6jQ6Ipd5awkyVGnS3FnU0Z3VXgS2Fgm5KP/GPSb8N1Szh zabYlzEych90EH1ALuox+IEpdEeGM5eZvoTcD+BgPMV5Jhz4u1TsC3hbH0GgbSowFl6M phtX9p9SjlYJ3mUjJIsDrW0o+IWVPOt+mv9yhGl7wTMaYSgURYc0kiWu6VL2q+8KOJ6W OPhQ== X-Gm-Message-State: AHQUAuZthCikhSUNzt+4Cr16b3lY6lj7EsOL96LfALRh62Itv9DOXDBJ K/3MYjO8+WNA3woXGgDLlLx5+oRB2sMwI+ERdmnZbw7p X-Google-Smtp-Source: AHgI3IZ+kaxIrNukHnKrIjDlVi/O26KQ1tHHnkAljxA4ifReH3aavqcf5AT0IXQw8nyvWlmbM4JX6XnqfB/jNPu9PHU= X-Received: by 2002:a1c:cf43:: with SMTP id f64mr2269906wmg.61.1550155745342; Thu, 14 Feb 2019 06:49:05 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Thu, 14 Feb 2019 09:48:29 -0500 Message-ID: To: opsawg@ietf.org Content-Type: multipart/alternative; boundary="0000000000008c553c0581dbc200" Archived-At: Subject: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 14:49:11 -0000 --0000000000008c553c0581dbc200 Content-Type: text/plain; charset="UTF-8" Hi all, So, I'd like to discuss this document: https://tools.ietf.org/html/draft-wkumari-opsawg-sdi-03 (I've had it kicking around since 2016, but haven't had time to push it). It is a very simple addition to the "normal" netboot process which many devices do, which allows "secure" installing of devices in places like exchange points, where you don't necessarily have full physical security. It is optimized for simplicity / ease of implementation in specific use cases, instead of being the all-singing-all-dancing-wizz-bang solution to everything. I'm using the Cisco autoboot-type functionality as an example, because it is the one which many people are familiar with[0], but it applies to basically all network device bootstrapping. At the 50'000ft level: It would be nice to be able to install devices in POPs, etc without having to: a: ship a person to configure the device b: leave an "open" Ethernet port where anyone with a laptop can plugin, get an IP and download device configs c: mail a USB drive with a proto-config or d: ship devices pre-configured from the vendor. This document provides a simple modification to the netboot / autoboot process which many vendors implement -- when a device is manufactured, and the serial number is programmed, it also gets a key-pair placed on it (this already happen for many manufacturers, some in TPM, some not). The vendor will now also publish the *public* part on a keyserver, indexed by serial number. When I buy a device and get it drop-shipped to the POP, the vendor (VAR, reseller) says "Thanks, here is the invoice, and the Serial Number is SN17345". While the device is in transit, I go fetch https://vendor.example.com/keys/SN17345.pem. I then encrypt the new device's config file with the key in that cert. When the device actually arrives at the POP, smart-hands unpacks it, racks and stacks it, and plugs it into the circuit which I've installed already had installed. The device does it's regular netboot - this is usually something like "get IP via DHCP, use DHCP option 66, 67, 150 to find the config server, download and install the named config". What this document add is: "If the config file is completely unparsable, use your private key to try decrypt it. If it is now readable, install and continue". Once the device boots and connects to the network you can delete the device keys, regenerate them, $whatever (personally I'd likely leave them so I can reuse this function in the future, but your choice). This is specifically designed to solve the common problem of: I'd like to be able to use netboot to install in a POP / IXP / PE location, where I can install a circuit, and provide DHCP, but where I don't want random smart-hands / customer to be able to plugin to the circuit and download my config files with my TACACS secret, SSH keys, $whatever (inquisitive customers can plugin, and can download files, but they will be encrypted and of no use to them). Common questions / answers: 1: Yes, this doesn't provide perfect security - a malicious customer / installer could install malicious firmware on the router before plugging it in, and / or could extract the private keys from the router flash, etc -- but this is basically always true once you ship a device to a location where you don't have physical control. 2: Yes, this isn't full "Internet" auto-install - you have to have a circuit on your network already installed - but you are likely to already have this, otherwise why are you installing the router? :-) It isn't intended to replace full autonomous networking, etc - 'tis designed to be dead simple and easy. 3: Yes, many vendors already sell a wizbang solution / appliance to do $magic - but this requires many more things to manage, is often expensive, and requires complex integration. 4: Yes, you *could* instead have a "base config" which the device loads, and then you SSH in, somehow ensure that it is the "right" device and put the rest of your config on... and you (probably) should - this provides an additional layer of protection for the base config. 5: Yes, this doesn't solve world hunger. Never said it does. Thoughts, comments? (please keep in mind the use-cases when commenting - again, it isn't intending to replace the next sexy thing, just be a simple addition to existing, deployed and used functionality). W [0]: Mentioning this so people don't see TFTP and assume that is the only option. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000008c553c0581dbc200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

So, I'd like to discuss this document:=C2=A0https://tools.iet= f.org/html/draft-wkumari-opsawg-sdi-03=C2=A0(I've had it kicking ar= ound since 2016, but haven't had time to push it).

It is a very si= mple addition to the "normal" netboot process which many devices = do, which allows "secure" installing of devices in places like ex= change points, where you don't necessarily have full physical security.= It is optimized for simplicity / ease of implementation in specific use ca= ses, instead of being the all-singing-all-dancing-wizz-bang solution to eve= rything. I'm using the Cisco autoboot-type functionality as an example,= because it is the one which many people are familiar with[0], but it appli= es to basically all network device bootstrapping.=C2=A0


At the 50= '000ft level:
It would be nice to be able to install devices in POPs, e= tc without having to:
a: ship a person to configure the device
b: leave an = "open" Ethernet port where anyone with a laptop can plugin, get a= n IP and download device configs
c: mail a USB drive with a proto-config or=
d: ship devices pre-configured from the vendor.

This document provide= s a simple modification to the netboot / autoboot process which many vendor= s implement -- when a device is manufactured, and the serial number is prog= rammed, it also gets a key-pair placed on it (this already happen for many = manufacturers, some in TPM, some not). The vendor will now also publish the= *public* part on a keyserver, indexed by serial number.

When I buy a = device and get it drop-shipped to the POP, the vendor (VAR, reseller) says = "Thanks, here is the invoice, and the Serial Number is SN17345". = While the device is in transit, I go fetch https://vendor.example.com/keys/S= N17345.pem. I then encrypt the new device's config file with the ke= y in that cert.

When the device actually arrives at the POP, smart-han= ds unpacks it, racks and stacks it, and plugs it into the circuit which I&#= 39;ve installed already had installed. The device does it's regular net= boot - this is usually something like "get IP via DHCP, use DHCP optio= n 66, 67, 150 to find the config server, download and install the named con= fig". What this document add is: "If the config file is completel= y unparsable, use your private key to try decrypt it. If it is now readable= , install and continue". Once the device boots and connects to the net= work you can delete the device keys, regenerate them, $whatever (personally= I'd likely leave them so I can reuse this function in the future, but = your choice).



This is specifically designed to solve the com= mon problem of: I'd like to be able to use netboot to install in a POP = / IXP / PE location, where I can install a circuit, and provide DHCP, but w= here I don't want random smart-hands / customer to be able to plugin to= the circuit and download my config files with my TACACS secret, SSH keys, = $whatever (inquisitive customers can plugin, and can download files, but th= ey will be encrypted and of no use to them).

Common questions / answer= s:=C2=A0
1: Yes, this doesn't provide perfect security - a malicious cu= stomer / installer could install malicious firmware on the router before pl= ugging it in, and / or could extract the private keys from the router flash= , etc -- but this is basically always true once you ship a device to a loca= tion where you don't have physical control.=C2=A0

2: Yes, this is= n't full "Internet" auto-install - you have to have a circuit= on your network already installed - but you are likely to already have thi= s, otherwise why are you installing the router? :-) It isn't intended t= o replace full autonomous networking, etc - 'tis designed to be dead si= mple and easy.=C2=A0

3: Yes, many vendors already sell a wizbang solut= ion / appliance to do $magic - but this requires many more things to manage= , is often expensive, and requires complex integration.

4: Yes, you *c= ould* instead have a "base config" which the device loads, and th= en you SSH in, somehow ensure that it is the "right" device and p= ut the rest of your config on... and you (probably) should - this provides = an additional layer of protection for the base config.=C2=A0

5: Yes, t= his doesn't solve world hunger. Never said it does.


Thoughts,= comments? (please keep in mind the use-cases when commenting - again, it i= sn't intending to replace the next sexy thing, just be a simple additio= n to existing, deployed and used functionality).
W=C2=A0

[0]: Mentioni= ng this so people don't see TFTP and assume that is the only option.
--
I don't think the execution is = relevant when it was obviously a bad idea in the first place.
This is li= ke putting rabid weasels in your pants, and later expressing regret at havi= ng chosen those particular rabid weasels and that pair of pants.
=C2=A0 = =C2=A0---maf
--0000000000008c553c0581dbc200-- From nobody Thu Feb 14 11:00:07 2019 Return-Path: <01000168ed613c76-cc8ec844-d1ee-47cc-ad5e-14270d5ea3cc-000000@amazonses.watsen.net> X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3D112426A for ; Thu, 14 Feb 2019 11:00:05 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 ZLBRTAGwydSK for ; Thu, 14 Feb 2019 11:00:01 -0800 (PST) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22CD1200ED for ; Thu, 14 Feb 2019 11:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1550170799; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=bK56IVFUGZMzt8yWIBxNmhy2MRyl2VM6BOQj1peqm+g=; b=GOyEhwXm57C1sWfwO2l+IFe++7WmzyUJv9lVTen1w+kEpv/g2fzPE2+LPk0x17iv p3bggwaIzFFcI8z+Xbsr/J7/m72hus889qS3Cj8EnaH9/hp3xltUDFrdUc5Y0lzPRg7 9PbGfndXGvj9uJl4nlJGZxEc4Ge8Xrut9XSjOtzY= From: Kent Watsen Message-ID: <01000168ed613c76-cc8ec844-d1ee-47cc-ad5e-14270d5ea3cc-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EAA25CE9-B0F9-47D0-8150-373305B15CAA" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 14 Feb 2019 18:59:59 +0000 In-Reply-To: Cc: opsawg@ietf.org To: Warren Kumari References: X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.14-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:00:05 -0000 --Apple-Mail=_EAA25CE9-B0F9-47D0-8150-373305B15CAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Warren, Have you looked at = https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch? = Currently in RFC Editor queue. Kent > On Feb 14, 2019, at 9:48 AM, Warren Kumari wrote: >=20 > Hi all, >=20 > So, I'd like to discuss this document: = https://tools.ietf.org/html/draft-wkumari-opsawg-sdi-03 = (I've had it = kicking around since 2016, but haven't had time to push it). >=20 > It is a very simple addition to the "normal" netboot process which = many devices do, which allows "secure" installing of devices in places = like exchange points, where you don't necessarily have full physical = security. It is optimized for simplicity / ease of implementation in = specific use cases, instead of being the = all-singing-all-dancing-wizz-bang solution to everything. I'm using the = Cisco autoboot-type functionality as an example, because it is the one = which many people are familiar with[0], but it applies to basically all = network device bootstrapping.=20 >=20 >=20 > At the 50'000ft level: > It would be nice to be able to install devices in POPs, etc without = having to: > a: ship a person to configure the device > b: leave an "open" Ethernet port where anyone with a laptop can = plugin, get an IP and download device configs > c: mail a USB drive with a proto-config or > d: ship devices pre-configured from the vendor. >=20 > This document provides a simple modification to the netboot / autoboot = process which many vendors implement -- when a device is manufactured, = and the serial number is programmed, it also gets a key-pair placed on = it (this already happen for many manufacturers, some in TPM, some not). = The vendor will now also publish the *public* part on a keyserver, = indexed by serial number. >=20 > When I buy a device and get it drop-shipped to the POP, the vendor = (VAR, reseller) says "Thanks, here is the invoice, and the Serial Number = is SN17345". While the device is in transit, I go fetch = https://vendor.example.com/keys/SN17345.pem = . I then encrypt the new = device's config file with the key in that cert. >=20 > When the device actually arrives at the POP, smart-hands unpacks it, = racks and stacks it, and plugs it into the circuit which I've installed = already had installed. The device does it's regular netboot - this is = usually something like "get IP via DHCP, use DHCP option 66, 67, 150 to = find the config server, download and install the named config". What = this document add is: "If the config file is completely unparsable, use = your private key to try decrypt it. If it is now readable, install and = continue". Once the device boots and connects to the network you can = delete the device keys, regenerate them, $whatever (personally I'd = likely leave them so I can reuse this function in the future, but your = choice). >=20 >=20 >=20 > This is specifically designed to solve the common problem of: I'd like = to be able to use netboot to install in a POP / IXP / PE location, where = I can install a circuit, and provide DHCP, but where I don't want random = smart-hands / customer to be able to plugin to the circuit and download = my config files with my TACACS secret, SSH keys, $whatever (inquisitive = customers can plugin, and can download files, but they will be encrypted = and of no use to them). >=20 > Common questions / answers:=20 > 1: Yes, this doesn't provide perfect security - a malicious customer / = installer could install malicious firmware on the router before plugging = it in, and / or could extract the private keys from the router flash, = etc -- but this is basically always true once you ship a device to a = location where you don't have physical control.=20 >=20 > 2: Yes, this isn't full "Internet" auto-install - you have to have a = circuit on your network already installed - but you are likely to = already have this, otherwise why are you installing the router? :-) It = isn't intended to replace full autonomous networking, etc - 'tis = designed to be dead simple and easy.=20 >=20 > 3: Yes, many vendors already sell a wizbang solution / appliance to do = $magic - but this requires many more things to manage, is often = expensive, and requires complex integration. >=20 > 4: Yes, you *could* instead have a "base config" which the device = loads, and then you SSH in, somehow ensure that it is the "right" device = and put the rest of your config on... and you (probably) should - this = provides an additional layer of protection for the base config.=20 >=20 > 5: Yes, this doesn't solve world hunger. Never said it does. >=20 >=20 > Thoughts, comments? (please keep in mind the use-cases when commenting = - again, it isn't intending to replace the next sexy thing, just be a = simple addition to existing, deployed and used functionality). > W=20 >=20 > [0]: Mentioning this so people don't see TFTP and assume that is the = only option. >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad = idea in the first place. > This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants. > ---maf > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail=_EAA25CE9-B0F9-47D0-8150-373305B15CAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Warren,

Have you = looked at https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch?<= /a>

Currently in RFC = Editor queue.

Kent


On Feb = 14, 2019, at 9:48 AM, Warren Kumari <warren@kumari.net> = wrote:

Hi all,

So, I'd like to discuss this = document: https://tools.ietf.org/html/draft-wkumari-opsawg-sdi-03&nbs= p;(I've had it kicking around since 2016, but haven't had time to push = it).

It is a = very simple addition to the "normal" netboot process which many devices = do, which allows "secure" installing of devices in places like exchange = points, where you don't necessarily have full physical security. It is = optimized for simplicity / ease of implementation in specific use cases, = instead of being the all-singing-all-dancing-wizz-bang solution to = everything. I'm using the Cisco autoboot-type functionality as an = example, because it is the one which many people are familiar with[0], = but it applies to basically all network device = bootstrapping. 


At the 50'000ft = level:
It would be nice to be able to = install devices in POPs, etc without having to:
a: ship = a person to configure the device
b: leave an "open" Ethernet = port where anyone with a laptop can plugin, get an IP and download = device configs
c: mail a USB drive with a = proto-config or
d: ship devices pre-configured = from the vendor.

This = document provides a simple modification to the netboot / autoboot = process which many vendors implement -- when a device is manufactured, = and the serial number is programmed, it also gets a key-pair placed on = it (this already happen for many manufacturers, some in TPM, some not). = The vendor will now also publish the *public* part on a keyserver, = indexed by serial number.

When I = buy a device and get it drop-shipped to the POP, the vendor (VAR, = reseller) says "Thanks, here is the invoice, and the Serial Number is = SN17345". While the device is in transit, I go fetch https://vendor.example.com/keys/SN17345.pem. I then = encrypt the new device's config file with the key in that = cert.

When = the device actually arrives at the POP, smart-hands unpacks it, racks = and stacks it, and plugs it into the circuit which I've installed = already had installed. The device does it's regular netboot - this is = usually something like "get IP via DHCP, use DHCP option 66, 67, 150 to = find the config server, download and install the named config". What = this document add is: "If the config file is completely unparsable, use = your private key to try decrypt it. If it is now readable, install and = continue". Once the device boots and connects to the network you can = delete the device keys, regenerate them, $whatever (personally I'd = likely leave them so I can reuse this function in the future, but your = choice).



This is = specifically designed to solve the common problem of: I'd like to be = able to use netboot to install in a POP / IXP / PE location, where I can = install a circuit, and provide DHCP, but where I don't want random = smart-hands / customer to be able to plugin to the circuit and download = my config files with my TACACS secret, SSH keys, $whatever (inquisitive = customers can plugin, and can download files, but they will be encrypted = and of no use to them).

Common = questions / answers: 
1: Yes, this doesn't provide = perfect security - a malicious customer / installer could install = malicious firmware on the router before plugging it in, and / or could = extract the private keys from the router flash, etc -- but this is = basically always true once you ship a device to a location where you = don't have physical control. 

2: Yes, = this isn't full "Internet" auto-install - you have to have a circuit on = your network already installed - but you are likely to already have = this, otherwise why are you installing the router? :-) It isn't intended = to replace full autonomous networking, etc - 'tis designed to be dead = simple and easy. 

3: Yes, = many vendors already sell a wizbang solution / appliance to do $magic - = but this requires many more things to manage, is often expensive, and = requires complex integration.

4: Yes, = you *could* instead have a "base config" which the device loads, and = then you SSH in, somehow ensure that it is the "right" device and put = the rest of your config on... and you (probably) should - this provides = an additional layer of protection for the base config. 

5: Yes, this doesn't solve = world hunger. Never said it does.


Thoughts, comments? (please = keep in mind the use-cases when commenting - again, it isn't intending = to replace the next sexy thing, just be a simple addition to existing, = deployed and used functionality).
W 

[0]: Mentioning this so people = don't see TFTP and assume that is the only option.

--
I don't think the execution is = relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later = expressing regret at having chosen those particular rabid weasels and = that pair of pants.
   ---maf
_______________________________________________
OPSAWG = mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

= --Apple-Mail=_EAA25CE9-B0F9-47D0-8150-373305B15CAA-- From nobody Fri Feb 15 09:46:05 2019 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DF0131008 for ; Fri, 15 Feb 2019 09:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 5yt01LpCQYby for ; Fri, 15 Feb 2019 09:45:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80DF128BCC for ; Fri, 15 Feb 2019 09:45:53 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 9629F3826D; Fri, 15 Feb 2019 12:45:50 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id DA0EC17FE; Fri, 15 Feb 2019 12:08:35 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D86CE17C6; Fri, 15 Feb 2019 12:08:35 -0500 (EST) From: Michael Richardson To: Warren Kumari cc: opsawg@ietf.org In-Reply-To: References: 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: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 17:45:56 -0000 --=-=-= Content-Type: text/plain Warren Kumari wrote: > So, I'd like to discuss this document: > https://tools.ietf.org/html/draft-wkumari-opsawg-sdi-03 (I've had it kicking > around since 2016, but haven't had time to push it). Sure sounds like ANIMA ACP and BRSKI to me. > This document provides a simple modification to the netboot / autoboot > process which many vendors implement -- when a device is manufactured, and > the serial number is programmed, it also gets a key-pair placed on it (this > already happen for many manufacturers, some in TPM, some not). The vendor > will now also publish the *public* part on a keyserver, indexed by serial > number. Yes, it's called an IDevID from 802.1AR. > When I buy a device and get it drop-shipped to the POP, the vendor (VAR, > reseller) says "Thanks, here is the invoice, and the Serial Number is > SN17345". While the device is in transit, I go fetch > https://vendor.example.com/keys/SN17345.pem. I then encrypt the new device's > config file with the key in that cert. We call that a voucher, RFC8366. We don't include the entire config file in BRSKI, but in netmod zero-touch, it basically does: > When the device actually arrives at the POP, smart-hands unpacks it, racks > and stacks it, and plugs it into the circuit which I've installed already had > installed. The device does it's regular netboot - this is usually something > like "get IP via DHCP, use DHCP option 66, 67, 150 to find the config server, > download and install the named config". What this document add is: "If the > config file is completely unparsable, use your private key to try decrypt it. > If it is now readable, install and continue". Once the device boots and -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxm8hMACgkQgItw+93Q 3WX11AgAqUrrj6dseu1dzfsMSJE0G8tozlHDqPqhBqOO/0m9/3tiPuzYqM9X94xY wDH83Ene49FSnnbCUE7tYwY+IOZESYv/E3k6zhVleOy9XHeFBOc5d4wra/cd6Bda 1gviamVi+gcpvxvkiGtQ0VWxmytmf47gr0pY5IDX5JQ5pDd8fDnhBnL0suMRcl0H jTk8KQv4XyjyXzvzmkGrjjKs69Kgpp/zltAqJSYWV2HxpCT/IfpJOJD0Cb08G+K5 kME3nAOe93swZuxfjBt7rnltblmHzFMkJWPvXWrx4/RGYVmqviTzAR+ZgjuRpaFg tsVwKzanGu2wPXm0YXgS+tOqfMhaVg== =S2X/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 15 09:55:39 2019 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B2B1274D0 for ; Fri, 15 Feb 2019 09:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 Rz-y7SuKk2g8 for ; Fri, 15 Feb 2019 09:55:33 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 770231271FF for ; Fri, 15 Feb 2019 09:55:32 -0800 (PST) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id x1FHtVF0006576; Fri, 15 Feb 2019 12:55:31 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Michael Richardson , Warren Kumari CC: "opsawg@ietf.org" Thread-Topic: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi Thread-Index: AQHUxHSCR7RL9+R64EOZlv7Lay/CWqXhbRSA//+5SYA= Date: Fri, 15 Feb 2019 17:54:57 +0000 Message-ID: References: <11327.1550250515@localhost> In-Reply-To: <11327.1550250515@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190115 x-originating-ip: [172.25.1.84] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3633080129_464786800" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-15_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902150122 Archived-At: Subject: Re: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 17:55:38 -0000 --B_3633080129_464786800 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable We proposed a similar approach (and called it, surprisingly, "zero-touch pr= ovisioning") back in 2004-2005. ;-) I don't recall if Intel patented it, but in any case it would've likely exp= ired by whenever this is going to be deployed. I think the approach has merits (though I might be biased in its favor, hav= ing conceived something like that back when :). =E2=80=94=20 Regards, Uri =EF=BB=BFOn 2/15/19, 12:47 PM, "OPSAWG on behalf of Michael Richardson" wrote: =20 Warren Kumari wrote: > So, I'd like to discuss this document: > https://tools.ietf.org/html/draft-wkumari-opsawg-sdi-03 (I've had= it kicking > around since 2016, but haven't had time to push it). =20 Sure sounds like ANIMA ACP and BRSKI to me. =20 > This document provides a simple modification to the netboot / aut= oboot > process which many vendors implement -- when a device is manufact= ured, and > the serial number is programmed, it also gets a key-pair placed o= n it (this > already happen for many manufacturers, some in TPM, some not). Th= e vendor > will now also publish the *public* part on a keyserver, indexed b= y serial > number. =20 Yes, it's called an IDevID from 802.1AR. =20 > When I buy a device and get it drop-shipped to the POP, the vendo= r (VAR, > reseller) says "Thanks, here is the invoice, and the Serial Numbe= r is > SN17345". While the device is in transit, I go fetch > https://vendor.example.com/keys/SN17345.pem. I then encrypt the n= ew device's > config file with the key in that cert. =20 We call that a voucher, RFC8366. We don't include the entire config file in BRSKI, but in netmod zero-to= uch, it basically does: =20 > When the device actually arrives at the POP, smart-hands unpacks = it, racks > and stacks it, and plugs it into the circuit which I've installed= already had > installed. The device does it's regular netboot - this is usually= something > like "get IP via DHCP, use DHCP option 66, 67, 150 to find the co= nfig server, > download and install the named config". What this document add is= : "If the > config file is completely unparsable, use your private key to try= decrypt it. > If it is now readable, install and continue". Once the device boo= ts and =20 -- ] Never tell me the odds! | ipv6 mesh net= works [ ] Michael Richardson, Sandelman Software Works | IoT archit= ect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [ =20 =20 --B_3633080129_464786800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAASM0NeaQGCMkrQwAAAABIzTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE4MDkyMDIwMDQxNVoXDTIxMDkx OTIwMDQxNVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5KhwKRERVEci3gVCNFzOOaHI936EF 1839xWXYCK803QONXJMPS5Xbq1N7a1qbV+3kcj7731DzW9Ph0MgtYBldIuZvZpLeNPRqf8fq u6GIROqKnfmi4qvFgpL/YDJNDxrveMzC7tQfAvfYkdHrEudW23hT317E2PU7Pw8MZKUSObmJ ugP0ce1C9zqAl51eh2nx2hfKmo/M/ASvetoe2DjvEhzQaCs/4UXAqtMbF+YSkJRM59Qm9PIf twaXXGpXHXqAyBtCNFdF7W5Kwwgepu4qI3s4yZPdPp1iyXo+Tmg8uJj98SKFWSBlLQLBcZC0 VIs4MK5rXuHBSQNHzGnARh1/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUZfsTPcDWQzMHxarg W0BqNCQ5jeEwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAH7Ti12g LGyTcEGmgbF1ST7VSemff0FDY1x8f+4sDP4jVhAFrBSol6GFL/3akxP3Od4xmRdCbGrhc6Q3 eSMSqtuSjdN4z0vkzg37Npbx/59JPOGgLYUihmvr8BzMeJqPoZOkAM7QFOlBmDkGxxxSbjDG 7ebBK4IHc1bsRopc1tGQTLNeGc+hNFA5MEFVd7WqjqNWl1mKPhIX79D9rS0cYO+XQJLW9cRf 9+bfVMzRcLAh60MU5S686UVjU7EnddiJ31EF9byZfB3idfPL7h/9OrFwpBFUXcs7J8y4DJTR 7Kl3c9tLMQuMJNHmyimV3VeEdfPxghowK6m3MfTRVZjsLfQwggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAASM0NeaQGCMkrQwAAAABIzTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDxAFD39zGsezdTXzXJjKztfycya8hpuECuUgMn f+DVAjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTAyMTUx NzU1MjlaMA0GCSqGSIb3DQEBAQUABIIBACpzKLFHTc2RkG1CbfLKzIR5VP7LEbKRzcezR0YK bGzLx+Tz7flmb04a0NjBOu71xQ+1O4Xp6fZswq0BzliuLydP+ft4fBueukeWBCR4V6R8zCbC t9nCGc/aFqJ2Tp/7ERC3BWpi62wrRH6N+jdDHZMyrHhA6+OlUNeDDxykqz9E53qXF0X6nMwv n5uCfdasdSDm7s5cynO+wVgWSy1drOo68E7c7076MfK6T/TzHiwx1SYBBCs5/C0nbyeTCyj8 /4Elm8bANovVvrlS+e2PpfFMXtakwCeZbSL1K1a5jTU34HGrqLPtoxMm6pOOJFC4fPSir/oT HSjwSJUh/0ylmok= --B_3633080129_464786800-- From nobody Fri Feb 22 17:15:57 2019 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6A2130ED1 for ; Fri, 22 Feb 2019 17:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 HZX60Jp-yjYZ for ; Fri, 22 Feb 2019 17:15:53 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFF0130EB0 for ; Fri, 22 Feb 2019 17:15:53 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3193F730E39276E6A7ED for ; Sat, 23 Feb 2019 01:15:51 +0000 (GMT) Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 23 Feb 2019 01:15:50 +0000 Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Sat, 23 Feb 2019 01:15:50 +0000 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Sat, 23 Feb 2019 01:15:50 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Sat, 23 Feb 2019 09:15:46 +0800 From: Tianran Zhou To: "opsawg@ietf.org" Thread-Topic: [104all] IETF 104 Preliminary Agenda Thread-Index: AQHUywuSVzmzmqtxTkGaAN5FqOtRvaXsktXw Date: Sat, 23 Feb 2019 01:15:46 +0000 Message-ID: References: <155088034379.5518.4616383450543152946.idtracker@ietfa.amsl.com> In-Reply-To: <155088034379.5518.4616383450543152946.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [OPSAWG] FW: [104all] IETF 104 Preliminary Agenda X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 01:15:56 -0000 SGkgV0csDQoNClBsZWFzZSBub3RpY2UgdGhhdCB0aGUgcHJlbGltaW5hcnkgYWdlbmRhIGlzIHBv c3RlZC4NClRoZSBPUFNBV0cgYW5kIE9QUyBBcmVhIGpvaW50IG1lZXRpbmcgaXMgc2NoZWR1bGVk IGF0IDEzNTAtMTU1MCBBZnRlcm5vb24gU2Vzc2lvbiBJLCBUSFVSU0RBWSwgTWFyY2ggMjgsIDIw MTkuDQpZb3UgY2FuIHNlbmQgeW91ciBwcmVzZW50YXRpb24gcHJvcG9zYWwgdG8gdGhlIGNoYWly cyBvciB0aGlzIG1haWxpbmcgbGlzdCBmb3IgdGhlIHNsb3QuDQoNCkNoZWVycywNClRpYW5yYW4g YXMgY28tY2hhaXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IDEwNGFsbCBb bWFpbHRvOjEwNGFsbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSUVURiBBZ2VuZGEN ClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAyMywgMjAxOSA4OjA2IEFNDQpUbzogSUVURiBBbm5v dW5jZW1lbnQgTGlzdCA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiByZWNlbnRhdHRlbmRl ZXNAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IDEwNGFsbEBpZXRmLm9yZw0KU3ViamVjdDogWzEw NGFsbF0gSUVURiAxMDQgUHJlbGltaW5hcnkgQWdlbmRhDQoNCklFVEYgMTA0DQpQcmFndWUsIEN6 ZWNoIFJlcHVibGljDQpNYXJjaCAyMy0yOSwgMjAxOQ0KSG9zdHM6IENpc2NvIGFuZCBDWi5OSUMN Cg0KVGhlIElFVEYgMTA0IFByZWxpbWluYXJ5IEFnZW5kYSBoYXMgYmVlbiBwb3N0ZWQuIFRoZSBm aW5hbCBhZ2VuZGEgd2lsbCBiZSBwdWJsaXNoZWQgb24gRnJpZGF5LCBNYXJjaCAxLCAyMDE5Lg0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L2FnZW5kYS5odG1sDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L2FnZW5kYS50eHQNCg0KDQpJ RVRGIDEwNCBJbmZvcm1hdGlvbjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L21lZXRpbmdzLzEw NC8NClJlZ2lzdGVyIG9ubGluZSBhdDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L21lZXRpbmdz L3JlZ2lzdGVyLw0KDQpEb27igJl0IGZvcmdldCB0byByZWdpc3RlciBmb3IgdGhlc2UgZXhjaXRp bmcgSUVURiAxMDQgZXZlbnRzIQ0KDQpIYWNrYXRob24gDQoJU2lnbnVwOiBodHRwczovL3d3dy5p ZXRmLm9yZy9yZWdpc3RyYXRpb24vaWV0ZjEwNC9oYWNrYXRob25yZWdpc3RyYXRpb24ucHkNCglN b3JlIGluZm9ybWF0aW9uOiBodHRwczovL3d3dy5pZXRmLm9yZy9ob3cvcnVubmluZ2NvZGUvaGFj a2F0aG9ucy8xMDQtaGFja2F0aG9uLw0KCUtlZXAgdXAgdG8gZGF0ZSBieSBzdWJzY3JpYmluZyB0 bzogDQoJaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9oYWNrYXRob24NCg0K Q29kZSBTcHJpbnQNCglTaWdudXA6IGh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy90b29scy9p ZXRmZGIvd2lraS9JRVRGMTA0U3ByaW50U2lnblVwDQoJTW9yZSBpbmZvcm1hdGlvbjogaHR0cHM6 Ly90cmFjLnRvb2xzLmlldGYub3JnL3Rvb2xzL2lldGZkYi93aWtpL0lFVEYxMDRTcHJpbnQNCg0K LS0gDQoxMDRhbGwgbWFpbGluZyBsaXN0DQoxMDRhbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vMTA0YWxsDQo=