Raj, Since I recognize a great deal of pasting here, I don't think I could object. Seriously, looks like you've captured.
On Fri, 2012-02-10 at 23:00 +0000, [email protected] wrote: > 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
