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

[IJsbrand Wijnands <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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)?
> 
>