Re: [Dime] AD review for draft-ietf-dime-diameter-qos-08.txt

["Sun, Dong (Dong)" <dongsun at alcatel-lucent.com>]

Dan,

I am taking a crack at your comments. See inline...

Avri,
I though you authored the security section. Could you take a look at comments T8/9/10 and respond?

Regards,
Dong 

-----Original Message-----
From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, June 24, 2009 1:12 PM
To: dime at ietf.org
Subject: [Dime] AD review for draft-ietf-dime-diameter-qos-08.txt


Please find below the AS review for draft-ietf-dime-diameter-qos-08.txt.
I believe that there is a need for a revised ID before going to IETF Last Call in order to clarify a number of questions and fix a few more. 

The comments below are divided into Technical and Editorial.

T1. Can the QoS application support multiple concurrent sessions between an NE and an AE? I think that we need to clarify and add adequate text.
>>yes. The QoS application session can be associated with a subscriber. Will add some texts as the last paragraph in section 4.2:
"The QoS authorization session is typically established per subscriber base (i.e.all requests with the same user ID), but it is also possible to be established on per node or per request base. The concurrent sessions between an NE and an AE are identified by different Session-ID. "

T2. Can an NE work with multiple AEs? The security considerations section mentions this as a problem but provides no hints as to how to solve it. I think that we need to clarify and add adequate text.

>> suggest to remove following sentences from section 11 since they are incorrect. 
"Lastly, there can be security vulnerability to the applications
   traversing a Network Element when a resource on a Network Element is
   controlled by multiple Authorizing Entities.  The operation of a
   Network Element may be disrupted due to conflicting directives from
   multiple Authorizing Entities.  Care must be taken in deployment to
   ensure that Network Elements are impacted by misconfiguration."

The following texts will be added into section 4.2.2 (at the end of the section).
"In the case Multiple AEs control the same NE, the NE should make the selection on the authorization decision to be enforced based on the priority of the request. "

T3. Are different modes of operation supported for a given NE? I think that we need to clarify and add adequate text.
>> yes. The operation mode is on per session. It is descrbed under section 4.2. 

T4. The Terminology section mentions that an AE corresponds to an RFC
2573 PDP and an NE corresponds to an RFC 2573 PEP. I am wondering why we go through the pain of inventing a new set of terms (AE, NE) and we do not just use the 2573 terminology all over. 
>> one of reasons to define new terms is to have a clear scope of the functionality. I think the AE and NE are well defined. If the linkage to PDP/PEP causes the confusion, the sentence could be removed. But I personally feel it is ok to leave it as now.  

T5. In Section 2 - 'For example, a SIP Agent is one kind of Application Endpoint.' - is this a SIP User Agent? 
>> yes.

T6.In section 4.2.1 

   The AE's identity, information about the application session and/or
   identity and credentials of the QoS RRE, requested QoS parameters,
   signaling session identifier and/or QoS enabled data flows
   identifiers MAY be encapsulated into respective Diameter AVPs and
   included in the Diameter message sent to the AE.  

Why is this a MAY? Is there another way to pass AE identity information at session establishment (assuming we are doing Diameter and not something else)
>> The MAY here means not every parameter has to be included. Concerning AE's ID, it may not need if the security is not a concern in the deployment.

T7. In the table the data type of the QoS-Authorization-Data attribute is Grouped, while in the textual description it shows as OctetString
>> I think it should be OctetString. Otherwise, we need to define what're in the grouped AVP.

T8. I find the security considerations section weak. I suggest that for each threat the security mechanisms within Diameter or external to Diameter that can be used for protection be explicitly mentioned. 
>> I am neither security expert nor the author of this section. 
Avri, could you take care of this comment as well T9/T10. I will incorporate into next version.

T9. Logging for security events related to authentication and authorization should be enhanced by sending alerts to a management system (if available)

T10. 'Failing to provide the required credentials should be subject to logging.'. Why is this a non-capitalized should and not a capitalized MUST? 



