Subject: [ANCP] Re: ANCP Digest, Vol 6, Issue 12

From: "Hasnaa Moustafa" <[email-masked]>
Date: Wed, 29 Nov 2006 14:57:08 +0100

Hi Bharat,
Thanks for your comments.
Below are our replies inserted in your message. Hope that it is more clear
now.

Regards,
Hassnaa

On 11/27/06, [email-masked] <[email-masked]> wrote:
>
> Send ANCP mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www1.ietf.org/mailman/listinfo/ancp
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ANCP digest..."
>
>
> Today's Topics:
>
>   1.  Few questions and suggestions on
>      draft-moustafa-ancp-security-threats-00.txt  (bharat_joshi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 27 Nov 2006 22:08:24 +0530
> From: "bharat_joshi" <[email-masked]>
> Subject: [ANCP] Few questions and suggestions on
>        draft-moustafa-ancp-security-threats-00.txt
> To: <[email-masked]>
> Message-ID:
>        <
> [email-masked]>
> Content-Type: text/plain;       charset="us-ascii"
>
>
> Hi,
>
>    I have few questions and suggestions on this document:
>
> * In abstract, it is mentioned that ANCP is used for "qos-, service- and
> subscriber-related operations between NAS and AN". I think it should say
> 'xxx-related configurations; instead of 'xxx-related operations'.

 Hassnaa

This brief description for ANCP exactly conforms to the framework <
draft-ietf-ancp-framework-00.txt>. We are based on this draft in deriving
the threat model, and it is really "operations" and not just
"configurations". Advertising DSL line sync speed is not a "configuration",
the same for OAM.
Hassnaa/

* In abstract, the first statement in the second paragraph is a little
> complex. You may want rephrase it something similar to:
>
> This document investigates security threats that all network elements
> running ANCP could encounter. This document develops a threat model for
> ANCP security aiming to decide which security functions are required.

Hassnaa

For clarity and readability, it can be re-phrased, as you suggested.
Hassnaa/

* In Introduction, second paragraph, first sentence, I think it would be
> good it we can add "for ANCP" at the end to make it "[ID...] illustrates
> the framework, usage scenarios and general requirements for ANCP"

Hassnaa

Right
Hassnaa/

* In Introduction, second paragraph, Second sentence is not very clear.
> Its mentioned that document derives security requirements from ANCP.
> Should not it be "for ANCP" instead of "from ANCP" here?

Hassnaa

Right
Hassnaa/

* In Introduction, "Message Protection", there is something missing in
> statement:
>
> "This applies both to ANCP payloads, and ANCP should also provide such
> protection as a service to the different service parameters between the
> two peers."
>
> What is "both" referring to? I think you may want to add ANCP header and
> payload.

Hassnaa

Yes.
Hassnaa/

* In some ANCP document, it is proposed that ANCP session would be
> initiated by AN and so the NAS address need to be configured in there.
> In this case, how NAS will authenticate or authorize an AN?

Hassnaa

This is considered in the security requirements given in the draft. In
Section 7 in the draft, the following are mentioned:

-         the protocol solution MUST offer authentication of the AN to the
NAS

-         the protocol solution MUST offer authentication of the NAS to the
AN

-         the protocol solution MUST allow authorization to take place at
the AN and the NAS

But how this should take place is not the objective of this draft. The main
objective is deriving the security requirements, but not giving security
solutions.

Hassnaa/

* In figure #1, I think you may want to show a ATM/Ethernet Switch
> between NAS and AN as there could be multiple ANs connected to one NAS
> through this switch.

Hassnaa

The architectural details are given in the framework draft, and we mentioned
that we follow the same thing.
Hassnaa/

* Does the Home Gateway shown in figure #1 is at correct place? Should
> not it be before CPE? Something like HGW --- CPE --- Access Node?

Hassnaa

This conforms to the architecture given in the framework draft. Also,
considering the Access Loop real deployments, I do not see how the HGW
should be before the CPE as it is supposed to connect different CPEs to the
AN.
Hassnaa/

* In the definition of 'Home Gateway', I did not get the 'DSL Network
> Termination' part? Can you explain a little more?

Hassnaa

Details are given in the framework draft. This draft focuses on the threats
and security requirements. We think that no more explanation is needed,
especially that redundancy is not recommended between the two drafts, but
rather the security requirements draft should complement the framework
draft.
Hassnaa/

* In section 4, typo "Attackers against the access network" -> " Attacks
> against the access network".

Hassnaa

Yes, this was mentioned in our reply to the previous received comments.
Hassnaa/

* In section 5.3, Third paragraph, first sentence " When the ANCP allows
> the AN to dynamically discovery the NAS". I did not find any such
> reference in the ANCP framework document.

Hassnaa

This relates to ANCP functioning and is not related to the Use Cases defined
in the framework draft. It is mentioned that the ANCP allows the AN to
dynamically discover the NAS, given that ANCP will use TCP for exchanging
protocol messages 'as mentioned in the draft <
draft-wadhwa-gsmp-l2control-configuration-02.txt>). In this case, the
session is initiated from the AN to the NAS to avoid static provisioning on
the NAS for all the ANs that are being served by the NAS.

