Re: [Last-Call] [I2nsf] Secdir last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22/11/2021 17:55, Kyle Rose via Datatracker wrote:
Reviewer: Kyle Rose
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
  Document editors and WG chairs should treat these comments just like any other
last call comments.

This document Has Issues.

I don't actually have a lot to say about this document from a security
perspective: its purpose is to describe, using YANG, a data model intended as
the basis for configuration schemas developed for implementations of the
Interface to Network Security Functions (I2NSF) framework. Security
considerations for the most part should be addressed in documents describing
system architecture or normatively detailing how implementations are to make
use of the data model described here. I'm not going to relitigate any such
issues here.

The main issues I found in this document are ones that I, as someone not
terribly familiar with YANG, found troubling from a general engineering
perspective. These are best illustrated by example:

  * Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) `-address`
  defined here? These concepts are generic enough that they should be in modules
  of their own to minimize variation among data models and the errors that will
  inevitably result from capturing the same concept in slightly different ways
  that are not obvious to the user. * Overall, I have to imagine that much of
  the `nsfintf` data model is generic enough that it should be captured
  externally. For instance, `tcp-flags`, `port-range`, `flow-label`, `dscp`,
  etc. are generally useful elements of an abstract transport data model that
  they shouldn't be defined here, but rather incorporated from an external data
  model that is maintained by those in (for example) the transport area.

Am I just commenting on the YANG ecosystem in general? If these are standard
practices, then the overall ecosystem has major latent problems. Ideally, a
particular YANG module seems like it should describe only those elements
defined at a particular layer, in this case rules and actions, and use
reference external modules for elements that are defined at lower layers.

The overall ecosystem has major latent problems IMHO but it is the IETF ecosystem that has them. It is very hard to get one WG to collaborate with another (and sometimes they wilfully trample on another's toes:-(

Yes, there a lots of e.g. transport-related items that could be in a transport module are imported by the other WG that need them. I tried to get the TCPM WG interested in draft-ietf-opsawg-l3sm-l3nm which e.g. redefined the flags in the TCP header, and mostly failed. Likewise I sought to get the LSR WG interesed in a redefinition of OSPF but failed. The IETF does not work that way.

Even the NETMOD WG, which might have claim to primacy with YANG, has failed to progress a common module, 6991bis, which has several generally useful constructs over and above RFC6991; the author recently asked on the NETMOD list if it was time to give up - I have not seen a reply. Over the years, I have seen I-D import 6991bis and have suggested they duplicate the definitions as there is no guarantee the 6991bis will ever become an RFC.

Equally the NETCONF WG has spent many years, performed many summersaults, and has yet to produce common modules for the netconf protocol, especially with security aspects thereof.

Closer to home, I first reviewed the i2nsf sdn module which is now an RFC. I failed to realise that there were another five or more overlapping I2NSF modules which cried out for a common module but which instead did not agree on naming, strucure and so on. By then, these I-D had been long in the making and my sense was and is that the WG does not have the energy to undertake such a major rethink in the approach so I focussed instead on getting the I-D more in line, using the same identifiers and structure, as the WG list will show.

So, when it comes to the common good, the IETF structure militates against it. I think that the early work on YANG succeeded because it was building on SMI, which had had decades to get it right (or not), and on the existing DDL of a major manufacturer. OPSAWG recently produced a common module for VPN, doing so after two of the four potential importers were RFC, and having it last called with the third. Now the fourth is in last call, suggestions have been made how the common should be improved - too late! Do it early, do it late, either way the IETF is not organised for it.

Tom Petch

Also some nits:

  * `ipvX-address` describes a subspace of the global IPvX address space, not a
  single address. The name is going to cause problems. * The descriptions given
  are often (usually?) just restatements of the entity name. Example is
  `identity priority-by-order` described as "Identity for priority by order".
  The description should provide some value for the user beyond simply restating
  the name. * The headings in section 5 should be clearly labeled with the word
  "example", such as "Example Security Requirement 1". * IPv6 addresses in text
  MUST be represented in lowercase, according to RFC 5952 section 4.3.


_______________________________________________
I2nsf mailing list
I2nsf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/i2nsf
.


--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux