[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: draft-ietf-sigtran-sctp-mib-09.txt - rev 10b included
W.r.t. the security concerns, why would you not add to th securty
considerations section
The above objects also have privacy implications, i.e., they
disclose who is connecting to what hosts. These are sensitive
from a perspective of preventing traffic analysis, and also to
protect individual privacy.
You could add it after the 2 bullets, just before the para that
starts with: SNMP versions prior to SNMPv3
I am assuming here that it applies to all the tables, but maybe
it only applies to one or two tables, in which case it might be good
to be specific.
I am checking the other changes.
Thanks,
Bert
> -----Original Message-----
> From: Javier Pastor-Balbas (ECE)
> [mailto:javier.pastor-balbas@ece.ericsson.se]
> Sent: dinsdag 3 juni 2003 12:00
> To: 'Wijnen, Bert (Bert)'; Maria-Carmen Belinchon-Vergara (ECE)
> Cc: Mreview (E-mail); LyOng@ciena.com; mankin@psg.com;
> jon.peterson@neustar.biz; shawn.routhier@windriver.com; C. M. Heard
> Subject: RE: FW: draft-ietf-sigtran-sctp-mib-09.txt - rev 10b included
>
>
> Hi Bert et al.,
>
> All the changes in the mail below have been included in the MIB.
>
> Regarding the security concerns, we think that what you're
> proposing is already stated in the MIB (see 3rd paragraph
> within Sec. Cons. section). This was your comment:
>
>
> *****start included text******
>
> Here is more input from IESG (assuming one more rev will
> occur)... it is from one of the security ADs. You may want
> to try and add some more explantion to the security considerations
> section that tells about each object what exactly the concerns
> or security and/or privacy aspects are. So that operators/users
> do have proper information based on which they can decide how
> to configure access control to those objects and tables.
>
> ***** end included text ****
>
> Pls, send us any further comments you have. We will very
> pleased to address them.
>
> We're sending you attached the updated version. When
> everything is OK, we'll send it out to the RFC-editor.
>
>
> Thanks // Maria and Javier.
>
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: lunes, 02 de junio de 2003 12:05
> > To: Javier Pastor-Balbas (ECE); Maria-Carmen Belinchon-Vergara (ECE)
> > Cc: Mreview (E-mail); LyOng@ciena.com; mankin@psg.com;
> > jon.peterson@neustar.biz; shawn.routhier@windriver.com; C. M. Heard;
> > 'Wijnen, Bert (Bert)'
> > Subject: RE: FW: draft-ietf-sigtran-sctp-mib-09.txt
> >
> >
> > Any idea when we can expect the new revision?
> > I will go on vacation next week... and probably for 3 weeks.
> >
> > Thanks,
> > Bert
> >
> > > -----Original Message-----
> > > From: Javier Pastor-Balbas (ECE)
> > > [mailto:javier.pastor-balbas@ece.ericsson.se]
> > > Sent: maandag 26 mei 2003 9:14
> > > To: 'Wijnen, Bert (Bert)'; C. M. Heard
> > > Cc: Mreview (E-mail); LyOng@ciena.com; mankin@psg.com;
> > > jon.peterson@neustar.biz; shawn.routhier@windriver.com;
> Maria-Carmen
> > > Belinchon-Vergara (ECE)
> > > Subject: RE: FW: draft-ietf-sigtran-sctp-mib-09.txt
> > >
> > >
> > > Thanks guys,
> > >
> > > We'll share with you the new version before submission to
> > > make sure you agree on the changes (esp. the security ones).
> > >
> > > Thanks again // Javier.
> > >
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > > > Sent: sábado, 17 de mayo de 2003 0:14
> > > > To: C. M. Heard; Wijnen, Bert (Bert)
> > > > Cc: Mreview (E-mail); LyOng@ciena.com; mankin@psg.com;
> > > > jon.peterson@neustar.biz; shawn.routhier@windriver.com;
> > Maria-Carmen
> > > > Belinchon-Vergara (ECE); Javier Pastor-Balbas (ECE)
> > > > Subject: RE: FW: draft-ietf-sigtran-sctp-mib-09.txt
> > > >
> > > >
> > > > Thanks Mike. I think those are reasonable (and also to my
> > > > undertsanding) only clarifying editorial changes. So once these
> > > > are done, I think they will address the comments that
> were raised
> > > > during IETF Last Call.
> > > >
> > > > Let me also remind the authors, that we had agreed that
> > > > sctpAssocRemHostName OBJECT-TYPE
> > > > SYNTAX OCTET STRING (SIZE(0..115))
> > > > MAX-ACCESS read-only
> > > > STATUS current
> > > > DESCRIPTION
> > > > "The peer's DNS name. This object needs to
> have the same
> > > > format as the encoding in the DNS protocol. This
> > > > implies that
> > > > the domain name can be up to 255 octets long, each
> > > > octet being
> > > > 0<=x<=255 as value with US-ASCII A-Z having a case
> > > > insensitive
> > > > matching.
> > > >
> > > > Needed to be changed to allow for a size of (0..255).
> And I think
> > > > this raises another issue that the index in
> > > sctpLookupRemHostNameTable
> > > > will possibly go over 128 subIDs, so there should be some
> > > > text in there
> > > > that explains that users should be carefull not to use
> > > hostnames that
> > > > are longer than 115 for now (e.g. while using SNMPv1/v2c or v3).
> > > >
> > > > Mike, is that OK with you too?
> > > >
> > > > Thanks,
> > > > Bert
> > > >
> > > > > -----Original Message-----
> > > > > From: C. M. Heard [mailto:heard@pobox.com]
> > > > > Sent: vrijdag 16 mei 2003 18:43
> > > > > To: Wijnen, Bert (Bert)
> > > > > Cc: Mreview (E-mail); LyOng@ciena.com; mankin@psg.com;
> > > > > jon.peterson@neustar.biz; shawn.routhier@windriver.com;
> > > > > maria-carmen.belinchon-vergara@ece.ericsson.se;
> > > > > javier.pastor-balbas@ece.ericsson.se
> > > > > Subject: Re: FW: draft-ietf-sigtran-sctp-mib-09.txt
> > > > >
> > > > >
> > > > > On Fri, 16 May 2003, Wijnen, Bert (Bert) wrote:
> > > > > > Mike, do you have time to propose exact wording
> > > > > > changes so that we would be happy.
> > > > >
> > > > > OK, based on the following:
> > > > >
> > > > > > For now, only IPv4 and IPv6 need to be supported,
> > > but possibly
> > > > > > in the future we may also allow for IPv4z and IPv6z
> > > > > >
> > > > > > For now, only IPv4 and IPV6 need to be supported,
> > > but possibly
> > > > > > in the future other addresses may be supported.
> > > > >
> > > > > and the fact that the conformance statements already
> > > require support
> > > > > of IPv4z and IPv6z under certain circumstances, I've
> crafted the
> > > > > following proposed wording changes. For the benefit of
> > > the authors
> > > > > and others who were not present when this was being discussed
> > > > > off-line on the mreview list, the changes are intended to
> > > fix a few
> > > > > perceived inaccuracies/inconsistencies and to get the MIB
> > > module to
> > > > > conform to the following recommendation in Section 4.6.5 of
> > > > > <draft-ietf-ops-mib-review-guidelines-01.txt>:
> > > > >
> > > > > It is RECOMMENDED that all MIB documents make explicit any
> > > > > limitations on index component lengths that
> > management software
> > > > > must observe. This may be done either by including SIZE
> > > > > constraints on the index components or by specifying
> > applicable
> > > > > constraints in the conceptual row DESCRIPTION clause
> > or in the
> > > > > surrounding documentation.
> > > > >
> > > > > The option chosen in the proposed wording changes is to
> > > specify the
> > > > > constraints in the relevant conceptual row DESCRIPTION
> > > clauses. The
> > > > > proposed changes apply to
> <draft-ietf-sigtran-sctp-mib-09.txt>.
> > > > >
> > > > > ========================================================
> > > > >
> > > > > On page 8 (4th paragraph from the bottom) make the
> > > > > following replacement:
> > > > >
> > > > > OLD:
> > > > >
> > > > > Both sctpAssocLocalAddrTable and sctpAssocRemAddrTable are
> > > > > indexed by
> > > > > addresses. 'Addr' and 'AddrType' use the syntax
> > InetAddress and
> > > > > InetAddressType defined in the Textual Conventions
> > for Internet
> > > > > Network Address (RFC3291). In the general case this
> > > > syntax is valid
> > > > > for Unknown IP addresses, IPv4, IPv6, non-global IPv4,
> > > non-global
> > > > > IPv6 address and DNS, but only the IPv4 and IPv6 address
> > > > > options are
> > > > > allowed in this MIB.
> > > > >
> > > > > DNS value is not used to identify an IP address since
> > > it is only
> > > > > valid during initialization (once this stage is finished,
> > > > > both sides
> > > > > only use IP addresses).
> > > > >
> > > > > NEW:
> > > > >
> > > > > Both sctpAssocLocalAddrTable and sctpAssocRemAddrTable are
> > > > > indexed by
> > > > > addresses. 'Addr' and 'AddrType' objects use the syntax
> > > > > InetAddress
> > > > > and InetAddressType defined in the Textual Conventions
> > > > for Internet
> > > > > Network Address (RFC 3291). The InetAddressType TC has
> > > > codepoints
> > > > > for unknown, IPv4, IPv6, non-global IPv4, non-global
> > > > IPv6, and DNS
> > > > > addresses, but only the IPv4 and IPv6 address types are
> > > > required to
> > > > > be supported by implementations of this MIB module.
> > > > > Implementations
> > > > > that connect multiple zones are expected to support the
> > > > non-global
> > > > > IPv4 and non-global IPv6 address types as well.
> > > > >
> > > > > Note that DNS addresses are not used in this MIB module.
> > > > They are
> > > > > always resolved to the on-the-wire form prior to
> > > > connection setup,
> > > > > and the on-the-wire form is what appears in the
> MIB objects.
> > > > >
> > > > > ========================================================
> > > > >
> > > > > On page 21:
> > > > >
> > > > > - DELETE the following text from the DESCRIPTION clause
> > > > > of sctpAssocRemPrimAddr:
> > > > >
> > > > > Only IPv4 and IPv6 addresses are expected.
> > > > >
> > > > > ========================================================
> > > > >
> > > > > On pages 27, 28, and 29:
> > > > >
> > > > > - DELETE the following text from the DESCRIPTION clauses
> > > > > of sctpAssocLocalAddrType and sctpAssocRemAddrType:
> > > > >
> > > > > Only IPv4 and IPv6 addresses are expected.
> > > > >
> > > > > - DELETE the following text from the DESCRIPTION clauses
> > > > > of sctpAssocLocalAddr and sctpAssocRemAddr:
> > > > >
> > > > > Theoretically this could result in a more than
> > > 128 subid
> > > > > index, but that in practice it is only required
> > > to support
> > > > > IPv4 and IPv6 addresses, so it would never be
> > > more than 20
> > > > > octets.
> > > > >
> > > > > - INSERT the following text at the end of DESCRIPTION
> clause of
> > > > > sctpAssocLocalAddrEntry:
> > > > >
> > > > > Implementors need to be aware that if the size
> > > > > of sctpAssocLocalAddr exceeds 114 octets then OIDs
> > > > > of column instances in this table will have more
> > > > > than 128 sub-identifiers and cannot be accessed
> > > > > using SNMPv1, SNMPv2c, or SNMPv3.
> > > > >
> > > > > - INSERT the following text at the end of DESCRIPTION
> clause of
> > > > > sctpAssocRemAddrEntry:
> > > > >
> > > > > Implementors need to be aware that if the size
> > > > > of sctpAssocRemAddr exceeds 114 octets then OIDs
> > > > > of column instances in this table will have more
> > > > > than 128 sub-identifiers and cannot be accessed
> > > > > using SNMPv1, SNMPv2c, or SNMPv3.
> > > > >
> > > > > ========================================================
> > > > >
> > > > > On page 34:
> > > > >
> > > > > - in the DESCRIPTION clause of sctpLookupRemPrimIPAddrEntry
> > > > > make the following replacement:
> > > > >
> > > > > OLD:
> > > > > Theoretically this could result in a more
> > than 128 subid
> > > > > index, but that in practice it is only required
> > > to support
> > > > > IPv4 and IPv6 addresses, so it would be
> > always below the
> > > > > limit.
> > > > >
> > > > > NEW:
> > > > > Implementors need to be aware that if the size of
> > > > > sctpAssocRemPrimAddr exceeds 114 octets then OIDs
> > > > > of column instances in this table will have more
> > > > > than 128 sub-identifiers and cannot be accessed
> > > > > using SNMPv1, SNMPv2c, or SNMPv3.
> > > > >
> > > > > ========================================================
> > > > > On page 35:
> > > > >
> > > > > - INSERT the following text at the end of DESCRIPTION
> clause of
> > > > > sctpAssocRemAddrEntry:
> > > > >
> > > > > Implementors need to be aware that if the size
> > > > > of sctpAssocRemAddr exceeds 114 octets then OIDs
> > > > > of column instances in this table will have more
> > > > > than 128 sub-identifiers and cannot be accessed
> > > > > using SNMPv1, SNMPv2c, or SNMPv3.
> > > > >
> > > > > ========================================================
> > > > >
> > > > > On page 40, update the text of Section 5 ("Compiling
> > > > > Notes") as shown below:
> > > > >
> > > > > OLD:
> > > > >
> > > > > When compiling the MIB the following type of warning
> > can occur:
> > > > >
> > > > > . index of row 'sctpLookupRemPrimIPAddrEntry' can
> > > exceed OID size
> > > > > limit by 141 subidentifier(s)
> > > > >
> > > > > This is due to the fact that sctpAssocRemPrimAddr has
> > > the default
> > > > > InetAddress size of (0..255), which exceeds OID size
> > > limitations.
> > > > > Introducing a size restriction on sctpAssocRemPrimAddr
> > > > > would make the
> > > > > warning go away - - although it would be
> > > > > one of those arbitrary
> > > > > restrictions.
> > > > >
> > > > > NEW:
> > > > >
> > > > > When compiling the MIB module warnings similar to the
> > > > following may
> > > > > occur:
> > > > >
> > > > > warning: index of row `sctpAssocLocalAddrEntry' can
> > exceed OID
> > > > > size limit by 141 subidentifier(s)
> > > > > warning: index of row `sctpAssocRemAddrEntry' can
> exceed OID
> > > > > size limit by 141 subidentifier(s)
> > > > > warning: index of row `sctpLookupRemPrimIPAddrEntry' can
> > > > exceed OID
> > > > > size limit by 141 subidentifier(s)
> > > > > warning: index of row `sctpLookupRemIPAddrEntry' can
> > exceed OID
> > > > > size limit by 141 subidentifier(s)
> > > > >
> > > > > These warnings are due to the fact that the row objects
> > > > have index
> > > > > objects of type InetAddress whose size limit is 255
> > > > octets, and if
> > > > > that size limit were reached the names of column
> > > > instances in those
> > > > > rows would exceed the 128 sub-identifier limit imposed
> > > by current
> > > > > versions of the SNMP. Actual limitations for the index
> > > > > object sizes
> > > > > are noted in the conceptual row DESCRIPTION clauses, and
> > > > > will not be
> > > > > reached with any of the address types in current use.
> > > > >
> > > > > ========================================================
> > > > >
> > > > > Notes:
> > > > >
> > > > > The purpose in avoiding explicit mention of address types in
> > > > > the object
> > > > > DESCRIPTION clauses is so that new address types that are
> > > > > introduced in
> > > > > the future can be supported without having to make
> > changes to the
> > > > > DESCRIPTION clauses that would change the semantics of
> > > the objects.
> > > > > Such changes are not allowed by the SMI. The
> > compliance statement
> > > > > already make clear what is required to be supported by this
> > > > version of
> > > > > the MIB module, and new compliance statements can be
> > > > written if future
> > > > > developments warrant.
> > > > >
> > > > > Finally, the proposed wording changes are NOT intended to
> > > change the
> > > > > design, but only to clarify things for potential
> > implementors. If
> > > > > the authors feel that something in the proposal is
> > incorrect they
> > > > > should push back.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mike Heard
> > > > >
> > > >
> > >
> >
>
>