Re: More confirmed-commit issues

[Andy Bierman <ietf@andybierman.com>]

Wes Hardaker wrote:

> Andy> T0 - boot with baseline config
> Andy> Tc -  Manager A issues a confirmed commit, w/ revert to baseline at Tc+i
> Andy> Tc+1 - Manager A loses its connection and session
> Andy> Tc+10 - Manager B has no idea Manager A did this, comes along, gets the 
> Andy> lock,
> Andy> and starts writing to the <candidate> config, which  
> Andy> starts with  the contents
> Andy> of <running> at time Tc
> Andy> Tc+20 - Then Manager A comes back and can't get a lock
> Andy> Tc+i   - Manager A's revert timer pops before Manager B is done
> Andy> The agent reverts the state of <running> to T0.  (But B 
> Andy> thinks the
> Andy> state of <running> is Tc).
>
> It's even more interesting when you think about A doing things like
> that intentionally.  Since the lock has been dropped, you're down to
> auditing to figure out who the bad guy was that reverted changes out
> from under you.
>  
The audit log may not help:
- scenario above occurs
- attacker (mgr B) logs in, makes changes to <candidate> to open
  holes in firewalls, etc. but doesn't commit them.  He doesn't
  close the session either.
- Mgr A recovers from the lost connection, logs in, gets the lock,
 and issues a <commit> command, which serves to finish his confirmed
 commit, and also commit the attacker's changes.

The 2nd <commit> in a confirmed-commit should be preceded by
a <discard-changes> operation, in the event the lock is lost
after the first <commit> operation.

Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>