Wed, Oct 14, 2015 at 05:09:14PM -0400, Jeffrey Haas: > On Wed, Oct 14, 2015 at 08:47:17PM +0000, heasley wrote: > > For debugging purposes, I'd perfer to see ALL protocols have a "cleartext" > > option - not for normal runtime, for debugging. its darwinian, if someone > > chooses to always run cleartext. > > This is actually a big deal with regards to streaming routing protocols. > > It's been my unfortunate experience over the years that most BGP developers > have more than the usual familiarity with the implementation behaviors of > TCP. Even *normal* TCP has ugly properties that negatively impact BGP. > Introduce another couple layers between the protocol PDUs and the final set > of transports and it's a royal pain to do anything about. > > To give a simplified and common issue, when BGP peering sessions on > otherwise quiet links time out, you get to look at things like the TCP > windows to see if your PDUs ever made it out and were advertised on the wire > and acknowledged by the other side. This often requires the sequencing data > from both sides to try to pin down the problems. > > Now introduce the peculiarities of other encapsulations and their > interactions with the underlying timings of the protocol. If I'm running > TLS, how do I know that it hasn't chosen to hold up a PDU for an extra > second or two in order to either have a full enough payload to make the > crypto library happy? > > I realize that these peculiarities can be addressed in the long-run, but I > tend to see these issues as having negative consequences on the operational > stability of the underlying protocol.
I may not follow you; I think that you are saying that by removing the "non-cleartext" path for purposes of debugging, you may have changed the behavior that is causing the thing that you are attempting to debug. I agree with that, but it does not discount the utility of being able to capture whats on the wire for debugging. > > I do not care if your suggested text is added or not; the existing security > > section of the draft covers the subject for me. Nor do I disagree that it > > could support TLS, just do it in a separate draft and move this one along. > > > > I suspect if you examined the idea of TLS as another one of the recommended > transport security options in the context of the existing text, you'd be > fine with that too. By which you mean that, as implied in the security section of the draft, one could run bmp over a vpn, ipsec tunnel, etc implemented external from BMP - yes, I'm happy with the existing text. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
