Mailing List Archive

GTSM IOS-XR
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.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: GTSM IOS-XR [ In reply to ]
Hello!

On Tue, 6 Aug 2019 at 19:38, Saku Ytti <saku@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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: GTSM IOS-XR [ In reply to ]
On Tue, 6 Aug 2019 at 18:38, Saku Ytti <saku@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.

Hi Saku,

Have you tested and verified this? If so how?

For a BGP session for example, I would expect LTPS to drop TCP packets
from any remote IP address which is not explicitly configured as a
peer. Because everyone has 100% deployed uRPF and IP spoofing is an
issue whatsoever in the world, have you managed to find a reliable way
of repeating this issue from an IP address permitted by LTPS?

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: GTSM IOS-XR [ In reply to ]
On Tue, 13 Aug 2019 at 00:18, James Bensley
<jwbensley+cisco-nsp@gmail.com> wrote:

> For a BGP session for example, I would expect LTPS to drop TCP packets
> from any remote IP address which is not explicitly configured as a
> peer. Because everyone has 100% deployed uRPF and IP spoofing is an
> issue whatsoever in the world, have you managed to find a reliable way
> of repeating this issue from an IP address permitted by LTPS?

If you look at the LPTS rules (show lpts pifib entry location ..),
there is no TTL==255 rule for established BGP, only configured. Now to
be fair, I've not actually tried to reset the BGP session, so if there
is in addition software verification of TTL, then it's just punted
unnecessarily and only a DoS vector.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/