#saltr (irc2p) | I2P+ 2.7.0-17+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

eyedeekay Re: review schedule - Afternoons are going to be better than mornings for me until next Wednesday. My cable will be out for part of this Wednesday and I don't know for how long so that isn't a good day for me. Thursday would be good. Friday also works well.

zzz yes I checked in 165

orignal so what's the next step?

zzz make a choice, state the reasons, add security analysis, and add specifics so it can be reviewed and implemented and copied to the specs. Same as any other proposal.

orignal so my choice is 4. how can I say it?

zzz say why it's better than 1-3, why it's secure, add details so it can be implemented

zzz we've done this 20 times before, and I gave you the same feedback in April

zzz if it's not ready to copy-paste into the spec, you're not done

zzz also need all the analysis about backward compatibility / versions

zzz say why it's better than 1-3, why it's secure, add details so it can be implemented

zzz please don't pretend we haven't done this 20 times before

orignal now tell me what's missing now beside why I thin 4 is better

zzz why it's secure, add details so it can be implemented

zzz also I suggested two flags, you only have one? the other one was to send to old routers, did you not like that idea? what's your idea to prevent spoofing new router as old one?

zzz please review my comments from april and may

orignal I wrote it about old routers

orignal got it I will explain in details

zzz yeah but my idea fixes it now, not 'at some point' years from now

orignal then YOU should add #5 explaining it

orignal right?

zzz I explained it in May, check backlog

orignal because it's your idea and you have argument to defend it

orignal I know but it's your idea

orignal I defend my idea, you should defend yours

zzz I'll defend it, you write it up, or come up with a better idea

orignal I'm going to defend my idea

zzz you have no solution in there at all

orignal I do

orignal just didn't elaborate it

zzz look in the May scrollback. I told you and you liked it

zzz without this part the whole proposal is useless for many years

orignal disagree

orignal anyway I will write it down

zzz here's the way I'd say it

zzz define 2nd flag 'bob is old'

zzz if bob is really old, he ignores the flag of course, he doesn't know about it

zzz if bob is really new, he drops the session request

zzz without this, fake old routers can't be prevented until we refuse to connect to old routers, many years from now, so the whole proposal is a waste of time

zzz maybe if bob just updated, wait a day before starting to look for the flag, because otherwise it will be a mess when we upgrade

orignal my point is different

orignal this issue is not critical and we have years

orignal with older routers use my algorithm:

orignal 1. if you have a profile for that router connect it without exctra MixHash

orignal 2. if a router is not known before, connect through NTCP2 first

orignal 3. if router is SSU2 only bypass it until you receive an incoming connection

orignal but remember that majoriry of routers(including floodfills) will update soon after a release

orignal even if advsary floods with fake routers with older version they also have to clone an old router

orignal hence they have less amount of routers to choose from

orignal that's I'm going to write in the proposal

zzz that algorithm is a PITA for us to implement over here, and it doesn't need a proposal at all, you already did it, and you admit it has problems because it prevents use of SSU2

zzz the flag bit is 100x easier and gets rid of all those problems

orignal two flags make things overcomplicated and harder to understand

orignal while I prefer to keep things simple

orignal and don't produce extra entities if not necessary

zzz what you did is a workaround. the 2nd flag bit is a real fix

orignal it prevents using SSU2 now but it will not soon after the release

orignal because majority of routers will be on new version

orignal and you can connect through SSU2 immediately

zzz no because attacker creates fake old RIs

orignal frthermore new routers will also be on new version

zzz without 2nd flag bit nothing is changed from today

orignal attacker can't create old fake RI

zzz why not

zzz clone s/ip/port, set old version, done and done

orignal attacker can only create fake RI with copy of address of another old router

orignal nope

zzz right, copy address, but set old router.version

orignal let me think

zzz 2nd flag bit is one line of code: if (bob is new) set flag 1; else set flag 2

zzz bob side: if (flag 2 set) drop

orignal right, Alice connect it as to old and doesn't set flag

orignal agree

zzz two lines of code. your workaround would take me a month, and it's just a messy workaround, not a fix

orignal but two flags remain in th protocol forever

orignal will add second flag

orignal but not today probably tommrowo

orignal need to finish stuff with current attack

orignal but what if attacker clones old router?

zzz that's what will take years, but as you said, most of the network will update pretty quickly

zzz unless you have a better idea

orignal I mean for this you would need this messy workaround

orignal or bypass older routers completely

zzz hasn't been a big problem so far for us, it's been a year and a half

orignal brb. rebuild

orignal so, what are going to do with unsolicited leasests?

RN I may be wrong, but I thought unsolicited means drop

RN (probably wrong)

zzz but 'unsolicited' could actually be 'got it after I asked and gave up waiting'

zzz do whatever you need to do to avoid getting dos'ed

zzz this is back to the part I defer to eyedeekay

eyedeekay Re: unsolicited leaseSets in client db's I've been analyzing all the ways they come in and trying to see whether there are any characteristics we can use to decide whether to accept or reject them when they're sent to us

