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
