Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-aaa-req-00.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 04 Nov 2002 14:01:09 +0200

Hi Juha,

inline:

Juha Heinanen wrote:
> 
> a few comments:
> 
> i didn't understand this:
> 
>         CANCEL is a hop-by-hop request that can be generated by
>         proxies. SIP servers receiving a CANCEL do not challenge
>         it, as they would do with an end-to-end request. Instead,
>         they check that the entity sending the CANCEL is the same
>         as the one that generated the request being canceled.
> 
> how can a proxy verify without authentication which ua sent a cancel and
> thus if that ua also sent the request being canceled?

The requirement you are referring to needs to be separated into two
different requirements; an authentication requirement and an
authorization requirement. Good catch!

I have keep them separate in the new version of the draft (01). Now they
look as follows:

2.2.1 Authentication Based on SIP Requests

   The home AAA server MUST be able to authenticate a user based on any
   SIP request, except CANCEL.

        CANCEL is a hop-by-hop request that can be generated by
        proxies that do not have the user's credentials.

2.3.1 Ability to Authorize SIP Requests

   The SIP-AAA interface MUST allow AAA servers to authorize any SIP
   request, except CANCEL.

        CANCEL is a hop-by-hop request that can be generated by
        proxies. SIP servers receiving a CANCEL do not challenge
        it, as they would do with an end-to-end request. Instead,
        they check that the entity sending the CANCEL is the same
        as the one that generated the request being canceled.

>    The scheme supported for the authentication between the SIP servers
>    and the AAA infrastructure MUST be flexible enough to accommodate a
>    variety of authentication mechanisms.
> 
> i think that there should be a requirement that the aaa scheme MUST
> support authentication of requests where digest authentication is used
> between the ua and the proxy and any other authentication mechanism that
> is mandated by the current sip specs.  that is, it would not make sense
> to select an authentication scheme that would require some new
> authentication mechanism between the ua and the proxy.

I have stressed that authentication mechanisms mandated by SIP MUST be
supported:

2.2.2 Flexible Authentication of SIP requests

   The scheme supported for the authentication between the SIP servers
   and the AAA infrastructure MUST be flexible enough to accommodate a
   variety of authentication mechanisms. In particular, the SIP-AAA
   interface MUST be able to accommodate all the authentication
   mechanisms mandated by the SIP specs.

> regarding accounting, it looks like the weakest part of the document.
> what should be accountable: dialogs, their duration, volume of data
> send, sip protocol messages themselves, requests outside dialogs, etc?
> real-time push or pull or accounting data between the aaa server and the
> sip server, threshold setting requirements, etc?

I did not want to list requirements that imply that the SIP server has
access to media information (like volume of data sent). I have only
assumed that the SIP server has access to the duration of the session
(time elapsed between INVITe and BYE).

However, if you disagree of think that further accounting requirements
are needed, I will be gald to have some discussions on them and add them
to the draft.

Thanks for your feedback,

Best regards,

Gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP