Subject: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Oct 2013 13:36:31 +0100

Hi,

I browsed through the draft.
Here is some feedback.
Disclaimer: I'm not a security expert, so no feedback on the security 
aspects.

-

      2.3
      <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#section-2.3>.
      Connection Closure

    A NETCONF server will process NETCONF messages from the NETCONF
    client in the order in which they are received.  A NETCONF session is
    closed using the <close-session> operation.  When the NETCONF server
    processes a <close-session> operation, the NETCONF server SHALL
    respond and close the TLS session as described in [RFC5246  <http://tools.ietf.org/html/rfc5246>]Section  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#section-7.2.1>
    7.2.1  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#section-7.2.1>.  The NETCONF server MUST NOT process any NETCONF messages
    received after the <close-session> operation.

Can the NETCONF server close the call-home function (I mean gracefully, 
not with a kill-session)?

-
From
       +--rw netconf
          +--rw tls
             +--rw enabled?     boolean
             +--rw cert-maps {tls-map-certificates}?
             |  +--rw cert-to-name* [id]
             |     +--rw id             uint32
             |     +--rw fingerprint    x509c2n:tls-fingerprint
             |     +--rw map-type       identityref
             |     +--rw name           string
             +--rw psk-maps {tls-map-pre-shared-keys}?
             |  +--rw psk-map* [psk-identity]
             |     +--rw psk-identity        string
             |     +--rw user-name           nacm:user-name-type
             |     +--rw not-valid-before?   yang:date-and-time
             |     +--rw not-valid-after?    yang:date-and-time
             |     +--rw key                 yang:hex-string
             +--rw call-home {tls-call-home}?
                +--rw client* [address port]
                   +--rw address                  inet:host
                   +--rw port                     inet:port-number
                   +--rw (connection-type)?
                   |  +--:(persistent)
                   |  |  +--rw persistent-connection?   empty
                   |  +--:(periodic)
                   |     +--rw periodic
                   |        +--rw interval?   uint16
                   |        +--rw linger?     uint16
                   +--rw reconnect-strategy
                      +--rw retry-interval?   uint16
                      +--rw max-attempts?     uint16

If the enabled boolean is yes, then both TLS AND call-home are enabled?
Don't we need a boolean for call-home?
At first glance, it seems like a flag to be set during the pre-staging phase.
I guess my question is more: how will the call home feature will be used?
Maybe it's covered by: http://datatracker.ietf.org/doc/draft-kwatsen-netconf-zerotouch/ ?
I haven't read it yet.

- Update the subject to include call home.

- Wrong draft number below

      A.1  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#appendix-A.1>.draft-ietf-netconf-rfc5539bis-03  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-03>  . . . . . . . . . . . . .24  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#page-24>
      A.2  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#appendix-A.2>.draft-ietf-netconf-rfc5539bis-03  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-03>  . . . . . . . . . . . . .25  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#page-25>
      A.3  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#appendix-A.3>.draft-ietf-netconf-rfc5539bis-02  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-02>  . . . . . . . . . . . . .25  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#page-25>
      A.4  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#appendix-A.4>.draft-ietf-netconf-rfc5539bis-00  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-00>  . . . . . . . . . . . . .26  <http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04#page-26>

- you mentioned "middle box". You might need to refer to RFC 3234

Regards, Benoit (as a contributor)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Oct 2013 13:55:32 +0100

On Wed, Oct 30, 2013 at 01:36:31PM +0100, Benoit Claise wrote:
> 
> Can the NETCONF server close the call-home function (I mean
> gracefully, not with a kill-session)?
> 

What does "NETCONF server close the call-home function" mean to you?
I think I do not understand the question.

[...]

> If the enabled boolean is yes, then both TLS AND call-home are enabled?

Yes. If there are no clients configured, no call-home will take place.

> Don't we need a boolean for call-home?

Maybe. To be discussed. I personally prefer to have this config
consistent between the TLS and SSH transport (ideally a single
grouping to be used by both). What I have is inspired by the SSH
document with some fixes applied. Would be nice to get it sorted out
in Vancouver how call home is configured for a NETCONF transport.

> At first glance, it seems like a flag to be set during the
> pre-staging phase.  I guess my question is more: how will the call
> home feature will be used?

You either ship boxes with pre-configured call-home addresses or the
call-home address is provided via some bootstrapping mechanism
(e.g. DHCP). (We once worked on an I-D discussing such bootstrapping
issues but it was shutdown in OPSAWG.)
 
> - Update the subject to include call home.

Not sure what to update.

> - Wrong draft number below

Fixed
 
> - you mentioned "middle box". You might need to refer to RFC 3234

OK

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Oct 2013 14:24:37 +0100

Jürgen,
> I think I do not understand the question.
Currently reading draft-kwatsen-netconf-zerotouch-00.txt, so reusing 
some text from that draft:
Call home function is a technique for how to establish a secure network 
management relationship between a newly delivered network device, 
configured with just its factory default settings, and the new owner's 
Network Management System (NMS).
When the newly delivered network device is fully operational, then the 
call home function should be closed, right? Who initiate this closure: 
only the NETCONF client, or could the NETCONF server also initiate it. 
Your text seems to indicate only the NETCONF client.

Or maybe you expect this call-home NETCONF session to remain up all the 
time?

I'm trying to look for answers in 
draft-kwatsen-netconf-zerotouch-00.txt, but I can only find
     "its ZeroTouch logic would be disabled the next time it boots."
> grouping to be used by both).
Make sense.
> What I have is inspired by the SSH
This draft doesn't only obsolete RFC 5539, it adds an important call 
home function
Basically add to the abstract a sentence such as

    It also provides
    an optional mechanism to establish the underlying TCP connection from
    the NETCONF server to the NETCONF client (call home).

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Oct 2013 15:45:25 +0100

