February 2006 - Test - lists.nanog.org

MLPPP over MPLS
by Jon R. Kibler 22 Feb '06

22 Feb '06

Greetings all, Would anyone who has every done MLPPP over MPLS care to share their experiences with this type of network? We have a customer that is implementing an MPLS network that will have 2 to 6 T1 feeds at some locations that will be using MLPPP for channel bonding. This is a telco provided network that will be customer managed. The routers will be customer managed because the same equipment will have interfaces to another telco's network as a backup to the MPLS network. Needless to say, no telco will support equipment that interfaces competitors networks. The customer is being told by their router vendor that an MLPPP/MPLS network is 'too complex' to be managed by anyone except for the router vendor's VARs or the telco. They indicated that it would be impossible for the customer's router vendor certified network person to come up to speed on MLPPP/MPLS configurations and manage such a network -- that it takes years to adequately learn how to manage that type of network configuration. This doesn't sound like rocket science to me -- it should be simple and rather straight forward, I would think: The telco specifies its requirements for the router configuration, the customer implements that configuration on the required router interfaces, the telco monitors line quality, and the customer does basic router monitoring. Am I missing something here, or is the router vendor just blowing a lot of smoke to try to provide business for some of his clients that provide managed services? Thanks in advance for your feedback! Jon Kibler -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

7 10

Re: a radical proposal (Re: protocols that don't meet the need...)
by Michael.Dillon＠btradianz.com 21 Feb '06

21 Feb '06

[[pushed the wrong button last time. This is the complete reply]] > - join a local IXP, which may be a physical switch or > virtualized by a set of bilateral agreements. Why should they join an IXP if they already have private peering arrangements? > - outside the region, they advertise the prefix of the > regional authority Mixing government with operations? If you favor doing that then why not just give IPv6 addresses to the various national governments and let the UN sort it out? Personally I disagree with any scheme which calls for national or municipal governments to assign IPv6 addresses to end users. Dressing it up as a "regional authority" does not make it any nicer. Forcing people to join an unecessary IX is not the way to solve the problem of regional aggregation of routes. This is a purely technical problem which can be solved by the RIR practices in allocating IPv6 addresses. If they would allocate addresses in a geo-topological manner then end users and ISPs would be free to aggregate routes outside of their region without any involvement of governments or any requirement to join consortia or IXes. It does require the users of such geo-topological addresses to ensure that in THEIR region, there is sufficient interconnectivity (physical and policy) between ISPs for the addressing to work. But that does not need to be determined or managed centrally. Geo-topological addressing refers to RIRs reserving large blocks of designated addresses for areas served my large cities (over 100,000) population. When end users are located in fringe areas roughly equidistant between two or more such centers, the RIR simply asks the end user (or ISP) which is the center to which they want to connect (communicate). This addressing scheme operates in parallel with the existing provider-oriented IPv6 addressing scheme but uses a different block of IPv6 addresses out of the 7/8ths that are currently reserved. No hardware or software changes are required for this to work, merely some geographical/economical research to determine the relative sizes of the address pool to be reserved for each of the world's 5000 largest cities. > Whenever I have talked about the model with an ISP, I have gotten > blasted. Basically, I have been told that > > (1) any idea on operations proposed in the IETF is a bad idea because > the IETF doesn't listen to operators This is true. Top-down does not work in Internet operations. We need bottom-up, i.e. customer demand. The IETF needs to view their role as enablers of customer demand. If the IETF can create something that will work for ISP customers, then ISPs will be happy to go along, once the customers demand the service. > (2) the ISPs aren't going to be willing to make settlement payments > among themselves in accordance with the plan Wait until this starts appearing as a requirement in custome RFPs. > I'm not sure how to proceed, given the level of invective I get in > any discussion with anyone on the topic. Perhaps the IETF needs to seek input, not just from ISPs, but also from ISP customers, the end users of the network. > Note 2: Provider-provisioned addresses continue to make sense for > folks that don't plan to multihome. Indeed they do. But the current IPv6 addressing model is completely slanted towards provider-provisioned addresses for single-homed entities. Calling a small block of these provider-provisioned addresses PI (provider independent) does not really make the addresses provider independent and does not help small enterprises to implement meaningful multihoming. The IETF has imposed this provider-provisioned model on IPv4 and is thus directly responsible for the ISP cartel which now exists. --Michael Dillon

4 4

Re: Quarantine your infected users spreading malware
by Scott Weeks 21 Feb '06

21 Feb '06

----- Original Message Follows ----- From: Michael.Dillon(a)btradianz.com > > Oh geez, here we go again... Search the archives and > > read until you're content. It's a non-thread. This > > horse isn't only dead, it's not even a grease spot on > the road any more. > > Are you saying that the problem of spreading worms > and botnets is fading? Where do you get your data on > this? > > I mean, it's all well and good to express an opinion > but if you want to be believed you have to be prepared > to back it up with data from another source. I'm not saying that at all and that'd be the silliest position to support anyway. We all know better than that. All I was saying is *every* position on the subject was expressed about two months ago in the thread that wouldn't die even in the clear evidence of an exponential decrease in quality of responses on the subject and I don't things have changed significantly since then. No biggie, I can delete when the quality of respones degrades below my threshold of ability to carry on reading... :-) scott

1 0

Maximun effective range of an excuse is... [Was: Re: Quarantine your i nfected users spreading malware]
by Fergie 21 Feb '06

21 Feb '06

QED: AT&T/SBC also does this for their DSL subscribers... - ferg -- Larry Smith <lesmith(a)ecsis.net> wrote: The problem with discussing AOL and "large provider" in the same sentence is that the complete AOL (connection, desktop, tools, etc) function are AOL controlled (walled garden) so they have the capability of doing much more in that arena that other providers. [snip] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: Quarantine your infected users spreading malware
by Scott Weeks 21 Feb '06

21 Feb '06

----- Original Message Follows ----- From: Gadi Evron <ge(a)linuxbox.org> > Many ISP's who do care about issues such as worms, > infected users "spreading the love", etc. simply do not > have the man-power to handle all their infected users' > population. > Some who are user/broadband ISP's (not say, tier-1 and > tier-2's who would be against it: "don't be the > Internet's Firewall") are blocking ports such as 139 and > 445 for a long time now, successfully preventing many of > their users from becoming infected. This is also an > excellent first step for responding to relevant outbreaks > and halting their progress. > > Philosophy aside, it works. It stops infections. Period. > > Back to the philosophy, there are some other solutions as > well. Plus, should this even be done? Oh geez, here we go again... Search the archives and read until you're content. It's a non-thread. This horse isn't only dead, it's not even a grease spot on the road any more. :-( scott

15 28

Subject: drone armies C&C report - February/2006
by c2report＠isotf.org 21 Feb '06

21 Feb '06

Below is an automatically generated periodic public report from the ISOTF's affiliated group "DA" ("Drone Armies (botnets) research and mitigation mailing list" / TISF DA) with the ISOTF affiliated ASreport project (TISF / RatOut). For this report it should be noted that we base our analysis on the data we have accumulated from various sources, which may be incomplete. Any responsible party that wishes to receive reports of botnet command and control servers on their network(s) regularly and directly, feel free to contact us. In the past few months we did not publish this report, allowing for responsible parties to ask for regular reports from us on suspected botnet C&C activity on their networks. As you can see below, the Internet drastically changed its face positively because these reports (compared to when we started), and now a lot more so due to direct reporting. For purposes of this report we use the following terms: open the host completed the TCP handshake closed No activity detected reset issued a RST This month's survey is of 4271 unique domain with port or IP with port suspect C&Cs. This list is extracted from the BBL which currently has a historical base of 7780 reported C&Cs. Of the suspect C&Cs surveyed, 685 reported as Open, 3353 reported as closed and 572 issued resets to the survey instrument. Of the C&Cs listed by domain name, 1847 are mitigated via remapping. Top 20 ASNes by Total suspect domains mapping to a host in the ASN. These numbers are determined by counting the number of domains which resolve to a host in the ASN. We do not remove duplicates and some of the ASNs reported have many domains mapping to a single IP. Note the Percent_resolved figure is calculated using only the Total and Open counts and does not represent a mitigation effectiveness metric. ASN Responsible Party Total Open Percent_Resolved 14744 PNAP Internap Network Services 91 0 100% 10913 PNAP Internap Network Services 67 0 100% 30058 FDCSE FDCservers.net LLC 65 18 72% 25761 STAMIN-2 Staminus Communications 58 6 90% 3356 Level 3 Communications, LLC 53 0 100% 13301 UNITEDCOLO-AS Autonomous System of 52 35 33% 14779 INKT Inktomi Corporation 42 0 100% 21844 THE PLANET 41 2 95% 19318 AIC-81 Albany International Corp. 40 11 73% 13749 EVRY Everyones Internet 37 5 86% 4766 KIXS-AS-KR 35 2 94% 30315 Everyones Internet 31 12 61% 12182 PNAP Internap Network Services 31 0 100% 9318 HANARO-AS 30 9 70% 21840 SAGONE Sago Networks 30 5 83% 13790 PNAP Internap Network Services 30 0 100% 22822 LLNW Limelight Networks 29 10 66% 27595 ATRIV Atrivo 27 5 81% 12832 Lycos Europe 26 3 88% 3561 Savvis 24 1 96% Top 20 ASNes by number of active suspect C&Cs. These counts are determined by the number of suspect domains or IPs located within the ASN completed a connection request. ASN Responsible Party Total Open Percent_Resolved 13301 UNITEDCOLO-AS Autonomous System of 52 35 33% 32748 NOZON NoZone 21 20 5% 30058 FDCSE FDCservers.net LLC 65 18 72% 174 Cogent Communications 20 16 20% 25700 SWIFTDESK VENTURE 19 13 32% 30315 Everyones Internet 31 12 61% 4134 CHINANET-BACKBONE 17 12 29% 19318 AIC-81 Albany International Corp. 40 11 73% 9121 TTNet 15 11 27% 22822 LLNW Limelight Networks 29 10 66% 8972 INTERGENIA-ASN intergenia autonomou 21 10 52% 15083 IIS-129 Infolink Information Servic 24 9 63% 30407 Velcom.com 12 9 25% 9318 HANARO-AS 30 9 70% 20115 Charter Communications 20 9 55% 23522 CIT-FOONET 14 9 36% 16265 LEASEWEB AS 15 9 40% 3269 TELECOM ITALIA 16 8 50% 8560 SCHLUND-AS 19 7 63% 19166 Alpha Red, INC 14 7 50% 33569 ALLHOSTSHOP.COM 16 6 63%

1 0

Re: Quarantine your infected users spreading malware
by Scott Weeks 20 Feb '06

20 Feb '06

> > Oh geez, here we go again... Search the archives and > > read until you're content. It's a non-thread. This > > horse isn't only dead, it's not even a grease spot on > > the road any more. :-( > > I quite agree, which is why I trived to cover the > philosophical part from both sides. Now, how about some > solutions that came about since our last discussion that > was nothing BUT philosophy? You can't get there from here. scott

2 1

Cisco 3550 replacement
by Jacky Lam 20 Feb '06

20 Feb '06

Hi all, I'm currently looking for a CPE that can replace the Cisco 3550 we currently deploy in our network. Key features that I'm looking for are as follows: Hierarchical QOS Traffic shaping/policing L3VPN functionality(VRF-lite) BGP OSPF dot1q some sort of spanning tree Any help would be really appreciated, Jacky

3 3

RE: MLPPP over MPLS
by Peering 20 Feb '06

20 Feb '06

I've been told by Juniper that the MTU negotiation problem was fixed in the 7.x versions. We're upgrading soon, so I hope to find out for myself. Diane Turley Sr. Network Engineer Xspedius Communications Co. 636-625-7178 -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Brent A O'Keeffe Sent: Monday, February 20, 2006 7:57 AM To: Jon Lewis Cc: Jon R. Kibler; nanog(a)merit.net Subject: Re: MLPPP over MPLS It may also be worth noting that if the provider is running Juniper and not Cisco, there are fragmentation issues with certain versions of Juniper code. The MLPPP session cannot agree on an MTU and usually stop somewhere around 100 bytes if they do. The workaround is to implement "ppp multilink fragment disable" on the Cisco Multilink interface. Brent Jon Lewis <jlewis(a)lewis.org> Sent by: owner-nanog(a)merit.edu 02/17/2006 03:38 PM To "Jon R. Kibler" <Jon.Kibler(a)aset.com> cc nanog(a)merit.net Subject Re: MLPPP over MPLS On Fri, 17 Feb 2006, Jon R. Kibler wrote: > We have a customer that is implementing an MPLS network that will have 2 > to 6 T1 feeds at some locations that will be using MLPPP for channel > bonding. This is a telco provided network that will be customer managed. It's not clear from your message, but I'm assuming the MLPPP will be from PE to CE and that the MPLS you speak of is MPLS VPN. If that's the case, on the customer end, it's just a MLPPP, and on your end, it's an MLPPP with an "ip vrf forwarding foo" statement. It's probably more than the average CCNA can handle (but so are MLPPP, MPLS, and most day to day IOS config work). Anyone who actually uses IOS on a regular basis (as opposed to someone who crammed for an exam and knows squat) should have no trouble with it. > The customer is being told by their router vendor that an MLPPP/MPLS > network is 'too complex' to be managed by anyone except for the router > vendor's VARs or the telco. They indicated that it would be impossible > for the customer's router vendor certified network person to come up to > speed on MLPPP/MPLS configurations and manage such a network -- that it > takes years to adequately learn how to manage that type of network > configuration. I think someone may be confusing "providing MPLS service" with "buying MPLS service". A customer buying MPLS VPN service never sees any of the MPLS tags or messes with MPLS/tag-switching commands. There is no added complexity...or at least there doesn't need to be any. > ================================================== > Filtered by: TRUSTEM.COM's Email Filtering Service > http://www.trustem.com/ > No Spam. No Viruses. Just Good Clean Email. Virus-free, because I say it is...and I run Pine on Linux :) ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

1 0

[operational update] Fast-Flux (fast IP changing hosts)
by Gadi Evron 18 Feb '06

18 Feb '06

[X-posted] I figure it's a good idea to update the ops community on a new term called Fast-Flux.. but for that you need a bit of background. There have been three *main* new phishing tricks used over the past year.. which will bring us to what interests us... POST information in the mail message ------------------------------------ That means that the user fills his or her data in the HTML email message itself, which then sends the information to a legit-looking site. The problem with that, is how do you convince an ISP that a real (compromised) site is indeed a phishing site, if there is no phishy-looking page there, but rather a script hiding somewhere? Trojan horses ------------- This is an increasing problem. People get infected with these bots, zombies or whatever else you'd like to call them and then start sending out the phishing spam, while alternating the IP address of the phishing server. Now.. Which brings us to... Fast-Flux --------- Fast Flux is a term coined in the anti spam world to describe such Trojan horses' activity. The DNS RR leading to the phishing server keeps changing, with a new IP address (or 10) every 10 minutes to a day. Trying to keep up and eliminate these sites before they move again is frustrating and problematic, making the bottle-neck the DNS RR which needs to be nuked. At times this is even on the domain level itself, making termination/suspension of the domain critical. This has been seen before, but before this past year mostly in POC's. This is mostly known is closed communities, and needs some public light. A lot more data and test cases out there, but I figure this is enough for now.. Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica.

1 0