Juniper PSN-2010-01-626 (AS4 Again!)

         imported      Tech · ISP · Cisco · JunOSe · BGP · IOS · JunOS

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.

LINX 65 Presentation

         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.

32-bit AS numbers introduce a new BGP flaw.

         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. Let’s run down the list:

Removing BGP from a VRF under 12.2(33)SRC2

         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...

% Topology SRC2-TEST::VPNv4 Unicast::base is currently being deconfigured.
% Topology SRC2-TEST::VPNv4 Unicast::base is currently being deconfigured.
% Topology SRC2-TEST::VPNv4 Unicast::base is currently being deconfigured.
% BGP context has not been initialized properly.
% Topology SRC2-TEST::VPNv4 Unicast::base is currently being deconfigured.
% BGP context not been initialized properly.
% Topology SRC2-TEST::VPNv4 Unicast::base is currently being deconfigured.
% Topology SRC2-TEST::VPNv4 Unicast::base is currently being deconfigured.
Current configuration : 340 bytes
ip vrf SRC2-TEST
 description :c=CORE:x=rjs test for ar01.tn5 issues:
 rd 5413:1020
 export map EXPORT-MAP-SRC2-TEST
 route-target export 5413:1020
 route-target import 5413:1022
!
!
ip route vrf SRC2-TEST 10.0.0.0 255.255.255.0 Null0
!
router bgp 65302
 !
 address-family ipv4 vrf SRC2-TEST
  redistribute static
 exit-address-family
end

And you then can’t get rid of the BGP from the VRF. It turns out the fix for this is to remove the VRF itself – or, rather than removing the address-family itself, remove the contents of the address family. I’m not entirely sure that this is designed behaviour – and I couldn’t seem to find any further results for it. I guess it needs to be put into TAC as another Cisco weird.