#i2p-dev (irc2p) | 2.9.0-5

zzz reminder: Proposal 160 review today 7 PM UTC #ls2

orignal zzz, if we receive an updated LS from racthets session do we need to verify signature?

zzz don't know. I verify all sigs

orignal then let's think

orignal it's truly router's side no I2CP inviolved

orignal I don't see a way how an LS can be forged in this scenario

zzz it seems like you're working on some big project to remove various checks for things that come over ratchet? I'm not really prepared to offer advice on that, not sure where you're headed

orignal not a big project really

orignal one change inspires another idea

orignal say I was working on removing signatures verification due to PQ

orignal then I started thiking about LS

orignal the whole idea is that an established ratchets session has many verifications already

orignal through the static key

zzz it's an interesting topic but I think it needs to be researched top-down, I'm not comfortable offering advice on tiny parts of it

zzz the topic is: Noise IK Ratchet offers certain security guarantees that old ElG+tags didn't ...

zzz what are those security properties, and if we attached that guarantee to messages as they went thru the router, what efficiencies or protocol changes at other layers are possible ...

zzz what can we do by signalling message provenance to other protocol layers, is that possible, can it be made secure ...

zzz can it be bypassed, does it open up other attack vectors, does it threaten protocol stack separation or introduce messy protocol 'layering violations'

zzz these issues apply whether crossing the I2CP boundary or not

orignal right, but LS is definitly now

orignal *not

zzz in theory we can have these security guarantees cross the I2CP boundary, it's just another protocol to modify or bridge

orignal well for now the only way I see now is to pass static key through I2CP

zzz the trick is to reason about the ratchet identity guarantees... which are about static keys... to the identity concepts in most of the rest of the router, which are about destinations/hashes

zzz and the LS is the bridge between those two

zzz and it's not one-to-one, there can be multiple keys for a dest, and multiple dests for a key

zzz so when we replaced ElG with Ratchet, we got some new security guarantees that perhaps we haven't taken advantage of, because we didn't fully understand it at the teime, or because it would require a huge redesign to do so

orignal you can have multiple LSes through the same sessions, but all of them must contain this static key

orignal futhermore static key for current crypto type

orignal also why do we need to send whole LS update through rachets rather than tunnels list only like in I2CP?

zzz can't help with brainstorming right now

zzz I just merged PQ ratchet, it doesn't compile due to a missing file, but I have to fix local merge conflicts first

thirtyseven test

thirtyseven thank you for voice

thirtyseven since the last time when i was told about i2ptunnel, do i understand right that it is the i2ptunnel itself that exposes i2p tunnels to the local ports, not the i2p router itself being ordered by i2ptunnel to do so?

thirtyseven so it is: 1.i2ptunnel requests i2p tunnel 2.i2p tunnel stays connected to it 3.i2ptunnel exposes a local port to connect to the tunnel

thirtyseven it is NOT: 1.i2ptunnel sends a request to create tunnel to i2prouter 2.i2p router creates the tunnel 3.i2ptunnel

thirtyseven is that correct?

thirtyseven 3.i2ptunnel terminates*

orignal should be done through i2pcontrol in my opinion

thirtyseven i agree

zzz right 37. the router does router things. i2ptunnel is a client-side application

thirtyseven ah yes, thx now it makes more sense

orignal can we create an i2p tunnel through ipcontrols?

thirtyseven from what im reading in the documentation, i2pcontrol is only meant for things that have to do with router itself, stats, open tunnels, peers info, decline transit and similar, and i2p control is probably expected to be used with a password if im correct?

orignal *i2pcontrol

orignal I asked this question few years ago

orignal if it's worth to add such command

thirtyseven if i assume right that there is no option do do that, i think the reason that i2pcontrol does not provide capability to make client tunnels exposed on local ports is because then if every application was supposed to be accessign i2pcontrol, then every application had full control of i2p router.

thirtyseven i think there should absolutely be a simple plaintext interface for managing i2p client and server tunnels exposed on local ports. but it seems there is no such thing. and instead to create tunnels exposed on local ports, we need to make a separate process that will expose tunnels that it makes with sam or another interface on desired local ports.

thirtyseven we almost have this but only for server tunnels, with SAM, the FORWARD command

thirtyseven but it is omitted for client tunnels, and they cannot be exposed on a local port easily like this

eyedeekay Pretty sure you can do point-to-point like a standard tunnel with FORWARD, right?

