[EAS] Next Generation

[Mike McCarthy]

Hi Harold,

I suggest a rolling three week group to address your concern. That way if
a week or even two is missed, no harm. Also, polling if a weekly test is
missed is a viable back-up for when either an endec or IPAWS returns to
service and the box determines it's codes are dated.  And that avoids a
barage of requests at a given time each week (unless FEMA misses a RWT).

I merely suggested 4 bytes as a starting point for the discussion.  As you
comment, the algorithm for the code may be public knowledge. So no number
of digits will be absoluteluy secure. With that said, the mere presence of
a validation requirement will do two things.  1) Turn away the less
ambitious hackers as they will simply not go any farther without digging
into the system and means to access to the code; and 2) decrease by at
least one order of magnitude the chance of a false event of any kind.
Conversely, it might prove to be a greater challenge and payoff to a more
agressive hacker.`Even still, the challenges will be great with a very
limited payoff.

Now, I also left the code at 4 digits/bytes so as to minimize the chance
of error in detecting the code(s) under marginal reception conditions.
Long codes are at much greater risk of seeing an error unless there is
error correction or parity.  And with three codes flowing across three
discreet data streams, at least one of the nine should get through.

I agree with the premise of checking validation on-line during an event is
fraught with many issues. All of which are not conducive to the system
working as expected. The validation must occur inside the receiving endec
and not require any outside communication to render a "go" or defer to
manual review.

MM

On Thu, November 13, 2014 5:11 pm, Harold Price wrote:
> While you are designing ...
>
> Here are some items you should consider:
>
> Preventing long delay replay problems (Bobby Bones)- just add a year
> to the protocol, define a start and end validity window in the spec, and