Re: [I2nsf] AD review follow-up on draft-ietf-i2nsf-registration-interface-dm-22
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Wed, 11 January 2023 17:37 UTC
Return-Path: <jaehoon.paul@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4154AC1527AE for <i2nsf@ietfa.amsl.com>; Wed, 11 Jan 2023 09:37:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.084
X-Spam-Level:
X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_DOTEDU=1.999] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSJQeKzczE0u for <i2nsf@ietfa.amsl.com>; Wed, 11 Jan 2023 09:37:06 -0800 (PST)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDF7C15C524 for <i2nsf@ietf.org>; Wed, 11 Jan 2023 09:37:06 -0800 (PST)
Received: by mail-pl1-x62f.google.com with SMTP id g23so1931129plq.12 for <i2nsf@ietf.org>; Wed, 11 Jan 2023 09:37:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/AZi6EYe0mvfAMo4D07p3Z1Twz4NqS2al9kUV31A3FI=; b=Hoajdbfn0j8RBCWZLu+E4wz0HOnMNU5hTeWoOsZ16JwMlCTCsUSD3jCLFzylusipNJ vLEOexSFdFIE7mxNq5TprubfXIRLVxV+7aBkxkTkY3qu/QgwH88q8qL76HSZC19tllGj QaOjoUV11iZtRjUv9oUeeH6DHPXopSTyuFYhk/v5QKThgmw87FHtSJivh1+3mrD1xeLZ XBMhIPiMUHe7Vk9me+5gNr3NAKVGo01H9inPGwuiR7jjIEeg/mqTwysHLeooFNhbh9ti pvaOu/GOb9aCakwZAiNKMi3WnbHzG6qiIt4A0DQBNtTeXkQeHDvRWB9J2zUhbdpuasCe emuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/AZi6EYe0mvfAMo4D07p3Z1Twz4NqS2al9kUV31A3FI=; b=RsPgI5lpiu05YJaHhpd3E6D2CoSN/rWwI/hovoKnWes0cPEqGLEfTgMVbySthA4C5N ee9syKUAQZUeOV58klwlQA39KBx/slLizdyXVFPtLkJ4lUg4/XWhre6rFVsico94omI7 ejNIpWUxOiX60co5NEl03nJzEQn0qqX+rYvG45II3A+T/1DZJoIMIxIevwF0RT7VBmSl vvBt/ab1cIEQ8qdpTKdhp5TMCyJ153SGeyswt5gPbngOYBVC238fZ2ZTlPuoDKTcrbIm 3S06TW0gb8QYeJZ8n0iPnw7wn6SHzo4MJ8kmoWKW6AOs2J1l359U7M+c1ySthcnpVLgR 1zzg==
X-Gm-Message-State: AFqh2kq8NJASunXWpHcrn8Ueg5GaPD2mx1Wf4zfaF6mEtd2YIfLj5NAi QKYYMnYji++L2qtKmoG/zqCXPfR+L+kU8H4NFEM=
X-Google-Smtp-Source: AMrXdXtpta9vqyf+wmvD1H7k6MAIyT+uLlS3qBQBtP6+geL5Hq/LK3CDaNu7Cm4hTGD6jg7vZ9Hv+Jx/0c4u3lpub00=
X-Received: by 2002:a17:90b:2792:b0:219:73d1:eb39 with SMTP id pw18-20020a17090b279200b0021973d1eb39mr3459696pjb.45.1673458625322; Wed, 11 Jan 2023 09:37:05 -0800 (PST)
MIME-Version: 1.0
References: <BN2P110MB1107AC9CE676242748E71AE6DCFC9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <BN2P110MB1107AC9CE676242748E71AE6DCFC9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Wed, 11 Jan 2023 12:36:53 -0500
Message-ID: <CAPK2DezLzzepu6vwWgPvjcHhAFFk-m-W0_D6q21x1WcWcFP8mg@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>, Patrick Lingga <patricklink888@gmail.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000e8a38e05f20072ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/ji5HzHOxrNhWjID3WMMxfm7XavM>
Subject: Re: [I2nsf] AD review follow-up on draft-ietf-i2nsf-registration-interface-dm-22
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jan 2023 17:37:11 -0000
Hi Roman, Thanks for your 2nd detailed review on RI. Patrick and I will work for the revision with your comments. Thanks. Best Regards, Paul 2023년 1월 11일 (수) 오전 11:25, Roman Danyliw <rdd@cert.org>님이 작성: > Hi > > I performed an AD review on draft-ietf-i2nsf-registration-interface-dm-21 ( > https://mailarchive.ietf.org/arch/msg/i2nsf/82QQzd1J6A8xqlyv5ZBRn4_xZCs/). > The authors produced at -22 in response. Thank you! > > To make it easier to track the remaining issues, I've created this new > thread. The following is feedback on -22: > > ** Architectural considerations #1 (Flows between the Security Controller > and DMS) > > Thanks for the new text in -22 to clarify that the Security Controller is > the NETCONF/RESTCONF server and the DMS is the client. With this > understanding I have a few more questions centered around the three > objectives described in Section 3. > > (a) Section 3. “Registering NSFs with the I2NSF framework” > > -- How does the DMS know that it’s supposed to connect to the Security > Controller? For -21: > > [-21] How does the Security Controller discover the DMS? > => [PAUL] This information should be known when an agreement for > subscribing to the > security service is approved between the I2NSF User and the vendor. The > vendor should > provide the DMS information to the Security Controller for such > connection. The method of > exchanging this information is out of the scope of this document. > > Can these out-of-scope assumptions please be documented. > > -- How is the credentialling provisioned so that the DMS can log-in to the > Security Controller? > > (b) Section 3. “Asking DMS about some required capabilities”. > Additionally, Section 5.1.2.2 notes that “In this case, Security Controller > makes a description of the required capabilities using this module and then > queries DMS about which NSF(s) can provide these capabilities.” > > -- If the Security Controller is the NETCONF/RESTCONF server and the DMS > is the client, what is the mechanism by which questions are posed to the > DMS? Does the Security Controller use the RPC mechanism defined in Section > 5.1.2.2 (with the DMS operating a registration server interface)? > > -- If the Security Controller use using the RPC mechanism, is the > following newly added text in Section 1 entirely accurate: > > Section 1. “Note that in either NETCONF [RFC6241] or RESTCONF [RFC8040] > parlance through the I2NSF Registration Interface, the Security Controller > is the server, and the DMS is the client because the Security Controller > and DMS run the server and client for either NETCONF or RESTCONF, > respectively.” > > -- If the DMS is running a Registration Interface already to satisfy > responses to the RPC mechanism, why can’t this same mechanism be used to > satisfying the “Registering NSFs with the I2NSF Framework” step? It would > simplify the architecture. > > ** Architectural Considerations 2 (scope of the DMS) > > Per -21: > > Per the local provisioning information. > > (a) Section 4.1.1.1 “The registration interface can control the usages and > limitations of the created instance and make the appropriate request > according to the status.)” > > (b) Section 4.1.2. The “NSF Access Information” (or grouping > nsf-access-info per the YANG module) appears to specify the IP address of > an NSF > > (c) YANG. rpc nsf-capability-query has the DMS returning nsf-access-info > which is an IP address of an nsf. > > Why would the DMS be privy to what appears to be local configuration > information. Does the DMS have a role in provisioning the NSF? Is there > any information about the Security Controller’s configuration stored on the > DMS (beyond authorization or authentication information)? > > -21 response: > => [PAUL] The DMS is the system developed by the vendor that provides and > deploys the > NSF. The NSF information is unknown to the Security Controller until it is > registered by > the DMS. Hence, the DMS knows the local configuration information and > informs the > Security Controller of the information. > > Thanks for this explanation and the addition of name and password into > nsf-access-info. I still have some confusion on the architecture and > semantics of these fields, and the implications they may have for the > security and operational considerations of I2NSF registration interface. > In re-read RFC8329 and the model here, I feel that we need either tighter > scoping or at least more explanation on the role of the DMS. > > -- Looking at nsf-specification and nsf-access-info, it appears that two > classes of information are being shared. The former describes a capability > of the NSF, and the latter is a provisioning information. Is there an > assumption that the DMS is both providing the software for and the NSF > _and_ also operating the NSF used by the Security Controller? This seems > to be the case in your response. My scan of RFC8329 and the descriptive > text of the DMS here does not explicitly say that. Are self-hosted or > third party-hosting options of an NSF precluded by this architecture? > > -- If the DMS “provides and deploys the NSF” how is the orchestration of > the NSFs expected to occur. When the DMS returns the nsf-access-info of an > NSF, does that mean it is ready to be fielded in production by the Security > Controller? Let’s say that a Security Controller no longer needs an NSF, > how does it turn it off? > > ** Section 5.1.2.1. and 5.2 nsf-access-information. > > Thanks for the edits here from -21. > +--rw name? string > +--rw password? ianach:crypt-hash > > leaf username { > type string; > description > "The user name string identifying the credentials for the > authentication."; > } > leaf password { > type ianach:crypt-hash; > description > "The password for the username for the authentication. > Any plain-text password must be converted to a hashed value > as soon as possible"; > } > > I wanted to discuss the degree of flexibility warranted here. > > -- I asked about this credentialing information in my -21 feedback. The > above fields were added. I want to make sure that the WG wants to have > this credential management in-scope. It would also be possible to say that > this is handled out of band, pre-negotiated with every DMS. > > If credential management will be in scope, these would be other matters to > consider: > > -- If SSH is used, should a list of authorized-keys also be supported? > > -- Should there be flexibility for this information to be entirely omitted > and these credentials to be provisioned out-of-band, in addition, to an > in-band mechanism specified in the module? > > -- If this mechanism is used to give the Security Controller the password > for the first time, doesn’t “plaintext” ($0$) have to be used? If the DMS > provided a hashed password, it isn’t clear what the Controller would do > with it. > > -- Should there be guidance stating that password resets and associated > credentials changes? > > ** Section 7. Remind the reader of the risks of externally operated NSFs > already documented in Section of RFC8329. > > ** Section 7. Editorial. Please do not use the word “illegally” in the > text here to describe the attacker behavior. > > Thanks, > Roman > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
- [I2nsf] AD review follow-up on draft-ietf-i2nsf-r… Roman Danyliw
- Re: [I2nsf] AD review follow-up on draft-ietf-i2n… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD review follow-up on draft-ietf-i2n… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD review follow-up on draft-ietf-i2n… Roman Danyliw
- Re: [I2nsf] AD review follow-up on draft-ietf-i2n… Mr. Jaehoon Paul Jeong