In addition, the protocol should cover if one or more of the DB's are unable to provide services as well. Nancy
On Feb 11, 2012, at 4:17 AM, Teco Boot wrote: > 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
