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
