Subject: [AAA-WG]: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-app-03

From: Miguel Garcia <[email-masked]>
Date: Fri, 06 Aug 2004 16:41:46 +0300

Hi:

My apologies for the crossposting. I read draft-sterman-aaa-sip-03 and I 
have some comments to both the draft itself and the Diameter SIP 
application. The authors of both drafts are copied as well.

First, I think that in general, both drafts are aligned. This is good 
news, since there is not need for a lot of rework. Here are some 
comments though:

1) Abstract: The abstract looks more like an introduction to me, 
providing a motivation for this work. I think the abstract should just 
indicate what this document provides, rather than a historical 
description of the capabilities of RADIUS, SIP and HTTP. I would suggest 
a text around this lines:

"This document specifies an extension to RADIUS that allows a RADIUS 
client in a SIP/HTTP server, upon reception of a SIP/HTTP request, 
retrieve and compute Digest authentication information from a RADIUS 
server. Additionally, a scenario describing  the authentication of a 
user emiting a SIP/HTTP request is provided."

2) Attributes/AVP: I am happy to see that we both drafts are aligned 
with the attributes/AVP names and semantics. But on reading 
draft-sterman I found suggestions for the Diameter SIP app.

In Diameter SIP app we had a conflict with the duplication of 
information. For instance, we use the User-Name AVP as well as 
Digest-Username AVP. We don't have, though, a Digest-Method AVP, since 
we have a SIP-Method AVP that does the same. I think this is wrong, and 
I propose to add a Digest-Method AVP to the Diameter SIP app. The idea 
is: Digest-xxx AVPs are used to compute the Digest authentication, 
wherease SIP-Method or User-Name are used to authorize the user to 
proceed with a particular request.

This adds a duplication of information, but on the other hand, it 
provides a clear split between Digest authentication and authorization 
of a request.

If I found no objections, next version of Diameter SIP app will include 
a new Digest-Method AVP.

3) draft-sterman defines a Digest-Body attribute. But actually, the 
attribute will not contain a body, but the hash of a body. I would 
suggest to rename this attribute to Digest-Entity-Body-Hash. It happens 
that this is the name of the same AVP in Diamter SIP app.

4) I noticed that draft-sterman does not specified a Digest-Nextnonce 
attribute, but we have a Digest-Nextnonce AVP in Diameter SIP app. It 
seems that draft-sterman reuses Digest-Nonce to transport a nextnonce. 
While the mechanism probably works, I would suggest to define a new 
Digest-Nextnonce attribute in draft-sterman, since the semantics of 
Nonce and Nextnonce are completely different, so they are sent in 
different parameters in the Digest header. Is this acceptable?

5) Similar to #4 above, I noticed that draft-sterman defines a 
Digest-Response that presumably is used to map it to both "response" and 
"rspauth" in Digest. As in #4, the semantics of both Digest parameters 
are different, so the attributes should be. In Diameter SIP app. we 
define Digest-Response and Digest-Response-Auth AVPs. I would suggest 
that draft-sterman splits Digest-Response similarly. Is this acceptable?

6) Question of documentation. I noticed that all the attribute 
descriptions in draft-sterman include a figure containing the position 
of Type, Length and String. I wonder if it is needed to repeat the 
figure in all the attribute descriptions or whether you can indicate in 
a general paragraph the commonality shared by all the attributes (among 
others, the structure represented in those figures).

7) Section 2.1 in draft-sterman. The definition of Type says:
     Type
          DIG-RES for Digest-Response.  Early implementations have used
          the experimental type 206.

    I would suggest to remove the last sentence. It is not relevant for 
this document the value an early implementation has used or not. What is 
important is the value assigned by IANA.

8) Section 2.16, Digest-Stale. I notice that draft-sterman and Diameter 
SIP app are not synchronized with the possible values of this attribute.

Draft-sterman indicates that if Digest-Stale is present, its value will 
always be set to "1". This will be mapped to the stale="true" parameter 
in Digest. I understan that if Digest-Stale is not present, then the 
RADIUS client should assume that stale="false" or simple not present in 
Digest

