Subject: [ANCP] Working Group Last Call for draft-ietf-ancp-security-threats-02.txt

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 3 Sep 2007 16:00:16 +0200

This email is to announce the start of a two week Working Group last
call for draft-ietf-ancp-security-threats-02.txt.

Please read the draft and provide comments to the ANCP list by Tuesday
11th September.

As agreed during the Chicago meeting, the following participants kingly
volunteered to review the draft as a part of the WG LC:
Curtis Sherbo
Phillipe Niger
Michael Busser
Francios LeFaucher
Raymond Zhang

We would like to thank them in advance for their help.

We will not be in a position to progress the draft until we have
received comments from at least five reviewers. 

Regards,

Matthew & Woj

-----------------------------------------
Matthew Bocci
IP Division,
Alcatel-Lucent Telecom Limited, 
Registered Office: Christchurch Way, Greenwich, London SE10 0AG. 
Registered in England & Wales number 02650571
-----------------------------------------

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 10 Sep 2007 14:55:08 +0200

Hassnaa, Hannes, Stefaan,

Please find my review comments on draft-ietf-ancp-security- 
threats-02.txt.
I tried split them into Substantial Comments, Editorial Comments and  
Typos.
I hope these comments are useful.

Francois

1 Substantial Comments
===================

Section 1:
Is there not a well-established generic categorisation of protocol  
security risks that could be applied here (or is this the generic  
categorization)?

Section 7:
In addition to discussing attacks against the 4 uses cases, I suspect  
there would be value in discussing attacks during the "Protocol  
establishment phase" (ie ANCP discovery phase, ANCP peering  
establishment, ANCP Capability negotiation ...), Could this be added?
Does it lead to any additional security requirements specifically for  
the ANCP Discovery phase? or peering phase?

section 7.4:
There is an additional type of DOS attack that, I think, is not  
discussed in the current text. Since, in some mode of operation of  
ANCP for multicast, an IGMP join/leave received on AN validly  
triggers an ANCP message from AN to NAS, a HGW/CPE can effectively  
achieve a NAS DOS by generating heaps of IGMP join/leaves. I believe  
this is worth discussing separately because it cannot be addressed  
solely through security mechanisms inside the ANCP protocol. This  
risk is discussed in section "6. Security Considerations" of draft- 
maglione. Could the corresponding text describing the risk be  
incorporated here in section 7.4(with appropraite editing if needed)?
Section "6. Security Considerations" of draft-maglione also  
recommends specific mitigation approaches for this ("To mitigate this  
risk,..."). Could this recommendation be added in section 8 of ancp- 
security?

section 7.4:
One of the functions that ANCP has to enable for multicast is  
accounting. So a specific additional risk associated with the  
multicast use cases is tempering with accounting information (eg  
escaping charging or conversely over-charging another user).
Could you add a statement to that effect? For example, perhaps, at  
teh very end of section 7.4 we could add:
"	*   Messages's modifications to temper with accounting information,  
for example in order to avoid service charges or conversely in order  
to artificially increase service charges on other users"

section 8:
Based on discussions on the list re multicast use case security  
aspects, I'd suggest adding requirements along the line of
"   o    The protocol solution SHOULD ensure that, by default, IGMP  
join/leave requests received by AN are only relayed to NAS for those  
multicast flows that have been explicitly identified before by the  
NAS through ANCP"

section 8:
In case of DOS attacks on NAS as a result of IGMP leave/joins  
resulting in ANCP messages from AN to NAS, we would want the NAS to  
be able to stop ANCP messages generated by the AN. I would suggest  
adding a requirement along the lines of:
"   o    The protocol solution MUST allow the NAS to instruct the AN  
to stop issuing ANCP messages to the NAS on join/leave (i) from a  
particular AN port , (ii) for a particular multicast flow (or ranges  
of multicast flows) or (iii) combination thereof."

2 Editorial Comments
================

Abstract:
s/to configure and manage access equipments and allow them to report  
information to the NAS in order to enable and optimize configuration/ 
to allow the NAS to configure, manage and control access equipments,  
including the ability for the access nodes to report information to  
the NAS/

Section1, 2nd paragraph:
s/This document/The present document/

Section 1:
I don't quite get the exact meaning of the following sentence:
" and ANCP should also provide such protection as a service to the  
different service parameters between the two peers."
Is this saying that the protection should ensure protection of the  
various parameters manipulated inside the ANCP message? if yes, then  
I think this is already covered in previous sentence stating that the  
ANCP payload ought to be protected. If not, can you clarify what it  
means?

Section 1:
Current text says:
"  Prevention against Impersonation:
       It is important that signaling messages are delivered to the  
correct nodes, and nowhere else."
The description doesn't quite match the title. The description sounds  
more like "mis-delivery of message". Perhaps it should say something  
like:
"  Prevention against Impersonation:
       It is important that protection be available against a device  
impersonating an ANCP node (i.e. an unauthorized device generating an  
ANCP message and pretending it was generated by a valid ANCP node) "

Section 1:
Current text says:
"For the threat analysis, the protocol communication between the   
Access Node and the NAS is important whereas the other component,  
such as HGW, CPE, AAA server only play a role in the understanding of  
the system architecture.
"
Should this say something like:
"For the threat analysis, this document focuses on the ANCP protocol  
communication between the Access Node and the NAS. However,  
communications with the other components, such as HGW, CPE, AAA  
server play a role in the understanding of the system architecture  
and of what triggers ANCP protocol communications."

Section 4:
"Also, through replaying old packets, of another privileged client  
for instance, an attacker can configure a better QoS profile on its  
own DSL line increasing its own benefit.
"
in previous sentence s/can/can attempt to/

Section 7:
Current text says:
"However, once the AAA server has the authorization data then it is  
given to the NAS, which is more in the scope of this work. "
In previous sentence s/which is more/which is/

Section 7:
Current text says:
"Consequently, this document considers the attacks that are related  
to the ANCP operation and are concerning the communication between  
the NAS and the AAA/Policy server."
I think you want to say that this document is concerned with the ANCP  
communications that result from communications between the NAS and  
AAA/Policy Server. But it is not directly considering "the attacks  
that ....are concerning the communication between teh NAS and the AAA/ 
Policy Server.". Right?
Should this read:
"Consequently, this document considers the attacks that are related  
to the ANCP operation associated with communication between the NAS  
and the AAA/Policy server."

section 7.2:
s/DoS attacks can take place by an attacker/DoS attacks of the AN can  
take place by an attacker/

section 7.4:
s/this allows the NAS to follow subscribers' multicast (source,  
group) membership/this allows the NAS to follow subscribers'  
multicast (source, group) membership and control replication  
performed by the AN./

