Subject: [Netconf] Some doubts about draft-ietf-netconf-call-home-07

From: Rohit R Ranade <[email-masked]>
Date: Thu, 11 Jun 2015 12:15:28 +0000

Hi All,

In Section 2.1 :

   C1  The NETCONF/RESTCONF client listens for TCP connection requests

       from NETCONF/RESTCONF servers.  The client SHOULD listen for

       connections on the IANA-assigned ports defined in section

       Section 5<https://tools.ietf.org/html/draft-ietf-netconf-call-home-07#section-5>, but MAY be configured to use a non-standard port

Here it mentions that NETCONF client needs to listen for TCP connections even if NETCONF is over SSH ?
If this is so, it violates one portion of "Introduction" section in RFC 4742 .

   Throughout this document, the terms "client" and "server" are used to

   refer to the two ends of the SSH transport connection.  The client

   actively opens the SSH connection, and the server passively listens

   for the incoming SSH connection.

In above statement , it mentions that SSH opens and listens on a connection. Can you please explain as to why NETCONF should handle the call-home connection when till now SSH was handling the connection part ?

NETCONF client will have to accept connections, pass the socket FD to the SSH client and then the SSH client will do the key-exchange and be ready with the SSH connection.
If there are some systems where in NETCONF and SSH are separate sub-systems,  then this passing of Socket Fds between modules is very cumbersome.

Coming back to Section 2.1 in draft-ietf-netconf-call-home-07

   C5  As part of establishing an SSH or TLS connection, the NETCONF/

       RESTCONF client MUST validate the server's presented host key or

       certificate.  This validation MAY be accomplished by certificate

       path validation or by comparing the host key or certificate to a

       previously trusted or "pinned" value.

Validation of Server is SSH client job, should this not be done by SSH client ? Why NETCONF client need to validate Server ?
The same holds good for C6 also ..

With Regards,
Rohit

---

From: Kent Watsen <[email-masked]>
Date: Thu, 11 Jun 2015 17:45:57 +0000

>        Section 5, but MAY be configured to use a non-standard port
>
> If this is so, it violates one portion of ³Introduction² section in RFC
>4742 .
 
>   for the incoming SSH connection.

RFC 4742 is obsolete, replaced by RFC 6242, which does not include the
quoted text above.  I can't find any conflicts with RFC 6242, can you?

> In above statement , it mentions that SSH opens and listens on
> a connection. Can you please explain as to why NETCONF should
> handle the call-home connection when till now SSH was handling
> the connection part ?

I don't understand your question, but I think that you asked a similar
question back in March.  Recall that with call home, there is a reversal
as to which peer initiates the TCP connection, otherwise all the roles are
the same.  Actually, the current text was greatly expanded to address your
earlier request for clarification.  Is the new text still not clear enough?

> NETCONF client will have to accept connections, pass the socket
> FD to the SSH client and then the SSH client will do the key-
> exchange and be ready with the SSH connection. If there are
> some systems where in NETCONF and SSH are separate sub-systems,
> then this passing of Socket Fds between modules is very cumbersome.

On the contrary, the NETCONF/SSH call-home client code has be written in a
few programming languages already without issue.  All SSH libraries seem
to support the ability to passed an accepted socket into the SSH library.
As for SSH and NETCONF being separate, call home doesn't change anything
between the SSH and NETCONF layers - in all cases, the NETCONF client
opens the "netconf" SSH subsystem on the NETCONF server...

 
> Validation of Server is SSH client job, should this not be done by SSH
> client ? Why NETCONF client need to validate Server ?   The same holds
> good for C6 also ..

Keep in mind that the NETCONF client *is* the SSH client, so actually it
is as you say it should be.  Makes sense?

Thanks,
Kent