Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)
draft-ietf-ancp-security-threats-08

[Ballot comment]
In section 3, first paragraph after the list of components:

  The threat model and the security requirments in this draft consider this
  later case.

s/later/latter/

In section 4, the document identifies three classes of attacks, but bullet three seems to identify two overlapping classes:

  o  attacks to gain profit for the attacker (e.g., by modifying the
      QoS settings).  Also, through replaying old packets, of another
      privileged client for instance, an attacker can attempt to
      configure a better QoS profile on its own DSL line increasing its
      own benefit.

This is fine if there are no attacks that gain profit which do not involve modifying the
QoS settings.  Are the authors confident that there are 3 rather than 4 classes?

[Ballot discuss]
The threat analysis and the resulting requirements do not cover any manageability aspects (I am not including AAA here). However the ANCP framework and WG charter include a MIB module, which can create by itself diclosure and mis-configuration related threats if the management channeld are not secured properly. I would expect the analysis to take this into consideration, and resulting requirements related to configuring and monitoring ANCP by management protocols to be added.

[Ballot comment]
In section 3, first paragraph after the list of components:

  The threat model and the security requirments in this draft consider this
  later case.

s/later/latter/

In section 4, the document identifies three classes of attacks, but bullet three seems to identify two overlapping classes:

  o  attacks to gain profit for the attacker (e.g., by modifying the
      QoS settings).  Also, through replaying old packets, of another
      privileged client for instance, an attacker can attempt to
      configure a better QoS profile on its own DSL line increasing its
      own benefit.

This is fine if there are no attacks that gain profit which do not involve modifying the
QoS settings.  Are the authors confident that there are 3 rather than 4 classes?

Updated proto shepherd doc



Document Shepard Write-Up





    (1.a) Who is the Document Shepherd for this document? Has the

          Document Shepherd personally reviewed this version of the

          document and, in particular, does he or she believe this

          version is ready for forwarding to the IESG for publication?



