Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Dec 2005 17:34:34 -0500

Hi.  This is not a blocking comment nor am I even asking for a change;
I'm just asking people consider this for netconf and future work.

Netconf currently recommends that netconf over ssh be run over a
different port than the normal ssh port.

That seems like a fine idea.  I think there are cases where you might
want to allow access to netconf but not allow access to the CLI
through the normal ssh port.  

However I think in many cases it would not be a security problem if
the netconf subsystem were available over the normal ssh port.  In
many applications the same privileges will be granted to users over
the CLI as to the same users over netconf.  In many cases the
functionality available through netconf will also be available through
the CLI.

--Sam

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Dec 2005 08:55:35 +0200 (EET)

Hi,

> functionality available through netconf will also be available through

As an operator, I agree.  Especially in smaller networks (say, less 
than 50 routers), the set of hosts where you can log in to the routers 
and the set of hosts from which network management (other than 
read-only SNMP) is expected to occur are similarly trusted.

With the expectation that more fine-grained control (rather than just 
IP address/port filtering) of SSH vs NETCONF access can be made as 
part of router's configuration, having a separate port is not needed, 
but it doesn't do much harm either.

However, I see that there may be different kinds of networks where 
being able to separate SSH and NETCONF access permissions at the 
IP/port filtering level may be desirable.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Eliot Lear <[email-masked]>
Date: Fri, 09 Dec 2005 08:40:04 +0100

Hi Sam,

> functionality available through netconf will also be available through
Obviously what you're suggesting isn't hard to do, and I agree with you
that in many cases use of port 22 would be safe (and it would certainly
be true for the VAST majority of cases when connecting to network
infrastructure).  However, once we decide to cover the other cases where
we are trying to give firewall administrators some leeway, I'm not sure
there's an added advantage to adding text  along the lines of "well,
sometimes you can use port 22."  For one it makes the tool building
HARDER if the other port isn't LISTENED to as well, because your canned
tools would end up playing guessing games or requiring extra
configuration.  And for our purposes I think I know of one SSH
implementation on a general computing device that hardcodes the port to
22 and that implementation also doesn't have means to support additional
applications.

All of this having been said, I am beginning to grow concerned about
port assignments and firewall administration.  If you're a firewall
administrator the IETF is about to make your life and perhaps the
performance of some low end / old gear, slightly more complex.  With
netconf there will be either two or three new ports to block.  ISMS will
later add another port.  And these are just the protocols I've been
playing with, as of late.  I'm sure a bunch of other protocols are out
there that I don't know about.  In addition there is the comparably
minor matter of well known port assignments.

All I'm saying now is that it is probably worth some thought to
reconsider the substrate RFC to give additional guidance for protocols
that have a notably similar purpose.

Regards,

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Dec 2005 09:02:35 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Obviously what you're suggesting isn't hard to do, and I
    Eliot> agree with you that in many cases use of port 22 would be
    Eliot> safe (and it would certainly be true for the VAST majority
    Eliot> of cases when connecting to network infrastructure).
    Eliot> However, once we decide to cover the other cases where we
    Eliot> are trying to give firewall administrators some leeway, I'm
    Eliot> not sure there's an added advantage to adding text along
    Eliot> the lines of "well, sometimes you can use port 22."  For
    Eliot> one it makes the tool building HARDER if the other port
    Eliot> isn't LISTENED to as well, because your canned tools would
    Eliot> end up playing guessing games or requiring extra
    Eliot> configuration.  And for our purposes I think I know of one
    Eliot> SSH implementation on a general computing device that
    Eliot> hardcodes the port to 22 and that implementation also
    Eliot> doesn't have means to support additional applications.

I think the only reason you might want to make the change is so that:

* People authorized to use the CLI in environments that have not gotten around to opening up the netconf port can use netconf

* People who have  tunnel  setups to get to ssh can also get to netconf.

However as I said, I'm not actually asking for the change just asking
people to think about it.  I think that it is even more critical to
think about it for isms than for netconf simply because we're at an
earlier stage with isms.