jc wrote:
On Dec 23, 2009, at 2:49 AM, Ari Keranen wrote:
jc wrote:
On Dec 22, 2009, at 7:50 AM, Ari Keranen wrote:
Is this (explicitly) stated somewhere in the draft? If so, also
I have missed it. If it isn't, perhaps it should be.
The RELOAD port is clearly documented in draft. Isn't this
enough?
IMHO, not really.
There many are cases where you could want to run RELOAD on a
non-standard port. For example, if the RELOAD port is already
reserved by some other application (everyone doesn't follow the
IANA recommendations), or you want to run multiple instances of
RELOAD on a single machine using different ports, or perhaps you
are behind a middlebox from which you can get a port forwarded but
can't decide the exact port number, or maybe you just don't want
your ISP to easily detect (by looking just into port numbers) that
you're using RELOAD.
And what about if a node wants to use a different port number
for TLS and DTLS? I think Jouni's proposal for explicit port
numbers per protocol and structured bootstrap-node element
makes sense.
Nowhere in the draft is dual-stack nor dual-transport ever
mentioned.
For example AttachReq lets you define the transport protocol to
use. Doesn't that imply that you are free to mix UDP and TCP (DTLS
and TLS) connections in the overlay?
Your assuming all connection setup uses AttachReq which is false. You
may have missed what I said, if you re-read you will see that I mix
TCP and UDP freely but it isn't discussed in draft.
What other ways except Attach did you have in mind for setting up a
RELOAD connection? Or are you referring to bootstrapping procedures?
Anyway, my point was that even the current draft, while not being too
explicit about it, supports simultaneous TCP and UDP (with different
port numbers too) for setting up connections between peers so the
configuration document should be in line with this. Or at least it would
not hurt.
Having said that a Bootstrap Node would never listen on two ports
with two different transport protocols, its one transport
protocol or the other. My implementation decision doesn't roll
over into the draft. Keep in mind that the draft doesn't outline
this scenario whatsoever and it introduces several caveats.
I think it would make sense to do like your implementation does;
but in addition support different ports. What kind of caveats did
you have in mind?
Well for one the discussion on which transport to use for bootstrap
and under what conditions? I currently use UDP and fallback to TCP
for bootstrapping. I prefer UDP however it very well may be blocked.
Implementation should try one and if that doesn't work, try the other;
which one to try first would be up to the implementation, and your
approach would fit well into that idea.
IMHO the topology-plugin element should provide transport and or
ciphersuite information because RELOAD isn't smart enough to
choose DTLS over TLS and so on. Only the topology plugin can
supply this recommendation to the underlying base.
Maybe, but likely even the topology plugin can't know whether TCP
or UDP is a better choice before running ICE.
ICE is generally run before anything by the topology plugin. It is up
to the topology plugin to decide which of the ICE transports to use
once ICE negotiation has completed.
Yes, something like that should work.
But back to the original question: wouldn't you also, considering all
the points we have discussed, prefer the following format (or something
similar) for the bootstrap-node element:
<bootstrap-node>
<address>192.0.0.1</address>
<port>5678</port>
<proto>TLS</proto>
</bootstrap-node>
over the original format:
<bootstrap-node>192.0.0.1:5678</bootstrap-node>
With the new format you are free to use the same port for both TLS and
DTLS, but you are not forced to do so. Also, this makes the element much
more extensible.
Cheers,
Ari
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
