Subject: RE: use of netconf to configure Unix systems

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 17 Mar 2006 15:57:33 -0800

Andy Bierman wrote:
> 
> 
> Randy Presuhn wrote:
> > Hi -
> >
> > I'm intrigued by the concern that netconf should be 
> assigned a Unix privileged port.
> > Does this mean that someone has or is developing a netconf 
> data model to configure
> > Unix hosts or applications?  Are there other reasons for 
> running a netconf server
> > on a Unix host?
> >   
> 
> Perhaps somebody is already implementing a "NETCONF to Unix 
> Config file" 
> gateway,
> running on Fedora4.  Netconf for unix is a very real possibility.
>

Hi Andy,

I can think of no conceivable reason someone would seriously
want to use Netconf for remote UNIX configuration.  For desktop
and server end systems, WBEM, WS-Management, and WSDM are the
plausible and _deployed_ solutions.  The DMTF DMI and DMTF CIM
models have been used for a decade to configure UNIX, MacOS,
Windows, and Linux systems.

Give me one technical reason that shifting from existing open
standard management protocols (that are already deployed and
already support interoperable event subscriptions and event
notifications) to Netconf would be a good idea?

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]

--
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: Fri, 17 Mar 2006 16:27:23 -0800

> notifications) to Netconf would be a good idea?

People can experiment with whatever they want.
I still use ASCII config files to manage most linux services.
I guess I'm the only one still doing it the old-fashioned way.

> - Ira

Andy

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Mar 2006 16:53:45 -0800

> Windows, and Linux systems.
I think you are looking at the problem as though every UNIX device is a
classical general computing device.  That is really not the case, as
Linksys & Juniper can attest.  Also, it's very early to say exactly how
popular netconf will be and on what platforms it will extend.

Finally I do wish you would answer the question that was asked several
times: if NETCONF is not a good use of well known ports, what is?

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Mar 2006 20:21:40 -0500

I believe that the correct, current, answer to your question is "nothing."
Netconf is clearly not a better use of those ports than a large 
number of things that have been assigned higher numbered ports.
Hence, I think Netconf should live in the same space as everyone else.
The 1024 port space was reserved based on a certain model of the 
world.  That model no longer obtains.

There is arguably even a good reason that Netconf should not be 
using, by default, a reserved port.  I can easily imagine 
experimental router implementations where the control logic (and even 
the router and router config logic) are living in user space.  They 
are not running as priviledged processes.  They could support 
Netconf, and the standard port, if that port were not in the kernel 
set.  But could not use the normal Netconf port if it was in the system space.

Using a <1024 port buys us nothing.
Not using one is more appropriate, and may even be useful.

Yours,
Joel M. Halpern

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Mar 2006 17:45:13 -0800

Joel M. Halpern wrote:
> Netconf is clearly not a better use of those ports than a large number 
> of things that have been assigned higher numbered ports.
> There is arguably even a good reason that Netconf should not be using, 
> by default, a reserved port.  I can easily imagine experimental router 
> implementations where the control logic (and even the router and 
> router config logic) are living in user space.  They are not running 
> as priviledged processes.  They could support Netconf, and the 
> standard port, if that port were not in the kernel set.  But could not 
> use the normal Netconf port if it was in the system space.
>

Your previous paragraph clearly contradicts this statement.
I am interested in current practice for operational systems,
not experimental systems that might exist in the future.
Current practice is to make it harder for users to attach processes
to system port numbers that higher port numbers.

> Not using one is more appropriate, and may even be useful.

I disagree -- current practice by network operators is contrary
to this conclusion. 

The logic that no protocol should ever use the <1024 range again
instantly makes the "Registered Port" range a more scarce resource
for no apparent reason.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Mar 2006 21:02:15 -0500

If the network operators gained anything by having Netconf running on 
ports below 1024, I would be more inclined to see that used.
As far as I can see from the discussion, there is no benefit.
And the notion of user space routers is not theoretical.  I would 
like the ForCES CE to be able to be managed using netconf.  And it is 
a specific design goal that ForCES CEs are NOT part of the kernel.
And that is just one example.

Looking at the list of assigned ports, there are an awful lot of 
things there that I can imagine would be run on a router control 
processor, and which better not have their port stolen.  (I am not 
naming protocols because the odds are that some of them are not for 
routers, and that some I am not even noticing are for routers.) It 
also looks like there are plenty of host oriented protocols that 
would need to have their ports remain available above 1024.  It sure 
looks like folks have learned to live with protocols (not just SIP 
and STUN, but many, many operationally necessary protocols) running 
above 1024.  Hence, it does not seem to me that the risk of "port 
occupation" is any more relevant for this protocol than for many, 
many other protocols.

So, is there some other reason that I have not seen for wanting to 
use a low numbered port?

Yours,
Joel

At 08:45 PM 3/17/2006, Andy Bierman wrote:
>>experimental router implementations where the control logic (and 
>>even the router and router config logic) are living in user 
>>space.  They are not running as priviledged processes.  They could 
>>support Netconf, and the standard port, if that port were not in 
>>the kernel set.  But could not use the normal Netconf port if it 
>>was in the system space.
>>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Mar 2006 18:24:56 -0800

Joel,

First thanks for the productive comments.  Please see below.

> ports below 1024, I would be more inclined to see that used.
I would agree that from a network perspective it's just as easy to block
a port below 1024 as it is above.  That having been said, I was confused
by what you wrote earlier as to how a well known port would harm efforts
in this area.

> And the notion of user space routers is not theoretical.  I would like
> the ForCES CE to be able to be managed using netconf.  And it is a
> specific design goal that ForCES CEs are NOT part of the kernel.
Just to be clear, at least on UNIX, ports below 1024 are accessed in
user space, the only difference being that root must own the process at
the time the port is assigned.  Processes that do not need well known
ports really SHOULDN'T have them because dealing with root permissions
*is* a minor complication - you really do want to isolate the code that
owns that port (for instance through use of inetd).  If this doesn't
address your concern, could you please clarify?

But it also sounds like you may wish for there to be some sort of
virtualization in NETCONF, as Elwyn discussed in his review (RFC
3620?).  That might be a worthy extension to consider.
> also looks like there are plenty of host oriented protocols that would
> need to have their ports remain available above 1024.  It sure looks
> like folks have learned to live with protocols (not just SIP and STUN,
> but many, many operationally necessary protocols) running above 1024. 
> Hence, it does not seem to me that the risk of "port occupation" is
> any more relevant for this protocol than for many, many other protocols.
>
> So, is there some other reason that I have not seen for wanting to use
> a low numbered port?

Ultimately not from me because I think a better approach is to have some
sort of authorization mechanism in the bind() and listen() routines, so
I would largely agree with you that the distinction should go away. 
Given that it's here I've attempted to apply it as intended.  In my mind
it's not a router versus host thing, but simply a matter of whether you
believe there is something special about < 1024 and what criteria should
be used to assign below it.

Thanks again,

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Mar 2006 18:40:20 -0800

> So, is there some other reason that I have not seen for wanting to use 

There are ways to allow users specific access to root programs (e,g,. 'su').

There is really no way to logically conclude this discussion.

You and Ira are arguing that no protocol should ever use the system port
space again, including NETCONF.  If this is IESG policy, then I guess we
are done discussing it.

Some others have said the port number doesn't really matter,
except a bit for unix implementations, and some "legacy bias" against
using higher port numbers for system services. (Large "don't care" camp)

Eliot and I are arguing that the task of configuring a networking device
(a server, not a plain host!)  is clearly a privileged task in almost all
environments, which is NETCONF's chartered purpose.  If device configuration
and control isn't a system task on a networking device, then
I don't know what is.

If there are no possible reasons for assigning system port numbers
anymore, then IANA can stop asking which range the new protocol
should be assigned, and WGs like us don't need to argue about
anymore.

Andy

>>> even the router and router config logic) are living in user space.  
>>> They are not running as priviledged processes.  They could support

---

From: Phil Shafer <[email-masked]>
Date: Fri, 17 Mar 2006 22:12:19 -0500

>a specific design goal that ForCES CEs are NOT part of the kernel.

Use of privileged port does not require code to be part of the
kernel, just that it be root (uid 0) when the bind() call is made.
Daemons can do their bind() and then setuid() to nobody to protect
themselves from giving crackers root access.

To me, the benefit of using a privileged port is minor, but the
benefit to _any_ protocol is minor nowadays, so I don't see this
as a big issue either way.  NETCONF doesn't need a priv port, but
no other protocol can be considered more (or less ;^) deserving,
so if IANA's willing to give us three, we should be gratious enough
to accept them.  If not, it's not a big deal.

>So, is there some other reason that I have not seen for wanting to 

Having to be root for debugging is a pain, but one can just do some
port forwarding to get around that.

>Eliot Lear wrote:
>Given that it exists, when SHOULD something be assigned <1024?

When the protocol was designed before the onslaught of Windows.  Or
if the protocol is expected to survive past the death of Windows.
Neither applies here ;^)

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Mar 2006 23:46:34 -0500

minor: Ira and I are not the only people speaking up.  I was struck 
by the tone of the debate that was occurring, which is why I spoke up.

And just to clarify my own sloppiness, I realized after I wrote the 
note that "root" rather than "kernel" is what is needed for a low 
port, and that is indeed easier.  But it is MUCH better to develop 
and run applications without having to make them root, even 
briefly.  (The coupling of the various permissions within Unix is not 
our problem, but that doesn't make it desirable.)

Given that, to paraphrase Phil's comment, it doesn't make that much 
difference, it would seem more sensible to go for a higher range port number.
However, neither Ira nor I speak for the IESG.  Heck, I'm not even 
speaking as a "reviewer", just as a participant / observer in this 
working group.
I guess I just find "its appropriate to use low numbers for this" a 
bad reason.  From different perspectives, different things are 
"privileged".  I know many folks who will claim that the only really 
privileged operation is collecting money. And others.......

Yours,
Joel

PS: I would prefer not to hang this protocol up on a debate about 
whether <1024 ports should ever be given out.  That would be a waste 
of all our time.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 18 Mar 2006 08:40:46 +0100

> themselves from giving crackers root access.

Several modern Unix like systems now support a more granular set of
capabilities so that the above is not quite correct. On those modern
systems, a process has to have the appropriate capabilities to bind a
priviledged port.

/js

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