Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed

[Kent Watsen <[e-mail]>]

Hi Tom,

Thank you for this review, and the other focusing on section 3.2 of
call-home draft.  For the most part, you're asking for improvements in the
flow and wording in the draft, for which I'll incorporate when editing the
draft next.

Below are some additional responses.

Thanks,
Kent


>I have read call-home and find it problematic.  I am reminded of Alan
>Luchuk's comments of almost a year ago when it was still reverse-ssh.  I
>find it unclear, hard to understand, confusing in places without knowing
>things that are unsaid.  The improvements made to the text then have
>mostly disappeared with a change of scope.

:sigh:


>I think that the scope of the document - NETCONF, RESTCONF, TLS, SSH,
>certificates, public keys - is right

Oh good, the restructuring of the documents we took on is paying off


>but that does not mean it is always
>possible to cover all the cases in a single sentence and that more
>fleshing out is needed.  Thus repeatedly the use of NETCONF/RESTCONF
>allows combinations that I suspect are invalid, such as RESTCONF over
>SSH or NETCONF using the port assigned to RESTCONF.

This came up before.  In fact, I raised the issue originally and did try
to make it better.  Apparently not.  I have reopened
https://github.com/netconf-wg/call-home/issues/6 to track this.



>What then is the scope?  For most of the I-D, I infer NETCONF with SSH
>and TLS, RESTCONF (which I am not competent to review) with TLS, TLS
>with certificates, SSH with public keys.  But then I see at the end of
>s.3
>" However, to use X.509 certificates with SSH, ..."
>so it looks like SSH with certificates is there too.  How about TLS with
>something else?  We did debate this at length for another I-D and slowly
>converged on X.509 certificates only.  Is this true here?  If so, it
>needs saying up front IMO.

The scope is: NETCONF/SSH, NETCONF/TLS, RESTCONF/TLS

But it so happens that NETCONF/SSH can also support X.509 certificates,
which is really important for the zero-touch solution.  To be honest, I'm
beginning to think that we should take out most of section 3.2 (the one
that leads to recommending X.509 host-keys).  For the call-home protocol,
all we need to say is that the client needs to:

 1) extract the server's identity
	- options: source-ip, host-key lookup, or PKI
 2) validate the server's host-key
	- options: pinning or PKI.

I think the current text is overstepping its scope and, in the process,
hiding the essential bits.  You providing an extensive response on section
3.2 separately, but I'm thinking another solution might be to make most of
this section 3.2 disappear
 


>SSH makes a rather sudden appearance in the Introduction (lack of scope
>again); I think it should be in the Abstract e.g.
>
>NEW (In both Abstract and Introduction)
>
> This document presents NETCONF Call Home and RESTCONF Call Home, which
>enable a NETCONF or RESTCONF server to initiate a
>   secure connection to a NETCONF or RESTCONF client respectively.  The
>RESTCONFconnection is over TLS, the NETCONF over TLS or SSH. "

True, SSH was removed from the abstract when we added RESTCONF, as I
didn't want to introductory paragraphs to already be in the weeds.  I like
your suggested text.



