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

[<[e-mail]>]

Hi Jüergen,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Juergen Schoenwaelder [mailto:[e-mail]]
> Envoyé : lundi 30 octobre 2017 17:22
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
> 
> 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.

[Med] You are right. Sorry for not being clear. 

What I meant is that the module used, for example, "if-feature nat64" and so on to refer to NAT flavors. We replaced those with "when" statements that points to the actual capabilities of an implementation. 
Another change we made, is that we used to have "Boolean" to indicate the support of a given tarnation scheme (e.g., nat64-support, nat44-support), but we updated those to make use of identities. 


 If I am not a nat64, then apparently
> several objects to not apply to me.

[Med] Yes. We tried to cover this by "when" statements. 

 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.
> 

[Med] The module indicates what a given implementation has to support based on its capabilities. This is handled by means of "when" statements.   

> > >
> > > - 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.

[Med] Thank you for clarifying. This is actually a good point. The options we considered are as follows: 

(1) Use an Identity to avoid struggling with semantics of how a VRF can be defined.
(2) Point to draft-ietf-rtgwg-ni-model, likely (?) as a normative reference. 
(3) Remove the VRF thing from the draft; future extensions can be defined.

Given that "VRFs" are not required for all NATs and some reviewers asked to add VRFs in addition to interfaces, we went for option (1). Having a dependency on a YANG module under development is not justified for all implementations. 

> 
> > >   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.

[Med] I hear you. FYI, there is no "manual" mention in the new revision of the draft. 

> 
> >  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.

[Med] That's another option which has implications on the NAT implementation itself. We modeled the YANG module to be aligned with current NAT implementations.  

 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.

[Med] I will revert config to false as we used to have in previous versions. As I said earlier, pyang will cry. I don't know how to fix that. 

> 
> > >   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?

[Med] The current module allows for implementations that support many translation flavors. In particular, it allows for a same NAT instance to enable many features in the same time.

There is no need to indicate explicitly the translation scheme(s) to enable because this will be implicitly deduced from the configuration parameters. For example: 
- an implementation supplied with an external IPv4 address pool only, will automatically behave in the base NAT mode.
- an implementation supplied with an external IPv4 address pool and port-related parameters will behave in the NAPT mode.
- an implementation supplied with an external IPv4 address pool, port-related parameters, and NAT64 prefixes will behave in the statefull NAT64 mode
- an implementation supplied with an external IPv4 address pool, port-related parameters, dst-nat-enable=true, and dst-ip-address-pool will behave in the NAPT mode + destination NAT

and so on. 


> 
> > > - 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.

[Med] Fixed in my local copy. 

> 
> > > - 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] Actually, what is more important is the protocol/port. 

BTW, I updated the module to indicate src and/or dst ports. 

> 
> > [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.

[Med] It is only about the minimal set of information. The information is not complete on purpose. Protocol-specific information is out of scope of this document. 

> 
> >  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.
> 

[Med] You are probably right, but I prefer to leave those for the secdir reviews. 

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