Subject: [P2PSIP] RELOAD overlay configuration document

From: Jouni Mäenpää <[email-masked]>
Date: Mon, 21 Dec 2009 15:34:25 +0200

Hi,

One question about the "bootstrap-node" element in the RELOAD overlay
configuration document. In the example configuration document included
in the RELOAD base draft, the bootstrap-node element has the following
contents:

<bootstrap-node>192.0.0.1:5678</bootstrap-node>

My question is that should the element also specify whether the
bootstrap node should be contacted using DTLS or TLS? In that case, the
element could perhaps look as follows:

<bootstrap-node>
  <address>192.0.0.1</address>
  <port>5678</port>
  <proto>TLS</proto>
</bootstrap-node>

Or is the assumption that the bootstrap node uses the same port for both
TLS and DTLS?

The above format would also make the bootstrap-node element more extensible.

Cheers,
Jouni

---

From: jc <[email-masked]>
Date: Mon, 21 Dec 2009 11:36:55 -0500

> Or is the assumption that the bootstrap node uses the same port for both

The same port is to be used, ideally it would be the RELOAD port.

> The above format would also make the bootstrap-node element more extensible.

There is debate about mandatory D(TLS) as THE base "secure" protocol which if not mandated MUST be placed in the XML configuration document. This would not be placed in a bootstrap-node element but rather in the root of the XML.

> 
> Cheers,
> Jouni
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: jc <[email-masked]>
Date: Mon, 21 Dec 2009 12:39:45 -0500

Jouni,

I should have mentioned that I use a dual-stack (IPv4 and IPv6) and ALWAYS accept both DTLS and TLS connections. So every node has (if applicable) a transport acceptor on IPv6 & IPv4 both TLS and DTLS capable and bound to the RELOAD port. ICE handles choosing DTLS and TLS out of the box via Attach for all other Nodes however I leave the DTLS or TLS decision for bootstrap up to the Node and use TCP first.

Julian Cain

---

From: jc <[email-masked]>
Date: Tue, 22 Dec 2009 13:04:21 -0500

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?

> 
> 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. 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.

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.

Julian

> Ari

---

From: Ari Keranen <[email-masked]>
Date: Tue, 22 Dec 2009 14:50:13 +0200

Cheers,
Ari

---

From: jc <[email-masked]>
Date: Wed, 23 Dec 2009 12:14:56 -0500

On Dec 23, 2009, at 2:49 AM, Ari Keranen wrote:

> jc wrote:
>>> Is this (explicitly) stated somewhere in the draft? If so, also I
>>> have missed it. If it isn't, perhaps it should be.
> 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.

> 
>> 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.

> 
>> 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.

---

From: Ari Keranen <[email-masked]>
Date: Tue, 29 Dec 2009 10:34:44 +0200

jc wrote:
>>>> Is this (explicitly) stated somewhere in the draft? If so, also
>>>> I have missed it. If it isn't, perhaps it should be.
>> 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.
>> 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.

>>>  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.

>>> 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>

over the original format:

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

---

From: jc <[email-masked]>
Date: Tue, 29 Dec 2009 11:15:03 -0500

On Dec 29, 2009, at 3:34 AM, Ari Keranen wrote:
> 
> 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>
> 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.
> 

I don't prefer this format. I see no value in adding <proto> and moving the port, at least not in my working implementation. You may want to get input from others.

---

From: Ari Keranen <[email-masked]>
Date: Wed, 30 Dec 2009 09:38:32 +0200

Eric Rescorla wrote:
> On Tue, Dec 29, 2009 at 12:34 AM, Ari Keranen
>> 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>
>> 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.
> 
> I have no problem with this suggestion.
> 

OK, thanks!

Cheers,
Ari

---

From: Jouni Mäenpää <[email-masked]>
Date: Wed, 30 Dec 2009 09:42:08 +0200

Hi,

Ari Keranen wrote:
> the points we have discussed, prefer the following format (or
> something similar) for the bootstrap-node element:
>
> <bootstrap-node>
> DTLS, but you are not forced to do so. Also, this makes the element
> much more extensible.

I like the new format since it is easy to extend.

Cheers,
Jouni