- Test - lists.nanog.org

Teleglobe / Bell Nexxia nexthop problems ?
by Mike Tancsa 25 Apr '04

25 Apr '04

I am not a direct customer of either of them, but have a lot of endpont sites in Quebec which go through 6543 and 577. Anyone from either of those networks know whats up ? Since we usually go through Chicago to reach them, this is the only reason we noticed. There are other prefixes involved, not just the /16 From the teleglobe LG in Chicago, Type escape sequence to abort. Tracing the route to 199.243.35.3 1 if-2-0.core2.Chicago3.teleglobe.net (66.110.14.166) [MPLS: Label 21 Exp 0] 12 msec 12 msec 12 msec 2 if-9-0.core2.Scarborough.Teleglobe.net (207.45.222.181) 12 msec 12 msec 8 msec 3 ix-7-0.core2.Scarborough.Teleglobe.net (207.45.198.2) 28 msec 24 msec 24 msec 4 * * * 5 * * * 6 * * * 7 * * * vs out of newyork, its fine Type escape sequence to abort. Tracing the route to 199.243.35.3 1 if-8-0.core3.NewYork.Teleglobe.net (64.86.83.154) [MPLS: Label 74 Exp 0] 204 msec 204 msec 200 msec 2 if-9-0.core2.Montreal.Teleglobe.net (207.45.222.110) 204 msec 208 msec 8 msec 3 ix-8-0.core2.Montreal.Teleglobe.net (207.45.204.46) 204 msec 204 msec 216 msec 4 core4-montreal02-pos6-2.in.bellnexxia.net (206.108.107.61) 200 msec 200 msec 204 msec 5 64.230.243.238 204 msec 12 msec 12 msec 6 64.230.242.94 16 msec 16 msec 16 msec 7 64.230.242.86 56 msec 52 msec 56 msec 8 64.230.248.178 64 msec 60 msec 60 msec 9 64.230.251.18 464 msec 200 msec 200 msec 10 199.243.35.3 [AS 577] 488 msec 320 msec 444 msec The lg from Chicago says, BGP routing table entry for 199.243.0.0/16, version 4127369 Paths: (2 available, best #2) Advertised to peer-groups: reflector-client Advertised to non peer-group peers: 66.110.14.2 204.255.169.17 206.223.119.39 206.223.138.254 577, (aggregated by 577 206.108.96.201) 207.45.220.252 (metric 45) from 207.45.223.231 (207.45.223.231) Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate Community: 6453:1000 6453:1200 6453:1203 Originator: 207.45.220.252, Cluster list: 207.45.223.231 577, (aggregated by 577 206.108.96.201) 207.45.220.252 (metric 45) from 207.45.222.246 (207.45.222.246) Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best Community: 6453:1000 6453:1200 6453:1203 Originator: 207.45.220.252, Cluster list: 207.45.222.246 -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

1 0

RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200orother vendor ?
by sthaug＠nethelp.no 25 Apr '04

25 Apr '04

> It is a great box. But I need BGP. I notice Cisco does not support 7505 > with Software Advisor but does 7507 whats the deal with that ? There are no differences between the 7505 and the 7507 when it comes to BGP. As for the 3550, it'll do BGP just fine - but it can't handle a full routing table. Same with the 3750. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

RE: Lazy network operators
by Michel Py 25 Apr '04

25 Apr '04

> Paul Jakma wrote: > Hmmm, or rather, there just wont be any demand for > IPv6 deployment, at least from the edges (consumers, > small/medium networks). Oh oh I see another one taking the path that leads to the dark side. _.-'~~~~~~`-._ / || \ / || \ | || | | _______||_______ | |/ ----- \/ ----- \| / ( ) ( ) \ / \ ----- () ----- / \ / \ /||\ / \ / \ /||||\ / \ / \ /||||||\ / \ /_ \o========o/ _\ `--...__|`-._ _.-'|__...--' | `' |

12 17

Re: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 orother vendor ?
by sthaug＠nethelp.no 25 Apr '04

25 Apr '04

> > I bought a Riverstone Rs-3000 for BGP with a single upstream provider. > > Great Deal. > > Yeah, it might be a Great Deal (tm), but you're in for some surprises. > I've seen an RS-8600 (with CM3 and 512MB on board) nearly melt under > 13Mbps of Nachi, to the point that I had to set the CM failover > keepalive timer to >30 seconds. This should come as no surprise - the Riverstone boxes are flow-based. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: Juniper failes to change keys (More MD5 fun: Cisco uses wrong MD5key for old session after key change)
by sthaug＠nethelp.no 24 Apr '04

24 Apr '04

> > After a while I decided to change the MD5 key. The session with the new > > key came up and looked fine, but the old session didn't close properly. > > Notice the close is initiated from the Juniper side, and the first > > packet from the Cisco side is now sent with an invalid MD5 digest - it > > turns out that the packet is actually sent with an MD5 digest based on > > the *new* key: > > This is a feature, and hopefully Juniper will also add the same feature > soon. The feature allows you to change the MD5 key without flapping the > BGP session which is very important on large peering sessions. There is > no requirement that MD5 keys must remain constant throughout an entire TCP > session, or to terminate a TCP session when the key changes. As long as > both sides agree, the key can be changed at any time including in the > middle of a TCP session. New packets after the key change are sent with > message digests based on the new key. But as long as the session *is* reset anyway, the current situation is extremely confusing - the log messages (on both Cisco and Juniper) give no indication that the invalid key in question is for an *old* BGP session, no longer active! Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: TCP/BGP vulnerability - easier than you think
by Iljitsch van Beijnum 23 Apr '04

23 Apr '04

On 21-apr-04, at 22:00, Paul Jakma wrote: >>> Why would MD5 be more of a crypto DoS risk with IPSec AH headers than >>> with bgp tcp-md5? >> Beats me. But why do you bring up IPsec? > The paragraph is quoted is your advice against using IPSec, Unless I was really sleep-typing I didn't say anything about IPsec, just about "crypto", which as far as I'm concerned includes MD5, which we were talking about. > I dont > see why an MD5 auth header IPSec protected sessions would have more > risk of crypto DoS than compared to the simple BGP TCP MD5 hack. The > risk is due to MD5, not IPSec :). As Crist Clark just pointed out: the presence of the SPI and replay counter actually makes it harder to do a crypto DoS against IPsec than the TCP MD5 option (assuming the traffic can't be sniffed). Makes you wonder if those TDM guys weren't on to something with out of band signalling, doesn't it? >> Anyway, what needs to happen is a form of crypto where the >> expensive algorithms are only executed for good packets and not for >> all packets. > So configure ipsec to authenticate packets between the peers allowing > only md5 or somesuch. I dont know about other IOS, but other > implementations do allow one to specify security associations on a > per port basis. Another advantage of IPsec is that it allows for key changes in a sane way. I'm not sure I'd want my routers to run IKE, though. However, note that even a relatively light-weight check such as an HMAC-MD5 can blow away a typical router CPU at orders of magnitude below line rate, so it is essential that attackers don't get to bypass the non-crypto checks for than a tiny fraction of the packets they spoof.

2 1

RE: Backbone IP network Economics - peering and transit
by Michel Py 23 Apr '04

23 Apr '04

> Deepak Jain wrote: > But that structure doesn't vary vastly if you'd traffic out > that gig via transit vs direct connect. It does vary (and > add lots of infrastructure) if you don't aggregate your > traffic at IXes and instead use loops to bring transit to > you instead of going to it. (say a few 100Mb/s or OC3s in > a few places instead of a GigE at an IX). Indeed. > Perhaps we should (for technical reasons) describe > peering as "direct connecting". This makes a lot of sense to me (although I would suggest a different name later). Since the beginning I have been trying to make the point that "direct connecting" was typically a no-brainer in terms of money. Peering when you have to buy the local loop is not such a slam dunk. > Business reasons aside, technically the difference is > that with transit you are expecting access via indirect > connections to networks. I'm not so sure about this. There are lots of people that buy transit and are directly connected to their provider in an IX for example. > With peering you expect direct connections into a network. If "direct connecting" != peering then definitely. Maybe we need to say differentiate between: - Connected transit - Remote transit - Connected peering - Remote peering And agree that, by default, transit ~= remote transit peering ~= direct peering Michel.

3 2

Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYN vulnerability)
by Lane Patterson 23 Apr '04

