Subject: [Netconf] regarding combining reverse-tls and reverse-ssh

From: Kent Watsen <[email-masked]>
Date: Tue, 19 Nov 2013 20:00:36 +0000

There was consensus in the Vancouver meeting to combine the YANG modules
for reverse-ssh and reverse-tls.  I want to suggest a few options.

Current Status:

          RFC5539bis              RFC6242
   (call-home + YANG module)         ^
                                     |
                                     |
                              Draft reverse-ssh
                          (call-home + YANG module)

Option #1:

          RFC5539bis              RFC6242
          (call-home)                ^
               ^                     |
                \                    |
                 \           draft-reverse-ssh
                  \             (call-home)

                   \                 ^
                    \               /
                     \             /
                      \           /
                  draft-call-home-config
                    (just YANG module)

Option #2:

          RFC5539bis           RFC6242bis
          (call-home)    (call-home text added)
               ^                   ^
                \                 /
                 \               /
                  \             /
                   \           /
               draft-call-home-config
                 (just YANG module)

Option #3:

            RFC5539bis             RFC6242
     (call-home text removed)   (no call-home)
                 ^                   ^
                  \                 /
                   \               /
                    \             /
                     \           /
                draft-netconf-call-home
               (call-home + YANG module)

Thoughts:
  - Both #2 or #3 achieve symmetry (symmetry good, yes?)
  - Only #3 provides a complete-solution, defining both
    protocol and config, for both SSH & TLS.
  - Thinking about possible further transports, any option seems
    OK, assuming config will always need to be revisioned...

What do you think?

Thanks,
Kent

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 19 Nov 2013 20:21:01 +0000

#3

Cheers, 
Mehmet 

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of ext Kent Watsen
> Sent: Tuesday, November 19, 2013 9:01 PM
> To: Netconf
> Subject: [Netconf] regarding combining reverse-tls and reverse-ssh
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Nov 2013 21:32:57 +0100 (CET)

Hi Kent,

I prefer #2.  I think it makes sense to keep all transport-specific
details in one document, and have a separate document to configure
them.

I can think of option #4 as well, but I think it is overkill:

           RFC5539bis           RFC6242bis
           (call-home)    (call-home text added)
         augment model         augment model
           w/ tls-stuff          w/ ssh-stuff
                 \                 /
                  \               /
                   \             /
                    \           /
                     V          V
                draft-netconf-server-config
               (YANG module w/ netconf-server specific
                config, including call-home)

Actually, maybe option #2+ would be a netconf-server specific data
model with more things than just call home, specifically normal listen
address + port and timeouts etc.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Nov 2013 23:33:10 +0100

>     OK, assuming config will always need to be revisioned...

The config in RFC5539bis is more than just call home hence the options
all seem somewhat problematic. For me, the easiest and most sensible
to do is to do RFC5539bis including the call home mechanism and
separately the call home mechanism for SSH (this might later be merged
into RFC6242bis but I do not think it is necessary to revise RFC6242
just because of this). In addition to this, we should create a NETCONF
configuration module:

RFC5539bis (NC over TLS and NC over TLS call home)
RFCXXXX    (NC over SSH call home)
RFCYYYY    (NC configuration data model)

This slightly expands the scope of the YANG module but also puts all
NC configuration parameters into a simple single YANG module (not
everybody liked the submodule setup currently in the RFC5539bis
draft).

/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: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Nov 2013 13:58:29 +0100 (CET)

> RFCYYYY    (NC configuration data model)

This is essentially my option #2+, but using a separate document for
SSH call home.  This suggestion is fine with me, although I am not
sure why 6242bis would be problematic.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Nov 2013 17:20:11 -0800

Hi,

> ...
I do not have strong preferences for 1 option over another but
I strongly support RFCYYYY.  I don't like submodules but I like
the idea of organizing all the NETCONF configuration under the
/netconf container.  If all the YANG is in 1 RFC, even better.
It is all in 1 namespace and it is clear to everyone where to
find the NETCONF protocol configuration YANG module.

/js

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Nov 2013 09:04:16 +0100

> sure why 6242bis would be problematic.

+1

I'd also support 5539bis, 6242bis and YYYY.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 21 Nov 2013 11:14:44 -0500

> for reverse-ssh and reverse-tls.  I want to suggest a few options.

