IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/03/21
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+orignal
+weko
Irc2PGuest89954
Leopold_
Onn4l7h
Onn4|7h
T3s|4_
aargh2
anon2
cancername
eyedeekay_bnc
hk
not_bob_afk
profetikla
shiver_
u5657
x74a6
zzz java.lang.IllegalArgumentException: TODO
orignal was able to decrypt SessionCreated
orignal AEAD failed
orignal but it's about lenght of payload
orignal decrypted SessionCreated
orignal 4 blocks
orignal and one unknown block of type 17
zzz for next time
orignal so is it right block?
zzz that's what the spec says, but we can talk about it. I put it in there because it's easy and there's plenty of room
zzz but it could also go in the first ack I guess. Or with termination. or both.
orignal so I'm done with SessionCreated
orignal will implement SessionConfirmed probably today
zzz fantastic
orignal Noise works fine so far
zzz 0) Hi
zzz what's on the agenda for today?
orignal SSU2 as usual
zzz ok SSU2 is 1); what else?
zzz eyedeekay, will you have a wikipedia update for us today?
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 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 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
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.
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
zzz anything else on 1) ?
zzz anything else for the meeting?
orignal not from my side
zzz one more thing from me...
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
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.
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
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 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 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