Subject: [SIP] RE: draft-hamer-sip-session-auth-00.txt

From: "Louis-Nicolas Hamer" <[email-masked]>
Date: Wed, 6 Dec 2000 10:37:14 -0500

Henry,

Thanks for your comments. Please see my response after [LNH].

Cheers,
Louis-Nicolas Hamer

>
>
>-----Original Message-----
>From: Henry Sinnreich [mailto:[email-masked]]
>Sent: December 1, 2000 5:13 PM
>Subject: RE: draft-hamer-sip-session-auth-00.txt
>
>
>There may not be enough time in the SIP WG, but SIP and session
>authorization is now the subject of several draft and needs to be
>discussed at least on the list.
>
>For the IETF, Internet-wide compatibility is of higher priority,
>since private IP networks and ISP networks have some latitude to
>customize their internal network design, such a illustrated in the
>draft:
>http://ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-00.txt
>
>This leads to top priority for the notions of:
>
>1 - Interdomain, no matter how the domains are designed internally,
>2 - Clearinghouses as trust brokers between domains.
>    Clearinghouses are widely used at present for VoIP.
>
>Getting now to the intradomain aspects, I would like to discuss the
>model in <draft-hamer-sip-session-auth-00.txt> Discussing the
>references, on page 9:
>>there are a number of issues with this model:
>
>> The same policy server makes decisions related to both service
>> authorization and resource utilisation. This is only possible if
>> the service provider and access provider are one and the same
>> business entity and if the network is simple enough to warrant
>> deployment of a single policy server.
>
>The service provider and access provider DO NOT NEED to be the same,
>since policy can be outsourced between business partners. See
>http://ietf.org/internet-drafts/draft-gross-sipaq-00.txt and
>http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt
>
[LNH] Fair enough. We will reference this scenario by inserting the phrase
"[This is only possible if] ... or if the service provider and access
provider outsource policy decisions to a common, trusted third party [ref]."

>
>A second theme of the draft-hamer-sip-session-auth-00.txt is also:
>
>> The end host is connected to a known point in the network that
>> defines the edge router and policy server for that host. This is
>> only possible in a network with fixed hosts and fixed routers
>> where the administrative burden of defining these associations
>> make this a feasible undertaking.
>
>This is also arguable, since:
>
>1 - SIP clients have to authenticate themselves to the SIP proxies
>    that control service inside the domain, so they are known,
>2 - SIP proxies, policy servers and edge routers are the crown
>    jewels of the ISP, similar to the IN in telephony and well
>    known and monitored network elements. Their security
>    associations are not only administered by hand,
>    but also with great care.
>
[LNH] The issue we were highlighting here is, in particular, the mobile
(wireless) environment although we believe similar problems may arise in
fixed networks with complex topologies. Although security associations may
be tightly controlled as you indicated, there is still the issue of
determining which entities are involved at the time the session is being
set-up.

Let's take a relatively simple scenario. The mobile client discovers (or is
assigned to) a SIP proxy at time t=0. The mobile then roams through the
network and initiates a session at time t=T. The edge router serving the
mobile at time t=T may be different from the edge router serving the mobile
at time t=0. Therefore, although the SIP signalling packets may still find
their way back to the assigned proxy, the proxy has no way of knowing which
edge router is currently serving the mobile.

In the associated model, we assume that the security associations between
network elements do, in fact, exist a priori but that some mechanism is
required to allow the elements involved in the session to discover each
other.

>
>Also, why modifications to three protocols?
>>-  Resource reservation protocol
>>-  Policy management protocol
>    (Which: COPS or DIAMETER?)
>>-  Session management protocol
>    (I suppose SDP is meant by this?)
>
[LNH] The ticket is being reflected through the client. The media
authorisation is granted by the proxy and signalled to the client via the
session management protocol (SIP/SDP). This authorisation is presented by
the client to the edge router when it reserves resources (e.g. via RSVP) in
order to acquire the QoS required for the media stream. The ticket is passed
by the edge router to its policy decision point (e.g. via COPS) to be used
by the PDP for admission control.

We believe that the framework we describe for media authorisation is generic
enough to be applied to various session/call management protocols (e.g. SIP,
H.323) in conjunction with various resource reservation protocols (e.g.
RSVP, YESSIR) and policy management protocols (e.g. COPS, ?DIAMETER?).

Our intent is to define extensions for SIP/SDP, RSVP and COPS-RSVP to
support the ticket concept; we invite other interested parties to define
extensions for any other protocols of interest to them.

>
>The references above and the preceding work contains a large number
>of scenarios and call flows, showing that existing protocols do the
>job without any modifications. As for SIP, please see:
>http://ietf.org/internet-drafts/draft-johnston-sip-osp-token-01.txt
>
[LNH] We believe we have already described scenarios in our draft that
cannot be realised by the token as currently defined. Arguably, the intent
of the token and the intent of the ticket are somewhat different -- your
token solves an inter-domain accounting issue and our ticket solves an
intra- and inter-domain resource authorisation issue. There may be
opportunities to combine the token and ticket into a single entity; we
welcome having those discussions with you.

>
>Finally some nits regarding terminology:
>
>I don't know what BEARER is in the IETF context. The ITU BEARER is
>very different from IETF TRANSPORT and NETWORK and imply very
>different design philosophies. Mixing these terms can lead to utter
>confusion.
>
[LNH] TRANSPORT and NETWORK also have connotations associated with them. We
are attempting to distinguish between packet flows used to carry session
control messages and packet flows used to carry the media streams
themselves. If you don't like CONTROL and BEARER, we'd be happy to adopt any
other terminology you might suggest to convey the same distinctions.

>
>SESSION MANAGER: SIP does only session setup, as its name implies.
>The IETF Multimedia Conferencing Architecture <draft-ietf-mmusic-
>confarch-03> and other MMUSIC work makes it clear that they don't
>believe in managing sessions. (There is always an exception that
>confirms the rule: SIP 3rd party call control)
>
>>Session management protocol? See the above.
>
[LNH] As we indicated above, we have defined a framework for media
authorisation that is generic. While SESSION MANAGER may not be part of the
SIP lexicon, it has (in our experience) been used in other environments.
Again, if you find the terminology confusing or offensive, we'd be happy to
adopt any other terminology you might suggest while retaining the generic
nature of the framework.

>
>>Bearer Control Domain.
>Suggest we avoid loose definitions of domains. A domain is a domain
>is a domain in the DNS sense.
>
[LNH] The term was not used loosely since the non-associated model is aimed
at co-ordinating actions across domain boundaries.

However, if you find the terminology confusing in the other models, we'd be
happy to adopt any other terminology you might suggest while retaining the
framework goal of defining a solution for the non-associated model.

>
>Voila! Plenty of items to discuss. If there is no time in the SIP WG
>we may have to try and meet at the bar.
>
[LNH] Thank you for the comments. I look forward to a night at the bar with
you :-)

_________________________________________________
Louis-Nicolas Hamer       Phone: (613) 768-3409   
Wireless IP Architect     Fax:   (613) 763-2686
Wireless Technology Labs  ESN:   398-3409
Nortel Networks                                     

[email-masked]
_________________________________________________