Re: [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

[Jared Mauch <[e-mail]>]

> On Dec 7, 2018, at 3:59 PM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Fri, Dec 7, 2018 at 12:46 PM Jared Mauch <[e-mail]> wrote:
> 
> 
> > On Dec 7, 2018, at 12:10 AM, Christopher Morrow <[e-mail]> wrote:
> > 
> > 
> > 
> > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla <[e-mail]> 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.

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.

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