Subject: RE: [AAA-WG]: Re: AAA URI draft

From: <[email-masked]>
Date: Thu, 21 Oct 2004 15:45:49 +0300

Roy,

At a high-level, the AAA URI scheme was introduce in RFC3588 to be able
to support NAPTR records for Diameter peer discovery - section 5.2.  
Advice was given to follow what SIP does, and so the AAA URI scheme
was based upon SIP.

I am not sure right now if a hierarchical model is warranted.

I'm curious to see if the WG has any opinion if there needs to be 
an expansion in the use of the Diameter URI for other purposes.

thanks,
John
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Roy T. Fielding
> Sent: 11 September, 2004 01:28
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AAA-WG]: Re: AAA URI draft
> 
> 
> Here are my comments regarding the AAA URI draft
> 
>    http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt
> 
> update to RFC 3588.  Sorry for the late review.
> 
> The basic premise of this update, namely
> 
>     RFC 3588 [RFC3588] describes the Diameter base protocol for
>     authentication, authorization and accounting purposes.  The RFC
>     provides for the existence of a DiameterURI AVP that contains a "aaa"
>     or "aaas" URI.  That definition of the "aaa" and "aaas" URI schemes
>     follows the so-called hierarchical model specified in RFC 2396
>     [RFC2396], although aaa/aaas resources do not point to hierarchical
>     resources.
> 
> appears to be incorrect.  For one thing, use of a namespace delegation
> mechanism like DNS within the scheme is inherently hierarchical in
> nature and benefits from using the common syntax forms.  Furthermore,
> if Diameter is actually a deployed protocol, an arbitrary change in
> syntax to an existing scheme would significantly impact 
> interoperability.
> 
> What is more problematic, however, is that the "aaa" and "aaas"
> schemes seem to have been defined without a clear indication of
> what is being identified:
> 
>     RFC 3588 [RFC3588] does not provide semantics for the
>     "aaas" URI nor it provide instructions to IANA to register any of
>     those URI schemes in the official IANA registry of URI schemes.
> 
> Unfortunately, the new draft doesn't really define what kind of
> resources are being identified either.  It only says
> 
>     Both the "aaa" and the "aaas" URI schemes are used to identify
>     resources related to authentication, authorization and accounting
>     (AAA) functions that are accessed with AAA protocols such as RADIUS
>     [RFC2865] or Diameter [RFC3588].
> 
> but as near as I can tell, the only resources ever provided by those
> protocols are the service points (i.e., the fact that there is an AAA
> listener at that address).  Why, then, is there a desire for a grab-bag
> identification scheme like "aaa", which hides the most important bits
> of information at the end of the URI, when the same thing can be
> better accomplished by specific URI schemes for each service?
> 
> In other words, what I would propose is the following:
> 
>     d      = "diameter"         "://" authority    ; Diameter/sctp
>     d-tcp  = "diameter.tcp"     "://" authority    ; Diameter/tcp
>     d-tls  = "diameter.tls"     "://" authority    ; Diameter/tls/sctp
>     dtc    = "diameter.tls.tcp" "://" authority    ; Diameter/tls/tcp
> 
>     r      = "radius"           "://" authority    ; RADIUS/udp
> 
>     t      = "tacacs"           "://" authority    ; TACACS+/sctp
>     t-udp  = "tacacs.udp"       "://" authority    ; TACACS+/udp
> 
> Note that the above removes all of the complexity described in
> section 3 regarding the various combinations of AAA protocol,
> transport, and session-based security that are not allowed.  If you
> simply define the URI schemes such that illegitimate combinations
> aren't even an option, then you don't have to require that
> applications keep track of what combination of parameters
> are allowed.  Likewise, all of the aliases (multiple URIs for the
> same service) are removed by specifying that the short scheme
> defines the most common protocol case (just as the "http" scheme
> defines HTTP over TCP, not HTTP over any transport).
> 
> Furthermore, if we later discover that there are more resources
> hidden within the Diameter, TACACS+, and RADIUS servers beyond
> the mere existence of the service points, then all we need to
> do is add a path to the URI definition and those new services
> can be used by other information systems beyond AAA.
> 
> A FAQ about URI scheme definitions is why doesn't the port component
> in authority come with parameterization, similar to that described
> in the draft for the aaa and aaas schemes?  The reason is because
> applications use URI schemes as a hook by which to select modular
> handlers for the processing of requests. Therefore, placing that
> distinction in the scheme allows handlers for different transports
> to be developed and deployed independently.  In contrast, embedding
> access parameters within a URI forces the application to choose
> either a generic handler that may be incapable of handling the URI,
> or to hard-code inspection of the URI path prior to URI handling
> (effectively breaking the orthogonality principle that is the
> central point of URI design).
> 
> 
> Cheers,
> 
> Roy T. Fielding                            <http://roy.gbiv.com/>
> Chief Scientist, Day Software              <http://www.day.com/>
> 
>

