#saltr (irc2p) | I2P+ 2.7.0-11+ >> 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

RN if there are two keys associated with the real router, why not use both of them together to 'sign' or create something to verify? or use one for 'first round' and other one for 'additional verification' when needed?

orignal I'm not going to point finger, but NOBODY took this problem seriously since last summer

RN I haven't seen 'nobody' sign onto this irc in a long time

orignal RN an advesary can also sign an address with signbing key and produce valid RI

RN (we used to have a user with the name 'nobody')

dr|z3d now is not the time for flippancy, RN :)

RN but it would not be the correct signing key?

RN sorry dr

orignal if this issue was addressed properly we din't have this problem today

RN I thought the point of signing is to prove you are the only one with that key

orignal but we have heard "write a proposal" simly meaning "fuck off"

dr|z3d then you heard it wrong.

orignal RN absolutely right, but this attack doing oppiste

RN no. write a proposal means 'write up the details in a formal manner' so we can pick the issue apart to find solutions

orignal dr|z3d the proposal was written many months ago

orignal and who picked the issue?

orignal nobody

orignal I kept chasing idk with this issue for couple months

orignal then gave up

RN you did

orignal then zzz that ended up with another "write a proposal"

orignal RN do you understand what is the nature of the attack?

orignal and why it's even possible?

RN I would say I have a basic understanding how it works as a ddos

RN very basic

dr|z3d just to be clear, we talking about i2p-projekt.i2p/spec/proposals/163 ?

orignal no it's opposute

orignal ddos when an andesray use own resources to flood the netwrok

orignal here he uses the network to flood the network

orignal 163 is from weko?

RN ok, so triggering something that propigates.

orignal I don't have I2P open right now

dr|z3d no, wrong link.

orignal I'm talking about one for SSU2

orignal no signatures will help against this attack

dr|z3d this one, sorry. i2p-projekt.i2p/spec/proposals/165-ssu2-fix

orignal yes, 165

orignal in two words when you connect to a router through SSU2 you can't verify if you connect to that router

dr|z3d so we need a test as part of the initial handshake.

orignal and your handshake will be successive as long as you use right public "s"

orignal handshake must include router's indormation

orignal NTCP2 uses router ident

orignal as AES key

orignal so my idea is

orignal use router's signing key as "s"

orignal crypto key is not better than "s"

orignal an adesary can clone it too

orignal also I really don't undeestand what do we need two keys for in router identity

orignal one ed25519 key is enough for both purposes

dr|z3d what are the downsides?

dr|z3d I'm hearing accidental DDOS mentioned wrt mitigations, not sure I understand that.

orignal str4d would said that I'm a fucking idiot

orignal that's not right to use same key for different purposes

orignal proposal 165 contains right solution but nobody cares

RN saying nobody cares doesn't help move things forward

orignal that's why I offer simplier alternative

orignal that requores much less work

RN it is clearly documented you were concerned about this and the current state of affiars proves you were right

orignal I'm really disappointed that this old attack still takes place

orignal the attack that has right mitignation year ago

orignal the problem now is that only powerfull floodfiils can handle this attack from entire network

orignal because other routers try to build tunnels through fake routers

orignal ofc the next step of advesary will be to clone all routers with public ips

orignal not only floodfills

orignal that are less powerful than floodfiils

dr|z3d yeah, but sybil detection takes care of some of the issues, albeit at the expense of legit routers that had their ips cloned.

orignal and even worse

dr|z3d which is not to say it's sufficient, because obviously it isn't, but it's a partial mitigation for some of the effects of the attack, not the attack itself.

orignal say I'm cloned floodfill trying to build an IB though you

orignal and since I'm banned on your side this requst will never reach me

orignal if SSU2 didn't have this hole

orignal nobody could cnnect to a fake router and recognized it as dead

orignal but other router recognize it as alive

orignal and trying to send data

dr|z3d it will be fixed, and elegantly, you know how zzz operates. festina lente :)

orignal I don't see any evidence of it so far

dr|z3d sometimes it takes a prolonged attack to bring things into sharp focus.

orignal the attack keeps going

dr|z3d exactly.

dr|z3d it can't be ignored, in other words.

orignal yes we did something from our side

orignal to keep rate 10%

dr|z3d corrupt sessionconfirmed packets all over.

RN there you go Unbur.

Unbur i take it im not the only one facing connection issues[q]

Unbur i have hours upon hours of 'remote host closed socket' everywhere

Unbur thats the attack isnt it[q]

not_bob Correct.

not_bob We are under attack.

not_bob RN!

not_bob Unbur: If you run i2pd, do a pull from the git and recompile.

not_bob Otherwise, install the latest dev build of I2P+ and that should help out quite a bit.

RN not_bob!

not_bob What's up!

orignal what is corrupt sessionconformed about?

dr|z3d SSU2 handshake failure.

dr|z3d Seeing a huge amount of those right now.

