IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/12/12
@eyedeekay
+R4SAS
+RN
+T3s|4
+Xeha
+acetone
+orignal
+weko
Hikari
Irc2PGuest67835
Irc2PGuest97144
Leopold
Minogami
Onn4l7h
Onn4|7h
T3s|4_
anon4
eyedeekay_bnc
idk
j6
not_bob_afk
profetikla
qend-irc2p
u5657
x74a6
x74a6h
zer0bitz
dr|z3d 90.243.28.77:13833 appears to be sending corrupt Session/Token requests.
dr|z3d dunno if that's interesting at all.
dr|z3d yeah, maybe not so much. 0.9.54, no ssu2.
dr|z3d that's slightly off the charts insane, one of stormycloud's outproxies spiking at just under 36MB/s
zzz that's total network i2p+clearnet sides?
dr|z3d that's just i2p+ network traffic, aggregate. mostly not outproxy traffic from the looks of things.
dr|z3d looks like it may correspond to our network abusing friends.
dr|z3d that's the first time I've seen the traffic correlate with the tunnel spikes.
zzz I don't think the abuse actually contributes that much bandwidth, build messages are < 1K now, but if you've tuned the throttles to be more permissive than canon, that's what you'll get
dr|z3d I get the participating tunnel spikes. What's new is the bandwidth spikes, which on the graphs broadly line up with tunnel spikes.
dr|z3d And I don't think I've ever seen 30+MB/s on a graph which indicates that it's being sustained for a minute.
dr|z3d It's not all bad. Impressive that the router can handle that much traffic without much bother.
dr|z3d in canon, isn't the max b/w capacity for a single tunnel 8MB/s?
zzz dunno
dr|z3d I vaguely recall that being the limit.
dr|z3d Might have that totally wrong, though. So I dunno either.
zzz ofc you can see per-tunnel bw on /tunnels
dr|z3d yeah, by the time I noticed the spikes had been and gone, so not seeing anything ridiculous there right now.
dr|z3d max ~ 70Kb/s for part tunnels. nothing special.
dr|z3d *KB/s
dr|z3d I may yet batten down the throttle hatches, but for the time being the impact doesn't seem hugely detrimental to router performance.
dr|z3d orignal: you don't throttle participating tunnel requests do you?
zzz wooty woot I got peer test bob trying multiple charlies working!
zzz 16:05:43.643 Got peer test msg 1 status: 0 from 183.171.22.189:48095 xIEbxF IB2
zzz 16:05:43.643 Send Alice RI and msg 2 to charlie Charlie: /84.234.96.38:19202
zzz 16:05:43.684 Got peer test msg 3 status: 70
zzz 16:05:43.684 Charlie response 70 picked a new one 141.148.237.212:11222 EugHAW IB2
zzz 16:05:43.705 Got peer test msg 3 status: 68
zzz 16:05:43.710 Charlie response 68 picked a new one [2001:470:1f0a:716:0:0:0:2]:29082 RZOdsy OB2
zzz 16:05:43.784 Got peer test msg 3 status: 0
zzz 16:05:43.784 Send Charlie RI to alice on PeerTest 899121178
zzz 16:05:43.785 Send msg 4 status 0 to alice on PeerTest 899121178
dr|z3d good stuff, zzz. smells like progress!
zzz baby steps, lets clean it up and push it over
orignal no I don't
orignal zzz will check
zzz next problem, haven't seen on .56 yet though:
zzz handshake, I'm alice, i2pd 0.9.55 bob:
zzz 12-12 16:03:06.216 WARN Got out-of-order Retry on: OES2 A56gjh 70.113.47.159:26669 lifetime: 7s
zzz (42 more!)
zzz 12-12 16:03:13.340 WARN Got out-of-order Retry on: OES2 A56gjh 70.113.47.159:26669 lifetime: 14s
zzz 44 retries in 7 seconds
zzz I'm having a lot of trouble dealing with retransmitted token requests and retries. Trying to straighten it all out
dr|z3d orignal: we're seeing one or two routers on the network making obscene amounts of requests in a very short period.
dr|z3d that's why I asked about throttling.
orignal maybe badwidth
orignal real bandwidth I mean
dr|z3d earlier today I witnessed part tunnels on a router go from 5K to 11.5K in around 10 minutes.
dr|z3d I had to relax the max part tunnels limit on the router to let it play out, max was 10K before I upped it.
dr|z3d bandwidth. you'll like this. just shy of 36MB/s seen on one of stormycloud's outproxies earlier today, spiking several times in a very short interval.
dr|z3d not outproxy traffic, part traffic.
orignal what is "out or order Retry"?
dr|z3d a retry message before the original message has been received.
dr|z3d oh, then I'll let zzz explain.
zzz a retry after I already got a retry and sent a session request
zzz they should be ignored, unless containing a termination, but I wasn't...
zzz one of many things I'm trying to fix
orignal maybe your token was wrong in new request?
orignal now please tell me why min size is 88?
orignal I see it's 87
zzz because with header encryption also encrypting the eph. key
zzz from the spec:
zzz Payload
zzz ```````
zzz - DateTime block
zzz - Options block (optional)
zzz - Relay Tag Request block (optional)
zzz - Padding block (optional)
zzz The minimum payload size is 8 bytes. Since the DateTime block is
zzz only 7 bytes, at least one other block must be present.
orignal but why "The minimum payload size is 8 bytes"?
orignal you have X there
orignal between header and payload
zzz because we need 24 bytes after X to get the header encryption keys. 8 bytes + 16 MAC
zzz same for session created, but it has an address block
orignal why "after X"?
zzz because we apply header encryption to X to obfuscate it
zzz so the 24 bytes of keys must be completely "after X"
orignal i2p::crypto::ChaCha20 (headerX, 48, m_Address->i, nonce, headerX);
orignal you use only i and zero nonce
zzz looking...
orignal 24 bytes is for header
orignal not for X
orignal but yes you are right
orignal reling on X is bad idea
orignal I will fix
orignal so my point it's doable
orignal but better to not do it
zzz I don't think I can decrypt the first part of the header right... or maybe I could but it would be messy
zzz but yeah, always add padding, easiest way
zzz thanks
zzz I guess most of the time you do add padding but not always? otherwise it would never have worked...
orignal ha ha
orignal I do unless padding is zero
orignal let me check
orignal definitly a bug
orignal I shoudld add up to 33 bytes
zzz also good to add every time even if zero, so the packet size distribution is smooth, otherwise it has a "gap"
zzz 87, no 88, no 89, no 90, and then 91 92 93 ...
orignal so zero padding size is alowed?
orignal e.g. padding block might be just 3 bytes
orignal can you confirm?
zzz looking...
orignal for some reason I don't allow it
zzz the spec doesn't say either way. I definitely can send and receive padding blocks with size = 0
zzz Pretty sure I do it in other protocols like NTCP2 also
orignal fine then. I will change it
zzz I assume you can handle it on receive or you would have complained a long time ago... you just don't send it now
orignal I have the code that doesn't send zero length padding
orignal not sure why
zzz it's fine if you don't care much about packet size distribution, which we probably don't most of the time
zzz maybe handshake is different, in china anyway
orignal no, I believe zero is acceptable
orignal I will be 5 minutes late
orignal something urgent
zzz 0) Hi
zzz let's work on the agenda then wait for orig.
zzz what's on the list for today?
zzz glad to have you eyedeekay, missed you 2 weeks ago
eyedeekay Yeah I got there about 35 minutes late last week, connectivity problems
eyedeekay Should be fine this time
eyedeekay Felt too late to interrupt
zzz you have a go-i2p report for us today?
eyedeekay Yup, a small one
zzz ok we can put you as 1)
zzz I'll add:
zzz 2) SSU2 / release status
zzz 3) SSU2 Peer Test firewalled charlie
zzz 4) SSU2 Peer Test improvement idea
zzz 5) schedule next meeting
zzz anything else for the list?
orignal I think Charlie for peer test
orignal what item is it?
zzz that's 3)
orignal got it
zzz ok then
zzz 1) go-i2p
orignal I have another item. What is the status of compressed identity?
zzz ok that's 6)
eyedeekay OK so I stripped away the NoiseSocket-specific parts from the code I copy-pasted from go-noisesocket and finally ended up with a noise-like transport using their examples
zzz go ahead eyedeekay 1)
eyedeekay It didn't work but I was pretty sure since I was using an example at least I was doing things in the right order
zzz are you testing XK or IK? I think I saw something in your commits about IK? NTCP2 is XK
eyedeekay So I started working on exchangine messages on a socket which was started for the transport and eventually got a write and a read operation to happen
eyedeekay I'm getting to that
eyedeekay And so I started trying to figure out how to change the existing code to Noise XK
eyedeekay Which also entailed changing the NoiseSocket example from Blake2B to SHA256, which was relatively easy
eyedeekay But I'm using a library, so it was mostly a matter of plugging in a different set of values at different points,
eyedeekay So now I have something like a Noise transport which uses roughly similar primitives to the ones which NTCP2 uses,
zzz well, the hash choice is independent of XK/IK, but yeah, have to change both
zzz have you changed the initializer string?
eyedeekay Yeah I've basically been trying to turn NoiseSocket into NTCP2 by breaking down their examples
eyedeekay I did figure that out, yes
zzz this one: "Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256"
zzz ok good
eyedeekay One of the steps involved switching it from AES_GCM to ChaChaPoly
zzz yup
eyedeekay Another involved changing the hashes
eyedeekay Anyway, I don't know if any of it works yet but that's what I've got so far
zzz well, I assume you're encrypting and writing, so can you decrypt what you read?
eyedeekay I cannot yet, but I think it's because I'm reading something in wrong from the socket
zzz ok, fun times
orignal why do you need a socket involved?
orignal just encrypt and decrypt instantly
eyedeekay Oh... I guess I could just do that, I was trying to do it by establishing a session with myself
zzz sure, you could do that for testing, if you're unsure of your socket issues
orignal sahred i is engough to decrypt SessionRequest
eyedeekay That makes sense
zzz just hexdump every message you write and every message you read
eyedeekay I'll try that to at least figure out if my error is because of what I think it is
orignal you would nedd s later for keys agreement
orignal but first excecise is deryption of SessionRequest
zzz sendSessionRequest("hi mom")
orignal we use AES not elligator, right?
zzz right. but he's just doing stock noise right now
zzz anyway, lots of other things on the agenda... thanks for the update eyedeekay ... anything else on 1) ?
zzz 2) SSU2 / release status
zzz you can go first orignal
orignal so, more traffic more problems
orignal right now we have a lot of SSU2 traffic
orignal and guys keep discovering problem
orignal I think we will make an intermdeiate release maybe at the start of January
orignal that fixes all these issues found so far
orignal beside this SSU2 works pretty fast
zzz how is everything going?
zzz ok I'll go first
orignal i2p looks much much faster than before
zzz lag, got it
zzz keep going
orignal I did some banking today through the I2P ))
zzz nice
orignal on high loaded online bank
orignal no access to it from ouside of Russia
orignal so I used someboydy's outproxy there
zzz a january release makes sense, we don't need one yet but the fixes are piling up
zzz so I've fixed a ton of issues in the last week and I'm still not done
zzz token expiration, post-termination handler, peer test issues...
zzz right now I'm fighting with retransmitted token requests and retries
zzz basically state management issues
orignal btw, fogot to include
orignal your idea about tokens
zzz I also implemented a disable-SSU1 option
orignal I removed SSU1 completely )))
zzz what was my token idea?
orignal what to do with tokens
zzz oh yeah, send only in termination
orignal not this
zzz then what?
orignal you don't store tokens if somebody is firewalled
orignal or something like this
zzz no, I don't think so
orignal then how do you reduce number of tokens?
zzz I was having token disaster. Sending token with 1 hour expiration, but forgetting the token in 10 minutes because cache was too small
zzz better cleanup, adjusting expiration to = cache lifetime
orignal the worst case is Retry message. why disaster?
zzz and also don't send in handshake at all. Only with termination
zzz yeah, not really a disaster
orignal so you don't send in SessionCreated?
zzz but forces alice to do a second DH if the token is no good
orignal only wih termination?
zzz correct, that's what I changed it to last week
orignal will do the same
zzz but our 0.9.56 release doesn't listen for termination reason 1, so I had to implement that also
zzz so a whole bunch of changes
zzz trying to have longer expiration without using more memory
orignal why it doesn't listen?
zzz because I sent termination and killed the whole state. No retransmissions, no more listening
dr|z3d what's the likely penalty from storing tokens on disk to mitigate memory usage, zzz?
zzz that was the simple way :)
orignal don't you wait for confirmation?
zzz no, I never waited for termination reason 1
zzz so if termination got lost, other guy could keep sending I2NP or whatever
zzz not good, but I just never got to it until now
zzz dr|z3d, that wouldn't help really, too slow
zzz oh, one other change: I'm now sending other termination reasons besides clock skew in response to token/session request
zzz one for limits, one for banned
orignal limits?
zzz connection limits
orignal is there connetion limit for SSU2?
zzz previously I'd just drop, and alice would retransmit several times
zzz yes
zzz anything else on 2) ?
dr|z3d ok, thought you might say speed penalty. puts that idea to bed.
zzz 3) peer test with firewalled charlie
zzz so the problem is:
zzz in SSU 1, the doc says bob must pick a charlie that is not firewalled (is publishing an IP/port)
zzz and in java we kept the same rules for SSU 2
orignal SSU1 is far from current reality ))
zzz so we won't pick a firewalled charlie
orignal in 2003 everybody had ipv4 ))
orignal my point is
zzz and in SSU2, if I can't find an IP/port in charlie's RI, I fail
zzz but i2pd bob will pick a firewalled charlie.
zzz (end of problem statement)
orignal Charlie can be firewalled and Alice should use his endpoint for msg 6 and 7
orignal so my argument is
orignal if we limit Charlie SSU1's way
orignal it can endup with lack of Charlies on Bob's side
orignal Firewalled router should participate more
orignal peer test is one of ways
zzz counter-arguments:
zzz 1) we have lots and lots of SSU2 peers now, no problem finding charlies
zzz 2) charlie could be SNATTed
orignal even on start
zzz which would screw up the test
orignal 2. Chralie shouldn't publish this cap if SNATed
zzz 2) yeah I guess charlie could reject the request, or not publish
orignal even he is SNBATed what's wrong?
orignal we test Alice not Charlie
zzz yeah maybe it would work
zzz but over 80% of routers are not firewalled
zzz it just seems messy to use a firewalled charlie, rather than one you know is good
orignal I don't think so
zzz also 3) the design goal of SSU2 was that Alice would get Charlie's RI so Alice could decide whether to rely on charlie
zzz aka "know" charlie
orignal majority of routers should be firewalled
orignal 3. Alice knows if Charlie if frewalled of not
zzz java has UPnP so they're behind a NAT but not firewalled for i2p
orignal if alice Chralie is firewalled she can stop on msg 5
zzz right, that's what I do now
orignal UPnP, are you seriopus?
zzz we've had UPnP since about 2008
orignal most of users use mobile netwroks
orignal I know
zzz that's why 80% of the network is not firewalled
orignal but usuelly ity's uselless
orignal Working UPnP is rare thing
zzz tell you what, let me disable my check, and gather some stats on how well peer test works with firewalled charlie
zzz and I'll come back next time with some data
zzz ok?
orignal but I donb't understand the problem
orignal if you stop on msg 5
zzz it's just a waste of time, you didn't pick a charlie I could use
zzz not a big problem
orignal why? I pick Chrarlie
zzz it also doesn't match the SSU 1 spec (SSU 2 spec is silent on it)
orignal you get msg 5
orignal hence you know your network status
zzz no. I stop on msg 4 and give up
orignal then wait for 5
zzz because I can't validate that the IP/port in the peer test matches the RI
orignal by nonce. no?
zzz yeah but I'm also double-checking that the RI matches, that's what fails
orignal you validate if your port is rechable
orignal that's the purpose of peer test
zzz I'm also validating that charlie isn't spoofed and I'm being given some bogus IP/port
zzz that was one of the points of SSU2 peer test, to make it more secure
orignal what's an advatge to spoof him?
orignal you puprose is to test if your port is reachable
zzz to send a bunch of packets to whitehouse.gov?
zzz that's the security part of it
orignal if you stop on msg 5
orignal let me explain the scenario
zzz to not have bob or charlie trick you into sending packets to some target, DDoS style
orignal you send msg 6 only if you can validated Charlie's endpoint
orignal if you get msg 5 it doesn't matter what was the intent
zzz but source endpoint could be spoofed in msg 5
orignal it means only one thing: your port is rechable
orignal that';s why you don't send msg 6 if you can't verify
zzz we're trying to keep the network from being used for ddos
orignal and stop on 5
zzz right but charlie could send any ip/port in peer test, then spoof msg 5 source
orignal simply speaking I don't see any reason to not rely on msg 5 for your own status
zzz right, its not about relying on msg 5, but deciding to send msg 6
orignal then how rechable Charlie can help?
orignal you said you don't rely on 5 in this case
zzz because his ip/port is in his signed RI
orignal in msg 4
zzz so I double-check that test ri/port matches RI IP/port
zzz yes
orignal but he can still spoof it
zzz sure, he could create a whole RI just for me
orignal just send some fake IP/port in msg 3
zzz but he has to spoof the RI plus msg 3 plus msg 5 source
orignal if he can spoof he can spoof RI
orignal becuase he creates it
zzz anyway, I'm going to do some testing and report back next meeting. As I said I'm not sure what the right answer is
orignal ашту
zzz you make some good points
orignal remeber msg 6 and 7 is for SNAT test ony
orignal main one is 5
zzz (and this isn't my only peer test problem, working on several things)
orignal me too
orignal I receive errors from Bob too often
zzz so enough on 3) for now?
zzz anything else on 3) ?
zzz meeting already long, I'm going to skip 4) peer test improvement idea, I'll bring it up another day, or maybe write it up somewhere
zzz 5) schedule next meeting
zzz I propose we skip 12/26 and 1/2, and have the next meeting on 1/9
zzz thoughts?
orignal lag agin
orignal wondring on which side
zzz hearing no objections, 1/9 for the next meeting
orignal maybe next monday?
eyedeekay 1/9 is fine with me, will avoid travel-related difficulties for me
zzz let's not do next monday
zzz kinda like every-other-week :)
orignal yes but holday break
orignal and we have a lot to discuss
zzz eyedeekay, 12/19 ?
eyedeekay I can be there for 12/19 if it's happening
zzz ok, orignal convinced me, 12/19 and then 1/9
zzz agreed?
eyedeekay works for me
orignal works for me too
zzz great
zzz 6) status of compressed identity
zzz go ahead orignal
orignal I'm waiting for you
orignal if you are donbe with it I will change it too
zzz checked in November 23, as I reported at the Nov. 28 meeting. Nothing else to report
orignal fine then
orignal will change
zzz great
zzz anything else on 6) ?
zzz anything else for the meeting?
zzz thanks everybody
zzz eyedeekay, one hint in case you haven't gotten there yet:
zzz the trick with noise handshake over sockets is there's no message encapsulation
zzz you have to know - in advance - the size of each message
zzz and read into a buffer until you have exactly that
zzz the protocol must specify those sizes
zzz so for your stock-noise testing, set a specific payload size, or zero payload (no "hi mom")
zzz and then that will be a big part of the mods to get to NTCP2
zzz EOT
eyedeekay Thanks zzz