---

From: <[email-masked]>
Date: Thu, 21 Oct 2004 15:48:24 +0300

Rui,

> I like it. It is consistent with the need to manage different sorts of 
> AAA servers during the migration to Diameter and can cater for all the 
> usual O&M issues (like custom port numbers, defaults, etc.) in a 
> non-ambiguous way that will minimize the chances for human error.
> 
> Yes, and applications handling the URI, as you put it quite nicely, can 
> process it in a standard way (with the proper validations, I can 
> envision using the URI as an XPath into a XML configuration file, 
> etc.).

Before expanding the use of the URI, I'd like to get some input on 
how the WG feels about this.  Is this functionality needed?  Also,
it might be useful to get some input from RADIUS folks, etc.

thanks,
John

---

From: <[email-masked]>
Date: Mon, 25 Oct 2004 14:23:30 +0300

Hi,

> - Make the aaa/aaas URI schemes protocol agnostic; remove all the 
> parameters (including protocol and transport).

I think we should keep aaa and aaas schemes including the parameters.

> - Define diameter and diameters URI schemes. Make them protocol 
> specific, obviously. Add a parameter that specifies the transport.

I'm not sure if we need Diameter-specific uri-schemes, but if 
such schemes are defined I'd suggest shorter forms 'dia:' and 'dias:' :)

BR,
Mikko

> ext Miguel Garcia
> Sent: 21 October, 2004 10:03
> To: Rui Carmo
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: Re: AAA URI draft
> 
> 
> Rui:
> 
> I am not the advocate of any proposal, but I will give you my 
> opinion on 
> this.
> 
> 1) The aaa URI scheme is already specified in RFC 3588 (though not 
> registered with IANA). Although I personally don't like URIs that are 
> not protocol specific, this is a common practice today. Think of the 
> mailto, im and pres URI schemes for e-mail, instant messaging and 
> pressence, respectively. All of them are protocol independent.
> 
> 2) As far as I know, it is not feasible to expose the combination of 
> protocol/transport/security in the URI scheme itself, because the 
> combination will be growing with time and makes unfeasible to have a 
> future compatible deployment of Diameter. As far as I know, 
> the IESG has 
> typically allowed to differentiate the security requirements 
> in the URI, 
> but not other aspects such as the transport protocol. For 
> instance, http 
> and https URIs differentiate the security aspects of HTTP. Well, HTTP 
> runs over TCP so it is not a big issue. But take as an 
> example the sip 
> URI scheme. SIP can run over TCP, UDP, and SCTP. There are not such 
> thing as sip.tcp, sip.udp, sip.sctp, sips.tcp, sips.sctp URI schemes. 
> Instead, there are only sip and sips URI schemes.
> 
> Therefore my opinion is that we shouldn't go in a direction where the 
> transport protocol is visible in the URI scheme. I think we 
> should try 
> to keep the aaa and aaas URI schemes.
> 
> 3) Having said that, I agree with Roy that the combinations 
> of different 
> AAA protocols, transport protocols and security protocols looks a bit 
> complicated. I wonder if we could make things easier by defining a 
> diameter and diameters URI schemes. If we go in this 
> direction I think 
> we would have to do the following:
> - Make the aaa/aaas URI schemes protocol agnostic; remove all the 
> parameters (including protocol and transport).
> - Define diameter and diameters URI schemes. Make them protocol 
> specific, obviously. Add a parameter that specifies the transport.
> - Somebody (we could do it if assigned) should do similar thing with 
> radius URI scheme.
> - We should define guidelines or even procedures to translate between 
> aaa/aaas URI schemes and their corresponding diameter/radius 
> URI schemes.
> 
> Comments?
> 
> BR,
> 
>       Miguel
> 
> Rui Carmo wrote:
> > 
> > On Sep 10, 2004, at 11:28 PM, Roy T. Fielding wrote:
> > 
> > envision using the URI as an XPath into a XML configuration 
> file, etc.).
> > 
> > Rui Carmo
> > 
> > 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
>