~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83_
+cancername
+cumlord
+hk
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest19353
Irc2PGuest46029
Irc2PGuest64530
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
acetone_
anon4
anu
boonst
enoxa
mareki2pb
mittwerk
not_bob_afk
plap
poriori_
shiver_
simprelay
solidx66
u5657_1
weko_
RN
where does the underpants come in?
orignal
?
RN
orignal, a southpark fan eh?
orignal
I'm sorry I didn't watch it
RN
underpants gnomes' plan: Step 1) collect underpants. 2) ... 3) profit
RN
you probably saw a meme inspired by that episode...
orignal
and how is it related to my proposal?
orignal
simply "no s - use signing key"
RN
you concluded with "profit"
RN
just humor
RN
not trying to detract from what sounds like a good idea
orignal
seems it's a big challenge to sort it out
orignal
I don't know why
orignal
then I propose simple and dirty solution
dr|z3d
what's wrong with hashing the current router ip with the router's key?
RN
perhaps an over-abundance of caution slows progress. but I like the way things get hashed out before any major changes
orignal
dr|z3d which of 2 keys?
dr|z3d
router's private key.
orignal
which one?
orignal
there are 2 keys
dr|z3d
the one linked to the routerid. that one.
orignal
router ident is hash of two keys
dr|z3d
if it matters. what matters is that the receiving router gets an ip and can cross check it with a signed hash from the router.
orignal
and how does it help against this attack?
orignal
seems you all don't understand what's realy going on
orignal
but what really going on you can "connect" to a fake router
dr|z3d
hmm, I was thinking signing the ip somehow might help, but maybe not.
orignal
by thinking you are connected to it
orignal
but actuualy connected to another one
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?