#ls2 (irc2p) | #ls2 Proposal 168 review here 8 PM UTC Tues. Dec. 3

eyedeekay Reachable as published is when we have at least one transport reachable on at least one IP address, whether it is NTCP2 or SSU2, and whether it is IPv4 or IPv6

orignal he said that reachable means by ANY transport

eyedeekay One transport, one IP is enough to mark a router as reachable

orignal in i2pd however I define reachable by ipv4

orignal or if it's ipv6 only

orignal so if I see firewalled ipv4 and OK for ipv6 I never set R

eyedeekay That may be close enough, but the definition I arrived at by reading and asking, it's any transport, any IP when publishing

orignal yes but that definitly is not usable practically

orignal makes R flag useless

eyedeekay Why do you think that?

orignal you see XfR for example

orignal but ipv4 is firewalled there

orignal would you consider it as a FF?

orignal definitly not

orignal although caps look good

eyedeekay I would decline to use it as a floodfill if there were routers publishing a 4 address I knew I could reach

eyedeekay But in principle I don't see it as tenable to disuse IPv6 only routers. Maybe it's OK for now

orignal FF must be recahble by ipv4

orignal what's with ipv6-only routers?

orignal they are good but can't be FF, OBEP or IBGW

orignal but my question is

orignal what are you going to use R for?

orignal based on your difenintion

eyedeekay It's not what I am going to use R for, it's what we already use R for, turns out, checks for R are spread out all over the code including in places I don't fully understand

orignal so do you sauggest to publish R evern for ygg-only routers?

orignal technically they are R

eyedeekay It looks like it's used for optimizing the way we select routers from the NetDB mostly but I can't be totally sure in all cases

eyedeekay our usage of U is a little clearer, and H is abundantly clear, but R is much more obscure

orignal then in which case we publish U?

dr|z3d sorry, late to the party.

orignal hi

orignal we are dicussing R/U

dr|z3d hi orginal, hi eyedeekay

eyedeekay Yes, for now I think you should. Clients who lack yggdrasil connectivity should figure it out for themselves

orignal great, will change

eyedeekay U should only be published if you have no IP addresses to listen on

eyedeekay Hi dr| z3d

orignal now, when we publish U?

dr|z3d yeah, U. I use U to determine whether or not a floodfill is good or marzipan dildo, orignal

eyedeekay "U" is published with either no IPs **or** no transports

eyedeekay H is not published at all anymore, instead the equivalent of H is to publish NTCP2 and SSU2 with no IP addresses, so it's AFAICT identical to U

dr|z3d I'm also using U to determine whether or not to serve transit requests to older, slower routers.

dr|z3d skimming the backlog, it seems you assumed R/U to mean reachable/unreachable to the router reading the cap, orignal?

orignal no I don't use there caps at all

orignal that's why I'm asking

dr|z3d I think the importance of R/U is knowing whether the router in question is directly reachable by other routers, regardless of whether or not our router can reach it.

eyedeekay ^ that, and it seems to be used at times to optimize peer selection

eyedeekay That's everything I had for 1, unless we have more orignal do you want to proceed with 2?

orignal but how it can be used?

orignal then 2

orignal why we need to publush encrypted RI though a tunnel

dr|z3d if a router is publishing U, then we know it's firewalled/natted.

dr|z3d if it's publishing R, then it's reachable by _some_ other routers.

dr|z3d so we can treat R and U differently.

dr|z3d U might as well == degraded performance, and we can avoid those routers for client tunnels.

orignal then why do we need both R and U?

dr|z3d it's also possible to deny service to older U cap routers entirely. LU? not current. no dice. etc.

orignal U = not R

orignal I mean if no R it means U

orignal why do we need two codes?

dr|z3d R only becomes active when the router's bootstrapped.

dr|z3d so there may be a small window where the router is neither R nor U.

eyedeekay You know that's a worthwhile point. I wonder if we can assume U when not R, maybe we can.

eyedeekay That's going to take some homework on my part, maybe we don't. Can't give you a good answer today

eyedeekay But I will look into it

dr|z3d sure, valid. if R/U is binary, then we only need U. or R.

dr|z3d might be worth -m'ing the channel, eyedeekay, just in case there are bystanders who have something to add :)

eyedeekay Thanks dr|z3d

eyedeekay Anybody else on the channel?

eyedeekay Also feel free to message me for voice

obscuratus hi, or course.

dr|z3d usual zzz practice, np. just noticed xeiaso commenting in #saltr.

xeiaso This issues strikes me as bikeshedding.

dr|z3d it's not bikeshedding, it's clarification of something orignal's not certain is required. refinement.

xeiaso i2pd doesn't use the flags, R routers are still profiled.

orignal we only publuish R and U for Java

eyedeekay According to the spec, clients need to be able to handle missing caps regardless, which I gather is i2pd's primary method of determining these specific capabilities

orignal we calculate it based on transports

eyedeekay Regardless, Java I2P does make use of them and will make use of them in similar ways for the forseeable future

orignal I use a bitmask intenally

eyedeekay I would prefer that i2pd continue to publish them until we know better

orignal no problem

orignal as we agreed I publish R if there an IP addresses amoung transports

eyedeekay Thanks

eyedeekay OK how about 2: Encrypted RI's

