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

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 10 Sep 2004 15:28:07 -0700

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: Miguel Garcia <[email-masked]>
Date: Fri, 17 Sep 2004 12:50:45 +0300

Hi Roy:

Thanks a lot for the comments. I have been waiting to see other 
responses from the AAA community, but unfortunately people seem to be 
busy with other stuff.

Now, inline answers.

Roy T. Fielding wrote:

> nature and benefits from using the common syntax forms.  

Agree with that. We meant the hierarchy of the URI, typically associated 
with a file system. In AAA resources, we are interested in find out AAA 
nodes, rather than a some other resource in a node (like a particular 
file in a file system).

> Furthermore,
> syntax to an existing scheme would significantly impact interoperability.

It is not. RFC 3588 is quite new. I am not aware of any deployments of 
RFC 3588. So an update by this draft will not suffer compatibility 
problems.

>    those URI schemes in the official IANA registry of URI schemes.

That can be easily solved by indicating that "aaa" and "aaas" resources 
identify AAA nodes running some AAA protocol (e.g., diameter, RADIUS, etc.)

> listener at that address).  

Correct.

> Why, then, is there a desire for a grab-bag

Good question, for which I don't have an answer. Unfortunately I didn't 
participate in the definition of the AAA URI. The only thing I can tell 
you is that today there are other URI schemes that does not define the 
service (e.g., im:, pres: URIs are protocol agnostic).

>    t-udp  = "tacacs.udp"       "://" authority    ; TACACS+/udp

I don't mind keeping the "diameter:", "radius:" and "tacacs:" URIs. they 
can be interesting to define them. But I don't think the idea of linking 
the transport protocol to the URI scheme is a good argument. As far as I 
know, the IESG has already shut down this kind of initiatives in the 
past. Additionally, other URI schemes like the SIP URI (RFC 3261) went 
already through this process, and end up defining "sip" and "sips", the 
former allowing TCP, UDP and SCTP as transport protocols, the latter 
indicating TLS over TCP.

Further more, I don't think radius and tacacs use URIs (as for today), 
so perhaps we might need only the "diameter:" and "diameters:" URIs.

The other point that you raised here is related to the double slash. 
Note that I don't even think the double slash is needed to identify the 
kind of resources we are identifying, at least this is what I understand 
when I read section 2.1.2 of RFC 2718:

    2.1.2 Improper use of "//" following "<scheme>:"

    Contrary to some examples set in past years, the use of double
    slashes as the first component of the <scheme-specific-part> of a URL
    is not simply an artistic indicator that what follows is a URL:
    Double slashes are used ONLY when the syntax of the URL's <scheme-
    specific-part> contains a hierarchical structure as described in RFC
    2396.  In URLs from such schemes, the use of double slashes indicates
    that what follows is the top hierarchical element for a naming
    authority.  (See section 3 of RFC 2396 for more details.)  URL
    schemes which do not contain a conformant hierarchical structure in
    their <scheme-specific-part> should not use double slashes following
    the "<scheme>:" string.

> defines HTTP over TCP, not HTTP over any transport).

On the contrary I would argue that existing URI schemes today share the 
scheme with different transport protocols. For instance the sip URI (RFC 
3261) allows TCP, UDP and SCTP transports, whereas the sips URI means 
TLS over TCP. I believe this is the model supported by the IESG 
(otherwise, I don't understand how all the RFCs that follow the SIP 
model have been approved).

> can be used by other information systems beyond AAA.

Note the case, even in a foreseeable future.

> central point of URI design).

The design of those handlers has not been a problem for protocols like 
SIP. So I don't quite agree with your argument that there seems to be an 
implementation problem. It seems that such problem has been solved, and 
it seems there are no requirements in this respect.

> Chief Scientist, Day Software              <http://www.day.com/>

Regards,

      Miguel

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