Using the NETCONF Configuration Protocol over Secure SHell (SSH)
draft-ietf-netconf-ssh-06
No Objection
(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(Brian Carpenter)
(Mark Townsley)
(Russ Housley)
(Scott Hollenbeck)
Abstain
Recuse
(Margaret Cullen)
Note: This ballot was opened for revision 06 and is now closed.
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
(2006-03-15)
Unknown
The writeup alludes to IANA Considerations updates appearing in the Notes to the RFC Editor, but they're not there - I suppose the latest revision incorporated them?
Bert Wijnen Former IESG member
(was Discuss, Yes)
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
(2006-03-01)
Unknown
I received the following comment by Ólafur Guðmundsson from the DNS review team: - draft-ietf-netconf-ssh-05.txt I reviewed this document for content and protocol clarity. The document is in good shape, I have two nits on the document neither is a show stoppers. - the document needs to be updated to refer the SSH RFC's that where published after the ID was submitted. - To avoid confusion the document may want to say that SSHv1 only clients do not implement subsystem it is a v2 extension.
Jon Peterson Former IESG member
No Objection
No Objection
(2006-03-16)
Unknown
netconf-prot-12: I can imagine the XML data structures described in this document being used in various application-layer protocols that meet the requirements described in Section 2; however, I'm not sure that it would be reasonable or meaningful for all of those applications to support SSH per 2.4. Do I understand 2.4 to mean that all client and server implementations of NETCONF would have to support SSH (and the transport of NETCONF XML documents over SSH)?
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
No Objection
No Objection
(2006-02-27)
Unknown
The security considerations section of draft-ietf-netconf-ssh claims: If the NETCONF server provides remote shell access through insecure protocols, such as rsh or Telnet, care should be taken to prevent execution of the NETCONF program when strong user authentication or data privacy is not available. Because it may be difficult or impossible in some operating environments to determine whether a shell command was accessed over a secure protocol such as SSH or an insecure protocol such as Telnet, it may be necessary to disable insecure shell access to the system to prevent insecure access to the NETCONF program. This recommendation seems out of scope for the ssh profile. It also seems wrong. If these other insecure shells allow changing the configuration of the device using a proprietary CLI, what harm is done by allowing people to make the changes using netconf over these transports. This usage is not standardized, but I don't see that it creates a new security exposure. However claiming that installing or enabling netconf should make other arbitrary changes like disabling rsh or telnet is unreasonable from an operational standpoint. While I'm being picky, I'll point out that telnet can be used in a perfectly secure manner with the starttls option. I'll admit this is pure pendanticism on my part and comes from too many years maintaining an encrypted telnet implementation.
Scott Hollenbeck Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
Abstain
Abstain
(2006-03-15)
Unknown
I believe that the locking model in this document has serious deficiencies, and that the filtering mechanism will eventually require XPATH as mandatory-to-deploy. I have agreed with Bert to discuss adding a more-capable locking function as a future work item, rather than block this document.
Margaret Cullen Former IESG member
Recuse
Recuse
()
Unknown