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

From: Kyle Rose via Datatracker <[email-masked]>
Date: Mon, 22 Nov 2021 09:55:54 -0800

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.

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.

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 23 Nov 2021 10:04:37 +0900

Hi  Kyle,
I will address your valuable comments on this draft.

Thanks.

Best Regards,
Paul

On Tue, Nov 23, 2021 at 2:57 AM Kyle Rose via Datatracker <[email-masked]>
wrote:

> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

---

From: t petch <[email-masked]>
Date: Wed, 24 Nov 2021 10:53:28 +0000

> 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

> .