Subject: [Netconf] configuration models status and timeline

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Jul 2018 13:21:08 +0200

Kent,

I liked your presentation since it was trying to close issues. I went
through the recording and here is my short summary of where we are:

1. trust anchors / keystore -> option #1 (resolved)

2. local-or-keystore keys -> keep + feature statement (resolved)

3. move groupings to crypt-types -> ? (unresolved)

4. move algorithm identities -> ? (discussion with security people)

5. periodic connections -> periodic feature (resolved)

6. tcp keepalives -> ? (protocol layer keep alives with a feature?)

So the sticky ones are #4 and #6.

- Concerning #4, will you manage to talk to the security people this
  week and can we expect a proposal soon after?

- Concerning #6, I am not really sure what protocol layer keep alives
  are (the client sending an "empty" rpc? - this would not need any
  server configuration just a definition how empty rpcs are handled;
  we would needs something similar than for RESTCONF). If this takes
  time to work out, perhaps another option is to remove keep alives
  from the models and to keep them on the TODO list for a future
  extension?

So given this, what is your (realistic) estimation when we can have
drafts that have all issues resolved and that go to WG last call?

/js

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Jul 2018 14:25:06 +0000

Hi Juergen,

Thanks for the analysis.  I was also thinking that it seems that just a couple issues were left, and then we could go to last call, potentially well within the timeframe needed for the YANG-push set of drafts.

Regarding #4: I met with two Security+YANG folks from Huawei yesterday, who have agreed to help me with this issue.  We also plan to try to loop back in Gary Wu, who created the identities in the ietf-ssh/tls-common modules in the first place.  Our tentative plan is a meet in a couple weeks.

Regarding #6: my understanding (from Tim C. and Balazs L.) is to use some combination of a notification and an RPC to stimulate traffic.  Presumably:

  For when the NC/RC-client is the transport-initiator (normal):

    - if there is a lull, the client could send a bogus RPC of 
      some sort (e.g., an <edit-config> that selects nothing) 
      and wait for the server sends an RPC-reply.

  For when the NC/RC-server is the transport-initiator (call-home):

    - if there is a lull, the server could send a notification
      and wait for the client to send an RPC of some sort, which
      the server would, presumably, send a reply for, to complete
      the protocol transaction.  The downside to this approach
      is that it is wholly dependent on the client processing the
      notification correctly (i.e., it's not baked into the NC/RC
      protocols themselves).

  As for removing keepalives altogether, please note the SHOULD 
  in RFC 8071, S7.  Another idea is to keep them, but add an 
  enumeration called something like "protocol-layer" (which 
  protocol layer should the keepalives occur) with a single 
  built-in option ("crypto-layer"?) and then let some future 
  module augment-in an additional enum like "app-layer".

Kent // contributor

===== original message =====

Kent,

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=4E8Nhsy9GmGFI5Ky0KlbUCLjhhhqAas03fitQxUUO8E&s=ldYx8j4esE4bY5MjA-MAzlDNR4_Y_HP44z0xO-pLafI&e=>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Jul 2018 17:02:28 +0200

> Regarding #4: I met with two Security+YANG folks from Huawei yesterday, who have agreed to help me with this issue.  We also plan to try to loop back in Gary Wu, who created the identities in the i…

Good. Sooner is better. ;-)
 
>       and wait for the server sends an RPC-reply.

Ideally, the keep alive would just be handled at the session layer. I am
not sure where the NC spec allows

C: <rpc message-id="101"
C:      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
S: <rpc-reply message-id="101"
S:      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>

otherwise one could define a noop RPC (I am not sure invoking a fake
edit-config is necessarily a good idea).

