Subject: [paws] PAWS use case: ad hoc network for emergency scenario's

From: Teco Boot <[email-masked]>
Date: Wed, 3 Aug 2011 08:08:28 +0200

Hi Scott,

I have written down an practical use case for PAWS in an ad hoc
network for emergency scenario's. Please comment.

Thanks, Teco

 3.x.  Rapid deployed network for emergency scenarios

 Organizations involved in handling emergency operations often have 
 a fully owned and controlled infrastructure, with dedicated spectrum, 
 for day to day operation. However, lessons learned from recent 
 disasters show such infrastructures are often highly affected by the 
 disaster itself. To set up a replacement quickly, there is a need for 
 fast reallocation of spectrum, where in certain cases spectrum can be 
 freed for disaster relief.

 To utilize free or freed spectrum quickly and reliable, automation of
 allocation, assignment and configuration is needed. A preferred 
 option is make use of a robust protocol, already adopted by radio
 manufacturers. This approach does in no way imply such organizations
 for disaster relief must compete on spectrum allocation with other 
 white spaces users, but they can.

 A typical network topology would include wireless access links to 
 the public Internet or private network, wireless ad hoc network 
 radios working independent of a fixed infrastructure and satellite 
 links for backup where lack of coverage, overload or outage of 
 wireless access links occur.

                           \|/
                            | ad hoc
                            |
                          |-|-------------|
                          | Master node   |       |------------|
  \|/                     | with          |       | Whitespace |
   | ad hoc              /| backhaul link |       | Database   |
   |              /-----/ |---------------|       |------------|
 --|-------------/                |      \           /
 | Master node   |                |       |      (--/--)
 | without       |                |       ------(       )
 | backhaul link |                |  Wireless  / Private \
 ---------------\-                |    Access (   net or  )
                 \                |            \ Internet )
                  \    \|/        |      -------(        /\
                   \    | ad hoc  |      |       (------)  \---------
                    \   |         |      /                 | Other  |
                     \--|-------------  /Satellite         | nodes  |
                     | Master node   | / Link              ----------
                     | with          |/
                     | backhaul link |
                     -----------------

     Figure x: Rapid deployed network with partly connected nodes

 In the ad hoc network, all nodes are master nodes in a way that
 they allocate RF channels from the white space database. However,
 the backhaul link could not be available to all nodes, such as
 depicted for the left node in figure x. To handle RF channel 
 allocation for such nodes, a master node with a backhaul link 
 relays or proxies the database query for them. So master nodes 
 without a backhaul link follow the procedure as defined for 
 clients.

 The ad hoc network radios utilise the provided RF channels. Details 
 on forming and maintenance of the ad hoc network, including repair 
 of segmented networks caused by segments operating on different 
 RF channels, is out of scope of spectrum allocation.

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Aug 2011 08:38:51 -0400

I think this is a good use case and brings up a new requirement:
The protocol must cater for a query from one entity on behalf of another entity.  

In many circumstances, this would be invisible to the protocol - the relay client would simply relay packets or use some private protocol.  However, in some circumstances we may need to know the identity of the requester as well as the real client, so the actual requirement is to be able to carry two identities.

Brian

On Aug 3, 2011, at 2:08 AM, Teco Boot wrote:

> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: Nancy Bravin <[email-masked]>
Date: Wed, 3 Aug 2011 05:59:32 -0700

---

From: Nancy Bravin <[email-masked]>
Date: Wed, 3 Aug 2011 06:03:31 -0700

Sorry for the missing info on the last email…here you go. N

Begin forwarded message:

> From: Nancy Bravin <[email-masked]>
> Date: August 3, 2011 5:58:02 AM PDT
> To: "Rosen, Brian" <[email-masked]>
> Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's
> 
> Brian, Scott and Teco, 
> What happens when the systems WS or otherwise are overloaded with calls, emails from around the world and the database can not handle the traffic
> let alone the priority for first responders…is there no transfer to other regions for 1. Information that someone is alive, a posting as it were? 2. NO power
> or no infrastucture left? 3. Two identities are an important ingredient, but maybe HAM operators should be part of this as they have been in the past
> picking up others by voice and transferring that information? Should they not have an identifier? 
> If you look at any disaster in Northern Japan, Indonesia, flooding around the world, how will this work? What will the backhaul be and
> a fixed or replaced or temporary system can take a while if conditions make getting to locations impossible? ANd should some have to move to higher ground
> and abandon any working equipment assuming power and something to receive the signal? 
> I think this has some great thoughts, but seems to be more relative in the US, or EU, what about developing countries, will this work as well?
> Thanks for your time, SIncerely, Nancy 
> 
> 
> On Aug 3, 2011, at 5:38 AM, Rosen, Brian wrote:
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Aug 2011 09:25:38 -0400

Nancy

In any standards work, it's essential to stay within the agreed upon scope.  If you don't, then you can't finish.

The issues you raise here are no doubt interesting and important, but they are not in scope of this work.  If you wish to work on solving them, then start an effort to do so.  If that involves protocol work, the IETF has a pretty easy process to get work going, assuming there is a large enough group of people in the organization who want to solve that problem with you.

For this work, our scope is a protocol between a white space device and a database that asks what spectrum is available for the type, location and other parameters the white space device is in.  Teco has provided another use case that fits that.  

We are always obligated to consider attacks of various forms on the protocol, as well as any unusual requirements for overload conditions.  I don't think there are many here, but if you don't agree, then please suggest requirements.  Given how these databases work, I don't think a priority access mechanism has much value: often we find that the work to identify and prioritize use is more work than serving all responses.  I think that would be the case here.  In any event, we will need some sort of identity for getting access to the database, and the database could take that identity into account when servicing the response, including some priority mechanism.  We don't need any standards for that.

HAM operators would seem to have no role in the protocol, and thus no need of identifiers.

Likewise, I don't see any protocol requirements to support disaster situations.  What would we need to do IN THE PROTOCOL to have it work in disaster situations?

Finally, this work seems to be applicable to any country that has spectrum congestion.  You don't need to share spectrum if there is room for all players, but even in developing countries, spectrum is relatively scarce.  I don't think the size or location of the country has any bearing on the protocol.  If you think otherwise, please state what requirement we need.

Brian

On Aug 3, 2011, at 8:58 AM, Nancy Bravin wrote:

> Scott and Teco,

---

From: Teco Boot <[email-masked]>
Date: Wed, 3 Aug 2011 15:44:57 +0200

Hi Nancy,

Thanks for the questions !!!
I'll try to answer, but as Brian already answered, much is not in scope of this WG.

Op 3 aug 2011, om 15:03 heeft Nancy Bravin het volgende geschreven:

>> let alone the priority for first responders…
First thought: the PAWS request will be delayed, or dropped somewhere.
But often, such organizations have dedicated infrastructure for emergency cases. For example, a PAWS database server could be easily replicated (it is query-only) and access links using satcom can be used for accessing these servers. 
So a requirement is that the PAWS protocol should be capable to be used in a distributed, fault tolerant system. 

>> is there no transfer to other regions for 1. Information that someone is alive, a posting as it were?
I understand the importance of such function. PAWS can help to fulfill. But PAWS is just a piece of the puzzle. And more puzzles are on the table.

>> 2. NO power
>> or no infrastucture left?
Again, the dedicated infrastructure can be allocated for emergency situations. Often, it is added to normal day-to-day infrastructure. Electric generators are important. But relation to PAWS is minimal, I think.

>> 3. Two identities are an important ingredient, but maybe HAM operators should be part of this as they have been in the past
>> picking up others by voice and transferring that information?
You are right. They can do that also.

>> Should they not have an identifier?
Not sure what you mean. Identifiers for their equipment? IP addresses? Names?
I think they should have such. And they have.

>> If you look at any disaster in Northern Japan, Indonesia, flooding around the world, how will this work?
This is not the WG to make the whole design. My opinion is that PAWS can help. Help a lot.

>> What will the backhaul be and
>> a fixed or replaced or temporary system can take a while if conditions make getting to locations impossible?
This is out of scope for PAWS, I think. 
Assume satcom link to a backbone, or a local replicate of a PAWS database.

>> ANd should some have to move to higher ground
A bit out of scope for this WG.

>> I think this has some great thoughts, but seems to be more relative in the US, or EU, what about developing countries, will this work as well?
I think the developing countries do not have the years of experience of regulators as in US, UK or elsewhere. But they do have lots of white spaces!! 
I guess PAWS will have fast adoption in development countries. We will see.

Thanks, Teco

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Aug 2011 09:46:14 -0400

As I read Teco's note, he is asking for a system that allocates spectrum.
As I understand the PAWS work, it specifically does not allocate 
spectrum.  It gives all equivalent requesters in the same place the same 
answer.

So if 10 emergency teams set up there PAWS oriented gear in the same 
place, they will all get the same list of available spectrum.  That does 
not appear to meet Teco's stated requrement.

There is also in implicit requirement that the database be subject to 
fairly fast update, so that spectrum taht would normally be reserved can 
be freed up for emergency use if the primary user is suddenly off-line. 
  There are interesting validation issues for this, particularly since 
the party responsible for those licensed uses may be unreachable due to 
the same disaster.  And DB management and update is, as far as I know, 
also outside of the PAWS charter.

Yours,
Joel

PS: That is not to say that what Teco describes is uninteresting.  It is 
an interesting and important problem.  But it seems not to be PAWS.

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Aug 2011 10:10:50 -0400

I read this entirely differently.

Teco is describing an ad-hoc network that needs bandwidth.  One or more participants in the network have an independent path to the Internet.  A request  is made by participants, possibly relayed through other participants to determine what spectrum is available in the location of the participant.

>>> RF channels, is out of scope of spectrum allocation.

I agree that if 10 teams set up in the same place, they get the same spectrum.  I don't see anything in Teco's use case that says otherwise.

There is no implied requirement that the primary user is told to stop using spectrum.  You get what is normally available in that location.  Consequently, there is no speed implication.  While there may be some way that the primary user's use is affected by emergencies, that isn't in scope of our work.  

In the base use case, we have a requirement for managing schedules.  Right now, the FCC only requires devices to query the database every 24 hours.  In other nations, this may not hold.  In fact, a news crew using wireless microphones would like to get 15 minute or less changes in schedule.  I think we might want to keep that in mind.  I believe it only reflects the load on the server, although some broadcast like mechanism that says "please recheck the database ASAP" might be nice.

Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Aug 2011 10:33:33 -0400

Teco, would you please clarify.  Clearly, Brian and I are reading your 
note differently.

Thank you,
Joel

---

From: Nancy Bravin <[email-masked]>
Date: Wed, 3 Aug 2011 07:34:09 -0700

Dear Brian, 
It is not that I do not understand what you are saying, what is in scope and what is not, what is in the prevue of others…what I am suggesting is, in the case
of HAM operators, it is something that spectrum is allocated for, which one can find in the ITU,  and each country's regulations relating to such use. As such, licensed, it could be a valuable resource in some of the disasters that take place around the world. I do understand that it is licensed, there are many types of transmitting equipment on the tops of mountains around the world and as 
an additional resource, you are not allocated spectrum, it is already there, with in some cases voice, video, IP access etc…I thought that it might be an extra component that could contact the database and in doing so, give location, or pass on the information as described in the previous examples. If this is out of scope, my apologies. 
Thanks for your thoughts.
Sincerely, Nancy

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Aug 2011 10:41:25 -0400

It's out of scope.

The scope of this work is that we have a set of primary users that may not be using all of the spectrum in the band.  That is what gives rise to the term "white space" = empty space.  We have secondary users who desire to make use of this empty space.  We're providing a protocol for those secondary users to ask where the white space is.

Your example of HAM operators doesn't fit.  There are no permitted secondary users in the amateur bands.

Brian

---

From: <[email-masked]>
Date: Wed, 3 Aug 2011 15:47:56 +0000

Hi,

I support this use case. PAWS should support a query from one entity on
behalf of another.

Regards,
Scott

On 8/3/11 7:38 AM, "ext Rosen, Brian" <[email-masked]> wrote:

>In many circumstances, this would be invisible to the protocol - the
>relay client would simply relay packets or use some private protocol.
>However, in some circumstances we may need to know the identity of the
>requester as well as the real client, so the actual requirement is to be
>able to carry two identities.
>
>Brian
>

---

From: Teco Boot <[email-masked]>
Date: Wed, 3 Aug 2011 17:55:04 +0200

Joel,

Op 3 aug 2011, om 15:46 heeft Joel M. Halpern het volgende geschreven:

> As I understand the PAWS work, it specifically does not allocate spectrum.  It gives all equivalent requesters in the same place the same answer.
I should have circumvent the term "allocate". To be replaced with "request free" or similar.

> So if 10 emergency teams set up there PAWS oriented gear in the same place, they will all get the same list of available spectrum.  That does not appear to meet Teco's stated requrement.
There are MAC layers that work in shared spectrum (e.g. 802.11). I am aware of the lack of guaranteed service, but using it is "better than nothing". Often, the principle is: use what you can get. And be polite, others are with you. 

Radio could start using the most unused channels (e.g. by sensing). Or use spread spectrum. Or CSMA (which is sensing).
It helps a lot if the gear gets running without manual intervention. Planning is also a bad idea. Using shared media access technology helps.

> There is also in implicit requirement that the database be subject to fairly fast update, so that spectrum taht would normally be reserved can be freed up for emergency use if the primary user is suddenly off-line.  There are interesting validation issues for this, particularly since the party responsible for those licensed uses may be unreachable due to the same disaster.  And DB management and update is, as far as I know, also outside of the PAWS charter.
No misunderstanding, I do not suggest revocations. Using time-out within hours or days is much faster than current practice where allocation is in decades.
A scenario could be where TV broadcast is limited to fewer channels, and a messages is pushed: "there could be more RF for you". This type of message can be out-of-band for PAWS (and should be, I think). Sure there could be less RF also. But that would not revoke, I think.

Want to see TVWS video? Check http://www.youtube.com/watch?v=IxLvEoP_jLM
This tower had a small fire, with unexpected results. More free spectrum near where I live :-)