E1. Potential problems detected by idnits: 
>> I will fix all nits in next version.
 Miscellaneous warnings:
 
------------------------------------------------------------------------
----

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.). 

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.

      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."


  Checking references for intended status: Proposed Standard
 
------------------------------------------------------------------------
----

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

 ...

  == Outdated reference: A later version (-12) exists of
     draft-ietf-dime-qos-attributes-11

  == Outdated reference: A later version (-11) exists of
     draft-ietf-dime-qos-parameters-10

  ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234)

  == Outdated reference: A later version (-20) exists of
     draft-ietf-nsis-ntlp-19

  -- Obsolete informational reference (is this intentional?): RFC 4346
     (Obsoleted by RFC 5246)

E2. In section 3.1 

   Note that the parameters passed to the Traffic
   Control function may be different from requested QoS (depending on
   the authorization decision). 

should rather be

  Note that the parameters passed to the Traffic
   Control function may be different from the ones in the requested QoS (depending on
   the authorization decision). 
>>ok

E3. In section 3.2.2 page 13:

either Push mode or Pull mode may be used

Better to use MAY with 2119 capitalization
>>ok

E4. The language used in the requirements in section 3.4 is confusing.
Many of the requirements are being expressed on the 'QoS AAA protocol' - should not they be rather on the 'Diameter QoS application'? 
>>ok

E5. The term 'Bearer' in the Bearer Gating requirement should probably be replaced with some other more IP-friendly term
>> how about 'media'?

E6. In the Accounting Correlation requirement 'may' should be capitalized to MAY
>>ok

E7. In the 'Interaction with other AAA Applications'  required should be capitalized to REQUIRED
>>ok

E8. 

   Authentication of the QoS reservation requesting entity to the AE is
   necessary if a particular Diameter QoS application protocol run
   cannot be related (or if there is no intention to relate it) to a
   prior authentication. 

Something is missing or wrong here. What is a 'Diameter QoS application protocol run'? 
>> might be an editing nit. will delete them.

E9. In Section 4.2.1

   The
   NE generates a QAR message in which the required objects from the QoS
   signaling message that is converted to Diameter AVPs.

Bad syntax makes this phrase impossible to understand.
>> revised as:
"The NE converts the required objects from the QoS signaling message to Diameter AVPs and generates a QAR message"

E10. In Section 4.2.2

   The indication of QoS reservation and activation of the data flow can
   be provided by the QoS-Install-Answer message immediately.  In the
   case of successful enforcement, the Result-Code (= DIAMETER_SUCCESS,
   (see Section 7.1)) information is provided in the QIA message.  Note
   that the reserved QoS resources reported in the QIA message MAY be
   different than those initially authorized with the QIR message, due
   to the QoS signaling specific behavior (e.g., receiver-initiated
   reservations with One-Path-With-Advertisements) or specific process
   of QoS negotiation along the data path.  When path coupled signaling
   is used for QoS reservation along the data path, QAR/QAA may be used
   to update the results of QoS reservation and enforcement following
   the establishment of data flows.

The usage of keywords seems to be wrong in this paragraph. The first MAY should rather be a 'may' while in the last phrase the 'may' seems to indicate a requirement, so it should rather be capitalized as MAY.
>> Ok.

E11. Last sentence in section 4.2.3 s/or globally routable IP address/or a globally routable IP address/
>> ok.

E12. In section 5 s/Diameter nodes conforming to this specification MAY advertise support by including/Diameter nodes conforming to this specification MAY advertise support for the Diameter QoS Application by including/  
>>ok

E13. It is recommended to put all the ABNF definitions in section 5 in an Annex that can also include in one place the copyright notice. 
>> you mean all the message content? Seems not the common way for Diameter specs.

E14. In section 6/1 s/This MUST be supported/These MUST be supported/
>> ok
 

Thanks and Regards,

Dan



_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime