Subject: [mpls] Stephen Farrell's Discuss on draft-ietf-mpls-mldp-node-protection-05: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 15 Sep 2015 05:18:44 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-mpls-mldp-node-protection-05: Discuss

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-mpls-mldp-node-protection/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The MUST in para 2 section 3 seems to me to create a possibly
new DoS enabler. The ability of N to cause this kind of ripple
effect, (setting up then pushing traffic to a bunch of new
LSPs), is what may be new. Exactly where in the referenced RFCs
is that covered? Or am I wrong that this is a new threat? (BTW:
Answering that this new threat is no worse than other existing
threats if one has access to the internals of a node.... is a
non-answer:-)

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

While it is fine to re-use text, it is increasingly hard to
believe that almost nothing done since RFC5920 (dated in 2010)
has any new security considerations.  Put another way, who is
really helped by a 2 line security considerations section that
points at 6388 which points at 5036 (etc)?

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 16 Sep 2015 08:54:11 +0200

Hi Steven,

Does Adrian’s proposed text solve your ‘DISCUSS’?

—
  The procedures in this document add two new TLVs to existing LDP
  messages.  Those TLVs can be protected by the mechanisms that are
  used to protect LDP messages as described in [RFC6388] and [RFC5920].
  If it were possible to attack the mechanisms described in this 
  document an LSR (a PLR or a MPT) could be induced to support a large
  number of tLDP sessions and set up an even larger number of LSPs.
  The security mechanisms in [RFC6388] and [RFC5920] are believed to be
  adequate, but an implementation could provide additional protection
  by counting such protection sessions and LSPs and producing a log
  message to the operator if a threshold is crossed.
—

Thx,

Ice.

> On 15 Sep 2015, at 14:18, Stephen Farrell <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Sep 2015 09:34:00 +0100

Hiya,

>   document an LSR (a PLR or a MPT) could be induced to support a large

Can't "N" also cause the potential DoS, if N is the compromised LSR?
But the main thing is that once this mechanism is supported, any LSR
(that is compromised) could try use this as a DoS vector/accelerator.

>   message to the operator if a threshold is crossed.

Yes, that text seems about right and good enough to clear
when you post a revision with that in it.

I could maybe quibble about the current security mechanisms being
adequate bit (are they really? say in a network with a small but
persistent percentage of compromised routers?) but I'll not quibble
in this case, as I guess that is a more general problem and it'd
not be right to try force a solution via this document.

Cheers,
S.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 16 Sep 2015 11:15:29 +0200

Hi Stephen,

> (that is compromised) could try use this as a DoS vector/accelerator.

Yes, I guess it does.

> when you post a revision with that in it.

Cool, will do.

> not be right to try force a solution via this document.

Thx!,

Ice.