On Tue, Aug 23, 2016 at 12:27 PM, Susan Hares <[email protected]> wrote:
> Jeff: > > Thank you your comments. I agree with your assessment of the WG's > desires. > It provides a helpful context for the IESG members. > > As I mentioned in another email, one of the first mechanisms is to describe > what portions of an data model can be sent in the PUB/SUB Push via a > non-secure HTTP session or what require a secure HTTP session. > > Sue > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Jeffrey Haas > Sent: Monday, August 22, 2016 3:46 PM > To: Andy Bierman > Cc: [email protected]; Alissa Cooper; Juergen Schoenwaelder; > [email protected]; Kathleen Moriarty; IESG; Joel Halpern; Lou Berger; > Susan Hares; [email protected] > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and > COMMENT) > > I'm lagging in my email, as usual. However, this one caught my eye: > > On Fri, Aug 19, 2016 at 07:23:47AM -0700, Andy Bierman wrote: > > We could have been tagging MIB objects all along, but we don't. > > Imagine if there was a debate for every single OBJECT-TYPE macro "is > > this leaf OK for noAuth/noPriv?" > > > > Are there even clear SEC-DIR guidelines on how one would decide this > > debate in a WG? Does SEC-DIR really want to be flooded with review > > requests so they become a bottleneck in YANG RFC publication process? > > I wanted to point out some of the per-object security evaluation that is > already imposed on MIB modules. Consider the following text from RFC 4273: > > : There are a number of managed objects in this MIB that contain > : sensitive information regarding the operation of a network. For > : example, a BGP peer's local and remote addresses might be sensitive > : for ISPs who want to keep interface addresses on routers confidential > : in order to prevent router addresses used for a denial of service > : attack or spoofing. > : > : Therefore, it is important in most environments to control read > : access to these objects and possibly to even encrypt the values of > : these object when sending them over the network via SNMP. > > In some respect, the discussion with regard to I2RS annotation of yang > nodes > with security considerations have precedence. It could be done in the > containing documents' security considerations section. It could be part of > the description clause for the node. > > Having some notion of the consideration available as a machine-parseable > markup thus doesn't seem completely unreasonable. > > The essence of your point, Andy, and I believe Juergen's is given a > presmise > of "secure by default", is it okay to mark things as "the author of this > module believes this to be okay to be insecure by default"? > > Possibly not. As you both mention, it will depend on the circumstances of > a > given operator's deployment. > I believe the actual annotation needs to apply to a specific subtree. There are corner-cases where the module-wide annotation does not work (such as groupings used in a different module). IMO the annotation needs to apply only to descendant-or-self nodes in the same module namespace. > > The underlying I2RS question is how to mark nodes in such a way that the > insecure transport protocols may be permitted to publish them without > requiring every single node to be audited if you have relatively weak > deployment considerations? If the answer is "read the security > considerations and write a filter", it's not the answer i2rs is looking > for. > > > -- Jeff > Andy > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