section 8:
I don't fully understand how the following translates in terms of  
ANCP Security requirements:
"   o  The protocol solution SHOULD distinguish the control messages  
from the data."
Can you elaborate?

section 9:
s/presenting the security requirements to be considered/presenting  
the security requirements to be considered for design of the ANCP  
protocol/

3 Typos
======

section 7.1:
s/injecting falsify packets/injecting falsified packets/

section 7.3:
s/carryout/carry out/

On 3 Sep 2007, at 16:00, BOCCI Matthew wrote:

>
> This email is to announce the start of a two week Working Group  
> last call for draft-ietf-ancp-security-threats-02.txt.
>
> Please read the draft and provide comments to the ANCP list by  
> Tuesday 11th September.
>
> As agreed during the Chicago meeting, the following participants  
> kingly volunteered to review the draft as a part of the WG LC:
>
> Curtis Sherbo
> Phillipe Niger
> Michael Busser
> Francios LeFaucher
> Raymond Zhang
>

---

From: "Busser, M" <[email-masked]>
Date: Tue, 11 Sep 2007 15:40:53 +0200

Hi Hassnaa, Hannes and Stefaan.
 
After reviewing the draft, i have the following comment:
 
Section 7:
Do we have some additional security requirements, when taking the "protocol setup phase" into account (beside the 4 use cases)?

Best Regards; Freundliche Grüße 

Michael Busser

T-Systems Enterprise Services GmbH 
Production Line Network Centric Systems
ICT-Systems Integration
Network Integration Services
 
Brückes 2 -8, 55545 Bad Kreuznach
Postfach 9100, 55541 Bad Kreuznach
+49 671 8333 8911 (Phone)
+49 521 9210 3859 (Fax)
+49 151 1211 9689 (Mobile)
E-Mail: [email-masked]
Internet:  <http://www.t-systems.com/> http://www.t-systems.com 

