On Fri, Dec 7, 2018 at 1:17 PM Jared Mauch <[email protected]> wrote:
> > > > On Dec 7, 2018, at 3:59 PM, Eric Rescorla <[email protected]> wrote: > > > > > > > > On Fri, Dec 7, 2018 at 12:46 PM Jared Mauch <[email protected]> > wrote: > > > > > > > On Dec 7, 2018, at 12:10 AM, Christopher Morrow < > [email protected]> wrote: > > > > > > > > > > > > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla <[email protected]> wrote: > > > > > > routing area (key agility, a stronger algorithm than MD5). And of > course TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate > on what you're referring to here? > > > > > > > > > "TCP-AO is a lie, there is zero deployable code anywhere that supports > it" > > > > > > was that the gist of his comment? > > > it'd be the whole of mine... because honestly it's the truth. > > > > I had written out a series of concerns around the requirements operators > have.. I can’t find the paper around my office right now I wrote them on, > but the went roughly like this: > > > > 1) We have long-lived TCP sessions, measured in years. (Implied: many > of the transport people really prefer stable routes without > flapping/jitter/reordering from us) > > 2) We use protocols that are stable as a result as transports > > 3) Security area does review and says “why is MD5 still a thing” without > considering #2 and #1 above > > 4) When doing routing things like an iBGP mesh, key rotation can be > complex in a multivendor environment when the catastrophic failure of the > network substrate is the consequence of a software bug > > 5) If these keys (md5) are in use, they’re not rotated because we got > that support much later than the ability to set/rotate them and > coordination with a network partner to rotate them is feasible but reaches > operational impossibility. > > 6) We need protection from tampering with the transport, not encryption > of the transport. You will know where the routes go because I assume > you’ve used a tool like traceroute before. > > > > I think most of these points are reasonable (I'd quibble about #3) but > they're not very actionable. > > > > If you're position is that TCP-MD5 is all you need (and maybe not even > that) then OK. > > It has problems, I’d like something “better” and a path to get to that > better thing. I just built a Greenfield network and we used some better > methods than my prior employer was able to use. We often get technology > lock-in when we use things for “security” purposes. > > > If what you want is some protocol with other, different, functions, then > you're going to need to be a lot clearer about what it is you *do* want, > not just what you *don't* want. > > I’m speaking about the operator challenges we have. I don’t have a draft > that’s getting caught up in sec-dir review because it still uses TCP-MD5 > because there are no TCP-AO or other implementations, or a migration path > to them. > Well, drafts don't get stuck in sec-dir review, because those reviews are non-blocking. And I'm pretty sure that neither Ben or I are holding discusses on any such drafts. If so, can you list them, please? > What I am is an operator that has experience in running a network, trying > to be minimalist in my responses to the badness, and keep it up so the > higher protocols can do their thing. When it gets problematic is when I > can’t differentiate something good from something bad as easily and people > decide to shift that line. I’m warning you where the guard rails are, they > may get moved. > > This entire draft I see in the subject/cc line is part of that, here’s > what operators are doing. EH’s are a cool idea, but they are also a > security risk in that they may end up in the punt path or significantly > impact performance of the forwarding plane in a way that could cause the > networking substrate to cease to function as desired. These are things > operators will work hard to protect to ensure it’s working. The network > has limits and just because it works in some hardware doesn’t mean it will > work in it all. > I have no position on IPv6 EHs. -Ekr > We are stuck today in many cases with whatever we get in a BCM Chipset and > that doesn’t appear to be changing (although I hope it does change, and > there continue to be options in the market). > > There are many protocols that need to be cleaned up, just like most people > stopped running chargen on their routers after it was used as an attack > vector. The same was done with changing the defaults around “ip > directed-broadcast” behavior. Expecting intermediate network elements to > honor requests in EH’s is not likely to change. > > - Jared > > > >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
