North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Winstar says there is no TCP/BGP vulnerability

  • From: James
  • Date: Wed Apr 21 05:46:57 2004

> Wouldnt anti-spoofing filters largely eliminate the need for all this 
> panic about MD5?

egress filtering, yes...
 but not everyone does this and thats what poses the panic i guess :(

ingress filtering... largely yes, but no? consider the scenario:

someone runs traceroute to you (Joe ISP) doing bgp with your upstream (Blah Transit)
14. aggr10-fe-0-0-0.nyc.blah-transit.net (5.5.10.102)
15. joe-isp-gw.customer.blah-transit.net (5.5.254.130)

assuming the usual setup, spoof the source ip to 5.5.254.129 and start fiddling
with your router, or spoof to 5.5.254.130 and fiddle with your upstream aggr
router.

ingress filtering won't help in this situation. GTSM although... would...

rather a very stupid workaround to think about:

Haven't tested on other vendors, but at least in Cisco, you can half-way hide
your single hop peering address showing up in traceroute by putting the assigned
p2p address as secondary and spoofed/bogus ip as primary. However, users behind
your network such as customers can still guess by looking at your upstream's
aggr router showing up in outbound trace.
i.e.
interface Serial2/0
 ip address 7.7.7.1 255.255.255.252
 ip address 5.5.254.130 255.255.255.252 secon

Anyhow the idea is that IOS replies icmp with interface's primary ip, not
secondary. so traceroute would show 7.7.7.1 instead of 5.5.254.130.

if i were you... i would only do that on ebgp interfaces, and not on any core/
internal interfaces.....

I still think good way around is use different address other than what shows up
in traceroute to maintain EBGP sessions. Not the best solution, but largely
secure as long as you and your peer don't publicly provide such information.
No need to worry about md5 implications or password management etc. If really
concerned, supplement it with GTSM to make it bit stronger.

For looking glass.. use a different loopback addr to peer up looking glass/
route server to your routers. use different set of non-publicly-known loopback
addrs to maintain ibgp sessions.. Again, not The solution, but better than
nothing compared with implications with md5 deployment.


-J

-- 
James Jun                                            TowardEX Technologies, Inc.
Technical Lead                        Network Design, Consulting, IT Outsourcing
[email protected]                  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net