Subject: [ANCP] Re: ANCP Digest, Vol 16, Issue 8

From: "Hasnaa Moustafa" <[email-masked]>
Date: Mon, 17 Sep 2007 11:19:44 +0200

Dear Philippe,

Thanks you a lot for reviewing and for all your remarks.

Please find our replies below.

Best Regards,
Hassnaa

Date: Wed, 12 Sep 2007 11:27:00 +0200
> From: "NIGER Philippe RD-RESA-LAN" <[email-masked]>
> Subject: RE: [ANCP] Working Group Last Call
>        fordraft-ietf-ancp-security-threats-02.txt
> To: <[email-masked]>
> Message-ID: <BBBE5BAA3B351C488C415EA662EA8840047F8FB9@ftrdmel2>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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.

Actually, the threat model in the draft and the security requirements apply
to this case. So a statement will be added here to confirm this point.

- 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).

Ok, may be more clarification is needed to show that the threat model and
the security requirements takes into consideration the data transfer between
the NAS and the AAA server, when this data is used within the ANCP
operation.

Minor comments (editorial).

We agree with most of the coming comments concerning some editorial
modifications.

-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
>
>
>
>
> 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
> -----------------------------------------
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www1.ietf.org/pipermail/ancp/attachments/20070912/fa7a3089/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ancp
>
>
> End of ANCP Digest, Vol 16, Issue 8
> ***********************************
>
_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp