#ls2 (irc2p) | #ls2 proposal review channel

zzz we must handle this situation, and the entire design of SSU2, with connection IDs, was developed with connection migration in mind, to improve what we do over SSU 1

orignal agree

zzz no, because android/mobile can change IPs also, we must support IP changes even if not firewalled

orignal I disgree

zzz why?

orignal if somebody publishes port in thier netdb

orignal it must be consistent

zzz then if you change, send your new RI to everybody?

orignal if I'm in situation when my port is changed by ISP

orignal I must be firewalled

zzz sure, but maybe you thought you were not firewalled, and then your port changes.

zzz so then you do a peer test and discover you really are firewalled

zzz you have to tear down all your sessions?

orignal if I'm not firewalled how it's possible?

orignal if my port changes I should reconnect

zzz maybe you assumed you were not firewalled when you started up

orignal them my sitation is mess anyway

orignal and I should clear it

orignal e.g. if my status is OK while I'm firewalled

zzz I don't understand why it would be necessary to put limitations on when we can migrate connections and when we can't. Why not just allow it no matter what?

orignal no reason, just my thoughts

orignal about possibilities

orignal then another question

orignal if I publish port and discoved my external port is different

zzz ok, well obviously we will get smarter about it in the next few weeks as we implement it

orignal should I run peer test again?

orignal of swith to firewalled

orignal my point is I want to understand how we might come to this situatation and how to handle it

zzz yeah if something changed I'll run at least two peer tests and look for the same result

orignal good pount

orignal that's what we should start from

zzz fyi - 1HmrG9 is a port-hopper that does respond to path challenge

orignal if port mismatches we start peer test

zzz that's the only one right now that will respond

orignal maybe older version

orignal maybe I did something worng

zzz yeah the others won't answer. lEKII is the most frequent hopper

zzz I won't send it unless the port changes :)

orignal see the mistake

orignal but still should reponse

zzz I also have seen CEFnjX hop from 6345 to 1044 and then back to 6245

orignal just don't copy chalenge

orignal will fix

zzz oh ok, good

orignal but you should get it back, maybe with worng data

orignal a minor bug

zzz I'll look at the logs later

zzz any other questions or comments on the spec for now? we'll definitely talk about it more in a few weeks

orignal not now

orignal question

zzz zlatinb, eyedeekay you have any comments?

orignal can I just change endpoint without path challenge for now?

zzz i don't think that's a good idea because an attacker could mess things up

zzz but that's kinda what we do for 10 years in java SSU 1

orignal after payload decryption ofc

zzz at least for port changes. We won't change IP in SSU 1

orignal how can they do it?

zzz an on-path attacker that copies or modifies a packet to change the port

orignal if they copy it will be out of sequence

orignal e.g. already handled

zzz usually the threat model says an on-path attacker can delay or reorder packets, so they could put the modified one first

orignal agree

zzz but it's not very likely, for sure

zzz I think any strategy would be ok for one release

orignal anyway let's not do it at least for this release

zzz yeah I'm not sending any path challenge in trunk, there's no code checked in

zzz anything else on 2) ?

orignal no

zzz 3) ipv6-only routers

orignal but it's good Ihave found a bug

orignal so, route48

orignal more and more people use it becuase it works trough wireguard tunnel

orignal and they don't ask questions

zzz interesting

orignal and many people like to use ipv6-only routers to hide own IP from netdb

orignal similiar to ygg but magnified

orignal now the qeustion itself

orignal they complain they see too small transit

orignal and we know the reason

orignal because they can be chosen as an intermediate participant

orignal not OBEP or IBGW

orignal and I asked myself why

zzz and what was your answer to yourself? :)

orignal I know the answer

orignal but when we pick tunnel pairs in one direction we can check transport compatibilty between tunnel endpoiunts

orignal that's basically my question if you are capable to do it

orignal the answer for myself it's not a problem for me

orignal because I can pick tunnels this way

orignal I do it alerady if need to talk to i2v6-only floodfiils

zzz capable to do what? BE a ipv6-only OBEP/IBGW or SELECT a ipv6-only OBEP/IBGW ?

orignal say you have 5 OB tunnels

orignal and you have 5 leases in remote LeaseSet

orignal can you check that a pair is compatible?

zzz ok, the question is do we check OBEP/IBGW compatibility when specifying the route

orignal OBEP of your OB and lease

orignal yes

orignal basically

zzz I don't think so...

orignal that's why I'm asking if you are able to implement it

zzz I'll have to research and get back to you

orignal yes

orignal no rush

orignal but potentially we will see more and more ipv6-only

zzz we really need more ipv6 routers, only about 1/3 have v6 now

zzz anything else on 3) ?

orignal my concern is ipv6-only router

orignal ipv4 + ipv6 are fine

orignal no

zzz sure, but the more v4+v6 we have, the better the v6-only will work ))

zzz anything else for the meeting?

zzz StormyCloud, dr|z3d, how is the outproxy holding up?

zzz thanks everybody