But since man-in-the-middle attack s also possible without dynamic
discovery, this sentence may be removed.
Hassnaa/

> * Typo "When the ANCP allows the AN to dynamically discovery the NAS
> then a", "discovery" -> "discover"

Hassnaa

Yes, it is typos.
Hassnaa/

* I think it might be good if we can add details on how a particular
> threat can be achieved and what is the solution to avoid a particular
> threeat?

Hassnaa

This is not at all the objective of this draft, we are not providing
solutions. We are providing general guidelines for any upcoming solutions.
Hassnaa/

* How does AN ensure that a request has been received by the correct
> NAS?

Hassnaa

The following security requirements, given in the draft (Section 7), can
assure this:

-         The protocol solution MUST offer authentication of the NAS to the
AN.

-         The protocol solution MUST provide data origin authenticity.
Hassnaa/

* In section 5.4, there is a list of information which a adversary can
> get if it can access the traffic and analyze it. I think this is
> possible only when the adversary has access to the network between AN
> and NAS. Right?

Hassnaa

No, not necessary. This may also take place by an external attacker on the
Internet affecting the Access Loop attributes sharing between the NAS and
the policy server (the second bullet in Section 6.1 explains this).
Hassnaa/

* In section 6.1, how a passive attacker can use the information of
> 'access loop configuration' for any access? Learning this information
> may not be proper but how it is a security threat?

Hassnaa

Here it is meant unauthorized information access by an attacker, through
later message modification for example. Re-phrasing will take place for
clarity.

Also, in case of 2 NASs belonging to different ISPs, one ISP may not see the
information of the other ISP. This might be sensitive information in some
cases.

Hassnaa/

* In section 6.1, I think off-path attack will always be there even if
> ANCP does not exist. I am not sure if this is required.

Hassnaa

This is required to show the off-path attacks that impact the proper
functioning of ANCP. In other words, we are showing all the attacks that
relates to ANCP functioning whether (on-path or off-path).
Hassnaa/

* In section 6.1, you may want to use 'lists' to talk about the attacks.
> For example:
>
> Those attacks may be:
>
> o Passive attacks
>     o First passive attack
>     o Second passive attack
> o Active attacks
>     o First active attack
>     o Second active attack
>
>    I am sure this way it will be more readable.

Hassnaa

Re-formatting may be considered for readability
Hassnaa/

* Are you sure that replaying of Config requests can be done by an
> attacker over TCP connections? I understand that after sniffing syn/ack,
> it can generate a possible message but can I replay the old config
> request which TCP itself would discard?

Hassnaa

Using TCP does not help to prevent replay attacks but provides some degree
of return routability checks through sequence numbers use. However, TCP is
not 100% safe for replay, it is only very hard.

Hassnaa/

* In section 6.4, how do we damage proxy functionality in AN? BTW, is AN
> doing IGMP snooping or IGMP proxy?

Hassnaa

As mentioned, signaling truncating disturb the proxy functionality (may be
rewording is needed). The framework draft states (in the multicast use case
description) that AN can do both IGMP snooping and IGMP proxy, this is
according to the framework draft. Any way, Section 6.4 has to wait until the
framework document tells more about multicast in the next version, then this
section will be updated accordingly.
Hassnaa/

* In section 6.4, more descriptive format of security consideration for
> Multicast can be added.

Hassnaa

Same as the previous point, since the multicast use case is in current
progress within the framework draft, we are thus analyzing the possible
threats related to this use case in a general and abstract manner.
Hassnaa/

* What triggers the requirement "The protocol solution SHOULD
> distinguish the control messages from the data"?

Hassnaa

This is important to help preventing replay signaling messages, and it is a
SHOULD requirement and not MUST.
Hassnaa/

* I think you should add details of specific cases on how a threat can
> be realized and what ANCP should do to avoid it?

Hassnaa

The draft contains a reasonable threat analysis,

Regarding (what ANCP should do) as you mentioned, will go through solution
details and is not the objective.
Hassnaa/

Thanks again,
Regards,
Hassnaa