Matthew Bocci (matthew.bocci@alcatel-lucent.com)

        Yes, I have reviewed the document and I believe it is ready for ?        forwading to the IESG.





    (1.b) Has the document had adequate review both from key WG members

          and from key non-WG members? Does the Document Shepherd have

          any concerns about the depth or breadth of the reviews that

          have been performed?



        Yes, the document has received adequate review. The document ?        received in depth review from five reviewers  nominated by the ?        WG, as well as comments during WG last call.

       





    (1.c) Does the Document Shepherd have concerns that the document

          needs more review from a particular or broader perspective,

          e.g., security, operational complexity, someone familiar with

          AAA, internationalization or XML?



      No, although as it is a security threats analysis, close attention?      from the Security ADs would be appropriate.





    (1.d) Does the Document Shepherd have any specific concerns or

          issues with this document that the Responsible Area Director

          and/or the IESG should be aware of? For example, perhaps he

          or she is uncomfortable with certain parts of the document, or

          has concerns whether there really is a need for it. In any

          event, if the WG has discussed those issues and has indicated

          that it still wishes to advance the document, detail those

          concerns here. Has an IPR disclosure related to this document

          been filed? If so, please include a reference to the

          disclosure and summarize the WG discussion and conclusion on

          this issue.



      No specific concerns.





    (1.e) How solid is the WG consensus behind this document? Does it

          represent the strong concurrence of a few individuals, with

          others being silent, or does the WG as a whole understand and

          agree with it?



      I am comfortable that the document represents WG consensus and has?      been reviewed by a reasonable number of active WG aprticipants.





    (1.f) Has anyone threatened an appeal or otherwise indicated extreme

          discontent? If so, please summarise the areas of conflict in

          separate email messages to the Responsible Area Director. (It

          should be in a separate email because this questionnaire is

          entered into the ID Tracker.)



      None indicated.





    (1.g) Has the Document Shepherd personally verified that the

          document satisfies all ID nits? (See

          http://www.ietf.org/ID-Checklist.html and

          http://tools.ietf.org/tools/idnits/). Boilerplate checks are

          not enough; this check needs to be thorough. Has the document

          met all formal review criteria it needs to, such as the MIB

          Doctor, media type and URI type reviews?





      The document uses a per-5378 boilerplate because it was submitted prior?      to the change in boilerplate requirements.

      This is an informational security threats analysis, so was not subject?      to MIB doctor or other reviews.



    (1.h) Has the document split its references into normative and

          informative? Are there normative references to documents that

          are not ready for advancement or are otherwise in an unclear

          state? If such normative references exist, what is the

          strategy for their completion? Are there normative references

          that are downward references, as described in [RFC3967]? If

          so, list these downward references to support the Area

          Director in the Last Call procedure for them [RFC3967].



      Yes, the references are split appropriately. There is one reference?      to the ANCP framework, that will need to be updated as both documents

      should be published together.







    (1.i) Has the Document Shepherd verified that the document IANA

          consideration section exists and is consistent with the body

          of the document? If the document specifies protocol

          extensions, are reservations requested in appropriate IANA

          registries? Are the IANA registries clearly identified? If

          the document creates a new registry, does it define the

          proposed initial contents of the registry and an allocation

          procedure for future registrations? Does it suggest a

          reasonable name for the new registry? See [RFC5226]. If the

          document describes an Expert Review process has Shepherd

          conferred with the Responsible Area Director so that the IESG

          can appoint the needed Expert during the IESG Evaluation?



      The IANA considerations section exists and there are no requests

      for IANA allocations.





    (1.j) Has the Document Shepherd verified that sections of the

          document that are written in a formal language, such as XML

          code, BNF rules, MIB definitions, etc., validate correctly in

          an automated checker?



      There are no sections that use a formal language.





    (1.k) The IESG approval announcement includes a Document

          Announcement Write-Up. Please provide such a Document

          Announcement Write-Up? Recent examples can be found in the

          "Action" announcements for approved documents. The approval

          announcement contains the following sections:



Technical Summary



  The Access Node Control Protocol (ANCP) aims to communicate QoS-

  related, service-related and subscriber-related configurations and

  operations between a Network Access Server (NAS) and an Access Node

  (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)).  The

  main goal of this protocol is to allow the NAS to configure, manage

  and control access equipments including the ability for the access

  nodes to report information to the NAS.

  This document investigates security threats that all ANCP

  nodes could encounter.  This document develops a threat model for

  ANCP security aiming to decide which security functions are required.

  Based on this, security requirements regarding the Access Node

  Control Protocol are defined.



  This document is a product of the ANCP working group.



  This document is INFORMATIONAL.



Working Group Summary



The origin of the working group can be traced back to the WT-147 "Layer 2 Control Protocol" document from the Broadband Forum. The ANCP protocol being developed in the ANCP working group as a result of that document is typically used in the access and aggregation portions of a broadband access network, and also in inter-provider

environments. It was therefore decided as a part of the creation of the working group to document the security

threats that this protocol could encounter to ensure that they were fully accounted for in the protocol design

and that operators deploying the protocol were aware of any security threats. This draft is the result of that work.



Document Quality



The document is a security threats analysis, with the protocol being specified in a separate WG draft (draft-ietf-ancp-protocol). The latter has a number of implementations.

draft-ietf-ancp-security-threats-07.txt



Document Shepard Write-Up





    (1.a) Who is the Document Shepherd for this document? Has the

          Document Shepherd personally reviewed this version of the

          document and, in particular, does he or she believe this

          version is ready for forwarding to the IESG for publication?



