#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

eyedeekay Nothing from me this week, just catching up to code, no substantial progress on the wikipedia thing yet, we haven't been able to determine if it's the classifier thing yet

zzz ok, thanks

zzz 1) SSU2

zzz orignal, I assume most of your status is above ^^^, anything else?

orignal yes,

orignal I would to discuss unpublished addresses

orignal because I see some hole

orignal SessionConfirmed and then data

orignal very close to it

zzz yeah, you're moving quickly

zzz ok then. my status:

orignal yesplease

zzz I've been starting to code Peer Test and fix up the docs on peer test. slow going, all untested, will be a while

zzz low priority

zzz re: tokens, I looked at the QUIC docs

orignal yes

orignal good question

zzz they bind only to IP. We want to bind to IP/port, which should be fine, because outbound port is fixed also

zzz so I'm going to redo my caches to use IP/port for both outbound and inbound

orignal and we might run multiple routers on the same IP

zzz right

orignal so, by endpoint only

zzz correct

orignal then I'm ready to request tokens first

zzz I'm also researching using an "opaque token" which is a siphash of ip/port/timestamp or something

orignal because tokens are not implemented yet on my side

zzz so I don't have to remember what tokens I give out

zzz but I don't know how to do that and still prevent token reuse

zzz just an implementation idea, for now

orignal how can it be reasued

orignal other side shoudl verify it

zzz tokens are opaque to the other side

orignal ofc it must include endpoins of both sides

zzz other side doesn't know what it "means"

zzz so it could be, for example, siphash(ip, port, current hour)

zzz but then you can't prevent it from being used again

orignal I know what you mean

zlatinb in Limewire we encrypted tokens with symmetric cypher with key known locally

zlatinb then when receiving a token back we just decrypted and checked if valid

zzz yeah, siphash is just a faster version of that zlatinb

zzz the trick is to somehow remember it was used so somebody doesn't try to use it again

zzz for further research, fyi only

zzz next status item for me:

zzz my outbound connections exploded today, because my IPv6 became firewalled, and that made my RI too big with introducers

zzz even gzipped it was over 1400 bytes

zzz and so didn't fit in the session confirmed

zzz and splitting the RI across two messages is not quite specified and unimplemented

zzz it's a mess

zzz so one idea I had last week was making the padding in the router identity more compressible. not a general solutionm but might help long term

orignal so what are we going to do?

orignal I have better idea

zzz well, what the spec says, if the RI is fragmented, don't accept any I2NP messages until you get the rest of the RI

zzz it's just a state machine problem

orignal replace 256+128 to 32+32

orignal and without cert

zzz that's my idea I discussed with zlatinb here a few days ago

orignal use some "short" version

zzz it's not really 32 + 32, it's 32 + (10x repeating pattern) + 32

zzz so it gzips nicely

zzz the "real" ident is still 391 bytes; but it gzips down to about 100

orignal yes it makes sense

zzz but even then, the full RI could still be bigger than the MTU

orignal but it means you want compressed RI block

orignal remeber it's uncomressed in NTCP2

zzz we do have a compressed RI block now... it's in the SSU2 spec... I saw this problem coming months ago...

orignal how about NTC2?

zzz even with compression, I still went over 1500 this morning

zzz no, not in NTCP2

orignal good

zzz I added an extra flag byte to SSU2 RI block

zzz for 1) fragment and 2) gzip

zzz something like that, don't remember exactly

zzz SSU 1 specified router identity fragments, which was dumb, because router identity was only 387 bytes back then

zzz but now we have full router info in session confirmed.

orignal yes

zzz so, another open issue. I need to go back and read what I wrote in the spec

orignal we didn't send RI in sessionconfirmed

zzz and look at the code to see how hard it would be to fragment

orignal and we should now to verify s

zzz right, SSU 1 only had router indentity, not full router info

zzz so if you don't have full router info in session confirmed, you can't verify that s matches

orignal basically you can

zzz I don't want to specify something that's ugly to implement, so I want to think about it more

orignal you can send identity + s + signature

zzz kinda like SSU 1 again

orignal I would prefer full RI

zzz agreed

zzz lets put it on the list for next week

zzz and I think that's the end of my status

orignal yes

zzz anything else on 1) ?

orignal no

zzz anything else for the meeting?

orignal not from my side

zzz one more thing from me...

orignal yes?

zzz I've been thinking about doing a 4-6 part tweet about SSU2

zzz saying it's one of the most secure and blocking-resistant protocols ever designed

orignal 4-6?

zzz but maybe that's going too far

orignal I would say it

orignal it's just better than SSU

zzz basic theme: SSU1 has been around for 17 years, almost never been blocked that we know of

orignal because solves many problem

zzz but we can do better. much better.

orignal yes

eyedeekay Might get us a free audit if you overstate it

zzz taking the best of noise, wireguard, QUICK, 25519, blah blah blah

orignal but I'm not sure if it would be better than NTCP2

zzz ha

orignal NTCP2 is too good now

zzz my theory is that UDP is more censorship-resistant

zzz because great firewalls can't deal with it very well

orignal oh just remebered something

zzz look at tor still getting blocked by everybody

orignal what do you think about mtu of 64K?

zzz for ygg?

orignal yes

orignal SSU2 over ygg with 64K mtu

zzz I thought udp didn't work over ygg

orignal can be tranferred a lot

orignal it worked but bad

orignal seems working now

zzz or there was no point to udp over ygg

zzz even if it did work

orignal both

orignal no point and didn't work well

zzz but sure, we could make special rules for ygg

orignal NTCP2 was easier

zzz no objections

orignal but 64K datagram can give bunch of profit

orignal but it's later

orignal 64K frames for NTCP2 works well

zzz yup

zzz agreed

zzz if you need me for SSU2 testing, mornings or early afternoon will be best

zzz zlatinb, I also need to follow up with you this week on my RTT/ack delay simulations and testing

orignal not now

orignal I will let you know

zzz anything else for the meeting?

zzz thanks everybody, happy testing