Thanks, Teco

> 
> Yours,
> Joel
> 
> PS: That is not to say that what Teco describes is uninteresting.  It is an interesting and important problem.  But it seems not to be PAWS.
>

---

From: Nancy Bravin <[email-masked]>
Date: Wed, 3 Aug 2011 10:07:42 -0700

Dear Brian and all, 

Yes, it may very well be out of scope, my thought is the same as the one that was given below…I thought that the spectrum allocated to HAM operators, would qualify as one that
could be "freed" and consistent with 3.x below. I Sorry my interpretation of this emergency situation for disaster only was not in line with what the author meant. 
Sincerely, Nancy

---

From: Subir Das <[email-masked]>
Date: Thu, 04 Aug 2011 14:51:13 -0400

Scott,
Are you suggesting to have proxy/relay support ?

Thanks,
_Subir

On 8/3/2011 11:47 AM, [email-masked] wrote:
> On 8/3/11 7:38 AM, "ext Rosen, Brian"<[email-masked]>  wrote:
>

---

From: <[email-masked]>
Date: Thu, 4 Aug 2011 19:35:39 +0000

Hi Subir,

Yes. The use case below requires this functionality.

Regards,
Scott

On 8/4/11 1:51 PM, "ext Subir Das" <[email-masked]> wrote:

>>> The protocol must cater for a query from one entity on behalf of
>>>another
>>> entity.
>>>

---

From: Robert Wu <[email-masked]>
Date: Thu, 4 Aug 2011 12:40:23 -0700 (PDT)

Will be very happy if PAWS can support this use case - critical for M2M. 

Best regards, Robert 
6Harmonics Inc. 

--- On Fri, 8/5/11, [email-masked] <[email-masked]> wrote:

From: [email-masked] <[email-masked]>
Subject: Re: [paws] PAWS use case: ad hoc network for emergency scenario's
To: [email-masked], [email-masked]
Received: Friday, August 5, 2011, 1:35 AM

Hi Subir,

Regards,
Scott

---

From: Subir Das <[email-masked]>
Date: Thu, 04 Aug 2011 15:46:21 -0400

Thanks.

_Subir

On 8/4/2011 3:35 PM, [email-masked] wrote:
> On 8/4/11 1:51 PM, "ext Subir Das"<[email-masked]>  wrote:
>
>> Scott,

---

From: Paul Lambert <[email-masked]>
Date: Thu, 4 Aug 2011 14:59:38 -0700

I don't see that a proxy or two addresses are ever required to meet the described use cases.
1) security needs to be end-to-end and a proxy that can modify the request is not allowed by the FCC
2) devices that cannot initially reach the GDB can initially be a client/slave/Mode I device
   The "master" then asks on their behalf and enables operation of the client
   Subsequently the device that was the client could act as a Master
   since it can now reach the GDB through the initial master

Paul

Paul A. Lambert |  Marvell  | +1 650 787 9141

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, August 04, 2011 12:36 PM
> To: [email-masked]; [email-masked]
> >>> requester as well as the real client, so the actual requirement is
> to
> >>>be
> >>>>                     \   |         |      /                 | Other

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 4 Aug 2011 18:06:51 -0400

You are confusing U.S. FCC rules with IETF protocol requirements.

We have several participants, including me, that would foresee "on behalf of" requests, where identification of both the original requester and the intermediary may be needed.   I will reiterate that it may be that the intermediary is simply relaying packets and would not be visible in a protocol exchange.  That would work on current FCC rules, but doesn't need anything in the protocol to support.

Just because the FCC currently disallows such a situation does not mean that there won't be other nations that do allow them.

I do think that the security model has to be fleshed out more, and we might have more requirements there.  

Brian

---

From: Paul Lambert <[email-masked]>
Date: Thu, 4 Aug 2011 16:33:10 -0700

Ok - FCC being an example ... here's the requirement:

48) The PAWS protocols must provide end-to-end security that prevents the modification of the messages sent between a White Spaces Device and the Geolocation Database.

A proxy is a man-in-the-middle attack.  A proxy that can modify a request and insert it's own address information is a mechanisms and not a useful requirement.

A transparent proxy ... that tunnels messages or changes link/network/transport layer information is possible, but does not seem very interesting in the scope of this effort. 

Paul

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, August 04, 2011 3:07 PM
> To: Paul Lambert
> Cc: [email-masked]; [email-masked];
> [email-masked]
> We have several participants, including me, that would foresee "on
> behalf of" requests, where identification of both the original
> requester and the intermediary may be needed.   I will reiterate that
> it may be that the intermediary is simply relaying packets and would
> not be visible in a protocol exchange.  That would work on current FCC
> rules, but doesn't need anything in the protocol to support.
> 
> Just because the FCC currently disallows such a situation does not mean
> that there won't be other nations that do allow them.
> 
> >>>> I support this use case. PAWS should support a query from one
> entity
> >> on
> >>>> behalf of another.
> >>>>
> >>>> Regards,
> >>>> Scott
> >>>>
> >>>>
> >>>>> However, in some circumstances we may need to know the identity
> of
> >> the
> >>>>>> disaster itself. To set up a replacement quickly, there is a
> need
> >> for
> >>>>>> fast reallocation of spectrum, where in certain cases spectrum
> can
> >> be
> >>>>>> To utilize free or freed spectrum quickly and reliable,
> automation
> >> of
> >>>>>>                   \    | ad hoc  |      |       (------)  \-----
> -
> >> ---
> >>>>>>                    \   |         |      /                 |
> Other
> >> |
> >>>>>>                     \--|-------------  /Satellite         |
> nodes
> >> |
> >>>>>>                     | Master node   | / Link              ------
> -
> >> ---
> >>>>>>                     | with          |/
> >>>>>>                     | backhaul link |
> >>>>>>                     -----------------
> >>>>>>
> >>>>>>

---

From: Teco Boot <[email-masked]>
Date: Fri, 5 Aug 2011 09:56:09 +0200

Paul,

> 48) The PAWS protocols must provide end-to-end security that prevents the modification of the messages sent between a White Spaces Device and the Geolocation Database.
Please provide ref.

I read FCC requirements as it allows a (protected) proxy function between Mode II and Fixed / Mode I. Other regulators exist.

FCC Federal Register/Vol. 75, No. 233::
>> 62. The Commission will further require that communications between TV bands devices and databases be transmitted using secure methods to prevent corruption or unauthorized modification of data. This requirement includes communications of channel availability and other spectrum access information between fixed and Mode II devices (it is not necessary for TVBDs to apply security coding to channel availability and channel access information that they simply pass through as such information will already be protected by the sending device). The Commission will require that when Mode I devices communicate with fixed or Mode II devices for purposes of obtaining a list of available channels, they are to use a secure method that ensures against corruption or unauthorized modification of the data. 

And:
>> (f) Mode II personal/portable device. A personal/portable TVBD that uses an internal geo-location capability and access to a TV bands database, either through a direct connection to the Internet or through an indirect connection to the Internet by way of fixed TVBD or another Mode II TVBD, to obtain a list of available channels.

I see (future) possibilities for this proxy function between fixed (rapid deployed) nodes.

> A proxy is a man-in-the-middle attack.  A proxy that can modify a request and insert it's own address information is a mechanisms and not a useful requirement.
If a TVWS device is malfunctioning, the security model is broken.

> A transparent proxy ... that tunnels messages or changes link/network/transport layer information is possible, but does not seem very interesting in the scope of this effort. 
If relay is used, it could be IP packet forwarding. Or PAWS message relay. No impact on PAWS protocol indeed. But this is to be decided later on. The use case simply describes the use case, nothing more. Next steps are gathering requirements and engineering.

Teco

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Aug 2011 08:38:27 -0400

I believe we do have a requirement to ensure privacy and integrity in the transaction between the device and the database.  Privacy because location is revealed.  Integrity because a Man in the Middle attack which modifies the request or response could cause interference for primary and/or secondary users.  We also have a requirement for authentication, because, as in the U.S., the database may be a commercial service with authorized users, and, in order to reveal location, the user will want to make sure it is talking to the bona fide database it thinks it is.

Its very common for protocols like this to have such requirements, and we probably would be questioned if we did not provide such capability in the protocol.  The protocol document will require a "Security Considerations" section in which these kinds of issues, among others, will need to be discussed.  The IETF is particularly sensitive to the privacy considerations associated with location of users.

Brian

---

From: Teco Boot <[email-masked]>
Date: Fri, 5 Aug 2011 15:29:50 +0200

Brian,

> I believe we do have a requirement to ensure privacy and integrity in the transaction between the device and the database.  Privacy because location is revealed.  Integrity because a Man in the Mid…
OK.

I think nothing prevents us for having a proxy or relay function. There is a trust relation between the PAWS master and geo database. There should be a trust relation between the TVWS master and slave (out of scope for PAWS). If the master functions as proxy or relay for the slave, the PAWS trust model is extended, in that the geo database has a trust relation with the master and implicit with all its slaves. I can imagine that some master devices are accredited for such, not all.

Teco

---

From: Paul Lambert <[email-masked]>
Date: Fri, 5 Aug 2011 14:03:19 -0700

Hi Teco,

While disagreeing initially with your proxy-ish requirement for
PAWS .. I do see a difference in how we are viewing
the set of requirements.

There seem to a variety of ways to look at this elephant:
PAWS as a unique "protocol"
PAWS as a data model for information carried in a particular framework
PAWS as a system specification supporting various communication models
Etc ...

As a system - I agree with you that implementations should
be allowed that "relay" PAWS messages/PDUs. This seems to
be viable without specific work at the upper layers and
should be transparent to end-to-endd security.

Proxy is another matter. I usually interpret a proxy
as acting on behalf and modifying the original request.
A system can always create a proxy like mode without additional
specification or considerations.  The proxy however would be
viewed (at the other end of the communications) as the principal.

The current FCC notion of Mode II devices requesting
enablement for Mode I is akin to a proxy where the Master
is acting on behalf of the client.  We could call this a
proxy ... but the role(IMHO) needs stronger definition
that simply passing on the request of another device.

The role of the Master is stronger in the sense that it
may directly provide enablement and channel information
without direct queries to the GDB.  There is more state here
than a simple proxy would maintain.

All this said ... your basic request at the network topology level
is quite valid.  Not all entities will have access to a GDB
and yet will need ways to determine available spectrum.

Paul

