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) On Sat, Mar 13, 2010 at 11:15 AM, Cullen Jennings <[email protected]> wrote: > > 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. > > > On Mar 9, 2010, at 12:24 PM, David A. Bryan wrote: > >> 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) >> >> On Tue, Mar 9, 2010 at 2:20 PM, Cullen Jennings <[email protected]> wrote: >> > >> > 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: >> > >> >> 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 protected]> Date: >> >>> Sun, 7 Mar 2010 11:42:22 To: [email protected]<[email protected]> >> >>> Cc: Cullen Jennings, Ph.D.<[email protected]>; >> >>> [email protected]<[email protected]>; Jouni >> >>> Mäenpää<[email protected]>; >> >>> [email protected]<[email protected]> Subject: Re: [P2PSIP] RELOAD overlay >> >>> configuration document >> >>> On Mar 7, 2010, at 11:30, "David A. Bryan" <[email protected]> >> >>> 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 _______________________________________________ P2PSIP mailing >> >>> list [email protected] 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 >> > >> > >> > >> > _______________________________________________ >> > P2PSIP mailing list >> > [email protected] >> > 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 > > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
