HBRI IPv4/6 verification for hybrid hubs

Ideas for ADC may be presented here for others to review and point out flaws or further improve the idea.
Forum rules
If you have an account on the wiki, remember to update the ADC Proposals page for new ideas.

http://dcbase.org/wiki/ADC_Proposals_list

HBRI IPv4/6 verification for hybrid hubs

Postby Pirre » 20 Mar 2012, 20:06

Maybe a possible solution for the IPv4/IPv6 verificaton in hybrid hubs supporting both ip versions that works also for IP4 or IP6 only.

A extention called, or can be called "HBRI".

It should be capable to work for the transition IPv4 --> IPv4and6 --> IPv6

Basic hub conduct: the hub removes all the IP related info like the I, U field from the INF string and the TCP4/TCP6 SU fields that are not verified at the end of the IDENTIFY state before broadcasting the INF. (And maybe send a STA if it did)


1) If the hub supports more then 1 IP version and has "HBRI" support, it must
send "HBRI" in SUP during the PROTOCOL state.If client supports more
then 1 IP version and has "HBRI" he must also announce "HBRI" in his
SUP.

2) HUB sends as normall the ISID to client.
CLIENT reponds with his INF.

If hub/client both have SU "HBRI" then

HUB sends ITCP I4"ip address" and I6"ip address" TO"token" (not sure
token is needed)
CLIENT connects to the ip its not connected with and sends HTCP SID
I6/I4"ip address" (the address he connects with) TO"token" (also for passive clients)
HUB verify's SID, TO and if address = 0.0.0.0 or [::] it leaves/puts the
connecting ip in the SID's I4/I6 field else the ip address is
verified en if correct left/put in the correct clients INF field
(this makes also sure NATT gets correct info)
HUB closes socket.
HUB/CLIENT communication go's further as usual.on the intitial H-C
connection.
HUB sends STA to SID with the relevant code regarding the "HBRI"
procedure,

end (lol)

3) HUB verifies as normall (in this stage the non verified INF fields are
removed or client disconnected)
HUB can now broadcast the clients INF string.

On any change of a clients ip addresses in such a hub, the hub must verify as usual and if it's a change regarding the non connected ip the hub must send his ITCP string again and the client should respond like in the login phase.
The the hub verify's the info and takes action before it broadcasts the changes to the clients INF.

The above should make it possible to verify/remove all connection details who can be used for C-C connections in the hub also for passive users and gives NATT both the IP addresses it needs.

If it would be needed that a hub can use 2 different portnumbers for the IP versions this could also be included in the ITCP string that the hub sends.

A pre discusion as this forum was down can be found in the bottom of this post https://bugs.launchpad.net/adchpp/+bug/309402

Main reaso to make it a different procedure then the normall connect procedure is the fact that when you use a single procedure for other things it will always backfire sooner or later and the fact that a CID is not unique outside a hub ...
Pirre
Junior Member
 
Posts: 31
Joined: 10 Nov 2009, 11:57

Re: HBRI IPv4/6 verification for hybrid hubs

Postby Ayo » 20 Mar 2012, 20:34

The wording is a bit hard to read and could use an introduction on what problem it tries to solve, but anyway. :-)
The extension itself looks good to me. One point of discussion, though: Should the hub be allowed to listen on a different port for each IP protocol version? If so, it would be necessary to add two port arguments ("P4" and "P6"?) to the ITCP message.
Ayo
Junior Member
 
Posts: 27
Joined: 23 Feb 2011, 13:50

Re: HBRI IPv4/6 verification for hybrid hubs

Postby Ayo » 20 Mar 2012, 21:32

Oh, and before I really go to sleep, let me dump this note here:

<Yorhel> damnit, I was just about to hit the sheets when a security consideration suddenly entered my head
<Yorhel> the token should be mandatory, and should not be easy to guess by others
<Yorhel> otherwise it's possible for other people in the hub to detect clients who hadn't done that connection yet and do it themselves (they know its SID)
Ayo
Junior Member
 
Posts: 27
Joined: 23 Feb 2011, 13:50

Re: HBRI IPv4/6 verification for hybrid hubs

Postby maksis » 11 Nov 2013, 14:12

I've implemented this extension in AirDC++ and ADCH++ with some changes:

1. Port is added in the ITCP command sent by the hub (P4/P6) and the command only contains information about the protocol that the client should use for verification.
2. HTCP command sent by the client doesn't have SID as I don't think that it's used with H-type commands elsewhere (the user can be identified from the token).
3. The STA code about the validation is sent via the secondary connection (if the connection was established). I also added a new STA code (55) that is sent by the hub if the validation times out.
4. My hub implementation performs the validation after VERIFY state. The client implementation doesn't care about the state so I don't know if there's need to be strict in here.
5. The hub initiates HBRI verification only when the client INF contains an IP address of a secondary protocol INF. The HBRI support is advertised by the client even if it's not using both protocols (the secondary protocol can be enabled later during the session without reconnecting).
6. The HTCP command may also contain SU field to allow better control of broadcasting protocol-specific supports.
7. "Any" address sent for IPv6 is "::", not "[::]"


Here's an example login:

Code: Select all
Hub:      [Outgoing][37.187.144.68:2780]       HSUP ADBAS0 ADBASE ADTIGR ADUCM0 ADZLIF ADHBRI
Hub:      [Incoming][37.187.144.68:2780]       ISUP ADBASE ADTIGR ADHBRI
Hub:      [Incoming][37.187.144.68:2780]       ISID 5CXQ
Hub:      [Outgoing][37.187.144.68:2780]       BINF 5CXQ IDG6SHNIXXWL4JV5OSM3GLMYK7UHOVFKF7GSUIGAY PD NImaksis SL8 FS8 SS18434984661 SF1005 HN2 HR2 HO2 VEAirDC++\s2.70a-23-g49ab7 LCfi-FI DS129000 US1250000 KPSHA256/ARM4IR7W7VCFLF2RJCWLWC2IHVHSEKGYVCQZAZBFXGDFGMAGISRQ SUSEGA,ADC0,TCP4,UDP4,TCP6,UDP6,ASCH I40.0.0.0 U410662 I6:: U610662
Hub:      [Incoming][37.187.144.68:2780]       IINF DEADCH++\sTest\shub VE2.11.0\s(r655)\sRelease HI1 NIADCH++ APADCH++ CT32
Hub:      [Incoming][37.187.144.68:2780]       ITCP I62001:41d0:h:3844::1 P62780 TO1720215383
Hub:      [Outgoing][2001:41d0:h:3844::1:2780]       HTCP I6:: U610662 TO1720215383
Hub:      [Incoming][2001:41d0:h:3844::1:2780]       ISTA 000 Validation\ssucceed
Hub:      [Incoming][37.187.144.68:2780]       BINF 5CXQ I480.223.55.221 U410662 I62001:14b8:100:8546:1000:a050:44ae:cc7f U610662 LCfi-FI IDG6SHNIXXWL4JV5OSM3GLMYK7UHOVFKF7GSUIGAY VEAirDC++\s2.70a-23-g49ab7 SF1005 NImaksis SL8 HN2 HO2 KPSHA256/ARM4IR7W7VCFLF2RJCWLWC2IHVHSEKGYVCQZAZBFXGDFGMAGISRQ HR2 DS129000 FS8 SS18434984661 US1250000 SUSEGA,ADC0,TCP4,UDP4,TCP6,UDP6,ASCH
maksis
Junior Member
 
Posts: 23
Joined: 26 Nov 2010, 19:36

Re: HBRI IPv4/6 verification for hybrid hubs

Postby maksis » 27 Nov 2013, 11:27

A compiled version of the HBRI hubsoft for Windows: http://builds.airdcpp.net/adchpp/adchpp_hbri_r660.7z (see the required changes to get HBRI functional from adchpp.xml)
maksis
Junior Member
 
Posts: 23
Joined: 26 Nov 2010, 19:36


Return to Protocol Ideas

Who is online

Users browsing this forum: No registered users and 1 guest

Powered by SnCMS, and phpBB® Forum Software © phpBB Group

cron