T-Systems Enterprise Services GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, 
Dr. Herbert Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644
*Geschäftsführer gem. § 35 GmbHG 

Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. 
T-Systems - Business flexibility 

-----Ursprüngliche Nachricht-----
Von: BOCCI Matthew [mailto:[email-masked]] 
Gesendet: Montag, 3. September 2007 16:00
An: [email-masked]
Betreff: [ANCP] Working Group Last Call fordraft-ietf-ancp-security-threats-02.txt

This email is to announce the start of a two week Working Group last call for draft-ietf-ancp-security-threats-02.txt. 

Please read the draft and provide comments to the ANCP list by Tuesday 11th September. 

As agreed during the Chicago meeting, the following participants kingly volunteered to review the draft as a part of the WG LC:

Curtis Sherbo
Phillipe Niger
Michael Busser
Francios LeFaucher
Raymond Zhang 

We will not be in a position to progress the draft until we have received comments from at least five reviewers. 

Regards, 

Matthew & Woj

---

From: "NIGER Philippe RD-RESA-LAN" <[email-masked]>
Date: Wed, 12 Sep 2007 11:27:00 +0200

Hi All,
 
After reviewing the draft, please find my comments below.

Regards,
 
Philippe Niger.
 
------------------------------------------------------------------

No major comments.

Important comments.

- In the section 3 it is indicated that "the NAS and AN might belong to two different administrative realms". It could be useful to indicate here if the threat model and the derived requirements apply also in that configuration or are limited to a configuration in which the NAS and the AN belong to the same administrative entitiy.

- At the end of the first paragraph of section 7 it is indicated that "this document considers the attacks that are related to the ANCP operation and are concerning the communication between the NAS and the AAA/Policy server". As ANCP is running between the AN and the NAS this sentence should be clarified (e.g. indicating that the data targeted by the attacks are those exchanged between the NAS and the AAA server and the derived security requirements applied when these data are transported over ANCP between the AN and the NAS).

Minor comments (editorial).

-0- Abstract :

The Access Node Control Protocol (ANCP) aims to communicate QoS-, service- and subscriber-related configurations... 

Change to : The Access Node Control Protocol (ANCP) aims to communicate QoS-[related], service-[related] and subscriber-related configurations... 

-1- Introduction :

Same change as described above.

-2- Terminology

This section should be renamed as "Specification of requirements" and moved before the "Introduction" section.

-3- Systeme Overview and Threat Model

- Home Gateway (HGW): The HGW connects the different Customer Premises Equipment (CPE)... 

Change to : Home Gateway (HGW): The HGW connects the different Customer Premises Equipment [s] (CPE)... 

- Aggregation Network: The aggregation network provides traffic aggregation from multiple ANs towards the NAS. ATM or Ethernet technologies can be used. 

Change to : Aggregation Network: The aggregation network provides traffic aggregation from multiple ANs towards the NAS. ATM or Ethernet [transport] technologies can be used. 

- Attackers can be: o off-path, i.e., it cannot see packets between the AN and the NAS; o on-path, i.e., they can see the message exchange between the AN and the NAS. 

Change to : Attackers can be: o off-path, i.e., [they] cannot see packets between the AN and the NAS; o on-path, i.e., they can see the message exchange[s] between the AN and the NAS. 

- Both off-path and on-path attackers can be: o passive, i.e., they do not participate in the network but rather listen to all transfer to obtain the maximum possible information; o active, i.e., they participate to the network and can inject falsify packets. 

Change to : Both off-path and on-path attackers can be: o passive, i.e., they do not participate in the network [operation] but rather listen to all transfer[s] to obtain the maximum possible information; o active, i.e., they participate to the network [operation] and can inject falsif[ied] packets. 

-5- Potential Attacks

- paragraph 5.1 : ... is a chance to mount denial of services attacks...

Change to : ...is a chance to mount denial of service[] attacks...

- paragraph 5.3 : An insecure parameter exchange or security negotiation protocol can help an adversary to mount a downgrading attack...

Change to : An insecure parameter exchange or security negotiation protocol can [give the opportunity to] an adversary to mount a downgrading attack...

- paragraph 5.4 : ...capturing all traversed packets

Change to : ...capturing all [traversing] packets

