Text 312, 106 rader
Skriven 2005-05-15 13:08:46 av Peter Knapper (3:772/1.10)
    Kommentar till text 303 av Val Khokhlov (2:463/180)
Ärende: Ballot form
===================
Hi Val,

 PK> While I can see the advantage of this, in reality it has nothing to do
 PK> with the transport of Mail, and Fidonet (or the FTSC) should stay
 PK> completely away from that one...
 vk>         not exactly so. new storage might lead to some 
 vk> changes for packet/message format. 

Well the bit you didnt quote was about using SQL, which I took to mean the
local storage of messages. Fidonet was built on the store and forward
principle, and Fidonet was not really too interested in the store part of that,
but Fidonet very much IS interested in the forward part of it. One just has to
isolate the STORE from the FORWARD........;-)

Maybe I read your comments wrong, but if you want to tie SQL into the transport
mechanism of Fidonet I think you have a hard road to walk, far too many systems
would be affected by that sort of approach. And then I wonder why we are doing
all this, after all, Fidonet is supposed to be a hobbyist Network. When does a
Hobby stop being a Hobby???

 vk>         anyway, it's too early to speak about standards 
 vk> :) we need to create software first.

At least as far as Fidonet is concerned you got that bit right, which is more
than a lot of folk out there......;-)

 vk>> 2) routing automation,
 PK> This would have been nice 10 years ago, but with so many nodes moving to
 PK> IP connectivity, point-to-point traffic is 
 PK> becoming very much the norm,
 vk>         you see, p2p in fidonet is not-so-desirable 
 vk> because there're no effective auth schemes. 

Yes, Fidonet is weak on p2p security, but that is primarily a trade off from
the early days when the average PSTN based node only had a few "regular"
connections, and management of those connections was reasonably simple. With
simple IP end-to-end connectivity being available now, connection security is
quite a different picture. However, I still think it is VERY important that
individual Sysops can control un-solicited traffic, and I don't see how you are
going to automate anything there without breaking either P4 or Fidonet Sysop
confidence in how the Network works (IMHO).


 vk> with password auth you can't do p2p (well, you need to 
 vk> specify password for each link). 

Or a method of handling real-time authentication (for those Nodes that wish to
use it). This sort of thing almost becomes a can of worms...

 vk> so, in order to use 
 vk> p2p we need some pka scheme ([open]ssl seems reasonable 
 vk> to me).
 vk>         but it's for ip-nodes. for pstn, routing is 
 vk> rather big problem in large networks. there's software 
 vk> for routing automation (e.g. safrouter), but i don't 
 vk> know any good way to make routing fully automatic 
 vk> (which includes creating routing maps, distributing and 
 vk> using them)

I don't think Routing Automation for PSTN would be a good thing. Routing
simplication, yes... that could be useful, but automation, I am certainly not
sure about that...

 PK> Yes to public-key for session/pkt traffic,
 vk>         securing traffic is a minor feature. the main 
 vk> advancement is validating a remote system. with node's 
 vk> certificates and revocation lists we can effectively 
 vk> use p2p connections.

However this can go too far (IMHO). One of the base tenants of Fidonet is that
MESSAGES are not endoded, so that HUBS and main nodes can view what is going
through their system. Point-to-point operation allows for this to be ignored
PROVIDED both end points agree to it. We would need to ensure this basis was
not disturbed...

 PK> but digital signatures for messages... again this 
 PK> is not something to do
 PK> with Fidonet or mail transport.
 vk>         one can sign his messages with pgp/gnupg now. 
 vk> it's not a fidonet issue.

Agreed.

 vk> the fidonet problem is we don't have authoritative 
 vk> source for sender's address.

That can only be achieved by P2P connections, and authenticating the end
points. Again, this would be quite hard to do automatically, without breaking
existing methodologies. 

It almsot sounds like a complete re-design of the Fidonet transport environment
needs to be done to solve all these issues, but then why re-invent the wheel
when it already exists???

 vk>         but once again i want to say - i don't mean 
 vk> creating proposals before software, of course.

Of course, that goes without saying.........;-)

Some good thoughts there Val.

Cheers............pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)