> From: Teco Boot [mailto:[email-masked]]
> Sent: Friday, August 05, 2011 6:30 AM
> To: Rosen, Brian
> Cc: Paul Lambert; [email-masked]
> > I believe we do have a requirement to ensure privacy and integrity in
> the transaction between the device and the database.  Privacy because
> location is revealed.  Integrity because a Man in the Middle attack
> which modifies the request or response could cause interference for
> primary and/or secondary users.  We also have a requirement for
> authentication, because, as in the U.S., the database may be a
> commercial service with authorized users, and, in order to reveal
> location, the user will want to make sure it is talking to the bona
> fide database it thinks it is.
> OK.
>
> I think nothing prevents us for having a proxy or relay function. There
> is a trust relation between the PAWS master and geo database. There
> should be a trust relation between the TVWS master and slave (out of
> scope for PAWS). If the master functions as proxy or relay for the
> slave, the PAWS trust model is extended, in that the geo database has a
> trust relation with the master and implicit with all its slaves. I can
> imagine that some master devices are accredited for such, not all.
>
> Teco
>
>
> > Its very common for protocols like this to have such requirements,
> and we probably would be questioned if we did not provide such
> capability in the protocol.  The protocol document will require a
> "Security Considerations" section in which these kinds of issues, among
> others, will need to be discussed.  The IETF is particularly sensitive
> to the privacy considerations associated with location of users.
> >
> > Brian
> >
> >>> 48) The PAWS protocols must provide end-to-end security that
> prevents the modification of the messages sent between a White Spaces
> Device and the Geolocation Database.
> >> Please provide ref.
> >>
> >> I read FCC requirements as it allows a (protected) proxy function
> between Mode II and Fixed / Mode I. Other regulators exist.
> >>
> >>>> 62. The Commission will further require that communications
> between TV bands devices and databases be transmitted using secure
> methods to prevent corruption or unauthorized modification of data.
> This requirement includes communications of channel availability and
> other spectrum access information between fixed and Mode II devices (it
> is not necessary for TVBDs to apply security coding to channel
> availability and channel access information that they simply pass
> through as such information will already be protected by the sending
> device). The Commission will require that when Mode I devices
> communicate with fixed or Mode II devices for purposes of obtaining a
> list of available channels, they are to use a secure method that
> ensures against corruption or unauthorized modification of the data.
> >>
> >> And:
> >>>> (f) Mode II personal/portable device. A personal/portable TVBD
> that uses an internal geo-location capability and access to a TV bands
> database, either through a direct connection to the Internet or through
> an indirect connection to the Internet by way of fixed TVBD or another
> Mode II TVBD, to obtain a list of available channels.
> >>
> >>> A proxy is a man-in-the-middle attack.  A proxy that can modify a
> request and insert it's own address information is a mechanisms and not
> a useful requirement.
> >>> A transparent proxy ... that tunnels messages or changes
> link/network/transport layer information is possible, but does not seem
> very interesting in the scope of this effort.
> >> If relay is used, it could be IP packet forwarding. Or PAWS message
> relay. No impact on PAWS protocol indeed. But this is to be decided
> later on. The use case simply describes the use case, nothing more.
> Next steps are gathering requirements and engineering.
> >>
> >> Teco
> >>
> >>
> >>>
> >>> Paul
> >>>
> >>>
> >>>> I do think that the security model has to be fleshed out more, and
> we
> >>>> might have more requirements there.
> >>>>
> >>>> Brian
> >>>>
> >>>>> I don't see that a proxy or two addresses are ever required to
> meet
> >>>> the described use cases.
> >>>>> 1) security needs to be end-to-end and a proxy that can modify
> the
> >>>> request is not allowed by the FCC
> >>>>> The "master" then asks on their behalf and enables operation of
> the
> >>>> client
> >>>>>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>>> Of
> >>>>>> [email-masked]
> >>>>>> On 8/4/11 1:51 PM, "ext Subir Das"
> <[email-masked]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Scott,
> >>>>>>>>> In many circumstances, this would be invisible to the
> protocol -
> >>>>>> the
> >>>>>>>>> requester as well as the real client, so the actual
> requirement
> >>>> is
> >>>>>> to
> >>>>>>>>> be
> >>>>>>>>>> Organizations involved in handling emergency operations
> often
> >>>> have
> >>>>>>>>>> disasters show such infrastructures are often highly
> affected by
> >>>>>> the
> >>>>>>>>>> A typical network topology would include wireless access
> links
> >>>> to

---

From: Teco Boot <[email-masked]>
Date: Sat, 6 Aug 2011 10:06:23 +0200

Hi Paul,

> PAWS .. I do see a difference in how we are viewing
I think we have to do some work on requirements. At first, let's
have use cases.

I hope we see a merged document soon, as WG doc, and ask WG for
comments. Could be interim telco meeting. Use cases should be complete. 
Then, we analyze the reqs.

But as I mentioned in the meeting, reqs are highly driven by rules
from regulators. We have to describe how this works (IETF consensus
is not enough). Having a baseline of reqs is fine.

> There seem to a variety of ways to look at this elephant:
It is not that big...

> PAWS as a system specification supporting various communication models
I would say: all three, but in reverse order.
And it is not "unique". There are many similar protocols, tailored
for different purposes. 

> should be transparent to end-to-endd security.
OK.
Can be done at IP layer. We don't need to come up with another 
network protocol :-)
However, the PAWS packet exchange could have an unacceptable volume
for acquiring a communication channel.

> viewed (at the other end of the communications) as the principal.
Not sure on this. Assume master is fixed. DB registers locations.
Others request RF channel list. Can we accept that proxying
master spoofs its own position? What if initiating master is of 
another type?
Term "initiating master" needs another thought. Slave doesn't fit
either, because slave can switch to master after it has connectivity
to the DB.

OK.

> than a simple proxy would maintain.
OK, it would be a "complex proxy".

Thanks.

Teco

---

From: Paul Lambert <[email-masked]>
Date: Mon, 8 Aug 2011 12:31:40 -0700

Hi Teco,

> master spoofs its own position?

Proxy is not a word I think we should use here.  A device that creates
a network speaks on behalf of it's clients that may not have location
capabilities.  There is a delegation of trust and responsibility to
this Master device that is more than just a proxy service.

