ThanKs ... that catching the concept .. Paul
>-----Original Message----- >From: [email protected] [mailto:[email protected]] >Sent: Friday, February 10, 2012 3:01 PM >To: [email protected] >Cc: Paul Lambert; [email protected] >Subject: Re: [paws] Threat model (Rev 3) > > >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
