24 Sep
2020
24 Sep
'20
11:15 p.m.
Gentlepeople,
Currently the details of what PyDECnet circuits connect to are not displayed. So you can
see that a Multinet circuit is up and the other end is node 42.73, but you don't see
the IP addresses or the like.
When things are working that's fine; when they are broken it might be helpful to see
what something is trying to talk to.
On the other hand, hiding IP addresses is arguably a security feature. So I have this
question:
1. Should the addressing info (basically, what's in the --device config argument) be
shown in the PyDECnet web interface?
2. Should the addressing info be visible via NCP / NML?
The difference is that #1 can be limited to be local only, if you use an internal address
for the web service. That's what I do for my nodes except for the mapper, though
perhaps there isn't a strong argument why it should be so restrictive. #2, on the
other hand, is visible to all HECnet users assuming you haven't disabled NML in your
config settings.
I'd be interested in comments. Am I too concerned about hiding information, or is it
sensible to be cautious?
paul
24 Sep
24 Sep
11:25 p.m.
FWIW, I don't care if my IP or FQDN is displayed for either option.
Neither is especially secret. And in my view, security thru obscurity is
not especially effective.
Which reminds me - I need to get some of my HECnet link partners to enable
passwords on their connections...
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Paul Koning
Sent: Thursday, September 24, 2020 2:16 PM
To: <hecnet at update.uu.se>
Subject: [HECnet] Question for PyDECnet users
Gentlepeople,
Currently the details of what PyDECnet circuits connect to are not
displayed. So you can see that a Multinet circuit is up and the other end
is node 42.73, but you don't see the IP addresses or the like.
When things are working that's fine; when they are broken it might be
helpful to see what something is trying to talk to.
On the other hand, hiding IP addresses is arguably a security feature. So I
have this question:
1. Should the addressing info (basically, what's in the --device config
argument) be shown in the PyDECnet web interface?
2. Should the addressing info be visible via NCP / NML?
The difference is that #1 can be limited to be local only, if you use an
internal address for the web service. That's what I do for my nodes except
for the mapper, though perhaps there isn't a strong argument why it should
be so restrictive. #2, on the other hand, is visible to all HECnet users
assuming you haven't disabled NML in your config settings.
I'd be interested in comments. Am I too concerned about hiding information,
or is it sensible to be cautious?
paul
11:30 p.m.
On Sep 24, 2020, at 5:25 PM, Robert Armstrong <bob
at jfcl.com> wrote:
FWIW, I don't care if my IP or FQDN is displayed for either option.
Neither is especially secret. And in my view, security thru obscurity is
not especially effective.
Ditto
Which reminds me - I need to get some of my HECnet link partners to enable
passwords on their connections...
Ooops
/s
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Paul Koning
Sent: Thursday, September 24, 2020 2:16 PM
To: <hecnet at update.uu.se>
Subject: [HECnet] Question for PyDECnet users
Gentlepeople,
Currently the details of what PyDECnet circuits connect to are not
displayed. So you can see that a Multinet circuit is up and the other end
is node 42.73, but you don't see the IP addresses or the like.
When things are working that's fine; when they are broken it might be
helpful to see what something is trying to talk to.
On the other hand, hiding IP addresses is arguably a security feature. So I
have this question:
1. Should the addressing info (basically, what's in the --device config
argument) be shown in the PyDECnet web interface?
2. Should the addressing info be visible via NCP / NML?
The difference is that #1 can be limited to be local only, if you use an
internal address for the web service. That's what I do for my nodes except
for the mapper, though perhaps there isn't a strong argument why it should
be so restrictive. #2, on the other hand, is visible to all HECnet users
assuming you haven't disabled NML in your config settings.
I'd be interested in comments. Am I too concerned about hiding information,
or is it sensible to be cautious?
paul
25 Sep
25 Sep
12:12 a.m.
I would echo the other's comments that making IPs visible is not a
concern, they're easily discoverable. There are better avenues to
protecting yourself rather than hoping no one sees you :-)
So my vote would be for #2
Mark
On 24/09/2020 22:15, Paul Koning wrote:
Gentlepeople,
Currently the details of what PyDECnet circuits connect to are not displayed. So you can
see that a Multinet circuit is up and the other end is node 42.73, but you don't see
the IP addresses or the like.
When things are working that's fine; when they are broken it might be helpful to see
what something is trying to talk to.
On the other hand, hiding IP addresses is arguably a security feature. So I have this
question:
1. Should the addressing info (basically, what's in the --device config argument) be
shown in the PyDECnet web interface?
2. Should the addressing info be visible via NCP / NML?
The difference is that #1 can be limited to be local only, if you use an internal address
for the web service. That's what I do for my nodes except for the mapper, though
perhaps there isn't a strong argument why it should be so restrictive. #2, on the
other hand, is visible to all HECnet users assuming you haven't disabled NML in your
config settings.
I'd be interested in comments. Am I too concerned about hiding information, or is it
sensible to be cautious?
paul
12:18 a.m.
Hi Paul et al.
I don't think there's any limit to the information that could/should be shown if
your https connection to pydecnet's web interface is authenticated.
I assume extra line parameters encoded into a NICE message coming back could convey the
actual physical details of the underlying 'line' in NCP's case?
As for security, the ports I open to let DECnet traffic through (Multinet over TCP, DDCMP
over UDP, bridge over UDP), there are ACLs associated with them so that all but specific
peers (individual IP addresses or small subnets) are dropped. The amount of port scanning
that goes on is insane!
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul
Koning
Sent: 24 September 2020 22:16
To: <hecnet at update.uu.se> <hecnet at Update.UU.SE>
Subject: [HECnet] Question for PyDECnet users
Gentlepeople,
Currently the details of what PyDECnet circuits connect to are not displayed. So you can
see that a Multinet circuit is up and the other end is node 42.73, but you don't see
the IP addresses or the like.
When things are working that's fine; when they are broken it might be helpful to see
what something is trying to talk to.
On the other hand, hiding IP addresses is arguably a security feature. So I have this
question:
1. Should the addressing info (basically, what's in the --device config argument) be
shown in the PyDECnet web interface?
2. Should the addressing info be visible via NCP / NML?
The difference is that #1 can be limited to be local only, if you use an internal address
for the web service. That's what I do for my nodes except for the mapper, though
perhaps there isn't a strong argument why it should be so restrictive. #2, on the
other hand, is visible to all HECnet users assuming you haven't disabled NML in your
config settings.
I'd be interested in comments. Am I too concerned about hiding information, or is it
sensible to be cautious?
paul
12:23 a.m.
Hi.
On 2020-09-24 23:15, Paul Koning wrote:
Gentlepeople,
Currently the details of what PyDECnet circuits connect to are not displayed. So you can
see that a Multinet circuit is up and the other end is node 42.73, but you don't see
the IP addresses or the like.
When things are working that's fine; when they are broken it might be helpful to see
what something is trying to talk to.
On the other hand, hiding IP addresses is arguably a security feature. So I have this
question:
1. Should the addressing info (basically, what's in the --device config argument) be
shown in the PyDECnet web interface?
2. Should the addressing info be visible via NCP / NML?
The difference is that #1 can be limited to be local only, if you use an internal address
for the web service. That's what I do for my nodes except for the mapper, though
perhaps there isn't a strong argument why it should be so restrictive. #2, on the
other hand, is visible to all HECnet users assuming you haven't disabled NML in your
config settings.
I'd be interested in comments. Am I too concerned about hiding information, or is it
sensible to be cautious?
Interesting question. For myself, I certainly do not care or worry. (I
sortof encourage the probing of Mim and Magica, since that helps iron
out any bugs in my TCP/IP.)
But I do want to respect if others would want to be more protective of
their information. So it becomes a little tricky.
It would be nice if individuals could tell how they would like it on an
individual basis. But I don't have any good suggestion at this time on
how to do it.
Finally, can you really stuff that information into the circuit
responses? Are there some free-text field available for this? (Doubt
I'll do anything in RSX right now, but if possible, it could maybe be
something I'd look into eventually...)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
12:51 a.m.
My 5-cents:
Make it a configurable option if the underlying IP-Addresses
should be visible or not, that way everyone can set the policy
they want.
-P
1:38 a.m.
On Sep 24, 2020, at 6:23 PM, Johnny Billquist <bqt
at softjar.se> wrote:
Hi.
On 2020-09-24 23:15, Paul Koning wrote:
Peter suggests a configuration option. That's easy as a global setting, and just
about as easy on a per circuit basis.
Gentlepeople,
Currently the details of what PyDECnet circuits connect to are not displayed. So you can
see that a Multinet circuit is up and the other end is node 42.73, but you don't see
the IP addresses or the like.
When things are working that's fine; when they are broken it might be helpful to see
what something is trying to talk to.
On the other hand, hiding IP addresses is arguably a security feature. So I have this
question:
1. Should the addressing info (basically, what's in the --device config argument) be
shown in the PyDECnet web interface?
2. Should the addressing info be visible via NCP / NML?
The difference is that #1 can be limited to be local only, if you use an internal address
for the web service. That's what I do for my nodes except for the mapper, though
perhaps there isn't a strong argument why it should be so restrictive. #2, on the
other hand, is visible to all HECnet users assuming you haven't disabled NML in your
config settings.
I'd be interested in comments. Am I too concerned about hiding information, or is it
sensible to be cautious?
Interesting question. For myself, I certainly do not care or worry. (I sortof encourage
the probing of Mim and Magica, since that helps iron out any bugs in my TCP/IP.)
But I do want to respect if others would want to be more protective of their information.
So it becomes a little tricky.
It would be nice if individuals could tell how they would like it on an individual basis.
But I don't have any good suggestion at this time on how to do it. Finally, can you really stuff that information into
the circuit responses? Are there some free-text field available for this? (Doubt I'll
do anything in RSX right now, but if possible, it could maybe be something I'd look
into eventually...)
Yes, no problem. That's why there are implementation specific parameter code ranges
available. There is one in use already by PyDECnet, circuit counter 3900, "Seconds
since last circuit up", a 16 bit counter. Parameters like this can go in that range
as well, and thanks to the NICE protocol encoding the data format is explicitly stated.
So strings will show up as text, and integers as integers.
paul
1:56 a.m.
Peter suggests a configuration option. That's easy
as a global setting,
and just about as easy on a per circuit basis.
It seems like the option to disclose my IP would have to be on the end
that I'm connecting to. In other words, the other guy has control over
displaying my IP, not me. As I said I don't mind, but this might not be
what people expect.
Bob
2:13 a.m.
On Sep 24, 2020, at 7:56 PM, Robert Armstrong <bob
at jfcl.com> wrote:
Yes, that's true. The primary parameter of interest is the remote address, so control
of whether to expose that would be at the other end.
I do have documentation, even though I admit it's not as clear as it should be.
(Comments etc. on the documentation are welcome just as comments on the software and
functionality are.)
paul
Peter suggests a configuration option.
That's easy as a global setting,
and just about as easy on a per circuit basis.
It seems like the option to disclose my IP would have to be on the end
that I'm connecting to. In other words, the other guy has control over
displaying my IP, not me. As I said I don't mind, but this might not be
what people expect.
Bob
2:33 a.m.
On 2020-09-25 01:38, Paul Koning wrote:
I'm sortof ok with that, but the problem is that you need to note it for
each circuit, based on what the other side prefers. It would be nicer if
possible to handle a bit more automatically.
But I don't really see, at the moment, how to do that. I was thinking
about some special pattern to the circuit name, but that fails for the
same reason - it's what the other side thinks we need to know, not our own.
Ah. So you just add an implementation specific parameter. Yes, of
course, that always works. But for any system not knowing them, they
will show up slightly funny, but perfectly readable. I thought maybe
there was already some field defined/existing.
NICE is otherwise a fairly good protocol.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Sep 24, 2020, at 6:23 PM, Johnny Billquist
<bqt at softjar.se> wrote:
Hi.
On 2020-09-24 23:15, Paul Koning wrote:
Peter suggests a configuration option. That's easy as a global setting, and just
about as easy on a per circuit basis. Gentlepeople,
Currently the details of what PyDECnet circuits connect to are not displayed. So you can
see that a Multinet circuit is up and the other end is node 42.73, but you don't see
the IP addresses or the like.
When things are working that's fine; when they are broken it might be helpful to see
what something is trying to talk to.
On the other hand, hiding IP addresses is arguably a security feature. So I have this
question:
1. Should the addressing info (basically, what's in the --device config argument) be
shown in the PyDECnet web interface?
2. Should the addressing info be visible via NCP / NML?
The difference is that #1 can be limited to be local only, if you use an internal address
for the web service. That's what I do for my nodes except for the mapper, though
perhaps there isn't a strong argument why it should be so restrictive. #2, on the
other hand, is visible to all HECnet users assuming you haven't disabled NML in your
config settings.
I'd be interested in comments. Am I too concerned about hiding information, or is it
sensible to be cautious?
Interesting question. For myself, I certainly do not care or worry. (I sortof encourage
the probing of Mim and Magica, since that helps iron out any bugs in my TCP/IP.)
But I do want to respect if others would want to be more protective of their information.
So it becomes a little tricky.
It would be nice if individuals could tell how they would like it on an individual basis.
But I don't have any good suggestion at this time on how to do it. Finally, can
you really stuff that information into the circuit responses? Are there some free-text
field available for this? (Doubt I'll do anything in RSX right now, but if possible,
it could maybe be something I'd look into eventually...)
Yes, no problem. That's why there are implementation specific parameter code ranges
available. There is one in use already by PyDECnet, circuit counter 3900, "Seconds
since last circuit up", a 16 bit counter. Parameters like this can go in that range
as well, and thanks to the NICE protocol encoding the data format is explicitly stated.
So strings will show up as text, and integers as integers. 
3:48 a.m.
On 2020-09-24
23:15, Paul Koning wrote:
Peter suggests a configuration option. That's easy as a global setting, and just
about as easy on a per circuit basis.
2:07 p.m.
On Sep 24, 2020, at 9:48 PM, David Moylan <djm at
wiz.net.au> wrote:
I think the more information that's available in the PyDECnet webui the better, but I
also think a configuration option to enable/disable would be appreciated and would fit the
use case of most users.
Thanks. Yes, I'll aim for that. Probably not in the next drop but soon after.
On
2020-09-24 23:15, Paul Koning wrote:
Peter suggests a configuration option. That's easy as a global setting, and just
about as easy on a per circuit basis. One thing that would be super cool is to have the
ability to actually edit the configuration within the webui itself. Of course there would
have to be an authentication required to do so.
The thought this spawns from would be the ability to change a circuit configuration, or
adding in a new circuit without fully restarting PyDECnet itself.
I was just thinking a few weeks ago while I was trying to get Multinet authentication
going between my home and my office - which turned out to be a few different things - but
that I was constantly stopping and starting PyDECnet while the only real change was one
specific circuit.
Not a real deal breaker - but if you were putting things on your development radar, the
ability to restart PyDECnet without breaking active connections would be nice.
It's on the radar, definitely. Not a simple change though. The current design builds
everything at startup. Changing parameters is typically not all that hard; adding and
removing things is a different matter. Some cases are still straightforward, like adding
or deleting node name/address entries. Adding or deleting circuits at run time is more
complicated, though doable in principle.
The right answer is likely to do it in pieces. First is access control, then parameter
change for existing objects, last the add/delete cases.
paul
1315
days inactive
1316
days old
12 comments
8 participants
participants (8)
-
bob＠jfcl.com -
bqt＠softjar.se -
djm＠wiz.net.au -
Keith.Halewood＠pitbulluk.org -
mark.curtis＠aardvarks-and-platypus.com -
paulkoning＠comcast.net -
roll＠stupi.com -
supratim＠riseup.net