20 aug 2008 kl. 12.50 skrev Dave Cridland:
On Wed Aug 20 11:24:54 2008, Johansson Olle E wrote:
20 aug 2008 kl. 12.08 skrev Dave Cridland:
On Wed Aug 20 07:37:32 2008, Johansson Olle E wrote:
3) Clients may be behind NAT, so even a client-to-client direct
session may need help from a server (proxy). This will have to
be considered.
This is a non-issue - we have Jingle, so we have the ability to
negotiate various channels, at least one of which (IBB) will work
through any amount of NATs and firewalling, albeit at a cost of
efficiency and ugliness. Really, this whole debate about IBB vs
NATs vs whatever is immaterial; we have Jingle specifically to
solve all these problems, and it passes the buck to ICE-TCP et al
to solve the tricky cases.
After spending many years with SIP and NAT traversal, I know that
we will still need NAT traversal proxys, ICE/STUN is just a
discovery service. And considering a possible future with IPv4 and
IPv6, there will be proxys there too. Any solution has to work
with an unknown or wellidentified point in the middle.
For the record, I'm saying that we, here, don't need to care at all
about NAT traversal because this problem is either solved, or else
needs to be solved by Jingle and not by us and not here.
Well, if you want end to end TLS, there's some architecture examples
that will be affected by a middle man. Take the example of the OTR
"proxy" :-) I mentioned earlier. No one really
bother to check the OTR fingerprints, so they would not discover the
proxy, unless the client reacted the way my ssh client reacts to a new
key fingerprint.
You need to be aware of this when designing a solution. Requiring TLS
encryption of the stream after connection setup won't really be
affected as much as using the TLS connection certificate/keys, where a
middleman can
present a different set of keys.
/O
