I can configure my system to accept a connection from a host with a dynamic address since
I can limit the port to the range of possible addresses instead of opening it to the
world. I would probably want to configure the circuit to use a routing initialization
password, however. Let me know if interested.
Mark Berryman
On Apr 4, 2019, at 6:03 PM, Paul Koning <paulkoning
at comcast.net> wrote:
On Apr 4, 2019, at 6:32 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2019-04-04 15:28, Paul Koning wrote:
On Apr 4,
2019, at 7:53 AM, Supratim Sanyal <supratim at riseup.net> wrote:
On 4/4/19 6:12 AM, Keith Halewood wrote:
> Hi,
> I'm pretty sure that a TCP listen doesn't care who connects to it on VAX
Multinet. UDP is a different matter.
> For example, there's a listener device set up with a 1.1.1.1 address on DUNE
here. PIVAX0 connects to it from a completely different address. I use access controls on
the router to restrict just who is allowed to connect to it.
> If you want I can set up another incoming line/circuit and you can connect to it.
I'm in area 29 FYI.
I have listeners waiting on 0.0.0.0. Yes, MULTINET does not seem to care what address
connections come in from.
Does that mean anyone can connect to HECnet without any
authentication? Or is DECnet node init authentication used?
"Security by obscurity" only goes so far. Is it good enough for HECnet?
So far that's mostly what we have, yes.
I have from time to time considered maybe adding a password on the link, as DECnet do
support that.
But so far, there has never been a single instance of someone actually trying to connect
some unknown node with DECnet on any link of mine. But it is most likely just because
pretty much any remote script-kid just have no clue that DECnet even exists, what to do
with it, or anything else.
Also, the worst I think anyone could do would just be disrupting DECnet. But maybe
someone else can think of anything else potentially interesting someone could do by
hijacking a circuit.
The worst you could do is what was done with BGP in the past: create a route diversion
that sends a pile of the traffic to a rogue router. Most of that traffic would not be all
that interesting, I suppose.
My biggest issue with those link passwords in RSX
is that I think I can only have one password, and it will be applied to all links. And I
also think that maybe I had to turn it on on all links if I turn it on on any.
But if people are willing to experiment some, we could test enabling it.
For RSTS, the password to use is a node attribute, so you specify what password to send
to and expect from a given claimed neighbor node. (RSTS doesn't support Multinet or
GRE, though -- but it does support DDCMP which is a fine way to offer point to point links
over TCP.) And of course for routers we build we can make the flexibility whatever we
care to code.
paul