I like Option #2.  I think it presents a decent evolution of what is 
there today.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Thu, 21 Nov 2013 21:43:02 +0000

I prefer to remove ssh and just use TLS. Simplifies everything and voids
this discussion.

I had the "why do we need ssh and TLS, if we can remove complexity and
increase security by just using TLS" discussion before but beside Kent
nobody voiced an opinion.

regards,

ralf

On Thu, Nov 21, 2013 at 4:14 PM, Joe Marcus Clarke <[email-masked]>wrote:

> I like Option #2.  I think it presents a decent evolution of what is there
> today.
>
> Joe
>
>
>
>> Current Status:
>>
>>            RFC5539bis              RFC6242

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 22 Nov 2013 00:24:17 -0500

SSH was the preferred protocol expressed in a poll of operators (by a wide
margin as I recall).

I think offering both SSH and TLS addresses the needs of interactive and
programmatic approaches well.

I support keeping both.

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: Netconf [mailto:[email-masked]] On Behalf Of Ralf Skyper
Kaiser
Sent: Thursday, November 21, 2013 4:43 PM
To: Joe Marcus Clarke
Cc: Netconf
Subject: Re: [Netconf] regarding combining reverse-tls and reverse-ssh

regards,

ralf

On Thu, Nov 21, 2013 at 4:14 PM, Joe Marcus Clarke <[email-masked]>
wrote:

Joe

Current Status:

           RFC5539bis              RFC6242

Option #1:

           RFC5539bis              RFC6242
           (call-home)                ^
                ^                     |
                 \                    |
                  \           draft-reverse-ssh
                   \             (call-home)

                    \                 ^
                     \               /
                      \             /
                       \           /
                   draft-call-home-config
                     (just YANG module)

Option #2:

           RFC5539bis           RFC6242bis

Option #3:

             RFC5539bis             RFC6242

Thoughts:

What do you think?

Thanks,
Kent

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>          c i s c
o  S y s t e m s
Email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 22 Nov 2013 08:09:16 +0100 (CET)

> programmatic approaches well.

I also support keeping both.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Nov 2013 08:27:43 -0800

Hi,

The WG charter explicitly states the call-home mechanism will
be developed for both SSH and TLS. For various reasons, SSH is
the mandatory-to-implement transport for NETCONF. Perhaps if we
were starting from scratch today, TLS would be the only transport,
but we started around 2004, not today.

Andy

---

From: Carl Moberg <[email-masked]>
Date: Fri, 22 Nov 2013 08:46:37 -0800

NETCONF over SSH is in very wide commercial deployment and is in at least 20+ implementations of networking equipment. 

 I don’t know of a single NETCONF over TLS implementation that is in use.

 My opinion is that SSH is required and TLS would be a great addition.

On 21 Nov 2013, at 13:43 pm, Ralf Skyper Kaiser <[email-masked]> wrote:

> I prefer to remove ssh and just use TLS. Simplifies everything and voids this discussion.
> 
> I had the "why do we need ssh and TLS, if we can remove complexity and increase security by just using TLS" discussion before but beside Kent nobody voiced an opinion.
> 
> regards,
> 
> ralf
> 
> 
> 
> On Thu, Nov 21, 2013 at 4:14 PM, Joe Marcus Clarke <[email-masked]> wrote:
> I like Option #2.  I think it presents a decent evolution of what is there today.
> 
> Joe
> 
> 
> 
> Current Status:
> 
>            RFC5539bis              RFC6242

--
Carl Moberg
VP Technology
twitter: @cmoberg
http://www.tail-f.com/

---

From: Kent Watsen <[email-masked]>
Date: Fri, 22 Nov 2013 19:42:34 +0000

I also don't know of any NC over TLS deployments.   Juniper doesn't even
support it.   

The SSH transport is very intuitive with regards to mapping the user.  The
TLS transport requires special configuration to map the client cert, which
relegates it to special use-cases (e.g. constrained devices)

K.

On 11/22/13 11:46 AM, "Carl Moberg" <[email-masked]> wrote:

>
> NETCONF over SSH is in very wide commercial deployment and is in at
>least 20+ implementations of networking equipment.
>
> I don¹t know of a single NETCONF over TLS implementation that is in use.
>