Subject: RE: I-D Publication Request: draft-ietf-netconf-soap-05.txt

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 11 Jul 2005 09:46:29 -0700

Hi,

I think you're leaning in the wrong direction here, folks.

Port-based screening is easy and standard to implement in firewalls and 
routers.  URL-based screening inside SOAP takes a fairly expensive ALG 
(application layer gateway) in the firewall and still is much less secure 
(because denial-of-service only requires attacking the _port_, not the 
specific SOAP application).

The IESG can and should vigorously object to NetConf being ambiguous
about the requirement for using dedicated standard port(s).  They
discouraged deployment of IPP/1.0 in print systems for two years
until IPP/1.1 required port 631 and deprecated the use of port 80.
That mess led to RFC 3205 "On the use of HTTP as a Substrate".

I suggest reading section 3 'Issues Regarding Reuse of Port 80' of
RFC 3205.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Sharon Chisholm
> Sent: Monday, July 11, 2005 12:23 PM
> To: netconf
> Subject: RE: I-D Publication Request: draft-ietf-netconf-soap-05.txt
> 
> 
> hi
> 
> I like it. If there is agreement it could be added as one of 
> those notes
> to the RFC editor.
> 
> Sharon
> 
> -----Original Message-----
> From: Ted Goddard [mailto:[email-masked]] 
> Sent: Monday, July 11, 2005 11:51 AM
> To: Chisholm, Sharon [CAR:5K50:EXCH]
> Cc: netconf
> Subject: Re: I-D Publication Request: draft-ietf-netconf-soap-05.txt
> 
> 
> 
> The idea was that new dedicated ports should be assigned, but 
> their use
> is not mandatory.  SOAP/HTTP allows applications to be 
> distinguished by
> URL, thereby allowing a variety of applications to coexist on the same
> port (so the distinct port may be necessary for administrative policy,
> but it's not necessary for the functioning of the protocol).
> 
> Perhaps the wording should be changed as follows?
> 
> > A NETCONF SOAP service can be offered on any desired port, but
> >    a new standard port for SOAP over HTTP, and a
> >    new standard port for NETCONF over SOAP (over HTTP) will 
> be defined
> 
> 
> Regards,
> Ted.
> 
> On 11-Jul-05, at 5:34 AM, Sharon Chisholm wrote:
> 
> > hi
> >
> > I have a clarifying question:
> >
> > The last paragraph of section 2.4 reads
> >
> > "It is also possible to respond to the concern on the re-use of port
> >    80.  A NETCONF SOAP service can be offered on any 
> desired port, and
> >    it is recommended that a new standard port for SOAP over 
> HTTP, or a
> >    new standard port for NETCONF over SOAP (over HTTP) be 
> defined, as
> >    requested in the IANA considerations of this document."
> >
> > Which considering the IANA considerations section says the following
> >
> > "The IANA will assign TCP ports for NETCONF for SOAP over HTTP and
> >    SOAP over BEEP."
> >
> > seems too weak. Is the section in 2.4 left over from before it was 
> > decided we liked specific ports, or did we intend to leave 
> port use as
> 
> > an exercise to the reader?
> >
> > Sharon
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:owner-
> > [email-masked]] On
> > Behalf Of Andy Bierman
> > Sent: Thursday, July 07, 2005 10:22 PM
> > To: Bert Wijnen
> > Cc: Simon Leinen; David Kessens; netconf; [email-masked]
> > Subject: I-D Publication Request: draft-ietf-netconf-soap-05.txt
> >
> >
> > [Area] OPS-NM
> > [WG]   NETCONF
> > [I-D]  draft-ietf-netconf-soap-05.txt
> > [Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt
> > [Shep] Andy Bierman <[email-masked]>
> >
> > 1.a) Yes, the WG Chairs have reviewed this version of the
> >      document, and believe it is ready for publication.
> >
> > 1.b) Yes the document has had adequate review.  Several
> >      WG members have reviewed this document.
> >
> > 1.c) There are no open issues, and no further review is
> >      required, for this document.
> >
> > 1.d) There are no concerns with this document at this time.
> >      It is possible that clarifications will be identified
> >      as implementation and interoperability experience is
> >      reported to the WG.
> >
> > 1.e) There is strong WG consensus for this document.
> >      It is expected that more complex network applications
> >      (e.g., 1st or 3rd party commercial applications) will
> >      use this application mapping for NETCONF.
> >
> > 1.f) No appeals have been threatened against this document.
> >
> > 1.g) There are some minor ID-nits that will be fixed
> >      before RFC publication. (See ID-nit log below).
> >
> > 1.h) Yes, references are split.
> >      Yes, there is a reference to an unpublished document,
> >      namely the NETCONF Configuration Protocol document
> >      (draft-ietf-netconf-prot-07.txt), but this is also ready
> >      for publication.
> >
> > 1.j) I-D Submission Summary
> >
> > Technical Summary
> >
> >
> >    The Network Configuration Protocol (NETCONF) is applicable to a
> > wide
> >    range of devices in a variety of environments.  The 
> emergence of  
> > Web
> >    Services gives one such environment, and is presently 
> characterized
> >    by the use of the Simple Object Access Protocol (SOAP).  NETCONF
> >    finds many benefits in this environment: from the re-use of  
> > existing
> >    standards, to ease of software development, to integration with
> >    deployed systems.  Herein, we describe SOAP over HTTP 
> and SOAP over
> >    BEEP bindings for NETCONF.
> >
> > Working Group Summary
> >
> >    The NETCONF Working Group has consensus to publish this document
> >    as a Proposed Standard.
> >
> > Protocol Quality
> >
> >    It is likely that there are several implementations of this
> >    document in various stages of completion at this time.
> >    Several major equipment vendors have indicated interest in
> >    supporting this document, and some non-commercial
> >    implementations are also expected.
> >
> > ----------------
> >
> > [ID-nit log]
> >
> > idnits 1.74
> >
> > tmp/draft-ietf-netconf-soap-05.txt:
> >
> > tmp/draft-ietf-netconf-soap-05.txt(452):
> >    Line is too long: the offending characters are 'elope"'
> > tmp/draft-ietf-netconf-soap-05.txt(464):
> >    Line is too long: the offending characters are 's:netconf:base:
> > 1.0">'
> >
> >
> >   Checking nits according to http://www.ietf.org/ID-Checklist.html:
> >     Checking conformance with RFC 3978/3979 boilerplate...
> >   * The document seems to lack an RFC 3978 Section 5.1 IPR 
> Disclosure
> >     Acknowledgement.
> >
> >   (Expected a match on the following text:
> >     "By submitting this Internet-Draft, each author represents that
> > any
> >     applicable patent or other IPR claims of which he or 
> she is aware
> >     have been or will be disclosed, and any of which he or 
> she becomes
> >     aware will be disclosed, in accordance with Section 6 
> of BCP 79.")
> >
> >     (The document uses RFC 3667 boilerplate or RFC 3978-like
> >     boilerplate instead of verbatim RFC 3978 boilerplate.  
> After 6 May
> 
> > 2005,
> >     submission of drafts without verbatim RFC 3978 
> boilerplate is not
> >     accepted.)
> >
> >   Checking nits according to
> > http://www.ietf.org/ietf/1id-guidelines.txt:
> >     Nothing found here (but these checks do not cover all of
> >     1id-guidelines.txt yet).
> >
> >   Miscellaneous warnings:
> >     None.
> >
> >
> >
> > --
> > 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/>
> >
> 
> 
> 
> 
> --
> 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: Ted Goddard <[email-masked]>
Date: Mon, 11 Jul 2005 11:02:04 -0600

Hi Ira,

> URL-based screening inside SOAP takes a fairly expensive ALG

Why can't the firewall simply drop all requests to the NETCONF URL
if the origin of those requests is on a list of attackers?  This seems
more expensive to process (string comparison vs integer comparison)
but not fundamentally less secure.

Thanks,
Ted.

On 11-Jul-05, at 10:46 AM, McDonald, Ira wrote:

>> [email-masked]]On

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jul 2005 21:53:22 +0200

> but not fundamentally less secure.

I think Ira was pointing to my Linux kernel which is pretty good in 
filtering packets based on port numbers but rather bad in filtering 
SOAP requests by URL or something like that.

/js

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