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

From: "Hasnaa Moustafa" <[email-masked]>
Date: Fri, 1 Dec 2006 10:09:50 +0100

Hi Bharat,
Thanks again for your comments.
Please find some clarifications in line.

Regards,
Hassnaa

On 11/30/06, bharat_joshi <[email-masked]> wrote:
>
>
> 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
> >         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/
> >
> >
> Ok. If so can you make it 'operation and configurations'?

Hassnaa: Ok, then no problem on this point.

       * 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/
> >
> >
> Ok.

Hassnaa: then OK.

       * 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/
> >
> >
> I just saw that the figure is same as is mentioned in the framework
> document.

Hassnaa: then it is clear now.

>       * 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/
> >
> >
>
> 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.

Hassnaa: I could not get your point! For us, CPE refers to an end-user
workstation (such as PC) together with the associated equipments that is
connected to the "demarc", and the HGW connects the CPE to the Access
Node.  Anyway,
this concerns more the framework document.

>       * 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/
> >
> OK. My mistake. Let me put this question to the framework document
> authors.

Hassnaa: then there is no issue here.

       * 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/
> >
> >
> Ok.

Hassnaa: Then, OK

       * 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/
> >
> >
> 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.

Hassnaa: At this phase of work, we are seeking requirements and general
guidelines.

>         * 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/
> >
> >
> What I meant is that if its an external attacker, how will he be able to
> snoop the traffic?

Hassnaa: External attacker represent an issue, during information sharing
between the NAS and the Policy Server. This can take place in the Dynamic
Access Loop Attributes Use Case where Access Loop characteristics
information received at the NAS is shared with the policy server.

       * 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/
> >
> >
> Ok.

Hassnaa: Then OK.

       * 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/
> >
> >
> Ok.

Hassnaa: Then 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,
> >         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/
> >
> >
> Yes. I agree that using TCP can not be completely avoid replay attacks.

Hassnaa: Then OK.

       * 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/
> >
> >
> How does it help in preventing replay signaling messages?

Hassnaa: By data here it is meant, the information transferred by a
reporting function to a controller function containing status information.
On the other hand messages sent by a controller function for either
information requests or triggering certain network element are signaling
messages. So, distinguishing between these messages types can help in
detecting replay signaling. In other words, the protocol should distinguish
between data and signaling because when the AN receives data, then there is
something wrong and the AN should ignore this. Similarly, a NAS receiving
signaling (ex: ANCP messages containing configuration request) should ignore
them.

Regards,

Hassnaa

**************** 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

---

From: Sven Ooghe <[email-masked]>
Date: Fri, 08 Dec 2006 16:22:52 +0100

Bharat, Hasnaa,

Allow me to come back to the question concerning CPE vs Home Gateway 
(HGW) terminology.

In DSL access architecture documents, traditionally the term "Broadband 
Network Termination" (B-NT) was used to refer to the DSL modem. That 
connected to the Customer Premises Equipment (CPE). See e.g. DSL Forum 
TR-025 and TR-058.

So traditionally we had:

LAN devices = CPE <---> B-NT <---> DSLAM <---> BRAS

Over time, the functionality of the DSL modem got more advanced, and the 
terms "Routing Gateway" and "Residential Gateway" were introduced. These 
replaced the "B-NT" term.

In the ANCP framework we have opted for the term Home Gateway to avoid 
confusion between "Routing" and "Residential" Gateways - both having the 
abbreviation "RG" but they have different connotations to some people.

The LAN devides in the home are then called the Customer Premises 
Equipment (CPE).

Regards,
Sven

bharat_joshi wrote:

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