Subject: [Dime] review of rfc3588bis, until about page 10

From: Jari Arkko <[email-masked]>
Date: Sun, 18 Jan 2009 12:16:52 +0200

Here's the first part of my review:

>    The Diameter base protocol is intended to provide an Authentication,
>    Authorization and Accounting (AAA) framework for applications such as
>    network access or IP mobility.  Diameter is also intended to work in
>    both local Authentication, Authorization & Accounting and roaming
>    situations.  This document specifies the message format, transport,
>    error reporting, accounting and security services to be used by all
>    Diameter applications.  The Diameter base application needs to be
>    supported by all Diameter implementations.
>   

s/intended to provide/provides/
s/intended to work/works/

or are you unsure about this? :-)

>    Authentication, Authorization and Accounting (AAA) protocols such as
>    TACACS [RFC1492 <http://tools.ietf.org/html/rfc1492>] and RADIUS [RFC2865 <http://tools.ietf.org/html/rfc2865>] were initially deployed to
>    provide dial-up PPP [RFC1661 <http://tools.ietf.org/html/rfc1661>] and terminal server access.  Over time,
>    with the growth of the Internet and the introduction of new access
>    technologies (including wireless, DSL, Mobile IP and Ethernet), both
>    the amount and complexity of processing performed by routers and
>    network access servers (NAS) have increased, putting new demands on
>    AAA protocols.
>   

Maybe ... Over time, AAA was needed on many new access technologies, the 
scale and complexity of AAA networks grew, and AAA was also used on new 
applications (such as voice over IP). This lead to new demands on AAA 
protocols.

> Since within [RFC4306 <http://tools.ietf.org/html/rfc4306>] authentication
> occurs only within Phase 1 prior to the establishment of IPsec SAs
> in Phase 2, it is typically not possible to define separate trust
> or authorization schemes for each application.
What phase 1 and 2? IKEv2 no longer has them...

>    The Diameter base protocol provides the following facilities:
>
>    o  Delivery of AVPs (attribute value pairs)
>   
This reads a bit funny. I'd say

o  Ability to exchange messages and deliver AVPs (attribute value pairs)

> AVPs are
>    used by the base Diameter protocol to support the following required
>    features:
>
>    o  ...
>
>    o  Relaying, proxying and redirecting of Diameter messages through a
>       server hierarchy.
>   

Maybe "Routing, relaying, ..." (because the basic routing functionality 
too relies on AVPs).

> At this time the focus of Diameter is network
>    access and accounting applications.
I do not know if this is true any more. Maybe "The initial focus of 
Diameter was network ..."

To be continued...

Jari

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Jari Arkko <[email-masked]>
Date: Sun, 18 Jan 2009 23:50:17 +0200

More review...

> The Diameter discovery
> process now supports only well known discovery schemes.
Maybe s/well known/widely used/

> IETF Review [RFC2434 <http://tools.ietf.org/html/rfc2434>],
Obsolete reference, use 5226.

> 11.4. AVP Values
>
>    Certain AVPs in Diameter define a list of values with various
>    meanings.  For attributes other than those specified in this section,
>    adding additional values to the list can be done on a First Come,
>    First Served basis by IANA.

What does "attributes other than those specified in this section" refer 
to? AVPs from this spec but not listed here? All AVPs not listed here? 
If its the latter, then the rules will be in conflict with some other 
specification, say, RFC 4005 has IETF Consensus rule for an AVP, 
Accounting-Auth-Method.

But even if it would only refer to AVPs from this spec, FCFS does not 
work for their values, e.g., addresses in Host-IP-Address AVP.

Finally, presumably {Auth,Acct}-Application-Id AVPs do not fall under 
the FCFS rule?

Suggested rewrite:

11.4. AVP Values

   Certain AVPs in Diameter define a list of values
   with various meanings. This section lists such
   attributes in the Diameter base protocol and their
   IANA allocation rules.

   Allocation of Application Ids was discussed in Section
   11.3. Other attributes in the base protocol do not take
   enumerated values or bit masks or employ existing
   name spaces such as SMI Network Management
   Private Enterprise Codes [RFC3232] or IP addresses.
   The allocation of new values for these existing name
   spaces is done in accordance with the rules already defined
   for them.

11.4.x. Experimental-Result-Code AVP

   Values for this AVP are purely local to the indicated
   vendor, and no IANA registry of them is maintained.

11.4.1 (the rest of the section continues as in the current draft)

> the data types listed in Section 4.2 or 4.3. 

This would be better as Section 4.2 or Section 4.3, because then the 
ietfs tools can jump between the sections :-) Now they just recognize 
the first section reference.

> Note: Protocol designer should try to re-use existing functionality,
> namely AVP values, AVPs, commands, and Diameter applications.  Reuse
> simplifies standardization and implementation.  To avoid potential
> interoperability issues it is important to ensure that the semantics
> of the re-used features are well understood.
>   
I would add: "Given that Diameter can also carry RADIUS attributes as 
Diameter AVPs,
such re-use considerations apply also to existing RADIUS attributes that 
may be useful
in a Diameter application."

> Every Diameter application specification MUST have an IANA assigned
> Application Id (see Section 2.4 <http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-15#section-2.4> and Section 11.3 <http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-15#section-11.3>).  The managed
> Application ID space is flat and there is no relationship between
> different Diameter applications with respect to their application
> IDs. 
Inconsistent capitalization of Id. The document mostly uses Application 
Id, but above we can see two instances of Application IDs. I grepped for 
additional instances and there weren't any, but my tool was unable to 
search across line endings.

> every Diameter application is a standalone
>    application that may or may not have a semantical relationship with
>    one or more Diameter applications being defined elsewhere.
>   
I commented this in the other e-mail already. But this would be better 
rewritten as:

... every Diameter application is a standalone application. If the 
application has a relationship with other Diameter applications, such a 
relationship is not known to Diameter.

> AVPs may be added arbitrarily to Diameter messages,
> so long as the requirements of a message's ABNF are met.
This is the first use of "ABNF", and the acronym is not explained or the 
concept explained.

>    Before describing the rules for creating new Diameter applications it
>    is important to discuss the semantics of the AVPs occurrences as
>    stated in the ABNF and the M-bit flag for an AVP.
This is the first use of "M-bit" and the concept is not given with 
either an explanation or a forward reference.

Suggested edit: ... the M-bit flag (Section 4.1) for ...

> Broker
>
> A broker is a business term commonly used in AAA infrastructures.
> A broker is either a relay, proxy or redirect agent, and may be
> operated by roaming consortiums.  Depending on the business model,
> a broker may either choose to deploy relay agents or proxy agents.
>   

Unused term, delete?

>    Diameter Node
>
>       A Diameter node is a host process that implements the Diameter
>       protocol, and acts either as a Client, Agent or Server.
>
>
>     Diameter Peer
>
>       A Diameter Peer is a Diameter Node to which a given Diameter Node
>       has a direct transport connection.
>
>   
What happened with indentation here?

Other similar occurrences in the same section.

>     Roaming Relationships
>
>       Roaming relationships include relationships between companies and
>       ISPs, relationships among peer ISPs within a roaming consortium,
>       and relationships between an ISP and a roaming consortium.
Unused term, delete?

(Section 9.1 has this text that is close to using this term, but not 
quite, and I think it is self-explanatory anyway: "The authorization 
server (chain) directs the selection of proper transfer strategy, based 
on its knowledge of the user and relationships of roaming partnerships.")

Jari

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 21 Jan 2009 08:52:03 -0500

Thanks for the review.

Btw, I would like to get your opinion on incrementing the version number 
in the diameter header. There are changes in bis that would not be 
compatible with 3588 and I think it maybe necessary to rev up the 
version num.

> or are you unsure about this? :-)

maybe we can re-word to: "The Diameter base protocol provides and 
Auth..." and "Diameter also works in both ..."

>>    TACACS [RFC1492 <http://tools.ietf.org/html/rfc1492>] and RADIUS 
>> [RFC2865 <http://tools.ietf.org/html/rfc2865>] were initially 
>> deployed to
> Maybe ... Over time, AAA was needed on many new access technologies, 
> the scale and complexity of AAA networks grew, and AAA was also used 
> on new applications (such as voice over IP). This lead to new demands 
> on AAA protocols.

Ok.

> What phase 1 and 2? IKEv2 no longer has them...

I guess we can simplify the paragraph to:

      While [RFC3162] defines the use of IPsec with RADIUS, support for
      IPsec is not required.  In order to provide universal support for
      transmission-level security, and enable both intra- and inter-
      domain AAA deployments, Diameter provides support for TLS.
      Security is discussed in Section 13.

> o  Ability to exchange messages and deliver AVPs (attribute value pairs)

Ok

> Maybe "Routing, relaying, ..." (because the basic routing 
> functionality too relies on AVPs).

Ok

> Diameter was network ..."

Ok.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 21 Jan 2009 10:20:05 -0500

Ok

> Obsolete reference, use 5226.

I'll updated all occurrences of 2434.

> What does "attributes other than those specified in this section" 
> refer to? AVPs from this spec but not listed here? All AVPs not listed 
> here? 

I think it meant the former. AVPs within this spec but not listed in 
this section. We can re-word to clarify.

> work for their values, e.g., addresses in Host-IP-Address AVP.

I guess it was refereing to AVPs with enumerated values or int values 
that are typically constants and have contextual meaning unlike 
Host-IP-Address. But since all of the AVPs with of this type of values 
are already listed in this section, mabye the FCFS text in the beginning 
of the section is not needed ?

> Finally, presumably {Auth,Acct}-Application-Id AVPs do not fall under 

Yes. They should fall under 11.3.

>   attributes in the Diameter base protocol and their

I agree. Pls dis-regard my comment above.

>   spaces is done in accordance with the rules already defined

Looks good.

Ok.

> the first section reference.

I see.

> such re-use considerations apply also to existing RADIUS attributes 
> that may be useful

Ok

>> Application Id (see Section 2.4 
>> <http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-15#section-2.4> 
>> and Section 11.3 
>> <http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-15#section-11.3>).  
>> The managed
> Inconsistent capitalization of Id. The document mostly uses 
> Application Id, but above we can see two instances of Application IDs. 
> I grepped for additional instances and there weren't any, but my tool 
> was unable to search across line endings.

I've searched the docs (manually .. to cover possible phrases broken by 
line endings) .. seems like it only occurs here.

> application has a relationship with other Diameter applications, such 
> a relationship is not known to Diameter.

Ok

> This is the first use of "ABNF", and the acronym is not explained or 
> the concept explained.

Changed to: "message's ABNF (Section 3.2) are met."

Ok.

>> a broker may either choose to deploy relay agents or proxy agents.

I agree.

> Other similar occurrences in the same section.

Fixed it.

> server (chain) directs the selection of proper transfer strategy, 
> based on its knowledge of the user and relationships of roaming 
> partnerships.")

I agree.

regards,
victor