Re: : 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:
> 
>> 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).
> 
> 
> 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.
> 
>> 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.
> 
> 
> 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.).
> 
> Rui Carmo
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland