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

orignal hi

eyedeekay Hi orignal

eyedeekay Hi everyone welcome to the meeting for the 21st, sorry I was a little late

eyedeekay Who all is here?

orignal seems nobody

eyedeekay What's on the agenda? I have 1) release and 2) SSU2 RI in SessionRequest

orignal please give voice to xeiaso

orignal nice

xeiaso hi

orignal let's talk about release

orignal eveything works good from my side

eyedeekay Same here, we've had lots of time to test our changes, looks good, I'll be ramping up for us to release on the 26th

xeiaso good to see its on schedule

orignal so tomorrow

eyedeekay No 1 week from today, it's the 19th

orignal so postponed for 1 more week?

eyedeekay Yeah, I had to push it back a week because my laptop died, had to find a replacement and get my work environment set back up

eyedeekay Anyhow, we're on track for that date.

orignal wut? your lattop died?

orignal and you don't have any other computerss?

eyedeekay I don't have any other ones with all my keys on them except for a backup locked in my office

eyedeekay Got locked out of everything without the keys. I can work fine on another computer, but can't check anything in from them

orignal and you don't have local storage I guess

orignal you shoould organize your work envirnment first

orignal to make sure that death of your laptop or PC doesn't postpone release

eyedeekay I didn't have a backup of my keys on my person at the time the laptop died no. Actually I thought I had, but what I actually had was a portable hard drive that made a strange grinding sound

susdo oof gotta backup my keys

eyedeekay At any rate, the delay for me between broken-laptop-to-recovered-environment should be down to around 48 hours in the worst case scenario now, if nothing I'm carrying works I can still get it from the backup in my office

orignal setup local NAS

orignal with RAID1 in it

orignal I thought it was obvious

eyedeekay Sure if I'm stationary, if I'm travelling then that does me little good

orignal are you travelling now?

eyedeekay Not anymore as of last week

eyedeekay I'll get around to setting up a NAS soon

eyedeekay When do you want to do the next release after this one?

eyedeekay September?

orignal so what's included to the next release?

orignal whenever you are ready

xeiaso wouldn't meeting point 2) be included in the next release?

orignal if we agree what we do

eyedeekay For Java I2P?

eyedeekay We have an option to set an expiration time for blocklist entries, we've got fixes for the messageID replay leak, and we've changed how we validate inbound messages

eyedeekay Yes, I thought we were still talking about 2.3.0

eyedeekay I would like to target SSU2 changes to 2.4.0, I'm on board with the routerIdent-in-SessionRequest thing per one or two pending questions

eyedeekay Figure we can get to them in 2)

orignal so, what's you opinion?

eyedeekay On SSU2? I like early validation and early dropping, it means less overhead and earlier effectiveness. routerIdent-in-SessionRequest gets us that

eyedeekay And it makes the clone attack ineffective AFAICT

orignal do you have an offical proposal?

eyedeekay No, I do not. What I need is for us to fit it into the official specification. I would like it very much if you wrote the proposal, since it is your idea and you probably understand it best. Doesn't need to be long

orignal will try

eyedeekay Thanks

eyedeekay For folks keeping score at home we've moved on to discussing 2)

eyedeekay I do have one kind of concern about this idea, though, which regards obfuscation

orignal obsfuscation?

orignal where?

eyedeekay Where is part of my question: does does including the routerIdent in the SessionRequest make it easier for an attacker to say "this is definitely SSU2," or alternately, "this is definitely an I2P session?"

orignal no, it's just one more block

orignal it goes as chacha20 encrypted payload

eyedeekay OK

orignal we have 4 block already if I remeber

eyedeekay Yeah

eyedeekay OK I'm still going to squint at it but if you can do a proposal for it we can work on it for 2.4.0, tenatively mid-September

eyedeekay Anything else for 2)?

orignal no

orignal ofc I don't know my plans for september yet

eyedeekay OK. Lots of time to coordinate in between now and then, just ping me if you need to let me know of your plans

eyedeekay OK any other topics for the meeting?

xeiaso what about 3) netDB modularization? I noticed i2pd seems to do this

eyedeekay Yes they do, something orignal's been suggesting we try for a long time IIRC

orignal xeiaso you mean netdb per desatination?

xeiaso yes

orignal ofc it should be done

orignal because that attacks still possible

eyedeekay We're considering the idea of making it so that it is possible to use different netDbs based on where a message came in, i.e. per-destination

orignal if you run your destination on a floodfill

eyedeekay It's a lot of work for us to do this and our extant defenses make the job a little complex and unclear, there are literally hundreds of places where the netDb is accessed in Java I2P, at least 280 that I've got to review so far for this process

xeiaso oh?

xeiaso orignal: why is it floodfill specific?

eyedeekay But branch on git.idk.i2p/idk/i2p.i2p i2p.i2p.2.2.1-nested-netdb contains a prototype

eyedeekay orignal IIRC you have a blog post somewhere about this, do you remember where it is?

orignal because you can submit LeaseSet to floodfill directly

orignal unlike regural router

orignal no I even didn't know you had a blog ))

xeiaso Java I2P allows direct submission to regular routers

eyedeekay Not my blog, your blog

eyedeekay Or maybe acetone's?

orignal my blog? I never wrote blog

orignal yes, acetone

eyedeekay Hm. Must be misremembering

orignal probably on habr

orignal xeiaso Java I2P has shared netdb between router and destinations

eyedeekay OK. I'll look for it later then, want to review it for researching our implementation

orignal if you submit a LeaseSet to a floodfill

orignal one of destinations might see it

orignal and it can lead to deanon

eyedeekay Anyway, this is something we're looking at, which we're trying to figure out the right way to do it

eyedeekay Knowing more about the scenarios where an attack might be possible, so we can evaluate if it's real, and where and how to handle it, is part of what needs to happen to do that

eyedeekay That's all I have to add for 3)

orignal there are at least 3 working scenario

orignal I descibed all of them and sent to gradpa long time ago

eyedeekay Can you PM them to me, or send them in an email?

orignal it was few years ago

orignal need soem time to remember

eyedeekay I don't have access to grandpa's email so anything you recall would be appreciated

orignal and grandpa agreed that such problem existed

orignal no it was in IRC

eyedeekay Oh, bummer

eyedeekay Well I have even less access to that

xeiaso what is old is new

orignal but the basic idea that router's LeaseSets and destination's LeaseSets can overlap

orignal e.g. destination might use LeaseSet submitted to router directly

orignal and vice-versa

eyedeekay Yeah, and if you can get one you sent to one from the other, then you can determine that they're both sharing a netDB and on the same router

xeiaso or a LeaseSet submitted to a router might already be a destination on that router

orignal it migth be special LeaseSet prepared for deanon

eyedeekay Pretty straightforward in principle, in practice we've got calls to get the context-wide netDB all over the place

eyedeekay So tracing them all is the biggest part of the work now

eyedeekay Something like 300 or so calls

eyedeekay I'm still identifying more, that's why it will help to know where the existing issues may be

eyedeekay Anything else on 3?

orignal no

eyedeekay Anything else for the meeting?

xeiaso no

eyedeekay OK thanks everybody for coming, see you around IRC, if you're interested in the segmentation approach see that branch I posted above

eyedeekay See you next time on the 7th

eyedeekay Oops, make that the 3rd