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

[t.petch <[e-mail]>]

<inline tp>
Tom Petch

----- Original Message -----
From: "Kent Watsen" <[e-mail]>
To: "t.petch" <[e-mail]>; "Ersue, Mehmet (Nokia - DE/Munich)"
<[e-mail]>; <[e-mail]>
Sent: Friday, March 20, 2015 6:31 PM

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

<snip>

>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.

<tp>
Yes, once we have settled 3.2, then I would take another look at this to
see if there any loose ends.

>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

<tp>
Well partially, but I find the I-D unclear on the related credentials,
which I take to be TLS-with-certificates, SSH-with-host-key,
SSH-with-certificates. I am fine with that being the scope but think
that the wording of the I-D does not always bear that out clearly enough
and this was a big issue for 5539bis.
</tp>

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

<tp>
Yes, subject to some agreement on terminology.  As Juergen said, more
like an essay, and my text in my separate response is still too essay
like.

>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.

<tp> Good, use it!

<snip discourse on grammar>

>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.

<tp>
text fine, diagram less so as it, again, could be read as endorsing
RESTCONF over SSH.  I really do want the I-D to be clear that it
excludes that possibility (I have been reading PPVPN lately and boy, it
is confusing because of this sort of mix and match).

=====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?

<tp Hope so

>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.

<tp>
Yes but Juergen has picked up on this point too, that if you call home
on a port configured for SSH, then you should only process SSH packets
and discard TLS ones; that we should be crystal clear on; whether the
port is IANA-assigned or not is immaterial, it just causes the sentence
to introduce an unwanted complication.


>"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?

<tp>
Yes, it is the same point, and the same as Juergen has picked up on.

>" 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 ;)

<tp>
SHOULD, I think (flattery will get you everywhere).  If the port is
IANA-assigned, it should only be used for that which it was assigned.
If the port is user chosen, it should only be used for the protocol, SSH
or TLS, for which it is configured.

I assume that user-defined ports follow the IANA model, that a port is
either for NETCONF-SSH or NETCONF-TLS or RESTCONF-TLS and not a
combination thereof; at least, that is what the I-D says they SHOULD
do - if an implementer wants to go further, then we do not give them any
help or encoiuragement.

>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.

<tp
Yes and Juergen's comments are relevant.

>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..."


Phew!

Tom Petch


Thanks again,
Kent