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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, Dec 7, 2018 at 12:46 PM Jared Mauch <jared@xxxxxxxxxxxxxxx> wrote:


> On Dec 7, 2018, at 12:10 AM, Christopher Morrow <morrowc.lists@xxxxxxxxx> wrote:
>
>
>
> On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla <ekr@xxxxxxxx> 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.

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.

-Ekr




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux