Subject: Re: [Sipping] New version of the SIP-AAA reqs draft

From: Stuart Jacobs <[email-masked]>
Date: Fri, 21 Feb 2003 11:22:08 -0500

Allison,

This material is part of ongoing efforts of Verizon and Verizon management 
to engage in thoughtful considerations of the fundamental changes and 
challenges facing the telecommunications industry. To meet its fiduciary 
responsibilities, management must explore all alternatives, even those that 
may appear highly speculative and hypothetical. Statements and 
representations contained herein are preliminary and/or tentative and 
should not be relied on unless approved by the appropriate Verizon 
governing body.  The following represent the anticipated approach Verizon 
most likely will use.  I cannot be more firm at this time as our 
architectural plans are not finalized.

Verizon's current direction for our Next Generation Network (NGN) VoIP 
Services will likely use a challenge/response approach (ala. Radius) for 
authentication and access control between our SIP service customers and SIP 
Proxies.  All our SIP service customers will probably go through SIP 
Proxies.  We will not support SIP UA to SIP UA within our operational 
domain.  Our SIP Proxies will likely authenticate themselves to other SIP 
Proxies and other back-office systems (OSSs, Application Servers, EMSs, 
etc.) by use of IPsec, specifically IKE combined with X.509v3 server 
certificates and ESP transport mode Null-encryption using 
HMAC-SHA1-96.  Access controls (rights/policies) between our intermediate 
systems (incl. SIP Proxies, Gateways , etc.) are expected to be based on 
use of policy certificates.  All policy and identity certificates are 
expected to be distributed via a redundant hierarchy of LDAP servers 
(repositories).  Accounting data will most likely be compiled by our SIP 
Proxies and transferred to billing systems with authentication provided by 
IPsec.  The actual billing data will probably be captured in the form of 
XML in conjunction with XML signatures (as defined by the W3C).

Stu

At 2/20/03 05:24 PM, you wrote:
>Stu,
>
>You are not doing the usage accounting with Radius, then.
>
>It is only doing the remote access authentication?
>
>We can work with this scenario.  Could you speak to this in
>the open mailing list?  I would like to rule out Radius for
>call detail and usage-based accounting, but it is ok for the
>other A's.
>
>Allison
>
> > Diameter in our Next Generation Network (NGN) VoIP Services.  We will be
> > doing our usage accounting within SIP Proxies and intend to transfer said
> > accounting "call detail records" back to our billing OSSes via other
> > protocols with IPsec providing authentication and confidentiality for 
> these
> > transfers.  We currently do not plan on any deployment of Diameter within
> > Verizon's wireline NGN architecture.  We will probably continue to use
> > Radius for remote access authentication at the application layer for a
> > number or years into the future.
> >
> > Stu Jacobs
> >
> > At 2/14/03 09:58 PM, you wrote:
> >
> > >Jiri,
> > >
> > >It always seems good to be able to stay with installed base, but
> > >there's a factor against our supporting RADIUS drafts for SIP's
> > >accounting - safety.  Even though there is deployment, there are
> > >some extremely bad cases of damage in production, and the IETF
> > >has concluded that RADIUS is not suitable for usage-based accounting
> > >(RFC2975).
> > >
> > >Unless there is no intention of having in SIP accounting usage-based,
> > >monetary, auditable applications, RADIUS is not the solution.  The
> > >protocol just does not preserve a complete stream of reliable
> > >accounting records that are auditable on any level, especially with
> > >any roaming.  As Bernard Aboba stated to this WG, quoting Mike O'Dell,
> > >the use of RADIUS may even be illegal in situations where there is an
> > >authority over the billing.  Records are too easily lost by the
> > >protocol. This is stated clearly by RFC2975.  This is the reason why
> > >the Operations and Mgt Area developed Diameter.  On these technical*
> > >grounds, that the RADIUS protocol does not have enough reliability,
> > >the work must be based on the Diameter protocol, which is now
> > >approved.  Alternatively, work could be done that does not include
> > >usage-based accounting, but this does not seem to be what is
> > >envisioned in the SIPPING AAA requirements.
> > >
> > >Allison
> > >
> > >P.S. There's a current investigation of RADIUS compatibility mode
> > >in Diameter for this - more needs to be thought about it.
> > > >
> > > > At 07:46 PM 2/11/2003, [email-masked] wrote:
> > > > >Hi Henry,
> > > > >
> > > > >> >but one option is develop a solution using
> > > > >> > Diameter in RADIUS-compatibility mode.
> > > > >>
> > > > >> OK, this is better than nothing. We'll take what we can :-)
> > > > >>
> > > > >> As mentioned, the installed base is RADIUS, no matter how
> > > > >> voluminous the DIAMETER literature may be.
> > > > >
> > > > >I think the issues is that the IETF should recommend what is the
> > > > >right thing to do & why.  If people choose to do something else,
> > > > >well, that is life.
> > > >
> > > > Remember that running code does not necessarily mean something known
> > > > to compile -- that is something known to be deployed.
> > > >
> > > > >I understand what you are asking but I do note that some
> > > > >people have thought that the potential for AAA is much greater
> > > > >than the existing installed base.
> > > >
> > > > I actually think that the deployment argument is a very important one.
> > > >
> > > > -Jiri
> > > >
> > > > _______________________________________________
> > > > 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
> > >_______________________________________________
> > >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
> >
> > ==========================
> > Stuart Jacobs CISSP
> > PMTS - Sr. Technologist
> > Verizon Laboratories
> > 40 Sylvan Road Waltham, MA 02451-1128     USA
> > telephone: (781) 466-3076   fax: (781) 466-2838
> > [email-masked] [email-masked]  [email-masked]
> > ==========================
> >