Thanks & Regards,
> Bharat
>
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message. Further, you are not to copy, disclose, or distribute this e-mail
> or its contents to any other person and any such actions are unlawful. This
> e-mail may contain viruses. Infosys has taken every reasonable precaution to
> minimize this risk, but is not liable for any damage you may sustain as a
> result of any virus in this e-mail. You should carry out your own virus
> checks before opening the e-mail or attachment. Infosys reserves the right
> to monitor and review the content of all messages sent to or from this
> e-mail address. Messages sent to or from this e-mail address may be stored
> on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>
>
>
> ------------------------------
>
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ancp
>
>
> End of ANCP Digest, Vol 6, Issue 12
> ***********************************
>
_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "bharat_joshi" <[email-masked]>
Date: Thu, 30 Nov 2006 12:01:14 +0530

Hi Hassnaa,

    Thanks for the response. Please see my response in line. I have
removed those comments where we both are in sync.

Thanks & Regards,
Bharat

        * In abstract, it is mentioned that ANC
> P is used for "qos-,
>         service- and
> This brief description for ANCP exactly conforms to the framework
> <draft-ietf-ancp-framework-00.txt >. We are based on this draft in
> deriving the threat model, and it is really "operations" and not just
> "configurations". Advertising DSL line sync speed is not a
> "configuration", the same for OAM.
>
> Hassnaa/
>
>
Ok. If so can you make it 'operation and configurations'?

        * In some ANCP document, it is proposed that ANCP session would
>         be
>         initiated by AN and so the NAS address need to be configured
in
>         there.
> -         the protocol solution MUST offer authentication of the AN to
> the NAS
>
> -         the protocol solution MUST offer authentication of the NAS
to
> the AN
>
> -         the protocol solution MUST allow authorization to take place
> at the AN and the NAS
>
> But how this should take place is not the objective of this draft. The
> main objective is deriving the security requirements, but not giving
> security solutions.
>
> Hassnaa/
>
>
Ok.

        * In figure #1, I think you may want to show a ATM/Ethernet
>         Switch
> The architectural details are given in the framework draft, and we
> mentioned that we follow the same thing.
>
> Hassnaa/
>
>
I just saw that the figure is same as is mentioned in the framework
document.

> should be before the CPE as it is supposed to connect different CPEs
to
> the AN.  

I think the definition of CPE is what is making a difference. IMHO, CPE
is always the first device in the Customer Premises and typically is a
modem. If I am not wrong, your document also defines it as 'demarc'
point which is inline what I just mentioned.

In my opinion, Routing Gateway and Home gateway are generally connected
to the CPE and provides access to the internet to multiple users
connected to the home gateway.

Even if both Home Gateway and CPE is in the same device, still we should
be showing it as:

HGW --- CPE.

> Details are given in the framework draft. This draft focuses on the
> threats and security requirements. We think that no more explanation
is
> needed, especially that redundancy is not recommended between the two
> drafts, but rather the security requirements draft should complement
the
> framework draft.
OK. My mistake. Let me put this question to the framework document
authors.

        * In section 5.3, Third paragraph, first sentence " When the
>         ANCP allows
> This relates to ANCP functioning and is not related to the Use Cases
> defined in the framework draft. It is mentioned that the ANCP allows
the
> AN to dynamically discover the NAS, given that ANCP will use TCP for
> exchanging protocol messages 'as mentioned in the draft <
> session is initiated from the AN to the NAS to avoid static
provisioning
> on the NAS for all the ANs that are being served by the NAS.
>
Ok.

        * I think it might be good if we can add details on how a
>         particular
I did not question the objective of this draft. I have seen couple of
other drafts which describe security threats to protocols which does
note how a particular threat can be realized and what can be done to
avoid that threat. Anyway as you mentioned that its just for general
guidelines, I think its ok.

> No, not necessary. This may also take place by an external attacker on
> the Internet affecting the Access Loop attributes sharing between the
> NAS and the policy server (the second bullet in Section 6.1 explains
> this). 
> Hassnaa/
>
>
What I meant is that if its an external attacker, how will he be able to
snoop the traffic?

        * In section 6.1, I think off-path attack will always be there
>         even if
Ok.

        * In section 6.1, you may want to use 'lists' to talk about the
>         attacks.
Ok.

        * Are you sure that replaying of Config requests can be done by
>         an
>         attacker over TCP connections? I understand that after
sniffing
>         syn/ack,
> Using TCP does not help to prevent replay attacks but provides some
> degree of return routability checks through sequence numbers use.
> However, TCP is not 100% safe for replay, it is only very hard.
>
> Hassnaa/
>
>
Yes. I agree that using TCP can not be completely avoid replay attacks.

> This is important to help preventing replay signaling messages, and it
> is a SHOULD requirement and not MUST.
>
> Hassnaa/
>
>
How does it help in preventing replay signaling messages?

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***