[Adslmib] FW: SECDIR review of draft-ietf-adslmib-vdsl2-07

["Romascanu, Dan (Dan)" <[e-mail]>]

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Richard Barnes
Sent: Thursday, June 25, 2009 7:06 AM
To: SECDIR; IESG; IETF Discussion;
[e-mail]
Subject: SECDIR review of draft-ietf-adslmib-vdsl2-07

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.

  These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document describes an SNMP MIB for managing VDSL interfaces,
extending existing MIBs for managing other classes of DSL interfaces. As
such, the primary security issues are related to the risks associated
with read, create, or write access to various tables and objects.

Overall, the Security Considerations does a good job of describing the
risks associated with use of this MIB and the security mechanisms that
should be used to mitigate them.  My only concerns are that:
1. There is no mandatory security mechanism, either for implementation
or deployment, and that 2. Risks related to read-only fields may require
a slightly more thorough treatment Beyond these two minor issues, the
comments below are focused on the clarity of the security discussion,
rather than its content.

--Richard



-----
The current security considerations section has three main parts:
1. A list of fields with write/create access and associated risks 2. A
list of fields with read access that pose especial risks 3.
Recommendations as to how to mitigate these risks Comments below are
organized accordingly.

1. Objects with write/create access

1.1. The current list seems to be comprehensive, but it can be difficult
for the reader to get a general idea of what the high-level risks are
and how these relate to the individual Objects.  It could be helpful to
group these tables and objects under classes of general risks (maybe in
subsections), or alternatively, to tag each table or object with an
indicator of which classes of risk it introduces.  The list I came up
with as I was reading was as follows:
1.1.1. Disruption of service
1.1.2. Degradation of service
1.1.3. Information loss or overload
1.1.4. Privilege escalation / unauthorized access to lines/channels
1.1.5. Multiple lines/channels/profiles/templates affected

1.2. The phrase "adverse operational effect" is too vague.  Suggest
trying to find something more specific to say (maybe from the above
list?)

2. Objects with read access

2.1. It's a good first step to list the fields you do here.  I'm
wondering though, whether there is some interaction between other
readable fields and the writable objects discussed previously.  Are
there situations where reading objects could allow an adversary to gain
information that would allow him to better exploit a write permission he
has?  E.g., an attacker that can read objects related to monitoring
(e.g., counter) might be able to determine what attacks would be
detectable by the current monitoring configuration and which would not. 
  It's not necessary (or even necessarily possible) to list all the
possible interactions here, but it would be helpful to have a general
note that they exist, and possibly a recommendation that any given user
be given access only to the objects he needs (e.g. only to objects
within a given set of tables), not all readable objects.

3. Recommendations for mitigations

3.1. The reference to Section 8 of RFC 3410 ("Standardization Status")
seems incorrect.  Suggest changing to refer to section 6.4, 7.8, or 7.9,
or simply to refer to RFC 3414 and 3415.

3.2. The phrase "using IPsec" is unclear here.  I assume this means
"using IPsec to connect sites that are remote from each other".

3.3. "IPSec" should be "IPsec"

3.4. What is the reason for not requiring implementations to provide
support for SNMPv3 security mechanisms?  The SHOULD=MUST+exceptions
(i.e., RECOMMENDED=REQUIRED+exceptions) pattern could be useful here --
when is it acceptable for an implementation to omit security support?