eyedeekay We should be able to know if we requested a leaseSet as part of a lookup but unsolicited stores are harder to figure I think

eyedeekay I don't know whether we could reject unsolicited stores in a consistent way based on things we know about where they came from at the router-context netDb

orignal in my opinuion LS should be accepted in 2 cases

zzz orignal sprayed a bunch of q's at me yesterday about do we check public key match, do we handle solicited vs unsolicited any different, do we have throttling or limits, etc etc etc

orignal if it response to a request

orignal or if static key matches session

orignal eyedeekay the problem is

eyedeekay Yeah I've been reading the scrollback and trying to find my own answers

zzz let us know how that works out in practice orignal

orignal attacked send fake LS througgh another ECIES session

orignal *attacker

orignal he also send SYN packet with ident from this LS

orignal since we store such LS we find it locally and trying to send SYN ACK to nowhere

orignal because real LS is fake

orignal that's the reason of my question if we should drop such LSes or it's allowed

eyedeekay I don't know from "should" right now my questions are about "can" "when" and "how"

eyedeekay As in "can we do this," "when is it OK" and "how should it be done"

orignal zzz, what you do if you see Lease's exp time more than 10 mintues?

orignal adjust or drop?

zzz or just slap a 1000 LS limit on client subdbs, done and done, no need to get complicated

zzz when you're being attacked, anything is 'allowed'

zzz don't need our permission

zzz same as RIs. too far in the future and we drop

eyedeekay Fair enough, even in the client subDb's that can get huge I've never seen 1000

orignal then good users will not be able to connect

orignal I'm asking about the protocol

RN why would a good user send an expire that's more than 10min... that is wrong

orignal RN that's another question

orignal my answer was about 1000 limit

orignal why good user can do it? say, clock skew

zzz unless you're doing a point release, you have two months to think about it and test and report back to us on your recommendation

RN other than wrong clock... shouldn't send more than 10m

zzz so make it 5000 or 10000, who cares. something less than 200,000

orignal zzz, so what you do with sch lease?

RN wrong clock is user error, other is not conforming and therefore suspicious to me

zzz same as RIs. too far in the future and we drop

orignal do you drop whole LS or just one lease?

zzz whole

orignal 5k or 10K doesn't matter

orignal I have 200k+ LSes and Ilita works

orignal what's your threshold?

orignal I use 11 minutes

orignal but not sure if it's right

zzz so if it's not a problem why panic and make a bunch of changes and need answers from us right away? take your time

orignal no panic ofc

orignal I have fixed it yesterday

orignal that's why I'm asking you how to solve the problem propery

zzz our limit is 16 minutes in the future, which sounds too long to me. probably 11 or 12 is better

orignal the problem with such number of LSes is memory

orignal thanks

orignal both for whole LS and individual leases?

orignal how about past? 30 seconds or so?

zzz oldest lease > now - 10 minutes

zzz newest lease < now + 16 minutes

zzz newest lease > now - 1 minute

orignal thanks

orignal and any of this condition is not satisfied you drop it

orignal about point release

orignal they attack only me and R4SAS ))

dr|z3d presumably because they don't like their treatment on your irc server?

dr|z3d maybe it's a russian state sponsored exercise and they just don't like freedom of speech, and you're a big target.

zzz dr|z3d, availability for a prop. 168 review meeting?

orignal no it's someone from kislitsa with mental disorder hired sha512sum for 500 roubles

dr|z3d got a window, zzz?

zzz say some afternoon at 3 eastern the week of Dec. 2?

dr|z3d 8PM UTC or thereabouts. should be ok.

zzz ok I'll propose 8 PM UTC Tues. Dec. 3 in #ls2. orignal eyedeekay ok with you?

orignal week of Dec 27 doesn't work dor me

orignal sec

orignal Dec 3 at 15:00 is fine for me

dr|z3d where did 27 appear from?

dr|z3d you added an errant 7, orignal :)

dr|z3d and the 3 is a bit of a wildcard, too.

dr|z3d *2

orignal Dec. 2?

orignal I read ? as 7 ))

zzz easy to do

zzz ok just waiting for ack from eyedeekay

dr|z3d *** chuckles ***

dr|z3d orignal's been welding all day and the screen's a little fuzzy right now.

eyedeekay 3rd or 2nd? 3rd works, 2nd is awkward for me but I can make it happen

zzz and y'all please review it in advance, don't make me break out the baffer

zzz tues. the 3rd eyedeekay

eyedeekay Perfect the 3rd is fine by me

zzz super

dr|z3d what's the venue? #ls2?

zzz yes

dr|z3d ok

zzz topic set in #i2p-dev and #ls2, and I'll put it on zzz.i2p

dr|z3d cake.i2p/file/HgYReJCTuU_QcybyQSrgXqQsRIt9AL23OGHLJc7mZ_dYXM0nSeMr/floodfills.png

dr|z3d we could light that up with indicators of the floodfills we're currently talking with, zzz.