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? Is the reachability and inability to obtain authorization a result of a malicious node preventing such communication? 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