This is a very explicit differentiation into a two tier trust model.
Different regulatory domains may differ from the FCC and have other
flatter models - however, cutting back from two layers to one is
easier than adding a layer of trust/functionality later.

A Master enables the use of spectrum by other (non-Master devices) within it's
geographic range.  The master may not need to contact the GDB for each
enablement. The FCC currently requires per enablement checking of the
device type/id.  Checking the available channels has a longer potential
latency.

This gets into a interesting design area - parameterization of potential
regulatory rules ...

> What if initiating master is of
> another type?

Slave or client would fit ... these are different functional elements
that would coexist. A device starts as client/slave/Mode-I ... it may
continue communicating to GDB as client/slave/Mode-I while at the same time
starting to act as a master.

Much of the bootstrapping, mesh, IBSS, etc. can be handled by decomposition
of the functional elements and allowing multiple at the same time.

Paul

> Sent: Saturday, August 06, 2011 1:06 AM
> To: Paul Lambert
> Cc: Rosen, Brian; [email-masked]
> >>>>>> not be visible in a protocol exchange.  That would work on
> current
> >> FCC
> >>>>>> Just because the FCC currently disallows such a situation does
> not
> >> mean
> >>>>>>> 2) devices that cannot initially reach the GDB can initially be
> a
> >>>>>> client/slave/Mode I device
> >>>>>>>> Subject: Re: [paws] PAWS use case: ad hoc network for
> emergency
> >>>>>>>> scenario's
> >>>>>>>>
> >>>>>>>> Hi Subir,
> >>>>>>>>
> >>>>>>>>>> On 8/3/11 7:38 AM, "ext Rosen,
> Brian"<[email-masked]>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> The protocol must cater for a query from one entity on
> behalf
> >> of
> >>>>>>>>>>> another
> >>>>>>>>>>> entity.
> >>>>>>>>>>>
> >>>>>>>>>>>> I have written down an practical use case for PAWS in an
> ad
> >> hoc
> >>>>>>>>>>>> a fully owned and controlled infrastructure, with
> dedicated
> >>>>>>>> spectrum,
> >>>>>>>>>>>> option is make use of a robust protocol, already adopted
> by
> >>>>>> radio
> >>>>>>>>>>>> for disaster relief must compete on spectrum allocation
> with
> >>>>>> other
> >>>>>>>>>>>> links for backup where lack of coverage, overload or
> outage
> >> of
> >>>>>>>>>>>> \|/                     | with          |       |
> Whitespace
> >>>>>>>>>>>> |              /-----/ |---------------|       |----------
> --
> >> |
> >>>>>>>>>>>> --|-------------/                |      \           /
> >>>>>>>>>>>>               \    | ad hoc  |      |       (------)  \---
> -
> >> -
> >>>>>> -
> >>>>>>>> ---
> >>>>>>>>>>>>                \   |         |      /                 |
> >>>>>> Other
> >>>>>>>> |
> >>>>>>>>>>>>                 | Master node   | / Link              ----
> -
> >> -
> >>>>>> -
> >>>>>>>> ---
> >>>>>>>>>>>>                 | with          |/
> >>>>>>>>>>>>                 | backhaul link |
> >>>>>>>>>>>>                 -----------------
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> the backhaul link could not be available to all nodes,
> such
> >> as
> >>>>>>>>>>>> The ad hoc network radios utilise the provided RF
> channels.
> >>>>>>>> Details
> >>>>>>>>>>>> on forming and maintenance of the ad hoc network,
> including
> >>>>>> repair

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Aug 2011 15:47:47 -0400

The point of the use case is an ad hoc network with no master.  That's why "proxy" is a better term.

Brian

---

From: Gerald Chouinard <[email-masked]>
Date: Mon, 08 Aug 2011 17:12:46 -0400

Brian,

My preference goes to Paul's interpretation.  A master role for the
delegation of the database query makes more sense because it carries with
it a 'legal' responsibility whereby, someone is still responsible if
interference occurs because the recommendations from the database have
not been followed.  This responsibility would be more difficult to
define, or to attribute, in the case of an ad-hoc network.

By the way, in the case of the FCC Regulation, the paragraph that deals
with "proxying" or better "mastering" database
queries is 15.701(c) of the 10-174 MO&O on Fixed Devices,
second sentence, where it is specified that: "A fixed TVBD may
select channels for operation itself from a list of available channels
provided by a TV bands database, initiate and operate a network by
sending enabling signals to one or more fixed TVBDs and/or
personal/portable TVBDs."

This is what the base stations in the 802.22 WRANs will do.  This
way, the operator of the base station has the legal responsibility of
complying to the database requests.

Gerald

At 15:47 08-08-11 -0400, Rosen, Brian wrote:

The point of the use case is an ad
hoc network with no master.  That's why "proxy" is a
better term.

Brian

emergency

>>> PAWS as a data model for information carried in a
particular

>> framework

>>> PAWS as a system specification supporting various
communication

>> models

emergency

>>>>> I believe we do have a requirement to ensure privacy
and integrity

>> in

>>>> the transaction between the device and the
database.  Privacy

>> because

>>>> I think nothing prevents us for having a proxy or relay
function.

>> There

