Subject: [Pals] Stephen Farrell's Abstain on draft-ietf-pals-rfc4447bis-05: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 28 Sep 2016 06:59:07 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-pals-rfc4447bis-05: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It is an embarrassment that we can't do better than TCP MD5.
TCP MD5 (from 1998, RFC2385) has been obsoleted by TCP-AO
(RFC 5925, from 2010), but that hasn't seen deployment.

Back in 1998 (18 years ago!) RFC 2385 included an IESG note
that says:

"This document describes current existing practice for
securing BGP against certain simple attacks.  It is
understood to have security weaknesses against concerted
attacks."

And all these years later we can still do no better when
promoting a document to IS.  Sigh.

However, I see no point in trying to block this document on
that basis. 

I would argue for an IESG note along the above lines if I
thought that'd have any impact, but I guess it won't if, as
seems to be the case, people won't move until there's a
catastrophic break.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 28 Sep 2016 10:40:46 -0700

> https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/
realistically one has to bound what consitutes a catastrophic break.
since the desgin goal is to provide protection against in-window-packet
injection to offlink attackers.

there's a bit of subtext in 2385

   To spoof a connection using the scheme described in this paper, an
   attacker would not only have to guess TCP sequence numbers, 

which is nonsense because the problem was you didn't have to guess the
sequence numbers, on most major routing platforms when that was written.

 TCP already does that probabilistically for basically everything except
onlink attackers we can re-litigate why vendors produced tcp stacks that
violated the protocol specification but the fact of the matter is they
did at time time and saw this as a pallative... it is nothing more than
a pallative for tcp reset injection from offlink attackers.

These things are in practice never rekeyed and in practice the password
is the same everywhere in the provider. personally I consider it's
inclusion a question of invulnerability with existing implementations
and the repsonsibility for protecting one's control-plane from offlink
attackers is elsewhere.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Sep 2016 19:12:29 +0100

On 28/09/16 18:40, joel jaeggli wrote:
> the repsonsibility for protecting one's control-plane from offlink
> attackers is elsewhere.

I'd hope so. And I believe so.

That said, I still find it sad that we've not improved upon
what we thought was broken 18 years ago. I do include myself
in that "we," though clearly those (not;-) implementing in
this space bear most responsibility.

S.