Subject: [paws] including a timestamp in every message

From: "Harasty, Daniel J" <[email-masked]>
Date: Thu, 25 Jul 2013 14:51:04 +0000

I'd like to comment some of Sanjeev's input.

I prefer to send independent replies on each topic, as that way a given email thread is about a single topic (more or less).

Sanjeev mentioned:

From: [email-masked]
Sent: Thursday, July 25, 2013 10:31 AM
[...]
2. It will be a good thing to include 'timestamp:string requirted' paramter in all the protocol transactions
[...]

I don't see the purpose in this.  I don't see how the operation of the Database - or the way it will respond to any given request - is dependent on it knowing what time the Device thinks it is.  (Or vice versa.)

Unless someone can point out a use case for this field, I consider it unneeded "chatter" in the protocol.  That said, the Database or Device can easily ignore it, so I won't push back if others believe this field is generally useful.

Dan

---

From: Vincent Chen <[email-masked]>
Date: Thu, 25 Jul 2013 08:45:36 -0700

I would agree with Dan. Given questionable reliability of time base on
devices, the Database should not trust timestamps in the request, even when
they are provided.
Thus, it does seem like "chatter".

-vince

On Thu, Jul 25, 2013 at 7:51 AM, Harasty, Daniel J
<[email-masked]>wrote:

> I'd like to comment some of Sanjeev's input.****
>
> ** **
>
> I prefer to send independent replies on each topic, as that way a given
> email thread is about a single topic (more or less).****
>
> ** **
>
> Sanjeev mentioned:****
>
> ** **
>
> Sent: Thursday, July 25, 2013 10:31 AM****
>
> [...]****
>
> 2. It will be a good thing to include 'timestamp:string requirted'
> paramter in all the protocol transactions ****
>
> [...]****
>
> ** **
>
> I don’t see the purpose in this.  I don’t see how the operation of the
> Database – or the way it will respond to any given request – is dependent
> on it knowing what time the Device thinks it is.  (Or vice versa.)****
>
> ** **
>
> Unless someone can point out a use case for this field, I consider it
> unneeded “chatter” in the protocol.  That said, the Database or Device can
> easily ignore it, so I won’t push back if others believe this field is
> generally useful.****
>
> ** **
>
> Dan****
>
> ** **
>
> ** **
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: "Aliu, Osianoh Glenn" <[email-masked]>
Date: Thu, 25 Jul 2013 16:30:40 +0000

Hi Daniel,
I would suggest the field be left there as it can be used by the database for security and ensuring devices adhere to frequency requirements of querying the database.

Using the timestamp field, I would assume the database can easily detect if a device is attempting a flooding attack.

Kind Regards,
Glenn

From: Harasty, Daniel J [mailto:[email-masked]]
Sent: Thursday, July 25, 2013 4:51 PM
To: [email-masked]
Subject: [paws] including a timestamp in every message

Sanjeev mentioned:

From: [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 25, 2013 10:31 AM
[...]
2. It will be a good thing to include 'timestamp:string requirted' paramter in all the protocol transactions
[...]

Dan

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Thu, 25 Jul 2013 19:08:53 +0000

Glenn,

Thank you for the input.  But I'm still confused.  It sounds like what you are calling a "flooding attack" might be where the device is sending many many requests at once, attempting (what I would call) a denial of service attack.

I don't understand how a timestamp helps a database detect/avoid this.  For one: if a Device is purposely misbehaving (by attempting a "flooding" attack), and it "knows" that the server will observe the timestamp and some algorithm to detect such an attack, then why do we trust that it will send accurate timestamps?

In other words" requiring an accurate "timestamp" field is likely to be as effective as the spec simply stating "Devices MUST NOT perform flooding attacks".

Unless PAWS introduces a unique, new attack vector or vulnerability, then I think the means to detect/avoid a generic denial of service-type attack is to rely on previously well-known methods, such as discussed in http://en.wikipedia.org/wiki/Denial-of-service_attack#Handling.

-- Dan

From: Aliu, Osianoh Glenn [mailto:[email-masked]]
Sent: Thursday, July 25, 2013 12:31 PM
To: Harasty, Daniel J; [email-masked]
Subject: RE: [paws] including a timestamp in every message

Hi Daniel,

Kind Regards,
Glenn

From: Harasty, Daniel J [mailto:[email-masked]]
Sent: Thursday, July 25, 2013 4:51 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] including a timestamp in every message

Sanjeev mentioned:

Dan

---

From: [email-masked]
Date: Fri, 26 Jul 2013 21:38:51 +0530

Hi,

In the PAWS working, geo-location(latitude/longitude), and timestamp are the
2 key parameters which affects the spectrum availability and use. That way I
would like to see even these 2 values to be embedded in all the protocol
transactions. Perhaps these 2 values, together with device id gives a
whitespace context too. Also as seen in this mail chain which may help in
identifying, and rejecting security threats. 

Thanks and Regards,

Sajeev

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vincent Chen
Sent: Thursday, July 25, 2013 9:16 PM
To: Harasty, Daniel J
Cc: [email-masked]
Subject: Re: [paws] including a timestamp in every message

-vince

On Thu, Jul 25, 2013 at 7:51 AM, Harasty, Daniel J <[email-masked]>
wrote:

I prefer to send independent replies on each topic, as that way a given
email thread is about a single topic (more or less).

Sanjeev mentioned:

[...]

2. It will be a good thing to include 'timestamp:string requirted' paramter
in all the protocol transactions 

[...]

I don't see the purpose in this.  I don't see how the operation of the
Database - or the way it will respond to any given request - is dependent on
it knowing what time the Device thinks it is.  (Or vice versa.)

Unless someone can point out a use case for this field, I consider it
unneeded "chatter" in the protocol.  That said, the Database or Device can
easily ignore it, so I won't push back if others believe this field is
generally useful.

Dan

 

-- 
-vince