Re: verio arrogance
In the referenced message, Ralph Doncaster said: That said, their current policy of refusing to accept de-aggregated prefixes from peers (while accepting such from paying customers) makes perfect sense, IMHO. Not arrogant, just a smart reasonable business decision. I have one downstream ISP customer that explicitly asked for full BGP routes to be written into the contract. Why Verio's customer's wouldn't want full routes makes no business sense to me. However a NANOG list subscriber was kind enough to help me get past Verio's NOC monkeys and get their filters updated to allow my announcements. -Ralph Accepting any route from anyone doesn't make much business sense to me. At least if you are interested in a quality network. If you'ld like, I'm sure multiple ISPs would be happy to send you all of their /32s. Verio's policy seems like a very responsible way to run a network. I'm saddened that more folks don't do filtering based upon RiR policy. Not announcing your largest aggregates is just plain stupid. If your peers are willing to accept more-specifics tagged no-export, with MEDs, then go for it, but the rest of us don't need them. I'm a little disappointed in Verio, if they really did decide to accept your unneccessarily deaggregated prefixes.
Re: verio arrogance
In the referenced message, Stephen Stuart said: I can't really see why, as long as the provider has punched the appropriate hole for your aggregate in their filters. More specific routes always win out. Or am I missing your point? The point, I think, is the effort involved in using global route announcements to solve your traffic engineering problems. When you use provider-assigned space, you have to coordinate your intent to add entries to the global routing table with the provider who assigned the space and the providers that you want to accept the new routes. When you use provider-independent space, you get to decide to add entries to the global routing table pretty much all by yourself, modulo running afoul of the occasional provider that does not, by default, buy into solving local traffic engineering problems in other people's networks using global routing table entries. Stephen Not to mention that the common retort is that everyone else in the world should upgrade their CPU and memory to solve a third parties traffic engineering problem. Thereby transferring the cost to others. The verio (and others) mechanism involves a stated policy soundly derived based upon RiR allocation policy. A policy which, if everyone announced their aggregates would lead to no blackholes during steady-state. If parties feel the need to exchange long prefixes, they can do so privately, without infecting everyone. In fact, many providers exchange regional routes, tagged no-export, for such mutual agreed-upon optimal traffic exchange purposes. This should, however, be constrained to those parties who mutually agree upon it. However, there are some who want to handle their traffic engineering needs preferably by transferring the costs to others. This is just shady, even if it makes perfect business sense from a capitalistic maximize profit no matter what the consequences mind set. I wonder how the anti-filter folks would feel if all of their providers/peers ceased filtering out iBGP routes on the sessions facing them. Would they begin scrambling to filter? If so, where would the line be drawn? Some arbitrary prefix-length, or based upon a published length obtained from some allocation authority? What about if everyone ceased filtering out their iBGP routes, and just leaked it all? Looking at only a single router, I could add another 8538 prefixes into the routing system. Certainly everyone could handle 9k more prefixes, right? Ok, then we get to do that across all my routers. Then across all providers. This is all in the name of optimal routing, right? What's a couple million routes between friends?
Re: verio arrogance
In the referenced message, Ralph Doncaster said: I'm a little disappointed in Verio, if they really did decide to accept your unneccessarily deaggregated prefixes. I'm a little disappointed you're wasting list bandwidth after this has been well discussed, and not a single post has offered a better technical alternative to de-aggregating my ARIN /20 (given my network topology). -Ralph Announce your largest aggregate, and announce more-specifics tagged no-export to those peers who agree to accept them? Upgrade the connectivity between your sites? (although I could have sworn I saw someone else make the above suggestions, already)
Re: DOS attack from PANAMSAT
In the referenced message, Clayton Fiske said: On Sun, Jul 07, 2002 at 03:08:14PM -0400, Richard A Steenbergen wrote: On Sat, Jul 06, 2002 at 06:24:40PM -0500, Rob Thomas wrote: Hmm, not according to the data I collect. I track numerous botnets and DoSnets, and a bit over 80% of them use the real IPs as the source of the floods. Then again, with 500 - 18000 bots, it isn't all that necessary to mask the source IPs. :/ There are only two situations where a DoS uses its real IP, 1) the network filters spoofed source addresses, 2) they havn't compromised root. Don't forget 3) the machine compromised isn't capable of spoofing. In Win95/98/ME/NT, there is no raw socket functionality. I don't know the breakdown of botnets in terms of which platform they typically harvest for hosts, but I'd imagine Windows represents a significant portion of non-spoofed attacks. -c I believe it is fairly trivial to add this functionality to these machines. Even if the addons weren't part of the payload, the worm could go snag it off the public internet and install it.
Re: Valid ip address ?
In the referenced message, JothirLatha Jaganathan said: Can any one tell me if the last byte of a point to point or loopback ipaddress with 32 bit mask can be 0 or 255? For e.g.: Is 10.1.1.0/32 a valid interace address? Yes, it is valid, as is 10.1.1.0/31, for ptp links.
Re: ATTBI refuses to do reverse DNS?
In the referenced message, Daniel Senie said: At 02:30 PM 6/18/02, Lou Katz wrote: snip Is this common? I have a CDPD card which has a fixed address. It's from Verizon Wireless. There's no INADDR. There seems to be a lack of understanding and clue all around on INADDR, which is the motivation for the above-mentioned draft. Having something to point network operators and server operators to would, IMO, help. The lack of clue tends to be on the providing in-addr side of things. I think it is a great thing to refuse connections from ips without in-addr, in the same way it is great to refuse mail from domains that don't provide postmaster addresses. It is a means through which one can influence the laziness of others. Simply disregarding what others do, only legitimizes the laziness, and continues us along the road of everyone doing the absolute minimum. Simply accepting the connections seems to be a path of least resistance which befits a pointy-hair more than an engineer. -- I suppose I could set up a bogus reverse for him, but, feh... Either you set up something, or you can make your server not care about reverse, or lose the customer. You neglect to include the option of the customer changing to an ISP that provides in-addr.
Re: What's wrong with provisioning tools?
In the referenced message, David Daley said: snip 4) There isn't anything to track non sanctioned changes to the network (i.e.: hacker induced re-configurations) I would be really surprised if anything other than mom-and-pop shops didn't have _at least_ this. rtrmon or rancid can do great config archiving and provide difference output.
Re: Bogon list
In the referenced message, Stephen J. Wilcox said: On Thu, 6 Jun 2002, Stephen Griffin wrote: In the referenced message, Sean M. Doran said: Basically, arguing that the routing system should carry around even more information is backwards. It should carry less. If IXes need numbers at all (why???) then use RFC 1918 addresses and choose one of the approaches above to deal with questions about why 1918 addresses result in messy traceroutes. Fewer routes, less address consumption, tastes great, less filling. Sean. Do you: 1) Not believe in PMTU-D RFC1918 does not break path-mtu, filtering it does tho.. sending RFC1918 addressed packets across enterprise boundaries is against RFC1918. RFC1918 states to filter ingress/egress at enterprise boundaries. Hence, filtering RFC1918 addresses is part of RFC1918. Therefore, the use of addresses where they are likely to generate traffic which violates RFC1918, is, well, a violation of RFC1918. This applies regardless of the ICMP error message generated. 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries (of which an exchange would be a boundary) What for? You'll find many more much more mailicious packets coming from legit routable address space. Who said anything about malicious? In any event, ICMP error messages are generally useful with a few minor exceptions. Things like Source Quench, unreachables, TTL expired, and Can't Frag (as examples of useful icmp.) snip For p2p you can use unnumbered.. it wont work on exchanges but i agree they shouldnt be rfc1918. I agree, however, most folks want to see the topology, some just choose to violate RFC1918 in order to do it. Steve
Re: Bogon list
In the referenced message, Sean M. Doran said: Basically, arguing that the routing system should carry around even more information is backwards. It should carry less. If IXes need numbers at all (why???) then use RFC 1918 addresses and choose one of the approaches above to deal with questions about why 1918 addresses result in messy traceroutes. Fewer routes, less address consumption, tastes great, less filling. Sean. Do you: 1) Not believe in PMTU-D 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries (of which an exchange would be a boundary) 3) Not believe packet-passing devices have legitimate needs in contacting hosts, even if hosts don't have legitimate needs for contacting them? (a superset of 1, above) 4) All or some of the above? I would love if RFC1918 were adhered to such that L3 packet-passing devices either weren't numbered out of those blocks, or allowed what juniper allows with the ability to select the ip address with which packets sourced by the L3 packet-passing device sent traffic (other than primary ip on destination interface). The latter would permit intra-enterprise use of RFC1918 addresses, while still conforming with RFC1918. Failing that, use of RFC1918 addresses in places where inter-provider packets get RFC1918 sources, is a violation of RFC1918. In any event, exchanges are inter-enterprise, and shouldn't be RFC1918.
Re: Interconnects
In the referenced message, Sean Donelan said: On Fri, 17 May 2002 [EMAIL PROTECTED] wrote: perhaps better late than never... PAIX LINX both have IPv6 capabilities at/on the exchange fabric(s). I am not aware that Equinix has taken that step. Uhm, another dumb question. Why does the operator of a layer 2 exchange care (or know) what protocols your are using? IPv4, IPv6, heck I remember seeing Appletalk, OSI and DECNET on MAE-EAST. What consenting network operators do They probably only care on broadcast-based protocols, since is more than the consenting networks. Might also include multicast, which could then get you into the realm of pim snooping, which might then get you up into the ipv4 and ipv6 arena.
Multicast at broadcast exchanges
Hmm, I was thinking about the topic of multicast at broadcast exchanges, and had a weird thought. Presently, the various participants may have divergent peering relationships and routing preferences. Such that RPF choices for the same (s,g) can go back to different places. If I remember correctly, all PIM routers on the same broadcast domain will elect a designated router, to keep from sending the same traffic for the same group multiple times. If network A is preferring network B (via localpref, for example) and network C is preferring network D, such that A rpf's to B for prefix E and C rpf's to D for prefix E, how would this be resolved? What if A doesn't peer with D at all, and C doesn't peer with B? Wouldn't one of B and D send the traffic, such that the other isn't sending any, regardless of the policies of any of the networks involved? What if the elected DR isn't one of B or D? The only workaround I could see, would be if the multicast traffic were unicasted across the exchange (much like how things are at the atm peering points). However, this nulls out the benefit of having a multicast broadcast exchange.
Re: BGP and aggregation
In the referenced message, Ralph Doncaster said: BGP will discard any prefix with its own AS in the path, for loop prevention. Hence, one half of the AS would still be unable to reach the other half. This is why a partitioned AS is a failure condition. A tunnel is a means to keep the AS nonpartitioned. I was thinking of doing iBGP over my transit connections (with a couple of static routes so the iBGP works) AND over my inter-city circuit. Any reason why this won't work? -Ralph The loss of igp metric will make it untenable at best. Do it over a GRE tunnel, with your regular igp (isis, ospf, eigrp, or shudder rip). default routes have their own problems which only treat the symptoms of a partitioned as, rather than the problem.
Re: BGP and aggregation
In the referenced message, Austin Schutz said: On Mon, May 13, 2002 at 06:57:19AM -0400, PS wrote: Multiple ASNs wouldn't solve anything in this case. What was wanted was under normal circumstances both A and B only announce a /20, and when the link between A and B breaks announce more specifics. Multiple ASN = inconsistent AS.. no no. Not necessarily. If 'A' originates the aggregate route it can still be transited via 'B', though with an additional AS hop. Not a perfect solution, but then neither is running a gre tunnel. Austin The only perfect solution is having multiple internal paths which are resilient to simultaneous outage. Failing that, I've never had a problem with GRE. Back in 1994-1997 or so, I used them a lot for disconnected sites, much as someone else mentioned, across sprint. Worked great and was certainly cheaper than interlata circuits.
Re: BGP and aggregation
In the referenced message, E.B. Dreger said: * BGP is an EGP, not an IGP BGP is one half of an IGP, it is the where to go half. You generally run another IGP along with it to provide the how to get there half. Most folks run isis or ospf to transport router loopbacks and other next-hop information, but still transport the majority of routes via bgp.
Re: BGP and aggregation
In the referenced message, Andy Walden said: On Sun, 12 May 2002, Stephen Griffin wrote: In the referenced message, Andy Walden said: Conditional Router Advertisement: http://www.american.com/warp/public/459/cond_adv.pdf As it sounds like he's using a single AS, the above may not be a fix, since a partitioned AS is still a failure condition. Why? If you announce one prefix via one circuit and announce a different prefix via a different with the same source AS, I don't see a problem since traffic will continue to reach its intended destination. andy BGP will discard any prefix with its own AS in the path, for loop prevention. Hence, one half of the AS would still be unable to reach the other half. This is why a partitioned AS is a failure condition. A tunnel is a means to keep the AS nonpartitioned. There are other ways to treat the symptoms, but they aren't particularly good, imho.
Re: ratios
In the referenced message, Dean S Moran said: Plus, wtf is this clause about announcing 5000 routes? What a crock of s**t! This really encourages aggregation, doesn't it? It would be more responsible if they had a minimum number of fully aggregated (by origin-as) routes This would, hopefully, prevent folks from merely deaggregating to meet the number. Hopefully, that number would be significantly less than 5000. Some time back, I look a look at all routes with origin as701, and came up with: 2165 total routes 1846 routes after removing more-specifics (not even going the extra step to aggregate what was left) 319 pointless more-specifics (same origin, so no additional path information) 14% of routes originated by as701 are entirely chaff I emailed uunet, asking why it was they were leaking all these wasted routes at me, but didn't get a response. I took a look at 3561 based upon that same snapshot and see: 342 total routes originated by 3561 324 routes after removing more-specifics (not even going the extra step to aggregate what was left) 18 pointless more-specifics (same origin, so no additional path information) 5% of routes originated by as3561 are entirely chaff so, as3561 appears to be less sloppy, but if their policy is worded minimum of X routes, it definately encourages sloppiness.
Re: Effective ways to deal with DDoS attacks?
In the referenced message, Steven W. Raymond said:
Stephen Griffin wrote:
Tell them they will need to register their routes in the IRR, even if they
don't necessarily advertise all or any of them. Build your exceptions
based upon the irr, as for all bgp-speaking customers.
not route-filtering. You use the irr-data to populate the exceptions
to strict-mode rpf. The irr is more of a flight-plan of possibility.
If the customer registers both sets of routes, and you use that
data to build the acl, then it doesn't matter what the customer announces
to you. Anything which fails the actual rpf check, will then be
passed through the acl to selectively override the rpf check.
What about existing customers that don't yet use the IRR? Say you
filter some BGP customers' route announcements using manually-built
prefix-lists. Have found that by using distribute-list in (instead of
prefix-list), one can simply refer the distribute-list # in the strict
uRPF configuration and accomplish both functions (route filtering +
uRPF) easily with one ACL.
the IRR is merely an input vector. an alternate input vector is manual
entry. the output would be an acl or prefix-list. I don't believe the
format of a routing-use acl and an RPF-use acl is the same.
My recollection is that when used for route filtering you have:
access-list foo {permit|deny} ip network wildbits netmask wildbits
where for RPF, or traditional traffic filter is
access-list foo {permit|deny} ip source wildbits dest wildbits
I guess you could use a standard acl however I wouldn't recommend
it for filtering routes. Even if you could use prefix-lists for
uRPF, you would want to match more-specifics, whereas generally you
don't want to match (unbounded) more-specifics on route filters.
RtConfig can generate either style from IRR data. It isn't too hard
to generate either style from a manual list either.
e.g.:
ip verify unicast source reachable-via rx 49
access-list 49 permit x.x.x.x 0.0.0.255
access-list 49 permit y.y.y.y 0.0.0.252
access-list 49 deny any log
Prefix-lists are preferable over ACL-based distribute-lists. Hey Cisco,
please make uRPF configuration accept either distribute-lists or
prefix-lists for the exception branching. I realize that to IOS ACLs
and prefix-lists are not the same, but the benefits of prefix-lists vs.
distribute-lists are many.
How would uRPF respond to the following prefix-list?
ip prefix-list foo deny 0.0.0.0/0 ge 25
ip prefix-list foo permit 1.2.3.0/24
ip prefix-list foo permit 0.0.0.0/0 le 16
Would it accept all sources within 1.2.3.0/24? What about 10.0.0.0/8?
I guess it could ignore ge and le. Although how it would resolve
conflicts is an unknown. It might try to correspond to actual prefixes, but
that seems unlikely.
It sounds that a lot of networks rely on IRRs for building BGP customer
route filters. What method then is used for the cases where a customer
is not already using the IRR? Forced IRR registration before BGP
turnup? Or do you fallback on filtering by using prefix- or
distribute-lists?
In my experience, providers that require IRR registration often allow
the customer to register their own objects, or offer to proxy-register
their customers objects. The preference generally being on the customer
registering their own objects, since it gives the customer the greatest
degree of control (especially should they change providers.)
What's NANOG's opinion: assuming that uRPF is implemented on all
customer interfaces, are there any legitimate purposes for a customer to
forward packets with source IP addresses not currently routed by the
transit provider towards the customer (either static or BGP)?
Yes, I think there are definitely legitimate reasons why a customer
would source traffic from prefixes where the actively selected route
does not point back at the interface. This is why acl exceptions and
the loose match came to be. With customers, the acl exception is
probably appropriate. If the customer exhibits sufficient clue, and
demonstrates that they are doing RPF checks, I could definitely see
relaxing restrictions against them. If they are providing transit to
other BGP-speakers, this is probably the case. As in all things, you
know your customer best, so you know how loose you are willing to
make things, with the potential that it may make you look bad.
Re: Effective ways to deal with DDoS attacks?
In the referenced message, Iljitsch van Beijnum said: On Fri, 3 May 2002, Stephen Griffin wrote: for single-homed customers, simple uRPF for multihomed customers, acl exceptions based upon their registered IRR-policy, since the customer should already be registering in the IRR you have a list of all networks reachable via the customer, regardless of the actual real-time announcements or policy applications (prepending, localpref tweaks, etc) This doesn't make any sense. If you use uRPF on a customer interface, it will check the packets coming in from the customer to see if they match the prefixes you route to that customer. So as long as what you route to them and what they use as source addresses are identical, you don't have a problem. think MEDs and localpref twiddles., identical prefixes do not necessarily relate to best paths. For multihomed customers, these sets of prefixes should be identical, just like with single homed customers. The only time when those sets of prefixes is NOT the same is for a backup connection. But if a connection is a pure backup for incoming traffic, it's reasonable to assume it's a pure backup for outgoing traffic as well, so as long as the backup is dormant, you don't see any traffic so no uRPF problems. Not always the case, customer behaviour can not be accurately modeled. Using an exception access list is pretty silly: if you're going through the trouble of listing all a cutomer's prefixes in a list, you might as well just apply this acl to the interface rather than uRPF with the acl as exceptions. the acl will only be used on packets failing the rpf check. interface acls get applied to all traffic. There is another way to handle backups: you can also set the weight to a higher value for customer routes. This way, the router connecting to the customer will always use the routes announced by the customer, even if the rest of the network deems them inferior to another route to this customer because of a lower local pref, a higher MED or a longer AS path. This mechanism is also useful for peering: because of the higher weight, the border router will always prefer the exchange (or private peering link) for all traffic to the customer, so uRPF works. The rest of the network can still decide to send the traffic to another exchange point. I'm quite leery of having islands of widely divergent policy, and I wouldn't think it would help if you have multiple non-equal-cost-paths on the same router with which to accept traffic on. for non-clued peers, accept based upon any available forwarding path [hopefully, by the 100th time you beat on the peer about spoofed crud coming from them, they'll get religion and register, since you'll have less overall spoofing to track down, you can devote it to slapping them around more] If people stop peering with those network polluters they'll clean up their act soon enough. This is unlikely to occur, unfortunately, so merely making it as annoying as possible for polluters and less annoying as possible for non-polluters, is probably the way to go. you should also in/egress filter known bogons at all borders, like src/dst in rfc1918 src/dst in class e Why? That doesn't buy you much except job security because someone spending so much time on those impressive filters can't be missed of course. Because it is polite to not send crap to your neighbors, and advantageous to not have crap coming into your network. src in class d (not dest, however) Some multicast apps set the source to the group address as well. How... odd... Iljitsch van Beijnum
Re: Effective ways to deal with DDoS attacks?
In the referenced message, Eric Gauthier said: snip Another limitation that we've found with uRPF is that it doesn't live well with multihomed systems (i.e. a host with two NIC's - each on a different subnet) because of the way most OS'es handle their default gateways. For anyone who is interested in our experience, drop me a note off list. If you have a solution for this multihoming problem, PLEASE email me off-list. Eric :) Most Cisco boxes have 3 related modes of uRPF: 1) pure RPF, if forwarding path back to source doesn't go via interface packet received from, then dump. I believe, but am not positive, that it will handle equal-cost-multipath ok in situations where that exists. 2) acl exceptions, if source matches the acl, allow the packet 3) not-so-pure RPF, if there is _any_ forwarding path back to the source via _any_ interface, then accept. for single-homed customers, simple uRPF for multihomed customers, acl exceptions based upon their registered IRR-policy, since the customer should already be registering in the IRR you have a list of all networks reachable via the customer, regardless of the actual real-time announcements or policy applications (prepending, localpref tweaks, etc) for peers that are clued-in, again acl exceptions based upon the peers registered policy for non-clued peers, accept based upon any available forwarding path [hopefully, by the 100th time you beat on the peer about spoofed crud coming from them, they'll get religion and register, since you'll have less overall spoofing to track down, you can devote it to slapping them around more] you should also in/egress filter known bogons at all borders, like src/dst in rfc1918 src/dst in class e src in class d (not dest, however) etc
Re: genuity - any good?
In the referenced message, Roy said: Registering is not bad, its just not beneficial. Given that the routes I want to announce are within my assigned range, why is it a good thing to register them? If the transit provider always add entries when I ask for them, it seems to be very little benefit.. This is the case of transit so I am a customer paying money for a service. I started this subthread because I felt others would want to know about this. I made the mistake of buying transit service without asking about their BGP policies. I was hoping to help by sharing my experience. Registered routes, imho are beneficial. It permits filtering based on IRR data, and ensures that the entity announcing the routes has spent at least a modicum of time considering the impact they will have on the network. (Oh, look, I'm registering 500 routes to deaggregate this 1, maybe I'm being rude!) Of course, they still may not care how it impacts the rest of the world. Some providers loosen their filters for registered routes, since the originating entity has taken the time to say we will announce blah. Otherwise, any leaking of more-specifics with the same origin only appears like a route leak that should be protected against. If I were choosing a transit provider, I would look for ones that attempted to do the right thing, as I enjoy stability even at the cost of a few minutes of extra work.
Re: genuity - any good?
In the referenced message, Roy said: Two bad experiences for me: 1) Their BGP polices are not as good as others. They force you to register each route you want to advertise rather than allowing you to advertise any reasonable route for your prefixes. According to one of their top people, prefix-lists were unreliable new technology. We gave up and canceled the circuit. How is registering the routes you are going to announce a bad thing?
Re: 31 bit ptp link addressing?
In the referenced message, Adrian Chadd said: Hi all, Just (mostly) out of personal curiousity - is anyone here running any PtP links using 31 bit prefixes rather than the /30's we're all happy with? If you go huh? take a look at rfc3021 - Using 31-Bit Prefixes on IPv4 Point-to-Point Links Thanks, Adrian Yes, and it works wonderfully. The only issue is (for me) getting around the thought that even=low and odd=high, vs the case where odd=low and even=high. For example, when I'm on a router, look at an interface, and want to ping the other end, I have to get out of years of autopilot.
Re: Route filters, IRRs, and route objects
In the referenced message, Przemyslaw Karwasiecki said: Hello, I would like to ask you for an advice in regards to proxy registering of customer route objects in IRR. What is the best current practice in a situation, when your customers want to advertise to you several /18 or /19 but they also have a requirement to be able to advertise some deaggregated routes on top of aggregates. If your customer is merely using the deaggregates for TE, why would they need to send the deags with anything but no-export. This would resolve the issue of having to advertise them to your peers, while still allowing the customer to have traffic come in whichever link they chose. The added benefit is that no one else needs to accept additional routes. snip
