Sure this added threat is important for ws users. Not only for emergency responders, all users are affected by communication breakdown between wsd and wsdb.
Question is: is this a thread on the protocol, or on the whole ws system? I think the latter. If included, I suggest the title: "Inability to obtain authorization for white spectrum use". And some text like this: The white space model makes use of a more centralized white space database an a communication protocol between the white space devices and the white space database. In cases where communication with the white space database fails, the white space devices cannot utilize white space spectrum. Emergency services, which require more spectrum precisely on locations where network infrastructure is malfunctioning or overloaded, backup communication channels and distributed white space databases are needed to overcome such circumstances. The first responders use case already suggests the required backup facilities (satcom link). It is also deployed that way, but I have to agree not everyone pays enough attention (and $€¥) to it. So yes, adding this threat description may help spending enough money for it. Or help when we make decisions on wsdb discovery. Teco Op 11 feb. 2012, om 00:00 heeft <[email protected]> <[email protected]> het volgende geschreven: > > Hi Paul/Rex, > > How about adding the following threat to the list: > > Threat 8: Natural disaster resulting in inability to obtain authorization > for > spectrum use by emergency responders > > In the case of a sizable natural disaster a lot of internet > infrastructure ceases to function. Emergency services users need to > reconstitute quickly and will rely on establishing radio WANs. The > potential for lot of radio WAN gear that has been unused suddenly > needs to be pressed into action. And the radio WANs need frequency > authorizations to function. Regulatory entities may also authorize > usage of additional spectrum in the affected areas. The white space > radio entities may need to establish communication with a database and > obtain authorizations. Alternatively there may be other mechanisms > which allow the use of spectrum by emergency service equipment without > strict authorization or with liberal interpretation of the regulatory > policy for white space usage. > > Please suggest additional text or changes as needed. > > -Raj > > > > > On 2/10/12 3:16 PM, "ext Rex Buddenberg" <[email protected]> wrote: > >> On Fri, 2012-02-10 at 21:00 +0000, [email protected] wrote: >>> Hi Rex, >>> >>> Thanks for the description. I understand the use case itself better now. >>> However I am still trying to parse the threat. >>> In the case of a natural disaster, I can imagine all types of radio >>> equipment being pressed into use. >>> So the statement: >>> "And the radio WANs need frequency authorizations to function." >>> >>> Is the threat then the inability to reach the entity that authorizes the >>> use of spectrum? >> >> Yes. >> >>> Is the reachability and inability to obtain authorization a result of a >>> malicious node preventing such communication? >> >> I did not consider this in the use case. What I was considering was >> that the disaster itself prevented comms, including those to the >> whitespace data server ... but not sure it would make a difference. >> However I would, in all use cases, consider authenticity of the data >> communicated (both ways) to be a requirement. >> >>> >>> Rgds, >>> -Raj >>> >>> >>> >>> On 2/10/12 2:28 PM, "ext Rex Buddenberg" <[email protected]> wrote: >>> >>>> Raj, >>>> >>>> I'll try ... >>>> >>>> The public safety users of spectrum are very concerned with an issue >>>> they call 'talk around'. It's not at all defined, but certainly >>>> includes a definition in which internet infrastructure or simply (in a >>>> single segment net) a base station does not exist. In IEEE 802 >>>> terminology, two erstwhile subscriber stations need to communicate. >>>> >>>> The prism through which most public safety folks look at this is the >>> LMR >>>> radio ... if I have the same freq as the guy over there that I can see >>>> then I can talk with him. >>>> Once this migrates to internet, the information power is amplified >>>> enormously, but what happens if I can't see a DNS server or a SIP >>> server >>>> or ...? The PAWS concern is 'what if I can't see the white space >>> server >>>> in order to get a freq allocation to use'. >>>> >>>> >>>> >>>> A suitable use case would be a sizable disaster where a lot of internet >>>> infrastructure ceases to function. Emergency services users need to >>>> reconstitute quickly and they will need radio WANs to do that. We can >>>> estimate that a lot of radio WAN gear that has been unused suddenly >>>> needs to be pressed into action. And the radio WANs need frequency >>>> authorizations to function. >>>> >>>> >>>> That work? >>>> >>>> On Fri, 2012-02-10 at 18:09 +0000, [email protected] wrote: >>>>> HI Paul, >>>>> >>>>> On 2/9/12 3:32 PM, "ext Paul Lambert" <[email protected]> wrote: >>>>> >>>>>> >>>>>>> The list in the current threat models text that I proposed is by no >>>>>>> means >>>>>>> exhaustiveŠ Or intended to be. The intent is to derive a key set of >>>>>>> security requirements for the protocol. The focus is on those >>> threats >>>>>>> that >>>>>>> are relevant to the device-2-database protocol rather than to the >>> much >>>>>>> more expansive topic of white space technology. >>>>>> >>>>>> Yes, but ... >>>>>> >>>>>> Without determining if there are technical mitigation mechanisms we >>>>>> should not be rejecting threats. The threats should all be examined >>>>> and >>>>>> we should explicitly determine what is in scope versus unilaterally >>> as >>>>>> part of the editing process. >>>>> >>>>> No doubt. I don't think there is any unilateral proposal here. I am >>>>> happy >>>>> to incorporate all relevant threats through the consensus process and >>>>> discussion on the mailing list. The threat model has evolved from >>> Rev 1 >>>>> to >>>>> Rev 4 as a result of feedback from you and others. >>>>> >>>>>> >>>>>> As an interesting example - if there is a natural disaster, should >>>>> there >>>>>> be protocol mechanisms to enable use of emergency services without >>>>> direct >>>>>> Internet connectivity to the DB? >>>>> >>>>> Would you consider this as a threat or a feature that the protocol >>> needs >>>>> to be concerned with regarding reachability of the database? >>>>> >>>>>> >>>>>> Loss of service (emergency and normal) usage of WS is a threat that >>>>>> should be listed and may or may not be addressed by technical or >>>>>> procedural mechanisms. >>>>> >>>>> If you can elaborate or (preferably) provide the text describing the >>>>> threat and consequences, I would be happy to include it. >>>>> >>>>> -Raj >>>>> >>>>>> >>>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>>> >>> >> >> > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
