Re: [I2nsf] AD review of draft-ietf-i2nsf-registration-interface-dm-21
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Thu, 27 October 2022 15:40 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 59956C14F6E5 for <i2nsf@ietfa.amsl.com>; Thu, 27 Oct 2022 08:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w621mXWLHAX for <i2nsf@ietfa.amsl.com>; Thu, 27 Oct 2022 08:40:40 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 34728C1524D4 for <i2nsf@ietf.org>; Thu, 27 Oct 2022 08:40:15 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id 21so3474741edv.3 for <i2nsf@ietf.org>; Thu, 27 Oct 2022 08:40:15 -0700 (PDT)
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=QsEXS++oNfOzWKtt9i+2L1J3e2N9xqM9Sp5PX5POnlo=; b=C0zM/aBuOEiZhbRjjgIYeq9iHVVta/uuZhjwFBLknNw+0wiYRmos4NpNtoUdkwD9ES hFxPCPc8zC55JiFNftxlVCZ/hZXLohn3Xmp3KYEl+jUlTVuWVZO3VKOQsd5ub7AitQFZ ZsL9D8mLCwZazEamXfj5JXJ76gVYREFSsQzm/XnNMvj9BMGwlpNdyVgPJ3fSo1+OjfoU VgcVOAQiINQgdLIUIe9NipbH5f9hzP4MKsTn3I3TSHS8QbFZHIZJEL28rrTAM3KkAd9g WLvgv3VYZSbfIvbxQ+Lga+tkn7gsryYfN1J5W5VYrDITHoIo5+ayG04/kN4xT2S+0c/9 U9/A==
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=QsEXS++oNfOzWKtt9i+2L1J3e2N9xqM9Sp5PX5POnlo=; b=IFtMr5/lfBzFNZ9zxetyBcIC3Pfi1XgCfohVE9FcChTMl+KH4tPgDw0hcSMHDWUKAD Pvr+T+l0s+cs5UMz2eXPhu4gWJUfcUXa0wgEfZWQmEUiGGDcfWSxQ3bhimqmx5pL7lp6 ryMhFHtKZi4ACZizjirzoP/d0CeBujTzzAdwFnCfsnFVJ13CfjS7JFI6dXbOcLIoHf0L XTa+C/ib5MuR0pQM6TGIp+qARiK0l5gA7PLCgWRwCcxMRidYbiwZnXGEGqaeiaE15snr CWD5mJ/B7bMswCpHhyO33ViZ38PLCVK8+yhiSeswRGacEC6L6Qb8ScU/ntz1ZwqbTlrb zkjA==
X-Gm-Message-State: ACrzQf2MJM2znH15ZwJPeAZ8crC5mRj/BBOq2adczC5+XgD0m5T//+LM Gf4mw0l5ObpaD6St7Dk5iNsQQiJgBBVchtzz0hQ=
X-Google-Smtp-Source: AMsMyM6Vj2OoWLHPnwxy2P/mDckwLhOGDrO7LO4LznrZ4SW4ctNs+44bY2ag/Iooda1dEDT8yLjje80vRfh15196s0Q=
X-Received: by 2002:aa7:c61a:0:b0:461:c48d:effe with SMTP id h26-20020aa7c61a000000b00461c48deffemr20060142edq.7.1666885213381; Thu, 27 Oct 2022 08:40:13 -0700 (PDT)
MIME-Version: 1.0
References: <BN2P110MB11077D28DBFCD00E00B42CCCDC339@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <BN2P110MB11077D28DBFCD00E00B42CCCDC339@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Fri, 28 Oct 2022 00:39:38 +0900
Message-ID: <CAPK2DexEDTOpeRZ+zDF4NFtPBZM73NQ0js8cgQN+86uevTOqTA@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, Patrick Lingga <patricklink888@gmail.com>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000066a5805ec05f51c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/n-MaUtuwGzkCuQo0MTFzRhUS1Io>
Subject: Re: [I2nsf] AD review of draft-ietf-i2nsf-registration-interface-dm-21
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: Thu, 27 Oct 2022 15:40:41 -0000
Hi Roman, Thanks for your detailed and constructive comments and questions. I will address yours on the revision. Thanks. Best Regards, Paul On Thu, Oct 27, 2022 at 12:34 PM Roman Danyliw <rdd@cert.org> wrote: > Hi! > > I performed an AD review of > draft-ietf-i2nsf-registration-interface-dm-21. More feedback is split into > a two section: general comments on the document followed by specific > section by section comments. > > ==[ General Comments > I appreciate that this document is intended to specify the registration > interface of the I2NSF architecture. Typically, when the primary intent of > a document is to specify a YANG module most operational and architectural > considerations can be covered elsewhere. In my assessment, I2NSF is a > special case. This is a niche YANG module for a specific architecture. To > ensure that it can be implemented in a secure and interoperable way, > additional details need to be specified beyond what is in RFC8329. > Practically, there are no other documents in which to convey this > information. Additionally, what makes this document different than the > other four YANG module documents is that it appears to be specifying > interactions across administrative domains. This suggests that even > greater care needs to be taken with the Security, Operational, and Privacy > Considerations. To that end, few high-level comments: > > ** Architectural considerations. > > -- Who initiates the registration and update process? Is this Security > Controller or DMS initiated, or is it expected to be possible for either to > do it? My confusion originates from Section 3 saying the DMS “uses [the] > Registration Interface to provide NSFs developed by the NSF vendor to > Security Controller”, but Section 4 saying that “DMS registers NSFs and > their capabilities with Security Controller via the registration interface” > and Section 4.1 repeats “This submodel is used by DMS to register an NSF > with Security Controller.” Please be consistent and explicit. > > -- In NETCONF/RESTCONF parlance, who is expected to be the client and > server? > > -- I don’t see it in the YANG module definition, but the text phrases > things as if the DMS is serving the NSF to the Security Controller. For > example: > > (a) Section 3. “Developer's Management System (DMS) in I2NSF framework is > typically run by an NSF vendor, and uses Registration Interface to provide > NSFs developed by the NSF vendor to Security Controller.” > > (b) Section 3. “the I2NSF Registration Interface can be used as a standard > interface for the DMSs to provide NSFs capability information to the > Security Controller.” > > (c) Section 3. “Security Controller needs to request DMS for additional > NSF(s) that can provide the required security capabilities via Registration > Interface.” > > The text in (b) is clear in saying that the registration interface provide > NSF capability information to the Security Controller. (a) and (c) seem to > suggest that the NSF itself is being shared through the interface. > > -- I was under the impression that the DMS was providing “NSF capability > information” so I was surprised to see instances of what appeared to be > local provisioning information. For example: > > (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)? > > ** Operational considerations > > -- What guides the cadence and workflow associated with the Security > Controller getting updates on the NSFs? > > -- How does the Security Controller discover the DMS? > > ** Security Considerations > > -- Thanks for the YANG object level analysis. Please also provide > high-level analysis about the supply-chain risk presented by this > architecture which has the Security Controller relying on a DMS. What > would be the impact to I2NSF if the DMS was not available? If the DMS was > compromised? What does the DMS learn about the Security Controller’s > configuration (and by proxy about the security architecture of the domain > in which it is fielded) through this interface? > > -- I recognize the boiler plate YANG security template on language on > citing that TLS/SSH and that NETCONF/RESTCONF can restrict access, but this > is generic. Given the described architecture (which entails exchanging > information that could affect security configurations across administrative > domains) there needs to be more specific guidance on the trust and > authentication/authorization models between the Security Controller and DMS. > > ** What does the YANG module for an “update” operation look like? > Registration is covered in Section 5.1.2.1 and Querying is in Section > 5.1.2.2. > > ==[ Section-by-section feedback > > The following are more detailed section specific feedback. > > ** Abstract. Typo. s/for Registration Interface/for the Registration > Interface/ > > ** Section 1. s/security controller/Security Controller/. Additionally, > as noted for the draft-ietf-i2nsf-consumer-facing-interface-dm, since > RFC8329 doesn’t mentioned Security Controller and uses Network Management > Operator System instead. Please note their relationship. > > ** Section 3. > > In this case, DMS > uses Registration Interface to update the capability of the NSF, > and this update SHOULD be reflected in the catalog of NSFs. > > If an update is going to occur, shouldn’t it be mandatory that the catalog > is modified? > > ** Section 3. Typo. s/from an I2NSF user, Security Controller/from an > I2NSF user, the Security Controller/ > > ** Section 4. The operations summarized in bullets (1) and (2), appear to > repeat the objectives 1 and 2 in Section 3? Is there a reason to do that > twice? > > ** Section 4.1. > The NSF Name contains a unique name of this NSF with the > specified set of capabilities. > > -- Unique within the scope of all NSF’s published by the DMS? > -- I note that draft-ietf-i2nsf-capability-data-model provides no guidance > beyond "The name of Network Security Function (NSF)", and on a registration > operation is uses that definition. As an side, on the rpc query response, > there is normative language in the YANG module. > > ** Section 4.1.1.1. Should this “NSF Specification” include other > dimensions like memory or disk? These are exposed alarms in the > monitoring-data-model. > > ** Section 4.1.1.1. > > This information represents the processing capability of an NSF. > > This sentence summarized the “NSF Specification” as “processing > capability”. However the descriptive text notes that this sub-model > element covers both “processing” and “bandwidth”. > > ** Section 4.1.1.1. > Assuming that the current workload status of each NSF is being > collected through NSF monitoring > [I-D.ietf-i2nsf-nsf-monitoring-data-model], this capability > information of the NSF can be used to determine whether the NSF is in > congestion by comparing it with the current workload of the NSF. > > Is this guidance only intended to cover “bandwidth”? I ask because I > don’t see a way to align the “% CPU load” metrics in the > monitoring-data-model with the processing-average and processing-peak > fields whose units are GHz. > > ** Section 4.1.1.1. > > These two information can be > used for the NSF's instance request. > > -- What is an instance request? > -- Editorial. "These two information" doesn't parse. > > ** Section 4.1.2. NSF Access Information. See earlier comments on not > understanding why this information is in the model. Setting that aside, > and just thinking of this container as what is necessary to connect to an > NSF over NETCONF/RESTCONF. > > -- Isn’t there also the possibility of various credentials being needed to > make a connection? Are they not represented for a reason? > > -- Why are domain names not supported? > > ** YANG. container processing > > I believe this is intended to express the processing capability of the NSF. > > -- Could the difference between “processing-average” and “processing-peak” > be explained. Is the latter expressing a concept like “Intel Turbo Boost”? > > -- Could the kind of decision support this is driving be better > explained. I ask because I’m not sure that GHz is the right unit. > Comparing clock speed absent a lot of other factors doesn’t seem > meaningful. Off the top of my head (and I’m not proposing this), something > like BogoMips or a benchmark seems more applicable. > > -- How would some of these figures be relevant in a virtualized > environment? > > ** YANG. container bandwidth. Outbound/inbound-average and -peak field. > > “The network bandwidth available to the NSF” > > -- Is this measuring the capacity of the NICs, throughput to > inspect/groom/filter a particular network load or the bandwidth of the > links provisioned to the NSF? > > -- If this is the provisioned bandwidth, please see my comments inquiring > about the role of the DMS with provisioning information. > -- If this is measuring capacity, then “bandwidth” doesn’t seem like the > right metric (maybe throughput)? What would “peak” throughput mean? > > ** Section 7. Please do not specifying normative behavior for the > attacker (i.e., “The attacker MAY …”, say “The attacker may”). > > ** Section 7. > > nsf-registration: The attacker MAY try to gather some sensitive > information of a registered NSF by sniffing this. > > Sniffing implies on-path inspection. Is the intent different here? > Shouldn’t the use of TLS or SSH preclude that? The subtext here is a > controlling read-access to the DMS server (I think). Can the threat please > be clarified? > > ** Section 7. For the “readable node analysis”, the following assessment > is used for the nsf-specification and nsf-capability-info: > > The attacker MAY gather the {specification / capability information} > information of any target NSF and misuse the information for > subsequent attacks. > > I would expect that knowing that a particular NSF is fielded by a > controller is of interest to the attacker as described. Is this > architecture, is the information tied to the specific and capability > information generic across all instances of that NSF for that vendor’s > deployment base? > > ** Section 7. > > * nsf-capability-query: The attacker MAY exploit this RPC operation > to deteriorate the availability of the DMS and/or gather the > information of some interested NSFs from the DMS. > > If the DMS is a vendor, wouldn’t the product capabilities be public in > some cases? Would that be worth clarifying? > > ** Appendix A. Step 5. > > 5. The NSF can have processing power and bandwidth. > > Could this please be made more descriptive. > > Regards, > Roman > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf >
- [I2nsf] AD review of draft-ietf-i2nsf-registratio… Roman Danyliw
- Re: [I2nsf] AD review of draft-ietf-i2nsf-registr… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD review of draft-ietf-i2nsf-registr… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] AD review of draft-ietf-i2nsf-registr… Mr. Jaehoon Paul Jeong