thirtyseven according to SAM documentation a server tunnel can be forwarded to a local port. but nothing is said about creating a client tunnel connected to a predetermined destination that can be accessed on a local port by an i2p-unaware application. my conspiracy theory that i made up is that this could be to prevent people from making too many destinations too easily?

eyedeekay Nah. Super easy to make dests with SAMv3 regardless

orignal if remember BOB allows this

orignal like bind to particular port etc.

thirtyseven BOB almost allows this, but you still need to send *.b32.i2p address in the beginning to initiate the connection, then the server gets client's pubkey sent to it and then they can communicate.

thirtyseven so there is still need for some middlemant to initiate the connection

thirtyseven middleman*

zzz this is all fairly pointless because it's for OP's use case of a preconfigured far-end dest ("standard tunnel") and a i2p-unaware, sam-unaware application connecting to a localhost port

zzz that's a very nice use case. In the real world, 99% of the time the app wants to tell the proxy where to send the data to, with SAM, or SOCKS, or HTTP proxy, or BOB, ...

thirtyseven Nah. Super easy to make dests with SAMv3 regardless -dests can be made, and they can accept connections and forward them to a local port, but i can't find out a way to do the opposite, aka make a dest, connect it to another dest, and then have this tunnel be exposed on local port to access by a client.

zzz that's why OP's feature is not in i2pcontrol, or SAM, or ...

eyedeekay That is why I thought i2ptunnel cli was a better fit

eyedeekay Because if you want to do that with SAMv3 you end up reinventing i2ptunnel

thirtyseven didn't you do that with go?

thirtyseven or someone else

thirtyseven this is absolutely no pointless. expecting everybody to develop new apps native for i2p is alot

eyedeekay Yes. Several times in fact

thirtyseven yea, were a few repos

thirtyseven not pointless: if what im talking about was a thing, you could just ship any i2p unaware app with a small script to quickly request a tunnel and connect the app to it.

eyedeekay The old one is sam-forwarder and the new one is go-i2ptunnel and there are about a dozen specialized tunnel like things

thirtyseven entire internet could be running on i2p

zzz ok then 37, tell us the application for programmatic standard tunnels, because I haven't heard it yet

eyedeekay You can literally do that with i2ptunnel cli

thirtyseven i2ptunnel cli would be fine, if it wasn't for the need to suddenly have java installed

thirtyseven go would be fine too, wouldn't it need internet connection to build

eyedeekay Hm. If that's a dealbreaker then maybe sam-forwarder is a better fit, go-i2ptunnel is much nicer but a WIP

thirtyseven osmt

eyedeekay One of the "special tunnels" that I mentioned earlier is a go modules proxy so you could do all the go get stuff anonymously

thirtyseven isn't sam forwarder also in go?

eyedeekay Yup

eyedeekay It's just ancient and messy

thirtyseven i wouldn't mind, if it was just normal to build it offline

eyedeekay The actual 'forwarder' doing the work is pretty simple, might be possible to yank out the tunnel you need and pare the requirements down to stdlib

eyedeekay Recv on socket A, write to socket B, etc

thirtyseven yea, i don't hate forwarder solution, my issue is only dependency on java or on internet connection to build it

thirtyseven i mean, i did a run through almost all i2p interfaces, and i could not believe there is no api alternative to webinterface/config, feels so wierd to me how someone can think this is not useful.

eyedeekay You might have to build what you need but all the pieces are available, I would just bring a SAMv3 library into /vendor then check in the vendor files, bam, offline

thirtyseven would be so easy to just ship anything with small script to request a client tunnel without implementing sam or bob natively

zzz still waiting for a use case for non-java programmatic _standard_ tunnels (aka configured for a single far-end dest)

thirtyseven you could just drop in a single line of code into application's code to request a client tunnel. this would be so much simlper to implement instead a full blown sam communication.

thirtyseven i just said the usecase.

thirtyseven i guess

eyedeekay sam-forwarder exists because I think this is useful. I am focused on router level stuff in go-i2p at the moment but go will support exactly this

thirtyseven any app could open a socket, or even call an external command, and send a config string to open a tunnel for itself.

eyedeekay I can finish go-i2ptunnel without a go router though

zzz no 37, because building new tunnels for every far-end is dumb. That's why proxies like socks and http exist, and why we support torsocks, and and and

thirtyseven support torsocks -sounds cool

eyedeekay torsocks already works

orignal why is it dumb?

eyedeekay If that helps you

orignal you don't want to connect to diffent addresses from the same dest

orignal otherwise you might be tracked

thirtyseven already works: not all i ever wanted but still cool to know, thank you

thirtyseven original this^

