#ls2 (irc2p) | #ls2 proposal review channel : No reviews currently scheduled

zzz altonen_, if you'd like to discuss the attacks, #i2p-news is the best place, before or after the meeting

altonen_ ok

orignal especially since it's not an attack )))

zzz everybody has their theories, what you call it doesn't matter

not_bob My graphs are looking generally up today.

orignal no evidence that these routers has been modifed for attack

zzz If you're here for the review, even if you're just lurking, please say hi.

not_bob Here

StormyCloud The cloud has arrived

orignal hi

zzz OK. welcome everybody, let's try to do this. If it doesn't work out, we'll reschedule for a week from now.

zzz I'll give a brief overview of what the agenda is for today and then I'll throw it open for questions and comments.

zzz This is the 4th review of proposal 169, going back a year. The previous 3 focused on Ratchet. Today we're going to look at the transports.

zzz Starting with NTCP2 and going on to SSU2 if we have time.

zzz Orignal and I made some preliminary agreements back in August on how we would advertise PQ transport support and I documented them at zzz.i2p/topics/3697 , you can look at that for a summary.

zzz We have recently implemented and tested PQ NTCP2 based on those decisions. I have updated prop. 169 to reflect those decisions and that's what we will be reviewing today. We have not started on SSU2.

zzz The changes are very similar to what we did for ratchet, together with guidance about how to advertise PQ support in router addresses.

zzz All changes are backward-compatible.

zzz I'll now ask for questions and comments.

orignal my issue is padding size

orignal we should have spikes in SessionReqest message size distrobution

zzz ok orignal at the bottom of the NTCP2 section I put my proposal

orignal *shouldn't

orignal so what's you proposal?

zzz Java I2P proposes using the defined message size as the maximum padding, that is, the maximum padding will double the message size, as follows:

zzz Message Max Padding MLKEM-512 MLKEM-768 MLKEM-1024

zzz Session Request 880 1264 1648

zzz Session Created 848 1136 1616

orignal right and I don't like it

zzz that's the proposal for the maximum. I don't specify the distribution

zzz ok what's YOUR proposal ? ))

StormyCloud Why do you not like that size?

orignal two options

orignal either up to next type min size

orignal or up to MLKEM-1024

orignal random

orignal StormyCloud because huilo will see two spikes

orignal around 287 and around 1264

orignal and they recignize I2P this way

zzz my proposal is more than the 'next type min size'

orignal we don't want it

orignal what's your max size for standard x25519?

zzz e.g. for mlkem512, 880 + 880 padding is > mlkem768 min size 1264

orignal great

orignal tell me about x25519

zzz Java I2P implements a maximum of 256 bytes padding for non-PQ connections, however this was not previously documented.

orignal we should extrend it

zzz I can extend it for non-PQ but you'd have to check router version

orignal to overlap MLMKEM-512

orignal ofc based on router version

zzz I can research how much of a pita it would be and get back to you

orignal fine

orignal no more question or concerns from me for NTCP2

altonen_ why support two different ways of signaling PQ support (same/different address), why is same-addres PQ not the only way?

zzz so are you happy with my proposal then as I pasted above?

zzz same-address will be the only way, until somebody wants to do it the other way

zzz or until we stop doing non-PQ

altonen_ but do i have to implement support for both types, in case somebody implements it at some point

orignal altonen_ because zzz din't have an anser from you

zzz nah what I said in the docs is contact us if you want to do different address because we haven't implemented it

altonen_ ok

zzz if it's easier for everybody to do same address I'll more clearly mark it in the spec, 'don't do this'

orignal same address with pq= is fine in my opinion

altonen_ i'd also prefer same address

zzz ok eyedeekay you happy with that?

orignal I suspect he is not up to what we are talking about ))

zzz probably not, that's ok

zzz any other comments or questions about NTCP2 ?

zzz how about on SSU2 ?

zzz note that we feel pretty good about the NTCP2 part since we've already implemented and tested it

orignal ssu2 is time to imlement

orignal to fix this old issue

zzz yeah I can start working on it after I checkin NTCP2 support

zzz there is one TODO in the SSU2 section, whether to change the version field in the Relay and Peer Test blocks

zzz or leave it at 2

zzz not sure, we can figure it out later I guess

zzz one of many problems, yes

orignal SYN packets become looong

zzz there are now 5 streaming impls including go/rust/i2pd/java/tixati

orignal no we are talking about signatures only for now

orignal and no idk how to do it through I2CP

zzz me either

zzz anyway, let's get back to transports

zzz anybody have any other things to discuss about the transports?

orignal gralic I2NP message for ratchets

orignal I send many datagrams in a signle garlic

orignal would you honor such garlic?

zzz with multiple cloves?

orignal yes

orignal basically multiple datagrams

zzz off the top of my head it seems like it should work but I'd have to research and get back to you

orignal but this is not my main quetion/proposals

zzz I don't think it violates any spec. Have you researched in the specs?

orignal in this case we do more

orignal we use delivery type "destination" only for first one

orignal others are "local"

orignal why?

zzz local violates the spec and won't work thru java

orignal if you datagram is 20 bytes, 32 extra is huge overhead

orignal yes, I know

orignal that's my proposal

orignal to let java support it

zzz write it up

orignal we use it in our UDP tunnels

orignal for packs of raw datagrams

orignal but this is incompatible with Java

orignal anybody esle?

orignal opionions?

orignal *opinions

orignal altonen_, eyedeekay

altonen_ i need to check my code but i think it should work

zzz you could also just define a packed format inside one clove. length | datagram | length | datagram | ...

eyedeekay I don't see why not but I want to think about 'local'

zzz depends what layer you want to do it at, the application layer or down in ratchets

orignal zzz, yes that's anotoer option without Data gzip header

orignal that's also overhead

orignal eyedeekay the difference between destination and local is extra 32 bytes

orignal i2pd UDP tunnel is Datgram3 + raw datagrams

zzz could define 'datagram4' which is a packed format

orignal why?

orignal it's ratchets level

orignal just another block type

zzz but I'm saying maybe the application layer is a better place to do it than the ratchets layer

orignal for raw datagrams

zzz or maybe not. just brainstorming

orignal special delivery of raw datagrams through racthets make sense

orignal that's all from me

orignal and datagrams are very fast now

altonen_ orignal what is a usecase for UDP tunnel?

orignal wireguard, my freind

orignal and also video streaming

orignal if you live in some "stan" wireguard over I2P is what you want

altonen_ cool

orignal huilostan is real case today

zzz if you write up a spec for it I'll consider supporting it

orignal for multi cloves

orignal or new block type?

zzz for what you're doing now for wireguard

zzz but if it's incompatible stuff in the ratchet layer thats harder

orignal you want speans for our UDP tunnel

orignal we also send some data in options

orignal will try to write

orignal how it works

zzz somebody asked me a while ago about it, I said there's no published spec afaik

zzz ok, no promises but will take a look ))

orignal ha ha

orignal it was a lot of discusssions with onon

orignal I will try to summarize

zzz no rush, kinda busy )))

zzz gotta run, thanks again everybody, especially nice to see altonen_ here

orignal however there is one issue

orignal it relies on the ability to swicth tunnels

orignal bye

altonen_ it was nice chatting again, cya