Re: [Netconf] update to client/server drafts

Martin Bjorklund <mbj@tail-f.com> Thu, 07 June 2018 11:27 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F631310E8 for <netconf@ietfa.amsl.com>; Thu, 7 Jun 2018 04:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ_XKW2z3qT1 for <netconf@ietfa.amsl.com>; Thu, 7 Jun 2018 04:27:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D699D1310E3 for <netconf@ietf.org>; Thu, 7 Jun 2018 04:27:10 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 348B41AE0309; Thu, 7 Jun 2018 13:27:05 +0200 (CEST)
Date: Thu, 07 Jun 2018 13:27:04 +0200
Message-Id: <20180607.132704.900255711945242973.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <FEB7E46B-D28B-4C68-8B20-DB03BAB0FCC7@juniper.net>
References: <FEB7E46B-D28B-4C68-8B20-DB03BAB0FCC7@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/OpjMS8H0Hc_9_WqzlII0oK_nROk>
Subject: Re: [Netconf] update to client/server drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2018 11:27:15 -0000

Hi,


Kent Watsen <kwatsen@juniper.net> wrote:
> 
> All drafts updated! It looks like a big change, but almost all of it
> goes to:
> 
>  1) the introduction of the new crypto-types and trust-anchors modules
> 
>  2) the resurrection of the keystore module, along with groupings 
>     enabling keys to be locally-defined of a reference to a key in
>     the keystore module
> 
>  3) reformatting all YANG modules to not exceed 69 chars/line.
> 
> 
> 
> 
> To recap, the relationship between these drafts is:
> 
>                      crypto-types
>                        ^      ^
>                       /        \
>                      /          \
>            trust-anchors      keystore
>               ^      ^------+    ^   ^
>               |              \   |   |
>               |      +-----------+   |
>               |     /          \     |
>        ssh-client-server      tls-client-server
>         ^                      ^           ^
>         |                      |           |
>         |            +---------+           |
>         |           /                      |
>  netconf-client-server          restconf-client-server
> 
> 
> 
> 
> 
> I have some questions for the WG:
> 
>  1) no regrets about trust-anchors being separate from keystore,
>     right?

Well, when the name was changed to trust-anchors, the idea was to
remove keystore.  Now we have a config tree in keystore again, so the
situation is a bit different.

The alternative would be a single module with:

     +--rw keystore
        +--rw asymmetric-keys
        +--rw pinned-certificates* [name]
        +--rw pinned-host-keys* [name]

or maybe:

     +--rw keystore
        +--rw asymmetric-keys
        +--rw trust-anchors
           +--rw pinned-certificates* [name]
           +--rw pinned-host-keys* [name]


BUT, I don't think we should overengineer this.  I don't have a strong
opinion either way.

>  2) are we happy with keystore's "local-or-keystore" groupings
>     (not too complicated?)

>From a modelling pow it looks fine.  But what is the use case for the
"local" case?  Should it have an "if-feature"?

>     and, if yes, should we have a similar
>     ability for trust-anchors (e.g., a "local-or-trust-anchor"
>     grouping like in the keystore module)?

If there is a use case for non-central keys in keystore, I assume the
same use case applies to trust anchors?

>  3) should some of keystore's groupings be moved to crypto-types?
>     e.g., asymmetric-key-grouping isn't a keystore-specific
>     concept.

Seems reasonable.

>  4) should trust-anchors include SSH host keys at all?  Maybe this
>     draft should define two modules (x509-trust-anchors and
>     ssh-trust-anchors)?

I don't think that is necessary.  Maybe use features though.

>  5) should algorithm identities be moved from ssh/tls-client/server
>     to crypto-types?

Which identities do you mean?

>  6) should we add a "periodic" feature to the netconf/restconf
>     client/server drafts, enablings the initiating peer to
>     optionally support periodic connections? 

I don't think it is necessary, but won't object to it being added.

BTW, why does "persistent" have an idle timeout?  It seems to me it
will just immediately reconnect after termininating the session due to
idleness.


/martin



> 
> I'll start a thread for each later, my only goal for mentioning
> them here is to get people thinking about such things when looking
> at these drafts. 
> 
> 
> 
> 
> Next steps:
> 
> My current plan is to update the zerotouch draft next, to make use
> of the new trust-anchor and keystore drafts, in the example device
> configuration module in the Appendix.
> 
> Once the zerotouch draft is submitted for publication, I'll swing
> back around to these drafts, hopefully updating them one more time
> before Montreal.
> 
> In the meanwhile, it would be awesome if you all could take a good
> look at these.  You really only need to look at the YANG modules
> themselves, but I still recommend looking at the drafts, which
> contain tree diagrams and examples that makes everything easier
> to understand.
> 
> 
> 
> Thanks,
> Kent // contributor
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>