Re: [GnomeMeeting-list] Major ILS change

Hi Craig,

> You get three pieces of information from the user:
>   a) the IP address in the ILS request
>   b) the port in the ILS request
>   c) the IP address that the ILS request comes from (from getpeername)

that one is true, however quoting damien (and believing what he wrote on
gm-devel this is done in 2 phases.. and unfortunatelly b) is stated only
in the 2nd phase)

> By definition, c) is always going to be a legal public address. If it is
> a private address, then the ILS is being spoofed - throw the request away.

fully logical. ;)

> If c) is the same as a), or they are both public addresses, then there
> is very good chance that the user has a public address, or has good NAT
> software. Either way, don't bother doing a portscan - just accept the
> info (you can do the portscan if you like - but I bet it will work 99%
> of the time)

sorry, but from the practical support on #gnomemeeting the 99% is *FAR*
from realistic.. if it were like 70% you'd already be counting high, but
most probably the real number is around 30-50% because people read very
scarely the FAQ about ports.. However with those running on public IP it
*USUALLY* is the problem that they forget UDP ports rather than TCP
ports and thus the scan of tcp1720 wouldn't help very much (but that's
nother story).. Anyway i would vote STRONGLY for doing it anyway.

> If c) is different from a), and a) is private, then the user is behind a
> NAT firewall and does not know it. Then, you need to detect if they can
> actually receive a call. There is no way we can be sure, but if we check
> port b) on address c) and there is a socket listening, we can give them
> the benefit of the doubt and assume they are able to receive calls.

this is technically challenging as this requires the registration to go
into the 2nd phase before rejecting the request. Nevertheless, I'm with
you that this is the valid solution.

What i wonder is: can't we recode some ohphone/openmcu code to form a
server which will just provide sanity checks and then disconnect with a
message in the GM text-chat? As the text-chat runs through tcp1720 it
should be perfectly working through NAT even when the h323-NAT is
misconfiugred. And ohphone/openmcu should have enough code to just
handshake valid protocols and thus calling like
"" could tell you "Check passed. You are
configured correctly." or "Check failed. You didn't open UDP/RTP

How this could be implemented with NetMeeting i currently lack a
proposal though. Maybe some webpage or ticket system for the IP with a
webpage for the incoming call IP could be held for the user. Or the ILS
registration will use the ticketing system. To me this does sound not
like the one solution, but like a means that users could need to fix
their broken config..

Best regards,

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]