On Wed, Oct 30, 2013 at 02:24:37PM +0100, Benoit Claise wrote:

> When the newly delivered network device is fully operational, then
> the call home function should be closed, right? Who initiate this
> closure: only the NETCONF client, or could the NETCONF server also
> initiate it. Your text seems to indicate only the NETCONF client.

> Or maybe you expect this call-home NETCONF session to remain up all
> the time?
 
I think this depends on the deployment. If you NC server is behind a
middlebox, you likely want to keep it calling home since otherwise
there is no way to talk to it.

As things are right now, once you remove the call home config entries,
call home attempts will stop. Hence, the NC client has always full
control over this. Should the server itself modify the configuration?
I don't know.

>    the NETCONF server to the NETCONF client (call home).

OK. I updated the abstract.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Oct 2013 18:15:11 +0000

>control over this. Should the server itself modify the configuration?

Right, this is the way to think about it - so long as the device is
configured to call home (using either SSH or TLS), it should continue to
do so ad infinitum.

ZeroTouch is related but somewhat orthogonal.   A device supporting
ZeroTouch *knows* when it has "factory default" config and, only when that
is the case, on boot, will it try to dynamically lookup an NMS to connect
to.  Ultimately, ZeroTouch ends with the device persisting the same "call
home" configuration, which then causes the above-mentioned call home logic
to kick in.

It's up to the NMS what it wants to do - it can either leave the device's
call-home config intact, letting the device call home again and again, or
it can remove that configuration because it plans to connect to the device
from that point forward.

Makes sense?

Thanks,
Kent

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 31 Oct 2013 10:24:02 +0000

Hi,

It looks to me that there is a clear distinction between the 'ZeroTouch' and the 'call home' capabilities which is not articulated clearly in the I-Ds text right now. I would not call them orthogonal, as it looks to me (please correct me if I am mistaken) that a device supporting the 'call home' functionality will support ZeroTouch as a subset. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Kent Watsen
> Sent: Wednesday, October 30, 2013 8:15 PM
> To: Juergen Schoenwaelder; Benoit Claise
> Cc: NETCONF
> Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments
> 
> 
> 
> ZeroTouch *knows* when it has "factory default" config and, only when
> that is the case, on boot, will it try to dynamically lookup an NMS to
> connect to.  Ultimately, ZeroTouch ends with the device persisting the
> same "call home" configuration, which then causes the above-mentioned
> call home logic to kick in.
> 
> It's up to the NMS what it wants to do - it can either leave the
> device's call-home config intact, letting the device call home again and
> again, or it can remove that configuration because it plans to connect
> to the device from that point forward.
> 
> Makes sense?
> 
> Thanks,
> Kent
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Benoit Claise <[email-masked]>
Date: Thu, 31 Oct 2013 12:53:19 +0100

> control over this. Should the server itself modify the configuration?

So basically, my question is around: what is the call home function?
1.  Zero touch provisioning, the managed device is operational, then 
reboots, and that's it: no more call home sessions.
2.  Zero touch provisioning, then the call home session is up all the 
time (because it's behind a middlebox)
3.  Zero touch provisioning, then, when there is something wrong, a call 
home session to the NMS (for example, a crash, looking for a bug), or 
regular scheduled call home sessions ("Hey NMS, I'm fine")

I'm not sure I've seen a clear definition somewhere.
And draft-kwatsen-netconf-zerotouch-00 
<https://datatracker.ietf.org/doc/draft-kwatsen-netconf-zerotouch/> is 
only 1 AFAICT.

Regards, Benoit

---

From: Kent Watsen <[email-masked]>
Date: Thu, 31 Oct 2013 12:04:43 +0000

Hi Dan,

You're right that one depends on the other.  Specifically, Zero Touch
depends on Call Home (either SSH or TLS), but Call Home can be implemented
without Zero Touch.

In a nutshell:

  * Call Home: the ability for the device to initiate the connection

  * Zero Touch: the ability for a device to bootstrap its Call Home
configuration

Thanks,
Kent

On 10/31/13 6:24 AM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:

>Hi,
>
>It looks to me that there is a clear distinction between the 'ZeroTouch'
>and the 'call home' capabilities which is not articulated clearly in the
>I-Ds text right now. I would not call them orthogonal, as it looks to me
>(please correct me if I am mistaken) that a device supporting the 'call
>home' functionality will support ZeroTouch as a subset.
>
>Regards,
>
>Dan