Re: Network Access Control

[P.Pillai@Bradford.ac.uk]

Hi Marie-Jose

I have worked with SIP before, and it can provide some very interesting features
that may be used here. I am not sure of your approach here though...are you
looking into using SIP from user terminal to DVB gateway/Hub (acting as a SIP
server or maybe a SIP proxy) for setting up MPEG2 sessions? In this case SIP 200
OK message after authorisation should initiate the rekeying mechanisms. What
about setting up multicast sessions - IGMP with SIP?

Access control could be used along with this when SIP Invites are sent. We would
still need a backend DIAMETER server and interaction between the SIP and
DIAMETER servers. There is I-D for diameter application for SIP
(draft-ietf-aaa-diameter-sip-app-10) that may be useful.

Are you working on an ID for this SIP approach? I would like to contribute
something on the access control issues.

Regards
Prashant

Quoting Marie-Jose Montpetit <marie@mjmontpetit.com>:

> P.Pillai@Bradford.ac.uk wrote:
> > Hi Gorry,
> >
> > As mentioned in some of the emails before, I think we should look into the
> > network access control methods for the IP services over DVB systems. Though
> > RCST authentication and key exchange mechanisms have been defined by DVB,
> but
> > authentication of the users behind the RCST may also be important. This may
> be
> > especially required by the service provider depending on their business
> models.
> > Do you think it is worthwhile to look into this issue?
> >
> > RADIUS (running over UDP/IP/ULE/MPEG2-TS) is a light protocol that could be
> used
> > for authentication of user terminals. The RCST would have to be a RADIUS
> Client
> > forwarding the authentication requests to the DVB gateways in the NCC. The
> DVB
> > gateways act as RADIIUS proxies which further forward the requests to an
> AAA
> > server. The AAA server would have user profiles. DIAMETER (over
> > TCP/IP/ULE/MPEG2-TS) could also be used. DIAMETER though a more complex
> > protocol with larger overheads as compared to RADIUS, one of its main
> advantage
> > is its support for mobility.
> >
> > Interaction of these with the RCS security could be an issue say when
> different
> > users connected to the same RCST (maybe in a cyber cafe) join different
> > multicast groups at different times and the new keys have to be sent to the
> > RCST.
> >
> > The draft-cruickshank-ipdvb-sec-00.txt, draft gives a nice starting point
> for
> > the security services to be provided. But this draft seems to be very
> specific
> > for securing the ULE packets. Maybe a new ID could address the network
> access
> > control issue, what do you think?
> >
> > Regards
> > Prashant
> >
> >
> >
> Took me a while to respond to this. We have been looking at
> configuration for a while using SIP based mechanisms like other groups
> have done. I would link NAC to this. What do you think?
>
> /mjm
>


-- 
Prashant Pillai
Research Assistant
School of Engineering, Design and Technology
University of Bradford
Bradford, BD7 1DP
West Yorkshire
United Kingdom
Phone: 0044-1274-233720
email: p.pillai@bradford.ac.uk
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to misuse@bradford.ac.uk
------------------------------------------------------------