Diameter SIP app. maps strictly the contents of the "stale" parameter in 
Digest, meaning that the contents can be "true" or "false" (we actually 
refer to RFC 2617).

I like more the approach taken by Diameter SIP app. There is no 
assumptions (as if the attribute is not present, it means 
stale="false"). And I found it more future proof, in case someone 
defines an extension with more values of stale (unlikely though, but 
this is not a justification).

My proposal is that draft-sterman aligns with Diameter SIP app and the 
value of the Digest-Stale AVP includes a quoted string that is straight 
forward mapped to the stale parameter in Digest. Is this acceptable?

9) Section 4, migration path to Diameter: Digest-URI

First a typo: s/DIAMETER/Diameter

We should synchronize the name of Digest-URI AVP. Diameter SIP app calls 
it Digest-Digest-URI. The reason is that the first "Digest-" refers to 
the prefix used for all those Digest AVPs. The second "Digest" refers to 
the name of the Digest direction, which is called "digest-uri". It is 
not so important, so I am willing to change the name in Diameter SIP app 
to Digest-URI.

Proposal: I will change the name of Digest-Digest-URI to Digest-URI. 
There is no action to draft-sterman.

10) Section 4:

This section will need an update after the discussion in this e-mail. 
Some other typos I found:

- Remove all the "AVP" instances
- s/SIP-Entity-Body-Hash/Digest-Entity-Body-Hash

You can also see how ugly is to overload an existing attribute when the 
semantics of the request difer from the semantics of the response. See 
the Digest-Response attribute

The "Access-Request Digest-Response" attribute should be mapped to the 
"Digest-Response" in Diameter SIP app.

The "Access-Accept Digest-Response" attribute should be mapped to the 
"Digest-Response-Auth" in Diameter SIP app.

Note that table 2 will become obsolete when we add the proposed changes 
in this e-mail. However the contents of the table should move to table 1 
with the appropriate values.

In general, I found that this section 4 has to be rewritten once we 
agree on the proposals in this e-mail. It would become easier to map 
both documents now.

11) Section 5:

I would expect that this section starts with the following sentence:

"This document serves as IANA registration request for ..."

Particularly, I would remove the dependency on becoming a working group 
(item) or IESG document.

12) Examples in Section 7:

This one was a shock to me. It violates all the rules of writing RFCs. 
For instance, it does not use the IP address space suggested for 
examples, it does not use the example.com domain name.

The SIP examples luck a few mandatory headers (e.g., Max-Forwards), 
contains the name of commertial products, contains undocumented 
extensions to SDP, misses recommendations of populating several SIP 
headers and SDP lines...

If you want to continue in this path, I may suggest that an expert 
reviewer assigned by the transport AD should inspect this examples.

I have a better suggestion: at the end of the day, this draft is about 
Digest and RADIUS. So why don't you focus on Digest and RADIUS in the 
examples? create some sort of abstract SIP/HTTP request, and just write 
down the Digest headers, but not the whole SIP message.

This is all for the time being. Thanks a lot,

         Miguel

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

---

From: MCarmen <[email-masked]>
Date: Sat, 21 Aug 2004 16:20:02 +0200

Hi Miguel,

   Regarding the Diameter SIP Application, I suggest to remove the 
User-Data-Request-Type AVP. We got to the conclusion in 3GPP that it is 
better to download the whole profile instead of splitting it into parts, 
since it may lead to unexpected error cases and inconsistencies between 
the diameter client and the diameter server data.

br,
MCarmen

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 23 Aug 2004 10:44:24 +0300

Mari Carmen:

Thanks for sharing this information.

My analysis of the situation:

3GPP had a requirement, sometime ago, to be able to download the whole 
user profile, or a fraction of it. It seems now that implementors have 
realized that this brings some extra complexity to the implementation 
and very little benefit. It seems that the only saving is a few bytes in 
memory and a few bytes in bandwidth, which is not a big deal since 
bandwidth is not so scarce in the core network.

So, I would propose also that we remove the SIP-User-Data-Request-Type 
from the Diameter SIP app., since the presence there was solely a 3GPP 
requirement.

If anyone has a concern, please raise it now.

I have listed this as an open issue:

http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue18

Regards,

          Miguel