dr|z3d here's some example output:

dr|z3d […andler 9/10] …blishmentManager: [SSU2] Received CORRUPT SessionConfirmed

dr|z3d • Router: [SSU2] InboundEstablishState 94.31.73.241:18806

dr|z3d • Lifetime: 282ms; Receive ID: -1257312924431045244; Send ID: 1799018147142317883; Token: 2698197131991171618 IB_STATE_FAILED

dr|z3d • IES2 Payload Error: [SSU2] InboundEstablishState 94.31.73.241:18806

dr|z3d • Lifetime: 282ms; Receive ID: -1257312924431045244; Send ID: 1799018147142317883; Token: 2698197131991171618 IB_STATE_CREATED_SENT

dr|z3d routers that ignore session termination packets are also pretty regular in the logs, sending 10,20 packets after session terminated.

dr|z3d both events possible symptoms of the attack?

orignal yes because they stared changing "s"

orignal ofc it doesn't match and crypto fails

dr|z3d possibly something to target, though it may be a case of addressing the symptom rather than the cause.

orignal we see bunch of clones with changed "s"

orignal I think they are trying to load routers with crypti

orignal because you can only recognize it in SessionConfirmed

orignal shared key mismatch

dr|z3d thinking out loud, I wonder if the fleet of chinese routers before the attack got into full swing suggests a nation state level attack.

orignal or it's just "salt" guy

dr|z3d he'd have been on your irc server by now taunting you.

dr|z3d hmm

orignal so any plans to resolve this SSU2 issue?

orignal for now we plan to not try to connect through SSU2 if NTCP2 failed for a non-confirmed router

orignal unrtunately we have to do some hacks

dr|z3d what about sybil detection, are you doing anything with that?

orignal partially like not pick tunnel from close IPs

orignal but current attack is not sybil

dr|z3d sure, but sybil detection routines that see too many routers on the same ip covers the current attack, albeit with side effects.

orignal no, because it also bans real routers

orignal that's not what we want

dr|z3d yeah, that's the side effects part.

orignal it's not our way

dr|z3d sure, it's something we all want to avoid.

orignal as result we have very low rate of floodfills

orignal becuase you guys ban us

orignal seems your response causes more troubles than the attack itself now

orignal another idea

orignal why can't we sign RI using "s" private key and include into address?

zzz orignal, weko, re: prop. 165 "taken seriously" -

zzz that will happen when you schedule a review, which you haven't done in 3 months

zzz nor did you even mention it between january and last week

zzz also, the proposal is a mess of alternatives, sub-alternatives, and sub-sub-alternatives, some with major compatibility problems that can't be taken seriousl

zzz also, none of the alternatives have enough detail to be implemented, even if I know which to choose

zzz I suggest to update the doc in light of recent events and to fix problems, and then schedule a review

zzz alternatively, you could schedule a pre-review discussion, if you'd rather do that before updating it

orignal my point is the problem exists for a long time

orignal and now we have this problem

orignal so you don't have own view how to fix this SSU2 hole?

zzz I don't even know what your recommendation is, because your proposal is a convoluted bag of alternatives. Please document what you want to do, and I'll evaluate it.

orignal to send Bob router ident

orignal during handshake

orignal also I offer 2 more alrenatives

orignal to use signing key for s

orignal or add signature of router identity to an address

zzz so write it up

orignal ?

orignal it's above

zzz I can't make any sense of "(1) can (2) should (3) no support (4) support" etc. in the proposal

zzz send me a patch to prop 165 markdown. I'm at the same place I was a year ago. Document your recommendations and schedule a review

orignal I'm on meeting

orignal will be back in 15 moinutes

orignal what is 1,2,3, 4?

orignal <orignal> why can't we sign RI using "s" private key and include into address?

orignal my today's idea

orignal every address in RI includes signature of router indenttity signed by "s" key

orignal this prevent advesary to insert an address to his fake RI

orignal and shit will be detected on earliest stage

orignal e.g. s signs router

Unbur finally im back. i think my connection issues are because of the attack.

Unbur how can i help[q]

orignal what do you think about my idea?

orignal sign addresses inside RI

Unbur im unfemiliar with the innerworking of i2p and the terms used around it. so i have no clue what RI is

Unbur from what i do know, maybe something similar like what tor uses to verify user sessions. a local computational proof bit that would scale horribly but is still doable for real users

Unbur it could limit the devices i2p can run on but most devices should still work

orignal_ do you understand the problem?

Unbur not really no

orignal what's the nature of the attack

orignal an adverasy copies address from real routers and insert them into his fakes

orignal and if someone tries to connect to such fake router they get connected

orignal to that IP of real router

orignal believe that fake router is real

orignal why it happens? because there is the hole in SSU2 protocol

zzz Alice (should(1), can(2)) send in payload RouterIdent block Flag_0 = 0 and Bob’s RouterIdent. Bob (should(3), can(4)) check

