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 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. -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