zzz any proposal to do the same thing in go is just another proxy, or a wrapper around sam. He wants to make SAM or i2pcontrol into something it's not, or wants somebody else to do the work to implement his vision

eyedeekay If he wants my sam-forwarder code he can have it, or contribute to go-i2ptunnel instead. I didn't and don't intend to work on go-i2ptunnel over router features until at least September

eyedeekay But wrappers around SAM that do this are not challenging

thirtyseven i just imagine that if adding i2p functionality to any application was as simple as calling a single command before it's start or even from inside of it, and passing tunnel config in it, it could help i2p adoption. and yes, i am not fully awar of how hard it is to the network, but having separate destination per application seems natural.

dr|z3d torsocks is the answer.

zzz dumb because there's no specific application or threat model offered, and no justifcation other than handwaving about "entire internet on i2p" if we had it

eyedeekay It's actually a little complicated at that level, which is what "context aware http proxies" is about

thirtyseven i2p is extremely valuable not only because of security. but also because it allows anyone to host anything

thirtyseven regardless of their type of internet connection, closed behind nat or not

eyedeekay \/context/host/

thirtyseven make a server of a game

thirtyseven accesssible from the internet

thirtyseven or serevr of a website

thirtyseven or anything else

thirtyseven ^host^

thirtyseven most people can't just a run server, forward a port and have others connect to their computer, because of gimped internet connection, and even if they can then they are exposing their home ip address to the world, which is kinda crazy and noone watns to do that.

thirtyseven i2p, solves both of those problems marvelously, and this is in my opinion it's primary wonder.

eyedeekay just dest-linking only get you contemporary association though, you have to have a stable identifier(account) to do shadow profiling

thirtyseven wat?

eyedeekay Nevermind, speaking about the host aware proxy proposal and about shared tunnel association

thirtyseven continuting what i said: and now, in order to host and connect all the stuff that you can host or connect with i2p, it is very useful to have a simplest way possible of requesting tunnels on local ports.

thirtyseven ah, yes. separate identities on socks, would also be cool.

thirtyseven but yea again i am aware of the concern with increased load on the network, but is it certain how far can it actually be pushed.

thirtyseven i suppose we would have to experience more cpu load when running i2p.

eyedeekay Not sure it's the best way for socks, that's in the proposal too, and yes the network overhead is probably the biggest concern. But on the topic of a simple tunnel configurer, those exist, I know the go ones but there are probably others as well

thirtyseven i saw some old thing written in c++, but unfortunately it didn't build

thirtyseven was looking for those, and i found your go ones, and this one

eyedeekay My suggestion remains, the actual tco forwarder in sam forwarder is like 90 lines long. Copypasta

eyedeekay *tcp

thirtyseven but i mean currently it is not that much cpu use for i2p, let's say we could probably get use the cpu that windows is normally eating up just for running, but for something useful

thirtyseven get away with using the cpu that windows is normally...*

thirtyseven they were creating alot of destinations?

thirtyseven or something else it was?

thirtyseven they were like spamming extremely. i2p weather was bad, shit kept disconnecting, but it i2p could be expected to handle it worse than it did.

eyedeekay That was one of them, also requesting lots of tunnels

thirtyseven yea

thirtyseven i2p got a strong stress test.

thirtyseven was getting kindof unstable. but this suggests it could handle a few more destinations. that there would also be more genuine network participants unlike during the attack.

thirtyseven and there would also*

thirtyseven that and* there would also*

eyedeekay We don't know much about the constraints the ddoser was operating under, lots we don't know. Maybe? Probably? But difficult to be sure.

thirtyseven probably he had big machine to destinatino ratio

thirtyseven one thing that alsco crossed my mind when trying to do this stuff with BOB was what if BOB could just pass the destination string automatically to itself, and just don't dup the pubkey on the other side?

thirtyseven don't dump the pubkey*

thirtyseven but could we then still connect several clients to a single localhost tunnel on which BOB tunnel is listening?

eyedeekay No idea, never touched bob

thirtyseven i did, honestly i liked it alot

thirtyseven alot simpler than sam

thirtyseven feels almost like using some regular command line utility

thirtyseven like, i2pd expanded BOB functionality with some new features, what if there could be an option like "preconnect" or just respect the key destination=*.b32.i2p for the command "option"

thirtyseven yea, maybe BOB could decide where to connect by a BOB command.

thirtyseven now that would make bob have almost the same abilities as tunnels.conf/webui

thirtyseven Ok, thank all of you guys for all the answers and clarifying some things for me. I understand the situation better now.