[c-nsp] GTSM IOS-XR

[Lukas Tribus]

Hello!

On Tue, 6 Aug 2019 at 19:38, Saku Ytti <saku at ytti.fi> wrote:
>
> If  you are running GTSM in IOS-XR, it does not work. TTL is verified
> during 3-way-sync, not after. So anyone can reset that session with
> trivial amount of packets in subsecond.
>
> Cisco is is having internal problems arguing if this is feature or
> bug. If you are relying on GTSM on IOS-XR today, and this is problem
> for you, I recommend talking to your account team or TAC to create bit
> more internal pressure to help parties inside Cisco who want to get
> this fixed.
>
> This is day1 issue, it has never worked.

Something that has helped me in the past, getting a different and
relevant perspective from someone other than the affected BU:

Reach out to PSIRT [1], and disclose the issue to them, *without
immediately sharing previous TAC/BU discussions and SR ID's with
them*. This forces them to think about the issue itself (it's PSIRT's
job), without all the BU politics involved. Just make sure you "speak
their language" and you use fancy words like "an unauthenticated,
remote attacker can cause a Denial of Service ...". When they
understand the issue technically and agree that it's something they
ought to fix, you share the SR/BugID's with them.

This is how I got them to publish CVE-2014-3347 [2] (when a BRI
interface raises an interrupt for an incoming call while the SPI bus
is already busy collecting entropy from a chip - the box hangs
requiring a cold reboot). Never fixed of course, but at least publicly
acknowledged, which is nice after literally years of troubleshooting
hung routers with TAC (aaah, good times).


Another possibility is to work with a CERT, but that's gonna require a
lot of time and effort.



hope this helps,
lukas

[1] https://tools.cisco.com/security/center/resources/security_vulnerability_policy.html
[2] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/Cisco-SA-20140828-CVE-2014-3347