Subject: copy-config

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Dec 2005 12:17:26 +0100 (CET)

Hi,

The <copy-config> operation takes source and target as parameters.  I
think the order of these is wrong - an implementation needs to buffer
the entire inline config before knowing which target is used.  I
suggest that the order is reversed - target before source.

The order is correct for edit-config.

(our implementation makes use of this for both edit-config and
copy-config in order to find a small set of diffs to apply to the db)

/martin

--
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: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Dec 2005 12:37:27 +0100

> copy-config in order to find a small set of diffs to apply to the db)

You start processing an operation before you have completed the
parsing of the request message which invokes that operation??

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Dec 2005 13:01:06 +0100 (CET)

> parsing of the request message which invokes that operation??

Yes.  No persistent stuff and no side effects of course; it's ok to get
a parse error or whatever later.

/martin

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 9 Dec 2005 08:43:20 -0500

Hi,

This sounds to me like a detail related solely to implementation
choices. I suggest you read the whole command so you know both the
source and target, and then you can, in your implementation, process
the arguments in the order you choose. 

It would probably be a good idea to validate the whole command before
starting processing, because this could make your implementation more
robust against mal-formed requests, including deliberate attempts to
cause denial of service to other users of the system.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Bjorklund
> Sent: Friday, December 09, 2005 6:17 AM
> To: [email-masked]
> Subject: copy-config
> 
> Hi,
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Dec 2005 15:08:56 +0100 (CET)

"David B Harrington" <[email-masked]> wrote:
> choices.

I agree.  But edit-config seems to be done that way (maybe
unintentional?!?), and I think it's nice to specify a protocol so that
it can be implemented as efficient as possible.

> I suggest you read the whole command so you know both the

This is of course trivial, but the point is that an implementation
will have to do more buffering than necessary.

> robust against mal-formed requests

Of course we handle mal-formed requests - the processing done in our
implementation at this point is more than plain parsing, but it does
not involve any side effects.

And (of course) we do validate everything before doing any side
effects.

As a somewhat simplified example, suppose I know that the target config is
valid, and I get a copy-config which contains:

   ...
   <interfaces>
      <interface>
         <ifName>eth0</ifName>
         <ifAddr>10.0.0.1</ifAddr>
         ... more params follow ...
      </interface> (*)
      ...
   </interfaces>
   ...

Now, at point (*) if the interface eth0 is unchanged, I can throw away
that part of the data.   But if I don't know which target to compare
against, I can't do this trick.

> including deliberate attempts to

If the agent has to buffer everything, it might be easier to do a dos
attack!

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 09 Dec 2005 12:44:47 -0500

Seems completely reasonable.

Thanks,
 Phil

---

From: Lei Zhang <[email-masked]>
Date: Fri, 09 Dec 2005 10:34:27 -0800

>If the agent has to buffer everything, it might be easier to do a dos
Second this. Requiring netconf server to buffer all inline data before 
start editing seems really lame.

The DOS claim is unjustified - why would a properly authenticated user 
attack a netconf server?

Lei

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 9 Dec 2005 10:54:33 -0800

Hi -

> From: "Lei Zhang" <[email-masked]>
> To: "Martin Bjorklund" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Friday, December 09, 2005 10:34 AM
> Subject: Re: copy-config
...
...

Wouldn't this be like arguing that if one has authentication,
one does not need access control?  There are cases where
having an audit trail that identifies who caused the damage
does little good, and it's much better to prevent the damage
from occurring in the first place.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 09 Dec 2005 11:59:52 -0800

> The DOS claim is unjustified - why would a properly authenticated user 

A few comments:

 - This is good implementation feedback. the kind we said we wanted.
 - Dismissing the issue as implementation-specific is not a good idea.
 - Worrying about the buffering of a single parameter,
    but the WG doesn't care about a max-message-size?  I don't get it.
 - Changing the parameter order at this late date is okay unless anybody
    objects strongly.
 - XML is verbose. Deal with it.  It's very possible that future commands
   or even current ones can cause the agent to process large amounts of
   data.
- The current parameter order is a result of considering the needs of the
   reader and writer, not the netconf engine implementor.
   That is our design focus.  In this case, parameter order isn't very 
universal,
   since there are many examples where the order is (copyTo, copyFrom).

> Lei

Andy