>       notification correctly (i.e., it's not baked into the NC/RC

If you do call-home, there is still a client who could send keep alive
messages. But yes, if you only stream notifications, then the server
receives no feedback from the client in NETCONF (and I assume the same
it true for RESTCONF notification streams).  So here it is easier to
say "protocol keep alive" than it is to work out the details.

>   in RFC 8071, S7.

Yep, but this text is specific for TLS and SSH and it seems TLS
libraries practically have an issue here.

>   Another idea is to keep them, but add an 

My point is that working out protocol layer keep alives is not as easy
as it may sound (unless someone has a solution I can't think of) and
the question is whether we want to hold off the documents until
someone found a solution. It seems, we can define crypto layer
keep-alives with a feature and then implementations will have to deal
with this (for SSH this seems less an issue, so this affects NC over
TLS primarily and also RC) and perhaps we can also define TCP layer
keep-alives with a feature and with a warning attached to it (could be
that the security ADs are OK with that if the warning makes the issues
clear). For both keep-alives, we know how they would work.

Protocol layer keep-alives are something new to be invented and it is
somewhat unclear how they would work for the notification streaming
case. It seems protocol layer keep-alives can be developed separately
and then augmented in where the keep-alives are configured. A short
RFC that details how the keep-alive messages work plus an augmentation
of the configuration model (perhaps even just the definition of another
identity).

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Jul 2018 15:57:11 +0000

> Ideally, the keep alive would just be handled at the session layer.

The NC/RC session layer, agreed.  And, per the budding statement [1],
it is RECOMMENDED that protocol designers always include an aliveness
check mechanism in the protocol.

> I am not sure where the NC spec allows
>
> C: <rpc message-id="101"

I don't think it does either.

> otherwise one could define a noop RPC (I am not sure 
> invoking a fake edit-config is necessarily a good idea).

True, it might show up in the logs, and there could be access
control restrictions.  Alternately, a malformed RPC could be
purposely sent, with the *goal* of receiving an RPC-error.
This should work for both NC and RC.

> If you do call-home, there is still a client who could send keep
> alive messages. But yes, if you only stream notifications, then 
> the server receives no feedback from the client in NETCONF (and 
> I assume the same it true for RESTCONF notification streams).  
> So here it is easier to say "protocol keep alive" than it is to
> work out the details.

Agreed, this is more complicated.  Sadly, per S7, the call-home
case is when the keepalives are needed the most.

> libraries practically have an issue here.

True.  Be aware that today's tsv-area open meeting will discuss 
the budding statement [1].  The ADs are aware that a partial goal
is encourage TLS-library maintainers to support TLS-keepalives.

> My point is that working out protocol layer keep alives is not
> as easy as it may sound (unless someone has a solution I can't
> think of) and the question is whether we want to hold off the
> documents until someone found a solution. 

I do not recommend holding off publishing these documents for this.
The folks asking for this said that, if IETF doesn't put something
into the standard model, they would augment in what they need. 
That said, I do think that we should perhaps switch to using an 
enumeration or an identity so that such extensions can be mixed in
easily in the future.  The only counterpoint might be that such 
would disable the ability to do aliveness checks at multiple 
protocol layers simultaneously, though I don't know if that would
ever be desired or even, perhaps, not recommended.

> It seems, we can define crypto layer keep-alives with a feature
> and then implementations will have to deal with this (for SSH 
> this seems less an issue, so this affects NC over TLS primarily
> and also RC) and perhaps we can also define TCP layer keep-alives
> with a feature and with a warning attached to it (could be that
> the security ADs are OK with that if the warning makes the issues

Agreed and, FWIW, it seems that the folks asking for this would the
happy, or maybe just "okay", with TCP-keepalives. As you say, we
know how to do it.  The only issue is that the budding statement 
[1] has a "SHOULD NOT" around this, though it seems that a warning
such as you suggest would suffice.  Would the WG like to try this?

> Protocol layer keep-alives are something new to be invented and
> it is somewhat unclear how they would work for the notification
> streaming case. It seems protocol layer keep-alives can be 
> developed separately and then augmented in where the keep-alives
> are configured. A short RFC that details how the keep-alive
> messages work plus an augmentation of the configuration model
> (perhaps even just the definition of another identity).

Yup.

[1] https://mailarchive.ietf.org/arch/msg/tsv-area/fmz3WMUmZUiRUMm2AJgsA85QY94

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Jul 2018 18:42:32 +0200

> ever be desired or even, perhaps, not recommended.

Since liveness at layer N likely implies liveness at layers < N, one
think liveness test is good enough. One thing you may watch out for
are keep-alive parameters. I would not be surprised if the amount of
control an application has over the parameters varies widely. (But
perhaps that is then a matter of deviations.)

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jul 2018 11:01:41 -0700

On Wed, Jul 18, 2018 at 8:02 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > Thanks for the analysis.  I was also thinking that it seems that just a
> couple issues were left, and then we could go to last call, potentially
> well within the timeframe needed for the YANG-push set of drafts.
> >
> > Regarding #4: I met with two Security+YANG folks from Huawei yesterday,
> who have agreed to help me with this issue.  We also plan to try to loop
> back in Gary Wu, who created the identities in the ietf-ssh/tls-common
> modules in the first place.  Our tentative plan is a meet in a couple weeks.
>
> > Regarding #6: my understanding (from Tim C. and Balazs L.) is to use
> some combination of a notification and an RPC to stimulate traffic.
> Presumably:
> >

I prefer an <no-op> RPC for this purpose.
It would be better if the session counters were not affected,
but that would require protocol changes.
Causing error counters to increment for keep-alives is bad.

Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Rohit R Ranade <[email-masked]>
Date: Thu, 19 Jul 2018 03:20:38 +0000

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: 18 July 2018 23:32
To: Juergen Schoenwaelder <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked]
Subject: Re: [Netconf] configuration models status and timeline

<snip>

C: <rpc message-id="101"

[Rohit R Ranade] +1

Andy

---

From: "Beauville, Yves (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 19 Jul 2018 17:23:20 +0200

Kent, Andy and Rohit,

Could we use a get request with an empty filter, as defined in section 
6.4.2 <https://tools.ietf.org/html/rfc6241#section-6.4.2> of RFC6241?

This looks like the smallest and less impacting RPC defined in the RFC.

Isn't it a good candidate for an aliveness check?

Yves

On 19-07-18 05:20, Rohit R Ranade wrote:
>
> *From:*Netconf [mailto:[email-masked]] *On Behalf Of *Andy 
> Bierman
> *Sent:* 18 July 2018 23:32
> *To:* Juergen Schoenwaelder <[email-masked]>; 
> Kent Watsen <[email-masked]>; [email-masked]
> *Subject:* Re: [Netconf] configuration models status and timeline
>
>     <snip>
>
> */[Rohit R Ranade] /*+1

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Sun, 29 Jul 2018 22:49:21 +0200

Hi Yves,

Below my comments.

Regards,
Ariel

> Isn't it a good candidate for an aliveness check?
An empty filter retrieves the whole configuration; which can take a  
lot space and time.

I would rather use, as filter of the RPC 'get', the 'current-datetime'  
or the 'boot-datetime'.

[1] https://tools.ietf.org/html/rfc7317#section-3.2
>> *From:*Netconf [mailto:[email-masked]] *On Behalf Of *Andy Bierman

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr