re: Re: File downloading

Completely true: Hole punching does not even require that an active session is established with a third party. On 
many routers is is just enough to punch a free port in order to open or maintain a forwarding rule within the 
router, in order for incoming packets (including incoming session requests) to reach the intended peer bhing the 
firewall or proxy. 

TLS by itself requires initiating a session with a third party, but the condition for it is that it must be 
reachable, so any intermediate router must still be traversed successfully. Hole punching is there to help the 
intermediate routers to maintain an active route to the peer behind the proxy or firewall.

By itself, hole punching offers no security, no authentication. It is just used by the router to indicate that 
there's a peer listening on that port, and that is ready to accept any random packet sent from unknown remote sites. 
It also indicates to the router to which host on the local private LAN to forward these incoming packets. So hole 
punching works in a way similar to UPnP forwarding rules, but it will work where UPnP is not usable or not 
implemented by the router.

The bad thing about hole punching is that this punching is temporary and it must be renewed regularly, as long as 
the forwarding rule has not been used by some other active session or other incoming/outgoing UDP traffic using the 
same pair of ports. Today, hole punching is deprecated and should not be used if UPnP is available, but UPnP has its 
own caveats: its forwarding rule will remain mostly perfmanently within the router, even if the intended recipient 
is no longer active and another unrealted port may be used without notive by another unrelated program : in fact it 
is not different from manually registering a port forwarding rule within the router.

Well-behaved UPnP-compatible servers should discard their UPnP forwarding rule when the server is being shutdown. 
Using UPnP is more economical in terms of bandwidth and stability than hole punching, which is really a trick that 
will generally work only on non-UPnP routers, but UPnP-compatible routers should ignore the hole punching technic, 
for security reasons, if their UPnP capability is already enabled.

TLS is unrealted here: it has nothing to do in terms of protocols within the router. The router perceives any TLS 
session as a normal TCP session, and it just just maintain the port forwqarding rule as long as the TCP session is 
active. There's no direct support of TLS in routers over a sessionless transport like UDP, even if TLS could be 
supported by emulating TCP over a UDP channel (in that case, UPnP port forwarding or hole punching or any kind of 
UDP traffic over the UDP chennel, including no-op, ping-like traffic, will maintain the port forwarding in order to 
support the session emulation).

So why are you speaking about TLS here? It's just because TLS is typically used in the context where a server is not 
directly reachable with active hole punching of its own router, or its own UPnP configuration of its local router, 
or by manual configurtion of a static forwarding rule in ots local router. In that case, the server will have to 
open an active session permanently to another proxy host found somewhere on the Internet and reachable there. TLS 
will be used to secure the traffic between the proxy and that firewalled server. The TLS session will remain active 
as long as the firewalled server is there. In that case, this TLS session is transparent to the other random clients 
somewhere else on the Internet, that will only see the proxy.

another use of TLS will be transparent for the proxy, but can be used in end-to-end sessions forwarded by the proxy: 
the random clients and the proxied server will just communicate through a VPN-like secured channel, that the proxy 
does not need to authenticate and manage itself. In that case, TLS will be used to anonimize the traffic between the 
random clients and the server, so that even the proxy will not be able to inspect the state of communications 
secured through the forwarded session.

All these are general considerations, they are not specific to Gnutella, but are related to network topologies and 
infrastructures and the level of security implied in each trafic forwarding domain managed by various (unknown) 
third-parties.

> Message du 07/09/09 09:21
> De : [email protected]
> A : [email protected]
> Copie à : 
> Objet : [the_gdf] Re: File downloading
> 
> 
> Quoting rik_saunderson  from ml.gnutella.dev-forum:
> :How do common implementations of hole punching and TLS work? Am I correct in
> :thinking that Hole Punching and Push Proxying are one and the same thing? If
> :not, how does it actually work in a gnutella context?
> :What's the process by which two servents engage in a TLS file transfer?
> 
> Hole Punching and TLS are two orthogonal concepts.
> 
> The process by which two servents engage in a TLS file transfer is that the
> connecting party issues a TLS request to the other TLS-enabled servent.
> It knows that the remote servent is TLS-enabled due to the presence of
> TLS indication in query hits, head pongs, push, alt-locs, etc....
> 
> Raphael
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>