- paragraph 5.4 : ...containing some information related to the connected client, indicating the client's existing at home. 

Change to : ...containing some information related to the connected client []. Or clarify the end of the sentence [indicating the client's existing at home].

-6- Attacks Forms

- title : Attacks Forms

Change to : Attack[] Forms.

- Through replaying of signaling messages, an adversary might mount a denial of service and theft of service attacks.

Change to : Through replaying of signaling messages, an adversary might mount a denial of service and [a] theft of service attacks.

- This could be at the signaling protocol level, at the level of a specific signaling parameters (e.g., QoS information), or the transport layer. An adversary might, for example, inject signaling message... 

Change to : This could be [achieved] at the signaling protocol level, at the level of a specific signaling parameters (e.g., QoS information), or [at] the transport layer. An adversary might, for example, inject [a] signaling message...

- ... reordering and delaying of messages causing a protocol's process failures. 

Change to : ...reordering and delaying of messages causing a protocol's process failure[]. 

- In this case the protocol could appear to continue correctly. 

Change to : In this case the protocol could appear to continue [working] correctly. 

-7- Attacks against ANCP Defined Use Cases

- ... concerning how the user gets authenticated and how the AAA server gets...

Change to : ...concerning how the user [are] authenticated and how the AAA server gets...

- paragraph 7.1 : Active, acting on the transferred attributes and injecting falsify packets.

Change to : Active, acting on the transferred attributes and injecting falsif[ied] packets.

- paragraph 7.1 : Passive gaining information of the access loop attributes.

Change to : Passive gaining information [on] the access loop attributes.

- paragraph 7.3 : Most of the attacks in this use case concern the network functionality.

Change to : Most of the attacks in this use case concern the network [operation].

- paragraph 7.3 : ...where an adversary can inject falsify signals or can truncate the triggering.

Change to : where an adversary can inject falsif[ied] signals or can truncate the triggering

-11- IANA Considerations

This section should be moved before the "Acknowledgments" section.

-12- References

The reference to the Framework document should be updated (version -02).

________________________________

De : BOCCI Matthew [mailto:[email-masked]] 
Envoyé : lundi 3 septembre 2007 16:00
À : [email-masked]
Objet : [ANCP] Working Group Last Call fordraft-ietf-ancp-security-threats-02.txt

Curtis Sherbo
Phillipe Niger
Michael Busser
Francios LeFaucher
Raymond Zhang 

Regards, 

Matthew & Woj

---

From: "Curtis Sherbo" <[email-masked]>
Date: Wed, 12 Sep 2007 11:09:41 -0700

I have reviewed the draft and have the following editorial comments:

5.4. Traffic Analysis An adversary can be placed at the NAS, or the AN, or
any other network element capturing all traversed packets. Adversaries can 

Internet-Draft ANCP Threats July 2007 thus have unauthorized information
access. As well, they can gather information relevant to the network and
then use this information in gaining later unauthorized access. This attack
can also help adversaries in other malicious purposes, as for example
capturing messages sent from the AN to the NAS announcing that a DSL line is
up and containing some information related to the connected client,
indicating the client's existing at home. <<--- Don't know what this means?

6. Attacks Forms 

Should Read Attack Forms

The text in read perhaps would read better if it said "which is in scope of
this work".

7.However, once the AAA server has the authorization data then it is given
to the NAS, which is more in the scope of this work. Consequently, this
document considers the attacks that are related to the ANCP operation and
are concerning the communication between the NAS and the AAA/Policy server. 

7.1 Active, acting on the transferred attributes and injecting falsify
packets. The main attacks here are: 

Should perhaps be falsified

Curtis Sherbo 

  _____  

From: BOCCI Matthew [mailto:[email-masked]] 
Sent: Monday, September 03, 2007 7:00 AM
To: [email-masked]
Subject: [ANCP] Working Group Last Call
fordraft-ietf-ancp-security-threats-02.txt

This email is to announce the start of a two week Working Group last call
for draft-ietf-ancp-security-threats-02.txt. 

Please read the draft and provide comments to the ANCP list by Tuesday 11th
September. 

Curtis Sherbo
Phillipe Niger
Michael Busser
Francios LeFaucher
Raymond Zhang 

We will not be in a position to progress the draft until we have received
comments from at least five reviewers. 

Regards, 

Matthew & Woj