Skip to main content

Last Call Review of draft-ietf-adslmib-vdsl2-

Request Review of draft-ietf-adslmib-vdsl2
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-06-30
Requested 2009-06-13
Authors Scott Baillie , Moti Morgenstern , Umberto Bonollo
I-D last updated 2009-06-25
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes
State Completed
Request Last Call review on draft-ietf-adslmib-vdsl2 by Security Area Directorate Assigned
Completed 2009-06-25
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.


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?