[secdir] SECDIR review of draft-ietf-adslmib-vdsl2-07

[Richard Barnes <[e-mail]>]

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?