Subject: Re: Proposed Resolution to PROT I-D Issues List

From: Wes Hardaker <[email-masked]>
Date: Thu, 17 Mar 2005 21:15:20 -0800

Andy> I012)

Wes> 7.3 example shows the use of ftp.  Can we use something more secure in
Wes> the example please?

Andy> ** CLOSED **
Andy> No change; no suggested replacement text provided

Suggested new text:

Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <copy-config>
         <source>
           <url>https://[email-masked]:passphrase/configs/testbed-dec10.txt</url>
         </source>
         <target>
           <running/>
         </target>
       </copy-config>
     </rpc>

--------------------

Andy> I013)
Andy> I014)
Andy> I015)

Wes> 7.4: #url allows a url to appear as a delete.  doing remote file
Wes> management using netconf is questionable at best.  From a security
Wes> point of view, it makes me cringe.
...

Andy> ** CLOSED **
Andy> No change; no suggested replacement text provided

Suggested text:  Add to 8.8.5.1:

   If this parameter contains a URL, then it should identify a local
   configuration file.

(this text exists for delete-config already)

----------------------

New text for the beginning of appendix B:

The following XML schema is for informational purposes.  It has
reviewed but there is no guarantee that the schema exactly matches the
definitions defined in the protocol description above.
Implementations MUST NOT assume that an incoming message is free from
malicious intent because it has been successfully verified against
this schema.

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

--
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: "Steven Berl \(sberl\)" <[email-masked]>
Date: Fri, 18 Mar 2005 09:03:01 -0800

<snip>

> The following XML schema is for informational purposes.  It 
> has reviewed but there is no guarantee that the schema 
> exactly matches the definitions defined in the protocol 
> description above.
> Implementations MUST NOT assume that an incoming message is 
> free from malicious intent because it has been successfully 
> verified against this schema.
> 

Are you saying that we have a formal language description of the syntax of
the protocol messages, but that is there just for information? The real
definition of the syntax is in the narrative text? It seems to me that this
is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there
just for information and the real description of the MIB is in the text? The
normative reference for message syntax should be the schema, and the text
should be there to describe the schema, and to explain things that are not
expressed in the schema such as the sequence of messages, or additional
constrains.

-steve

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Mar 2005 12:29:31 -0800

><snip>
I think we should make the text normative and the XSD as correct as 
possible,
but not intended to override the text.  The exact standard netconf XSD that
an agent should accept is different depending on the exact set of capability
values supported by that agent for a particular session.

The XSD represents a superset of all base + standard capability variants.
I think this is good enough.

Andy

---

From: Hector Trevino <[email-masked]>
Date: Fri, 18 Mar 2005 13:40:55 -0700

in-line
Hector

Andy Bierman wrote:

>>> reviewed but there is no guarantee that the schema exactly matches 
>>> the definitions defined in the protocol description above.
>>> Implementations MUST NOT assume that an incoming message is free 
>>> from malicious intent because it has been successfully verified 
>>> against this schema.
>>>   
>>

Why couldn't the operation defintions in the XSDs be normative as well? 
Seems this is a way to help with interoperability.
I agree that "The XSD represents a superset of all base + standard 
capability variants" and it is an implementation decision as to what 
capabilities are supported/implemented but the definitions themselves 
should be normative. I guess I don't understand the objection to making 
the schemas normative.

-- 
Hector Trevino
Network Management Technology Group (NMTG)
Cisco Systems Inc.        Voice:  720-875-1369
Suite 400                      
9155 E. Nichols Ave     Fax:    720-875-3014
Englewood, CO             E-mail: [email-masked]
80112

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 21 Mar 2005 13:59:59 -0800

>>>>> On Fri, 18 Mar 2005 09:03:01 -0800, "Steven Berl (sberl)" <[email-masked]> said:

Steven> Are you saying that we have a formal language description of
Steven> the syntax of the protocol messages, but that is there just
Steven> for information?

My only intent was to state that it hasn't been proven to be perfect,
and thus implementers should not rely on it as a check that an
incoming packet is indeed perfect.

The problem I've seen with XML applications is that many of them pass
an incoming packet to a validator (which is merely validating the XML,
not the data within) and then doesn't implement its own sanity error
checking afterward.  Thus, I've actually seen many security problems
in XML applications because they assume that the packet contains
everything it needs in the exact form it needs when in fact it may
not.

Andy is right, however, that an XSD probably couldn't be written which
meet every implementations requirements.

If you're going to make it normative, I don't think it should go into
the appendix as it is currently.  (If memory serves, appendices in
RFCs are supposed to be normative).