eyedeekay orignal go ahead

orignal yes

orignal so if we publish unecrypted RI through a tunnel OBEP can catch it and send rerple back

orignal according to the instruction

orignal I did it in i2pd unintentionally

orignal but an advesary can do it intenitonally

orignal e.g. you publish your RI and get confoirmation back

orignal but it never reaches that FF

orignal that's why we need to encrypt it

orignal EOT

eyedeekay So it can prevent you from publishing an RI? That's no good. Thanks for spotting it

eyedeekay So how do you encrypt the RI?

orignal yes

xeiaso What about lookups? Can't the OBEP fake a reply for an unencrypted lookup?

orignal you are supposed to encrypt it already in Java

orignal gradpa did it long time ago but couldn't expalin a reason

orignal beside "better to encrypt data going through OBEP/IBGW"

orignal but now I see a real reson

orignal and implemented in i2pd

eyedeekay OK good

orignal xeiaso lookup of what?

xeiaso netdb lookup

dr|z3d orignal: is it interoperable with java?

orignal lookups for LS are always encrypted

orignal dr|z3d encryption?

dr|z3d yeah, RI encryption.

dr|z3d I think we already do in most cases unless the router in question is slow perf.

orignal while RI lookups usually are being sent directly

orignal but yes good point

dr|z3d but details are a bit fuzzy right now.

orignal I will check

orignal RI encryption is the same as for LS

orignal just ECIES using flodfill's public key

orignal slow perf for what?

orignal for ECIES ecryption?

orignal it's just single x25519

orignal unlike ElGamal days

dr|z3d slow perf being arm, android etc, but as I mentioned, details are a bit fuzzy. we have an isSlow() flag.

orignal probably lookups through tunnels should be also encrypted as xeiaso mentioned

orignal xeiaso also while you are here

orignal you asked what whould happen if tunnel builc comes down though a tunnel

orignal basically nothing unless they know your RI already

orignal and can encryopt a record just for you

xeiaso right. but RIs are public and you can scrape the netdb for them

orignal but yes there is non-zero posiibility of such attack, so it should dropped

orignal see my point

orignal you see and LS and trying to indenfyn it's router

orignal but sending tunnel build message

orignal though one of IB

orignal but you need to know router already for doing it

orignal e.g. you can't find a router but you can't only confirm if that's the router you suspect where LS is

xeiaso with enough tries it's the same thing

orignal not really because you never have whole ntedb

orignal but better to drop it anyway

xeiaso why wouldn't an attacker have the whole netdb? stats.i2p used to collect RIs

eyedeekay I would challenge the idea that nobody ever has the whole NetDB, somebody with a little time and money can probably get a pretty good picture of a contemporary netDB, they might not have all of it all the time

eyedeekay But they can have a lot of it, maybe as near as makes no matter

orignal because netdb keeps changing all the time

orignal eyedeekay as I said I agree that there is a possibility

orignal and we should avoid it

xeiaso key rotations happen every how long? that's how long a RI would be useful for.

orignal nodays we can't exlude any scenario

eyedeekay Yeah better to be safe

orignal because attach re real

xeiaso and an attacker can try RIs as they come across them

orignal *attacks are real

orignal and we must be prepared for any possibility

dr|z3d "abundance of caution"

eyedeekay Agreed, better to drop before the possibility of an attack

xeiaso drop before the attack could succeed. the attack is real.

orignal also TunnelGateway

orignal DatabseStore is more complicated

orignal because it contains reply instructions

obscuratus Let me make sure I got this straight. RI and LS in an encrypted Garlic Message are OK, but regular unencrypted I2NP RI and LS should be dropped?

orignal no

orignal depends on how they received

orignal if you receive it down a tunnel

orignal you should drop reply instruction

orignal you can't just drop DatabaseStore because it might be reponse to your lookup

xeiaso so uh canon i2p should drop weird inbound tunnel packets too

eyedeekay Yes it looks like it

eyedeekay We may need to study the impact it has first

eyedeekay But yes

eyedeekay Anything else for 2/2.5?

orignal no

eyedeekay All right, good meeting everyone, thanks very much for coming. See you around IRC.

eyedeekay Just FYI, I will be offline Thursday night and most of Friday so I can go meet with my the install technician from my ISP

RN \o/

dr|z3d you can toggle +m now eyedeekay :)

dr|z3d out of an abundance of caution :)

xeiaso unless he's already afk... :)

dr|z3d *thumbs up* RN

RN :)

RN hey, got a ? for you

RN you said a while ago, IIRC that it was easy to switch plus from redirecting to https for the console?

RN I'm not finding in my notes or in the config pages

RN I tried removing the "-s 7667" part but that didn't work

RN removing from clients

RN now HE went afk.

eyedeekay I'm back, just took out the trash

dr|z3d the config is listed on /help/advancedsettings

RN thanks

dr|z3d routerconsole.redirectToHTTPS={true|false}

RN so if I leave the -s the https will still work, just not forced right?

dr|z3d correct.

dr|z3d I think when you're modding the listening ports, a router restart is required.

RN perfect

dr|z3d that config I don't think requires a restart, however.

RN that was what I feared... but if turning off the redirect affects jsonrpc too then I should be good