[OPSAWG] Benjamin Kaduk's Abstain on draft-ietf-opsawg-ntf-12: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-opsawg-ntf-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntf/ -- COMMENT: -- Thanks for making the applicability statement more prominent in the -12. I think the document paints an exciting picture of a new mindset in which to frame discussion of network monitoring and management (even if it does stray too far into marketing language for my taste in places). It doesn't do quite as well at convincing me that an entirely new technology suite is merited (as opposed to just extending existing protocols to align with the new mindset), but I am willing to admit the possibility that the new technology suite is the right approach. That said, I have strong misgivings about the current state of the document, mostly relating to privacy considerations and the risk of pervasive monitoring, so I am balloting Abstain. While we do clearly say to not analyze individual users, we also have guidance (e.g., in §2.1) that only says "no user packet content should be collected". However, packet contents are not the only things that can be a threat to user privacy, and we've seen numerous instances where just metadata about user flows are sufficient to make strong conclusions about user behavior that impact user privacy. But if we try to strengthen the requirement to be not collecting any data about user packets, the utility of the system decreases greatly, and I don't see a clear way to reconcile the impasse. (There are also a few lingering references to "user flows", "user packets", "user traffic", etc. in the main body text, especially in §2.3. I'm not convinced that all of the instanaces of these phrases are compatible with the applicability statement.) Furthermore, the applicability statement seems to be a case of wishful thinking. I do not see any proposals for technical measures to enforce that data is not collected from networks where endpoints represent users, and I also don't see any mechansisms to disincentivize such use in favor of other, more privacy-friendly, alternatives. So even if we consider such usage of the network telemetry framework to be an abuse case rather than a use case, if we are going to honestly document the implications of the technology, I can't escape the conclusion that we need to consider these scenarios in our assessment of whether we are defining the right technology. Though I am balloting Abstain, I will also some specific comments on the document that might help improve it, even if I may not be completely happy with the resulting document (for the reasons described above). It's pretty surprising to see a document that mentions autonomic networking and aims to achieve self-managing networks make no reference at all to the IETF ANIMA WG or its outputs, a group that is specifically chartered to produce protocols and procedures for automated network management. In particular, it's my understanding that ANMIA has had very little traction with network Intent thus far, and this document references IRTF documents in many places (both for Intent and other things). Are we confident that these concepts are ready to move from the IRTF into the engineering world? Section 1 Network visibility is the ability of management tools to see the state and behavior of a network, which is essential for successful In the TLS WG we've sometimes seen participants use the term "visibility" to include the plaintext of encrypted data flows. While I have no reason to believe that that's a universally held understanding of the term, I mention it only to ask that clarification be provided if the intent of the term here is to include such decryption capabilities. If the intent is only to observe the normal visible wire image of the protocol, I don't see particular need for clarification. Section 2 forward. When a network's endpoints do not represent individual users (e.g. in industrial, datacenter, and infrastructure contexts), network operations can often benefit from large-scale data collection without breaching user privacy. In the vein of my toplevel remarks, I don't think that just "a network's endpoints do not represent individual users" is sufficient to ensure that large-scale data collection does not breach user privacy. It covers first-order effects, I think, but we've seen a lot of research indicating that second- and higher-order analyses can still extract
[OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-l3sm-l3nm-14: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-opsawg-l3sm-l3nm-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/ -- COMMENT: -- Thanks for the many updates in the -12 through -14. Just one final comment on the new changes: Section 7.6.3 The L3NM supports the configuration of one or more IPv4/IPv6 static routes. Since the same structure is used for both IPv4 and IPv6, it was considered to have one single container to group both static entries independently of their address family, but that design was abandoned to ease the mapping with the structure in [RFC8299]. This paragraph appears both at the end of 7.6.3 and at the start of 7.6.3.1; presumably only the latter is needed. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-l3sm-l3nm-11: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/
--
DISCUSS:
--
(1) I think there may be some ambiguity we need to resolve, relating to
per-AF router IDs and other per-AF lists:
list router-id {
key "address-family";
description
"Router-id per address family.";
leaf address-family {
type identityref {
base vpn-common:address-family;
}
description
"Indicates the address family for which the
Router-ID applies.";
What actually gets used as the router-id for a given address family if
both "dual-stack" and that address family are present in this list?
There's some similar potential for amiguity in the
"redistribute-connected" list for BGP routing, that is also keyed on an
address-family identityref.
(2) In a similar vein as Roman's Discuss (and perhaps obviated by it?), if
we're going to allow raw keys to be specified, as a string type, we
should be very clear about whether the string is hex-encoded,
base64-encoded, etc., in light of deployed experience with devices that
take the string and use it as the raw key (thereby eliminating a good
chunk of the key space from potential use).
(2.5) For raw keys, should we be using nacm:default-deny-all?
(3) the ipsec authentication option for the various routing protocols
uses a string to identify an (IKE, unspecified version thereof) SA. RFC
7296 doesn't have the concept of a name for an IKE SA itself, so I think
we need to provide more details on what is being named and what the
naming authority is. IKE does have identities for the peers, if the
goal is to refer to the peer's identity for the SA.
(4) I'd also like to have a discussion about the NTP configuration
options; in particular, we currently have an enumeration to select
between broadcast client and broadcast server, with no option apparent
for symmetric or other NTP modes. Given the rigidity of YANG
enumerations, I'd like to confirm that no other NTP modes could be
appropriate on the network access before we lock in to this model.
--
COMMENT:
--
I expect there's a large degree of personal preference involved, but I
find it easier to read the document when the tree (fragment) precedes
the per-field descriptions; this document has many instances of the
other order (as well as some instances of my preferred order).
Section 1
The L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as
described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as
described in [RFC6037][RFC6513].
RFC 6037 is Historic; is it nonetheless still a worthwhile reference?
Section 7.6.1
tunnel selection. The container can also identify the pseudowire
(Section 5.2 of [RFC4447]).
RFC 4447 is showing up as obsolete, obsoleted by RFC RFC 8077.
Section 7.6.2
Is the indentation of the tree diagram correct between
"(allocation-type)?" and ":(dhcp-relay)"? I think that dhcp-relay
should be at the same level as provider-dhcp -- maybe the implicit
'case' around "container provider-dhcp" is confusing the tooling?
Section 7.6.3
When the IPv4 or dual-stack address-family is requested, it is
up to the implementation to decide whether OSPFv2 [RFC4577] or
Which implementation? The service orchestrator's? (The phrase "up to
the implementation" appears at least one other place, as well.)
'authentication': Controls the authentication schemes to be
enabled for the OSPF instance. The following options are
supported: IPsec for OSPFv3 authentication [RFC4552],
authentication trailer for OSPFv2 [RFC5709] [RFC7474] and
OSPFv3 [RFC7166].
[...]
| | +--rw authentication
| | | +--rw enable?boolean
| | | +--rw keying-material
| | | +--rw (option)?
| | |+--:(md5)
| | || +--rw md5-keychain?
| | || kc:key-chain-ref
| | |+--:(ipsec)
| | | +--rw sa? string
I don't
[OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-vpn-common-10: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-vpn-common-10: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/
--
COMMENT:
--
I have a bold proposal for consideration: since we are defining a new
common set of groupings for VPN and, in some cases, proposing to rename
existing terminology already, can we consider moving away from the term
"VPN" itself? The word "private" is ambiguous as to what level of
privacy is being provided (e.g., network routing vs cryptographic) and
who the conveyed content is to be private from. A term like "virtual
network" removes that ambiguity, and lets us use the explicit attributes
to convey whether encryption is in use when appropriate.
There is no particular triggering point (at least, not yet) at which it
becomes clearly correct to make a breaking change like this, so we may
end up just having to pick a time somewhat arbitrarily, if we are to
make such a change at all. Perhaps now is that time; perhaps not.
Section 3
grouping vpn-profile-cfg
+-- valid-provider-identifiers
+-- external-connectivity-identifier* [id]
| {external-connectivity}?
| +-- id? string
Presumably I am just misreading RFC 8340, but I thought that the list
key was implicitly mandatory, so it would appear as just "id" (as
opposed to "id?"). (Many instances.)
'vpn-route-targets':
* A YANG grouping that defines Route Target (RT) import/export
rules used in a BGP-enabled VPN (e.g., [RFC4364][RFC4664]).
On very quick skim, it's not clear what motivates the RFC 4664
reference -- "route target" does not appear, for example, nor does
"import" or "export".
Section 4
identity pim-proto {
if-feature "pim";
base routing-protocol-type;
This is in the section with the group-management-protocols; is
"routing-protocol-type" really the intended base?
identity embb {
[...]
identity urllc {
[...]
identity mmtc {
Similar to Roman's comment, a reference seems useful for these.
If we intend to implicitly rely on RFCs 8299 and/or 8466 for
terminology, we should say so in the terminology section.
leaf vpn-id {
type vpn-common:vpn-id;
description
"A VPN identifier that uniquely identifies a VPN.
This identifier has a local meaning, e.g., within
a service provider network.";
Thank you for indicating the scope of validity of the identifier!
(Elsewhere as well.)
grouping service-status {
[...]
leaf last-change {
type yang:date-and-time;
description
"Indicates the actual date and time of the service status
change.";
What's the motiviation behind leaving this as "config true"? When would
it be useful to set it manually?
list vpn-target {
[...]
leaf id {
type int8;
description
"Identifies each VPN Target.";
I wasn't able to find the motivation for limiting to int8 in RFC 4364,
though I mostly assume I'm just looking in the wrong place.
(But why *signed* int8?)
Section 5
While there may be no direct security considerations from what is
effectively just defining some new compound types for reuse, I think we
may want to consider some privacy considerations. For example, we have
the "customer-name" field in the vpn-description, and it is sometimes
the case that customers want to remain confidential. Thus, any
instantiations of the grouping would incur a potential need for
confidentiality and minimizing the scope of distribution.
NITS
Section 4
feature bearer-reference {
description
"Indicates support for the bearer reference access constraint.
That is, the reuse of a network connection that was already
ordered to the service provider apart from the IP VPN site.";
I echo Roman's comment that this feature would benefit from a reference
or further discussion; the current description leaves me unclear on what
is meant and with no recourse for learning more. (RFCs 4026 and 4176
are presented as generic references for VPN-related terms, but do not
cover the concept of "bearer reference".)
reference
"I-D.ietf-teas-ietf-network-slice-framework:
Framework for IETF Network Slices";
draft-ietf-teas-ietf-network-slice-framework is
[OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/
--
COMMENT:
--
This document presents a couple use cases for the new IE 46 codepoints,
but both are in the context of monitoring the rollout of a migration of
control-plane technology. Are there steady-state use cases for these
values?
Section 2
Another use case is to monitor MPLS control plane migrations from
dynamic BGP labels [RFC8277] to BGP Prefix-SIDs in the context of
Seamless MPLS SR described in Section 4.6 of
[I-D.hegde-spring-mpls-seamless-sr].
I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of
maturity to be a good reference here (and thus, that this example is
worth including). For example, the referenced section refers to "option
A", "option B", and "option C" but I couldn't find where in the document
these options were enumerated as such. (Maybe it's supposed to be
what's described in sections 4.1.{1,2,3}; maybe not.) (Further aside
about that draft: it also isn't using the RFC 8174 version of the BCP 14
boilerplate, and has more authors than recommended by the RFC Series
Editor statement on authorship,
https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html
.)
Section 5
If pressed to come up with new security considerations from this work, I
would submit that conveying information about what control-plane
protocol is in use gives an attacker information to use in planning an
attack on that control plane. But the attacker would need to have
access to the IPFIX information in order to do so, and RFCs 7012 and
7011 are clear that the mechanism for conveying the IPFIX data has to
provide confidentiality protection, so it seems that endpoint compromise
would be needed for the attacker to actually gain access, and it's hard
to come up with a realistic scenario involving endpoint compromise where
these new codepoints are key to an attack. In short, it doesn't really
seem like a consideration that's relevant enough to be worth mentioning
in this document, so I'm okay with leaving this section as-is.
The most that I would suggest changing is to add the word "significant",
for "no significant extra security considerations".
NITS
Section 1
Four new routing protocol extensions, OSPFv2 Extensions [RFC8665],
I suggest dropping the word "new", which is a relative term and will be
less and less applicable over time.
Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow
Information Export [RFC7012] can be leveraged to account traffic to
MPLS SR label dimensions within a Segment Routing domain.
I don't understand the word "dimensions" in this context. (It doesn't
appear in the referenced documents, either, which suggests that a
different word may have been intended.)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-tacacs-yang-10: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/
--
COMMENT:
--
I have very little to add that was not already mentioned by my
colleagues (but I agree with Roman and Francesca that a compelling case
for standards-track has not been visibly made). These are basically
nit-level comments.
Section 3
authorization, and accounting servers. Authentication is used to
validate a user's username and password, authorization allows the
user to access and execute commands at various command levels
I think that RFC 8907 uses the term "privilege level" for what is being
referred to as "command level" here.
Section 4
leaf timeout {
type uint16 {
range "1..300";
}
How was the maximum of 300 seconds chosen?
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-opsawg-model-automation-framework-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/ -- COMMENT: -- Sorry that there are so many editorial nits mixed in with actual content-ful comments. I think they are all marked as such, at least. Section 1 o The lack of standard data input/output (i.e., data model) raises many challenges in system integration and often results in manual configuration tasks. (nit) I feel like this would read better with "interfaces" after "input/output". o Ease data inheritance and reusability among the various architecture layers promoting thus a network-wise provisioning instead of device-specific configuration. nit: this looks better with "thus" and "promoting" swapped. o Dynamically fed a decision-making process (e.g., Controllers, nit: s/fed/feed/. Orchestrators) with notifications that will trigger appropriate actions allowing thus to continuously adjust a network (and thus involved resources) to comply the intended service to deliver. nit: the wording here also feels a bit unusual. Perhaps: %o Dynamically fedd a decision-making process (e.g., Controllers, % Orchestrators) with notifications that will trigger appropriate % actions, allowing them to continuously adjust a network (and % thus, the involved resources) to deliver service that conforms % to the intended parameters. Section 2.2 "AP" should probably be in the list as well. We don't seem to define "PM" as such anywhere (though "Performance Monitoring" appears four or five times), but do use it in Appendix A.4.4. Section 3.1 Each level maintains a view of the supported YANG modules provided by low-levels (see for example, Appendix A). nit(?): "lower levels" Section 3.2 Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service filtering request modelled using [RFC8783] will be translated into device-specific filtering (e.g., ACLs defined in [RFC8519]) that to fulfil the service request. nit: s/that to/that/ Section 3.3 Note that it is important to correlate telemetry data with configuration data to be used for closed loops at the different stages of service delivery, from resource allocation to service operation, in particular. Is "closed loops" a well-known term in this space? Section 4.1.2 service requirements in the service request can be met (i.e., whether there is sufficient resources that can be allocated with the requested guarantees). nit: s/is/are/ In addition, a customer may require to change the underlying network infrastructure to adapt to new customer's needs and service requirements. This service modification can be issued following the same Service Model used by the service request. I'm not sure I understand what "underlying network infrastructure" means here -- are there supposed to come into being new routers because the customer issues a request in the Service Model? Section 4.1.3 Performance measurement telemetry model can tie with Service or Network Models to monitor network performance or Service Level Agreement. nit: missing article (e.g., "The performance measurement telemetry model"). Section 4.1.4 Service optimization is a technique that gets the configuration of the network updated due to network changes, incidents mitigation, or nit: s/incidents/incident/ Section 4.2.1 configuration models for network elements; the configuration information includes: [...] o Security I think we need some more details than just "Security". Are these security protocols? Security properties? Physical security? What is in or out of scope for being covered by any indicated security mechanisms? Section 4.2.2 For example, a customer creates an interface "eth-0/0/0" but the interface does not physically exist at this point, then configuration data appears in the status but does not appear in datastore. nit: I think this reads better as "if a customer creates" (added "if"). Section 4.2.3 When a configuration is in effect in a device, nit: "the ". Section 4.3 Another example is to map service parameters in the L3SM into Traffic Engineered (TE) tunnel parameter (e.g., Tunnel ID) in TE model and nit: "parameters" plural. Section 5.1 L3NM inherits
[OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-sdi-12: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-opsawg-sdi-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/ -- COMMENT: -- Thanks for the updates in the -12 (and -11? My notes claim I reviewed the -10, though the datatracker history says it was the -11; perhaps there was some skew between when I opened the doc and balloted). They get most of the way to where I want us to be, so I'm switching to No Objection. That said, the Abstract and Introduction still feel like they're slightly overstating the confidentiality protection attainable with this mechanism: The Abstract currently says "to provide confidentiality to initial configuration during bootstrapping", but we may need to hedge that a bit more, e.g., that this is partial or limited confidentiality. Similarly, Section 1 currently says "while maintaining confidentiality of the initial configuration", and would get similar treatment. Finally, I see that you took my suggestion of using "directory service" instead of "Certificate Publication Server". It may be worth a reference for this concept -- e.g., Section 2.1 of RFC 5280 references both [X.500] and RFC 4510 as potential ways to provide directory service for obtaining certificates. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-sdi-11: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-sdi-11: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/
--
DISCUSS:
--
I support Roman's discuss.
I don't think this document is sufficiently clear about the limits of
the scope of what it's trying to do.
An ideal solution in this space would protect both the confidentiality
of device configuration in transit and the authenticity (and
authorization status) of configuration to be used by the device. This
document makes no real effort to do the latter, with the device
accepting any configuration file that comes its way and is encrypted
to the device's key (or not encrypted, as the case may be), and with no
attempt to keep the device's public key secret (which is just as well).
I would expect some disucssion of this being highly desirable, but also
requiring more complicated machinery (per, e.g., BRSKI and other
voucher-based methods) and that this document aims to provide something
much simpler, at the cost of only providing limited protection.
However, even the confidentiality protection has only a limited realm of
applicability, and it seems to fall apart in some plausible threat
models.
The security considerations rightly note that an attacker with physical
access can likely extract the device private key, retrieve the encrypted
configuration file, and decrypt the configuration contents. However, I
don't think this possibility is necessarily limited to an attacker with
physical access. An attacker on the network in the IXP/POP has several
routes to getting attacker-controlled configuration on the device,
whether by uploading to the configuration server, spoofing the DHCP
response to point to the attacker's configuration server, rewriting
traffic between the device and the configuration server, etc. Once the
attacker has configuration on the device, they have a foothold by which
to gain remote access and use whatever interfaces the device provides
for decrypting configuration files and learning their contents
(potentially even by installing a "backdoor-type" access mechanism and
then running the normal install process for the legitimate encrypted
configuration, and using the backdoor to return and retrieve the
plaintext configuration information).
While this level of attacker control taking over a device in the process
of being installed is not a new attack with the encrypted configuration,
it does still limit the extent to which confidentiality protection for
configuration data is actually achievable, and I don't think the current
document text provides an accurate description of the risk and what
protection is provided.
--
COMMENT:
--
Per the discussion in the DISCUSS section, the incremental improvement
offered by this mechanism is quite limited, to the extent that I wonder
if it's worth putting effort into at all.
Abstract
The first paragraph implies that there is not currently a secure way to
initially provision the device ("if there were"), but the second
paragraph implies that there are such mechanisms ("extends existing";
"more secure"). Which is true?
(Also, I'm reluctant to describe the procedure outlined by this document
as a "secure way" to do anything; it's better to talk about the
(limited) protection that is provided for the confidentiality of
sensitive configuration data, as other aspects of security are unchanged
by this mechanism.)
Section 1
is it intended to solve all use-cases - rather it is a simple
targeted solution to solve a common operational issue where the
network device has been delivered, fibre laid (as appropriate) but
there is no trusted member of the operator's staff to perform the
initial configuration.
nit: the sentence structure here doesn't seem quite right -- the comma
before fibre sets us up for a list, but the "but" doesn't conclude a
list. Perhaps replace the comma with "and"?
Section 2
[RFC2131]). The device then contacts this configuration server to
download its initial configuration, which is often identified using
the devices serial number, MAC address or similar. This document
nit: "device's"
[RFC4122]), but this will likely make it somewhat harder for
operators to use (the serial number is usually easy to find on a
device, a more complex system is likely harder