23 Apr '04

Although someone mentioned using non-routable /30 or /31's on private eBGP peers, there hasn't been much broad-ranging discussion of keeping internal infrastructure addresses non-routable. I am thinking of a couple different things here: 1. Backbone addresses: ISPs that hide interface addresses and/or primary loopback addresses, and best practices for doing so? (e.g. traceroutes don't break, but the router uses say Loopback1 address to respond to them, while iBGP uses Loopback0. All Loopback0 address blocks can be filtered at borders.) 2. Public IX addresses: ISPs that do not redistribute the IX prefix into their iBGP or IGP and do not use external next-hops (except local to the connected border router), but instead use the loopback of the border router when propogating these routes within their iBGP mesh. This should not break traceroutes "through" the exchange, but will break any traffic such as ping, spoofed packets, etc. to the exchange from a non-connected router. Can anyone provide pro/con, better description of config templates for doing this, and/or discussion of major networks that choose to do this, or not do this? Cheers, -Lane

8 10

Re: Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYNvulnerability)
by sthaug＠nethelp.no 23 Apr '04

23 Apr '04

> > (TTL should only be decremented when _forwarding_, and I don't think > > you could argue that you need to _forward_ a packet from your ingress > > interface to your _loopback_ interface..) > > Well, if that were the case, then you wouldn't need multi-hop to do > loopback peering. Different issue (directly connected interfaces vs not directly connected). Easy test: Connect two routers (I used Ciscos) to the same Ethernet switch, sniff the traffic between them. Ping from one router to the other on the directly connected interfaces, observe TTL with sniffer. Ping from loopback on one router to loopback on the other, observe TTL again. I see the *same* TTL in both cases, which means that at least for the IOS version I was testing, TTL is not decremented when sending from the loopback interface. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Point and click tools released for RST/SYN vulnerability
by Mike Tancsa 23 Apr '04

23 Apr '04

http://lists.netsys.com/pipermail/full-disclosure/2004-April/020458.html The full original paper is at http://www.osvdb.org/4030 ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

1 0