>[Note that the current use of respectively is wrong IMO; you have 'A and
>B', but no 'C and D' to be respective to.]

Not that it matters, but isn't it:

  A = NETCONF Call Home
  B = RESTCONF Call Home
  C = enable a NETCONF server to initiate a
      secure connection to a NETCONF client
  D = enable a RESTCONF server to initiate a
      secure connection to a RESTCONF client

So, A goes with C and B goes with D?



>1
>"preserve the client/server roles of underlying transport, as when
>compared"
>
>Well no, the whole point is to reverse the transport.  Of course, if TCP
>is not a transport, well, I part company there.  It is argued just what
>TLS is, transport or not, with TCPM and TLS WGs apt to part company.  SO
>
>" preserve the client/server roles of underlying secure connection, as
>when
>compared"
>I would add at the end of this paragraph
>"References to SSH in this document are only applicable to NETCONF"
>
>(as well as fleshing this out later).


I think the word "transport" simply refers to the layer below.  So TCP is
the transport for SSH and TLS, whereas SSH is a transport for NETCONF and
TLS is a transport for NETCONF and the transport for HTTPS/RESTCONF.
This also seems consistent with the term's usage in RFCs 5539 and 6242.

Nonetheless, as Rohit's recent confusion illustrates, it seems that this
draft still does not spell out clearly enough this point.  So, how about
this:

=====START=====

   Both NETCONF Call Home and RESTCONF Call Home preserve all client/
   server roles, except for at the TCP transport layer, as when compared
   to standard NETCONF and RESTCONF connections.  Specifically,
   regardless if call home is used or not, the SSH, TLS, NETCONF, and
   RESTCONF roles are the same, only the TCP roles vary.  Stated another
   way, and depicted below, the network element is always the NETCONF/
   RESTCONF server, as well as also always the SSH/TLS server.  Indeed,
   the only difference is in which peer initiates the underlying TCP
   connection.

            +--------------------+------------+-------------+
            |    Protocol Layer  |  Standard  |  Call home  |
            +--------------------+------------+-------------+
            |  NETCONF/RESTCONF  |   server   |   server    |
            |           SSH/TLS  |   server   |   server    |
            |               TCP  |   server   |   client    |
            +--------------------+------------+-------------+

               Client/Server Roles for the Network Element

  Please note that throughout this document, including the text above,
  are switches such as "NETCONF/RESTCONF" and "SSH/TLS".  It should
  be understood that the only valid combinations are NETCONF/SSH [RFC
  6242], NETCONF/TLS [RFC 5593], and RESTCONF/TLS
[draft-ietf-netconf-restconf].
  In particular, never is it intended that RESTCONF/SSH is a valid
  combination.

=====STOP=====




>
>1.3
>A year ago, we had
>
>" these techniques MUST only be used for NETCONF Call Home"
>
>which Benoit said was impossible.  Now we have 'SHOULD' but it still
>seems impossible to me.  'SHOULD' should be accompanied by indications
>of when it does not apply and I don't really see this.  I think we are
>still leaving the barn door wide open.  I would say something like
>"These techniques are only defined for ..."
>since I think any RFC2119 language unenforceable.

Sound OK to me, do others agree?



>1.4
>"Security implications related to
>  this change are discussed in Security Considerations (Section 4)."
>Not really, section 4 refers you to section 3.

Good point.  There use to be more text there at one time though ;)



>2.1
>"The NETCONF/RESTCONF server initiates a TCP connection request
>      (SYN) to the NETCONF/RESTCONF client.  "
>A strict reading of this allows a NETCONF server to initiate connection
>of a RESTCONF client!  I think you need
>'NETCONF server or RESTCONF server' twice with a ',respectively' tacked
>On

OK


>"depending on how it is configured."
>Again, this allows you to configure a RESTCONF server to use port X.  It
>is not configuration, it is a question of which port you have just
>called that determines what the server fires up.

[assuming section 2.1, there would be a different response if for section
3.1]

No, non-standard and even mismatched IANA-assigned ports are possible.
>From the network-elements POV, what matters is how it was configured.  For
example, in the server-model draft, the configuration allows the
transport-specific default-port destination port to be overwritten.


>"Using this TCP connection, the NETCONF/RESTCONF server MUST
>      immediately start using either the SSH-server [RFC4253] or the
>      TLS-server [RFC5246] protocol.
>If the connection was made to PORT-X (or a user chosen non-default
>port), then the SSH-server protocol is initiated; if the connection was
>made to either port PORT-Y or PORT-Z (or a user-chosen non-deault port),
>then the TLS-server protocol is initiated."

I'm confused, are you providing alternate text here?



>" Once the SSH or TLS connection is established, the NETCONF/
> RESTCONF server MUST immediately start using either the NETCONF-server
>[RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] protocol,
>depending on how it is configured.  "
>
>Same story, it is the port not the configuration that matters. Perhaps
>" Once the SSH or TLS connection is established, the NETCONF/
>RESTCONF server MUST immediately start using either the NETCONF-server
>[RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf]
>protocol, depending on the port to which the connection has been
>established."

See above for my comment on section 2.1



>3
>same comments about
>"depending on how it is configured"
>Twice

Actually, here I think it is different, in that I believe we can use a
MUST (or a SHOULD, since it's not enforceable?) to assert that the right
protocol is started on the IANA-assigned port.  That is, ports must/should
only be used for the protocols as assigned by IANA.  For non-standard
ports, it would be as configured.  Tom, I might need your wordsmithing
prowess here ;)




>3.2 I need to go through this many more times but meanwhile
>
>"information  persisted previously."
>I don't understand.
>
>"This IP address could be used as an identifier directly, but doing "
>so should come with a health warning; source IP addresses are forgeable
>in the Internet.
>
>"Yet another option for identifying a NETCONF/RESTCONF server is for
>its host key or certificate to encode its identity directly (e.g.,
>   within the "Subject" field).  "
>
>What 'Subject field' is that?  I am not familiar with one.

You did provide a separate response focusing on section 3.2, so I'll defer
comment on it here now.



>4
>"An attacker could DoS the "
>I just read an AD review (in IESG review I think ) that said 'Dos is not
>a verb'!

Good point, it should be "An attacker could launch a denial of service
(DoS) attack on the..."


Thanks again,
Kent