SECDIR review of draft-ietf-adslmib-vdsl2-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?






_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]