Re: LoA (Letter of Authorization) for Prefix Filter Modification?
Joe Greco wrote: How do you verify the authenticity of anything? This is a common problem in the Real World, and is hardly limited to LoA's. How do you prove that what was on Pages 1 to (N-1) of an N page contract contained the words you think they said? I knew a guy, back in the early days, who habitually changed the SLA's in his contracts so that he could cancel a contract for virtually no reason at all ... the folly of mailing around contracts as .doc files in e-mail. But even failing that, it's pretty trivial to reprint a document, so where do you stop, do you use special paper, special ink, watermarking of documents, initial each page, all of the above, etc? what about using a digital signation of e.g. a pdf version of a scan? cheers, raoul -- DI (FH) Raoul Bhatia M.Sc. email. [EMAIL PROTECTED] Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email.[EMAIL PROTECTED] 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax.+43 1 3670030 15
Re: Procedure to Change Nameservers
Free sites that perform similar DNS configuration checks that I know of are: http://dnssy.com http://www.intodns.com Just to add to the list: http://squish.net/dnscheck/
Re: Atrivo/Intercage: Now Only 1 Upstream
Looks like PIE got themselves a /22 in spamhaus - http://www.spamhaus.org/sbl/sbl.lasso?query=SBL67906 _quote__ 206.223.144.0/22 is listed on the Spamhaus Block List (SBL) 17-Sep-2008 09:57 GMT | SR04 Pacific Internet Exchange LLC. NT Technology ; nttec.com http://cidr-report.org/cgi-bin/as-report?as=AS32335 Hosted/routed Scott Richter AND Alan Ralsky - now decided to pick up Intercage/Atrivo. Perhaps someone does not read the news? http://news.google.com/news?q=intercage http://www.spamhaus.org/news.lasso?article=636 We hope that's the case and this is not a knowing routing decision. On Wed, Sep 17, 2008 at 6:31 AM, Matthew Moyle-Croft [EMAIL PROTECTED] wrote: On 16/09/2008, at 10:17 PM, *Hobbit* wrote: So in cases like this where the community appears to agree that there's a consistently bad apple, what's preventing everyone from simply nullrouting the netblocks in question and imposing the death penalty? Dunno - but something did occur to me this morning on the drive into work:
Re: Atrivo/Intercage: Now Only 1 Upstream
On Tuesday 16 September 2008 23:36:20 *Hobbit* wrote: you expect them to apply a null route? Well, I *have* been talking somewhat idealistically here and there with this crop of questions, but frankly I thought in the 2 or 3 years I was ignoring the list that the NETWORK OPERATORS ostensibly in custody of the intertubes would have pulled things together a little better and grown enough of a pair to firmly state this crap stops here and now and make it happen. :-) Speaking as an observer only, and not as someone who, other than at my own edge, could make a significant impact on the result. Seems to me getting that IP space on a bogon list could be enough to make a serious dent.
Re: LoA (Letter of Authorization) for Prefix Filter Modification?
Joe Greco wrote: How do you verify the authenticity of anything? This is a common problem in the Real World, and is hardly limited to LoA's. How do you prove that what was on Pages 1 to (N-1) of an N page contract contained the words you think they said? I knew a guy, back in the early days, who habitually changed the SLA's in his contracts so that he could cancel a contract for virtually no reason at all ... the folly of mailing around contracts as .doc files in e-mail. But even failing that, it's pretty trivial to reprint a document, so where do you stop, do you use special paper, special ink, watermarking of documents, initial each page, all of the above, etc? what about using a digital signation of e.g. a pdf version of a scan? Try putting that up next to an apparently legitimate but actually subtly modified paper contract with signatures, in a court of law, and feel free to inform us of which one the court finds more compelling. In an environment where there's an established history and standard procedures, they're typically going to prefer the familiar method. In our world, if we were to have some sort of crypto-based way to have a netblock owner sign something like that, yeah, that'd be great, and it would mean that the community would generally be able to manage the issue without having to resort to faxed-around LoA's, etc., but we don't have that infrastructure, or even a common/widespread LoA system. Sigh. I'm not arguing that some sort of technical/crypto infrastructure for authorizing the advertisement of space shouldn't be developed, and in fact I think it should. However, as an interim step, things like LoA's are much better than nothing at all, and worrying about the authenticity of an LoA is probably not worth the time and effort, given the way these things tend to work out. If there's cause for concern, those who are receiving the LoA's will ramp up the paranoia. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
RE: Atrivo/Intercage: Now Only 1 Upstream
Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. - S -Original Message- From: Lamar Owen [EMAIL PROTECTED] Sent: Wednesday, September 17, 2008 09:26 To: nanog@nanog.org nanog@nanog.org Subject: Re: Atrivo/Intercage: Now Only 1 Upstream On Tuesday 16 September 2008 23:36:20 *Hobbit* wrote: you expect them to apply a null route? Well, I *have* been talking somewhat idealistically here and there with this crop of questions, but frankly I thought in the 2 or 3 years I was ignoring the list that the NETWORK OPERATORS ostensibly in custody of the intertubes would have pulled things together a little better and grown enough of a pair to firmly state this crap stops here and now and make it happen. :-) Speaking as an observer only, and not as someone who, other than at my own edge, could make a significant impact on the result. Seems to me getting that IP space on a bogon list could be enough to make a serious dent.
RE: Atrivo/Intercage: Now Only 1 Upstream
On Wed, 17 Sep 2008, Skywing wrote: Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. We all want a really really bad stuff BGP feed for anyone who wants it, but the Internet is not ready for that. Gadi. - S -Original Message- From: Lamar Owen [EMAIL PROTECTED] Sent: Wednesday, September 17, 2008 09:26 To: nanog@nanog.org nanog@nanog.org Subject: Re: Atrivo/Intercage: Now Only 1 Upstream On Tuesday 16 September 2008 23:36:20 *Hobbit* wrote: you expect them to apply a null route? Well, I *have* been talking somewhat idealistically here and there with this crop of questions, but frankly I thought in the 2 or 3 years I was ignoring the list that the NETWORK OPERATORS ostensibly in custody of the intertubes would have pulled things together a little better and grown enough of a pair to firmly state this crap stops here and now and make it happen. :-) Speaking as an observer only, and not as someone who, other than at my own edge, could make a significant impact on the result. Seems to me getting that IP space on a bogon list could be enough to make a serious dent.
Re: Atrivo/Intercage: Now Only 1 Upstream
On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron [EMAIL PROTECTED] wrote: On Wed, 17 Sep 2008, Skywing wrote: Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. We all want a really really bad stuff BGP feed for anyone who wants it, but the Internet is not ready for that. hrm, so actually there's a lot of supporting infrastructure that is necessary (or could be necessary) to implement something of that sort in any decent sized network. Provided you wanted to sinkhole the trafffic off somewhere to 'do the right thing' not just null0 the traffic, of course. There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from someone else whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens. Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ... How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made? -Chris
Re: Atrivo/Intercage: Now Only 1 Upstream
On Wed, Sep 17, 2008 at 1:07 PM, Christopher Morrow [EMAIL PROTECTED] wrote: On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron [EMAIL PROTECTED] wrote: On Wed, 17 Sep 2008, Skywing wrote: Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. We all want a really really bad stuff BGP feed for anyone who wants it, but the Internet is not ready for that. hrm, so actually there's a lot of supporting infrastructure that is necessary (or could be necessary) to implement something of that sort in any decent sized network. Provided you wanted to sinkhole the trafffic off somewhere to 'do the right thing' not just null0 the traffic, of course. right on. There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from someone else whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens. and this is the exact reason i will not implement any of these auto-bgp feeds or drop lists in my network. now not only do i have internal operation folks fat fingers to worry about,but what if one of these third parties, as you pointed out, with no money changing hands or formal agreements,has fat fingers one day, and now adds a legitimate allocation to the feed/list? then what? Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ... How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made? -Chris Christian
Re: Atrivo/Intercage: Now Only 1 Upstream
Christopher Morrow wrote: How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made? Reputation based on src_addr is /so/ 2005. ASN has a few more legs perhaps... but... All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, etc.) makes any system based around IP reputation decidedly less useful. At the end of the day, nobody is going to drop packets for amazon's IP space. -David
Re: Atrivo/Intercage: Now Only 1 Upstream
On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: Christopher Morrow wrote: How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made? Reputation based on src_addr is /so/ 2005. ASN has a few more legs perhaps... but... All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, etc.) makes any system based around IP reputation decidedly less useful. At the end of the day, nobody is going to drop packets for amazon's IP space. I'm afraid reality disagrees with you - there already are networks doing it. Being big does not guarantee you ability to do Bad Things. -- TTFN, patrick
Re: Atrivo/Intercage: Now Only 1 Upstream
On Wednesday 17 September 2008 12:55:49 Skywing wrote: Lamar Owen Wrote: Seems to me getting that IP space on a bogon list could be enough to make a serious dent. Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. Seems a similar topic has been here before... hrm... Yep, back around the first of August the subject came up of Is it time to abandon bogon prefix filters? in which thread you (among many others) were a participant. I don't have an archive link, sorry, since I used my personal archive of NANOG to find. Seems there are already trust, DoS, etc issues out there, in spades. But if someone wanted to do a 'badon' list and distribute in a similar fashion nothing is preventing folks for subscribing. The various antispam DNSBL's have multiple feeds of different kinds; some enterprising soul could do the same for routing. Will everyone do that? Of course not; some will choose to not, others will simply not care, and others will just ignore. Perhaps it could be called the wish-they-were-bogons list. Then a I-really-wish-they-were-bogons list for just the more severe block. The point made by Christopher Morrow is well taken: There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from someone else whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens. Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ... Folks who use a DNSBL are already letting people in their network, in the e-mail sense at least (and some firewall interfaces to these lists). Those same people would likely not have a problem with a wish-they-were-bogons list. But, yeah, it's like chasing a weasel with an M134 with someone else aiming while you hold down the trigger. For infrastructure notes, see Team Cymru's description page at http://www.team-cymru.org/Services/Bogons/routeserver.html Seems easy enough to duplicate (of course, the devil is in the details, and nothing is as easy as it seems); and making the 'thing' 'do the right thing' is a matter of what routes are actually served by your route-servers. Perhaps a good use for that old Internet backbone router (or wannabe) that can no longer take a full BGP feed.
Re: Atrivo/Intercage: Now Only 1 Upstream
On Wed, 17 Sep 2008, Christopher Morrow wrote: On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron [EMAIL PROTECTED] wrote: On Wed, 17 Sep 2008, Skywing wrote: Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. We all want a really really bad stuff BGP feed for anyone who wants it, but the Internet is not ready for that. hrm, so actually there's a lot of supporting infrastructure that is necessary (or could be necessary) to implement something of that sort in any decent sized network. Provided you wanted to sinkhole the trafffic off somewhere to 'do the right thing' not just null0 the traffic, of course. There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from someone else whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens. Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ... How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made? Chris, that does not solve the one issue you did not mention: liability. Gadi. -Chris
Re: Atrivo/Intercage: Now Only 1 Upstream
On Wednesday 17 September 2008 13:34:22 Patrick W. Gilmore wrote: On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: At the end of the day, nobody is going to drop packets for amazon's IP space. I'm afraid reality disagrees with you - there already are networks doing it. Indeed. Google's e-mail servers get on the various DNSBL's frequently. Being big does not guarantee you ability to do Bad Things. Might even provide incentive for the grid computing providers to keep tabs on what their uses are doing. Imagine that! Accountability, using the only 'stick' available.
Re: Atrivo/Intercage: Now Only 1 Upstream
Lamar Owen wrote: On Wednesday 17 September 2008 13:34:22 Patrick W. Gilmore wrote: On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: At the end of the day, nobody is going to drop packets for amazon's IP space. I'm afraid reality disagrees with you - there already are networks doing it. Indeed. Google's e-mail servers get on the various DNSBL's frequently. I occasionally get in to an argument with a customer who is trying to get mail from someone after a spam run came out of a google mail server and landed it on a DNSBL. The argument presented to me always boils down to Google could never do anything wrong or Google is too big to do anything wrong and I should immediately stop recommending any DNSBL that would dare to block Google. ~Seth
Re: Atrivo/Intercage: Now Only 1 Upstream
On Wed, Sep 17, 2008 at 1:32 PM, David Ulevitch [EMAIL PROTECTED] wrote: Christopher Morrow wrote: How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made? Reputation based on src_addr is /so/ 2005. ASN has a few more legs perhaps... but... All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, etc.) makes any system based around IP reputation decidedly less useful. there is more than 'srcip' you can use to judge reputation on... if you have something 'not a router' you can even implement other options... Adding things like ttl's to the entries, sliding the reputation on that as well. It's not just 'src ip'. ASN is a really big hammer At the end of the day, nobody is going to drop packets for amazon's IP space. nope, but amazon can/may-be-able-to do some protections on their side, or individuals could choose to block bits/pieces of amazon, and they have already. -David
RE: Atrivo/Intercage: Now Only 1 Upstream
I occasionally get in to an argument with a customer who is trying to get mail from someone after a spam run came out of a google mail server and landed it on a DNSBL. The argument presented to me always boils down to Google could never do anything wrong or Google is too big to do anything wrong and I should immediately stop recommending any DNSBL that would dare to block Google. ~Seth A more rational version of this argument would be that blocking Google's mail servers will obviously have large amounts of collatarel damage. Any DNSBL that blocks Google's mail servers, other than perhaps in sufficiently serious situations to justify this level of collatarel damage, shouldn't be recommended. You should provide a way for customers to opt out of your blacklists. Many people are perfectly happy to run their own spam filtering software and retain the capability to skim (or analyze) their spam. If you provide a way for your customer to do this, point them to it. If not, that is a failing on your part. (Though of course it's always possible you have cost/benefit arguments that justify not providing that service.) Some people would really like email to be as reliable as possible, even if that means they have to wade through a lot of spam. At least this gives them ability to whitelist sources that are important to them personally. David Schwartz [EMAIL PROTECTED]
Re: Atrivo/Intercage: Now Only 1 Upstream
Patrick W. Gilmore wrote: On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: At the end of the day, nobody is going to drop packets for amazon's IP space. I'm afraid reality disagrees with you - there already are networks doing it. Being big does not guarantee you ability to do Bad Things. I didn't imply that it did. But the ability to block without causing significant collateral damage becomes more and more difficult as IPs become less tied to the organization using them. That said, you're right that people are doing it now. Consensus from friends running their apps on EC2 is that you can't expect to be able to send any email from EC2 and hope for a high deliverability rate.
Re: Atrivo/Intercage: Now Only 1 Upstream
David Schwartz wrote: I occasionally get in to an argument with a customer who is trying to get mail from someone after a spam run came out of a google mail server and landed it on a DNSBL. The argument presented to me always boils down to Google could never do anything wrong or Google is too big to do anything wrong and I should immediately stop recommending any DNSBL that would dare to block Google. ~Seth A more rational version of this argument would be that blocking Google's mail servers will obviously have large amounts of collatarel damage. Any DNSBL that blocks Google's mail servers, other than perhaps in sufficiently serious situations to justify this level of collatarel damage, shouldn't be recommended. You should provide a way for customers to opt out of your blacklists. Many people are perfectly happy to run their own spam filtering software and retain the capability to skim (or analyze) their spam. If you provide a way for your customer to do this, point them to it. If not, that is a failing on your part. (Though of course it's always possible you have cost/benefit arguments that justify not providing that service.) Some people would really like email to be as reliable as possible, even if that means they have to wade through a lot of spam. At least this gives them ability to whitelist sources that are important to them personally. Oh, they can. They have full control of everything hardcore filtering to nothing at all and anything in between. They could prune out the DNSBL they didn't like, turn off DNSBL completely, whitelist the source CIDR range (which I gave them), whitelist the sender's address/domain, etc. There was 15 different ways they could have fixed it, but didn't want to. I can't really say why. All they would say is it's Google. ~Seth
Re: Atrivo/Intercage: Now Only 1 Upstream
Some people would really like email to be as reliable as possible, even if that means they have to wade through a lot of spam. By what twisted logic can a system where desired email is found when they have to wade through a lot of spam? Have you ever inadvertently deleted a desired item in the middle of a delete-yes-delete-yes-delete-yes-delete-yes-delete-yes-delete-yes sequence that went on for a lot of spam? How many times? Did you recover all of the desired items? How do you know that? To me a reliable system is one that delivers what I want and only what I want every time. And having to pick the pepper out of the flysh*t is not my idea of reliable.
Any group(s) discounts to NANOG in LA?
I'm so close to it, not attending is not really an option.. Peter -- ピーター
Atrivo Update
I've been in touch with all of the upstream transit providers currently routing Atrivo/Intercage netblocks. Without naming any names, they are all aware, and working on getting them pulled in accordiance with their AUPs. Hats off particularly to NTT and AboveNet for going the extra mile here. (Unfortuantely, I understand sales and contractual pushback can sometimes put a damper on these things.) Gas is still expensive, so Drive Slow, Paul Wall
Re: Atrivo/Intercage: Now Only 1 Upstream
On Wed, 17 Sep 2008, David Ulevitch wrote: Reputation based on src_addr is /so/ 2005. ASN has a few more legs perhaps... but... All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, etc.) makes any system based around IP reputation decidedly less useful. At the end of the day, nobody is going to drop packets for amazon's IP space. While I can't speak for the others on your list, we have been putting a fair amount of thought into abuse detection and mitigation at GoGrid. We are well aware of the problems we would have if our address space were to end up with a bad reputation. If stuff does get through that shouldn't, please contact [EMAIL PROTECTED] and we'll take care of it. -Steve
Re: Any group(s) discounts to NANOG in LA?
2008/9/17 Peter Serwe [EMAIL PROTECTED] I'm so close to it, not attending is not really an option.. Peter, Your message was a little cryptic, but I assume you are inquiring about the accomodations. If you go to www.nanog.org, and then click on the link entitled 'Hotel Information,' (just look for the bright red text) it leads you to: http://www.nanog.org/meetings/nanog44/hotel.php Where you can find all sorts of information. But book now, the rate expires tomorrow! Saul P.S. There are always options in life, don't give up hope.
Re: Any group(s) discounts to NANOG in LA?
Actually, I was inquiring about the registration fee. I live close enough and my gear is a few buildings down from the location. Peter On Wed, Sep 17, 2008 at 5:02 PM, Saul Moll [EMAIL PROTECTED] wrote: 2008/9/17 Peter Serwe [EMAIL PROTECTED] I'm so close to it, not attending is not really an option.. Peter, Your message was a little cryptic, but I assume you are inquiring about the accomodations. If you go to www.nanog.org, and then click on the link entitled 'Hotel Information,' (just look for the bright red text) it leads you to: http://www.nanog.org/meetings/nanog44/hotel.php Where you can find all sorts of information. But book now, the rate expires tomorrow! Saul P.S. There are always options in life, don't give up hope. -- ピーター
[NANOG-announce] NANOG44 Updates
Hello Everyone: As Philip Smith indicated... a few more update messages to the community will be coming, and here is one of them. First, Merit would like to draw your attention to the Hotel Reservation link http://nanog.org/meetings/nanog44/hotel.php An IMPORTANT NOTE to be aware of is, the Hotel room block rate EXPIRES on FRIDAY, Sept. 19! Merit has reserved rooms for the community, so please do reserve your room before the deadline. Just an easy click away. So now that you have reserved your room, you should check out the updated NANOG44 meeting agenda. http://nanog.org/meetings/nanog44/agenda.php Highlights include: Updated presentations and content information, along with meeting room assignments. Soon, Merit will also highlight which presentations will be broadcast and which will be encoded for future reference. For the first time while at NANOG, Merit will have a room assigned to view the Fall 2008 Internet2 Member Meeting netcast. There are evening events on Sunday, Monday and Tuesday!! And we have a very exciting joint session with ARIN on Wednesday morning. Lastly, the [EMAIL PROTECTED] email list will help you keep in touch with each other. It will also be the distribution method for sharing additional site and meeting specific information. Make sure if you are attending, you are subscribed!! Again, on behalf of Merit Network, the NANOG SC and PC, we encourage you to attend this exciting meeting. We are confident this is one meeting you will not want to miss !! Hope to see many of you in LA and as always, if you have any questions or concerns regarding the meeting venue or registration, please send a note to [EMAIL PROTECTED] Sincerely, Betty Burke Merit/NANOG Project Manager Merit Network Inc. Merit/NANOG Project Manager ___ NANOG-announce mailing list [EMAIL PROTECTED] http://mailman.nanog.org/mailman/listinfo/nanog-announce
RE: Atrivo/Intercage: Now Only 1 Upstream
Welcome the Internet version of Too big to fail. I like the corollary: If it's too big to fail, it's too big, and needs to be broken up. Otherwise, we get an oligarchy, -Original Message- From: Seth Mattinen [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2008 11:27 AM To: nanog@nanog.org Subject: Re: Atrivo/Intercage: Now Only 1 Upstream Lamar Owen wrote: On Wednesday 17 September 2008 13:34:22 Patrick W. Gilmore wrote: On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: At the end of the day, nobody is going to drop packets for amazon's IP space. I'm afraid reality disagrees with you - there already are networks doing it. Indeed. Google's e-mail servers get on the various DNSBL's frequently. I occasionally get in to an argument with a customer who is trying to get mail from someone after a spam run came out of a google mail server and landed it on a DNSBL. The argument presented to me always boils down to Google could never do anything wrong or Google is too big to do anything wrong and I should immediately stop recommending any DNSBL that would dare to block Google. ~Seth
Mechanisms for a multi-homed host to pick the best router
(My apologies, in advance, for the fact that this question is very long winded.) I have a server which is multi-homed to N routers as shown below: +---+ R1---| | | | R2---| | ... | S | | | Rn---| | +---+ This server is a host; it is not a router in the sense that it will never forward any packets (but it might run routing protocols as discussed below). Also, for the sake of simplicity in this discussion, let's say this server only receives inbound TCP connections; it never initiates outbound TCP connections. Finally, this server has a loopback address L. All traffic destined to the server uses address L as the destination address. All N routers have a static route to L and inject that route into their routing protocol (possibly as part of an aggregate). Now, imagine the server receives an inbound connection from another host whose address is A. Thus, the TCP SYN packet which S receives has source address A and destination address L. When the server sends TCP traffic for that same connection back to host A, it needs to pick one of the N routers, in other words, it needs to pick an outbound interface from its N interfaces. Traditionally, this is done by doing a best-match lookup for address A in the forwarding table of the server. One could install a ECMP default route which points to all N routers. In this case, the downstream router would essentially be picked at random (for each connection, assuming 5-tuple hashing). The problem is that some routers are better than other routers in the sense that they are closer to the final destination address A. (For example, each router could be connected to a different ISP.) One way for the server to pick the optimal downstream router, is to run stub BGP between the server and each of the routers. By stub BGP I mean that the server uses the BGP session only to learn routes. It advertises its own loopback L, but it never advertises any other routes, and it never propagates and routes from one BGP session to another BGP session. The server would have N BGP sessions and learn the full default-free BGP route table over each of those sessions. In other words, the server would end up with approximately N x 250,000 routes in its RIB and 250,000 routes in its FIB. While this approach would certainly allow the server to pick the optimal downstream router in all cases, I would prefer not to run routing protocols on this server for a number of reasons: - I don't want to the spend memory and CPU on such large RIBs and FIBs. - I'm afraid that other routers will attempt to forward traffic through the server (due to accidental misconfigurations) once it starts participating in the routing protocols. - Since there might be many of these servers (many more than the number of routers) I might end up stretching the routers beyond their scaling limits (number of BGP sessions, link state database size, etc.) and destabilizing the network. - I know there are good open source implementation of routing protocols, but still, I'm nervous that any instability or bugs on the servers could end up screwing up the routers (e.g. persistent BGP flaps). - One possible variation is that the server is a client of some route-reflectors which are not in the forwarding path (i.e. next-hop-self is not enabled). In that case, I might end up needing to do BGP next-hop resolution for a very large number of BGP next-hops. This, in turn, implies that the server might need to also run OSPF in a very large flat area 0. For all these reasons, I don't want to run BGP on the server. Someone suggested an idea to me which seems almost to simple to work, but I cannot find any good reason why it would not work. The idea is the server simply sends all outbound traffic for the TCP connection out over the same interface over which the most recent TCP traffic for that connection was received. So, for example, if the server receives the SYN from router R3, it would send the SYN ACK and all subsequent packets for the TCP connection over that same interface R3. If the inbound packets for that same TCP connection start arriving from a different router (e.g. because of link failure), say R4, then the server also switches the outbound packets to that same router R4. I am aware that routing is not always symmetrical. In other words, I am aware that the best route from A to Z might be A-B-C-Z while the best route from Z to A might be Z-D-A. However, since the IP routing tables form an inverted tree, it seems to me that in realistic scenarios the traffic should still arrive at A (maybe over a non-optimal path in rare cases) if Z sends the reverse traffic to C instead of D. It seems unlikely (impossible?) that this would cause a routing loop. I can think of the following problems with this approach: (Problem 1) It only works for inbound TCP connections and not for outbound TCP connections. For outbound TCP connections we would not know which router to send the first SYN packet
Re: Mechanisms for a multi-homed host to pick the best router
Cayle Spandon wrote: I have a server which is multi-homed to N routers as shown below: +---+ R1---| | | | R2---| | ... | S | | | Rn---| | +---+ This server is a host; it is not a router in the sense that it will never forward any packets (but it might run routing protocols as discussed below). This is going to be the stupid question of the day, but unless you have a route policy (in which case, what was the question again?) why would you not sent the reply out the same spigot you go the request on?
Re: Mechanisms for a multi-homed host to pick the best router
[EMAIL PROTECTED] (Cayle Spandon) writes: (My apologies, in advance, for the fact that this question is very long winded.) np. I have a server which is multi-homed to N routers as shown below: +---+ R1---| | | | R2---| | ... | S | | | Rn---| | +---+ This server is a host; it is not a router in the sense that it will never forward any packets (but it might run routing protocols as discussed below). Also, for the sake of simplicity in this discussion, let's say this server only receives inbound TCP connections; it never initiates outbound TCP connections. Finally, this server has a loopback address L. All traffic destined to the server uses address L as the destination address. All N routers have a static route to L and inject that route into their routing protocol (possibly as part of an aggregate). Now, imagine the server receives an inbound connection from another host whose address is A. Thus, the TCP SYN packet which S receives has source address A and destination address L. ... For all these reasons, I don't want to run BGP on the server. too many moving parts. Someone suggested an idea to me which seems almost to simple to work, but I cannot find any good reason why it would not work. The idea is the server simply sends all outbound traffic for the TCP connection out over the same interface over which the most recent TCP traffic for that connection was received. So, for example, if the server receives the SYN from router R3, it would send the SYN ACK and all subsequent packets for the TCP connection over that same interface R3. ... right idea. works great. see the following: http://www.academ.com/nanog/feb1997/multihoming.html http://www.irbs.net/internet/nanog/9706/0232.html http://gatekeeper.dec.com/pub/misc/vixie/ifdefault/ ... I can think of the following problems with this approach: (Problem 1) It only works for inbound TCP connections and not for outbound TCP connections. For outbound TCP connections we would not know which router to send the first SYN packet to. you said above you only needed inbound. for outbound and udp: round robin. ... My question for the NANOG community are these: (Question 1) Can you think of any additional problems with this approach? Specifically, I am interested in persistent failures in the absence of topology changes. topology change frequency is in a different order of magnitude than the usual tcp session startup frequency, so unless you've got long running tcp sessions which won't restart on a connection reset, you've got no problem, and if you do have that kind of tcp session, you've already got problems. (Question 2) Is there another mechanism for the server (a multi-homed host) to pick a best router, short of running stub BGP? Are there any standards for this? there are a bazillion patented and/or ubersecret ways to do this. noone has ever demonstrated anything that works better than an undercommitted network with undercommitted connections to other undercommitted first-hop networks. (Question 3) If the answer to question 2 is no, is there any interest in standardizing a protocol for a multi-homed host to pick a best next-hop router? One could think of this is a host-to-router routing protocol. One might call the existing routing protocols router-to-router protocols (because I think we are abusing them by running them on hosts). This is somewhat analogous to the multicast routing world where we use different protocols for router-to-router multicast (PIM) versus host-to-router (IGMP). sadly, this has been tried, but it always runs into least-cost routing issues whereby not only the predicted connection quality but also contract details like whether this is over or under the per-period minima and how many quatloos per kilosegment it will cost all have to get exchanged at high speed with low latency and good accuracy. been there, did that, got no useful t-shirt even. -- Paul Vixie
