[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] "...management must explore all alternatives..." ??
From: "Stuart Jacobs" <stu.jacobs@labs.gte.com>
"...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" <stu.jacobs@labs.gte.com>
To: "Allison Mankin" <mankin@psg.com>
Cc: <sipping@ietf.org>; <sip@ietf.org>
Sent: Friday, February 21, 2003 10:22 AM
Subject: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft
> 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, john.loughney@nokia.com 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 sip-implementors@cs.columbia.edu for questions on current sip
> > > > > Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> > > >Use sip@ietf.org 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
> > > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com
> > > ==========================
> > >
>
> ==========================
> Stuart Jacobs CISSP
> PMTS - Sr. Technologist
> Verizon Laboratories
> 40 Sylvan Road Waltham, MA 02451-1128 USA
> telephone: (781) 466-3076 fax: (781) 466-2838
> stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com
> ==========================
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip