Re: [Nanog-futures] NANOG List Monthly Post.
On Tue, Aug 19, 2008 at 07:44:48AM +1200, NANOG Mail List Committee wrote: Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the BB-Outage mailing lists http://www.dataoutages.com/ That site/list is Blackbery specific; could we possibly get the outages list at puck added to this message with a higher (perhaps second) priority? Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
RE: Is it time to abandon bogon prefix filters?
You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. This is usually VERY BAD traffic, and EVEN WORSE if a user goes TO a site hosted in such IP space. So, Bogon filtering has value beyond mere spoofed source rejection. -Original Message- From: Sean Donelan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2008 5:19 PM To: NANOG list Subject: Re: Is it time to abandon bogon prefix filters? On Mon, 18 Aug 2008, Danny McPherson wrote: All the interesting attacks today that employ spoofing (and the majority of the less-interesting ones that employ spoofing) are usually relying on existence of the source as part of the attack vector (e.g., DNS cache poisoning, BGP TCP RST attacks, DNS reflective amplification attacks, etc..), and as a result, loose mode gives folks a false sense of protection/action. Yep. Same thing with bogon filters. Any attacker which can source packets with bogon addresses, can by definition, source packets with any valid IP address too. Great as an academic exercise, but the bad guys are going to send evil packets without the evil bit nor using bogon addresses. If the bad guys are using spoofed addresses, they don't care about the reply packets to either valid or unallocated addresses. However, seeing packets with unallocated IP addresses on the Internet is evidence of a broken network. Just like when a network trips max prefix on a BGP session, shouldn't a broken network be shutdown until the problem is fixed. If you don't want to risk your network peers turning off the connections, make sure your network doesn't source spoofed packets.
BGP Timers Configuration
Folks, We are pursuing some work along the lines of studying BGP scalability in terms of churn evolution. One of the key mechanisms used by BGP to dampen the churn is the MRAI timer (Minimum Route Advertisement Interval). From different vendors' specifications we find that: 1- Cisco enables MRAI by default for both route announcements and route withdrawals. 2- Juniper has a similar parameter called out-delay which is disabled by default. Of course these are default configurations, and we don't know if ISPs use them without any change. We would appreciate any input on the following questions: A- Is it common that ISPs change MRAI default configurations? If yes, then what decides the MRAI settings for both e-BGP and i-BGP sessions? B- Does anybody use a configuration where only route announcements are rate limited, and not explicit route withdrawals? C- Are there configurations where rate limiting is applied only to a subset of session? Best regards, Ahmed Elmokashfi Simula Research Laboratory.
Re: IP Fragmentation
At 07:07 p.m. 20/08/2008, Sam Stickland wrote: Yet all OSes have it enabled and there is no fallback to fragmentation in PMTUD: if your system doesn't get the ICMP messages, your session is dead in the water. Windows Vista/2007 has black hole detection enabled by default. It's not massively elegant, but it will keep sessions up (falls back to 536 byte MTU). http://support.microsoft.com/kb/925280 IPv4 minimum MTU is 68 bytes, not 536. 536 is the minimum fragment re-assembly buffer size. Falling back to 536-byte packets does not guarantee that sessions will be kept up. Kind regards, -- Fernando Gont e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: IP Fragmentation
On 25 aug 2008, at 12:27, Fernando Gont wrote: http://support.microsoft.com/kb/925280 IPv4 minimum MTU is 68 bytes, That's kind of like a human being can live without food for four to six weeks. It's not a recommendation. 536 is the minimum fragment re-assembly buffer size. Falling back to 536-byte packets does not guarantee that sessions will be kept up. But: PMTU black hole router detection is triggered on a TCP connection when TCP starts retransmitting full-sized segments with the DF flag set. TCP resets the PTMU for the connection to 536 bytes. Then, TCP retransmits its segments when the DF flag is clear.
YAOTM
Yet another of topic message;) I'm looking for IP transit in Newfoundland, since I'm not familiar with that territory, I was hoping that someone could message me offline for available options. Regards MKS
Re: Is it time to abandon bogon prefix filters?
On Sun, 24 Aug 2008 23:21:23 PDT, Tomas L. Byrnes said: You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. But if you've seen a BGP announcement with a prefix that covers the source, is it really a bogon anymore? At that point, you're not worrying about bogon filtering, you're worrying about sanity-checking what BGP advertisements you accept. Also a worthy thing to do, but different from bogon filtering. pgpmV7FPm2FYR.pgp Description: PGP signature
Re: Is it time to abandon bogon prefix filters?
[EMAIL PROTECTED] wrote: On Sun, 24 Aug 2008 23:21:23 PDT, Tomas L. Byrnes said: You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. But if you've seen a BGP announcement with a prefix that covers the source, is it really a bogon anymore? IIRC bogon is specific to unallocated space. Whether it be advertised or not should not matter. Regards, Chris
Re: Is it time to abandon bogon prefix filters?
On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote: On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Isn't it time to change the assumption that sending arbitrary source IP addresses without checking is Ok? Unless the customer has specifically told their ISP about all the IP addresses they intend to use as source IP addresses, shouldn't the default be to drop those packets. If those multi-homed customers have not told their upstream ISPs about additional source IP addresses (hopefully also registered/authorized for use by the same customer) why can they still send packets with those source addresses? Instead shouldn't you say Be careful if you are a using source IP addresses without informing your upstream. In practice, how many multi-homed customers send packets with unannounced source IP addresses? And for those customers which do, why is the ISP unable to implement any of the alternative source IP checking options, such as using a ACL with uRPF or on the interface? I certainly believe that this is the trap people fall into. I can't manage it, nor do I want to spend the effort telling my provider, peer, etc.. that I stole their customer from them, so I'm better off making the global network less secure. With all the concern about DNS cache integrity, network abuse, etc.. networks that are not taking afirmative action to implement better policies, systems are going to continue to lower their overall value. If you think I'm wrong, I do suggest you sit back and ignore your network and customers further. When they are unable to trust your network to deliver the correct response to a dns query, they will ask for credits and will leave. If I were any sort of a bank, I would insist that my provider take actions to prevent my customers from being redirected to a phishing site. The interesting thing is the effort put into dns patching, dnssec, etc.. could all be helped by the networks doing u-rpf. Not 100% mitigated against, but the difference would be huge. this is no longer a ddos issue of people spoofing packets. That's gone, it's easier to take over a million desktops with malware than one on a fe/ge. But the ability to use those machines to brute-force or reconfigure the resolver settings to someplace bad, that risk is truly tangible and possibly severely disruptive to the industry. If I can't trust that I am reaching my bank, email, etc.. what impact will that have? If you've not factored these things into your business process, hardware acquisition, I think you will end up with a bad situation. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Is it time to abandon bogon prefix filters?
On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote: On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote: On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Isn't it time to change the assumption that sending arbitrary source IP addresses without checking is Ok? Unless the customer has specifically told their ISP about all the IP addresses they intend to use as source IP addresses, shouldn't the default be to drop those packets. If those multi-homed customers have not told their upstream ISPs about additional source IP addresses (hopefully also registered/ authorized for use by the same customer) why can they still send packets with those source addresses? Instead shouldn't you say Be careful if you are a using source IP addresses without informing your upstream. In practice, how many multi-homed customers send packets with unannounced source IP addresses? And for those customers which do, why is the ISP unable to implement any of the alternative source IP checking options, such as using a ACL with uRPF or on the interface? I certainly believe that this is the trap people fall into. I can't manage it, nor do I want to spend the effort telling my provider, peer, etc.. that I stole their customer from them, so I'm better off making the global network less secure. With all the concern about DNS cache integrity, network abuse, etc.. networks that are not taking afirmative action to implement better policies, systems are going to continue to lower their overall value. If you think I'm wrong, I do suggest you sit back and ignore your network and customers further. When they are unable to trust your network to deliver the correct response to a dns query, they will ask for credits and will leave. If I were any sort of a bank, I would insist that my provider take actions to prevent my customers from being redirected to a phishing site. The interesting thing is the effort put into dns patching, dnssec, etc.. could all be helped by the networks doing u-rpf. Not 100% mitigated against, but the difference would be huge. this is no longer a ddos issue of people spoofing packets. That's gone, it's easier to take over a million desktops with malware than one on a fe/ge. But the ability to use those machines to brute-force or reconfigure the resolver settings to someplace bad, that risk is truly tangible and possibly severely disruptive to the industry. If I can't trust that I am reaching my bank, email, etc.. what impact will that have? My Bank (Bank of America) put in something to mitigate against this about 2 years ago (IIRC), so they were clearly anticipating something like this. Not only do you have to verify that you are you, you also have to verify that the bank is the bank. Regards Marshall If you've not factored these things into your business process, hardware acquisition, I think you will end up with a bad situation. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Is it time to abandon bogon prefix filters?
On Mon, 25 Aug 2008 09:38:00 EDT, Chris Marlatt said: IIRC bogon is specific to unallocated space. Whether it be advertised or not should not matter. Right. Tell that to everybody who's ever been at the wrong end of a bogon filter for 69/8, 70/8, 71/8... I'll go out on a limb and say that if you see a BGP announcement for a prefix you think is a bogon, it's *more* likely that the space is no longer unallocated and you didn't get the memo, than it's still unallocated but being pirated by somebody. (Which raises a question - what % of sites that are doing bogon filtering but *not* listening to something like Team Cymru's bogon feed? If it's nearly ubiquitous, it's not a big problem. But given the number of places that have problems with bogon filters, only a small percentage seem to be doing so...) At the point that you're doing bogon filtering, you have no way to disambiguate those two cases. Which is why I said it's a BGP announcement filtering issue. pgpFceBGl2O1h.pgp Description: PGP signature
Re: Force10 Gear - Opinions
On Aug 23, 2008, at 10:52 PM, Paul Wall wrote: EANTC did a comprehensive study of the E-series: http://www.eantc.de/en/test_reports_presentations/test_reports/force_10_sfm_failover_video_ftos_6211.html http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/EANTC_Full_Report.pdf http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/Section_8.pdf Did you read these? They appear to be nonsense. They were bought and paid for by Cisco, and including nonsense things like if you leave a slot open the chassis will burn up as a decrement, which is also true in pretty much every big iron vendor. They also deliberately detuned the force10 configuration. They re-ran the tests using the recommended configuration and got very different numbers -- which you can request from them, but they won't publish on the website. I'm not trying to be a Force10 advocate here (although I like their stuff) so much as trying to point at an incredibly biased and non- vendor-neutral report. It is entirely funny the amount they tried to make nonsensical stuff sound important. Comparing list pricing, it looks like Force 10 would have you pay more for less features. Based on what? For E and C series boxes, Cisco is never cheaper. S- series are a different story. As a box designed with the enterprise datacenter in mind, the E-series looks to be missing several key service provider features, including MPLS and advanced control plane filtering/policing. Ah, because Cisco does either of these in hardware? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Force10 Gear - Opinions
On Aug 22, 2008, at 7:34 AM, Matlock, Kenneth L wrote: 1) Reliability Very good. Across our entire business we've lost 1 RPM module in ~2 years. 2) Performance [Note: we have no 10g interfaces, so I can only speak to a many- singleg-port environment] Much higher than Cisco. So good at dealing with traffic problems that we have had multi-gig DoS attacks that we wouldn't have known about without having an IDS running on a mirroring port. 3) Support staff (how knowledgeable are they?) Significantly higher than Cisco, and escalation is easier. On par with Juniper. 4) Price (higher/lower/comparable to comparable Cisco gear) 80% of the Cisco of a comparable Cisco solution, and the support contracts are cheaper too. We're exclusively a Cisco shop here right now (mostly Cat6500s), so changing out some of our core gear with Force 10 is a bit 'scary', but if it meets our needs, maybe... If you go from Juniper to Force10 you might find some things lacking, but Cisco to Force10 is only an improvement. You'll never have to wonder if the command you're typing will throw the unit into software routing mode, as Cisco bugs have usually done. (not possible in the FTOS architecture) These things are so very solid that I rarely spend any time doing network work any more. Gigabit line-speed BCP38 makes life easier for the abuse helpdesk too. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Force10 Gear - Opinions
2) Performance [Note: we have no 10g interfaces, so I can only speak to a many-singleg-port environment] Much higher than Cisco. So good at dealing with traffic problems that we have had multi-gig DoS attacks that we wouldn't have known about without having an IDS running on a mirroring port. Do they have something with a few singleg-ports (could be only 2) but can route a large FIB (half a million, million routes) and some large RIBs (3 full-routing views, a hundred peers) ? Rubens
[NANOG-announce] 2008 Elections Reminder...
Hello everyone, Just a friendly reminder! Nominations for the NANOG Steering Committee, are due by Tuesday, 9th September. If you have not yet nominated someone and wish to do so, or if you have been asked to serve and have not yet accepted, please do so as soon as you can by sending a note to [EMAIL PROTECTED] Please refer to the 2008 elections page at http://www.nanog.org/elections08.html for more information. IMPORTANT DATES Tue 2008-08-12 Call for Nominations issued Tue 2008-09-09 Last day for SC Nominations to be received Sun 2008-10-12 Voting for the 2008/2008 NANOG SC opens at Noon PDT Tue 2008-10-14 Voting for the 2008/2009 NANOG SC closes at 1 pm PDT Best wishes, Philip Smith (on behalf of the NANOG Steering Committee) -- ___ NANOG-announce mailing list [EMAIL PROTECTED] http://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: Is it time to abandon bogon prefix filters?
In article [EMAIL PROTECTED] you write: On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote: On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote: With all the concern about DNS cache integrity, network abuse, etc.. networks that are not taking afirmative action to implement better policies, systems are going to continue to lower their overall value. If you think I'm wrong, I do suggest you sit back and ignore your network and customers further. When they are unable to trust your network to deliver the correct response to a dns query, they will ask for credits and will leave. If I were any sort of a bank, I would insist that my provider take actions to prevent my customers from being redirected to a phishing site. The interesting thing is the effort put into dns patching, dnssec, etc.. could all be helped by the networks doing u-rpf. Not 100% mitigated against, but the difference would be huge. this is no longer a ddos issue of people spoofing packets. That's gone, it's easier to take over a million desktops with malware than one on a fe/ge. But the ability to use those machines to brute-force or reconfigure the resolver settings to someplace bad, that risk is truly tangible and possibly severely disruptive to the industry. If I can't trust that I am reaching my bank, email, etc.. what impact will that have? My Bank (Bank of America) put in something to mitigate against this about 2 years ago (IIRC), so they were clearly anticipating something like this. Not only do you have to verify that you are you, you also have to verify that the bank is the bank. Regards Marshall While some people with some protocols have solutions to detect when the communication path has been compromised. Not all people with all protocols have a solution to this problem. There is no panecea to this problem, however *everyone* should do their best to reduce the problem. Any operator not implemting BCP 38 is potentially aiding and abetting some criminal. BCP 38 is over 10 years old. There is no excuse for not having equipment in place to handle the processing needs of BCP 38. Mark If you've not factored these things into your business process, hardware acquisition, I think you will end up with a bad situation. - Jared
RE: Force10 Gear - Opinions
As a box designed with the enterprise datacenter in mind, the E- series looks to be missing several key service provider features, including MPLS and advanced control plane filtering/policing. Ah, because Cisco does either of these in hardware? Yes. PFC3 inside Supervisor 32, 720 and RSP 720 for Catalyst 6500/Router 7600 series perform both of these features in hardware. The article mentioned in this thread compares Force10 E against the 6500 series. james
Tools Bof nanog 44
Greetings, It's not to late to think about sharing with your peers... Got a tool you use to monitor dns or ip hijacking, got some practices for monitoring your prefixes for anonlous events, have a commercial product you use that does one of these really well? Have some experience managing ipv6 addresses, or a dnssec toolkit? I'm sure your peers would love to hear about any of the above. Other topics are encouraged and invited. thanks joel
Re: Native v6 with Level(3)?
On 8/22/08, Kyle Murray [EMAIL PROTECTED] wrote: Here is the response I got from L3 when I inquired about IPV6: The answer to your questions is no, we have not yet inplemented IPV6 for our customers yet. IPV4 is the de facto on our backbone nad alledge router on which customers connectc. Poor spelling aside, it seems they have not implemented it yet. If someone manages to get them to implement, I would really like to hear about it. wow that is odd.. since stewart bamford has been off giving ipv6 deployment talks to various conferences (including this one: http://www.nanog.org/mtg-0510/bamford.html ) maybe L3's support staff should check their internal documentation?? Slide 17 says: Deployment completed Q3 2005... so, they apparently have it, can get it to you and do 6PE (or did 6PE a bit ago). Maybe ask again and aim the nay-sayer to the nanog preso and ask them to call stewart up directly? -chris