orignal zzz, there are few options to implement this

orignal but it my opinion, Alice should send Bob ident hash in SessionRequest if she needs to verify Bob

zzz right. there's dozens of combinations of them in your proposal. Make some choices please.

zzz so fix your proposal.

orignal if Bob recieves such block and ident doesn't match he must terminate

orignal the reason for this

zzz I can't make any sense of it and definitely can't implement it

orignal no crypto is being called from Bob's side if ident is wrong

orignal so it's not requeired from Alice to send this block if she knows Bob already

orignal but Bob must validate it

orignal please tell me what's wrong

orignal Alice can, Bob must

zzz there is no "must" in the proposal. only "can" and "should"

zzz and those are choices listed, some of which have compatibility issues?

orignal then shoud instead must

orignal and Alice "can"

orignal no compatibinty issue

orignal Only "unknown block" for older version

snex this kinda stuff would be a whole lot easier if we had an automated test suite and cleaned up the code

zzz it's not a proposal yet, it's a list of interlocking ideas. Make some choices, you probably know more than you did 3 months ago, and update it

zzz and specify your backward compatibility requirements

orignal I didn't do it weko did

zzz "With (1) Alice does not support old routers. With (2) Alice supports old routers."

orignal I know only what I would like to see

zzz then isn't (2) a requirement?

orignal Alice should rely on this block for new routers only

orignal and check router version first

zzz it has your name on it. fix it up so it makes some sense and matches your current recommendations

orignal where do I change it? on github?

orignal ok. time to rebuld and update

zzz orignal, I need a patch against the .rst file from github

zzz orignal, weko, you say the new block contains a router ident, I believe you mean a router hash

zzz orignal, weko, preliminary thought: a crypto solution like MixHash() or XOR (as you describe in the notes section) would be better than a new block

orignal so I make a patch and then PR>?

zzz orignal, weko, is all of this useless until a year from now when we can ban old versions?

orignal router ident hash

zzz no, patch and email

orignal e.g. 32 bytes sha256 hash

zzz router ident = full 391 byte identity

weko [16:36:19] <zzz> orignal, weko, you say the new block contains a router ident, I believe you mean a router hash

weko It is same terms, isn't?

zzz no

weko zzz: thanks, will know

zzz fix all this (1) (2) (3) (4) can/should stuff to say: If Bob is >= version X, ALice must do this, otherwise, Alice must do that. If Bob sees this, bob must do that, otherwise bob must do something else

weko [16:37:09] <zzz> orignal, weko, preliminary thought: a crypto solution like MixHash() or XOR (as you describe in the notes section) would be better than a new block

weko Yes, you said it earlier, it is reason why I wrote it in notes

orignal MixHash of what?

orignal I didn't get your point

orignal wouldn't it break compatibimity?

orignal I see now. One more call of MixHash at the end

zzz e.g., set a flag in the session request header, then xor or MixHash() Bob's hash in somewhere

zzz orignal, weko, please assess and document the security of any recommended solution. Also consider a scenario where the attacker controls the 'real' router rather than just cloning somebody else's

zzz orignal, weko, in NTCP2 we simply XOR bob's hash into alice's ephemeral key. Is that not sufficient? Why are you proposing something completely different?

orignal if I remeber it's AES key

orignal for SessionRequest encryption

orignal because SSU2 doesn't use AES

orignal SSU2 uses "i" key instead

orignal i2p::crypto::CBCEncryption encryption;

orignal encryption.SetKey (m_RemoteIdentHash);

orignal that's what we do in NTCP2

zzz you're right, it's AES encrypted with bob's hash as the key

zzz not a simple XOR

orignal AFAIK this is only place where we use Bob's ident

orignal I did this analisys last summber

zzz in ssu2, we already have one layer of obfuscation, with the header encryption

orignal however

orignal why can't we use ident hash as "i" ?

zzz so maybe xor is enough? don't know. The idea was just to make it hard for DPI

zzz that's your section 3

orignal what is section 3?

zzz in your proposal that has your name on it ))

orignal "i" doesn't break compatibility

orignal unlike other changes in crypto

orignal in SSU2 with xor derived from chacha20

zzz compatibility is not broken if you design it right.

zzz old must be able to talk to new and vice versa. that's a requirement

orignal another problem with NTCP2

orignal you know that address from wrong router

orignal only when you receive SessionConfirmed

orignal e.g. advesary forces you to do whole handahske

orignal that CPU greedy

zzz that's noise XK. authenticity is not assured until the handshake is complete

orignal ideal solution is to let Alice know before trying to connect

zzz I still have no idea what your recommendation is, section 2 or section 3 or both or something new you haven't documented yet

zzz I'm more confused than I was a year ago

dr|z3d here's an idea, apologies in advance if it's naive.

dr|z3d if session request includes the remote router's ip in the packet, and the details are screwy, can't we just take the ip and ban that router without affecting the valid router?

orignal who should do it?