Hi, Peter, In part, you write:
... > The FCC rule requires the Master to identify the slave by FCC-ID and > query the WSDB to determine if it is allowed to provide access/service > to this device (FCC-ID). ... > How the master gets the information > from the slave or how it maintains or verifies it is not, I believe, > within the PAWS scope. You seem to agree, though, that we must have some representation of the slave's FCC ID on the PAWS interface, and that the database must be able to give an answer (yes/no) about a particular FCC ID. Correct? This seems to imply some sort of relationship between the slave device and the database. If we want a slave device (with a different vendor/ owner/database from the master device) to interoperate with any master device, it would seem that any database would need to be capable of responding yes/no with respect to any particular slave FCC ID. Will there be a global whitelist of all un-revoked FCC IDs? Or am I mistaken, and is FCC ID more akin to a model number than a serial number? -Pete Peter Stanforth wrote: > Under current US rules a "Slave" or low power Personal/Portable client > attempts to associate with a "master" which is a Fixed or > Personal/Portable Mode 2 device. As a precursor to this association > attempt the master has obtained a permitted channel list from a WSDB. > The FCC rule requires the Master to identify the slave by FCC-ID and > query the WSDB to determine if it is allowed to provide access/service > to this device (FCC-ID). The rules don't preclude the master from > remembering this information so it does not have to ask again if it has > cached the response from the WSDB. So from a protocol perspective, which > is what I believe PAWS is about, there needs to be a mechanism to > support this kind of capability. How the master gets the information > from the slave or how it maintains or verifies it is not, I believe, > within the PAWS scope. Under the same US rules a "slave" that is a High > Power Fixed device (Typically found in a wide area point to point or > point to multipoint solution) the slave has to both register with the > WSDB and request a channel list. The rule explicitly allows the slave, > in this case, to use the channel that the master is operating on to > query the WSDB. If the returned channel list does not include the > channel the master is currently operating on then the slave cannot use > it and the master/slave have to figure out some alternative (no rule to > define what or how that happens). As a US WSDB operator. We never see a > low power personal portable slave, other than the query from it's > master). We treat a high power fixed slave in exactly the same way as a > high power fixed master. > > On WedApr/18/12 Wed Apr 18, 12:02 PM, "Peter McCann" > <[email protected]> wrote: > >> Hi, Brian, >> >> The problem is, the master device cannot be authoritative on whether >> the slave device is approved for use by the regulator. It must rely >> on the WSDB it uses (has a relationship with) to tell it. >> >> At the least, we need a format for device identifiers that can be >> understood by multiple independently operated databases. Maybe the >> WSDB trusts the master device to collect this information securely from >> the slave devices using slave-to-master credentials. Normally, the >> allocation authority for the identifier space would be a trust anchor >> for the identifier-to-device binding. I agree that the master-to-slave >> interface is out of scope, but there should be some mechanism in the >> marketplace for the master device operator to securely bind the >> identifier presented by the slave to the communication channel with the >> slave device, in the sense that the master device is able to know in a >> secure way that the device it is talking to actually does own the >> regulator-assigned device identifier. It seems natural for the master >> device to rely on its relationship with a database to help with this >> binding. >> >> -Pete >> >> Rosen, Brian wrote: >>> <As individual, and I should have said that on all of my messages on >>> this thread> The credentialling system used between the database >>> server and its client (the master) are those of its client. The >>> database trusts its client. >>> >>> The client (the master) may need its customer, the slave, to present >>> credentials for service. >>> >>> This means we assume transitive trust on the ID information from the >>> client. The master validates the slave, the database validates the >>> master. I would not advocate trying to make anything more complex. >>> >>> Brian >>> >>> On Apr 18, 2012, at 11:16 AM, Peter McCann wrote: >>> >>>> Right, the master queries the database on behalf of the slave, >>>> sending the slave's Device ID and location. (See Don's message about >>>> validating the FCC ID). My question is, what is the security model >>>> for validating the slave's ID? Is there a secure credential >>>> associated with the ID, or is it an insecure check of a number >>>> against a whitelist? If the former, we will need a credential >>>> management system that is able to cross between different databases. >>>> If the latter, I wonder if it opens up security problems. >>>> >>>> -Pete >>>> >>>> Rosen, Brian wrote: >>>>> Perhaps I am confused, but I think in a master/slave environment, >>>>> the slave does not query the database, the master does. The slave >>>>> gets its allowed spectrum data from the master. There is always the >>>>> question of whether the master queries on its own behalf and the >>>>> slaves just get assignments within that database response, or >>>>> whether the master queries on behalf of the slaves. Might have to >>>>> support both models. In many cases, I think it's the latter: the >>>>> master queries using the slaves location and parameters. >>>>> >>>>> The most common master/slave setup is tower and clients, right? The >>>>> tower has an Internet connection and can query the database. The >>>>> clients of the tower are the slaves. Does the database query use >>>>> the location and type data of the slave or the master? >>>>> >>>>> Brian >>>>> >>>>> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: >>>>> >>>>>> I think it would be a mistake to assume that the slave & master >>>>>> devices both have pre-existing relationships with the same >>>>>> database. In a commercial service, the slave devices would all come >>>>>> from different manufacturers and would certainly have different >>>>>> owners. Wouldn't we want them to interoperate with any master >>>>>> device, assuming they are RF-compatible? >>>>>> >>>>>> -Pete >>>>>> >>>>>> Rosen, Brian wrote: >>>>>>> Doesn't the slave get it's database access through the master? >>>>>>> If that's true, the problem you are worried about doesn't exist. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>>>>>> >>>>>>>> I agree with Brian that LoST could be a good model for >>>>>>>> discovering the appropriate database for the region you're in. A >>>>>>>> nation may decide to subdivide their territory into provinces or >>>>>>>> states, each of which maintains its own database. >>>>>>>> >>>>>>>> I think it would be a mistake to assume that there is a single, >>>>>>>> pre-defined relationship for one device with just one database. >>>>>>>> In particular, I think there is a thorny issue that will arise >>>>>>>> with management of secure credentials on whitespace devices, >>>>>>>> illustrated by the first use case in Section 4.2.1 of >>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that >>>>>>>> use case says: >>>>>>>> >>>>>>>> 9. Once the master/AP has met all regulatory domain >>> requirements >>>>>>>> (e.g. validating the Device ID with the trusted database, >>>>>>>> etc) the master provides the list of channels locally >>>>>>>> available to the slave/user device. >>>>>>>> My question is, what if the master device has a relationship with >>>>>>>> one database, but the slave device has a relationship with >>>>>>>> another? How is the master's database supposed to validate the >>>>>>>> credentials of the slave device, if we don't have some sort of >>>>>>>> common trust anchor? Or will this "validation" be simply an >>>>>>>> insecure check of an ID against a whitelist/blacklist? Who will >>>>>>>> allocate Device IDs? Will they be specific to a particular >>>>>>>> database operator, or do we need some common top-level allocation >>>>>>>> format? >>>>>>>> >>>>>>>> -Pete >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> >> >> _______________________________________________ >> paws mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
