RE: Network Access Control

[Marie-Jose Montpetit <marie@mjmontpetit.com>]

Yes it would be to setup sessions, get addresses, verify authorization
etc. I have a now expired draft that did something to start some work
and I would not mind reviving it and adding to it. It was part of the
"address resolution" part of the charter but getting an address implies
a lot of underlying things including access control these days.

/mjm

> -------- Original Message --------
> Subject: Re: Network Access Control
> From: P.Pillai@Bradford.ac.uk
> Date: Thu, January 19, 2006 3:51 am
> To: ipdvb@erg.abdn.ac.uk, Marie-Jose Montpetit <marie@mjmontpetit.com>
> Cc: Gorry Fairhurst <gorry@erg.abdn.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
> ------------------------------------------------------------