Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt

[Kent Watsen <[e-mail]>]

Hi Tom,

Thank you for voicing my own thoughts as well.  I had previously raised
the idea of merging the reverse-ssh draft into a 4742bis, but the WG
agreed to keep it separate for simplicity sake.  That said, I like
symmetry, and it would be more consistent for 5539bis and a 4447bis,
rather than what we have now.  Just saying  ;)

Regarding Normative vs Informative, I recently asked about this and Bert
said that it comes down to if said draft needs to be understood and/or
implemented.  If this is the condition, then I believe it swings to being
Informative, as proprietary vendor-specific configuration could be used
alternatively.  As it is, the vendor can decide if they want to advertise
urn:ietf:params:xml:ns:yang:ietf-netconf-server-model in their <hello>
message.  Are you suggesting that advertising this capability in the
<hello> message should be required in order for an implementation to claim
they implement Reverse SSH for NETCONF Call Home?

Thanks,
Kent


On 4/8/14 9:44 AM, "t.petch" <[e-mail]> wrote:

>I do not think that this is ready to advance.  I had not intended to
>comment but having started on netconf-server, and found I had to read
>5539bis to understand where it was going, I then found that reverse-ssh
>was another piece of the jigsaw.
>
>In particular, I think that this I-D is more or less updating RFC4742 in
>its considerations of security.  And I think it may be confused about
>public keys and certificates and their role in authentication.
>
>Taken together, and I do not think they can be considered separately, I
>do not think that the three I-Ds give a coherent view of how to secure a
>NETCONF session.
>
>I would point to the queries raised by Tadek and Bajpai which, to me on
>the one hand seem spot on and on the other, seem to regard the subject
>material of these three I-Ds as of a one - which I obviously agree with.
>
>I think that netconf-server is the one in most need of progress and see
>it as a Normative, not Informative, prerequisite.
>
>Tom Petch
>
>
>----- Original Message -----
>From: "Bert Wijnen (IETF)" <[e-mail]>
>To: "Kent Watsen" <[e-mail]>
>Cc: <[e-mail]>
>Sent: Thursday, April 03, 2014 12:36 PM
>
>> WGLC period ended last Tuesday (April 1st).
>>
>> Kent, where are we with this one?
>>
>> Do you expect to post a rev 04 that addresses all comments we have
>received?
>> Either WGLC comments or other comments? Once that is done, I would
>like to ask:
>> - Kent to post which comments have not been addressed and why (if any)
>> - If possible, Kent to post a summary of changes (although that may
>already be
>>    in the document, and that is fine too).
>> - All those that made comments to check if they are OK with the way
>that
>>    they have been addressed or responded to.
>>
>> Bert
>>
>> On 27/03/14 17:02, Kent Watsen wrote:
>> >
>> > Hi Alan,
>> >
>> >
>> > Awesome comments - thanks!
>> >
>> >
>> > I applied all fixes mentioned below to my working copy of what will
>be
>> > -04, so you'll have to wait until then to see the diff.  The reason
>I'm
>> > not posting -04 now is because I'm still trying to work out an issue
>with
>> > Applicability Statement and with the port's name.
>> >
>> > Below are my detailed responses.
>> >
>> > Cheers,
>> > Kent
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >> Typos
>> >> -----
>> >>
>> >
>> > I fixed all the issues you found.
>> >
>> >
>> >
>> >
>> >
>> >
>> >> Section 2.1, Page 3, Second Paragraph:  (wording)
>> >> -------------------------------------------------
>> >>
>> >> The second paragraph seems vague.  Would something along the lines
>of
>> >> the following text be clearer and/or more specific?
>> >
>> > I forwarded this comment to Steve Hanna, who wrote the Applicability
>> > Statement.  At first I was just going to ask if he was OK with the
>> > proposed text, but then I started thinking that I didn't agree with
>it.
>> > That is, I think that the SSH protocol does require mutual
>authentication
>> > and that NETCONF's requirement that it be possible to derive a
>"username"
>> > from the transport doesn't change that.  I'm still OK limiting
>Reverse SSH
>> > to just NETCONF, but I want the reason to be accurate.  I'm now
>waiting
>> > for a response from Steve on this.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >> Section 4, Page 4:  (wording)
>> >> -----------------------------
>> >>
>> >> The current text reads:
>> >>
>> >>    o  The NETCONF server initiates a TCP connection to the NETCONF
>> >>       client on the IANA-assigned Reverse SSH port YYYY.
>> >>
>> >>    o  The TCP connection is accepted and a TCP session is
>established.
>> >
>> >
>> > I'm not sure about this change since these bullet-points are
>preceded by
>> > the line "From the NETCONF server's perspective:".  The intent is to
>only
>> > explain the NETCONF-server's perspective, and to let the next
>section
>> > provide the client's perspective.   Currently, neither section
>references
>> > the remote peer, so that its text remains squarely focused on its
>side of
>> > the connection.  What do you think?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >> Section 5, Page 5, First Paragraph:  (wording)
>> >> ----------------------------------------------
>> >>
>> >> The current text reads:
>> >>
>> >>    "When the management system accepts a new incoming connection,
>it
>> >>     needs to authenticate the remote peer.  Ultimately, this
>entails
>> >>     identifying the peer and verifying its SSH host key.
>> >>
>> >>     Due to Reverse SSH having the network element initiate the TCP
>> >>     connection,"
>> >
>> >
>> > I changed the wording to be more clear, but did it another way,
>please let
>> > me know if you think it's OK!
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >> Section 5, Page 6, First Paragraph:  (clarification)
>> >> ----------------------------------------------------
>> >>
>> >> The current text reads:
>> >>
>> >>    "However, configuring distinct host keys on the management
>system
>> >>    doesn't scale well, which is an important consideration to a
>network
>> >>    management system.  A more scalable strategy is to have the
>network
>> >>    element's host key signed by a common trusted key, such as a
>> >>    certificate authority.  Thus, the mangement system only needs to
>> >>    trust a single public key, which vouches for the authenticity of
>the
>> >>    various network element public keys."
>> >>
>> >> Please help me understand this.  The way this paragraph is written,
>it
>> >> is not clear to me why "signing each network element's host key
>with a
>> >> common trusted key" scales better than "configuring distinct host
>keys
>> >> on the management system".
>> >>
>> >> In either of these two situations, it seems like an administrator
>must
>> >> do work for each network element.  In one case, it is configuring
>host
>> >> keys, in another, it is signing each network element's host key.
>If
>> >> anything, it seems like signing a host key for each network element
>> >> requires _more_ work for each network element, so it seems like
>this
>> >> would scale less well.
>> >>
>> >> What am I missing here?
>> >
>> >
>> > Very good question.  Of course it comes down to how the device's
>"entity
>> > certificates", as they are called, is distributed.  In the best
>case, as
>> > described in the zero-touch draft, the device would ship from
>factory with
>> > a built-in entity-certificate, signed by a trust-chain to its
>vendor's
>> > well-known trust anchor.  In this case, there is no additional
>effort
>> > needed, the management system only needs to trust the vendor's
>certificate
>> > for its well-known trust anchor.  For cases where the device doesn't
>ship
>> > from factory with an entity-certificate, introducing PKI is still
>> > advantageous as it decouples the management-system from direct
>> > involvement, such that it could be outsourced to some 3rd-party.
>Makes
>> > sense?  What update would you like to see in the draft?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >> Section 7, Page 7, Third Paragraph:  (wording)
>> >> ----------------------------------------------
>> >>
>> >> In a few places in the third paragraph, and possibly in other
>places
>> >> in the document, would changing "needs to" to lowercase "must", or
>> >> lowercase "should", make the document a little more concise?
>Example:
>> >>
>> >>    "Note that since the SSH server would have to be configured to
>know
>> >>     which IP address it needs to connect to,"
>> >>                         ^^^^^^^^
>> >
>> >
>> > I changed "needs to" to "is to" for this cited location and another
>I
>> > found.
>> >
>> >
>> >
>> >
>> >
>> > Thanks again,
>> > Kent
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Netconf mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netconf
>> >
>>
>> _______________________________________________
>> Netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
>
>
>