I’ve had a couple of mails relating to this PSN, which again references the research that Andy Davidson, Jonathan Oddy and I did last year. It seems that some of the sources of the initial mailing list posts we made are gone (particularly the merit.edu one that is referenced from both Juniper’s site and most other places). For that reason, I’ve included both the mails that we sent to NANOG/C-NSP/J-NSP last year here.
imported Tech · Work · ISP · LINX · Cisco · Code · BGP · IETF · Presentations
Further to my previous post - I presented this issue at LINX65 - video and slides can be found below. Video Fixed Slides - LINX’s PowerPoint install seems to have corrupted my slides on the day. Comments and feedback are most welcome.
imported Tech · Geek · ISP · Cisco · BGP · JunOS
Last Friday, Andy Davidson, Jonathan Oddy, and I pushed out some research that has some quite worrying repercussions. Whilst I’ve heard from a lot of people privately about this matter, there’s a big flaw here, and as Andy posted on his blog (which is much more informative than mine, I think!), this is a big problem. The reason, I think, that we’re getting limited public discussion of this exploit (I hesitate to call it an exploit, it’s a flaw really, because it’s actually a result of the RFC that the problem exists), is because the implementations of 4-byte AS support that are out there already are generally not standards compliant.
imported Work · Cisco
I had a bit of a weird problem last night – when trying to remove BGP from a VRF on a 7600 running 12.2(33)SRC2, I tried: ar01.tn5(config)#router bgp 65302 ar01.tn5(config-router)#no address-family ipv4 vrf SRC2-TEST ar01.tn5(config-router)#exit ar01.tn5(config)#exit One would expect that this would stop BGP redistributing the VRF routes for the VRF SRC2-TEST. In fact, what happens is that the VRF starts reporting ‘debugging-style’ messages: ar01.tn5#sh run vrf SRC2-TEST Building configuration…