The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <561621C69F17D511A3A20050047340EC01AAF627@VCMD-NT1>, "Ferrell, Willi
am" writes:
> Hmmm.. 
> This sounds like a real vulnerabilty. Just how exploitable it is may be
> worth further investigation.
> Will


This is just a matter of disabling a feature.  In the case of
local-protect, interoperability is acheived by not setting the
local-protect bits.  It is also an implementation that pre-dates the
current fast-reroute draft and this behaviour wrt at least the
local-protect bits is going away.

At worst with the current situation and lacking a work around fast
reroute protection would be defeated.  Considering that this is
pre-standards (deployed though) for FRR, some incompatibilities
between vendors can bw expected as implementations converge on a
common specification.

With soft-preempt, at worst an LSP which is being preempted gets torn
down so in effect soft preempt doesn't work with a particular midpoint
LSR that doesn't support it.

Not much of an exploit in either case.

Curtis


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Tuesday, March 18, 2003 12:35 PM
> To: Adrian Farrel
> Cc: curtis@fictitious.org; Jean Philippe Vasseur; George Swallow;
> mrn@gblx.net; denver@gblx.net; jpv@cisco.com; 'mpls@uu.net'
> Subject: Re: draft-meyer-soft-preemption-00.txt 
> 
> 
> 
> In message <003501c2ed6f$3b708da0$d68a8182@movaz.com>, "Adrian Farrel"
> writes:
> > 
> > Are you sure there are no implementations out there that will tear down =
> > the LSP because of an unrecognized flag in the RRO? :-)
> > 
> > Adrian
> 
> 
> Based on our experience with the local-protect bits, there is an
> implementation out there that we know will tear down the LSP because
> of an unrecognized flag in the RRO but that same implementation will
> send a path-err when it doesn't recongnize the capability request bits
> in the session attributes flags so soft-preempt will be disabled.
> 
> Curtis
>