Re: use of netconf to configure Unix systems

[Eliot Lear <lear@cisco.com>]

Joel,

First thanks for the productive comments.  Please see below.

Joel M. Halpern wrote:
> If the network operators gained anything by having Netconf running on
> 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.
>
> 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?

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

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