Subject: [Netconf] netconf figure

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Aug 2009 08:32:54 +0200

Hi,

the netconf figure in RFC 4741 is outdated. The YANG usage guidelines
document contains a different figure:

          Layer                Example
         +-------------+   +--------------------+ +-------------------+
     (4) |   Content   |   | Configuration data | | Notification data |
         +-------------+   +--------------------+ +-------------------+
                |                    |                   |
         +-------------+   +-----------------+     +---------------+
     (3) | Operations  |   |  <edit-config>  |     |  <eventType>  |
         +-------------+   +-----------------+     +---------------+
                |                    |                   |
         +-------------+   +--------------------+  +----------------+
     (2) |     RPC     |   | <rpc>, <rpc-reply> |  | <notification> |
         +-------------+   +--------------------+  +----------------+
                |                    |                   |
         +-------------+       +--------------------------------+
     (1) |  Transport  |       |  BEEP, SSH, SSL, TLS, console  |
         |   Protocol  |       |                                |
         +-------------+       +--------------------------------+

I think this is better but still can be improved. First, there is no
transport over SSL - there is only a transport over TLS. Second, there
is a published transport over SOAP. Third, I think we should order the
transports such that SSH (the mandatory to implement) comes first and
I am not sure how useful console as a transport is. My preference
would be to actually relabel the "Transport Protocol" layer to "Secure
Transport" and the "RPC" layer to "Messages" layer. So what about
this:

          Layer                Example
         +-------------+   +--------------------+ +-------------------+
     (4) |   Content   |   | Configuration data | | Notification data |
         +-------------+   +--------------------+ +-------------------+
                |                    |                   |
         +-------------+   +-----------------+     +---------------+
     (3) | Operations  |   |  <edit-config>  |     |  <eventType>  |
         +-------------+   +-----------------+     +---------------+
                |                    |                   |
         +-------------+   +--------------------+  +----------------+
     (2) |   Messages  |   | <rpc>, <rpc-reply> |  | <notification> |
         +-------------+   +--------------------+  +----------------+
                |                    |                   |
         +-------------+       +--------------------------------+
     (1) |   Secure    |       |  SSH, TLS, BEEP, SOAP, ...     |
         |  Transport  |       |                                |
         +-------------+       +--------------------------------+

Comments? I like to get the updated figure into 4741bis as the new
authoritative source of it...

/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: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Aug 2009 11:25:45 +0200

On Thu, Aug 13, 2009 at 10:57:21AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
> 
> All is fine but SOAP is not a secure transport protocol.
> s/SOAP/SOAP\/HTTPS/
> 

I expected this comment. But note this statement in section 4.2 of RFC
4743:

   At a miniumum, all conforming NETCONF over SOAP implementations MUST
   support TLS.  Specifically, NETCONF over SOAP over HTTP MUST support
   NETCONF over SOAP over HTTPS, and NETCONF over SOAP over BEEP MUST
   support NETCONF over SOAP over BEEP over TLS.

NETCONF does not have an architectural model but surely security
services are expected to be provided by the "transport". This is
also reflected in section 9 of RFC 4741:

   [...] It is anticipated that the
   underlying protocol (SSH, BEEP, etc) will provide for both
   confidentiality and authentication, as is required. 

I translate "underlying protocol" to the "transport" layer (1) (one
more case where the usage of terms could be more precise).

But yes, I do see your point that people will read "SOAP == secure"
(but such a statement is naive by itself since even commonly assumed
secure transports can usually be configured to run in plaintext mode).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Aug 2009 11:31:44 +0200

> All is fine but SOAP is not a secure transport protocol.

So what about this one:

      Layer                Example
     +-------------+   +--------------------+ +-------------------+
 (4) |   Content   |   | Configuration data | | Notification data |
     +-------------+   +--------------------+ +-------------------+
            |                    |                   |
     +-------------+   +-----------------+     +---------------+
 (3) | Operations  |   |  <edit-config>  |     |  <eventType>  |
     +-------------+   +-----------------+     +---------------+
            |                    |                   |
     +-------------+   +--------------------+  +----------------+
 (2) |  Messages   |   | <rpc>, <rpc-reply> |  | <notification> |
     +-------------+   +--------------------+  +----------------+
            |                    |                   |
     +-------------+   +----------------------------------------+
 (1) |   Secure    |   | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
     | Transports  |   |                                        |
     +-------------+   +----------------------------------------+

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 13 Aug 2009 10:57:21 +0200

Cheers,
Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Juergen 
> Schoenwaelder
> Sent: Thursday, August 13, 2009 8:33 AM
> To: [email-masked]
> Subject: [Netconf] netconf figure
> 
> Hi,
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 13 Aug 2009 18:25:53 +0200

After a short offline discussion we agree that...

It is good to highlight that we have "Secure Transports" and it would
the best to have "SSH, TLS, BEEP, SOAP/HTTPS" on layer (1) of the
picture.

It would be appropriate if people use BEEP and SOAP on top of TLS but it
is not prohibited to use BEEP with SASL nor 'SOAP over HTTP over SSL'.
BTW: SASL supports secure transport so you don't have to have TLS with
BEEP if you use SASL.

There is a value in using TLS instead of SASL or SSL but it is the job
of the transport mappings to recommend TLS.
The core NETCONF document should not really go into those details. 

Cheers,
Mehmet

> From: ext Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, August 13, 2009 11:32 AM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: [email-masked]
> Subject: Re: [Netconf] netconf figure
>

---

From: Phil Shafer <[email-masked]>
Date: Thu, 13 Aug 2009 12:10:03 -0400

Is "eventType" an operation?

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Aug 2009 19:26:15 +0200

> Is "eventType" an operation?

As the caml-case already indicates, it is an accident. ;-) 

If you color the boxes covered by YANG, you also see some interesting
assymmetry centered around <eventType>. Perhaps we should simply
remove this box from the figure...

/js

---

From: shikhar <[email-masked]>
Date: Thu, 20 Aug 2009 00:01:47 +0200

On Thu, Aug 13, 2009 at 8:32 AM, Juergen
Schoenwaelder<[email-masked]> wrote:
> My preference
> Transport" and the "RPC" layer to "Messages" layer.

A move to "Messages" instead of "RPC" would definitely be good in
light of <notification>'s and any future extensions.

Shikhar

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 25 Aug 2009 08:47:52 -0400

Hi,

I support this change.

I wish this was the layering used when SNMPv3 was designed; it would
have made adding extensions to SNMPv3 simpler.

Where do you envision data access controls in this layering? 

dbh

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Thursday, August 13, 2009 5:32 AM