[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Pls review documents on IESG Agenda October 27, 2005 Telechat
Inline
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: Thursday, October 27, 2005 15:54
> To: Wijnen, Bert (Bert); ietfdbh@comcast.net; Mreview (E-mail)
> Subject: RE: Pls review documents on IESG Agenda October 27, 2005
> Telechat
>
>
> It looks OK for all practical purposes, but is there any special reason
> to have left out the phrase that David suggested about the
> standardization status of SNMP?
>
> 'The IETF has declared those prior versions Historic, and RECOMMENDS
> that deployments upgrade to SNMP version 3'.
>
Because in our standard tenmplate, this tect:
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security.
covers the same (in different words).
Bert
> Dan
>
>
>
>
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: Thursday, October 27, 2005 3:34 PM
> > To: ietfdbh@comcast.net; Romascanu, Dan (Dan); 'Mreview (E-mail)'
> > Subject: RE: Pls review documents on IESG Agenda October 27,
> > 2005 Telechat
> >
> > I have recorded the below. Does that address your concerns?
> > I have recorded it as a COMMENT (i.e. non-blocking), but I
> > have brough it to the attention of the security ADs to let
> > them advise if we should block on it or not.
> >
> > Makes sense?
> >
> > Bert
> > -----------------
> >
> >
> > Bert Wijnen:
> > Comment:
> > [2005-10-25] I see:
> > 3.8 MIB
> >
> > Management Information Bases (MIBs) SHOULD be defined for
> mechanisms
> > specifically in place to support ETS. These MIBs MAY
> > include objects
> > representing accounting, policy, authorization.
> >
> > I suggest to change to:
> >
> > 3.8 MIB
> >
> > Management Information Base (MIB) modules SHOULD be defined for
> > mechanisms specifically in place to support ETS. These MIB
> > modules MAY include objects representing accounting, policy,
> > authorization.
> >
> > That is: there is one single MIB, which is composed of many
> > MIB modules.
> > I am not sure I understand the capitalized MAY in the 2nd
> > sentence. I can live withit, but porbably better to just use
> > lowercase "may".
> >
> > The discussion about MIB and SNMP in the Security
> > Considerations section is porbably best changed/updated to
> > state a subset of the text in the common MIB Security
> > Template as found at
> > http://ops.ietf.org/mib-security.html
> >
> > Specifically, I think I would like to see text aka:
> >
> > SNMP versions prior to SNMPv3 did not include adequate security.
> > Even if the network itself is secure (for example by using IPsec),
> > even then, there is no control as to who on the secure network is
> > allowed to access and GET/SET (read/change/create/delete)
> > the objects
> > in this MIB module.
> >
> > It is RECOMMENDED that implementers consider the security
> > features as
> > provided by the SNMPv3 framework (see [RFC3410], section 8),
> > including full support for the SNMPv3 cryptographic
> mechanisms (for
> > authentication and privacy).
> >
> > Further, deployment of SNMP versions prior to SNMPv3 is NOT
> > RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
> > enable cryptographic security. It is then a customer/operator
> > responsibility to ensure that the SNMP entity giving access to an
> > instance of this MIB module is properly configured to
> give access to
> > the objects only to those principals (users) that have legitimate
> > rights to indeed GET or SET (change/create/delete) them.
> >
> > Which I think covers the considreations that are relevant for
> > this MIB document.
> >
> > > -----Original Message-----
> > > From: owner-mreview@ops.ietf.org
> > [mailto:owner-mreview@ops.ietf.org]On
> > > Behalf Of David B Harrington
> > > Sent: Wednesday, October 26, 2005 18:08
> > > To: 'Romascanu, Dan (Dan)'; 'Wijnen, Bert (Bert)'; 'Mreview
> > (E-mail)'
> > > Subject: RE: Pls review documents on IESG Agenda October 27, 2005
> > > Telechat
> > >
> > >
> > > Hi,
> > >
> > > I have suggestions to improve the wordings here. All the
> > lines I have
> > > changed have no '>' preceding the line.
> > >
> > > > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-i
> > > eprep-doma
> > > > in-req-05.txt includes in the Security Consideration section the
> > > > following:
> > > >
> > > > - Most current deployments of SNMP are of versions prior to
> > > > SNMPv3, even though there are well-known security
> > > > vulnerabilities in those versions of SNMP. The IETF has
> > > declared those prior versions Historic, and RECOMMENDS
> > > that deployments upgrade to SNMP version 3.
> > > >
> > > > - SNMP versions prior to SNMPv3 cannot support cryptographic
> > > > security mechanisms. Hence, any use of SNMP prior to
> > > > old: version 3 to write or modify MIB objects do so in a
> > > new: version 3 to read or write or modify MIB objects
> do so in a
> > > > non-secure manner. As a result, it may be best to
> > constrain
> > > the use of SNMP to SNMPv3-capable agents and managers
> > > (i.e. to SNMPv3 messages).
> > > >
> > > > - Finally, any MIB defining writable objects should carefully
> > > > consider the security implications of an SNMP
> compromise on
> > > > the mechanism(s) being controlled by those writable MIB
> > > objects. It is already a requirement of all IETF
> standard
> > > MIB modules that a detailed Security
> > Considerations section
> > > accompany the MIB module. It is RECOMMENDED that
> > MIB modules
> > > developed by other organizations include a comparable
> > > Security
> > > Consideration section.
> > >
> > > Dave Harrington
> > > dbharrington@comcast.net
> > >
> > >
> > >
> > >
> >
>