Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

[cc-ing my co-authors, as they're beginning to convert crypto-types back to identities again]


Rob et. al.,

> I tend to agree that sometimes less modules is more. For me, the
> problem is likely more that I am not entirely sure what the proper
> base types would be, which may depend on what exactly they are used
> for. I guess I wait until I see the description text...
>  
> Okay, we'll keep just the one YANG module.
> [RW]
> Do you mean one module for all the identities of just the base identities?
> 

Dunno.   

Identities provide the desirable benefit of hierarchy and extensibility, but they come with the weight of the module needing to be implemented (not just imported) in order for the identity to be defined.  This is how YANG works; it would've been better if, e.g., identities could be defined by "implemented" via YANG-library...

The thing with crypto algorithms, the algorithms a server supports is a matter of importance, e.g., because the algorithm isn't approved for use on the network.  The ability to configure algorithms supported is not currently present in the ssh-client-server and tls-client-server drafts, as I was hoping it could be added later as a -bis extension or an update, but perhaps it should be, in order to drive this problem, to ensure a proper crypto-types solution.

Working within the current YANG construct, one possible solution would be to define every algorithm identity in its own module, thus enabling servers maximum flexibility to describe which are supported.  The ostensible negative is that doing so would produce many modules.  While not a computer problem, it could become onerous.

Another idea is to not use identities either (in addition to enumerations), but instead define a data model that preserves the extensibility of identities without needing to implement modules.  For instance, instead of assuming the "algorithm" field is an 'identityref', perhaps a "leafref" is used.


ietf-crypto-types.yang snippet:

	// protocol accesible nodes  (note: config false)
	list algorithms {
	  config false;
	  key name;
	  leaf name {
	    type string;
	    description "The name of a collection of algorithms.  Suitable values are defined in the TBD IANA registry...";
	  }
	  list algorithm {
	    key name;
	    leaf name {
	      type string;
	      description "The name of an algorithm.   Suitable values are defined in the TBD IANA registry...";
	    }
	  }
	}    

	grouping public-key {
          leaf algorithm-type {
	    type leafref {
	      path "/ct:algorithms/ct:name";
	      require-instance false;
	    }
	    must '../algorithm';
          }
	  leaf algorithm {
	      type leafref {
	        path "/ct:algorithms[ct:name = current()/../algorithm-type]/ct:algorithm/ct:name";
	        require-instance false;
	      }
	    must '../algorithm-type';
	  }
	}


PROs:
  - allows a server to advertise (in <operational>) which algorithms it supports without any need to implement a module, other than crypto-types.
  - supports extensibility via IANA registries.  Sequence:  RFC updates registry --> server supports --> client configures to use.
  - "require-instance false" enables YANG-based config validations to succeed w/o presence config false data.

CONs:
  - only one level of hierarchy (would more every be needed?)
  - "require-instance false" enables YANG-based config validations to succeed even when misconfigured (though commit should fail).


Thoughts?

Kent // contributor