[SIPForum-techwg] Remarkable progress so far....

Sat Sep 10 17:18:22 EDT 2005

Hi Chris,

This is good.

Make sure you define in there SIP ALG versus SIP SBC (to do the fixing
of the IP address). There was an email I think from Rohan explaining
this (it talked about "transparent ALGs" versus "ALGs that also act as a
B2BUA in the sense that they are explicitly addressed", or something
along those lines.

-----Original Message-----
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Chris Sibley
Sent: Friday, September 09, 2005 11:32
To: 'Richard Shockey'; 'Rohan Mahy'
Cc: 'SIP Forum Tech WG'; 'Chris Gatch'
Subject: RE: [SIPForum-techwg] Remarkable progress so far....

Richard,

I also agree that we have made pretty fabulous progress and have almost
reached consensus on most of the major issues. At this point, I am
working on putting together a new high-level reference diagram as
previously discussed by the group. This new diagram will depict the
enterprise and SP as logical entities and will place the emphasis on the
protocols used between the two entities (as opposed to the older diagram
which broke things down to the component level).

I think this diagram will help spur further discussions, as well as
serve as a "checkpoint" of sorts that I am correctly capturing the major
architectural points discussed so far. 

I expect to have the diagram out to the group no later than next Friday
(9/16). Once we can reach consensus on the reference diagram, I should
be able to get the textual portion of the document re-worked for review
by the group pretty quickly afterwards (~ 1 - 2 weeks). 

I have also attempted to provide a short summary of where we are today.
Group members, please feel free to add to / elaborate on / disagree with
these bullet items:

Major Issues Solved

---------------------------------

[[ 1 - Definition of a PBX ]] 

-- Can be either a pure proxy solution or a B2BUA solution. Both are
valid implementations and must be supported by the specification.

[[ 2 - AOR "Ownership" ]] 

-- The PBX may be the authoritative entity for a registered domain (i.e.
acmerockets.com), or it may be "authoritative" for a sub-domain assigned
by the SP (i.e. acmerockets.cbeyond.net)

[[ 3 - NAT Traversal ]] 

-- The Enterprise and the SP are each responsible for "fixing-up" IP
addresses contained in SIP messages before sending to the other.

-- Symmetric NATs should not be used and explicitly discouraged.

-- Any NATs/firewalls in the transmission path must be STUN-friendly.

-- Any SIP ALGs in the transmission path must be disabled.

[[ 4 - Media / Capability Requirements ]] 

-- The specification will include guidelines and/or minimum requirement
levels for such things as echo cancellation, DTMF relay, DSCP markings,
etc.

[[ 5 - Securing signaling traffic between the enterprise and SP ]] 

-- The general group consensus is that TLS will be the mechanism used to
secure signaling between the enterprise and SP.

-- The TLS tunnel may or may not terminate directly on the SP's SIP
application server (CCS).

-- The PBX may optionally choose to authenticate the SP using mutual TLS
authentication. For this draft, this is the only supported method for a
PBX to authenticate a SP.

[[ 6 - Call Flows ]]

-- Call flows should be outside the scope of the document and thus
removed.

Semi-Resolved Issues

-----------------------------

[[ 1 - Conveying / determining Billing Identity on a per-call basis ]]

-- The choice of whether or not to use TLS to secure signaling is at the
discretion of the enterprise. The SP must support it.

-- The service provider may challenge INVITES received from the PBX if
TLS if desired.

-- If challenged on an INVITE, the enterprise PBX must respond with a
SP-supplied username and password valid in the SP's realm.

[[ 2 - Providing current PBX contact information to the SP ]] 

-- If the enterprise is authoritative for their domain (i.e. cisco.com),
they are responsible for updating the associated DNS records whenever
their public IP address changes. This can be done via DYNDNS or manual
updating, but the actual mechanism probably should be outside the scope
of the document.

-- If the SP is authoritative for the customer domain (i.e.
acmerockets.cbeyond.net), the SP is responsible for updating the
associated DNS record upon request by the customer. 

-- The PBX may optionally register zero or more AORs with the SP.

Ideas / RFCs to be Considered for Future Draft Versions

----------------------------------------------------------------------

[[ 1 - draft-ietf-sip-identity ]]

-- As a group, we want to keep a close eye on this draft and make sure
that any specification we release will be ultimately compatible with it.

[[ 2 - SAML ]]

-- As a group, we need to look closer into the application of SAML
towards our problem of identity verification / authentication.

[[ 3 - Carrying billing information within the SP network ]]

-- Standard methods of carrying billing information within the SP
network needs to be defined (i.e. OSP, etc.) This will also help
facilitate SP-to-SP interoperability later.

Thanks,

--Chris

________________________________________

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Richard Shockey

Sent: Thursday, September 08, 2005 9:23 AM

To: Rohan Mahy

Cc: SIP Forum Tech WG; Chris Gatch

Subject: [SIPForum-techwg] Remarkable progress so far....

Rohan Mahy wrote: 

> 

> On Sep 1, 2005, at 15:15, Chris Gatch wrote: 

> 

>> Rohan, 

>> 

>> Clipping from your e-mail a few days ago with call flow examples 

>> regarding identity and naming conventions, you wrote 

>> 

>>> Acme's LA PBX gets a call to DC.  The PBX opens a TLS connection to 

>>> provider.net and provides its client certificate.  Acme sends an 

>>> INVITE that looks like this: 

>>> 

>>> INVITE sip:+12025551222 at provider.net;user=phone SIP/2.0 

>>> From: "Alice Andrews" 

>>> <sip:+13105554233 at lax-pbx.acemwidgets.com;user=phone> 

>>> Identity: # appropriate hash here # 

>>> Identity-Info: 

>>> <https://sec.acmewidgets.com/acme-cert.pem>;alg=rsa-sha1 

>> 

>> 

>> Regarding the use of the Indentity and Identity-Info fields, are you 

>> suggesting that we require support for draft-ietf-sip-identity-05? 

> 

> 

> While I think it is a good idea to encourage use of the Identity 

> mechanism, I don't think it is essential that we use it in the first 

> version of our spec. 

I agree.  The idenity spec is still under discussion and there is no 

current field experience with its use. Consequently adding it in to the 

requirements could seriously affect  the "time to market" issues I'm 

personally worried about. In addition I'm not sure the idenity spec is 

really the last word on the subject I continue to believe there is a 

strong relationship between SAML and SIP that has yet to be fully played

out in the IETF. 

I'm getting the sense of the list  that their is considerable consensus 

on the direction we're going and that we are starting to see resolution 

of some of the major issues. 

Chris what is your time table for a second rev of the document? 

What other issues do you feel need to be resolved?  I have the sense 

that the question of idenity as it relates to billing matters is not 

completely resolved here if certs are not used. 

-- 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

Richard Shockey, Director - Member of Technical Staff 

NeuStar Inc. 

46000 Center Oak Plaza  -   Sterling, VA  20166 

sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com 

ENUM +87810-13313-31331 

PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 

Fax: +1 815.333.1237 

<mailto:richard(at)shockey.us> or 

<mailto:richard.shockey(at)neustar.biz> 

<http://www.neustar.biz> ; <http://www.enum.org> 

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 

_______________________________________________ 

techwg mailing list 

Send mail to: techwg at sipforum.org 

Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20050910/f928b4f9/attachment.html 