[EAS] FCC NPRM on improving EAS just issued

[Sean Donelan]

On Tue, 2 Feb 2016, felucia at att.net wrote:
> Initially the NWS policy for the date time stamp was that that was the 
>time when the warning would expire.  Example, the tornado warning is in 
>effect until JJJHHMM.  Do not know if that policy was changed.

Julian days (ordinal date) wrap around every year. When comparing 
+TTTT-JJJHHMM you need to decide how much clock skew and how far in the 
future or past is acceptable.  Are the sender's or receiver's clock too 
far in the past or future, or is it a recording of an old alert that 
expired years in the past.

January 1, 2015 = Julian Day 1
December 31, 2015 = Julian Day 365
January 1, 2016 = Julian Day 1
December 31, 2016 = Julian Day 366

Is an alert with the date JJJHHMM = 0341200 in the future or in the past?

1. Overly loose validation checks allow replay attacks (false positive 
re-transmitting an invalid alert)

2. Overly strict validation checks hurt interoperability (false negative 
not re-transmitting a valid alert)

Ambigious and poorly written specifications make everything worse. 
Protocol standards bodies have learned there are always interoperability
issues that come up, and they need to issue errata and clarifications to 
protocol standards.