Re: [Bluez-devel] RFCOMM service level security testing

[Marcel Holtmann <marcel@holtmann.org>]

Hi Steve,

> > thanks for testing and what do you think, should I put this feature into
> > the next stable kernel?
> 
> Yes: definitely!

does anyone tested this on a SMP system, a 64 bit box or big endian
machine?

> > Another question is what should we do when the encryption on a link with
> > RFCOMM_ENCRYPT is switched off? At the moment L2CAP keeps works, but in
> > the RFCOMM layer I drop the connection by sending DM.
> 
> Yeah I thought I saw something like this happen. I don't think it is 
> correct behaviour. My reasoning would go something like this:
> 
> * If encryption on a link is switched off at the HCI level, _all_ of the
> connections (L2CAP and RFComm) which required it should be closed
> shouldn't they? 
> 
> * Conversely, encryption should be automatically turned off on a link
> when the last connection which required encryption is closed.
> 
> * Owners of a connection should be able to indicate that they're no
> longer interested in encryption by an ioctl on the L2CAP or RFComm
> socket.
> 
> * Connections which were created without the encryption requirement
> should be able to ask for it by a similar ioctl.
> 
> I imagine this behaviour would be required only very rarely but it seems
> the most intuitive to me. What do you think?

Actually I have no real meaning about it a the moment. There are pros
and cons and I like to follow some written specification or erratum. Is
there something that tells us exactly what to do in these cases?

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel