Subject: RE: More confirmed-commit issues

From: "Rob Enns" <[email-masked]>
Date: Fri, 13 May 2005 14:08:27 -0700

How does this replacement text sound?

----
8.4  Confirmed Commit Capability

8.4.1  Description

   The #confirmed-commit capability indicates that the server will
   support the <confirmed> and <confirm-timeout> parameters for the
   <commit> protocol operation.  See section Section 8.3 for further
   details on the <commit> operation.

   A confirmed commit operation MUST be reverted if a follow-up commit
   (called the "confirming commit") is not issued within 600 seconds (10
   minutes).  The timeout period can be adjusted with the <confirm-
   timeout> element.  The confirming commit can itself include a
   <confirmed> parameter.

   If a confirming commit is not issued, the device will revert it's
   configuration to the state prior to the issuance of the confirmed
   commit.  Note that any commit operation, including a commit which
   introduces additional changes to the configuration, will serve as a
   confirming commit.  Thus to cancel a confirmed commit and revert
   changes without waiting for the confirm timeout to expire, the
   confirming commit can explicitly restore the configuration to it's
   state before the confirmed commit was issued.

   For shared configurations, this feature can cause other configuration
   changes (for example, via other NETCONF sessions) to be inadvertently
   altered or removed, unless the configuration locking feature is used
   (in other words, lock obtained before the edit-config operation is
   started).  Therefore, it is strongly suggested that in order to use
   this feature with shared configuration databases, configuration
   locking should also be used.

8.4.2  Dependencies

   The #confirmed-commit capability is only relevant if the #candidate
   capability is also supported.

8.4.3  Capability and Namespace

   The #confirmed-commit capability is identified by the following
   capability string:

      urn:ietf:params:xml:ns:netconf:base:1.0#confirmed-commit

   The #confirmed-commit capability uses the base NETCONF namespace URN.

8.4.4  New Operations

   None.

8.4.5  Modifications to Existing Operations

8.4.5.1  <commit>

   The #confirmed-commit capability allows 2 additional parameters to
   the <commit> operation.

   Parameters:

      confirmed:

            Perform a confirmed commit operation.

      confirm-timeout:

            Timeout period for confirmed commit, in seconds.  If
            unspecified, the confirm timeout defaults to 600 seconds.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <confirmed/>
         <confirm-timeout>120</confirm-timeout>
       </commit>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Sunday, May 08, 2005 10:24 AM
> To: netconf
> Subject: More confirmed-commit issues
> 
> Hi,
> 
> IMO, PROT, section 8.4 is not very clear what happens
> if locking is not used, or if the manager doesn't follow
> the elements of procedure that the document suggests.
> 
> If a confirmed-commit timeout is pending, and the <candidate>
> config is modified again before the 2nd <commit> or the timeout
> occurs, how does the agent interpret the <commit> that is intended
> to be for the newly modified <candidate>?  What exactly is the the
> contents of <running> after the confirm-commit timer pops?
> What if the 2nd commit is also a confirmed-commit?  What if
> time(C2) < timer(C1)? How come a manager cannot cancel a confirmed
> commit  (after commit-1 but before the timeout)?
> 
> Note that this corner-case can occur naturally if locking is not 
> properly used,
> or pathologically, if the manager holding the locks writes to the 
> <candidate>
> before finishing the first confirmed commit.  (E.g., operator 
> forgets a line
> of config -- adds it -- commits it.)
> 
> The vague warning about "use locks properly" (8.4.1, para 2) is not 
> relevant
> to agent implementers who have to make this work even if 
> locking isn't 
> used,
> used wrong, or the manager doesn't follow the implied 
> transaction model.
> 
> I would also like to note that the #rollback feature was 
> thrown out because
> of these same corner-cases, that (IMO) are neither explained 
> or properly 
> handled
> in the current draft as they relate to the #candidate and  
> #confirmed-commit
> capabilities.
> 
> Andy
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

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

---

From: Andy Bierman <[email-masked]>
Date: Sat, 14 May 2005 05:12:46 -0700

>   timeout> element.  The confirming commit can itself include a
This last sentence is confusing to me.  It makes sense if the 
<candidate> contains
new changes and the 2nd confirmed commit starts a new "revert timeout" 
for these
new changes.  

I really don't like the possible side effects from this confirmed 
commit, especially with our
shared <candidate> and global locking.  If you don't maintain the 
session and hold the
lock throughout the entire double commit, really bad things can happen. 

  (NEW ISSUE: What happens to a confirmed commit in progress if the 
session is lost
   or the agent reboots?)

 T0 - boot with baseline config
 Tc -  Manager A issues a confirmed commit, w/ revert to baseline at Tc+i
 Tc+1 - Manager A loses its connection and session
 Tc+10 - Manager B has no idea Manager A did this, comes along, gets the 
lock,
               and starts writing to the <candidate> config, which  
starts with  the contents
               of <running> at time Tc
Tc+20 - Then Manager A comes back and can't get a lock
Tc+i   - Manager A's revert timer pops before Manager B is done
            The agent reverts the state of <running> to T0.  (But B 
thinks the
            state of <running> is Tc).

At this point, it depends on the difference between config T0 and Tc, and
what Manager B is doing, as to whether benign or devastating effects 
will follow.

It's never a good thing to design this much "astonishment" into routing 
products.
At a minimum, we need to document what happens in as many corner cases as
we can think of, but we should also try to respect the principle of 
least astonishment.

>   state before the confirmed commit was issued.
I don't understand this last sentence, and this revert operation at all.
BTW, s/it's/its/ in both paragraphs above.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 16 May 2005 14:06:50 -0700

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.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 May 2005 14:30:05 -0700

>auditing to figure out who the bad guy was that reverted changes out
I would be more worried about security-related config that gets reverted
by mistake.  There is no way or Mgr B to know a confirmed commit is in
progress.  We can fix this part by adding a "confirmed-commit-in-progress"
warning (rpc-error response) that is generated if an rpc request which
would alter the <running> config is received by the agent while a 2nd
commit operation or revert-timeout is pending.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 May 2005 14:51:23 -0700

>auditing to figure out who the bad guy was that reverted changes out
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