==========================
Stuart Jacobs CISSP
PMTS - Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128    USA
telephone: (781) 466-3076  fax: (781) 466-2838
[email-masked] [email-masked] [email-masked]
==========================

_______________________________________________
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

---

From: [email-masked]
Date: Tue, 25 Feb 2003 16:16:11 +0200

nobody replied to my bye question, but after some more thinking i have
myself come to the conclusion that it is impossible for a regular sip
proxy without a dialog state or a crypto identification of all requests
from its clients to do any accounting at all.

so it would be important for a sip-aaa requirements draft to list the
preconditions for sip accounting.

-- juha

---

From: "Jim Fleming" <[email-masked]>
Date: Tue, 25 Feb 2003 09:27:32 -0600

From: "Stuart Jacobs" <[email-masked]>
"...management must explore all alternatives..."
====

Do you mean "explore all alternatives" provided by the I* society...(small s...aka The Big Lie Society)...
...after ethnic cleansing has been done by the I* society thugs...?

----- Original Message ----- 
From: "Stuart Jacobs" <[email-masked]>
To: "Allison Mankin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, February 21, 2003 10:22 AM
Subject: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft

> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for new developments on the application of sip

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 26 Feb 2003 12:54:38 +0100

Sorry for latency -- yes, I think that is a very important issue,
and mentioning it in the draft would be very good. (Has anyone else 
made the observation too that operationally-related questions are 
rarely replied here?)

I agree too it takes awareness of dialog state. It doesn't imply though,
a proxy needs to be stateful -- record-routing can help, most likely
along with some message integrity check if the dialog information
is sensitive (which is most likely the case with AAA).

-jiri

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 27 Feb 2003 10:28:20 +0200

Juha,

[removing SIP (but keeping SIPPING) from the cc: ]

Do you mean that you would like to see a note along these lines added to
the draft?

"Note that, in order to perform accounting, a SIP proxy server should
see and authenticate every message sent over the dialog."

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~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

---

From: [email-masked]
Date: Thu, 27 Feb 2003 13:58:19 +0200

> see and authenticate every message sent over the dialog."

unfortunately in most common cases the sip proxy cannot authenticate
every message.  in order to be able to account a request, the proxy
should be able to either authenticate it (if it was send by its own
user) or know that i came from a trusted another proxy that has already
authenticated the request.

in order to know that the requstest was sent by its own user, the proxy
should either be dialog aware or have somekind of security association
with its user.  neither of these is possible with products that are in
common use today.

-- juha

---

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Feb 2003 16:18:18 +0200

There are different reasons for collecting accounting data. Only
one of these reasons is billing based on it. Even if you bill
based on usage, it probably depends on the particular business
models what "usage" is. It could be a one-time fee per call,
not tracking of session lengths. I agree that billing based
on what proxies know about bandwidths, codecs, session lengths
is troublesome (at least in the general case, maybe possible
in some specific networks).

But one key question is whether SIP AAA is only for proxies or
for all types of SIP nodes. I think it should not be just
for proxies. SIP user agents of course would also know
session lengths and other parameters. (Not for regular user
terminals of course but for some services offered by the
network.)

Jari