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?