Matthew Bocci (matthew.bocci@alcatel-lucent.com)

        Yes, I have reviewed the document and I believe it is ready for ?        forwading to the IESG.





    (1.b) Has the document had adequate review both from key WG members

          and from key non-WG members? Does the Document Shepherd have

          any concerns about the depth or breadth of the reviews that

          have been performed?



        Yes, the document has received adequate review. The document ?        received in depth review from five reviewers  nominated by the ?        WG, as well as comments during WG last call.

       





    (1.c) Does the Document Shepherd have concerns that the document

          needs more review from a particular or broader perspective,

          e.g., security, operational complexity, someone familiar with

          AAA, internationalization or XML?



      No, although as it is a security threats analysis, close attention?      from the Security ADs would be appropriate.





    (1.d) Does the Document Shepherd have any specific concerns or

          issues with this document that the Responsible Area Director

          and/or the IESG should be aware of? For example, perhaps he

          or she is uncomfortable with certain parts of the document, or

          has concerns whether there really is a need for it. In any

          event, if the WG has discussed those issues and has indicated

          that it still wishes to advance the document, detail those

          concerns here. Has an IPR disclosure related to this document

          been filed? If so, please include a reference to the

          disclosure and summarize the WG discussion and conclusion on

          this issue.



      No specific concerns.





    (1.e) How solid is the WG consensus behind this document? Does it

          represent the strong concurrence of a few individuals, with

          others being silent, or does the WG as a whole understand and

          agree with it?



      I am comfortable that the document represents WG consensus and has?      been reviewed by a reasonable number of active WG aprticipants.





    (1.f) Has anyone threatened an appeal or otherwise indicated extreme

          discontent? If so, please summarise the areas of conflict in

          separate email messages to the Responsible Area Director. (It

          should be in a separate email because this questionnaire is

          entered into the ID Tracker.)



      None indicated.





    (1.g) Has the Document Shepherd personally verified that the

          document satisfies all ID nits? (See

          http://www.ietf.org/ID-Checklist.html and

          http://tools.ietf.org/tools/idnits/). Boilerplate checks are

          not enough; this check needs to be thorough. Has the document

          met all formal review criteria it needs to, such as the MIB

          Doctor, media type and URI type reviews?





      The document uses a per-5378 boilerplate because it was submitted prior?      to the change in boilerplate requirements.

      This is an informational security threats analysis, so was not subject?      to MIB doctor or other reviews.



    (1.h) Has the document split its references into normative and

          informative? Are there normative references to documents that

          are not ready for advancement or are otherwise in an unclear

          state? If such normative references exist, what is the

          strategy for their completion? Are there normative references

          that are downward references, as described in [RFC3967]? If

          so, list these downward references to support the Area

          Director in the Last Call procedure for them [RFC3967].



      Yes, the references are split appropriately. There is one reference?      to the ANCP framework, that will need to be updated as both documents

      should be published together.







    (1.i) Has the Document Shepherd verified that the document IANA

          consideration section exists and is consistent with the body

          of the document? If the document specifies protocol

          extensions, are reservations requested in appropriate IANA

          registries? Are the IANA registries clearly identified? If

          the document creates a new registry, does it define the

          proposed initial contents of the registry and an allocation

          procedure for future registrations? Does it suggest a

          reasonable name for the new registry? See [RFC5226]. If the

          document describes an Expert Review process has Shepherd

          conferred with the Responsible Area Director so that the IESG

          can appoint the needed Expert during the IESG Evaluation?



      The IANA considerations section exists and there are no requests

      for IANA allocations.





    (1.j) Has the Document Shepherd verified that sections of the

          document that are written in a formal language, such as XML

          code, BNF rules, MIB definitions, etc., validate correctly in

          an automated checker?



      There are no sections that use a formal language.





    (1.k) The IESG approval announcement includes a Document

          Announcement Write-Up. Please provide such a Document

          Announcement Write-Up? Recent examples can be found in the

          "Action" announcements for approved documents. The approval

          announcement contains the following sections:



  The Access Node Control Protocol (ANCP) aims to communicate QoS-

  related, service-related and subscriber-related configurations and

  operations between a Network Access Server (NAS) and an Access Node

  (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)).  The

  main goal of this protocol is to allow the NAS to configure, manage

  and control access equipments including the ability for the access

  nodes to report information to the NAS.

  The present document investigates security threats that all ANCP

  nodes could encounter.  This document develops a threat model for

  ANCP security aiming to decide which security functions are required.

  Based on this, security requirements regarding the Access Node

  Control Protocol are defined.



  This document is a product of the ANCP working group.



  This document is INFORMATIONAL.