Comments on (08-198r0) iADT Service Discovery using UPnP

Paul Suhler Paul.Suhler at Quantum.Com
Mon Apr 28 14:54:18 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Paul Suhler" <Paul.Suhler at Quantum.Com>
*
I'd originally replied only to the ADI folks, but since there's interest
I'll post it here.
That particular restriction isn't essential to the proposal in question.
I can certainly imagine various reasons for letting a host outside the
library contact the drive via its network port.
Further comments:
1)  A UPnP-based exploit has been demonstrated against switches and/or
routers.  I would recommend that they not accept connections on the UPnP
port, 1900.  Or at least not accept them from outside the library.
2)  If anyone can suggest why it would be a bad idea for us to use a
vendor-specific UPnP device type, service type, etc., then please let me
know.  The intent of this proposal is *not* to have to join the UPnP
forum and standardized this usage there.
3)  Security of iADT connections could be enforced by not allowing any
packets with the iADT port number (4169) to enter or leave the library.
We do not want to require the use of authentication for iADT.
Comments are welcome.
Thanks,
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com
___________________________________
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individual(s) or organization(s), without restriction.
-----Original Message-----
* From the T10 Reflector (t10 at t10.org), posted by:
* Tim Jones <tjmac at tolisgroup.com>
*
On Apr 28, 2008, at 12:31 PM, Kevin D Butt wrote:
> While it is true that some installations will be configured this way, 
> it is also true that some installations will require that the DTDs' 
> ethernet port is accessible by the external network.	We cannot limit 
> what vendors are going to do here.
I agree with Kevin as both an ISV and a service provider that such an
implementation would hamper remote monitoring of such systems by service
organizations.
Tim
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.
------------------------------------------------------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list