[Rift] draft update after today's interim (last nonce corner case discussions) ...

[Tony Przygienda <[e-mail]>]

After today's discussion in the interim (and Bruno's detailed thread on
security) here's the update to draft that should resolve all outstaning
comments and insight from implementation

5.4.3.  Security Envelope

   RIFT MUST be carried in a mandatory secure envelope illustrated in
   Figure 31.  *Any value in the packet following a security fingerprint
   MUST be used only after the according fingerprint has been validated.*

   Local configuration can *MAY* allow to skip the checking of the envelope's
   integrity.


*This should address the outstanding issue of whether nonces can be
used before security envelope is validated*
Any implementation including RIFT security MUST generate and wrap
   around local nonces properly.  *When a nonce increment leads to
   `undefined_nonce` value the value SHOULD be incremented again
   immediately.*

*That should resolve the comment on nonce rollback. *

   As a necessary exception, an implementation MUST advertise
   `undefined_nonce` for remote nonce value when the FSM is not in 2-way
   or 3-way state and accept an `undefined_nonce` for its local nonce
   value on packets in any other state than 3-way.

   *As optional optimization, an implemenation MAY send one LIE with
   previously negotiated neighbor's nonce to try to speed up a
   neighbor's transition from 3-way to 1-way and MUST revert to sending
   `undefined_nonce` after that.*

5.4.5.  Lifetime

   Protecting lifetime on flooding can *may* lead to excessive number of
   security fingerprint computation and hence an application generating
   such fingerprints on TIEs SHOULD *MAY* round the value down to the next
   `rounddown_lifetime_interval` defined in the schema when sending
   TIEs. *TIEs
   albeit such optimization in presence of security hashes over
   advancing weak nonces may not be feasible.*




*This describes optimization to shut down neighbor faster (helpful in
ZTP) and the other text is a consideration how much recomputation of
security envelopes can we really save on rounding up lifetimes and
having 'weak nonces'*



*I also looked @ the expired OSPF karp, it's clever but it's a new
protocol to negotiate and I didn't see any treatement of
losses/reordering which IMO will force it towards equivalent of 'weak
nonces' and with that make*



*it equivalent of what we have in RIFT already *


*So, please comments ...*


*--- tony *