Stephen: Thank you for your comments. See answers below. I hope you will stay involved in reviews. It is critical we consider privacy and security for this new interface.
Sue -----Original Message----- From: Stephen Farrell [mailto:[email protected]] Sent: Thursday, March 17, 2016 8:22 AM To: The IESG Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-architecture-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >- If i2rs were used to control home networks, then that would raise more >privacy issues, >e.g. the agent's IP address can be privacy sensitive. Would it be useful to >rule that out of > scope? E.g. to say that i2rs SHOULD NOT be used where the agent/router in > question > is specific to one person or home? Sue: I'm really not sure what you are getting at. Data in routers is privacy sensitive. Data between I2RS Agent and I2RS client will be encrypted except in very, very rare circumstances where is defined to be public data in the data model. SECDIR, OPSDIR, RTGWG, Transport-directorate will be asked to review any IETF data model that claims this is the case to validate it is appropriate. So... I think we are going beyond what people use for home networks. > section 2: security role, hmm..... Do netconf/restconf have the concept of > mapping >identifiers to roles? If not, that might be tricky to graft on. Not > sure. Sue: - section 4: "Mutual authentication between the I2RS Client and I2RS Agent is required. " yay! thanks:-) Even better if you did s/Mutual/Strong mutual/ to prevent someone saying that TCP-MD5 is good enough. Sue: At least 15 years with BGP has taught about some mistakes. - section 4: "The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, confidentiality and replay protection." yay! again! :-) Sue: This is why I do not understand the first question. - section 4: "Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS Client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection." sorry, boo! :-) Sue: I agree the bar should be high on all of our streams. I hope you will review (as AD or sec-dir) our proposed streams for replay. The WG indicated that if OSPF is good enough to run the network, it is secure enough to listen to. Perhaps OSPF needs to change (smile). It's often unsafe to mix and match differently protected sets of data between the same sets of entities. I think you'd be better off there saying that the requirements may *exceptionnally* differ but usually only because of e.g. some level of broadcast or multicast being part of the story, where we don't have good usable security solutions today. (This is not a DISCUSS because I think the protocol work will end up saying "just use TLS always" as that'll be simpler and better, so I hope this'll be a non-issue. If you know already that there's some other plan in place, then please say so we can chat now and avoid a trickier discussion later.) Sue: 90% answer is "just use TLS as always. For the first version of I2RS protocol we will use NETCONF/RESTCONF as the base for configuration, publication/subscription of large data, and action commands. NETCONF has definitions over TLS and over SSH. RESTCONF runs of HTTP and requires TLS. We are finalizing requirements for insecure stream and multicast - so I would really like to hear your concerns in person. - section 4: I think you're heading here towards use of TLS and not object level security. Is that right? If so, would it be useful to say so? (Just so as to correctly set expectations for later.) Sue: We are using TLS, but we are indicating that certain data models are only allowed to be accessed (read, write, or both) by certain users. This fits within the NETCONF/RESTCONF concepts. - 7.7: Would it be useful to say that the relevant information here is only about network state and stastics and not about connections (e.g. who spoke to whom) or payloads? That might save some discussions about RFC2804 later on. Sue: Yes, sections about network state. It is about network connections and topologies - but not about "who spoke to whom" or payloads. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
