Subject: Re: [P2PSIP] RELOAD overlay configuration document

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Mar 2010 12:10:28 -0700

I was fixing this and it was just not obvious to me if if we really needed the TLS flag. Anyone have strong arguments one way or the other?  Regardless of TLS decision, it makes sense to split out the address and port. 

Cullen

On Dec 21, 2009, at 6:34 AM, Jouni Mäenpää wrote:

> 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
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: jc <[email-masked]>
Date: Sun, 7 Mar 2010 14:13:53 -0500

If your splitting out the port I'm for this.

Sent from my iPhone

On Mar 7, 2010, at 2:10 PM, Cullen Jennings <[email-masked]> wrote:

>
> I was fixing this and it was just not obvious to me if if we really  
> needed the TLS flag. Anyone have strong arguments one way or the  
> other?  Regardless of TLS decision, it makes sense to split out the  
> address and port.
>
> Cullen
>
>
>

---

From: "David A. Bryan" <[email-masked]>
Date: Sun, 7 Mar 2010 19:30:38 +0000

Would we add text indicating that different ports somehow imply different transport/security mechanism (since there were many many folks who supported mandatory to implement but not mandatory to use for (D)TLS on list)? I'd personally prefer having the flag too, so users can choose both port and mechanism to make that easier.

David (as individual)
Sent from my mobile device

-----Original Message-----
From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Mar 2010 12:10:28 
To: Jouni MÃ¤enpÃ¤Ã¤<[email-masked]>
Cc: [email-masked]<[email-masked]>
Subject: Re: [P2PSIP] RELOAD overlay configuration document

Cullen

Cullen Jennings

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Mar 2010 11:42:22 -0800

On Mar 7, 2010, at 11:30, "David A. Bryan" <[email-masked]> wrote:

> Would we add text indicating that different ports somehow imply  
> different transport/security mechanism

If you mean use the port to indicate separate security mechanism  
without an explicit indicator in the config file, I don't see what  
that adds.

Ekr

---

From: "David A. Bryan" <[email-masked]>
Date: Sun, 7 Mar 2010 22:00:05 +0000

Yep, I agree, that's kind of my thought as well, so for my part, I'd rather see the flag and make it a bit more explict.

David (as individual)

-----Original Message-----
From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Mar 2010 11:42:22 
To: [email-masked]<[email-masked]>
Cc: Cullen Jennings, Ph.D.<[email-masked]>; [email-masked]<[email-masked]>; Jouni MÃ¤enpÃ¤Ã¤<[email-masked]>; [email-masked]<[email-masked]>
Subject: Re: [P2PSIP] RELOAD overlay configuration document

Ekr

---

From: Ari Keranen <[email-masked]>
Date: Tue, 09 Mar 2010 16:00:15 +0200

I would support an explicit flag.

Also, since a single bootstrap node is likely to support multiple 
options, it could make sense to have something like:

<bootstrap-node address="192.0.0.1">
    <port proto="TLS">5678</port>
    <port proto="DTLS">6789</port>
</bootstrap-node>

or

<bootstrap-node>
    <address>192.0.0.1</address>
    <port proto="TLS">5678</port>
    <port proto="DTLS">6789</port>
</bootstrap-node>

The latter is a bit more verbose, but more consistent with the rest of 
the schema preferring XML values over attributes.

Cheers,
Ari

David A. Bryan wrote:
> Yep, I agree, that's kind of my thought as well, so for my part, I'd
> rather see the flag and make it a bit more explict.
> 
> David (as individual) Sent from my mobile device
> 
> 
> -----Original Message----- From: Eric Rescorla <[email-masked]> Date:
> Sun, 7 Mar 2010 11:42:22 To: [email-masked]<[email-masked]>
>  Cc: Cullen Jennings, Ph.D.<[email-masked]>;
> [email-masked]<[email-masked]>; Jouni
> MÃ¤enpÃ¤Ã¤<[email-masked]>;
> [email-masked]<[email-masked]> Subject: Re: [P2PSIP] RELOAD overlay
> configuration document
> 
> 
> 
> Ekr _______________________________________________ P2PSIP mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/p2psip

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Mar 2010 12:20:50 -0700

So I was sort of hoping to get reasons why the flag was needed (or not). 

On Mar 9, 2010, at 7:00 AM, Ari Keranen wrote:

> Also, since a single bootstrap node is likely to support multiple options, it could make sense to have something like:
> 
> The latter is a bit more verbose, but more consistent with the rest of the schema preferring XML values over attributes.
> 
> 
> Cheers,
> Ari
> 
> David A. Bryan wrote:
>>> Would we add text indicating that different ports somehow imply different transport/security mechanism
>> If you mean use the port to indicate separate security mechanism without an explicit indicator in the config file, I don't see what that adds.

Cullen Jennings

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 9 Mar 2010 14:24:23 -0500

Unless I am missing something, it is needed to specify what protocol
is used to contact the bootstrap peer. Again, how can one otherwise
know how to contact the bootstrap peer if and using what protocol if
the overlay isn't using (D)TLS? If that is specified somewhere else in
the XML, you don't need it here, but I don't see a mechanism about the
security protocol being used specified anywhere else.

David (as individual)

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 13 Mar 2010 09:15:41 -0700

Let's say we added a new transport. Just to make a concrete example, lets say someone defined a IPsec based transports, it seems to me that the RFC that defined the new transport would also specify a configuration option for the config XML  to say that the ring required use of IPsec. Now an node forming a new link would know that it needed to use that link layer protocol. I'm not seeing how the attach to the bootstrap node is different from any other attach in this regard. I don't care one way or the other how it gets done, it's just not clear to me yet what is needed. Totally agree we have to understand how this works. I'm just not clear yet on what people want. 

Cullen Jennings

---

From: "David A. Bryan" <[email-masked]>
Date: Sat, 13 Mar 2010 13:28:59 -0500

As long as I have a way to specify an alternate transport/security
model, I'm pretty flexible, and the more I think about it, the right
place for the flag may very well be to have it lower, in the root of
the config, rather than with the bootstrap field (since, as you point
out, this really isn't specific to the bootstrap peer/process, that
just happens to be the first time you need to know the transport).

The one thing I'd personally prefer is to have a field that specifies
the transport by default (including TLS in the base case) rather than
an assumption that it if it isn't present we use TLS. My reasoning
being to make clear what the behavior of a peer that only implements
TLS will be when it gets a bootstrap with an unsupported transport. It
might not understand the extension in the XML if it's not in the base
(i.e., what do I do if there is one parameter in the XML I don't get)?
If it just ignores it, it would try to connect with TLS (and fail). I
think it's better to understand that parameter, and recognize it is a
value for transport that isn't supported.

(Which just now made me think of one out there question...should we
allow multiple values for the field? I guess the overlay could allows
connections with different transports...haven't really thought about
that. If we do that, then is there a need to specify which ports the
bootstrap accepts which transport on? Personally, i think this may be
more bother than it is worth, and I can't really think of a good
reason for it, but mentioning it for completeness in case someone else
knows a reason why we might need it)

Not sure about others, but to be clear what I want: I just need some
way to build an overlay that doesn't have to use TLS, even for the
bootstrap case, and ideally, a way so that base clients that implement
only TLS can tell (from the config) that they won't be able to connect
before trying. Otherwise, I have no particular need for the flag to be
on the bootstrap per-se, modulo my question above about multiple
transports.

David (as individual)

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Mar 2010 11:40:16 -0800

> value for transport that isn't supported.

I don't have a problem with this.

> knows a reason why we might need it)

I think this is a bad idea.

-Ekr