Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Ben,

Thank you for your review.


Regarding your original comments:


> If the client MAY be configured to listen on a non-standard port, doesn’t
> that imply that the server MUST be _capable_ of being configured to
> connect to a non-standard port?

This is correct and what draft-ietf-netconf-server-model-08 allows.   Were you thinking that there needs to be a change in this draft?


> I'm curious why people felt it necessary to reverse the usual TLS or SSH
> client and server roles. Did the working group consider having the
> NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the

As Juergen noted, this allows that all existing authentication to continue working.  Also, since SSH is not a symmetric protocol, it’s actually important for the client to be the SSH-client so it can open/close SSH channels (e.g., to start the “netconf” subsystem).





And regarding your latest message:

>Paraphrasing back to check my understanding:
>
>At least for the case of TLS, The NETCONF/RESTCONF server is 
>authenticated by TLS, and the client by credentials that are exchanged 
>after the TLS handshake completes?

NETCONF over TLS requires the client to use client-certificate based authentication and this happens at the time the TLS session is being established, for the NETCONF protocol layer starts.

RESTCONF over TLS (the only choice) uses HTTP Authentication [RFC7235].  When “Basic” or “Digest” are used, the client-authentication is after the TLS session has been established.  The “ClientCertificate” is used, then the client-authentication occurs at the time the TLS session is being established (same as NETCONF over TLS). 




>I'm going to go out on a limb and guess that that approach is an 
>artifact of the normal (non-call-home) connection direction, and a lack 
>of client certs? I am no NETCONF expert, so forgive me if I am missing 
>some other obvious reason.

Yes, that is fair to say, in the sense that it is very easy to implement it this way.   For instance, JUNOS uses `inetd` to listen on port 22 and, when a TCP connection is established, it forks/execs `sshd -i` passing the open socket descriptor.   So to implement call home, all that had to be done was to write a daemon that initiates the TCP connection to the client and then, as soon as the TCP connection is established, it forks/execs `sshd -i` exactly like how `inetd` does it.   Everything else stays the same.  In fact, the SSH has no awareness of how it was invoked.



>However, this does make me wonder about the statement in the Security
>Considerations that the DoS potential is "no different than for any 
>other secured service". The reversed connection approach seems to allow 
>an attacker to cause the NETCONF client to perform computationally 
>intense operations with just a TCP connection--that is, with marginally 
>less effort on the part of the attacker. I'm not sure that's enough 
>difference to make a real-world difference, but it might be worth a 
>mention.


A normal SSH or TLS server accepts the TCP connection and immediately starts a computationally expensive operation (proving it has the private key associated with its SSH host key or TLS server certificate).   

Here we have similar setup, except the client has the port open and it starts the SSH/TLS client protocol.  It could be argued that the client protocol is less expensive than the server protocol, so perhaps it’s not so bad.

Still, for the draft, what do you recommend changing?   The current text follows:

    An attacker could launch a denial of service (DoS) attack on the
    NETCONF/RESTCONF client by having it perform computationally
    expensive operations, before deducing that the attacker doesn't
    posses a valid key.  This is no different than any secured service
    and all common precautions apply (e.g., blacklisting the source
    address after a set number of unsuccessful login attempts).




Thanks again,
Kent