>>>> slave, the PAWS trust model is extended, in that the geo
database

>> has a

>>>> trust relation with the master and implicit with all its
slaves. I

>>>> "Security Considerations" section in which
these kinds of issues,

>> among

>>>> others, will need to be discussed.  The IETF is
particularly

>> sensitive

>>>>>> Op 5 aug 2011, om 01:33 heeft Paul Lambert het
volgende

>> geschreven:

>>>> prevents the modification of the messages sent between a
White

>> Spaces

>>>> other spectrum access information between fixed and Mode
II devices

>> (it

>>>> communicate with fixed or Mode II devices for purposes
of obtaining

>>>> that uses an internal geo-location capability and access
to a TV

>> bands

>>>> database, either through a direct connection to the
Internet or

>> through

>>>> an indirect connection to the Internet by way of fixed
TVBD or

>>>>>> I see (future) possibilities for this proxy
function between fixed

>>>> (rapid deployed) nodes.

>>>> request and insert it's own address information is a
mechanisms and

>>>> link/network/transport layer information is possible,
but does not

>> seem

>>>>>> If relay is used, it could be IP packet
forwarding. Or PAWS

>> message

>>>>>>>> Subject: Re: [paws] PAWS use case: ad
hoc network for emergency

>>>>>>>> You are confusing U.S. FCC rules with
IETF protocol

>> requirements.

>>>>>>>> We have several participants, including
me, that would foresee

>> "on

>>>>>>>> requester and the intermediary may be
needed.   I will reiterate

>>>> that

>>>>>>>> it may be that the intermediary is
simply relaying packets and

>>>> would

>>>>>>>> I do think that the security model has
to be fleshed out more,

>> and

>>>>>>>>> Subsequently the device that was the
client could act as a

>> Master

>>>>>>>>>> From: [email-masked]
[mailto:[email-masked]]
On

>>>>>>>>>> To:
[email-masked]; [email-masked]

>>>>>>>>>>>> I support this use case.
PAWS should support a query from

>> one

>>>>>>>>>>>>> I think this is a
good use case and brings up a new

>>>> requirement:

>>>>>>>>>>>>> In many
circumstances, this would be invisible to the

>>>>>>>>>>>>> relay client would
simply relay packets or use some private

>>>>>>>>>> protocol.

>>>>>>>>>>>>> However, in some
circumstances we may need to know the

>>>> identity

>>>>>>>>>>>>>> I have written
down an practical use case for PAWS in an

Teco

>>>>>>>>>>>>>> Organizations
involved in handling emergency operations

>>>>>>>>>>>>>> for day to day
operation. However, lessons learned from

>>>> recent

>>>>>>>>>>>>>> disaster itself.
To set up a replacement quickly, there is

>>>>>>>>>>>>>> fast
reallocation of spectrum, where in certain cases

>>>> spectrum

>>>>>>>>>>>>>> allocation,
assignment and configuration is needed. A

>>>> preferred

>>>>>>>>>>>>>> option is make
use of a robust protocol, already adopted

>>>>>>>>>>>>>> manufacturers.
This approach does in no way imply such

>>>>>>>>>> organizations

>>>>>>>>>>>>>> for disaster
relief must compete on spectrum allocation

>>>>>>>>>>>>>> A typical
network topology would include wireless access

>>>>>>>>>>>>>> the public
Internet or private network, wireless ad hoc

>>>> network

>>>>>>>>>>>>>> radios working
independent of a fixed infrastructure and

>>>>>>>> satellite

\|/

| ad hoc

|

|-|-------------|

| Master node   |
|------------

\|/
| with
|       |

>>>>>>>>>>>>>> | ad
hoc
/| backhaul link |       | Database

|
/-----/ |---------------|
|----------

--|-------------/
|
\           /

>>>>>>>>>>>>>> | Master
node
|
|       |
(--/--)

without
|
|
------(       )

>>>>>>>>>>>>>> | backhaul link
|
|  Wireless  / Private \

---------------\-
|    Access (   net or  )

\
|            \
Internet )

\    \|/
|
-------(        /\

\    | ad hoc  |
|       (------)  \---

\   |
|
/
|

\--|-------------
/Satellite         |

| Master node   | /
Link
----

| with          |/

| backhaul link |

-----------------

>>>>>>>>>>>>>> Figure x: Rapid
deployed network with partly connected

>>>>>>>>>>>>>> In the ad hoc
network, all nodes are master nodes in a way

>>>> that

>>>>>>>>>>>>>> they allocate RF
channels from the white space database.

>>>>>>>> However,

>>>>>>>>>>>>>> the backhaul
link could not be available to all nodes,

>>>>>>>>>>>>>> depicted for the
left node in figure x. To handle RF

>> channel

>>>>>>>>>>>>>> allocation for
such nodes, a master node with a backhaul

>>>> link

>>>>>>>>>>>>>> relays or
proxies the database query for them. So master

>>>>>>>>>>>>>> without a
backhaul link follow the procedure as defined

>>>>>>>>>>>>>> of segmented
networks caused by segments operating on

>>>> different

>>>>>>>>>>>>>> paws mailing
list

[email-masked]

>>>>>>>>>>>>> paws mailing
list

paws mailing list

[email-masked]