Re: [yang-doctors] Yangdoctors early review of draft-ietf-opsawg-nat-yang-06

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Oct 30, 2017 at 02:41:19PM +0000, [e-mail] wrote:
>  That said, there are a number of details where I doubt
> > the model is correct and things where I believe things are incomplete.
> > Given that there are many different NAT functions, I also expected to
> > see usage of YANG features.
> 
> [Med] We used to make use of "features", but there was a comment during the WG call for adoption that requested us to make use of identities, instead.

But these are not the same thing. If I am not a nat64, then apparently
several objects to not apply to me. This is what features allow you to
express. Perhaps someone wanted identities for something different, I
do not know. I think it is reasonable to assume that not all NAT
implementations will support all types of NATs that the model supports
and hence the model should reflect this.

> > 
> > - What is the vrf-routing-instance identity good for?
> 
> [Med] This is used to bind a NAT function to an external VRF routing instance. Please check https://www.ietf.org/mail-archive/web/opsawg/current/msg05117.html 
>

I very much doubt that an identity identifies a VRF instance. I am not
questioning the need to identify a VRF, I am questioning that the
solution put in place achieves this.

> >   Its used only in
> >   the leaf external-vrf-instance and the description of that leaf is
> >   not telling me how this is going to be used. Who is going to derive
> >   identities? I fear you are trying to achieve something where using
> >   identities is really the wrong approach. Section 2.10 does not tell
> >   how this is supposed to work either. I assume this needs to be
> >   checked by the routing area experts to make sure things fit with
> >   their modeling of VRFs.

And this was my explanation why I believe this identity thing does not
work. You need to make work this out with the people modeling VRFs.
 
> > - mapping-entry/type: instead 'manually configured', I would write
> >   'explicitly configured' (configuration does not have to be a manual
> 
> [Med] Manually is derived from RFC6887, which says: 
> 
>       *  Explicit static mappings are created by manual configuration
>          (e.g., via command-line interface or other user interface) and
>          persist until the user changes that manual configuration.

Note the word 'explicit' there. I assume this boils down in NMDA terms
to configuration ending up in <intended> and I prefer explicit
configuration since configuration ending up in <intended> can very
well come from automated systems, i.e., there is not necessarily a
manual process.

>  And is
> >   this a ticking lifetime, i.e., this changes on every get request? Is
> >   this useful? Have alternatives been considered such as reporting the
> >   point in time when the mapping was established? Or is the idea that
> >   the lifetime reports the time left until the mapping will be garbage
> >   collected? What does "tracks the connection" really mean here?
> 
> [Med] The initial value indicates the duration to maintain a mapping. When retrieved in a get operation, it indicates the remaining validity lifetime.  
> I updated the text to clarify this.

This means this is constantly changing. If you would return the
timestamp when the lifetime ends the value would change rarely. The WG
needs to think about the choice. Note that constantly changing values
are potentially a burden with telemetry interfaces and caches but this
may not apply here. The WG should discuss what the right choice is
here.

> > - container nat-capabilities:
> > 
> >   Here we find a bunch of "config true" leafs and I wonder how these
> >   work. There are things a NAT implementation is capable to do, and
> >   there are things that are enabled in a NAT deployment and of course
> >   you can't enable something in a deployment that has not been
> >   implemented. So are these 'capabilities' more like NAT features
> >   enabled (since we have "config true" nodes) or are these more
> >   implemented capabilities (but then "config true" may be wrong)?
> 
> [Med] These are about what an implementation is able to do. When I set config to "false", pyang is complaining.

If leafs are not configurable, then they should be config false.
 
> >   Depending on the answer, did you consider using YANG features?
> 
> [Med] Yes, we considered the YANG features.

I do believe you want features. Now, if an implementation supports
multiple different NATs, how do I tell the NAT which type of NAT
function applies to a given packet? Is this always clear?

> > - Some nat type specific parameter lists are flat, for others there is
> >   an additional container. Is this by design?
> 
> [Med] Yes, the design was built with NAT/NAT64 as the core functionality. Other specific-techniques are added as containers for clarity. 
>

Hm. Perhaps a bit subtle without a description.
 
> >   Is this restricted to the acronyms that are used in the IANA
> >   protocol numbers registry?
> 
> [Med] Yes.  

So please state this.
 
> > - alg-name
> > 
> >   Is there a list of well-known ALG names? IANA? Or is this a random
> >   string that one needs to guess form the vendor's documentation,
> >   i.e., this is potentially not interoperable out of the box? Is there
> >   a way to obtain the number of ALGs supported or is the idea to do
> >   trial and error probing to find out (which is even harder if there
> >   are no well-known ALG names)?
> > 
> 
> [Med] There is no "standardized/IANA" list of ALGs. There is a list of widely deployed/implemented ones.
> FWIW, we used to have this list: 
> 
>     |        +--rw ftp-alg-enable?              boolean
>     |        +--rw dns-alg-enable?              boolean
>     |        +--rw tftp-alg-enable?             boolean
>     |        +--rw msrpc-alg-enable?            boolean
>     |        +--rw netbios-alg-enable?          boolean
>     |        +--rw rcmd-alg-enable?             boolean
>     |        +--rw ldap-alg-enable?             boolean
>     |        +--rw sip-alg-enable?              boolean
>     |        +--rw rtsp-alg-enable?             boolean
>     |        +--rw h323-alg-enable?             boolean
>     |        +--rw all-algs-enable?             boolean
> 
> We changed the design to this one because it is easily extensible.

Well, as long as it is clear what an ALG name is...
 
> [Med] Yes. 
> 
> > 
> > - logging-info
> > 
> >   Is this information complete? Perhaps it is for plain syslog
> >   (without any security) but I doubt the info is complete for the
> >   other transports mentioned, at least not for FTP. And surely, if you
> >   want to protect the logging information, then you will neeed way
> >   more parameters. And what does 'retrieving' logging entries mean?  I
> >   assume with syslog and ipfix you push log messages. I am less sure
> >   about FTP. Perhaps less is more and simply provide support for
> >   syslog and leave the other options for extensions. You have a choice
> >   in place, so not need to go and deal with all possible complexity
> >   here.
> > 
> 
> [Med] It is out of scope of specify the exact logging information. Those considerations are out of scope. We only focus on the protocol and the server information.

I think my comment was saying that the information is not sufficient to
talk to a server.

>  I think it would help to be more specific
> >   about the security aspects of this data model. This text is quite
> >   generic.
> 
> [Med] The text Acks that all information are sensitive. They must be protected and secure means must be used.

A generic statement - in the past you there usually was a problem
getting such generic statements through the approval process since
security people want authors to think through the security aspects of
individual objects or groups of related objects. But you can try of
course, perhaps the mindset has changed - and I am not a secdir
reviewer. ;-)

>  With a NAT, things even have privacy aspects. If I can
> >   force a specific NAT mapping, I can track a subscriber.
> 
> [Med] IMHO, this is not specific to the NAT. Mandating secure means to control the NAT is a guard against such attack.  

I think this is actually more subtle than one might think but this is
the job of the security directorate people to think about.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>